Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs Considered ACME Rapide Wright Aesop Unicon UML Approaches Conclusion Architecture Definition ADLs Architecture vs. Design ADLs Considered ACME Rapide Wright Aesop Unicon UML Approaches Conclusion Tw Cook Tw Cook

Microelectronics and Computer Technology Corporation 2 2-Jul-99 Architecture – A Definition n “The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.” – from Software Architecture in Practice, Bass, Clements, and Kazman n “The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.” – from Software Architecture in Practice, Bass, Clements, and Kazman

Microelectronics and Computer Technology Corporation 3 2-Jul-99 Architecture Description Languages n The positives u ADLs represent a formal way of representing architecture u ADLs are intended to be both human and machine readable u ADLs support describing a system at a higher level than previously possible u ADLs permit analysis of architectures – completeness, consistency, ambiguity, and performance u ADLs can support automatic generation of software systems n The negatives u There is not universal agreement on what ADLs should represent, particularly as regards the behavior of the architecture u Representations currently in use are relatively difficult to parse and are not supported by commercial tools u Most ADL work today has been undertaken with academic rather than commercial goals in mind u Most ADLs tend to be very vertically optimized toward a particular kind of analysis n The positives u ADLs represent a formal way of representing architecture u ADLs are intended to be both human and machine readable u ADLs support describing a system at a higher level than previously possible u ADLs permit analysis of architectures – completeness, consistency, ambiguity, and performance u ADLs can support automatic generation of software systems n The negatives u There is not universal agreement on what ADLs should represent, particularly as regards the behavior of the architecture u Representations currently in use are relatively difficult to parse and are not supported by commercial tools u Most ADL work today has been undertaken with academic rather than commercial goals in mind u Most ADLs tend to be very vertically optimized toward a particular kind of analysis

Microelectronics and Computer Technology Corporation 4 2-Jul-99 Architecture vs. Design non-functional requirements (“ilities”) functional requirements (domains) Heuristic: it is necessary to go one level deeper to validate choices, so the architect has to do a high-level design to validate the partitioning Architecture: where non-functional decisions are cast, and functional requirements are partitioned Design: where functional requirements are accomplished architecture (ADL) design (UML)

Microelectronics and Computer Technology Corporation 5 2-Jul-99 Positive Effects Negative Effects Quality Attributes and Architectural Strategies n Dependability n Interoperability n Usability n Performance n Adaptability n Cost n Schedule n Dependability n Interoperability n Usability n Performance n Adaptability n Cost n Schedule n Assurance monitoring & control n Layering n Diagnostics n Pipelining n Architecture balance n Parallelism n GUI-driven n API-driven n Performance monitoring & control n Change-source hiding n COTS/reuse-driven

Microelectronics and Computer Technology Corporation 6 2-Jul-99 Common Concept of Architecture: Object Connection Architecture n Configuration consists of the interfaces and connections of an object-oriented system n Interfaces specify the features that must be provided by modules conforming to an interface n Connections represented by interfaces together with call graph n Conformance usually enforced by the programming language u decomposition - associating interfaces with unique modules u Interface conformance - static checking of syntactic rules u communication integrity - visibility between modules n Configuration consists of the interfaces and connections of an object-oriented system n Interfaces specify the features that must be provided by modules conforming to an interface n Connections represented by interfaces together with call graph n Conformance usually enforced by the programming language u decomposition - associating interfaces with unique modules u Interface conformance - static checking of syntactic rules u communication integrity - visibility between modules

Microelectronics and Computer Technology Corporation 7 2-Jul-99 An Object Connection Architecture

Microelectronics and Computer Technology Corporation 8 2-Jul-99 Object Connection Architecture n The good news u Mature development languages - C++, Ada, Java u Visual modeling and automatic code generation tools u Standardized modeling language - UML n The bad news u Modules must be built before the architecture is defined u Architecture not invariant under changes to system u Conformance of a system to an architecture is minimal u Can not be used to plan a system n Really not an architecture at all! n The good news u Mature development languages - C++, Ada, Java u Visual modeling and automatic code generation tools u Standardized modeling language - UML n The bad news u Modules must be built before the architecture is defined u Architecture not invariant under changes to system u Conformance of a system to an architecture is minimal u Can not be used to plan a system n Really not an architecture at all!

Microelectronics and Computer Technology Corporation 9 2-Jul-99 Another Concept of Architecture: Interface Connection Architecture n Expands the role of interfaces and connections u Interfaces specify both “required” and “provided” features u Connections are defined between “required” features and “provided” features n Consists of interfaces, connections and constraints u Constraints restrict behavior of interfaces and connections in an architecture u Constraints in an architecture map to requirements for a system n Expands the role of interfaces and connections u Interfaces specify both “required” and “provided” features u Connections are defined between “required” features and “provided” features n Consists of interfaces, connections and constraints u Constraints restrict behavior of interfaces and connections in an architecture u Constraints in an architecture map to requirements for a system

Microelectronics and Computer Technology Corporation 10 2-Jul-99 An Interface Connection Architecture module interface connection provides requires

Microelectronics and Computer Technology Corporation 11 2-Jul-99 Interface Connection Architecture n The Good news u Improved conformance of a system to an architecture u Architecture can be built before modules are implemented n The bad news u No emerging standard u Poor quality tools n Most ADLs implement an interface connection architecture. n The Good news u Improved conformance of a system to an architecture u Architecture can be built before modules are implemented n The bad news u No emerging standard u Poor quality tools n Most ADLs implement an interface connection architecture.

Microelectronics and Computer Technology Corporation 12 2-Jul-99 Software Architecture: ADL Perspective n The ADL community generally agrees that Software Architecture is a set of components and the connections among them. u components u connectors u configurations u constraints n The ADL community generally agrees that Software Architecture is a set of components and the connections among them. u components u connectors u configurations u constraints

Microelectronics and Computer Technology Corporation 13 2-Jul-99 ADLs Considered by MCC n Leading candidates u ACME (CMU/USC) u Rapide (Stanford) u Wright (CMU) u Unicon (CMU) n Secondary candidates u Aesop (CMU) u MetaH (Honeywell) u C2 SADL (UCI) u SADL (SRI) n Others u Lileanna u UML u Modechart n Leading candidates u ACME (CMU/USC) u Rapide (Stanford) u Wright (CMU) u Unicon (CMU) n Secondary candidates u Aesop (CMU) u MetaH (Honeywell) u C2 SADL (UCI) u SADL (SRI) n Others u Lileanna u UML u Modechart

Microelectronics and Computer Technology Corporation 14 2-Jul-99 ACMEACME n ACME was developed jointly by Monroe, Garlan (CMU) and Wile (USC) n ACME is a general purpose ADL originally designed to be a lowest common denominator interchange language n ACME as a language is extremely simple (befitting its origin as an interchange language) n ACME has no native behavioral specification facility so only syntactic linguistic analysis is possible u there are currently efforts under consideration to define a behavioral semantics for ACME, possibly along the Wright/CSP line n ACME has no native generation capability n ACME has seen some native tool development, and there are indications of more, as well as use of other language tools via interchange n ACME was developed jointly by Monroe, Garlan (CMU) and Wile (USC) n ACME is a general purpose ADL originally designed to be a lowest common denominator interchange language n ACME as a language is extremely simple (befitting its origin as an interchange language) n ACME has no native behavioral specification facility so only syntactic linguistic analysis is possible u there are currently efforts under consideration to define a behavioral semantics for ACME, possibly along the Wright/CSP line n ACME has no native generation capability n ACME has seen some native tool development, and there are indications of more, as well as use of other language tools via interchange

Microelectronics and Computer Technology Corporation 15 2-Jul-99 An ADL Example (in ACME) System simple_cs = { Component client = {Port send-request} Component server = {Port receive-request} Connector rpc = {Roles {caller, callee}} Attachments : {client.send-request to rpc.caller; server.receive-request to rpc.callee} server.receive-request to rpc.callee}} System simple_cs = { Component client = {Port send-request} Component server = {Port receive-request} Connector rpc = {Roles {caller, callee}} Attachments : {client.send-request to rpc.caller; server.receive-request to rpc.callee} server.receive-request to rpc.callee}} client send-request server receive-request callercallee rpc

Microelectronics and Computer Technology Corporation 16 2-Jul-99 RapideRapide n Rapide was developed by Dr. David Luckham at Stanford n Rapide is a general purpose ADL designed with an emphasis on simulation yielding partially ordered sets of events (posets) n Rapide as a language is fairly sophisticated, including data types and operations n Rapide analysis tools focus on posets u matching simulation results against patterns of allowed/prohibited behaviors u some support for timing analysis u focus on causality n Rapide has some generation capability since Rapide specifications are executable n Rapide has a fairly extensive toolset n Rapide was developed by Dr. David Luckham at Stanford n Rapide is a general purpose ADL designed with an emphasis on simulation yielding partially ordered sets of events (posets) n Rapide as a language is fairly sophisticated, including data types and operations n Rapide analysis tools focus on posets u matching simulation results against patterns of allowed/prohibited behaviors u some support for timing analysis u focus on causality n Rapide has some generation capability since Rapide specifications are executable n Rapide has a fairly extensive toolset

Microelectronics and Computer Technology Corporation 17 2-Jul-99 The Rapide Model n Rapide is a concurrent, object-oriented, event-based simulation language n Defines and simulates behavior of distributed object system architectures n Produces a simulation represented by a set of events (poset) u Events are ordered with respect to time and causality n System requirements are expressed as constraints on time and concurrent patterns of events n Posets enable visualization and analysis of an execution n Rapide is a concurrent, object-oriented, event-based simulation language n Defines and simulates behavior of distributed object system architectures n Produces a simulation represented by a set of events (poset) u Events are ordered with respect to time and causality n System requirements are expressed as constraints on time and concurrent patterns of events n Posets enable visualization and analysis of an execution

Microelectronics and Computer Technology Corporation 18 2-Jul-99 The Rapide Model (cont’d) n Components execute independently n Components both observe and generate events u Each event represents the occurrence of an activity n Generates dependent events u Reactive rules in interface behaviors (i.e. transition rules) u Reactive processes in modules (i.e. when statements) u Events generated by sequential execution u Shared objects via references n Generates timed events u Interface behavior or module can be timed u Events receive start and finish times within scope of its clock u Events can be synchronized to a clock n Components execute independently n Components both observe and generate events u Each event represents the occurrence of an activity n Generates dependent events u Reactive rules in interface behaviors (i.e. transition rules) u Reactive processes in modules (i.e. when statements) u Events generated by sequential execution u Shared objects via references n Generates timed events u Interface behavior or module can be timed u Events receive start and finish times within scope of its clock u Events can be synchronized to a clock

Microelectronics and Computer Technology Corporation 19 2-Jul-99 Rapide Architectural Elements Componentscomponents connections constraints Componentsinterface architecture interface module Architecture Component

Microelectronics and Computer Technology Corporation 20 2-Jul-99 Rapide Architectural Elements (cont’d) n Components u Interface objects u Architecture that implements an interface u Module that implements an interface n Connections u Connects “sending interfaces” to “receiving interfaces” u Components communicate through connections by calling actions or functions in its own interface u Events generated by components trigger event pattern connections between their interfaces u Three types of connections: l Basic connections (A to B) l Pipe connections (A => B) l Agent connections (A ||> B) n Components u Interface objects u Architecture that implements an interface u Module that implements an interface n Connections u Connects “sending interfaces” to “receiving interfaces” u Components communicate through connections by calling actions or functions in its own interface u Events generated by components trigger event pattern connections between their interfaces u Three types of connections: l Basic connections (A to B) l Pipe connections (A => B) l Agent connections (A ||> B)

Microelectronics and Computer Technology Corporation 21 2-Jul-99 Architectural Elements (cont’d) n Constraints - Pattern u Bound execution in terms of event patterns u Appear in an interface and/or architecture definition u [label] filter_part constraint_body l Filter creates context l Constraint body constrains computation in context n Constraints - Sequential u Bound execution in terms of boolean expressions u Normally appear in module level behavior u Applied to parameters, types, objects and statements n Configuration u The architecture itself u Supports hierarchical decomposition (I.e nested architectures) u Contains components, connections, and constraints n Constraints - Pattern u Bound execution in terms of event patterns u Appear in an interface and/or architecture definition u [label] filter_part constraint_body l Filter creates context l Constraint body constrains computation in context n Constraints - Sequential u Bound execution in terms of boolean expressions u Normally appear in module level behavior u Applied to parameters, types, objects and statements n Configuration u The architecture itself u Supports hierarchical decomposition (I.e nested architectures) u Contains components, connections, and constraints

Microelectronics and Computer Technology Corporation 22 2-Jul-99 Architectural Elements (cont’d) Components provides part functions objects types in actions out actions state state transitions pattern constraints interface with no private part requires part Components action part service part Components behavior part constraint part Components private part Interface

Microelectronics and Computer Technology Corporation 23 2-Jul-99 Architectural Elements (cont’d) Components components statements Module statements connections Components initial part processes state transitions Components rule part constraints Map range domain Components final part constraints Components handlers

Microelectronics and Computer Technology Corporation 24 2-Jul-99 A Simple Specification in Rapide type Producer (Max : Positive) is interface action out Send (N: Integer); action in Reply(N : Integer); action out Send (N: Integer); action in Reply(N : Integer);behavior Start => send(0); Start => send(0); (?X in Integer) Reply(?X) where ?X Send(?X+1); (?X in Integer) Reply(?X) where ?X Send(?X+1); end Producer; type Consumer is interface action in Receive(N: Integer); action out Ack(N : Integer); action in Receive(N: Integer); action out Ack(N : Integer);behavior (?X in Integer) Receive(?X) => Ack(?X); (?X in Integer) Receive(?X) => Ack(?X); end Consumer architecture ProdCon() return SomeType is Prod : Producer(100); Cons : Consumer; Prod : Producer(100); Cons : Consumer;connect (?n in Integer) Prod.Send(?n) => Cons.Receive(?n); Cons.Ack(?n) => Prod.Reply(?n); (?n in Integer) Prod.Send(?n) => Cons.Receive(?n); Cons.Ack(?n) => Prod.Reply(?n); end architecture ProdCon; type Producer (Max : Positive) is interface action out Send (N: Integer); action in Reply(N : Integer); action out Send (N: Integer); action in Reply(N : Integer);behavior Start => send(0); Start => send(0); (?X in Integer) Reply(?X) where ?X Send(?X+1); (?X in Integer) Reply(?X) where ?X Send(?X+1); end Producer; type Consumer is interface action in Receive(N: Integer); action out Ack(N : Integer); action in Receive(N: Integer); action out Ack(N : Integer);behavior (?X in Integer) Receive(?X) => Ack(?X); (?X in Integer) Receive(?X) => Ack(?X); end Consumer architecture ProdCon() return SomeType is Prod : Producer(100); Cons : Consumer; Prod : Producer(100); Cons : Consumer;connect (?n in Integer) Prod.Send(?n) => Cons.Receive(?n); Cons.Ack(?n) => Prod.Reply(?n); (?n in Integer) Prod.Send(?n) => Cons.Receive(?n); Cons.Ack(?n) => Prod.Reply(?n); end architecture ProdCon;

Microelectronics and Computer Technology Corporation 25 2-Jul-99 WrightWright n Wright was developed by Dr. David Garlan at CMU n Wright is a general purpose ADL designed with an emphasis on analysis of communication protocols u Wright uses a variation of CSP to specify the behaviors of components, connectors, and systems l CSP - Communicating Sequential Processes - process algebra developed by C. A. R. Hoare n Wright as a language focuses primarily on the basic component/connector/system paradigm u Wright is very similar syntactically to ACME and Aesop n Wright analysis focuses on analyzing the CSP behavior specifications. u Any CSP analysis tool or technique could be used to analyze the behavior of a Wright specification n Wright does not currently have a generation capability n Wright has minimal native tool support (but CSP tools could be used) n Wright was developed by Dr. David Garlan at CMU n Wright is a general purpose ADL designed with an emphasis on analysis of communication protocols u Wright uses a variation of CSP to specify the behaviors of components, connectors, and systems l CSP - Communicating Sequential Processes - process algebra developed by C. A. R. Hoare n Wright as a language focuses primarily on the basic component/connector/system paradigm u Wright is very similar syntactically to ACME and Aesop n Wright analysis focuses on analyzing the CSP behavior specifications. u Any CSP analysis tool or technique could be used to analyze the behavior of a Wright specification n Wright does not currently have a generation capability n Wright has minimal native tool support (but CSP tools could be used)

Microelectronics and Computer Technology Corporation 26 2-Jul-99 A Simple Specification in Wright System simple_cs Component client = port send-request = [behavioral spec] spec = [behavioral spec] Component server = port receive-request= [behavioral spec] spec = [behavioral spec] Connector rpc = role caller = (request!x -> result?x ->caller) ^ STOP role callee = (invoke?x -> return!x -> callee) [] STOP glue = (caller.request?x -> callee.invoke!x -> callee.return?x -> callee.result!x -> glue) [] STOP -> glue) [] STOPInstances s : server c : client r : rpc Attachments : client.send-request as rpc.caller server.receive-request as rpc.callee end simple_cs. System simple_cs Component client = port send-request = [behavioral spec] spec = [behavioral spec] Component server = port receive-request= [behavioral spec] spec = [behavioral spec] Connector rpc = role caller = (request!x -> result?x ->caller) ^ STOP role callee = (invoke?x -> return!x -> callee) [] STOP glue = (caller.request?x -> callee.invoke!x -> callee.return?x -> callee.result!x -> glue) [] STOP -> glue) [] STOPInstances s : server c : client r : rpc Attachments : client.send-request as rpc.caller server.receive-request as rpc.callee end simple_cs.

Microelectronics and Computer Technology Corporation 27 2-Jul-99 AesopAesop n Aesop was developed by Dr. David Garlan at CMU n Aesop is a general purpose ADL emphasizing architectural styles u Aesop is also a toolset and a framework n Aesop the ADL is very similar to ACME/Wright u Emphasis on styles reflected in more sophisticated hierarchical facilities centered around subtyping and inheritance n Wright analysis focuses on analyzing the CSP behavior specifications. u Any CSP analysis tool or technique could be used to analyze the behavior of a Wright specification n Aesop does have limited generation capability for some styles n Interchange facilities to and from Aesop via ACME exist and have been used to make Aesop editing tools available to other ADLs, notably Wright n Aesop was developed by Dr. David Garlan at CMU n Aesop is a general purpose ADL emphasizing architectural styles u Aesop is also a toolset and a framework n Aesop the ADL is very similar to ACME/Wright u Emphasis on styles reflected in more sophisticated hierarchical facilities centered around subtyping and inheritance n Wright analysis focuses on analyzing the CSP behavior specifications. u Any CSP analysis tool or technique could be used to analyze the behavior of a Wright specification n Aesop does have limited generation capability for some styles n Interchange facilities to and from Aesop via ACME exist and have been used to make Aesop editing tools available to other ADLs, notably Wright

Microelectronics and Computer Technology Corporation 28 2-Jul-99 UniconUnicon n Unicon was developed by Dr. Mary Shaw at CMU n Unicon is a general purpose ADL designed with an emphasis on generation of connectors u Unicon developed to support treatment of connectors as first class objects by providing for the generation of systems with explicit connectors n Unicon as a language focuses primarily on the basic component/connector/system paradigm but with an emphasis on architectural styles u Emphasis on styles simplifies generation efforts n Unicon has a generation capability n Unicon was developed by Dr. Mary Shaw at CMU n Unicon is a general purpose ADL designed with an emphasis on generation of connectors u Unicon developed to support treatment of connectors as first class objects by providing for the generation of systems with explicit connectors n Unicon as a language focuses primarily on the basic component/connector/system paradigm but with an emphasis on architectural styles u Emphasis on styles simplifies generation efforts n Unicon has a generation capability

Microelectronics and Computer Technology Corporation 29 2-Jul-99 Others … n MetaH u Developed by Honeywell, a domain specific ADL aimed at guidance, navigation, and control applications with ControlH u Sophisticated tool support available n C2 SADL u Developed by Taylor/Medvidovic (UCI), style specific ADL, emphasis on dynamism u Still in prototype stage n SADL u Developed by Moriconi and Riemenschneider (SRI), emphasis on refinement mappings n MetaH u Developed by Honeywell, a domain specific ADL aimed at guidance, navigation, and control applications with ControlH u Sophisticated tool support available n C2 SADL u Developed by Taylor/Medvidovic (UCI), style specific ADL, emphasis on dynamism u Still in prototype stage n SADL u Developed by Moriconi and Riemenschneider (SRI), emphasis on refinement mappings

Microelectronics and Computer Technology Corporation 30 2-Jul-99 UML as an ADL n The Positive u lowers entry barrier, mainstreams modeling, tools n Shortcomings of UML as an ADL u Weakly integrated models with inadequate semantics for (automated) analysis u Connectors are not first class objects u Visual notation with little generation support, hidden and ambiguous relationships between views, both too much and too little n The Positive u lowers entry barrier, mainstreams modeling, tools n Shortcomings of UML as an ADL u Weakly integrated models with inadequate semantics for (automated) analysis u Connectors are not first class objects u Visual notation with little generation support, hidden and ambiguous relationships between views, both too much and too little

Microelectronics and Computer Technology Corporation 31 2-Jul-99 Approaches to Architecture Academic Approach n focus on analytic evaluation of architectural models n individual models n rigorous modeling notations n powerful analysis techniques n depth over breadth n special-purpose solutions Academic Approach n focus on analytic evaluation of architectural models n individual models n rigorous modeling notations n powerful analysis techniques n depth over breadth n special-purpose solutions Industrial Approach n focus on wide range of development issues n families of models n practicality over rigor n architecture as the “big picture” in development n breadth over depth n general-purpose solutions Source: N. Medvidovic, USC MCC’s role

Microelectronics and Computer Technology Corporation 32 2-Jul-99 ConclusionsConclusions n There is a rich body of research to draw upon n Much has been learned about representing and analyzing architectures n Effort is needed now to bring together the common knowledge and put it into practice n There is a rich body of research to draw upon n Much has been learned about representing and analyzing architectures n Effort is needed now to bring together the common knowledge and put it into practice

Microelectronics and Computer Technology Corporation 33 2-Jul-99 For More Information n ACME: n ACME: n Rapide: n Rapide: n Wright: n Wright: index.html index.html n Aesop: n Aesop: aesop_home.html aesop_home.html n Unicon: n Unicon: ndex.html ndex.html n C2 SADL: n C2 SADL: n SSEP: n SSEP: n ADML: n ADML: A possibly more current version of this presentation can be found at: A possibly more current version of this presentation can be found at: n ACME: n ACME: n Rapide: n Rapide: n Wright: n Wright: index.html index.html n Aesop: n Aesop: aesop_home.html aesop_home.html n Unicon: n Unicon: ndex.html ndex.html n C2 SADL: n C2 SADL: n SSEP: n SSEP: n ADML: n ADML: A possibly more current version of this presentation can be found at: A possibly more current version of this presentation can be found at: