Architecture Description LanguagesArchitecture Description Languages
Mohamed Soliman ([email protected])
Basem Shihada ([email protected])
Andreas Grau ([email protected])
2
Introduce Architecture Description Languages
Present three different classes of ADLs and their application
Show modeling in ADLs with components
GoalsGoals
3
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
IntroductionIntroduction
5
IntroductionIntroduction
Many ADLs have been proposedMetaHModeChartObjectTimeRapideRESOLVESADLUMLUniConWeavesWright
ACMEAesopArTekC2CODEDarwinDemeterFRGestaltLILEANNA
6
IntroductionIntroduction
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
IntroductionIntroduction
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
Rapide: An Event Based Architecture Description Language
10
OutlineOutline
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
BackgroundBackground
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 goalsRapide 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 SpecificationArchitecture Specification
1. Interfaces
(External component behavior)
2. Connections – wires
3. Constraints
(on interface & conn.)
Architecture
14
ADL requirements in RapideADL 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 AbstractionComponent 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 ExampleComponent 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 RapideEvents 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 ComponentsConnecting 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 RulesConnection 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 ConnectionsExample Connections
A Basic Connection?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 Architecturewith 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;
21
ConstraintsConstraints
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 RapideADL 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 ArchitecturesDynamic 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 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 ArchitecturesRelativity 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 ExecutionArchitecture 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
DiscussionDiscussion
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
ConclusionConclusion
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
Basem Shihada
Questions?!Questions?!
Break!
ACME: Architecture Description ACME: Architecture Description InterchangeInterchange Language Language
http://bbcr.uwaterloo.ca/~bshihada/cs854/acme.pdf
31
Presentation OutlinePresentation 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 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 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
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 GoalsACME 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.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 ACME Capabilities
1. Architectural Interchange
2. Extensible foundation for new architecture design & analysis tools
3. Architectural Description
38
ACME Features ACME Features
1. 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
39
ACME Kernel 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 ACME Kernel
41
ACME Kernel ExtensionsACME 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
ACME PropertiesACME Properties
Architectural Integration properties
Annotation
Properties list
43
ACME PropertiesACME Properties
44
Interchange History 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
45
ACME InfrastructureACME Infrastructure
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
ADL Converter
ACME Description
ACME Parser
ACME Access
Methods Description Target ADL
46
Wright to RapideWright to Rapide
47
Ongoing WorkOngoing 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
ConclusionConclusion
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?Questions?
Break!
50
Andreas Grau
UUnified nified MModeling odeling LLanguageanguage
52
UMLUML
Motivation, HistoryOverview of capabilitiesArchitecture in UMLUML as ADL
– Things in UML but not in ADLs– Drawbacks of UML– Different approaches– Commercial tools
53
UML: MotivationUML: Motivation
Provide a standardized notation for graphical models of software
Model systems from concept to executable
Useable for humans and computers
toolstools
Object OrientationObject Orientation
54
UML: HistoryUML: History
Based on OO-design (70s, 80s)Unification of Booch, OOSE, OMTFirst release v0.8 in 1995 by OMGLatest version: 1.4 (2001)
55
UML: MotivationUML: Motivation
Large set of predefined constructsExtensibleSemi-formal definition and semanticsWidely known
Developers already use UMLDevelopers already use UML
56
UML: OverviewUML: Overview
A UML model consists of several partial modelsClasses with attributes, operations and
relationsStates and behaviour of classesPackages of classes and their dependenciesScenarios of system usageDistributed component behaviour and
communication…
57
UML: OverviewUML: Overview A model is represented by
– Graphical notation (meta model)– Descriptive text– Constraints
10..*Flight Airplane
type :enum of cargo, passenger
type : enum of cargo, passenger
flights
58
UML for ArchitectureUML for Architecture
Design view Implementation view
Process view Deployment view
Use cases view
59
UML as ADLUML 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 ADLUML 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
[41], [61] on Medvidovic[41], [61] on Medvidovic
In the literatureIn the literature
61
Integrate UML and ADLsIntegrate UML and ADLs
Define UML meta-model similar to an existing ADL
Use OCL for constraints, invariants, pre- and postconditions
62
Integrate UML and ADLsIntegrate 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 are constraint to that of the ADLROOM, real ADLsROOM, real ADLs
63
Integrate UML and ADLsIntegrate UML and ADLs
Attendee-2 Attendee-3 Important Attendee-1
Important Attendee-2
Attendee-1
Meeting Initiator
AC
MC
IAC
<<CB>> <<CB>>
<<Component>> Attendee-1
<<Component>> Attendee-2
<<Component>> Attendee-3
<<Component>> ImportantAttendee-1
<<Component>> ImportantAttendee-2
<<Component>> MeetingInitiator
<<Connector>>
AC
<<Connector>>
IAC
<<Connector>>
MC
<<CB>> <<CB>> <<CB>>
<<BB>> <<BB>>
<<BC>>
Nenad Medvidovic ([email protected])
64
Integrate UML and ADLsIntegrate 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 extensionADL-UML extension
Use UML to refine a design in an ADLStill problems:
– Inter view consistency– Automated design tools (partly solved)– Not a standard
66
UML: Commercial toolsUML: 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, SAAGEDradel, SAAGE
67
UML: DiscussionUML: 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
ConclusionsConclusions
69
ComparisonComparison
Rapide– ADL with event based coordination
UML– Widely used graphical OMG standard
ACME– Interchange between ADLs
70
SummarySummary
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?!Questions?!
?