2. How would you define an Architecture
Description Language (ADL)?
Architecture Description Languages (ADLs) are formal
languages that can be used to represent the architecture
of a software-intensive system
How would you define an architecture?
The components that comprise a system;
The behavioural specifications for those components;
The patterns and mechanisms for interactions among
them.
3. What are the main differences between
ADL and requirements?
In principle…
… Requirements describe problem spaces, while
… ADL are rooted in the solution space.
In practice…
… Requirements are often divided into behavioural chunks for
ease of presentation,
… Languages such as ADLs are more suited to represent
architectural components.
4. What are the main differences between
ADL and programming languages?
In principle…
… Programming languages bind all architectural abstractions to
specific point solutions, while
… ADLs intentionally suppress or vary such binding.
In practice…
… Architecture is embodied and recoverable from code, while
… Languages provide architecture-level views of the system.
5. What are the main differences between
ADL and modelling languages?
In principle…
… Modelling languages are more concerned with the
behaviours of the sholw rather than of the parts, while
… ADLs concentrate on representation of components.
In practice…
… Many modelling languages allow the representation of
cooperating components and can represent architectures
reasonably well.
6. Which leads to the question…
Why do we study ADLs when modelling
languages, such as UML, “can represent
architectures quite well”?
7. Properties that ADLs should exhibit:
[Shaw] [Luckham]
Ability to represent Component abstraction
components Communication abstraction
Ability to represent Communication integrity
connectors Ability to model dynamic
Abstraction and architectures
encapsulation Ability to reason about
Types and Type-checking causality and time
Ability to accommodate Hierarchical refinement
analysis tools openly support
Relativity, the mapping of
behaviours to architecture
What are the commonalities between the two lists?
8. Do you think that researchers are re-
inventing the wheel of ADLs?
9. Why do you think ADLs still lack
industrial applicability?
11. Two aspects of ADL:
1. To aid understanding and
communication about a software system
2. To provide formal syntax and semantics
of ADLs, powerful analysis tools and
runtime support tools.
Researchers have generally adopted one or
another…
12. Tracz defines an ADL as consisting
of four “C”s: components,
connectors, configurations and Given that there is
constraints. NO standard
Medvidovic and colleagues argue definition of what
that it is vital to model
architectures at four levels of
abstraction: internal component
{ properties an ADL
should exhibit, do
you think ADL
semantics, component interfaces, interchange is
component interconnections in an possible?
architecture, and architectural style
rules.
We have seen Luckham and Shaw
in the previous paper…
If you had to define a consensus of an
ADL, what would that be?
13. Different types of ADLs:
Implementation Implementation
Independent Constraining
Wright and Rapide: Weaves
Model components and UniCon
connectors at a high level
of abstraction; MetaH
Do not assume or Require a much higher degree
prescribe a particular of fidelity of an architecture to
relationship between an its implementations.
architectural description
Components are directly
and an implementation.
related to their
implementations
What do you think is the most successful ADL?
Implementation Independent or Constraining?
15. So previously we discussed ADL
vs. Modelling Languages,
especially UML…
Here, the paper states that:
{ “Although UML may provide
modeling power equivalent to or
suprassing that of an ADL, the
abstractions it provides will not
match an architect’s mental
model of the system”.
16. Statecharts is a modeling formalism based on
finite state machines (FSM) that provides a
state encapsulation construct, support for
concurrency, and broadcast communication.
{ Comparing Statecharts & ADLs
States -> components
Transitions -> connectors
Interconnections -> configurations
17. Do you think Statechart is
an ADL?
Statechart is NOT an ADL!
18. Each ADL models
components
ACME, Aesop, CS, Darwin, SADL, UniCon and
Wright -> components;
Rapide -> interfaces;
Weaves -> tool fragments;
MetaH -> processes.
---> Differ in the Terminology!
Different ADLs focus on different application domains,
architectural styles, or aspects of the architectures they
model.
19. PLAYER input IS StreamIn
MAXASSOCS (1)
MINASSOCS(1)
SIGNATURE (“line”)
PORTBINDING (stdin)
END input
{ UniCon
Explanation: The constraint that the input player of StreamIn
type is bound to standard input and participates in exactly one
association in a given architecture.
20. port DataRead = get DataRead ☐
✓
Explanation: Interaction protocol for a component port.
: event transition
✓ : successfully terminating process
☐ : deterministic choice
{ Wright
21. Local_client : TYPE = {c:Client | Local(c)}
Explanation: Local_client is a subtype of Client such that all of
its instance satisfy the predicate Local.
{ SADL
22. Do you think an ADL is
capable of specifying non-
functional component
requirements?
ACME, Aesop and Weaves lack support.
MetaH and UniCon provide more support
for modelling non-functional properties.
23. ADLs that model
connectors
ACME, Aesop, C2, SADL, UniCon and Wright ->
connectors;
Rapide and MetaH-> connections;
Weaves -> transport services;
Darwin -> bindings.
---> Differ in the Terminology!
24. ROLE output IS Source
MAXCONNS(1)
END input
Explanation: Belongs to the Pipe connector type and is
constrained to be connected to at most a single player.
Example of
{ connector in
UniCon
25. What about Non-Functional
Connector Properties?
UniCon is the only ADL that
supports explicit specification
of non-functional connector
properties.
26. ADLs that model
configurations
In-line configuration ADLs (ex. Rapide) tend to be
encumbered with connector details.
Explicit configuration ADLs (ex. Wright) have the
best potential to facilitate understandability of
architectural structure.
27. Configurations are used to facilitate
communication among different
stakeholders with different level of
technical expertise.
In-line configuration ADLs (ex. Rapide) tend to be
encumbered with connector details.
Explicit configuration ADLs (ex. Wright) have the
best potential to facilitate understandability of
architectural structure.
28. ADLs support development in the
following programming languages:
Aesop and Darwin C++;
MetaH Ada;
Unicon C;
C2 C++, Ada and Java;
Weaves C, C++, Objective C and Fortran.
29. Scaling an Architecture
An existing
architecture is
{ scaled up: (a) by
adding new
components/conn
ectors to its
interior and (b)
by expanding it
C2’s graphical notation “outward”.
Can you name any disadvantages between
the two different scaling approaches?
30. Evolvability
What are the two different perspectives of
evolvability of architectural configuration?
The ability to accommodate addition of new
components (as shown in the previous slide).
An ADL’s tolerance and/or support for incomplete
architectural descriptions.
31. What is Architecture
Tradeoff Analysis Method
(ATAM)?
- A comprehensive way to evaluate a
software architecture;
- Reveals how well an architecture
satisfies particular quality goals;
- Provides insight into how quality
goals interact.
32. ATAM requires
participation and mutual
cooperation of 3 groups:
1. The evaluation team – an external group
to the project.
2. Project decision makers – are empowered
to speak for the development project or
have to mandate changes to it.
3. Architecture stakeholders.
33. Outputs of the ATAM
- A concise presentation of the
architecture;
- Articulation of the business goals;
- Quality requirements in terms of a
collection of scenarios;
- Mapping of architectural decisions to
quality requirements;
- A set of identified sensitivity and
tradeoff points;
- A set of risks and non risks;
- A set of risk themes.
34. Phases of the ATAM
Phase Activity Participants Typical
Duration
0 Partnership and Evaluation team Proceeds informally
Preparation leadership and key project as required, perhaps
decision makers over a few weeks.
1 Evaluation Evaluation team and 1 day followed by a
project decision makers hiatus of 2 to 3
weeks
2 Evaluation Evaluation team, project 2 days
(continued) decision makers and
stakeholders
3 Follow-up Evaluation team and 1 week
evaluation client