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