Transcript Architecture Description Languages: An Overview

Tw Cook
+1-512-338-3522
[email protected]
Architecture
Definition
ADLs
Architecture vs.
Design
ADLs Considered
ACME
Rapide
Wright
Aesop
Unicon
UML
Approaches
Conclusion
Architecture Description
Languages: An Overview
Architecture – A Definition

“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


Microelectronics
and Computer
Technology
Corporation
3 2-Jul-99
The positives
 ADLs represent a formal way of representing architecture
 ADLs are intended to be both human and machine
readable
 ADLs support describing a system at a higher level than
previously possible
 ADLs permit analysis of architectures – completeness,
consistency, ambiguity, and performance
 ADLs can support automatic generation of software
systems
The negatives
 There is not universal agreement on what ADLs should
represent, particularly as regards the behavior of the
architecture
 Representations currently in use are relatively difficult to
parse and are not supported by commercial tools
 Most ADL work today has been undertaken with academic
rather than commercial goals in mind
 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

Dependability


Interoperability



Usability




Performance
Positive
Effects
Adaptability






Microelectronics
and Computer
Technology
Corporation
5 2-Jul-99
Cost
Schedule
Negative
Effects


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
Microelectronics
and Computer
Technology
Corporation
6 2-Jul-99

Configuration consists of the interfaces and
connections of an object-oriented system

Interfaces specify the features that must be
provided by modules conforming to an interface

Connections represented by interfaces together with
call graph

Conformance usually enforced by the programming
language
 decomposition - associating interfaces with unique
modules
 Interface conformance - static checking of syntactic
rules
 communication integrity - visibility between modules
An Object Connection Architecture
Microelectronics
and Computer
Technology
Corporation
7 2-Jul-99
Object Connection Architecture
Microelectronics
and Computer
Technology
Corporation
8 2-Jul-99

The good news
 Mature development languages - C++, Ada, Java
 Visual modeling and automatic code generation tools
 Standardized modeling language - UML

The bad news
 Modules must be built before the architecture is
defined
 Architecture not invariant under changes to system
 Conformance of a system to an architecture is
minimal
 Can not be used to plan a system

Really not an architecture at all!
Another Concept of Architecture:
Interface Connection Architecture
Microelectronics
and Computer
Technology
Corporation
9 2-Jul-99

Expands the role of interfaces and connections
 Interfaces specify both “required” and “provided”
features
 Connections are defined between “required” features
and “provided” features

Consists of interfaces, connections and constraints
 Constraints restrict behavior of interfaces and
connections in an architecture
 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
Microelectronics
and Computer
Technology
Corporation
11 2-Jul-99

The Good news
 Improved conformance of a system to an architecture
 Architecture can be built before modules are
implemented

The bad news
 No emerging standard
 Poor quality tools

Most ADLs implement an interface connection
architecture.
Software Architecture: ADL Perspective

Microelectronics
and Computer
Technology
Corporation
12 2-Jul-99
The ADL community generally agrees that Software
Architecture is a set of components and the
connections among them.
 components
 connectors
 configurations
 constraints
ADLs Considered by MCC



Microelectronics
and Computer
Technology
Corporation
13 2-Jul-99
Leading candidates
 ACME (CMU/USC)
 Rapide (Stanford)
 Wright (CMU)
 Unicon (CMU)
Secondary candidates
 Aesop (CMU)
 MetaH (Honeywell)
 C2 SADL (UCI)
 SADL (SRI)
Others
 Lileanna
 UML
 Modechart
ACME






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
 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
there 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





Microelectronics
and Computer
Technology
Corporation
16 2-Jul-99

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 of events (posets)
Rapide as a language is fairly sophisticated,
including data types and operations
Rapide analysis tools focus on posets
 matching simulation results against patterns of
allowed/prohibited behaviors
 some support for timing analysis
 focus on causality
Rapide has some generation capability since Rapide
specifications are executable
Rapide has a fairly extensive toolset
The Rapide Model
Microelectronics
and Computer
Technology
Corporation
17 2-Jul-99

Rapide is a concurrent, object-oriented , event-based
simulation language

Defines and simulates behavior of distributed object
system architectures

Produces a simulation represented by a set of events
(poset)
 Events are ordered with respect to time and
causality

System requirements are expressed as constraints
on time and concurrent patterns of events

Posets enable visualization and analysis of an
execution
The Rapide Model (cont’d)
Microelectronics
and Computer
Technology
Corporation
18 2-Jul-99

Components execute independently

Components both observe and generate events
 Each event represents the occurrence of an activity

Generates dependent events
 Reactive rules in interface behaviors (i.e. transition rules)
 Reactive processes in modules (i.e. when statements)
 Events generated by sequential execution
 Shared objects via references

Generates timed events
 Interface behavior or module can be timed
 Events receive start and finish times within scope of its
clock
 Events can be synchronized to a clock
Rapide Architectural Elements
Components
components
Architecture
connections
constraints
Components
interface
interface
Component
architecture
interface
module
Microelectronics
and Computer
Technology
Corporation
19 2-Jul-99
Rapide Architectural Elements (cont’d)

Components
 Interface objects
 Architecture that implements an interface
 Module that implements an interface

Connections
 Connects “sending interfaces” to “receiving
interfaces”
 Components communicate through connections by
calling actions or functions in its own interface
 Events generated by components trigger event
pattern connections between their interfaces
 Three types of connections:


Microelectronics
and Computer
Technology
Corporation
20 2-Jul-99

Basic connections (A to B)
Pipe connections (A => B)
Agent connections (A ||> B)
Architectural Elements (cont’d)

Constraints - Pattern
 Bound execution in terms of event patterns
 Appear in an interface and/or architecture definition
 [label] filter_part constraint_body


Microelectronics
and Computer
Technology
Corporation
21 2-Jul-99
Filter creates context
Constraint body constrains computation in context

Constraints - Sequential
 Bound execution in terms of boolean expressions
 Normally appear in module level behavior
 Applied to parameters, types, objects and statements

Configuration
 The architecture itself
 Supports hierarchical decomposition (I.e nested
architectures)
 Contains components, connections, and constraints
Architectural Elements (cont’d)
Components
provides
part
requires part
Interface
Components
action part
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
functions
objects
types
interface with no
private part
Architectural Elements (cont’d)
Components
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<Max => 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 ProdCon() return SomeType is
Prod : Producer(100); Cons : Consumer;
connect
(?n in Integer) Prod.Send(?n) => Cons.Receive(?n);
Cons.Ack(?n) => Prod.Reply(?n);
end architecture ProdCon;
Wright


Wright was developed by Dr. David Garlan at CMU
Wright is a general purpose ADL designed with an
emphasis on analysis of communication protocols
 Wright uses a variation of CSP to specify the behaviors of
components, connectors, and systems





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
 Wright is very similar syntactically to ACME and Aesop
Wright analysis focuses on analyzing the CSP behavior
specifications.
 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






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
 Aesop is also a toolset and a framework
Aesop the ADL is very similar to ACME/Wright
 Emphasis on styles reflected in more sophisticated
hierarchical facilities centered around subtyping and
inheritance
Wright analysis focuses on analyzing the CSP
behavior specifications.
 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




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
 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
 Emphasis on styles simplifies generation efforts
Unicon has a generation capability
Others …



Microelectronics
and Computer
Technology
Corporation
29 2-Jul-99
MetaH
 Developed by Honeywell, a domain specific ADL
aimed at guidance, navigation, and control
applications with ControlH
 Sophisticated tool support available
C2 SADL
 Developed by Taylor/Medvidovic (UCI), style specific
ADL, emphasis on dynamism
 Still in prototype stage
SADL
 Developed by Moriconi and Riemenschneider (SRI),
emphasis on refinement mappings
UML as an ADL


Microelectronics
and Computer
Technology
Corporation
30 2-Jul-99
The Positive
 lowers entry barrier, mainstreams modeling, tools
Shortcomings of UML as an ADL
 Weakly integrated models with inadequate semantics
for (automated) analysis
 Connectors are not first class objects
 Visual notation with little generation support,
hidden and ambiguous relationships between views,
both too much and too little
Approaches to Architecture
Academic Approach
Microelectronics
and Computer
Technology
Corporation
31 2-Jul-99
Industrial Approach

focus on analytic MCC’s role
evaluation of
architectural models

focus on wide range of
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
Source: N. Medvidovic, USC
Conclusions



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








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/
index.html
Aesop:
http://www.cs.cmu.edu/afs/cs/project/able/www/aesop/
aesop_home.html
Unicon:
http://www.cs.cmu.edu/afs/cs/project/vit/www/unicon/i
ndex.html
C2 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