Tw Cook 1 -512 -338 -3522 tw mcc com

Tw Cook +1 -512 -338 -3522 tw@mcc. com Architecture Definition ADLs Architecture vs. Design ADLs Considered ACME Rapide Wright Aesop Unicon UML Approaches Conclusion Architecture Descriptio Languages: An Overview

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 Microelectronics and Computer Technology Corporation 2 2 -Jul-99

Architecture Description Languages n n Microelectronics and Computer Technology Corporation 3 2 -Jul-99 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 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

Architecture vs. Design Architecture: where non-functional decisions are cast, and functional requirements are partitioned Design: where functional requirements are accomplished non-functional requirements (“ilities”) functional requirements (domains) Microelectronics and Computer Technology Corporation 4 2 -Jul-99 architecture (ADL) design (UML) 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

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

Common Concept of Architecture: Object Connection Architecture n n Connections represented by interfaces together with ca graph n 6 2 -Jul-99 Interfaces specify the features that must be provided by modules conforming to an interface n Microelectronics and Computer Technology Corporation Configuration consists of the interfaces and connection of an object-oriented system 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

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

Object Connection Architecture n n Microelectronics and Computer Technology Corporation 8 2 -Jul-99 The good news u Mature development languages - C++, Ada, Java u Visual modeling and automatic code generation tools u Standardized modeling language - UML 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!

Another Concept of Architecture: Interface Connection Architecture n n Microelectronics and Computer Technology Corporation 9 2 -Jul-99 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 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

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

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

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

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

ACME n n n Microelectronics and Computer Technology Corporation 14 2 -Jul-99 ACME was developed jointly by Monroe, Garlan (CMU) and Wile (USC) ACME is a general purpose ADL originally designed to be a lowest common denominator interchange language ACME as a language is extremely simple (befitting its origin as an interchange language) 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 ACME has no native generation capability ACME has seen some native tool development, and ther are indications of more, as well as use of other language tools via interchange

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} } rpc client server caller send-request Microelectronics and Computer Technology Corporation 15 2 -Jul-99 callee receive-request

Rapide n n n Microelectronics and Computer Technology Corporation 16 2 -Jul-99 n Rapide was developed by Dr. David Luckham at Stanford Rapide is a general purpose ADL designed with an emphasis on simulation yielding partially ordered sets o events (posets) Rapide as a language is fairly sophisticated, including data types and operations 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 Rapide has some generation capability since Rapide specifications are executable Rapide has a fairly extensive toolset

The Rapide Model n 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 17 2 -Jul-99 Defines and simulates behavior of distributed object system architectures n Microelectronics and Computer Technology Corporation Rapide is a concurrent, object-oriented , event-based simulation language Posets enable visualization and analysis of an execution

The Rapide Model (cont’d) n 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 18 2 -Jul-99 Components both observe and generate events u Each event represents the occurrence of an activity n Microelectronics and Computer Technology Corporation Components execute independently 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

Rapide Architectural Elements Components components Architecture connections constraints Components interface Component architecture interface module Microelectronics and Computer Technology Corporation 19 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 l Microelectronics and Computer Technology Corporation 20 2 -Jul-99 l Basic connections (A to B) Pipe connections (A => B) Agent connections (A ||> B)

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 l Filter creates context Constraint body constrains computation in context n n Microelectronics and Computer Technology Corporation 21 2 -Jul-99 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 Configuration u The architecture itself u Supports hierarchical decomposition (I. e nested architectures) u Contains components, connections, and constraints

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

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

A Simple Specification in Rapide type Producer (Max : Positive) is interface action out Send (N: Integer); action in Reply(N : Integer); behavior Start => send(0); (? 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); behavior (? X in Integer) Receive(? X) => Ack(? X); end Consumer Microelectronics and Computer Technology Corporation 24 2 -Jul-99 architecture Prod. Con() return Some. Type is Prod : Producer(100); Cons : Consumer; connect (? n in Integer) Prod. Send(? n) => Cons. Receive(? n); Cons. Ack(? n) => Prod. Reply(? n); end architecture Prod. Con;

Wright n n Wright was developed by Dr. David Garlan at CMU 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 n n Microelectronics and Computer Technology Corporation 25 2 -Jul-99 CSP - Communicating Sequential Processes - process algebra developed by C. A. R. Hoare Wright as a language focuses primarily on the basic component/connector/system paradigm u Wright is very similar syntactically to ACME and Aesop 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 Wright does not currently have a generation capability Wright has minimal native tool support (but CSP tools could be used)

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 Instances 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 26 2 -Jul-99

Aesop n n n Microelectronics and Computer Technology Corporation 27 2 -Jul-99 Aesop was developed by Dr. David Garlan at CMU Aesop is a general purpose ADL emphasizing architectural styles u Aesop is also a toolset and a framework Aesop the ADL is very similar to ACME/Wright u Emphasis on styles reflected in more sophisticated hierarchical facilities centered around subtyping and inheritance 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 Aesop does have limited generation capability for some styles Interchange facilities to and from Aesop via ACME exist and have been used to make Aesop editing tools available to other ADLs, notably Wright

Unicon n n Microelectronics and Computer Technology Corporation 28 2 -Jul-99 Unicon was developed by Dr. Mary Shaw at CMU 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 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 Unicon has a generation capability

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

UML as an ADL n n Microelectronics and Computer Technology Corporation 30 2 -Jul-99 The Positive u lowers entry barrier, mainstreams modeling, tools 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

Approaches to Architecture Academic Approach n focus on analytic evaluation MCC’s role of architectural models n Industrial Approach individual models n rigorous modeling notations powerful analysis techniques n n Microelectronics and Computer Technology Corporation 31 2 -Jul-99 depth over breadth special-purpose solutions 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 n n general-purpose solutions Source: N. Medvidovic, USC

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

For More Information n n n n Microelectronics and Computer Technology Corporation 33 2 -Jul-99 ACME: http: // www. cs. cmu. edu /~acme Rapide http: // : pavg. stanford. edu/rapide / Wright: http: // www. cs. cmu. edu/afs/cs/project/able/www/wright/in dex. html Aesop: http: //www. cs. cmu. edu/afs/cs/project/able/www/aesop/aes op_home. html Unicon: http: //www. cs. cmu. edu/afs/cs/project/vit/www/unicon/ind ex. html C 2 SADL: http: // www. ics. uci. edu /pub/arch/ SSEP: http: //www. mcc. com/projects/ssepp 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