Download presentation
Presentation is loading. Please wait.
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?! ?
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.