The document introduces Architecture Description Languages (ADLs), explaining their purpose in formally specifying software architecture structure and behavior. It discusses the differences between types of specifications, such as structural and behavioral, and highlights the need for formal methods in ensuring systems meet required properties. Furthermore, it explores the prevalence of various ADLs in the industry, noting their diverse applications and the challenges in adopting a universal ADL.

1. _________ _____ ____ ____
_____
L05: Introduction to ADLs
Henry Muccini
DISIM, University of L’Aquila
henry.muccini@univaq.it

2. The material in these slides may be freely reproduced
and distributed, partially or totally, as far as an explicit
reference or acknowledge to the material author is
preserved.
Henry Muccini

3. Intro to SA Intro to Software Testing
SA Case study Structural Testing
SA style Model-based Testing
ADLs Architecture-based Testing
Design Decisions
Lab
Views/Viewpoints
UML Non Functional S.E.
UML Profiling Performance modeling
Lab Performance analysis

4. WEB:
www.di.univaq.it/muccini/SE+/2012/
SVN:
https://svn.di.univaq.it/seagroup/Courses/SE+2012/PROGETTI

5. HOW TO MODEL SA?

6. Which are the problems with such a notation?

7. There are three different options:
component ElevatorPanel is {
state {
vport : ViewportType;
sub_vports : set ViewportIDType;
}
invariant {
#sub_vports eqgreater 0;
}
interface {
prov ip_newvpt: createViewport() : ViewportType;
...
req ir_selshp: selectShipment(port : PortID; shp : ShipmentID);
}
operations {
prov op_subvpt: {
let vpt : ViewportIDType;
pre vpt not_in sub_vports;
post (#~sub_vports = #sub_vports + 1) and
(vpt in sub_vports);
} ...

8. Architecture Description Languages
An architecture description language (or architecture
definition language, or ADL) is a
•formal specification language
•for describing the structure and behavior of a
software architecture

9. ADLs Principles

10. Motivations: Why use Specifications
Specification is “the software lifecycle phase
concerned with precise definition of the tasks to be
performed by the system”[Meyer85]
To reveal ambiguity, incompleteness and inconsistency
→ Rephrasing: to be sure that the product released conforms to the customer
expectations
To prove that the system is:
→ Consistent
→ Complete
→ Unambiguous
→ Minimal
→ Adequate

11. Specification: What

12. Specification and Formal Specification
“Formal methods provide mathematically based techniques” that have the
additional advantage of “being amenable to machine analysis and
manipulation” [Wing90]
A Formal specification is the expression, in some formal language and at
some level of abstraction, of a collection of properties some system should
satisfy [Lam00]
A formal specification language consists of
→ syntax (the notation)
→ semantics (the specifiable objects)
→ satisfies relation (the semantics associated to the syntax)

13. Formal Specification: Why
Sometimes, systems must run reliably
for 99.9999 % of the time
semi-automated generation of test cases
from formally specified requirements
semi-automated derivation of correctness,
security, safety and other properties

14. Formal Specification: Why
For avoiding:
» [In]Consistency
1. [In]Completeness
2. [Non] Minimality

15. Types of Formal Specifications for SA modeling
Structural specifications:
→ Structural specifications describe topological constraints
→ Properties on the structure of the element in the
specification
Behavioral specification
→ Behavioral specifications describe
constraints on behavior of the
system
→ functional properties

16. Example
Structural specification

17. State Transition Specifications: the FSP Process Algebra
range N = 0..1
range K = 0..1 a)
range Sent = 0..1
/**UserProcess*/
USER_ALARM= (sendAlarm_To_Router -> receiveAck_From_Router -> USER_ALARM).
USER_CHECK = (sendCheck_To_Router -> USER_CHECK). b)
||USER = (USER_ALARM||USER_CHECK).
/**RouterProcess*/
ROUTER_RECEIVEALARM = (receiveAlarm_From_User -> sendAlarm_To_Server ->
receiveAck_From_Server -> sendAck_To_User -> ROUTER_RECEIVEALARM).
ROUTER_RECEIVECHECK = (receiveCheck_From_User -> (sendInput_To_Timer ->
ROUTER_RECEIVECHECK|pre_receiveCheck -> ROUTER_RECEIVECHECK)). c)
ROUTER_RECEIVETIME = (receiveTime_From_Timer ->(sendNoFunc_To_Server ->
ROUTER_RECEIVETIME|pre_receiveTime-> ROUTER_RECEIVETIME)).
||ROUTER = ([0..1]:ROUTER_RECEIVEALARM||[0..1]:ROUTER_RECEIVECHECK||
ROUTER_RECEIVETIME).
... d)
/**System*/
||ALL_PROCESSES=(u[0..1]:USER||r:ROUTER||sa[0..1]:SERVER||t:TIMER)/
{
u[0].sendAlarm_To_Router/r.[0].receiveAlarm_From_User, e)
u[1].sendAlarm_To_Router/r.[1].receiveAlarm_From_User,
...

18. ADL
ADL = Formal specifications for modeling SA concepts
Structural:
→Components, Connectors, Interfaces, Ports, Channels
→Configurations, Constraints, Properties
Behavioral:
→How components and connectors behave
→How they behave in integration
→Constraints, Properties

19. Practical ADLs

20. Existing ADLs (and many many more)
NOME ADL
NOME ADL
AADL
LISA
ABC/ADL
LITTLE JIL
ACME
MAE
ADAGE
MADL
ADLARS
MAFIIA
ADML
MAUDE
AESOP
M(énage / xADL
ArchJava
META H
ArchWare
MIMOLA
ArchiTRIO
MODE CHART
ARTECH
PALANTIR
C2
PRISMA
C2 AML
RADL
C2 SADEL
RAPIDE
CommUnity
RESOLVE
DAOP ADL
SADL
DARWIN
SATURN
DICAM
SKWYRL
EAST ADL UDL/i
EXPRESSION UNICON
GEN VOCA WEAVES
HMDES WRIGHT
ISDL WSDL
JACAL xArch / xAcme
KOALA xArch / xADL
LILEANNA xC2

21. NON PRESENZA DI BUON
ADL NON ADL NON PIU’ MANCANZA DI TOOL TOOLKIT E MANCANZA DI ADL NON SOFTWARE
CONVENZIONALE UTILIZZATO DI SUPPORTO MULTIPIATTAFORMA SPECIFIC
(V3) (V4) (V5) (V8.1) (V9)
OR OR OR OR
NON ESISTENZA DI
ADL DATATO
(V1)
AND APPLICAZIONI CHE
ESTEDONO
L’ADL
(V7)
OFFICIAL WEB SITE NON ESISTENZA DI
NON AND APPLICAZIONI CHE
ESTEDONO
AGGIORNATO
(V2) L’ADL
(V7)
REJECTED
SCARSE INFORMAZIONI NON ESISTENZA DI
CAUSA GIOVANE ETA’
DELL’ADL
AND APPLICAZIONI CHE
ESTEDONO
(V6) L’ADL
(V7)
NON ESISTENZA DI
PRESENZA DI BUON TOOLKIT APPLICAZIONI CHE
MA MANCANZA DI
MULTIPIATTAFORMA
AND ESTEDONO
(V8.2) L’ADL
(V7)

22. ADL/Tool Support
Mainly for Strongly Supports code Oriented to
Analysis oriented to generation and dynamic
Architectural architectural architectures
Styles programming via FSP
AADL/OSATE ACME/AcmeStudio AcmeArchJava DARWIN/SAA
Representationa Support to XML Schemas-
Supports for and Aspect based
model checking Implementatino Oriented and extensibility
SA of PLAs Component
Based
development
EAST-
EAST-ADL/AutoFocus2 xADL/Ménage-
xADL/Ménage-Palantir Prisma/PrismaCase xADL/ArchStudio

23. A Look to Some of them
Darwin & FSP
→ Imperial College London, J. Kramer & J. Magee
Koala
→ Philips Research
ACME
→ Carnegie-Mellon, D. Garlan
Rapide
→ Stanford, D. Luckham
xArch/xADL
→ University of California, Irvine

24. For distributed sytems
Darwin/FSP
[Darwin], [DarwinWeb]
range N = 0..1
range K = 0..1 a)
range Sent = 0..1
/**UserProcess*/
USER_ALARM= (sendAlarm_To_Router -> receiveAck_From_Router -> USER_ALARM).
USER_CHECK = (sendCheck_To_Router -> USER_CHECK). b)
||USER = (USER_ALARM||USER_CHECK).
/**RouterProcess*/
ROUTER_RECEIVEALARM = (receiveAlarm_From_User -> sendAlarm_To_Server ->
receiveAck_From_Server -> sendAck_To_User -> ROUTER_RECEIVEALARM).
ROUTER_RECEIVECHECK = (receiveCheck_From_User -> (sendInput_To_Timer ->
ROUTER_RECEIVECHECK|pre_receiveCheck -> ROUTER_RECEIVECHECK)). c)
ROUTER_RECEIVETIME = (receiveTime_From_Timer ->(sendNoFunc_To_Server ->
ROUTER_RECEIVETIME|pre_receiveTime-> ROUTER_RECEIVETIME)).
||ROUTER = ([0..1]:ROUTER_RECEIVEALARM||[0..1]:ROUTER_RECEIVECHECK||
ROUTER_RECEIVETIME).
... d)
/**System*/
||ALL_PROCESSES=(u[0..1]:USER||r:ROUTER||sa[0..1]:SERVER||t:TIMER)/
{
u[0].sendAlarm_To_Router/r.[0].receiveAlarm_From_User, e)
u[1].sendAlarm_To_Router/r.[1].receiveAlarm_From_User,
...

25. Koala [KoalaWeb][Koala]
Koala (Ommering, 2004) is an ADL specially designed for
modeling embedded software for consumer electronics.
It inherits from Darwin the main concepts and ideals, even
though it is more oriented to notations and concepts
commonly used in consumer electronics products.
Koala allows to specify hierarchical architectures, it makes
a distinction between component types and instances, it
allows to construct configurations by instantiating
components and connectors and explicitly models optional
interfaces.

26. For product lines
A graphical view of Koala

27. For modeling styles
AcmeStudio ACME tool

28. For formal verification
Rapide [Rapide, RapideWeb]
Rapide is an event-based ADL
→component behavior and interconnection represented by
─ explicit event sequences. Events are the method of
communication
─ event sequencing constraints
→Events organized in POSETs (Partially Ordered SETs)
→Specified systems can be simulated by Rapide toolset
→Simulations can be visualized in a graph format

29. POSETs
Consider events that a person might emit at a gas station:
→ Pull up
→ Leave
→ Use Credit Card Machine
→ Wash Windows
→ Pump Gas
What are the orderings
between these events?
Credit Card Pump Gas Wash
Pull Up Leave
Wash Credit Card Pump Gas
Credit Card Pump Gas

30. The Result

31. The Result
Could this be a problem?
Ability to specify Constraints
(patterns that should or should
not happen) are important in
finding these issues.

32. For extensibility
xArch/xADL 2.0 [xADL_Wicsa01]
xArch is an XML-based representation for building
ADLs.
It consists of a core of basic architectural elements,
defined in an XML schema called the “instances”
schema.
The xArch instances schema provides definitions for
the following elements typically found in an ADL:
•Component, connector, interface, and link instances;
•Subarchitectures, for specifying hierarchically composed component and
connector instances; and
•Groups, allowing the combination of basic elements

33. xArch XML Schema
Open the XMLinstance.html file

34. AADL Part of the material on AADL comes from
www.aadl.info and from Dr. Peter Feiler.
Notation for specification of runtime architecture of
real-time, embedded, fault-tolerant, secure, safety-
critical, software-intensive systems
Fields of application: Avionics, Aerospace, Automotive,
Autonomous systems, Medical devices
Based on 15 years of research & industry input
Standard approved & published Nov 2004
www.aadl.info

35. High level description of AADL
Developed and standardized under the auspices of the
International Society of Automotive Engineers (SAE)
Support the design and analysis of complex real-time
safety-critical systems in avionics, automotive, space,
…
AADL provides a formal mechanism to capture the
architecture specification
─ AADL -> mathematical analysis of real-time embedded,
multiprocessor, safety critical, fault tolerant systems (hardware
and software)
AADL is precise but abstract, incremental, system of
systems, extendable

36. Model-based Assurance
Availability
Predictive Analysis
& Reliability Across Perspectives Security
MTBF Intrusion
FMEA Integrity
Architecture Model Confidentiality
Hazard
analysis
Resource
Data Consumption
Quality
Bandwidth
Data precision/ Real-time CPU time
accuracy
Performance Power
Temporal consumption
Execution time/
correctness
Deadline
Confidence
Deadlock/starvation Reduced model
Latency validation cost due to
single source model

37. SAE AADL Standard
RMA Simplex MetaH
ACME
Automotive
Lehoczky Dependable Upgrade Error Model
Garlan
Klein Sha Honeywell
EDCS
HOOD Eclipse GME
MetaH
VanderBilt
Honeywell STOOD EMF
MoBIES
DSSA
MBE
Avionics
Avionics
SAE AADL AADL Meta
Standard Model & XMI
Nov 2004 June 2006 OSATE
Toolset
SEI
Aerospace
AADL UML AADL Error
Profile Std Annex Standard
2007 June 2006
Embedded
Systems Industry
Research Industrial Industrial Industrial Standards
Initiatives Projects Tools
Unmanned
www.aadl.info
Medical Vehicles Aerospace Avionics Automotive

38. Application Components
System: hierarchical organization
of components
Process: protected virtual address
space
Thread group: organization of
threads in processes
Thread: an active unit of
concurrent execution
Data: potentially sharable data
Subprogram: Callable unit of
sequential code

39. Why So Many ADLs?
There are many reasons for having many ADLs:
→Different ADLs for different “stakeholder concerns”
─ Different Domains
─ Different Analysis
─ Different Viewpoints
→Some of them are really similar, with just small semantic or
syntactic differences
→Many are just prototipal languages research specific

40. Problems with Existing ADLs
High degree of formality
→making difficult their integration in industrial life-cycles
Specialized semantic basis:
→Differentanalysis require different ADLs
→Impossible to construct an ADL which supports every kind of analysis
Limited tool support
Lack of lifecycle-wide support
Very limited industry buy-in to date

41. Our study
Goal:
→To understand which ADLs are used by industry
→To underestand what they like and do not like
→To understand how to plan for more practical ADLs
Plan:
→We identified 135 ADLs!!! (see googledocs)
→We interviewed 35 practitioners
─ from Volvo, IBM, ESA, Ericsson, CapGemini, SAP, Accenture Lab,
ABB, and many others

42. RQ1: most popular notations
RQ1: What are the most popular notations used by
the interviewed companies?
Standard notation types
45
40
→UML vs formal ADL 35
30
─ Standard notation types 25
20
15
10
5
0

43. RQ1: most popular notations
RQ1: What are the most popular notations used by
the interviewed companies?
→UML vs formal ADL
AS IS (73%)
─ Standard notation types
─ Do you use UML?
How?
PROFILED
(25%)
NO USAGE
(19%)

44. RQ1: most popular notations
RQ1: What are the most popular notations used by
the interviewed companies?
Kind of UML diagrams
→UML vs formal ADL
─ Standard notation types
Structural
─ Do you use UML? 38%
How? 57%
Behavioral
Which UML diagrams? 5%
Mixed(Structural/Behav
ioral)

45. RQ1: most popular notations
RQ1: What are the most popular notations used by
the interviewed companies?
→UML vs formal ADL
─ Standard notation types
─ Do you use UML?
How?
Which UML diagrams?
─ Used ADL (see next slide)

46. RQ1: Used ADLs
Used Architectural Notations
40
35
30
25
20
15
10
5
0

47. RQ1: most popular notations
RQ1: What are the most popular notations used by
the interviewed companies?
Use of multiple ADLs
→UML vs formal ADL
21%
Yes
79% No
─ About 21% of the respondents use multiple ADLs
─ Free sketching is advocated as useful

48. RQ1 - Summary
→Summary:
─ UML very used (86%)
─ Formal ADL: only rarely and produced by industry (AADL,
Archimate, ad hoc, Rapide)

49. usefulness of ADL features in past and future
projects

50. A Compromise: UML
UML is the de facto standard design notation of choice
in industrial software development
Understood by many industrial software developers
Reasonably applicable to software architectures
→ UML can be adapted for use as an ADL, but
─ Less formal and much more ambiguous than existing ADLs
─ Mature design environments, but lack of powerful analysis tools
Nowadays, many approaches to extend the UML for
SA modeling

51. In general
As a matter of fact, a Software Architect needs to use
different ADLs or UML profiles to model different
aspects of his system
→As analyzed in many papers, it is impractical to think about a
universal ADL covering all the different users’ concerns
→We will see our solution (DUALLY) in L17 and L18

52. What you shall have learned
You get the precise idea on what an ADL is
You get a precise idea on why there are many ADLs