architecture description languages

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

4


Nenad Medvidovic ([email protected])

5


Many ADLs have been proposedMetaHModeChartObjectTimeRapideRESOLVESADLUMLUniConWeavesWright

ACMEAesopArTekC2CODEDarwinDemeterFRGestaltLILEANNA

6


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

[email protected], [email protected]

7


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


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


Attendee-2 Attendee-3 Important Attendee-1

Important Attendee-2

Attendee-1

Meeting Initiator

AC

MC

IAC

<<CB>> <<CB>>

<<Component>> Attendee-1



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


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

?

architecture description languages

Documents

software architecture

abstractformal architecture

parent architecture

architecture adl requirements

description of elements

attentionhardware description

event ev2poset

event ev1