Software Architecture: Architecture Description Languages

6,592 views
6,262 views

Published on

This is an introductory lecture to Architecture Description Languages, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)

Published in: Education
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,592
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
196
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

Software Architecture: Architecture Description Languages

  1. 1. _________ _____ ____ ____ _____L05: Introduction to ADLs Henry Muccini DISIM, University of L’Aquila henry.muccini@univaq.it
  2. 2. The material in these slides may be freely reproducedand distributed, partially or totally, as far as an explicitreference or acknowledge to the material author ispreserved. Henry Muccini
  3. 3. Intro to SA Intro to Software TestingSA Case study Structural TestingSA style Model-based TestingADLs Architecture-based TestingDesign Decisions LabViews/ViewpointsUML Non Functional S.E.UML Profiling Performance modelingLab Performance analysis
  4. 4. WEB:www.di.univaq.it/muccini/SE+/2012/SVN:https://svn.di.univaq.it/seagroup/Courses/SE+2012/PROGETTI
  5. 5. HOW TO MODEL SA?
  6. 6. Which are the problems with such a notation?
  7. 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. 8. Architecture Description LanguagesAn architecture description language (or architecturedefinition language, or ADL) is a •formal specification language •for describing the structure and behavior of a software architecture
  9. 9. ADLs Principles
  10. 10. Motivations: Why use SpecificationsSpecification is “the software lifecycle phaseconcerned with precise definition of the tasks to beperformed by the system”[Meyer85]To reveal ambiguity, incompleteness and inconsistency → Rephrasing: to be sure that the product released conforms to the customer expectationsTo prove that the system is: → Consistent → Complete → Unambiguous → Minimal → Adequate
  11. 11. Specification: What
  12. 12. Specification and Formal Specification“Formal methods provide mathematically based techniques” that have theadditional advantage of “being amenable to machine analysis andmanipulation” [Wing90]A Formal specification is the expression, in some formal language and atsome level of abstraction, of a collection of properties some system shouldsatisfy [Lam00]A formal specification language consists of → syntax (the notation) → semantics (the specifiable objects) → satisfies relation (the semantics associated to the syntax)
  13. 13. Formal Specification: WhySometimes, systems must run reliablyfor 99.9999 % of the timesemi-automated generation of test cases from formally specified requirementssemi-automated derivation of correctness, security, safety and other properties
  14. 14. Formal Specification: WhyFor avoiding: » [In]Consistency 1. [In]Completeness 2. [Non] Minimality
  15. 15. Types of Formal Specifications for SA modelingStructural specifications: → Structural specifications describe topological constraints → Properties on the structure of the element in the specificationBehavioral specification → Behavioral specifications describe constraints on behavior of the system → functional properties
  16. 16. ExampleStructural specification
  17. 17. State Transition Specifications: the FSP Process Algebrarange N = 0..1range 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. 18. ADLADL = Formal specifications for modeling SA conceptsStructural: →Components, Connectors, Interfaces, Ports, Channels →Configurations, Constraints, PropertiesBehavioral: →How components and connectors behave →How they behave in integration →Constraints, Properties
  19. 19. Practical ADLs
  20. 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. 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) REJECTEDSCARSE INFORMAZIONI NON ESISTENZA DI CAUSA GIOVANE ETA’ DELL’ADL AND APPLICAZIONI CHE ESTEDONO (V6) L’ADL (V7) NON ESISTENZA DIPRESENZA DI BUON TOOLKIT APPLICAZIONI CHE MA MANCANZA DI MULTIPIATTAFORMA AND ESTEDONO (V8.2) L’ADL (V7)
  22. 22. ADL/Tool Support Mainly for Strongly Supports code Oriented to Analysis oriented to generation and dynamic Architectural architectural architectures Styles programming via FSPAADL/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 developmentEAST-EAST-ADL/AutoFocus2 xADL/Ménage- xADL/Ménage-Palantir Prisma/PrismaCase xADL/ArchStudio
  23. 23. A Look to Some of themDarwin & FSP → Imperial College London, J. Kramer & J. MageeKoala → Philips ResearchACME → Carnegie-Mellon, D. GarlanRapide → Stanford, D. LuckhamxArch/xADL → University of California, Irvine
  24. 24. For distributed sytems Darwin/FSP [Darwin], [DarwinWeb]range N = 0..1range 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. 25. Koala [KoalaWeb][Koala]Koala (Ommering, 2004) is an ADL specially designed formodeling embedded software for consumer electronics.It inherits from Darwin the main concepts and ideals, eventhough it is more oriented to notations and conceptscommonly used in consumer electronics products.Koala allows to specify hierarchical architectures, it makesa distinction between component types and instances, itallows to construct configurations by instantiatingcomponents and connectors and explicitly models optionalinterfaces.
  26. 26. For product linesA graphical view of Koala
  27. 27. For modeling stylesAcmeStudio ACME tool
  28. 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. 29. POSETsConsider 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. 30. The Result
  31. 31. The ResultCould this be a problem? Ability to specify Constraints (patterns that should or should not happen) are important in finding these issues.
  32. 32. For extensibilityxArch/xADL 2.0 [xADL_Wicsa01]xArch is an XML-based representation for buildingADLs.It consists of a core of basic architectural elements,defined in an XML schema called the “instances”schema.The xArch instances schema provides definitions forthe 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. 33. xArch XML SchemaOpen the XMLinstance.html file
  34. 34. AADL Part of the material on AADL comes from www.aadl.info and from Dr. Peter Feiler.Notation for specification of runtime architecture ofreal-time, embedded, fault-tolerant, secure, safety-critical, software-intensive systemsFields of application: Avionics, Aerospace, Automotive,Autonomous systems, Medical devicesBased on 15 years of research & industry inputStandard approved & published Nov 2004www.aadl.info
  35. 35. High level description of AADLDeveloped and standardized under the auspices of theInternational Society of Automotive Engineers (SAE)Support the design and analysis of complex real-timesafety-critical systems in avionics, automotive, space,…AADL provides a formal mechanism to capture thearchitecture specification ─ AADL -> mathematical analysis of real-time embedded, multiprocessor, safety critical, fault tolerant systems (hardware and software)AADL is precise but abstract, incremental, system ofsystems, extendable
  36. 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. 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 2006Embedded Systems IndustryResearch Industrial Industrial Industrial Standards Initiatives Projects Tools Unmanned www.aadl.infoMedical Vehicles Aerospace Avionics Automotive
  38. 38. Application ComponentsSystem: hierarchical organizationof componentsProcess: protected virtual addressspaceThread group: organization ofthreads in processesThread: an active unit ofconcurrent executionData: potentially sharable dataSubprogram: Callable unit ofsequential code
  39. 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. 40. Problems with Existing ADLsHigh degree of formality →making difficult their integration in industrial life-cyclesSpecialized semantic basis: →Differentanalysis require different ADLs →Impossible to construct an ADL which supports every kind of analysisLimited tool supportLack of lifecycle-wide supportVery limited industry buy-in to date
  41. 41. Our studyGoal: →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 ADLsPlan: →We identified 135 ADLs!!! (see googledocs) →We interviewed 35 practitioners ─ from Volvo, IBM, ESA, Ericsson, CapGemini, SAP, Accenture Lab, ABB, and many others
  42. 42. RQ1: most popular notationsRQ1: What are the most popular notations used bythe interviewed companies? Standard notation types 45 40 →UML vs formal ADL 35 30 ─ Standard notation types 25 20 15 10 5 0
  43. 43. RQ1: most popular notationsRQ1: What are the most popular notations used bythe interviewed companies? →UML vs formal ADL AS IS (73%) ─ Standard notation types ─ Do you use UML? How? PROFILED (25%) NO USAGE (19%)
  44. 44. RQ1: most popular notationsRQ1: What are the most popular notations used bythe 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. 45. RQ1: most popular notationsRQ1: What are the most popular notations used bythe interviewed companies? →UML vs formal ADL ─ Standard notation types ─ Do you use UML? How? Which UML diagrams? ─ Used ADL (see next slide)
  46. 46. RQ1: Used ADLs Used Architectural Notations40353025201510 5 0
  47. 47. RQ1: most popular notationsRQ1: What are the most popular notations used bythe 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. 48. RQ1 - Summary →Summary: ─ UML very used (86%) ─ Formal ADL: only rarely and produced by industry (AADL, Archimate, ad hoc, Rapide)
  49. 49. usefulness of ADL features in past and futureprojects
  50. 50. A Compromise: UMLUML is the de facto standard design notation of choice in industrial software developmentUnderstood by many industrial software developersReasonably 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 toolsNowadays, many approaches to extend the UML for SA modeling
  51. 51. In generalAs a matter of fact, a Software Architect needs to usedifferent ADLs or UML profiles to model differentaspects 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. 52. What you shall have learnedYou get the precise idea on what an ADL isYou get a precise idea on why there are many ADLs

×