Architecture Description Languages: An Overview

1. Tw Cook
[phone]
twOmcc.com

Architecture Definition
ADLs
Architecture vs. Design
ADLs Considered
+ ACME
+ Rapide
+ Wright
+ Aesop
+ Uni h
+ UML '
Approaches 1
'
'

: NONE N
10101010000] fe

Conclusion

Architecture Description
Languages: An Overview

© 1999 Microelectronics and Computer Technology Corporation — All Rights Reserved

2. Mcc

Architecture — A Definition

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.”

— from Software Architecture in Practice,
Bass, Clements, and Kazman

3. MCC
Architecture Description Languages

= 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
m 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

+

4. MCC
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”)

architecture
(ADL)

functional
requirements
(domains)

design
(UML)

a Heuristic: it is necessary to go one level deeper to validate choices, so the
Le) architect has to do a high-level design to validate the partitioning

5. MCC
Quality Attributes and Architectural Strategies

Dependability

Interoperability

Usability a )

Performance Positive
Effects:

Adaptability Amy

Cost 4

Schedule Bégeuve

Eifzcis

Assurance monitoring &
control

Layering
Diagnostics
Pipelining
Architecture balance
Parallelism
GUI-driven
API-driven

Performance monitoring &
control

Change-source hiding
COTS/reuse-driven

6. Mcc

Common Concept of Architecture:
Object Connection Architecture

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

7. Mcc
An Object Connection Architecture

8. MCC
Object Connection Architecture

= 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!

+ “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.”

9. MCC
Another Concept of Architecture:
Interface Connection Architecture

a 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

10. MCC
An Interface Connection Architecture

provides. requires

connection

interface

module

4

11. Mcc

Interface Connection Architecture

= The Good news
+ Improved conformance of a system to an architecture
+ Architecture can be built before modules are implemented

m The bad news
+ No emerging standard
+ Poor quality tools

= Most ADLs implement an interface connection architecture.

12. Mcc

2
21-0219

Software Architecture: ADL Perspective

= The ADL community generally agrees that Software
Architecture is a set of components and the connections
among them.

components
+ connectors

+ configurations
+

constraints

13. Mcc

ADLs Considered by MCC

= 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

14. Mcc

ACME

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

15. Mcc

15
21-0299

An ADL Example (in ACME)

System simple_cs = {
Component client = {Port send-request}
Component server = {Port receive-request}
Connector rpe = {Roles {caller, callee}}
Attachments : {client.send-request to rpc.caller;
server.receive-request to rpc.callee}

16. Mcc

Rapide

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

17. Mcc

The Rapide Model

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

18. Mcc

The Rapide Model (cont’d)
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

19. Mcc

Rapide Architectural Elements

Architecture ——

Component

components

connections

constraints

interface

interface

architecture

interface

module

20. MCC
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:
« Basic connections (A to B)
+ Pipe connections (A => B)
» Agent connections (A ||> B)

21. Mcc

Architectural Elements (cont’d)

a Constraints - Pattern
+ Bound execution in terms of event patterns
+ Appear in an interface and/or architecture definition
+ [label] filter_part constraint_body
+ 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

m Configuration
+ The architecture itself
+ Supports hierarchical decomposition (l.e nested architectures)
+ Contains components, connections, and constraints

22. Mcc

Architectural Elements (cont’d)

Interface ———>

provides part io
objects
requires part types
action part in actions
out actions
service part state
behavior part State transitions

constraint part

pattern constraints

private part

interface with no
private part

23. Mcc

Architectural Elements (cont’d)

components

connections

initial part

statements

Module ———>

processes

constraints

handlers

Map —

J]
domain —> range

final part —_——

statements

state transitions

rule part >

constraints

24. Mcc

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

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;

25. Mcc

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

+ 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)

26. Mcc

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
Ss : server
e : client
ro: rpe
Attachments
client.send-request as rpc.caller
server.receive request as rpc.callee
end simple_cs.

27. Mcc

Aesop

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
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

28. Mcc

Unicon

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

29. Mcc
Others ...

u MetaH

+ Developed by Honeywell, a domain specific ADL aimed at
guidance, navigation, and control applications with ControlH

+ Sophisticated tool support available
= C2SADL

+ 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

30. Mcc |
UML as an ADL

u The Positive
+ lowers entry barrier, mainstreams modeling, tools
= Shortcomings of UML as an ADL

+ Encourages an object connection architecture rather than
interface connection architecture

+ 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

31. Mcc

Approaches to Architecture

Bs

Academic Approach ( À Industrial Approach

MCC's role
= focus on analytic evaluation of m 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

Source: N. Medvidovic, USC

32. Mcc

Approaches to Architecture

Academic Approach

Industrial Approach

MCC's role

focus on analytic evaluation of
architectural models

individual models

rigorous modeling notations

powerful analysis techniques

depth over breadth

special-purpose solutions

focus on wide range of:
development issues

families of models

practicality over rigor

architecture as the “big picture” in
development

breadth over depth

general-purpose solutions

Source: N. Medvidovic, USC

33. Conclusions

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

34. Mcc

For More Information

ACME: htip://www.cs:emuedu/-aeme

Rapide: http://pavg.stanford.edu/rapige,
Wright: http:/www.cs.cmu.edi/ats/es/prolesvabie www wrantindex him!

Aesop:

http:/Avww.cs.cmu.edu/afs/es/projecvablenvwWisesOp/aesop home html
Unicon: htto:/wwwies emu ed/atsies/projectVitiwww/unicon/index.htm|
C2 SADL: hitp://www.ies:ueredu/pub/arch/

SSEP: http://wwiwimec.com/projects/ssepp

ADML: hitp:/iwwwemee cami/projecis/ssepp/admi

A possibly more current version of this presentation can be
found WuuEmee comiprojects/ssepp/admi/tog