1. Architecture Description Languages
Mohamed Soliman
Basem Shihada
Andreas Grau

2. Goals Introduce Architecture Description Languages
Present three different classes of ADLs and their application
Show modeling in ADLs with components

3. Introduction Software can have high complexity => ADL
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

4. Nenad Medvidovic (neno@usc.edu)
Introduction
Nenad Medvidovic

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

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

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

8. Mohamed Soliman

9. Rapide: An Event Based Architecture Description Language

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

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

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

13. Architecture Specification
1. Interfaces
(External component behavior)
2. Connections – wires
3. Constraints
(on interface & conn.) 
Architecture

14. ADL requirements in Rapide
Component Abstraction
- Interface
- Behavior
Communication Abstraction
- Conn. uses interface
- Allow exec. / analysis
Communication Integrity
- Use of connection
- Ind. Communication
Dynamism
- # of components & connections may vary
During execution
Causality and Time
- Causal dependency of behaviors
- Orders of events
- Poset
Hierarchical Refinement - Relativity
- Arch. Vs. sub-arch.
- Reference. Arch.

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

16. 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;

17. Events in Rapide Events: tuples of information containing:
What generated the event - What activity was done
Data values - 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

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

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

20. Example Connections A Basic Connection Modem and Computer
?P : Person; ?B : Button;
Connections
?P.Push(?B) to Button_light_On(?B);;
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;
A Dynamic Architecture
with Airplane, Control_center;
architecture Air_Control_sector is
?A : Airplane; ?M : Msg;
SFO: Control_center
?A.Radio(?M) Where ?A.InRange(SFO)
||> SFO.Receive(?M);;
End Air_Control_Sector;

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

22. ADL requirements in Rapide
Component Abstraction
- Interface
- Behavior
Communication Abstraction
- Conn. uses interface
- Allow exec. / analysis
Communication Integrity
- Use of connection
- Ind. Communication
Dynamism
- # of components & connections may vary
During execution
Causality and Time
- Causal dependency of behaviors
- Orders of events
- Poset
Hierarchical Refinement - Relativity
- Arch. Vs. sub-arch.
- Reference. Arch.

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

24. 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]

25. 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
vs. reference architecture

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

27. 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!

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

29. Questions?!
Basem Shihada
Break!

30. ACME: Architecture Description Interchange Language

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

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

33. 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 high-learning curve

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

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

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

37. ACME Capabilities Architectural Interchange
Extensible foundation for new architecture design & analysis tools
Architectural Description

38. ACME Features
An architecture ontology consisting of seven basic architectural design elements
A flexible annotation mechanism sporting association of non-structure information using externally defined sub languages
A type mechanism for abstracting common, reusable architecture phrase and styles
An open semantic framework for analysis about architectural descriptions

39. 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)

40. ACME Kernel

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

42. Architectural Integration properties
ACME Properties
Architectural Integration properties
Annotation
Properties list

43. ACME Properties

44. 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 <-> UniCon works

45. ACME Infrastructure ACME-Lib infrastructure
ADL Converter
ACME
ACME
ACME
Access
Description
Description
Parser
Methods
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

46. Wright to Rapide

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

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

49. Questions?
Break!

50. Andreas Grau

51. Unified Modeling Language

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

53. UML: Motivation
Provide a standardized notation for graphical models of software
Model systems from concept to executable
Useable for humans and computers
Object Orientation
tools

54. 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)

55. UML: Motivation Large set of predefined constructs Extensible
Semi-formal definition and semantics
Widely known
Developers already use UML

56. 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 …

57. UML: Overview A model is represented by
Graphical notation (meta model)
Descriptive text
Constraints
Flight
0..* 1
Airplane
flights
type :
enum of cargo, passenger
type :
enum of cargo, passenger

58. UML for Architecture Design view Implementation view Use cases view
Process view
Deployment view

59. 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.)

60. UML as ADL Several problems occur:
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
In the literature
[41], [61] on Medvidovic

61. Integrate UML and ADLs
Define UML meta-model similar to an existing ADL
Use OCL for constraints, invariants, pre- and postconditions

62. Integrate UML and ADLs Application of UML in software architecture
Use UML “as is”
Extend UML to directly support architectural concerns
Use UML with build-in extensions
Select meta class close to ADL
Define stereotypes and apply them to class instances
Class semantics are constraint to that of the ADL
ROOM, real ADLs

63. <<Connector>>
Integrate UML and ADLs
Attendee-2
Attendee-3
Important Attendee-1
Important Attendee-2
Attendee-1
Meeting Initiator AC MC
IAC
<<CB>>
<<Component>> Attendee-1
<<Component>> Attendee-2
<<Component>> Attendee-3
<<Component>> ImportantAttendee-1
<<Component>> ImportantAttendee-2
<<Component>> MeetingInitiator
<<Connector>> AC
IAC MC
<<BB>>
<<BC>>
Nenad Medvidovic

64. Integrate UML and ADLs UML “as is” Manipulate by standard tools
Architectural constraint violations
readable
UML “constrained”
Ensures Architectural constraints
Requires complete style specifications
UML “extended”
“native” support for architectures
Requires special tools
May result in incompatible UML versions

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

66. 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
UML designers profit from analyses capabilities
Architects profit from UML tools (code generation, analysis …)
Dradel, SAAGE

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

68. Conclusions

69. Comparison Rapide UML ACME ADL with event based coordination
Widely used graphical OMG standard
ACME
Interchange between ADLs

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

71. Questions?! ?