Kellan Hilscher
 Definition
 Different perspectives on the components, behavioral
specifications, and interactions that make up a software
system
 Importance of Formalized Architecture
 Architectural decisions have a very long lifespan
 Very valuable tool in developer and stakeholder
understanding of a system at a high level
 Increased potential for commonality across
architectures.
 Reduces time spent in maintenance and evolution
phases
 Formal languages that can be used to represent the
architecture of software-intensive systems.
 Evolved from Module Interconnection Languages
 Allow for very high level views of a system even before
design work begins
 Allow for early analysis and feasibility testing of
architectural possibilities
 How ADLs Work
 Decompose a system into multiple components,
connections, and configurations
 Standardization through the use of styles
 Provide different views of a system’s architecture
 Definition
 Diverse representations of a system’s architecture for
distinct audiences and uses
 Ex. Structural, behavioral, physical
 Viewpoints address concerns identified by particular
stakeholders
 Ex. A process viewpoint might address concurrency,
distribution, scalability, and integration
 First version released in 1997
 Similar to IBM Rational for UML
 Two components:
 Acme ADL
 AcmeStudio
 Can act as a vehicle for standardizing elements used
across multiple ADLs
 Architecture (formerly Avionics) Analysis & Design
Language
 Describes DRE architectures with software and
hardware components
 Dissuades “build then test” mentality
 Specialized for processor architecture description.
 Allows users to generate assemblers and simulators for
processors from:
 Architecture Resources: User provides processor
resource info from programmer’s manual
 Instruction Set Architecture: User enters information
about each instruction such as format and syntax,
behavior, and info for decoding
 Tailors the modeling environment to your processor
 No clear consensus on what is required of architecture
modeling (or ADLs)
 Can be very convoluted
 Many lack explicit mechanisms for multiple
architecture views.
 “[A]n ADL for software application focuses on the
high-level structure of the overall application
rather than the implementation details of any
specific source module”
 Less formalized than ADLs
 No notion of entity restriction (styles)
 Largely a documenting language
 Idea:
 One view cannot capture an entire complex architecture
 Concurrent views:
 4:
 Logical View – Object Model
 Process View – Concurrency Model
 Physical View – Mapping and distribution of software to
hardware
 Development View – Development environment view
 +1:
 Use Cases/Scenarios
 Logical Model
-> Class Diagram
 Process Model
-> Activity Diagram
 Development Model
-> Package Diagram
 Physical Model
-> Deployment Diagram
 Wraps the notion of component standardization
around design languages:
 Contexts (styles)
 Properties (style conformant attributes)
 Operations (define property behavior)
 Provides additions to graph navigations
 Less ambiguity
 OCL tools parse UML diagrams to provide further
analysis