architecture description languages: an overview architecture description languages: an overview...

33
Architecture Architecture Description Languages: Description Languages: An Overview An Overview Architecture Def inition ADLs Architecture vs. Design ADLs Considered ACME Rapide Wright Aesop Unicon UML Approaches Conclusion Tw Cook +1-512-338-3522 [email protected]

Upload: sabina-williamson

Post on 27-Dec-2015

277 views

Category:

Documents


5 download

TRANSCRIPT

Page 1: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Architecture Description Architecture Description Languages: An OverviewLanguages: An Overview

Architecture Definition

ADLs

Architecture vs. Design

ADLs Considered

ACME

Rapide

Wright

Aesop

Unicon

UML

Approaches

Conclusion

Tw Cook+1-512-338-

[email protected]

Tw Cook+1-512-338-

[email protected]

Page 2: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

2 2-Jul-99

Architecture – A DefinitionArchitecture – A DefinitionArchitecture – A DefinitionArchitecture – A Definition

““The software architecture of a program or The software architecture of a program or computing system is the structure or structures computing system is the structure or structures of the system, which comprise software of the system, which comprise software components, the externally visible properties of components, the externally visible properties of those components, and the relationships among those components, and the relationships among them.”them.”

– – from from Software Architecture in PracticeSoftware Architecture in Practice,,Bass, Clements, and KazmanBass, Clements, and Kazman

““The software architecture of a program or The software architecture of a program or computing system is the structure or structures computing system is the structure or structures of the system, which comprise software of the system, which comprise software components, the externally visible properties of components, the externally visible properties of those components, and the relationships among those components, and the relationships among them.”them.”

– – from from Software Architecture in PracticeSoftware Architecture in Practice,,Bass, Clements, and KazmanBass, Clements, and Kazman

Page 3: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

3 2-Jul-99

Architecture Description LanguagesArchitecture Description LanguagesArchitecture Description LanguagesArchitecture Description Languages

The positivesThe positives ADLs represent a formal way of representing architectureADLs represent a formal way of representing architecture ADLs are intended to be both human and machine ADLs are intended to be both human and machine

readablereadable ADLs support describing a system at a higher level than ADLs support describing a system at a higher level than

previously possiblepreviously possible ADLs permit analysis of architectures – completeness, ADLs permit analysis of architectures – completeness,

consistency, ambiguity, and performanceconsistency, ambiguity, and performance ADLs can support automatic generation of software ADLs can support automatic generation of software

systemssystems The negativesThe negatives

There is not universal agreement on what ADLs should There is not universal agreement on what ADLs should represent, particularly as regards the behavior of the represent, particularly as regards the behavior of the architecturearchitecture

Representations currently in use are relatively difficult to Representations currently in use are relatively difficult to parse and are not supported by commercial toolsparse and are not supported by commercial tools

Most ADL work today has been undertaken with Most ADL work today has been undertaken with academic rather than commercial goals in mindacademic rather than commercial goals in mind

Most ADLs tend to be very vertically optimized toward a Most ADLs tend to be very vertically optimized toward a particular kind of analysisparticular kind of analysis

The positivesThe positives ADLs represent a formal way of representing architectureADLs represent a formal way of representing architecture ADLs are intended to be both human and machine ADLs are intended to be both human and machine

readablereadable ADLs support describing a system at a higher level than ADLs support describing a system at a higher level than

previously possiblepreviously possible ADLs permit analysis of architectures – completeness, ADLs permit analysis of architectures – completeness,

consistency, ambiguity, and performanceconsistency, ambiguity, and performance ADLs can support automatic generation of software ADLs can support automatic generation of software

systemssystems The negativesThe negatives

There is not universal agreement on what ADLs should There is not universal agreement on what ADLs should represent, particularly as regards the behavior of the represent, particularly as regards the behavior of the architecturearchitecture

Representations currently in use are relatively difficult to Representations currently in use are relatively difficult to parse and are not supported by commercial toolsparse and are not supported by commercial tools

Most ADL work today has been undertaken with Most ADL work today has been undertaken with academic rather than commercial goals in mindacademic rather than commercial goals in mind

Most ADLs tend to be very vertically optimized toward a Most ADLs tend to be very vertically optimized toward a particular kind of analysisparticular kind of analysis

Page 4: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

4 2-Jul-99

Architecture vs. DesignArchitecture vs. DesignArchitecture vs. DesignArchitecture vs. Design

non-functional requirements

(“ilities”)

functional requirements

(domains)

Heuristic: it is necessary to go one level deeper to validate choices, Heuristic: it is necessary to go one level deeper to validate choices, so the architect has to do a high-level design to validate the so the architect has to do a high-level design to validate the

partitioningpartitioning

Architecture:Architecture: where non-functional decisions are cast, where non-functional decisions are cast, and functional requirements are partitionedand functional requirements are partitionedDesign:Design: where functional requirements are where functional requirements are accomplishedaccomplished

architecturearchitecture(ADL)(ADL)

designdesign(UML)(UML)

Page 5: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

5 2-Jul-99

PositiveEffects

PositiveEffects

NegativeEffects

NegativeEffects

Quality Attributes and Architectural Quality Attributes and Architectural StrategiesStrategies

Quality Attributes and Architectural Quality Attributes and Architectural StrategiesStrategies

DependabilityDependability

InteroperabilityInteroperability

UsabilityUsability

PerformancePerformance

AdaptabilityAdaptability

Cost Cost

ScheduleSchedule

DependabilityDependability

InteroperabilityInteroperability

UsabilityUsability

PerformancePerformance

AdaptabilityAdaptability

Cost Cost

ScheduleSchedule

Assurance monitoring & Assurance monitoring & controlcontrol

LayeringLayering DiagnosticsDiagnostics PipeliningPipelining Architecture balanceArchitecture balance ParallelismParallelism GUI-drivenGUI-driven API-drivenAPI-driven Performance monitoring Performance monitoring

& control& control Change-source hidingChange-source hiding COTS/reuse-drivenCOTS/reuse-driven

Assurance monitoring & Assurance monitoring & controlcontrol

LayeringLayering DiagnosticsDiagnostics PipeliningPipelining Architecture balanceArchitecture balance ParallelismParallelism GUI-drivenGUI-driven API-drivenAPI-driven Performance monitoring Performance monitoring

& control& control Change-source hidingChange-source hiding COTS/reuse-drivenCOTS/reuse-driven

Page 6: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

6 2-Jul-99

Common Concept of Architecture:Common Concept of Architecture:Object Connection ArchitectureObject Connection Architecture

Common Concept of Architecture:Common Concept of Architecture:Object Connection ArchitectureObject Connection Architecture

Configuration consists of the interfaces and Configuration consists of the interfaces and connections of an object-oriented systemconnections of an object-oriented system

Interfaces specify the features that must be Interfaces specify the features that must be provided by modules conforming to an interfaceprovided by modules conforming to an interface

Connections represented by interfaces together Connections represented by interfaces together with call graphwith call graph

Conformance usually enforced by the Conformance usually enforced by the programming languageprogramming language decomposition - associating interfaces with unique decomposition - associating interfaces with unique

modulesmodules Interface conformance - static checking of syntactic Interface conformance - static checking of syntactic

rulesrules communication integrity - visibility between communication integrity - visibility between

modulesmodules

Configuration consists of the interfaces and Configuration consists of the interfaces and connections of an object-oriented systemconnections of an object-oriented system

Interfaces specify the features that must be Interfaces specify the features that must be provided by modules conforming to an interfaceprovided by modules conforming to an interface

Connections represented by interfaces together Connections represented by interfaces together with call graphwith call graph

Conformance usually enforced by the Conformance usually enforced by the programming languageprogramming language decomposition - associating interfaces with unique decomposition - associating interfaces with unique

modulesmodules Interface conformance - static checking of syntactic Interface conformance - static checking of syntactic

rulesrules communication integrity - visibility between communication integrity - visibility between

modulesmodules

Page 7: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

7 2-Jul-99

An Object Connection ArchitectureAn Object Connection ArchitectureAn Object Connection ArchitectureAn Object Connection Architecture

Page 8: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

8 2-Jul-99

Object Connection ArchitectureObject Connection ArchitectureObject Connection ArchitectureObject Connection Architecture

The good newsThe good news Mature development languages - C++, Ada, JavaMature development languages - C++, Ada, Java Visual modeling and automatic code generation Visual modeling and automatic code generation

toolstools Standardized modeling language - UMLStandardized modeling language - UML

The bad newsThe bad news Modules must be built before the architecture is Modules must be built before the architecture is

defineddefined Architecture not invariant under changes to system Architecture not invariant under changes to system Conformance of a system to an architecture is Conformance of a system to an architecture is

minimalminimal Can not be used to plan a systemCan not be used to plan a system

Really not an architecture at all!Really not an architecture at all!

The good newsThe good news Mature development languages - C++, Ada, JavaMature development languages - C++, Ada, Java Visual modeling and automatic code generation Visual modeling and automatic code generation

toolstools Standardized modeling language - UMLStandardized modeling language - UML

The bad newsThe bad news Modules must be built before the architecture is Modules must be built before the architecture is

defineddefined Architecture not invariant under changes to system Architecture not invariant under changes to system Conformance of a system to an architecture is Conformance of a system to an architecture is

minimalminimal Can not be used to plan a systemCan not be used to plan a system

Really not an architecture at all!Really not an architecture at all!

Page 9: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

9 2-Jul-99

Another Concept of Architecture:Another Concept of Architecture: Interface Connection ArchitectureInterface Connection ArchitectureAnother Concept of Architecture:Another Concept of Architecture:

Interface Connection ArchitectureInterface Connection Architecture

Expands the role of interfaces and connectionsExpands the role of interfaces and connections Interfaces specify both “required” and “provided” Interfaces specify both “required” and “provided”

featuresfeatures Connections are defined between “required” Connections are defined between “required”

features and “provided” featuresfeatures and “provided” features

Consists of interfaces, connections and Consists of interfaces, connections and constraintsconstraints Constraints restrict behavior of interfaces and Constraints restrict behavior of interfaces and

connections in an architectureconnections in an architecture Constraints in an architecture map to requirements Constraints in an architecture map to requirements

for a system for a system

Expands the role of interfaces and connectionsExpands the role of interfaces and connections Interfaces specify both “required” and “provided” Interfaces specify both “required” and “provided”

featuresfeatures Connections are defined between “required” Connections are defined between “required”

features and “provided” featuresfeatures and “provided” features

Consists of interfaces, connections and Consists of interfaces, connections and constraintsconstraints Constraints restrict behavior of interfaces and Constraints restrict behavior of interfaces and

connections in an architectureconnections in an architecture Constraints in an architecture map to requirements Constraints in an architecture map to requirements

for a system for a system

Page 10: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

10 2-Jul-99

An Interface Connection ArchitectureAn Interface Connection ArchitectureAn Interface Connection ArchitectureAn Interface Connection Architecture

module

interface

connection

provides requires

Page 11: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

11 2-Jul-99

Interface Connection ArchitectureInterface Connection ArchitectureInterface Connection ArchitectureInterface Connection Architecture

The Good newsThe Good news Improved conformance of a system to an Improved conformance of a system to an

architecturearchitecture Architecture can be built before modules are Architecture can be built before modules are

implementedimplemented

The bad newsThe bad news No emerging standardNo emerging standard Poor quality toolsPoor quality tools

Most ADLs implement an interface connection Most ADLs implement an interface connection architecture.architecture.

The Good newsThe Good news Improved conformance of a system to an Improved conformance of a system to an

architecturearchitecture Architecture can be built before modules are Architecture can be built before modules are

implementedimplemented

The bad newsThe bad news No emerging standardNo emerging standard Poor quality toolsPoor quality tools

Most ADLs implement an interface connection Most ADLs implement an interface connection architecture.architecture.

Page 12: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

12 2-Jul-99

Software Architecture: ADL Software Architecture: ADL PerspectivePerspective

Software Architecture: ADL Software Architecture: ADL PerspectivePerspective

The ADL community generally agrees that The ADL community generally agrees that Software Architecture is a set of components Software Architecture is a set of components and the connections among them.and the connections among them. componentscomponents connectorsconnectors configurationsconfigurations constraintsconstraints

The ADL community generally agrees that The ADL community generally agrees that Software Architecture is a set of components Software Architecture is a set of components and the connections among them.and the connections among them. componentscomponents connectorsconnectors configurationsconfigurations constraintsconstraints

Page 13: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

13 2-Jul-99

ADLs Considered by MCCADLs Considered by MCCADLs Considered by MCCADLs Considered by MCC

Leading candidatesLeading candidates ACME (CMU/USC)ACME (CMU/USC) Rapide (Stanford)Rapide (Stanford) Wright (CMU)Wright (CMU) Unicon (CMU)Unicon (CMU)

Secondary candidatesSecondary candidates Aesop (CMU)Aesop (CMU) MetaH (Honeywell)MetaH (Honeywell) C2 SADL (UCI)C2 SADL (UCI) SADL (SRI)SADL (SRI)

OthersOthers LileannaLileanna UMLUML ModechartModechart

Leading candidatesLeading candidates ACME (CMU/USC)ACME (CMU/USC) Rapide (Stanford)Rapide (Stanford) Wright (CMU)Wright (CMU) Unicon (CMU)Unicon (CMU)

Secondary candidatesSecondary candidates Aesop (CMU)Aesop (CMU) MetaH (Honeywell)MetaH (Honeywell) C2 SADL (UCI)C2 SADL (UCI) SADL (SRI)SADL (SRI)

OthersOthers LileannaLileanna UMLUML ModechartModechart

Page 14: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

14 2-Jul-99

ACMEACMEACMEACME

ACME was developed jointly by Monroe, Garlan ACME was developed jointly by Monroe, Garlan (CMU) and Wile (USC)(CMU) and Wile (USC)

ACME is a general purpose ADL originally ACME is a general purpose ADL originally designed to be a lowest common denominator designed to be a lowest common denominator interchange languageinterchange language

ACME as a language is extremely simple ACME as a language is extremely simple (befitting its origin as an interchange language)(befitting its origin as an interchange language)

ACME has no native behavioral specification ACME has no native behavioral specification facility so only syntactic linguistic analysis is facility so only syntactic linguistic analysis is possiblepossible there are currently efforts under consideration to there are currently efforts under consideration to

define a behavioral semantics for ACME, possibly define a behavioral semantics for ACME, possibly along the Wright/CSP linealong the Wright/CSP line

ACME has no native generation capability ACME has no native generation capability ACME has seen some native tool development, ACME has seen some native tool development,

and there are indications of more, as well as use and there are indications of more, as well as use of other language tools via interchangeof other language tools via interchange

ACME was developed jointly by Monroe, Garlan ACME was developed jointly by Monroe, Garlan (CMU) and Wile (USC)(CMU) and Wile (USC)

ACME is a general purpose ADL originally ACME is a general purpose ADL originally designed to be a lowest common denominator designed to be a lowest common denominator interchange languageinterchange language

ACME as a language is extremely simple ACME as a language is extremely simple (befitting its origin as an interchange language)(befitting its origin as an interchange language)

ACME has no native behavioral specification ACME has no native behavioral specification facility so only syntactic linguistic analysis is facility so only syntactic linguistic analysis is possiblepossible there are currently efforts under consideration to there are currently efforts under consideration to

define a behavioral semantics for ACME, possibly define a behavioral semantics for ACME, possibly along the Wright/CSP linealong the Wright/CSP line

ACME has no native generation capability ACME has no native generation capability ACME has seen some native tool development, ACME has seen some native tool development,

and there are indications of more, as well as use and there are indications of more, as well as use of other language tools via interchangeof other language tools via interchange

Page 15: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

15 2-Jul-99

An ADL Example (in ACME)An ADL Example (in ACME)An ADL Example (in ACME)An ADL Example (in ACME)

System simple_cs = {System simple_cs = {Component client = {Port send-request}Component client = {Port send-request}Component server = {Port receive-request}Component server = {Port receive-request}Connector rpc = {Roles {caller, callee}}Connector rpc = {Roles {caller, callee}}Attachments : {client.send-request to rpc.caller;Attachments : {client.send-request to rpc.caller; server.receive-request to rpc.callee}server.receive-request to rpc.callee}

}}

System simple_cs = {System simple_cs = {Component client = {Port send-request}Component client = {Port send-request}Component server = {Port receive-request}Component server = {Port receive-request}Connector rpc = {Roles {caller, callee}}Connector rpc = {Roles {caller, callee}}Attachments : {client.send-request to rpc.caller;Attachments : {client.send-request to rpc.caller; server.receive-request to rpc.callee}server.receive-request to rpc.callee}

}}

client

send-request

server

receive-requestcaller callee

rpc

Page 16: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

16 2-Jul-99

RapideRapideRapideRapide

Rapide was developed by Dr. David Luckham at Rapide was developed by Dr. David Luckham at StanfordStanford

Rapide is a general purpose ADL designed with Rapide is a general purpose ADL designed with an emphasis on simulation yielding partially an emphasis on simulation yielding partially ordered sets of events (posets)ordered sets of events (posets)

Rapide as a language is fairly sophisticated, Rapide as a language is fairly sophisticated, including data types and operationsincluding data types and operations

Rapide analysis tools focus on posetsRapide analysis tools focus on posets matching simulation results against patterns of matching simulation results against patterns of

allowed/prohibited behaviorsallowed/prohibited behaviors some support for timing analysissome support for timing analysis focus on causalityfocus on causality

Rapide has some generation capability since Rapide has some generation capability since Rapide specifications are executableRapide specifications are executable

Rapide has a fairly extensive toolsetRapide has a fairly extensive toolset

Rapide was developed by Dr. David Luckham at Rapide was developed by Dr. David Luckham at StanfordStanford

Rapide is a general purpose ADL designed with Rapide is a general purpose ADL designed with an emphasis on simulation yielding partially an emphasis on simulation yielding partially ordered sets of events (posets)ordered sets of events (posets)

Rapide as a language is fairly sophisticated, Rapide as a language is fairly sophisticated, including data types and operationsincluding data types and operations

Rapide analysis tools focus on posetsRapide analysis tools focus on posets matching simulation results against patterns of matching simulation results against patterns of

allowed/prohibited behaviorsallowed/prohibited behaviors some support for timing analysissome support for timing analysis focus on causalityfocus on causality

Rapide has some generation capability since Rapide has some generation capability since Rapide specifications are executableRapide specifications are executable

Rapide has a fairly extensive toolsetRapide has a fairly extensive toolset

Page 17: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

17 2-Jul-99

The Rapide ModelThe Rapide ModelThe Rapide ModelThe Rapide Model

Rapide is a concurrent, object-oriented , event-Rapide is a concurrent, object-oriented , event-based simulation languagebased simulation language

Defines and simulates behavior of distributed Defines and simulates behavior of distributed object system architecturesobject system architectures

Produces a simulation represented by a set of Produces a simulation represented by a set of events (poset)events (poset) Events are ordered with respect to time and Events are ordered with respect to time and

causalitycausality

System requirements are expressed as System requirements are expressed as constraints on time and concurrent patterns of constraints on time and concurrent patterns of eventsevents

Posets enable visualization and analysis of an Posets enable visualization and analysis of an executionexecution

Rapide is a concurrent, object-oriented , event-Rapide is a concurrent, object-oriented , event-based simulation languagebased simulation language

Defines and simulates behavior of distributed Defines and simulates behavior of distributed object system architecturesobject system architectures

Produces a simulation represented by a set of Produces a simulation represented by a set of events (poset)events (poset) Events are ordered with respect to time and Events are ordered with respect to time and

causalitycausality

System requirements are expressed as System requirements are expressed as constraints on time and concurrent patterns of constraints on time and concurrent patterns of eventsevents

Posets enable visualization and analysis of an Posets enable visualization and analysis of an executionexecution

Page 18: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

18 2-Jul-99

The Rapide Model (cont’d)The Rapide Model (cont’d)The Rapide Model (cont’d)The Rapide Model (cont’d)

Components execute independentlyComponents execute independently

Components both observe and generate eventsComponents both observe and generate events Each event represents the occurrence of an activityEach event represents the occurrence of an activity

Generates dependent eventsGenerates dependent events Reactive rules in interface behaviors (i.e. transition rules)Reactive rules in interface behaviors (i.e. transition rules) Reactive processes in modules (i.e. when statements) Reactive processes in modules (i.e. when statements) Events generated by sequential executionEvents generated by sequential execution Shared objects via referencesShared objects via references

Generates timed eventsGenerates timed events Interface behavior or module can be timedInterface behavior or module can be timed Events receive start and finish times within scope of its Events receive start and finish times within scope of its

clockclock Events can be synchronized to a clockEvents can be synchronized to a clock

Components execute independentlyComponents execute independently

Components both observe and generate eventsComponents both observe and generate events Each event represents the occurrence of an activityEach event represents the occurrence of an activity

Generates dependent eventsGenerates dependent events Reactive rules in interface behaviors (i.e. transition rules)Reactive rules in interface behaviors (i.e. transition rules) Reactive processes in modules (i.e. when statements) Reactive processes in modules (i.e. when statements) Events generated by sequential executionEvents generated by sequential execution Shared objects via referencesShared objects via references

Generates timed eventsGenerates timed events Interface behavior or module can be timedInterface behavior or module can be timed Events receive start and finish times within scope of its Events receive start and finish times within scope of its

clockclock Events can be synchronized to a clockEvents can be synchronized to a clock

Page 19: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

19 2-Jul-99

Rapide Architectural ElementsRapide Architectural ElementsRapide Architectural ElementsRapide Architectural Elements

Componentscomponents

connections

constraints

Componentsinterface

interface

architecture

interface

module

Architecture

Component

Page 20: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

20 2-Jul-99

Rapide Architectural Elements Rapide Architectural Elements (cont’d)(cont’d)

Rapide Architectural Elements Rapide Architectural Elements (cont’d)(cont’d)

ComponentsComponents Interface objectsInterface objects Architecture that implements an interfaceArchitecture that implements an interface Module that implements an interfaceModule that implements an interface

ConnectionsConnections Connects “sending interfaces” to “receiving Connects “sending interfaces” to “receiving

interfaces”interfaces” Components communicate through connections by Components communicate through connections by

calling actions or functions in its own interface calling actions or functions in its own interface Events generated by components trigger event Events generated by components trigger event

pattern connections between their interfaces pattern connections between their interfaces Three types of connections:Three types of connections:

Basic connections (A to B)Basic connections (A to B) Pipe connections (A => B)Pipe connections (A => B) Agent connections (A ||> B)Agent connections (A ||> B)

ComponentsComponents Interface objectsInterface objects Architecture that implements an interfaceArchitecture that implements an interface Module that implements an interfaceModule that implements an interface

ConnectionsConnections Connects “sending interfaces” to “receiving Connects “sending interfaces” to “receiving

interfaces”interfaces” Components communicate through connections by Components communicate through connections by

calling actions or functions in its own interface calling actions or functions in its own interface Events generated by components trigger event Events generated by components trigger event

pattern connections between their interfaces pattern connections between their interfaces Three types of connections:Three types of connections:

Basic connections (A to B)Basic connections (A to B) Pipe connections (A => B)Pipe connections (A => B) Agent connections (A ||> B)Agent connections (A ||> B)

Page 21: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

21 2-Jul-99

Architectural Elements (cont’d)Architectural Elements (cont’d)Architectural Elements (cont’d)Architectural Elements (cont’d)

Constraints - Pattern Constraints - Pattern Bound execution in terms of event patterns Bound execution in terms of event patterns Appear in an interface and/or architecture definitionAppear in an interface and/or architecture definition [label] filter_part constraint_body[label] filter_part constraint_body

Filter creates contextFilter creates context Constraint body constrains computation in contextConstraint body constrains computation in context

Constraints - Sequential Constraints - Sequential Bound execution in terms of boolean expressionsBound execution in terms of boolean expressions Normally appear in module level behaviorNormally appear in module level behavior Applied to parameters, types, objects and statementsApplied to parameters, types, objects and statements

ConfigurationConfiguration The architecture itselfThe architecture itself Supports hierarchical decomposition (I.e nested Supports hierarchical decomposition (I.e nested

architectures)architectures) Contains components, connections, and constraintsContains components, connections, and constraints

Constraints - Pattern Constraints - Pattern Bound execution in terms of event patterns Bound execution in terms of event patterns Appear in an interface and/or architecture definitionAppear in an interface and/or architecture definition [label] filter_part constraint_body[label] filter_part constraint_body

Filter creates contextFilter creates context Constraint body constrains computation in contextConstraint body constrains computation in context

Constraints - Sequential Constraints - Sequential Bound execution in terms of boolean expressionsBound execution in terms of boolean expressions Normally appear in module level behaviorNormally appear in module level behavior Applied to parameters, types, objects and statementsApplied to parameters, types, objects and statements

ConfigurationConfiguration The architecture itselfThe architecture itself Supports hierarchical decomposition (I.e nested Supports hierarchical decomposition (I.e nested

architectures)architectures) Contains components, connections, and constraintsContains components, connections, and constraints

Page 22: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

22 2-Jul-99

Architectural Elements (cont’d)Architectural Elements (cont’d)Architectural Elements (cont’d)Architectural Elements (cont’d)

Componentsprovides part

functionsobjectstypes

in actionsout actions

state

state transitions

pattern constraints

interface with noprivate part

requires part

Componentsaction part

service part

Componentsbehavior part

constraint part

Componentsprivate part

Interface

Page 23: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

23 2-Jul-99

Architectural Elements (cont’d)Architectural Elements (cont’d)Architectural Elements (cont’d)Architectural Elements (cont’d)

Componentscomponents

statements

Module

statements

connections

Componentsinitial part

processes

state transitionsComponentsrule part

constraints

Map

rangedomain

Componentsfinal part

constraints

Componentshandlers

Page 24: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

24 2-Jul-99

A Simple Specification in RapideA Simple Specification in RapideA Simple Specification in RapideA Simple Specification in Rapide

type Producer (Max : Positive) is interfacetype Producer (Max : Positive) is interface action out Send (N: Integer); action out Send (N: Integer); action in Reply(N : Integer); action in Reply(N : Integer);behaviorbehavior Start => send(0);Start => send(0); (?X in Integer) Reply(?X) where ?X<Max => Send(?X+1);(?X in Integer) Reply(?X) where ?X<Max => Send(?X+1);end Producer;end Producer;

type Consumer is interfacetype Consumer is interface action in Receive(N: Integer); action in Receive(N: Integer); action out Ack(N : Integer); action out Ack(N : Integer);behaviorbehavior (?X in Integer) Receive(?X) => Ack(?X);(?X in Integer) Receive(?X) => Ack(?X);end Consumerend Consumer

architecture ProdCon() return SomeType isarchitecture ProdCon() return SomeType is Prod : Producer(100); Cons : Consumer;Prod : Producer(100); Cons : Consumer;connectconnect (?n in Integer) Prod.Send(?n) => Cons.Receive(?n);(?n in Integer) Prod.Send(?n) => Cons.Receive(?n); Cons.Ack(?n) => Prod.Reply(?n); Cons.Ack(?n) => Prod.Reply(?n);end architecture ProdCon;end architecture ProdCon;

type Producer (Max : Positive) is interfacetype Producer (Max : Positive) is interface action out Send (N: Integer); action out Send (N: Integer); action in Reply(N : Integer); action in Reply(N : Integer);behaviorbehavior Start => send(0);Start => send(0); (?X in Integer) Reply(?X) where ?X<Max => Send(?X+1);(?X in Integer) Reply(?X) where ?X<Max => Send(?X+1);end Producer;end Producer;

type Consumer is interfacetype Consumer is interface action in Receive(N: Integer); action in Receive(N: Integer); action out Ack(N : Integer); action out Ack(N : Integer);behaviorbehavior (?X in Integer) Receive(?X) => Ack(?X);(?X in Integer) Receive(?X) => Ack(?X);end Consumerend Consumer

architecture ProdCon() return SomeType isarchitecture ProdCon() return SomeType is Prod : Producer(100); Cons : Consumer;Prod : Producer(100); Cons : Consumer;connectconnect (?n in Integer) Prod.Send(?n) => Cons.Receive(?n);(?n in Integer) Prod.Send(?n) => Cons.Receive(?n); Cons.Ack(?n) => Prod.Reply(?n); Cons.Ack(?n) => Prod.Reply(?n);end architecture ProdCon;end architecture ProdCon;

Page 25: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

25 2-Jul-99

WrightWrightWrightWright

Wright was developed by Dr. David Garlan at CMUWright was developed by Dr. David Garlan at CMU Wright is a general purpose ADL designed with an Wright is a general purpose ADL designed with an

emphasis on analysis of communication protocolsemphasis on analysis of communication protocols Wright uses a variation of CSP to specify the behaviors of Wright uses a variation of CSP to specify the behaviors of

components, connectors, and systemscomponents, connectors, and systems CSP - Communicating Sequential Processes - process CSP - Communicating Sequential Processes - process

algebra developed by C. A. R. Hoarealgebra developed by C. A. R. Hoare Wright as a language focuses primarily on the basic Wright as a language focuses primarily on the basic

component/connector/system paradigmcomponent/connector/system paradigm Wright is very similar syntactically to ACME and AesopWright is very similar syntactically to ACME and Aesop

Wright analysis focuses on analyzing the CSP Wright analysis focuses on analyzing the CSP behavior specifications.behavior specifications.

Any CSP analysis tool or technique could be used to Any CSP analysis tool or technique could be used to analyze the behavior of a Wright specificationanalyze the behavior of a Wright specification

Wright does not currently have a generation Wright does not currently have a generation capabilitycapability

Wright has minimal native tool support (but CSP tools Wright has minimal native tool support (but CSP tools could be used)could be used)

Wright was developed by Dr. David Garlan at CMUWright was developed by Dr. David Garlan at CMU Wright is a general purpose ADL designed with an Wright is a general purpose ADL designed with an

emphasis on analysis of communication protocolsemphasis on analysis of communication protocols Wright uses a variation of CSP to specify the behaviors of Wright uses a variation of CSP to specify the behaviors of

components, connectors, and systemscomponents, connectors, and systems CSP - Communicating Sequential Processes - process CSP - Communicating Sequential Processes - process

algebra developed by C. A. R. Hoarealgebra developed by C. A. R. Hoare Wright as a language focuses primarily on the basic Wright as a language focuses primarily on the basic

component/connector/system paradigmcomponent/connector/system paradigm Wright is very similar syntactically to ACME and AesopWright is very similar syntactically to ACME and Aesop

Wright analysis focuses on analyzing the CSP Wright analysis focuses on analyzing the CSP behavior specifications.behavior specifications.

Any CSP analysis tool or technique could be used to Any CSP analysis tool or technique could be used to analyze the behavior of a Wright specificationanalyze the behavior of a Wright specification

Wright does not currently have a generation Wright does not currently have a generation capabilitycapability

Wright has minimal native tool support (but CSP tools Wright has minimal native tool support (but CSP tools could be used)could be used)

Page 26: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

26 2-Jul-99

A Simple Specification in WrightA Simple Specification in WrightA Simple Specification in WrightA Simple Specification in Wright

System simple_cs System simple_cs Component client = Component client =

port send-request = [behavioral spec] port send-request = [behavioral spec] spec = [behavioral spec]spec = [behavioral spec]

Component server = Component server = port receive-request= [behavioral spec]port receive-request= [behavioral spec]spec = [behavioral spec]spec = [behavioral spec]

Connector rpc = Connector rpc = role caller = (request!x -> result?x ->caller) ^ STOProle caller = (request!x -> result?x ->caller) ^ STOProle callee = (invoke?x -> return!x -> callee) [] STOProle callee = (invoke?x -> return!x -> callee) [] STOPglue = (caller.request?x -> callee.invoke!x glue = (caller.request?x -> callee.invoke!x -> callee.return?x -> callee.result!x -> callee.return?x -> callee.result!x -> glue) [] STOP-> glue) [] STOP

InstancesInstancess : servers : serverc : clientc : clientr : rpcr : rpc

Attachments : Attachments : client.send-request as rpc.caller client.send-request as rpc.caller server.receive-request as rpc.calleeserver.receive-request as rpc.callee

end simple_cs.end simple_cs.

System simple_cs System simple_cs Component client = Component client =

port send-request = [behavioral spec] port send-request = [behavioral spec] spec = [behavioral spec]spec = [behavioral spec]

Component server = Component server = port receive-request= [behavioral spec]port receive-request= [behavioral spec]spec = [behavioral spec]spec = [behavioral spec]

Connector rpc = Connector rpc = role caller = (request!x -> result?x ->caller) ^ STOProle caller = (request!x -> result?x ->caller) ^ STOProle callee = (invoke?x -> return!x -> callee) [] STOProle callee = (invoke?x -> return!x -> callee) [] STOPglue = (caller.request?x -> callee.invoke!x glue = (caller.request?x -> callee.invoke!x -> callee.return?x -> callee.result!x -> callee.return?x -> callee.result!x -> glue) [] STOP-> glue) [] STOP

InstancesInstancess : servers : serverc : clientc : clientr : rpcr : rpc

Attachments : Attachments : client.send-request as rpc.caller client.send-request as rpc.caller server.receive-request as rpc.calleeserver.receive-request as rpc.callee

end simple_cs.end simple_cs.

Page 27: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

27 2-Jul-99

AesopAesopAesopAesop

Aesop was developed by Dr. David Garlan at CMUAesop was developed by Dr. David Garlan at CMU Aesop is a general purpose ADL emphasizing Aesop is a general purpose ADL emphasizing

architectural stylesarchitectural styles Aesop is also a toolset and a frameworkAesop is also a toolset and a framework

Aesop the ADL is very similar to ACME/WrightAesop the ADL is very similar to ACME/Wright Emphasis on styles reflected in more sophisticated Emphasis on styles reflected in more sophisticated

hierarchical facilities centered around subtyping and hierarchical facilities centered around subtyping and inheritanceinheritance

Wright analysis focuses on analyzing the CSP Wright analysis focuses on analyzing the CSP behavior specifications.behavior specifications. Any CSP analysis tool or technique could be used to Any CSP analysis tool or technique could be used to

analyze the behavior of a Wright specificationanalyze the behavior of a Wright specification Aesop does have limited generation capability for Aesop does have limited generation capability for

some stylessome styles Interchange facilities to and from Aesop via ACME Interchange facilities to and from Aesop via ACME

exist and have been used to make Aesop editing exist and have been used to make Aesop editing tools available to other ADLs, notably Wrighttools available to other ADLs, notably Wright

Aesop was developed by Dr. David Garlan at CMUAesop was developed by Dr. David Garlan at CMU Aesop is a general purpose ADL emphasizing Aesop is a general purpose ADL emphasizing

architectural stylesarchitectural styles Aesop is also a toolset and a frameworkAesop is also a toolset and a framework

Aesop the ADL is very similar to ACME/WrightAesop the ADL is very similar to ACME/Wright Emphasis on styles reflected in more sophisticated Emphasis on styles reflected in more sophisticated

hierarchical facilities centered around subtyping and hierarchical facilities centered around subtyping and inheritanceinheritance

Wright analysis focuses on analyzing the CSP Wright analysis focuses on analyzing the CSP behavior specifications.behavior specifications. Any CSP analysis tool or technique could be used to Any CSP analysis tool or technique could be used to

analyze the behavior of a Wright specificationanalyze the behavior of a Wright specification Aesop does have limited generation capability for Aesop does have limited generation capability for

some stylessome styles Interchange facilities to and from Aesop via ACME Interchange facilities to and from Aesop via ACME

exist and have been used to make Aesop editing exist and have been used to make Aesop editing tools available to other ADLs, notably Wrighttools available to other ADLs, notably Wright

Page 28: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

28 2-Jul-99

UniconUniconUniconUnicon

Unicon was developed by Dr. Mary Shaw at CMUUnicon was developed by Dr. Mary Shaw at CMU Unicon is a general purpose ADL designed with Unicon is a general purpose ADL designed with

an emphasis on generation of connectorsan emphasis on generation of connectors Unicon developed to support treatment of Unicon developed to support treatment of

connectors as first class objects by providing for connectors as first class objects by providing for the generation of systems with explicit connectors the generation of systems with explicit connectors

Unicon as a language focuses primarily on the Unicon as a language focuses primarily on the basic component/connector/system paradigm basic component/connector/system paradigm but with an emphasis on architectural stylesbut with an emphasis on architectural styles Emphasis on styles simplifies generation effortsEmphasis on styles simplifies generation efforts

Unicon has a generation capabilityUnicon has a generation capability

Unicon was developed by Dr. Mary Shaw at CMUUnicon was developed by Dr. Mary Shaw at CMU Unicon is a general purpose ADL designed with Unicon is a general purpose ADL designed with

an emphasis on generation of connectorsan emphasis on generation of connectors Unicon developed to support treatment of Unicon developed to support treatment of

connectors as first class objects by providing for connectors as first class objects by providing for the generation of systems with explicit connectors the generation of systems with explicit connectors

Unicon as a language focuses primarily on the Unicon as a language focuses primarily on the basic component/connector/system paradigm basic component/connector/system paradigm but with an emphasis on architectural stylesbut with an emphasis on architectural styles Emphasis on styles simplifies generation effortsEmphasis on styles simplifies generation efforts

Unicon has a generation capabilityUnicon has a generation capability

Page 29: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

29 2-Jul-99

Others … Others … Others … Others …

MetaH MetaH Developed by Honeywell, a domain specific ADL Developed by Honeywell, a domain specific ADL

aimed at guidance, navigation, and control aimed at guidance, navigation, and control applications with ControlHapplications with ControlH

Sophisticated tool support availableSophisticated tool support available C2 SADL C2 SADL

Developed by Taylor/Medvidovic (UCI), style Developed by Taylor/Medvidovic (UCI), style specific ADL, emphasis on dynamismspecific ADL, emphasis on dynamism

Still in prototype stageStill in prototype stage SADL SADL

Developed by Moriconi and Riemenschneider (SRI), Developed by Moriconi and Riemenschneider (SRI), emphasis on refinement mappingsemphasis on refinement mappings

MetaH MetaH Developed by Honeywell, a domain specific ADL Developed by Honeywell, a domain specific ADL

aimed at guidance, navigation, and control aimed at guidance, navigation, and control applications with ControlHapplications with ControlH

Sophisticated tool support availableSophisticated tool support available C2 SADL C2 SADL

Developed by Taylor/Medvidovic (UCI), style Developed by Taylor/Medvidovic (UCI), style specific ADL, emphasis on dynamismspecific ADL, emphasis on dynamism

Still in prototype stageStill in prototype stage SADL SADL

Developed by Moriconi and Riemenschneider (SRI), Developed by Moriconi and Riemenschneider (SRI), emphasis on refinement mappingsemphasis on refinement mappings

Page 30: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

30 2-Jul-99

UML as an ADLUML as an ADLUML as an ADLUML as an ADL

The PositiveThe Positive lowers entry barrier, mainstreams modeling, toolslowers entry barrier, mainstreams modeling, tools

Shortcomings of UML as an ADLShortcomings of UML as an ADL Weakly integrated models with inadequate Weakly integrated models with inadequate

semantics for (automated) analysissemantics for (automated) analysis Connectors are not first class objectsConnectors are not first class objects Visual notation with little generation support, Visual notation with little generation support,

hidden and ambiguous relationships between hidden and ambiguous relationships between views, both too much and too littleviews, both too much and too little

The PositiveThe Positive lowers entry barrier, mainstreams modeling, toolslowers entry barrier, mainstreams modeling, tools

Shortcomings of UML as an ADLShortcomings of UML as an ADL Weakly integrated models with inadequate Weakly integrated models with inadequate

semantics for (automated) analysissemantics for (automated) analysis Connectors are not first class objectsConnectors are not first class objects Visual notation with little generation support, Visual notation with little generation support,

hidden and ambiguous relationships between hidden and ambiguous relationships between views, both too much and too littleviews, both too much and too little

Page 31: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

31 2-Jul-99

Approaches to ArchitectureApproaches to ArchitectureApproaches to ArchitectureApproaches to Architecture

Academic Approach

focus on analytic focus on analytic evaluation of evaluation of architectural modelsarchitectural models

individual modelsindividual models

rigorous modeling rigorous modeling notationsnotations

powerful analysis powerful analysis techniquestechniques

depth over breadthdepth over breadth

special-purpose special-purpose solutionssolutions

Academic Approach

focus on analytic focus on analytic evaluation of evaluation of architectural modelsarchitectural models

individual modelsindividual models

rigorous modeling rigorous modeling notationsnotations

powerful analysis powerful analysis techniquestechniques

depth over breadthdepth over breadth

special-purpose special-purpose solutionssolutions

Industrial Approach

focus on wide range of focus on wide range of development issuesdevelopment issues

families of modelsfamilies of models

practicality over rigorpracticality over rigor

architecture as the “big architecture as the “big picture” in developmentpicture” in development

breadth over depthbreadth over depth

general-purpose general-purpose solutionssolutions

Industrial Approach

focus on wide range of focus on wide range of development issuesdevelopment issues

families of modelsfamilies of models

practicality over rigorpracticality over rigor

architecture as the “big architecture as the “big picture” in developmentpicture” in development

breadth over depthbreadth over depth

general-purpose general-purpose solutionssolutions

Source: N. Medvidovic, USCSource: N. Medvidovic, USC

MCC’s roleMCC’s role

Page 32: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

32 2-Jul-99

ConclusionsConclusionsConclusionsConclusions

There is a rich body of research to draw uponThere is a rich body of research to draw upon Much has been learned about representing and Much has been learned about representing and

analyzing architecturesanalyzing architectures Effort is needed now to bring together the Effort is needed now to bring together the

common knowledge and put it into practicecommon knowledge and put it into practice

There is a rich body of research to draw uponThere is a rich body of research to draw upon Much has been learned about representing and Much has been learned about representing and

analyzing architecturesanalyzing architectures Effort is needed now to bring together the Effort is needed now to bring together the

common knowledge and put it into practicecommon knowledge and put it into practice

Page 33: Architecture Description Languages: An Overview Architecture Description Languages: An Overview Architecture Definition ADLs Architecture vs. Design ADLs

Microelectronics and

Computer Technology Corporation

33 2-Jul-99

For More InformationFor More InformationFor More InformationFor More Information

ACME: ACME: http://www.cs.cmu.edu/~acme Rapide:Rapide: http://pavg.stanford.edu/rapide/ Wright:Wright:

http://www.cs.cmu.edu/afs/cs/project/able/www/wright/index.html

Aesop:Aesop: http://www.cs.cmu.edu/afs/cs/project/able/www/aesop/aesop_home.html

Unicon: Unicon: http://www.cs.cmu.edu/afs/cs/project/vit/www/unicon/index.html

C2 SADL:C2 SADL: http://www.ics.uci.edu/pub/arch/ SSEP: SSEP: http://www.mcc.com/projects/ssepp ADML: ADML: http://www.mcc.com/projects/ssepp/adml

A possibly more current version of this presentation A possibly more current version of this presentation can be found at: can be found at: http://www.mcc.com/projects/ssepp/adml/tog