Architecture Description Languages
Mohamed Soliman
Basem Shihada
Andreas Grau
(msoliman@bcr6.uwaterloo.ca)
(bshihada@bbcr.uwaterloo.ca)
(agrau@elora.math.uwaterloo.ca)
Goals
Introduce Architecture Description
Languages
 Present three different classes of
ADLs and their application
 Show modeling in ADLs with
components

2
Introduction

Software can have high complexity
– Coarse grain elements help to abstract
– Formal architecture is needed
•
•
•
•
•
Model System
Test System
Avoid wrong decisions on architectural (early!)
Reusability
Reduce development costs
=> ADL
3
Introduction
Nenad Medvidovic (neno@usc.edu)
4
Introduction
Many ADLs have been proposed
ACME
Aesop
ArTek
C2
CODE
Darwin
Demeter
FR
Gestalt
LILEANNA
MetaH
ModeChart
ObjectTime
Rapide
RESOLVE
SADL
UML
UniCon
Weaves
Wright
5
Introduction
What is an architecture?
“Software architecture involves the description of elements
from which systems are built, interactions among those
elements, patterns that guide their composition, and
constraints on these patterns.”
--Shaw and Garlan
Mary.Shaw@cs.cmu.edu, Garlan@cs.cmu.edu
6
Introduction
What is an ADL then?


An ADL is a language that provides features for modeling a
software system’s conceptual architecture.
Essential features: explicit specification of
–
–
–
–

components
interfaces
connectors
configurations
Desirable features
– specific aspects of components, connectors, and configurations
– tool support
7
Mohamed Soliman
8
Rapide: An Event Based Architecture
Description Language
Outline

Background
 Rapide Design goals
 ADL Requirements in Rapide
 Architecture components
 The Event Model and Posets
 Connecting Components – The Architecture
 More Rapide Features
 Discussion
 Conclusion
10
Background
Created in Stanford for DARPA – early 90’s
 Based on work by Prof. D. Luckham
– Logician
– Worked in concurrent Ada
– Co-founder of Rational Software, Inc.
 By then, and still, describing Software Architecture
needed more attention
 Hardware Description was more mature (VHDL)
 Now, it is widely accepted ADL

11
Rapide goals

To be an Executable Architecture Description
Language (EADL) that
– Provides constructs for defining executable
prototypes of architectures
– Adopts an execution model in which the
concurrency, synchronization, data flow and
timing properties of the prototype are explicitly
represented
12
Architecture Specification
1. Interfaces
(External component behavior)
2. Connections – wires
3. Constraints
(on interface & conn.)

Architecture
13
ADL requirements in Rapide
Component
Abstraction
Communication
Abstraction
Communication
Integrity
- Interface
- Behavior
- Conn. uses interface
- Allow exec. / analysis
- Use of connection
- Ind. Communication
Dynamism
Causality and Time
Hierarchical
Refinement Relativity
- # of components &
connections may vary
During execution
- Causal dependency
of behaviors
- Orders of events
- Poset
- Arch. Vs. sub-arch.
- Reference. Arch.
14
Component Abstraction

Description of rich interfaces is needed – must go beyond
traditional information hiding
• Why?

Interface type allows two methods of communication:
– Synchronous: by function calls (provides, requires)
• Provides: declared functions in module
• Requires: invoked functions by the module
– Asynchronous: by events (in, out)
• In: what actions the component will do on observing an event
• Out: what events the component will generate to the parent
architecture (other components)
• In, Out actions are glued by connectors
15
Component Example
Type AutoControls is interface
Provides
function speedometer return MPH;
function Gas return Gallons;
in action Steering_Wheel (A:Angle),
in action Accelerator(P : Position),
in action Brake(p : Pressure);
out action Warning(S : Status);
behavior
Speedometer > 55 ||>
Accelerator(0) || Brake(High) ||
Warning(On);;
……..
End AutoControls;
16
Events in Rapide

Events: tuples of information containing:
-

What generated the event
Data values
- What activity was done
- Time ,… etc
Causality between events: Components reactive behavior
– E.g. component X reacted to event EV1 by generating event EV2

Poset: Partially Ordered Set of Events
– Dependencies and independencies of events (ordering)
– Architecture Execution generates posets as well

Event Patterns: Expressions on events used for :
–
–
–
–
–
Defining behavior of components and connections
Mapping between architectures
Imposing constraints on posets Constraining behavior
Generate behavior (by generating posets)
E.g.
A(?I) Where ?I > 4
17
Connecting Components


An interface connection is a set of
- Interfaces - Connections - Constraints
Connections:
– Connection Rules


- Creation Rules
Creation Rules: event conditions leading to creation
of new components (for Dynamic architectures)
Connection Rules:
– Implementation independent relationship between events or
functions
– Uses event pattern matching
– Static and dynamic architectures
18
Connection Rules




‘Wire up’ components
Provide communication abstraction
Two patterns separated by (to, =>, ||>)
– Syntax: [Trigger op Right]
– Functions or Events
Connects (in, out) - Synchronous
(requires, provides) – Asynch.
19
Example Connections
A Basic Connection
?P : Person; ?B : Button;
Connections
?P.Push(?B) to Button_light_On(?B);;
A Dynamic Architecture
with Airplane, Control_center;
architecture Air_Control_sector is
?A : Airplane; ?M : Msg;
SFO: Control_center
Connections
?A.Radio(?M) Where ?A.InRange(SFO)
||> SFO.Receive(?M);;
End Air_Control_Sector;
Modem and Computer
with computer, modem;
architecture Office is
PC : Computer;
Mod: Modem;
….
Connect
-- bi-directional flow of events
PC.S1 To Mod.S;
End Office;
20
Constraints

Example: Component uses a particular
communication protocol
 Generated events in interfaces and
connections must match the constraints
(Constraint section)
 Along with connection rules, they provide
communication integrity
21
ADL requirements in Rapide
Component
Abstraction
Communication
Abstraction
Communication
Integrity
- Interface
- Behavior
- Conn. uses interface
- Allow exec. / analysis
- Use of connection
- Ind. Communication
Dynamism
Causality and Time
Hierarchical
Refinement Relativity
- # of components &
connections may vary
During execution
- Causal dependency
of behaviors
- Orders of events
- Poset
- Arch. Vs. sub-arch.
- Reference. Arch.
22
Dynamic Architectures

Static Architectures: declare the components in
object declarations

Dynamic Architectures (Evolution):
– Number of components is not known
– Declare the interface types of components
– By using component creation rules
23
Hierarchy




Hierarchical composition is an important feature of
ADLs
Connecting components should result in a new
component
Done in Rapide by binding architectures to interfaces
using connections
The Architecture is a component ->
[Interconnection of Architectures – ACME]
24
Relativity of Architectures

Comparing the behavior of one Architecture
(connected components) to another architecture
 Idea: Study how events of one system correspond to
the other
 Different levels of abstraction
– E.g.: Many events in one system map to just one
 Done by MAPPINGS
– Map from one name to another - Mapping rules
 Several advantages:
– Comparing different versions - Refinement
– Evaluate proposed architectures
25
vs. reference architecture
Architecture Execution

To test consistency of the interfaces and
connections
 To discover various aspects of the
architecture’s behavior
 To test that communication complies with
constraints
26
Discussion

Rapide provides only one single view of a system –
graphical tools support may help
Components are first-class entities while connectors
are not first-class entities as in Unicon, for example
– In Rapide, connectors are defined in the
architecture entity
Rapide is powerful but complex …

Rapide and coordination models!


27
Conclusion

Rapide is an Executable Architecture Description
Language (EADL) that is capable of:
– Modeling and describing architectures by
connecting components
– Modeling and simulation of the dynamic behaviors
by using Posets
 Components, Connectors and Constraints are the
basic entities
 The Poset execution model is a powerful tool for
analyzing system behavior – Not in other ADLs
 Dynamic Architectures, relativity, and hierarchical
refinement are achieved with Rapide
28
Questions?!
Basem Shihada
Break!
29
ACME: Architecture Description
Interchange Language
http://bbcr.uwaterloo.ca/~bshihada/cs854/acme.pdf
Presentation Outline







Background
Motivation
ACME
ACME Goals
ACME Capabilities
ACME Features
ACME Kernel







ACME Kernel Extensions
ACME Properties
Interchange History
ACME Infrastructure
Wright to Rapide
Ongoing Work
Conclusion
31
Background





Started early 1995
By D. Garlan, R. Monroe, & D. Wile, from
Garnegie Mellon Univ. & USC/Inf. Sciences
Institute
Categorized under the architecture
interchange languages
Support the interchange of architectural
description between variety of architectural
design tools.
A new design & analysis tools can be built
without rebuild standard infrastructure. 32
Motivations




Different ADL’s provides certain
distinctive capabilities
Each operates in stand-alone fashion
Many common aspects already
implemented in each ADL
Adopting certain ADL requires highlearning curve
33
ACME

Acme is simple, generic software
architectural description language that
provide generic, extensible infrastructure
for describing , representing, generating,
and analyzing software architecture
descriptions
 Consist of Acme Language and Acme Tool
Developer
34
ACME Goals

Interchange format for architectural
development tools and environments
 Underlying representation for
developing new tolls for analyzing
and visualizing architectures
 Foundation for developing new,
domain-specific ADLs
35
ACME Goals cont.

Vehicle for creating conventions:
consensus building
– Semantic foundations
• Refinement
• Event-based
• Temporal logic
– Architecture families
• Architecture evolution
• Dynamic architectures

Expressive descriptions that are easy for
humans to read and write.
36
ACME Capabilities
1.
2.
3.
Architectural Interchange
Extensible foundation for new
architecture design & analysis tools
Architectural Description
37
ACME Features
An architecture ontology consisting of seven
basic architectural design elements
2. A flexible annotation mechanism sporting
association of non-structure information
using externally defined sub languages
3. A type mechanism for abstracting common,
reusable architecture phrase and styles
4. An open semantic framework for analysis
about architectural descriptions
1.
38
ACME Kernel







Components (box): Primary computations
elements and data stores.
Connectors (Arrow): Interaction among
components
Systems: configuration of components and
connectors
Ports: components interfaces
Roles: connectors interfaces
Representations
Rep-maps: maps the internal and external
(interfaces, ports, ..etc)
39
ACME Kernel
40
ACME Kernel Extensions

Need to extend kernel to as large a language
as is acceptable by the community
 Templates
– Typed macros
– With typed arguments

Families: Styles and other constrained
aggregates
– Specification as a set of templates and types
– Declaration of restriction to family enforces
template usage
41
ACME Properties
Architectural Integration properties
Annotation
Properties list
42
ACME Properties
43
Interchange History

Wright -> Rapide Translation
– Initial translation technology developed
– One-way translation (not round trip)

Aesop <-> ACME <-> UniCon
–
–
–
–
Aesop <-> ACME 1.0 works
Aesop <-> ACME 3.0 underway
Aesop <-> ACME 3.0 underway
Aesop <-> ACME <-> UniCon works
44
ACME Infrastructure
ADL Converter
ACME
Description

ACME
Parser
ACME
Access
Methods
Description
Target ADL
ACME-Lib infrastructure
–
–
–
–
Extensible ACME parser & unparsed
Extensible ACME Translation tools
Native-ADL embeddable support
Support for design traversal, manipulation, and
type-checking in ACME-native tools
45
Wright to Rapide
46
Ongoing Work

Prototypes for several ACME tools to
be provided to the architecture and
generation EDCS cluster
 Prototypes for tools that allow others to
provide domain-specific analyzers
 Promised, type checker, visualization
tools
47
Conclusion





Architectural description Integration
Language
Capable of
– Architectural integration toolkit
– Extendable foundation for new tools
– Architecture Description.
Consist of several elements
Elements supported with properties
Open semantic framework
48
Questions?
Break!
49
Andreas Grau
50
Unified Modeling Language
UML
Motivation, History
 Overview of capabilities
 Architecture in UML
 UML as ADL

– Things in UML but not in ADLs
– Drawbacks of UML
– Different approaches
– Commercial tools
52
UML: Motivation
Provide a standardized notation for
graphical models of software
 Model systems from concept to
executable Object Orientation
 Useable for humans and computers

tools
53
UML: History
Based on OO-design (70s, 80s)
 Unification of Booch, OOSE, OMT
 First release v0.8 in 1995 by OMG
 Latest version: 1.4 (2001)

54
UML: Motivation
Large set of predefined constructs
 Extensible
 Semi-formal definition and semantics
 Widely known

Developers already use UML
55
UML: Overview

A UML model consists of several partial models
 Classes with attributes, operations and
relations
 States and behaviour of classes
 Packages of classes and their dependencies
 Scenarios of system usage
 Distributed component behaviour and
communication
 …
56
UML: Overview

A model is represented by
– Graphical notation (meta model)
– Descriptive text
– Constraints
Flight
type :
enum of cargo, passenger
0..*
flights
1
Airplane
type :
enum of cargo, passenger
57
UML for Architecture
Design view
Implementation view
Use cases view
Process view
Deployment view
58
UML as ADL
“Yes, UML is an ADL” (Grady Booch,
Rational Rose)
(UML is used
visualizing
specifying
constructing and
documenting
the aspects of a software intensive system.)
59
UML as ADL
Several problems occur: In the literature
 Description of connectors as first class entities
 Support of different styles
 Description of interfaces as first class entities
 Topological constraints
 Semantically insufficient for tools analysis
 Focus on physical instead of logical components
[41], [61] on Medvidovic
60
Integrate UML and ADLs
Define UML meta-model similar to an
existing ADL
 Use OCL for constraints, invariants,
pre- and postconditions

61
Integrate UML and ADLs
Application of UML in software architecture
1.
Use UML “as is”
2.
Extend UML to directly support architectural
concerns
3.
Use UML with build-in extensions



Select meta class close to ADL
Define stereotypes and apply them to class instances
Class semantics
arereal
constraint
to that of the ADL
ROOM,
ADLs
62
Integrate UML and ADLs
Attendee-1
Attendee-2
Attendee-3
Important
Attendee-1
Important
Attendee-2
AC
IAC
MC
Meeting
Initiator
<<Component>>
<<Component>>
<<Component>>
Attendee-1
Attendee-2
Attendee-3
<<CB>>
<<CB>>
<<Component>>
ImportantAttendee-1
<<CB>>
<<Component>>
ImportantAttendee-2
<<CB>>
<<CB>>
<<Connector>>
<<Connector>>
AC
IAC
<<BB>>
<<BB>>
<<Connector>>
MC
<<BC>>
<<Component>>
Nenad Medvidovic (neno@usc.edu)
MeetingInitiator
63
Integrate UML and ADLs
UML “as is”
UML “constrained”
UML “extended”
•Manipulate by
standard tools
•Ensures
Architectural
constraints
•“native” support for
architectures
•Architectural
constraint violations
•readable
•Requires complete
style specifications
•Requires special
tools
•May result in
incompatible UML
versions
64
ADL-UML extension
Use UML to refine a design in an ADL
 Still problems:

– Inter view consistency
– Automated design tools (partly solved)
– Not a standard
65
UML: Commercial tools



Rational Rose, USC-CSE (C2Sadel+UML)
Tools help refining an architectural system model
in an ADL to an UML design
ADLs and UML can complement each other
Dradel, SAAGE
– UML designers profit from analyses capabilities
– Architects profit from UML tools (code generation,
analysis …)
66
UML: Discussion




UML is widely used in the industry to model
software (architectural constraints are missing)
UML can be extended to be an ADL
UML can be complemented with an ADL
UML 2.0 will offer support of Architectural
constraints
67
Conclusions
68
Comparison

Rapide
– ADL with event based coordination

UML
– Widely used graphical OMG standard

ACME
– Interchange between ADLs
69
Summary



Architecture is Components +
Connectors + Topology
ADLs can help to describe, test, analyse
and design architecture
People in the literature disagree what
ADLs should provide
– Rapide and UML are different design
languages with different approaches
– ACME can connect different ADLs
70
Questions?!
?
71