Presentation is loading. Please wait.

Presentation is loading. Please wait.

Architecture Description Languages

Similar presentations


Presentation on theme: "Architecture Description Languages"— Presentation transcript:

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


Download ppt "Architecture Description Languages"

Similar presentations


Ads by Google