Architecture Description Languages: An Overview

  • 762 views
Uploaded on

 

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
762
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
37
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Tw Cook Tw Cook +1-512-338-3522 +1-512-338-3522 tw@mcc.com tw@mcc.com Architecture Definition ADLs Architecture vs. Design ADLs Considered u ACME u Rapide u Wright u Aesop u Unicon u UML Approaches Conclusion Architecture Description Languages: An Overview © 1999 Microelectronics and Computer Technology Corporation – All Rights Reserved
  • 2. 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 2 21-Oct-99
  • 3. 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 3 21-Oct-99
  • 4. Architecture vs. Design Architecture: where non-functional decisions are cast, and functional requirements are partitioned Design: where functional requirements are accomplished non-functional architecture requirements (ADL) (“ilities”) functional requirements design (domains) (UML) 4 Heuristic: it is necessary to go one level deeper to validate choices, so the 21-Oct-99 architect has to do a high-level design to validate the partitioning
  • 5. Quality Attributes and Architectural Strategies n Dependability n Assurance monitoring & control n Interoperability n Layering n Diagnostics n Usability n Pipelining n Architecture balance n Performance n Parallelism Positive Positive Effects n GUI-driven Effects n Adaptability n API-driven n Performance monitoring & control n Cost n Change-source hiding Negative Negative n COTS/reuse-driven n Schedule Effects Effects 5 21-Oct-99
  • 6. 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 6 21-Oct-99
  • 7. An Object Connection Architecture 7 21-Oct-99
  • 8. 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! u “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.” 8 21-Oct-99
  • 9. 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 9 21-Oct-99
  • 10. An Interface Connection Architecture provides requires connection interface module 10 21-Oct-99
  • 11. 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. 11 21-Oct-99
  • 12. 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 12 21-Oct-99
  • 13. 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 13 21-Oct-99
  • 14. ACME 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 14 21-Oct-99
  • 15. An ADL Example (in ACME) System simple_cs = { System simple_cs = { Component client = {Port send-request} Component client = {Port send-request} Component server = {Port receive-request} Component server = {Port receive-request} Connector rpc = {Roles {caller, callee}} Connector rpc = {Roles {caller, callee}} Attachments : {client.send-request to rpc.caller; Attachments : {client.send-request to rpc.caller; server.receive-request to rpc.callee} server.receive-request to rpc.callee} } } rpc client server caller callee send-request receive-request 15 21-Oct-99
  • 16. Rapide 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 16 21-Oct-99
  • 17. 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 17 21-Oct-99
  • 18. 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 18 21-Oct-99
  • 19. Rapide Architectural Elements Components components Architecture connections constraints Components interface interface Component architecture interface module 19 21-Oct-99
  • 20. 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: • Basic connections (A to B) • Pipe connections (A => B) • Agent connections (A ||> B) 20 21-Oct-99
  • 21. 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 • Filter creates context • 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) 21 u Contains components, connections, and constraints 21-Oct-99
  • 22. Architectural Elements (cont’d) Components provides part functions objects requires part types Components in actions action part out actions Interface service part state Components behavior part state transitions constraint part pattern constraints Components private part interface with no private part 22 21-Oct-99
  • 23. Architectural Elements (cont’d) Components components connections Components initial part statements processes Module Components final part statements constraints Components handlers domain range Map Components rule part state transitions constraints 23 21-Oct-99
  • 24. A Simple Specification in Rapide type Producer (Max : Positive) is interface type Producer (Max : Positive) is interface action out Send (N: Integer); action out Send (N: Integer); action in Reply(N : Integer); action in Reply(N : Integer); behavior behavior Start => send(0); Start => send(0); (?X in Integer) Reply(?X) where ?X<Max => Send(?X+1); (?X in Integer) Reply(?X) where ?X<Max => Send(?X+1); end Producer; end Producer; type Consumer is interface type Consumer is interface action in Receive(N: Integer); action in Receive(N: Integer); action out Ack(N : Integer); action out Ack(N : Integer); Ack(N behavior behavior (?X in Integer) Receive(?X) => Ack(?X); (?X in Integer) Receive(?X) => Ack(?X); Ack(?X); end Consumer end Consumer architecture ProdCon() return SomeType is architecture ProdCon() return SomeType is ProdCon() Prod : Producer(100); Cons : Consumer; Prod : Producer(100); Cons : Consumer; connect connect (?n in Integer) Prod.Send(?n) => Cons.Receive(?n); (?n in Integer) Prod.Send(?n) => Cons.Receive(?n); Cons.Ack(?n) => Prod.Reply(?n); Cons.Ack(?n) => Prod.Reply(?n); Cons.Ack(?n) end architecture ProdCon; end architecture ProdCon; ProdCon; 24 21-Oct-99
  • 25. Wright 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 • 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) 25 21-Oct-99
  • 26. A Simple Specification in Wright System simple_cs System simple_cs Component client = Component client = port send-request = [behavioral spec] port send- send-request = [behavioral spec] spec = [behavioral spec] spec = [behavioral spec] Component server = Component server = port receive-request= [behavioral spec] port receive- receive-request= [behavioral spec] spec = [behavioral spec] spec = [behavioral spec] Connector rpc = Connector rpc = role caller = (request!x -> result?x ->caller) role caller = (request!x -> result?x ->caller) ^ ^ STOP STOP role callee = (invoke?x -> return!x -> callee) role callee = (invoke?x -> return!x -> callee) [] [] STOP STOP glue = (caller.request?x -> callee.invoke!x glue = (caller.request?x -> callee.invoke!x -> callee.return?x -> callee.result!x -> callee.return?x -> callee.result!x -> glue) [] STOP -> glue) [] STOP Instances Instances s : server s : server c : client c : client r : rpc r : rpc Attachments : Attachments : client.send-request as rpc.caller client.send- client.send-request as rpc.caller server.receive-request as rpc.callee server.receive- server.receive-request as rpc.callee end simple_cs. end simple_cs. 26 21-Oct-99
  • 27. Aesop 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 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 27 21-Oct-99
  • 28. Unicon 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 28 21-Oct-99
  • 29. 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 29 21-Oct-99
  • 30. UML as an ADL n The Positive u lowers entry barrier, mainstreams modeling, tools n Shortcomings of UML as an ADL u Encourages an object connection architecture rather than interface connection architecture 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 30 21-Oct-99
  • 31. Approaches to Architecture Academic Approach Industrial Approach MCC’s role MCC’s role n focus on analytic evaluation of n focus on wide range of architectural models development issues n individual models n families of models n rigorous modeling notations n practicality over rigor n powerful analysis techniques n architecture as the “big picture” in development n depth over breadth n breadth over depth n special-purpose solutions n general-purpose solutions 31 Source: N. Medvidovic, USC Source: N. Medvidovic, USC 21-Oct-99
  • 32. Approaches to Architecture Academic Approach Industrial Approach MCC’s role MCC’s role focus on analytic evaluation of focus on wide range of architectural models development issues individual models families of models rigorous modeling notations practicality over rigor powerful analysis techniques architecture as the “big picture” in development depth over breadth breadth over depth special-purpose solutions general-purpose solutions 32 Source: N. Medvidovic, USC Source: N. Medvidovic, USC 21-Oct-99
  • 33. Conclusions 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 33 21-Oct-99
  • 34. For More Information n ACME: http://www.cs.cmu.edu/~acme n Rapide: http://pavg.stanford.edu/rapide/ n Wright: http://www.cs.cmu.edu/afs/cs/project/able/www/wright/index.html n Aesop: http://www.cs.cmu.edu/afs/cs/project/able/www/aesop/aesop_home.html n Unicon: http://www.cs.cmu.edu/afs/cs/project/vit/www/unicon/index.html n C2 SADL: http://www.ics.uci.edu/pub/arch/ n SSEP: http://www.mcc.com/projects/ssepp n ADML: http://www.mcc.com/projects/ssepp/adml A possibly more current version of this presentation can be found at: http://www.mcc.com/projects/ssepp/adml/tog 34 21-Oct-99