Advanced Software Engineering course, a.y. 2014-2015
http://lore.com/Advanced-Software-Engineering-Univaq/
This lecture is about Architecture Description Languages. What they are, how they evolved in time, current challenges and perspectives.
1. Introduction to ADLs
Henry Muccini
henry.muccini@univaq.it
DISIM
Dep.nt of Information Engineering, Computer Science and Mathematics
University of L’Aquila, Italy
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.
Some material in this presentation has been previously
presented at ECSA 2014, tutorial T2: The Road Ahead for
Architectural Languages, P. Lago, I. Malavolta, H. Muccini,
P. Pelliccione, A. Tang
SEA Group
Henry Muccini
3. Intro to SA
SA Case study
SA style
ADLs
Design Decisions
Views/Viewpoints
SEA Group
Non Functional S.E.
Performance modeling
Performance analysis
UML
UML Profiling
Lab
4. An Architecture Description Language (ADL) (or
simply, AL) is a form of expression used for architecture
description. [ISO/IEC/IEEE 42010]
It may be a formal language (like Acme, Darwin, AADL),
a UML-based notation, as well as any other means you
may have used to describe a software architecture.
An ADL is tailored to specify SA concepts (components,
connectors, interfaces, …) through different viewpoints
SEA Group
5. 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
To prove that the system is:
SEA Group
7. 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
SEA Group
8. HISTORICAL VIEW
SEA Group
25+ years back
(maybe more…)
IIII hhhhaaaavvvveeee ttttoooo sssshhhhaaaarrrreeee wwwwiiiitttthhhh
aaaarrrrcccchhhhiiiitttteeeeccccttttssss tttthhhheeee
aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrreeee ssssoooolllluuuuttttiiiioooonnnn
IIII hhhhaaaavvvveeee iiiinnnn mmmmiiiinnnndddd....
WWWWhhhhaaaatttt sssshhhhaaaallllllll IIII uuuusssseeee????
SSSSooooffffttttwwwwaaaarrrreeee AAAArrrrcccchhhhiiiitttteeeecccctttt
10. HISTORICAL VIEW
10
SEA Group
Comp&C
on Spec
OOOOtttthhhheeeerrrr
CCCCoooonnnncccceeeerrrrnnnnssss
Interco
nnectio
n
Compo
sition
Abstracti
on
Reusabili
ty
Analysis
Hetero
geneity
Configur
ation
11. WHAT HAPPENED NEXT (1/2)
11
SEA Group
Darwin
first generation ALs [MDT07]
FSP
to support components and connectors specification, their overall
interconnection, composition, abstraction, reusability, configuration,
heterogeneity, and analysis
ACME
Rapide
Wright
ACME
12. HISTORICAL VIEW
12
SEA Group
Config.
Manage
ment
MMMMoooorrrreeee
CCCCoooonnnncccceeeerrrrnnnnssss
Distrib
ution
Product
Line
Styles
Differe
nt
domain
s
…
…
second generation ALs [MDT07]
13. UML FOR ARCHITECTURE DESCRIPTION
RRRReeeeaaaassssoooonnnnaaaabbbbllllyyyy aaaapppppppplllliiiiccccaaaabbbblllleeee ttttoooo ssssooooffffttttwwwwaaaarrrreeee aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrreeeessss
…
SEA Group
taken from https://code.google.com/p/staff/wiki/SoaApplicationStruct
15. OVERALL
15
Type of spec.
Language
SEA Group
Box and Line
Formal
UML
1990 2000 today
16. SEA Group
Pro:
.formal semantics
.computable
Cons:
.difficult to learn
.general lack of
industrial tools
.prolifetarion
Pro:
.not too difficult
.same notation for SA
and design modeling
Cons:
.not a 100% fit
.tool investment
Pro:
.of immediate use
.perfect for sketching
.communicative
Cons:
.Ambiguous
.non automated
16
17. TODAY
SEA Group
AL Name
AADL
ABC/ADL
ACME
ADAGE
ADLARS
ADML
AESOP
ArchJava
ArchWare
ArchiTRIO
ARTECH
C2
C2 AML
C2 SADEL
CommUnity
DAOP ADL
DARWIN
DICAM
EAST ADL
EXPRESSION
GEN VOCA
HMDES
ISDL
JACAL
KOALA
LILEANNA
AL Name
LISA
LITTLE JIL
MAE
MADL
MAFIIA
MAUDE
M(énage / xADL
META H
MIMOLA
MODE CHART
PALANTIR
PRISMA
RADL
RAPIDE
RESOLVE
SADL
SATURN
SKWYRL
UDL/i
UNICON
WEAVES
WRIGHT
WSDL
xArch / xAcme
xArch / xADL
xC2
100+ ALs
(better to say, languages that consider themselves to be ALs)
18. 100+ ALS
18
http://www.di.univaq.it/malavolta/al/
SEA Group
19. WHY SO MANY ALS?
TTTThhhheeeerrrreeee aaaarrrreeee mmmmaaaannnnyyyy rrrreeeeaaaassssoooonnnnssss ffffoooorrrr hhhhaaaavvvviiiinnnngggg mmmmaaaannnnyyyy AAAALLLLssss:
Different ALs for different “stakeholder concerns”
SEA Group
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
20. ISSUES (1/2)
PPPPrrrroooolllliiiiffffeeeerrrraaaattttiiiioooonnnn ooooffff llllaaaannnngggguuuuaaaaggggeeeessss ffffoooorrrr ((((SSSSAAAA)))) ddddeeeessssccccrrrriiiippppttttiiiioooonnnn
without a clear understanding of their merits and limitations.
TTTTeeeennnnssss ooooffff AAAALLLLssss,,,, cccchhhhaaaarrrraaaacccctttteeeerrrriiiizzzzeeeedddd bbbbyyyy sssslllliiiigggghhhhttttllllyyyy ddddiiiiffffffffeeeerrrreeeennnntttt ccccoooonnnncccceeeeppppttttuuuuaaaallll
aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrraaaallll eeeelllleeeemmmmeeeennnnttttssss,,,, ddddiiiiffffffffeeeerrrreeeennnntttt ssssyyyynnnnttttaaaaxxxx,,,, oooorrrr sssseeeemmmmaaaannnnttttiiiiccccssss....
Focussing on a generic or a specific operational domain
SSSSoooommmmeeee ssssuuuuppppppppoooorrrrtttt aaaauuuuttttoooommmmaaaatttteeeedddd aaaannnnaaaallllyyyyssssiiiissss,,,, ssssoooommmmeeee ooootttthhhheeeerrrrssss ddddoooo nnnnooootttt
20
SEA Group
21. ISSUES (2/2)
AAAAnnnn IIIIDDDDEEEEAAAALLLL aaaannnndddd ggggeeeennnneeeerrrraaaallll ppppuuuurrrrppppoooosssseeee AAAALLLL iiiissss NNNNOOOOTTTT lllliiiikkkkeeeellllyyyy ttttoooo eeeexxxxiiiisssstttt
SSSSttttaaaakkkkeeeehhhhoooollllddddeeeerrrr ccccoooonnnncccceeeerrrrnnnnssss are various, ever evolving, and adapting
to changing system requirements. [ISO/IEC/IEEE 42010]
Difficult to capture all such concerns with a single, narrowly
focused notation.
21
Architectural languages must be able to focus on
“what is needed” by the stakeholders involved in the
SEA Group
architecting process.
23. ADL/Tool Support
Mainly for
Analysis
Strongly
oriented to
Architectural
Styles
Supports code
generation and
architectural
programming
Oriented to
dynamic
architectures
via FSP
AADL/OSATE ACME/AcmeStudio AcmeArchJava DARWIN/SAA
Supports for
model checking
SEA Group
SA
Representationa
and
Implementatino
of PLAs
Support to
Aspect
Oriented and
Component
Based
development
XML Schemas-based
extensibility
EAST-ADL/AutoFocus2 xADL/Ménage-Palantir Prisma/PrismaCase xADL/ArchStudio
24. A Look to Some of them
Darwin FSP
SEA Group
→ 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
25. Darwin/FSP
SEA Group
[Darwin], [DarwinWeb]
range N = 0..1
range K = 0..1
range Sent = 0..1
a)
/**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,
...
For distributed sytems
26. Darwin
Darwin is a language for describing software structures, i.e., network
topologies.
Model distributed systems
Model dynamic systems
It possesses both a textual and graphical notation
SEA Group
[Darwin], [DarwinWeb]
27. Darwin Example [Darwin]
SEA Group
component filter{
provide outputstream char;
require inputstream char;
};
component pipeline(int n){
provide output;
require input;
array F[n]: filter;
forall k:0..n-1{
inst F[k] @ k+1;
when k n-1
bind F[k+1].input -- F[k].output;
}
bind
F[0].input -- input;
output -- F[n-1].output;
}
}
H2
28. Diapositiva 27
H2 The Example description is specified in the paper Specifying Distributed Software Architectures, [Darwin]
Henry_2; 10/10/2011
30. Diapositiva 28
h12 Take a look to the printed document
[SAA]
hank72; 18/09/2002
31. Chat in Darwin
Main differences:
There are not rules on how components and connectors need to be put together
Different interfaces for different messages
User 1
ok/no
chat chat register chat
Chat Client Chat Client Chat Client Chat Client Chat Client
SEA Group
User 2 User 3
Chat Log
Chat Room Chat Room
User 4
Reg. Dbase
run
run run
register
check
save
32. FSP
[FSP, FSPWeb]
The Finite State Process (FSP) is a specification language which provides a
concise way of describing Labeled Transition Systems (LTSs).
SEA Group
→Each FSP expression can be mapped onto a finite LTS and vice versa
The FSP specification is based on the definition of processes, whose behavior
is modeled by LTSs;
→each process instance implements an architectural component;
→several processes can be combined (with a parallel composition operator) to
describe the interaction between different processes.
The LTSA tool automatically generates the LTS associated to the FSP
specification
33. An example
range N = 0..1
range K = 0..1
range Sent = 0..1
/**UserProcess*/
USER_ALARM= (sendAlarm_To_Router - receiveAck_From_Router - USER_ALARM).
USER_CHECK = (sendCheck_To_Router - USER_CHECK).
||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)).
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).
...
/**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,
u[1].sendAlarm_To_Router/r.[1].receiveAlarm_From_User,
...
SEA Group
a)
b)
c)
d)
e)
35. 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.
SEA Group
38. SEA Group
Rapide
[Rapide, RapideWeb]
Rapide is an event-based ADL
For formal verification
→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
39. POSETs
Consider events that a person might emit at a gas station:
SEA Group
→ Pull up
→ Leave
→ Use Credit Card Machine
→ Wash Windows
→ Pump Gas
Credit Card Pump Gas
What are the orderings
between these events?
Pull Up Leave
Wash
Credit Card
Wash
Pump Gas
Credit Card Pump Gas
41. Diapositiva 38
h13 This example comes from http://pavg.stanford.edu/rapide/examples/teaching/gas_station/
that is linked in [RapideWeb]
hank72; 12/10/2002
42. The Result
Could this be a problem?
Ability to specify Constraints
(patterns that should or should
not happen) are important in
finding these issues.
SEA Group
43. xArch/xADL 2.0 [xADL_Wicsa01]
For extensibility
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:
SEA Group
•Component, connector, interface, and link instances;
•Subarchitectures, for specifying hierarchically composed component and
connector instances; and
•Groups, allowing the combination of basic elements
46. 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,
SEA Group
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
47. 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
SEA Group
─ 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
48. Model-based Assurance
SEA Group
Predictive Analysis
Across Perspectives Security
Intrusion
Integrity
Confidentiality
Availability
Reliability
MTBF
FMEA
Hazard
analysis
Real-time
Performance
Execution time/
Deadline
Deadlock/starvation
Latency
Resource
Consumption
Bandwidth
CPU time
Power
consumption
Data
Quality
Data precision/
accuracy
Temporal
correctness
Confidence
Architecture Model
Reduced model
validation cost due to
single source model
49. SEA Group
Model-Based Embedded System Engineering
Execution
Platform
Electronic
. . . . . . . . . .
Document the
Architecture
Abstract, but
Precise
Navigation
System
Airbag
Parking Deployment
Assistance
Emission
Management
Cruise
Control
Antilock
Braking
System
Application
Software
Fuel
Injection
System Analysis
• Schedulability
• Performance
• Reliability
• Fault Tolerance
• Dynamic Configurability
System Construction
• AADL Runtime System
• Application Software
Integration
External
Environment
50. SAE AADL Standard
Embedded
Systems
Research Industrial
SEA Group
MetaH
Honeywell
DSSA
RMA
Lehoczky
Klein
SAE AADL
Standard
Nov 2004
Industry
Industrial Standards
Projects
Industrial
Initiatives
Simplex
Dependable Upgrade
Sha
GME
VanderBilt
MoBIES
ACME
Garlan
EDCS
HOOD
STOOD
MetaH
Error Model
Honeywell
Automotive
Unmanned
Vehicles
OSATE
Toolset
SEI
AADL Meta
Model XMI
June 2006
AADL Error
Annex Standard
June 2006
AADL UML
Profile Std
2007
Tools
Aerospace Avionics
Medical
Automotive Avionics Aerospace
Eclipse
EMF
MBE
www.aadl.info
51. Industrial Embedded Systems
Initiatives
SEA Group
SAE AADL
Standard
Nov 2004
Automotive
OSATE
Toolset
SEI
AADL Meta
Model XMI
June 2006
AADL Error
Annex Standard
June 2006
Avionics
Aerospace
MBE
EAST ADL
AutoSAR
US AVSI Avionics Consortium
Analysis-based System Validation
8 partners $12+M 2007-2010
ITEA SPICES
Model-Driven Embedded
Systems Engineering
15 partners €16M 2006-2009
TOPCASED
Open Source Embedded
Systems Tool Framework
28 partners €20+M2005-2008
EC ASSERT
Proof-based Satellite
Architectures
ESA + 30 partners
€15M 2004-2007
IST ARTIST2
Embedded Systems
Center of Excellence
2007-2011
OpenGroup
Real-Time Forum
EU + US partners
52. Two-Tier Tool Strategy
Based on AADL XMI interchange format standard
Open Source Tool Solution
SEA Group
─ Low entry cost solution based on Eclipse Eclipse Modeling Framework
─ SEI Open Source AADL Tool Environment (OSATE) integrated with open source
Airbus TOPCASED tools
─ Vehicle for pilot projects, in-house prototyping, and architecture research
Commercial Tool Support
─ Addition of AADL to existing commercial environment (ElliDiss)
─ Interface with in-house commercial tools (Dassault, Airbus, Rockwell, Honeywell)
─ UML tool environment extension integration (Telelogic, Rational, Artisan,
MARTE)
53. AADL: The Language
Precise execution semantics for components interactions
SEA Group
─ Thread, process, data, subprogram, system, processor, memory, bus, device,
abstract component, virtual processor, virtual bus
Continuous signal processing stochastic event processing
─ Data, event, message communication, unqueued queued
─ Synchronous call/return, Shared data access
─ End-to-End flow specifications
Modeling of large-scale configurable systems
─ Component variants, packaging of component classifiers, layered systems,
parameterized templates, component arrays
Accommodation of diverse analysis needs
─ User-defined properties, sublanguage extensions
AADL V2
54. 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
SEA Group
55. 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
SEA Group
→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
57. Why So Many ADLs?
There are many reasons for having many ADLs:
SEA Group
→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
58. SEA Group
Problems with Existing ADLs
High degree of formality
→making difficult their integration in industrial life-cycles
Specialized semantic basis:
→Different analysis 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
59. SEA Group
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
60. 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
SEA Group
61. SEA Group
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)
h9
63. Formal Specification: Why
For avoiding:
SEA Group
» [In]Consistency
1. [In]Completeness
2. [Non] Minimality
64. Types of Formal Specifications for SA modeling
Structural specifications:
SEA Group
→ 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