With very special thanks to David S. Rosenblum, Richard N. Taylor and Eric M. Dashofy for the use of their materials.
1
Informal notations (boxes and arrows) are ambiguous, imprecise, unanalyzable, … SA management is expensive and time consuming
maximize the benefits Analyze SA as much as possible To perform automatic or semi-automatic analysis, formal specifications are necessary
73/2
73/3
321sci/iniccum~/ude.icu.sci.www//:ptth ]iniccuM .H :rerutceL[
ytilibareporetnI dna ,smetsyS detubirtsiD ,serutcetihcrAerawtfoS
segaugnaL noitpircseD erutcetihcrA
An architecture description language (or architecture definition language, or ADL) is a formal notation for describing the structure and behavior of a software architecture ADLs provide
a concrete syntax a formal semantics a conceptual framework for explicitly modeling the conceptual architecture of a system
A programming language is used to define the implementation architecture of a system
LDA :5 erutceL
sLDA gnisU sLDA emoS sLDA yhW si LDA na tah W -
)2002 llaF(
?sLDA yhW
321 SCI
⇒ ⇒
⇒
1
From Medvidovic and Taylor, 2000:
“An ADL must explicitly model components, connectors, and their configurations; furthermore, to be truly usable and useful, it must provide tool support for architecture-based development and evolution. These four elements of an ADL are further broken down into constituent parts.” “In order to infer any kind of information about an architecture, at a minimum, interfaces of constituent components must also be modeled. Without this information, an architectural description becomes but a collection of (interconnected) identifiers, similar to a “boxes and lines” diagram with no explicit underlying semantics.”
There is, however, still little consensus in the research community on what an ADL is, what aspects of an architecture should be modeled by an ADL… This can be a good thing!
Model only what you will find useful. Model things that your tools can work with or analyze. Model critical aspects of your software system in more detail.
This can be a bad thing!
Limits on architectural interchange. Limits applicability of tools on divergent notations.
Not everybody agrees on what else goes in an ADL
73/6
73/4
73/5
?noitpircseD erutcetihcrA erawtfoS a ni seoG tahW
?LDA na ni seog yllaer tahW
…LDA laedi nA
An ideal architectural description language would provide [GarlanShawBook]
Composition: it should be possible to describe systems as composed of existent libraries of components and connectors; Abstraction: components and connectors should be described at a desired level of abstraction hiding unnecessary details and putting in evidence important properties; Reusability: components, connectors and whole architectures should be reused to develop new components, connectors and system architectures; Analysis: architectural descriptions should be analyzed.
2
Darwin & FSP
Imperial College London, J. Kramer & J. Magee
Rapide
Stanford, D. Luckham
Cham
Inverardi and Wolf
ACME
Carnegie-Mellon, D. Garlan
[Darwin], [DarwinWeb]
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
73/7
73/8
73/9
meht fo emoS ta kooL feirB A
sLDA emoS
Darwin & FSP Distributed systems Rapide Events Wright Behavioral Properties Chemical Abstract Machine (Cham) Reactions C2SADL Dynamic Systems Koala Product Families xADL1.0 Implementation mappings ...
Papers on ADL: [ADL_Neno97,GarlanPerry95]
niwraD
3
component filter{ provide output; require input; };
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; } }
[FSP, FSPWeb]
The Finite State Process (FSP) is a specification language which provides a concise way of describing Labeled Transition Systems (LTSs).
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
73/21
73/01
73/11
]AAS[]looT_niwraD[
]niwraD[
elpmaxE niwraD slooT :niwraD PSF
4
[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
73/51
73/31
73/41
elpmaxe nA
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)/ { e) u[0].sendAlarm_To_Router/r.[0].receiveAlarm_From_User, u[1].sendAlarm_To_Router/r.[1].receiveAlarm_From_User, ...
edipaR
5
Consider events that a person might emit at a gas station:
Pull up Leave Use Credit Card Machine Wash Windows Pump Gas
6
73/81
.seussi eseht gnidnif ni tnatropmi era )neppah ton dluohs ro dluohs taht snrettap( stniartsnoC yficeps ot ytilibA
?melborp a eb siht dluoC
tluseR ehT
73/71
tluseR ehT
73/61
saG pmuP saG pmuP evaeL hsaW draC tiderC saG pmuP
draC tiderC hsaW pU lluP draC tiderC
?stneve eseht neewteb sgniredro eht era tahW
sTESOP
Chat Client:
A Chat Client is used by users to chat with other users in a Chat Room. A user must first register with a particular Chat Room before chatting with other users in that room. A User may start different Chat Clients to chat in multiple Chat Rooms It queries the Registration Database to ensure that the user associated with a message is currently registered to chat in the room. If the user is registered, the message is delivered to all other users registered in the room, and a copy of the message is filed in a Chat Log associated with the Room. There are multiple Chat Room components available, each devoted to a different chat topic.
Chat Room:
Registration Database:
The Registration Database stores the set of currently registered users for each Chat Room and is able to remember which users are registered with which Chat Room. There is one Registration Database in the system.
Chat Log:
The Chat Log stores a record of all messages sent in a Chat Room. There is one Chat Log associated with each Chat Room.
73/02
Components and Connectors - P: User1, User2, ChatRoom1, ChatRoom2, ChatLog1, Chat Log2, RegistrationDbase, - C: register, AskForChat, chat, NoChat, YesChat, disconnect, … Transition Rules: … User1.o(AskForChat), ChatRoom1. i(AskForChat) = User1.o(chat), ChatRoom1. i(chat) User1.o(disconnect), ChatRoom1.i(disconnect) - > User1.o(AskForChat), ChatRoom1.i(AskForChat) … Initial State: User = User1, User2, UserN User1 = User1.o(AskForChat), User1.o(register) ChatRoom = ChatRoom1, ChatRoom2, ChatRoomM ChatRoom1 = ChatRoom1. i(AskForChat)
Differences with other ADLs: It is totally context aware… It does not specify the behavior of each component
73/12
73/91
)mahC( enihcaM tcartsbA lacimehC ehT
A Cham specification identify: Cham specifications have been used for:
Deadlock detection in SA specifications Testing of SAs Performace evaluation of SAs …
[Cham, ChamSA]
a solution S0 representing the initial state of the system; a set R of reaction rules describing how the components interact to achieve the dynamic behavior of the system. a set of solutions S representing the intended final states of the system. a description of the syntax Σ by which components of the system (i.e., the molecules) can be represented;
tahC MAHC A elpmaxE nA
7
Also UML has been used to describe Software Architectures There are, at least, four different approaches We will analyze them in Lecture 7
73/22
73/32
73/42
oidutSEMCA
LMU dna AS
EMCA
[AcmeWeb]
ACME is and ADL that can be used as an architectural interchange language Three main capabilities:
Interchange:
Acme allows architectural tool developers to readily integrate their tools with other complementary tools. architects using Acme-compliant tools have a broader array of analysis and design tools available at their disposal than architects locked into a single ADL.
Basis for new tools:
It provides a language and toolkit to use as a foundation for building tools
Architecture Description:
It provides a straightforward set of language constructs for describing architectural structure, architectural types and styles
8
If nothing else, an ADL must allow precise, accurate representation of an architecture, to support understanding and communication between stakeholders Key differentiator: Are connectors modeled explicitly as first-class architectural entities?
No: in-line configuration languages Yes: explicit configuration languages
73/52
73/62
73/72
ssecorP ngiseD
n o i t u l o v E . 2
ytilibaecarT.2
troppuS
esU ot sLDA gnittuP
tnemenifeR.2
noitatneserpeR.1
noitatneserpeR.1
sLDA gnisU
noitucexE dna noitalumiS.4 sisylanA.3
9
Refinement
ClientB
noitulovE dna ytilibaecarT ,tnemenifeR :esU ot sLDA gnittuP
Refinement Proof-based checking between levels of abstraction Different granularity Traceability is a more general and less restrictive form of refinement Relationships between views and between levels of abstraction Relationships between SA description and its real implementation Relationships in the software process Two kinds of evolution Specification-time Execution-time
Planned at specification time or unplanned
73/92
Software Architecture
Client
Server
ServerMaster Client ServerSlave
Traceability & Analysis
ClientA
ServerMaster Recovery Server Slave
Traceability & Analysis
73/82
73/03
noitulovE dna ytilibaecarT ,tnemenifeR.2
)ytilibaecarT dna tnemenifer( elpmaxE laivirt A
ssecorP ngiseD troppuS
noitucexE dna n noitalumiS.4 o i t u l o tnemenifeR.2 v E ytilibaecarT.2 . 2 sisylanA.3
noitatneserpeR.1
10
SA 1
ClientA
SA 2
ClientA
ServerMaster Recovery
ServerMaster Recovery
Evolution
ClientB
ClientB
Server Slave
Server Slave
ClientC
Analysis
- Are we sure that the SA 2 model is still conform to the SA 1 Requirements? - What about the performance of the two models? - If we tested SA 1 what we need to retest in SA 2?
Treating an architectural model as a prototype Increased understanding of consequences of design decisions Increased communication with customer Dynamic analysis of behavior, performance, reliability
73/13
73/23
73/33
)sisylanA dna noitulovE( elpmaxE laivirt A
noitucexE dna noitalumiS .4
sisylanA dna AS .3
SA and Testing SA and Coordination models Model checking SA SA and Performance Analysis Deadlock detection on SA-based specification SA and Security Refining SA SA-based development processes ADL-based analysis of SA
For more information, refers to [Muccini02]
11
No “one true approach” Flexibility, interchange, evolvability of ADLs is still unachieved
But we’re getting there, and hopefully will be there soon!
[Darwin] J. Magee, N. Dulay, S. Eisenbach and J. Kramer. Specifying distributed software architectures. In Proc. ESEC95, September 1995. [DarwinWeb] http://www.doc.ic.ac.uk/~jsc/research/darwin.html [DarwinTool] http://www.doc.ic.ac.uk/~igeozg/Project/Darwin/ [SAA] Software Architect’s Assistant, http://www.doc.ic.ac.uk/~kn/saa.html [FSP] J. Magee and J. Kramer. Concurrency: State models & java programs. Wiley publisher, April 1999. [FSPWeb] Finite State Process (FSP). On-line at: http://wwwdse.doc.ic.ac.uk/~jnm/book/ltsa/Appendix-A.html.
[Rapide] D. C. Luckham, J. J. Kenney, L. M. Augustin, J. Vera, D. Bryan and W. Mann. Specification and Analysis of System Architecture Using Rapide. IEEE Trans. on Software Engineering}, Special Issue on Software Architecture, 21 (4):336-355, April 1995. [RapideWeb] Rapide. The Stanford Rapide Project. On-line at: http://pavg.stanford.edu/rapide/.
73/43
73/53
73/63
)edoC dna AS( elpmaxE laivirt A
Traceability
SA 2
ClientA
Code
XClient
ServerMaster Recovery
ClientA
ClientB
ClientB ClientC
Server Slave
ClientC
Class Client -----------------------
Simulated before Coding
Analysis and Testing
)1( secnerefeR emoS
yrammuS
12
73/73
)2( secnerefeR emoS
[Cham] P. Inverardi and A.L. Wolf. Formal Specifications and Analysis of Software Architectures Using the Chemical Abstract Machine Model. IEEE Trans. on Software Engineering, 21, 4 (April 1995), pp. 100-114. [ChamSA] P. Inverardi and D. Yankelevich. Relating CHAM Descirptions of Software Architectures. In Proc. IWSSD eight, Germany, 1996. [AcmeWeb] http://www-2.cs.cmu.edu/~acme/ Papers on ADL and SA-base analysis: [ADL_Neno97] N. Medvidovic and R.N. Taylor. A Framework for Classifying and Comparing Architecture Description Languages. In Proc. ESEC/FSE'97, LNCS vol1301, Spet 1997. [GarlanPerry95] D. Garlan and D. Perry.Introduction to the special issue on software architecture. IEEE Trans. on Software Engineering, 21(4), April 1995. [Muccini02] H. Muccini. Software Architecture for Testing, Coordination Models and Views Model Checking, PhD thesis, year 2002.
13