software architecture: architecture description languages

_________ _____ ____ ____

_____

L05: Introduction to ADLs

Henry Muccini

DISIM, University of L’Aquila

[email protected]

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)


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,


...

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







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 ->


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)/

{



...

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





─ Standard notation typesAS IS (73%)

─ Do you use UML?

How?

NO USAGE (19%)

PROFILED (25%)





─ 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)





─ 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: What are the most popular notations used bythe interviewed companies?


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

software architecture: architecture description languages

Education