_________ _____ ____ ____
_____
L05: Introduction to ADLs
Henry Muccini
DISIM, University of L’Aquila
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. preserved.
Henry Muccini
Intro to Software Testing
Structural Testing
Model-based Testing
Architecture-based Testing
Lab
Intro to SA
SA Case study
SA style
ADLs
Design Decisions
Views/Viewpoints
Non Functional S.E.
Performance modeling
Performance analysis
UML
UML Profiling
Lab
Views/Viewpoints
WEB: www.di.univaq.it/muccini/SE+/2012/
SVN:
https://svn.di.univaq.it/seagroup/Courses/SE+2012/PROGETTI
HOW TO MODEL SA?HOW TO MODEL SA?
Which are the problems with such a notation?
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);
} ...
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
ADLs PrinciplesADLs Principles
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:To prove that the system is:
→ Consistent
→ Complete
→ Unambiguous
→ Minimal
→ Adequate
Specification: What
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]
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)
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
Formal Specification: Why
For avoiding:
» [In]Consistency
1. [In]Completeness
2. [Non] Minimality
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
Example
Structural specification
State Transition Specifications: the FSP Process Algebra
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).
a)
b)
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,
...
c)
d)
e)
ADL
ADL = Formal specifications for modeling SA concepts
Structural:
→Components, Connectors, Interfaces, Ports, Channels
→Configurations, Constraints, Properties
Behavioral:Behavioral:
→How components and connectors behave
→How they behave in integration
→Constraints, Properties
Practical ADLsPractical ADLs
Existing ADLs (and many many more)
NOME ADL
AADL
ABC/ADL
ACME
ADAGE
ADLARS
ADML
AESOP
ArchJava
ArchWare
NOME ADL
LISA
LITTLE JIL
MAE
MADL
MAFIIA
MAUDE
M(énage / xADL
META H
MIMOLA
ArchiTRIO
ARTECH
C2
C2 AML
C2 SADEL
CommUnity
DAOP ADL
DARWIN
DICAM
EAST ADL
EXPRESSION
GEN VOCA
HMDES
ISDL
JACAL
KOALA
LILEANNA
MODE CHART
PALANTIR
PRISMA
RADL
RAPIDE
RESOLVE
SADL
SATURN
SKWYRL
UDL/i
UNICON
WEAVES
WRIGHT
WSDL
xArch / xAcme
xArch / xADL
xC2
ADL NONADL NONCONVENZIONALECONVENZIONALE
(V3)(V3)
ADL NON PIU’ADL NON PIU’UTILIZZATOUTILIZZATO
(V4)(V4)
MANCANZA DI TOOLMANCANZA DI TOOLDI SUPPORTODI SUPPORTO
(V5)(V5)
NON PRESENZA DI BUONNON PRESENZA DI BUONTOOLKIT E MANCANZA DITOOLKIT E MANCANZA DIMULTIPIATTAFORMAMULTIPIATTAFORMA
(V8.1)(V8.1)
ADL NON SOFTWAREADL NON SOFTWARESPECIFICSPECIFIC(V9)(V9)
OROR OROR OROR OROR
OFFICIAL WEB SITEOFFICIAL WEB SITENONNON
AGGIORNATOAGGIORNATO(V2)(V2)
NON ESISTENZA DINON ESISTENZA DIAPPLICAZIONI CHE APPLICAZIONI CHE
ESTEDONOESTEDONOL’ADLL’ADL(V7)(V7)
ADL DATATOADL DATATO(V1)(V1)
PRESENZA DI BUON TOOLKITPRESENZA DI BUON TOOLKITMA MANCANZA DIMA MANCANZA DI
MULTIPIATTAFORMAMULTIPIATTAFORMA(V8.2)(V8.2)
SCARSE INFORMAZIONISCARSE INFORMAZIONICAUSA GIOVANE ETA’CAUSA GIOVANE ETA’
DELL’ADLDELL’ADL(V6)(V6)
ANDAND
NON ESISTENZA DINON ESISTENZA DIAPPLICAZIONI CHE APPLICAZIONI CHE
ESTEDONOESTEDONOL’ADLL’ADL(V7)(V7)
NON ESISTENZA DINON ESISTENZA DIAPPLICAZIONI CHE APPLICAZIONI CHE
ESTEDONOESTEDONOL’ADLL’ADL(V7)(V7)
NON ESISTENZA DINON ESISTENZA DIAPPLICAZIONI CHE APPLICAZIONI CHE
ESTEDONOESTEDONOL’ADLL’ADL(V7)(V7)
ANDAND
ANDAND
ANDAND
REJECTEDREJECTED
Mainly for Analysis
Strongly oriented to Architectural
Styles
Supports code generation and architectural programming
Oriented to dynamic
architectures via FSP
ADL/Tool Support
AADL/OSATEAADL/OSATE ACME/AcmeStudioACME/AcmeStudio AcmeArchJavaAcmeArchJava DARWIN/SAADARWIN/SAA
EASTEAST--ADL/AutoFocus2ADL/AutoFocus2 xADL/MénagexADL/Ménage--PalantirPalantir Prisma/PrismaCasePrisma/PrismaCase xADL/ArchStudioxADL/ArchStudio
Supports for model checking
SA
Representationa and
Implementatino of PLAs
Support to Aspect
Oriented and Component Based
development
XML Schemas-based
extensibility
A Look to Some of them
Darwin & FSP → Imperial College London, J. Kramer & J. Magee
Koala→ Philips Research
ACME → Carnegie-Mellon, D. Garlan
RapideRapide→ Stanford, D. Luckham
xArch/xADL→ University of California, Irvine
Darwin/FSP[Darwin], [DarwinWeb]
For distributed sytems
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,
...
a)
c)
d)
b)
e)
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 makesKoala 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.
A graphical view of KoalaFor product lines
AcmeStudio ACME toolFor modeling styles
RapideRapide 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)
[Rapide, RapideWeb]
For formal verification
→Events organized in POSETs (Partially Ordered SETs)
→Specified systems can be simulated by Rapide toolset
→Simulations can be visualized in a graph format
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
Pull Up Leave
Wash
Credit Card Pump Gas
Credit Card
Wash
Pump Gas
Pump GasCredit Card
What are the orderings between these events?
The Result
The Result
Could this be a problem?Could this be a problem?
Ability to specify Constraints (patterns that should or should not happen) are important in finding these issues.
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.
For extensibility
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
xArch XML Schema
Open the XMLinstance.html file
AADL
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
Part of the material on AADL comes from
www.aadl.info and from Dr. Peter Feiler.
Autonomous systems, Medical devices
Based on 15 years of research & industry input
Standard approved & published Nov 2004
www.aadl.info
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 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
Model-based Assurance
Predictive Analysis
Across Perspectives SecurityIntrusion
Integrity
Confidentiality
Availability & Reliability
MTBF
FMEA
Hazard analysis
Architecture Model
Real-timePerformance
Execution time/Deadline
Deadlock/starvation
Latency
ResourceConsumption
Bandwidth
CPU time
Power consumption
Data precision/accuracy
Temporal correctness
Confidence
Data Quality
Reduced model validation cost due to single source model
SAE AADL Standard
MetaHHoneywell
DSSA
SAE AADL
RMALehoczky
Klein
Simplex Dependable Upgrade
Sha
GMEVanderBilt
MoBIES
ACMEGarlanEDCS
HOOD
STOOD
MetaH
Error ModelHoneywell
AADL Meta
Au
tom
otiv
eA
vio
nics
Eclipse
EMF
MBE
SAE AADLStandardNov 2004
Industry
StandardsIndustrial
Projects
Industrial
Initiatives
AutomotiveUnmanned
Vehicles
OSATEToolset
SEI
AADL Meta Model & XMIJune 2006
AADL Error Annex Standard
June 2006
AADL UML Profile Std
2007
AvionicsAerospace
EmbeddedSystemsResearch Industrial
Tools
Medical
Av
ion
icsA
erosp
ace
www.aadl.info
Application Components
System: hierarchical organization of components
Process: protected virtual address space
Thread group: organization of threads in processesthreads in processes
Thread: an active unit of concurrent execution
Data: potentially sharable data
Subprogram: Callable unit of sequential code
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
Problems with Existing ADLsHigh 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
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
RQ1: most popular notations
RQ1: What are the most popular notations used by
the interviewed companies?
→UML vs formal ADL
─ Standard notation types 25
30
35
40
45
Standard notation types
0
5
10
15
20
25
RQ1: most popular notations
RQ1: What are the most popular notations used by
the interviewed companies?
→UML vs formal ADL
─ Standard notation typesAS IS (73%)
─ Do you use UML?
How?
NO USAGE (19%)
PROFILED (25%)
RQ1: most popular notations
RQ1: What are the most popular notations used by
the interviewed companies?
→UML vs formal ADL
─ Standard notation types
Kind of UML diagrams
Structural
─ Do you use UML?
How?
Which UML diagrams?
38%
5%
57%
Structural
Behavioral
Mixed(Structural/Behav
ioral)
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)
RQ1: Used ADLs
20
25
30
35
40
Used Architectural Notations
0
5
10
15
20
RQ1: most popular notations
RQ1: What are the most popular notations used bythe interviewed companies?
→UML vs formal ADL
21%
Use of multiple ADLs
─ About 21% of the respondents use multiple ADLs
─ Free sketching is advocated as useful
79%
Yes
No
RQ1 - Summary
→Summary:
─ UML very used (86%)
─ Formal ADL: only rarely and produced by industry (AADL,
Archimate, ad hoc, Rapide)
usefulness of ADL features in past and future
projects
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─ 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
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
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