© 1999 Microelectronics and Computer Technology Corporation – All Rights Reserved

Architecture Description Languages: An Overview

Architecture DefinitionADLsArchitecture vs. DesignADLs Consideredu ACMEu Rapideu Wrightu Aesopu Uniconu UML

ApproachesConclusion

Tw Cook+1-512-338-3522

tw@mcc.com

Tw Cook+1-512-338-3522

tw@mcc.com

221-Oct-99

Architecture Architecture –– A DefinitionA Definition

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

–– from from Software Architecture in PracticeSoftware Architecture in Practice,,Bass, Clements, and Bass, Clements, and KazmanKazman

321-Oct-99

Architecture Description LanguagesArchitecture Description Languages

nn The positivesThe positivesuu ADLs represent a formal way of representing architectureADLs represent a formal way of representing architectureuu ADLs are intended to be both human and machine readableADLs are intended to be both human and machine readableuu ADLs support describing a system at a higher level than ADLs support describing a system at a higher level than

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

consistency, ambiguity, and performanceconsistency, ambiguity, and performanceuu ADLs can support automatic generation of software systemsADLs can support automatic generation of software systems

nn The negativesThe negativesuu 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

uu Representations currently in use are relatively difficult to parRepresentations currently in use are relatively difficult to parse se and are not supported by commercial toolsand are not supported by commercial tools

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

uu 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

421-Oct-99

Architecture vs. DesignArchitecture vs. Design

non-functional requirements

(“ilities”)

functional requirements

(domains)

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

Architecture:Architecture: where nonwhere non--functional decisions are cast, and functional decisions are cast, and functional requirements are partitionedfunctional requirements are partitionedDesign:Design: where functional requirements are accomplishedwhere functional requirements are accomplished

architecturearchitecture(ADL)(ADL)

designdesign(UML)(UML)

521-Oct-99

PositiveEffects

PositiveEffects

NegativeEffects

NegativeEffects

Quality Attributes and Architectural StrategiesQuality Attributes and Architectural Strategies

nn DependabilityDependability

nn InteroperabilityInteroperability

nn UsabilityUsability

nn PerformancePerformance

nn AdaptabilityAdaptability

nn Cost Cost

nn ScheduleSchedule

nn Assurance monitoring & Assurance monitoring & controlcontrol

nn LayeringLayeringnn DiagnosticsDiagnosticsnn PipeliningPipeliningnn Architecture balanceArchitecture balancenn ParallelismParallelismnn GUIGUI--drivendrivennn APIAPI--drivendrivennn Performance monitoring & Performance monitoring &

controlcontrolnn ChangeChange--source hidingsource hidingnn COTS/reuseCOTS/reuse--drivendriven

621-Oct-99

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

nn Configuration consists of the interfaces and connections of Configuration consists of the interfaces and connections of an objectan object--oriented systemoriented system

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

nn Connections represented by interfaces together with call Connections represented by interfaces together with call graphgraph

nn Conformance usually enforced by the programming languageConformance usually enforced by the programming languageuu decomposition decomposition -- associating interfaces with unique modulesassociating interfaces with unique modulesuu Interface conformance Interface conformance -- static checking of syntactic rulesstatic checking of syntactic rulesuu communication integrity communication integrity -- visibility between modulesvisibility between modules

721-Oct-99

An Object Connection ArchitectureAn Object Connection Architecture

821-Oct-99

Object Connection ArchitectureObject Connection Architecture

nn The good newsThe good newsuu Mature development languages Mature development languages -- C++,C++, AdaAda, Java, Javauu Visual modeling and automatic code generation toolsVisual modeling and automatic code generation toolsuu Standardized modeling language Standardized modeling language -- UMLUML

nn The bad newsThe bad newsuu Modules must be built before the architecture is definedModules must be built before the architecture is defineduu Architecture not invariant under changes to system Architecture not invariant under changes to system uu Conformance of a system to an architecture is minimalConformance of a system to an architecture is minimaluu Can not be used to plan a systemCan not be used to plan a system

nn Really not an architecture at all!Really not an architecture at all!uu “The software architecture of a program or computing system “The software architecture of a program or computing system

is the structure or structures of the system, which comprise is the structure or structures of the system, which comprise software components, the software components, the externally visible propertiesexternally visible properties of those of those components, and the components, and the relationships among themrelationships among them.”.”

921-Oct-99

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

nn Expands the role of interfaces and connectionsExpands the role of interfaces and connectionsuu Interfaces specify both “required” and “provided” featuresInterfaces specify both “required” and “provided” featuresuu Connections are defined between “required” features and Connections are defined between “required” features and

“provided” features“provided” features

nn Consists of interfaces, connections and constraintsConsists of interfaces, connections and constraintsuu Constraints restrict behavior of interfaces and connections in Constraints restrict behavior of interfaces and connections in

an architecturean architectureuu Constraints in an architecture map to requirements for a Constraints in an architecture map to requirements for a

system system

1021-Oct-99

An Interface Connection ArchitectureAn Interface Connection Architecture

modulemodule

interfaceinterface

connectionconnection

providesprovides requiresrequires

1121-Oct-99

Interface Connection ArchitectureInterface Connection Architecture

nn The Good newsThe Good newsuu Improved conformance of a system to an architectureImproved conformance of a system to an architectureuu Architecture can be built before modules are implementedArchitecture can be built before modules are implemented

nn The bad newsThe bad newsuu No emerging standardNo emerging standarduu Poor quality toolsPoor quality tools

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

1221-Oct-99

Software Architecture: ADL PerspectiveSoftware Architecture: ADL Perspective

nn The ADL community generally agrees that Software The ADL community generally agrees that Software Architecture is a set of components and the connections Architecture is a set of components and the connections among them.among them.uu componentscomponentsuu connectorsconnectorsuu configurationsconfigurationsuu constraintsconstraints

1321-Oct-99

ADLs Considered by MCCADLs Considered by MCC

nn Leading candidatesLeading candidatesuu ACME (CMU/USC)ACME (CMU/USC)uu Rapide Rapide (Stanford)(Stanford)uu Wright (CMU)Wright (CMU)uu Unicon Unicon (CMU)(CMU)

nn Secondary candidatesSecondary candidatesuu Aesop Aesop (CMU)(CMU)uu MetaH MetaH (Honeywell)(Honeywell)uu C2 SADL (UCI)C2 SADL (UCI)uu SADL (SRI)SADL (SRI)

nn OthersOthersuu LileannaLileannauu UMLUMLuu ModechartModechart

1421-Oct-99

ACMEACME

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

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

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

nn ACME has no native behavioral specification facility so only ACME has no native behavioral specification facility so only syntactic linguistic analysis is possiblesyntactic linguistic analysis is possibleuu there are currently efforts under consideration to define a there are currently efforts under consideration to define a

behavioral semantics for ACME, possibly along the behavioral semantics for ACME, possibly along the Wright/CSP lineWright/CSP line

nn ACME has no native generation capability ACME has no native generation capability nn ACME has seen some native tool development, and there are ACME has seen some native tool development, and there are

indications of more, as well as use of other language tools indications of more, as well as use of other language tools via interchangevia interchange

1521-Oct-99

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

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

server.receive-request to rpc.callee}}

System simple_System simple_cscs = {= {Component client = {Port sendComponent client = {Port send--request}request}Component server = {Port receiveComponent server = {Port receive--request}request}ConnectorConnector rpcrpc = {Roles {caller,= {Roles {caller, calleecallee}}}}Attachments : {client.sendAttachments : {client.send--request torequest to rpcrpc.caller;.caller;

server.receiveserver.receive--request to request to rpcrpc..calleecallee}}}}

client

send-request

server

receive-requestcaller callee

rpc

1621-Oct-99

RapideRapide

nn Rapide was developed by Dr. David Luckham at StanfordRapide was developed by Dr. David Luckham at Stanfordnn Rapide is a general purpose ADL designed with an emphasis Rapide is a general purpose ADL designed with an emphasis

on simulation yielding partially ordered sets of events on simulation yielding partially ordered sets of events (posets)(posets)

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

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

allowed/prohibited behaviorsallowed/prohibited behaviorsuu some support for timing analysissome support for timing analysisuu focus on causalityfocus on causality

nn Rapide has some generation capability since Rapide Rapide has some generation capability since Rapide specifications are executablespecifications are executable

nn Rapide has a fairly extensive toolsetRapide has a fairly extensive toolset

1721-Oct-99

The Rapide ModelThe Rapide Model

nn Rapide is a concurrent, objectRapide is a concurrent, object--oriented , eventoriented , event--based based simulation languagesimulation language

nn Defines and simulates behavior of distributed object system Defines and simulates behavior of distributed object system architecturesarchitectures

nn Produces a simulation represented by a set of events (Produces a simulation represented by a set of events (posetposet))uu Events are ordered with respect to time and causalityEvents are ordered with respect to time and causality

nn System requirements are expressed as constraints on time System requirements are expressed as constraints on time and concurrent patterns of eventsand concurrent patterns of events

nn PosetsPosets enable visualization and analysis of an executionenable visualization and analysis of an execution

1821-Oct-99

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

nn Components execute independentlyComponents execute independently

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

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

nn Generates timed eventsGenerates timed eventsuu Interface behavior or module can be timedInterface behavior or module can be timeduu Events receive start and finish times within scope of its clockEvents receive start and finish times within scope of its clockuu Events can be synchronized to a clockEvents can be synchronized to a clock

1921-Oct-99

RapideRapide Architectural ElementsArchitectural Elements

ComponentsComponentscomponentscomponents

connectionsconnections

constraintsconstraints

ComponentsComponentsinterfaceinterface

interfaceinterface

architecturearchitecture

interfaceinterface

modulemodule

ArchitectureArchitecture

ComponentComponent

2021-Oct-99

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

nn ComponentsComponentsuu Interface objectsInterface objectsuu Architecture that implements an interfaceArchitecture that implements an interfaceuu Module that implements an interfaceModule that implements an interface

nn ConnectionsConnectionsuu Connects “sending interfaces” to “receiving interfaces”Connects “sending interfaces” to “receiving interfaces”uu Components communicate through connections by calling Components communicate through connections by calling

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

connections between their interfaces connections between their interfaces uu 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)

2121-Oct-99

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

nn Constraints Constraints -- Pattern Pattern uu Bound execution in terms of event patterns Bound execution in terms of event patterns uu Appear in an interface and/or architecture definitionAppear in an interface and/or architecture definitionuu [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

nn Constraints Constraints -- Sequential Sequential uu Bound execution in terms of Bound execution in terms of booleanboolean expressionsexpressionsuu Normally appear in module level behaviorNormally appear in module level behavioruu Applied to parameters, types, objects and statementsApplied to parameters, types, objects and statements

nn ConfigurationConfigurationuu The architecture itselfThe architecture itselfuu Supports hierarchical decomposition (I.e nested architectures)Supports hierarchical decomposition (I.e nested architectures)uu Contains components, connections, and constraintsContains components, connections, and constraints

2221-Oct-99

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

ComponentsComponentsprovides partprovides partfunctionsfunctionsobjectsobjectstypestypes

in actionsin actionsout actionsout actions

statestate

state transitionsstate transitions

pattern constraintspattern constraints

interface with nointerface with noprivate partprivate part

requires partrequires part

ComponentsComponentsaction partaction part

service partservice part

ComponentsComponentsbehavior partbehavior part

constraint partconstraint part

ComponentsComponentsprivate partprivate part

InterfaceInterface

2321-Oct-99

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

ComponentsComponentscomponentscomponents

statementsstatements

ModuleModule

statementsstatements

connectionsconnections

ComponentsComponentsinitial partinitial part

processesprocesses

state transitionsstate transitionsComponentsComponentsrule partrule part

constraintsconstraints

MapMap

rangerangedomaindomain

ComponentsComponentsfinal partfinal part

constraintsconstraints

ComponentsComponentshandlershandlers

2421-Oct-99

A Simple Specification in A Simple Specification in RapideRapide

type Producer (Max : Positive) is interfaceaction out Send (N: Integer); action in Reply(N : Integer);

behaviorStart => send(0);(?X in Integer) Reply(?X) where ?X<Max => Send(?X+1);

end Producer;

type Consumer is interfaceaction in Receive(N: Integer); action out Ack(N : Integer);

behavior(?X in Integer) Receive(?X) => Ack(?X);

end Consumer

architecture ProdCon() return SomeType isProd : Producer(100); Cons : Consumer;

connect(?n in Integer) Prod.Send(?n) => Cons.Receive(?n);Cons.Ack(?n) => Prod.Reply(?n);

end architecture ProdCon;

type Producer (Max : Positive) is interfacetype Producer (Max : Positive) is interfaceaction out Send (N: Integer); action out Send (N: Integer); action in Reply(N : Integer);action in Reply(N : Integer);

behaviorbehaviorStart => 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 interfaceaction in Receive(N: Integer); action in Receive(N: Integer); action outaction out AckAck(N : Integer);(N : Integer);

behaviorbehavior(?X in Integer) Receive(?X) =>(?X in Integer) Receive(?X) => AckAck(?X);(?X);

end Consumerend Consumer

architecturearchitecture ProdConProdCon() return() return SomeTypeSomeType isisProd : 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.Cons.AckAck(?n) => Prod.Reply(?n);(?n) => Prod.Reply(?n);

end architectureend architecture ProdConProdCon;;

2521-Oct-99

WrightWright

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

on analysis of communication protocolson analysis of communication protocolsuu 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 CSP -- Communicating Sequential Processes Communicating Sequential Processes -- process algebra process algebra

developed by C. A. R. Hoaredeveloped by C. A. R. Hoare

nn Wright as a language focuses primarily on the basic Wright as a language focuses primarily on the basic component/connector/system paradigmcomponent/connector/system paradigmuu Wright is very similar syntactically to ACME and AesopWright is very similar syntactically to ACME and Aesop

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

the behavior of a Wright specificationthe behavior of a Wright specificationnn Wright does not currently have a generation capabilityWright does not currently have a generation capabilitynn Wright has minimal native tool support (but CSP tools could Wright has minimal native tool support (but CSP tools could

be used)be used)

2621-Oct-99

A Simple Specification in WrightA Simple Specification in Wright

System simple_cs Component client =

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

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

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

-> callee.return?x -> callee.result!x -> glue) [] STOP

Instancess : serverc : clientr : rpc

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

end simple_cs.

System simple_cs System simple_cs Component client = Component client =

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

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

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

--> callee.return?x > callee.return?x --> callee.result!x > callee.result!x --> glue) [] STOP> glue) [] STOP

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

Attachments : Attachments : client.sendclient.send--request as rpc.caller request as rpc.caller server.receiveserver.receive--request as rpc.calleerequest as rpc.callee

end simple_cs.end simple_cs.

2721-Oct-99

AesopAesop

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

stylesstylesuu Aesop is also a toolset and a frameworkAesop is also a toolset and a framework

nn Aesop the ADL is very similar to ACME/WrightAesop the ADL is very similar to ACME/Wrightuu 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

nn AesopAesop does have limited generation capability for some does have limited generation capability for some stylesstyles

nn Interchange facilities to and from Aesop via ACME exist and Interchange facilities to and from Aesop via ACME exist and have been used to make Aesop editing tools available to have been used to make Aesop editing tools available to other ADLs, notably Wrightother ADLs, notably Wright

2821-Oct-99

UniconUnicon

nn Unicon was developed by Dr. Mary Shaw at CMUUnicon was developed by Dr. Mary Shaw at CMUnn Unicon is a general purpose ADL designed with an emphasis Unicon is a general purpose ADL designed with an emphasis

on generation of connectorson generation of connectorsuu Unicon developed to support treatment of connectors as first Unicon developed to support treatment of connectors as first

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

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

nn Unicon has a generation capabilityUnicon has a generation capability

2921-Oct-99

Others … Others …

nn MetaH MetaH uu Developed by Honeywell, a domain specific ADL aimed at Developed by Honeywell, a domain specific ADL aimed at

guidance, navigation, and control applications with ControlHguidance, navigation, and control applications with ControlHuu Sophisticated tool support availableSophisticated tool support available

nn C2 SADL C2 SADL uu Developed by Taylor/Medvidovic (UCI), style specific ADL, Developed by Taylor/Medvidovic (UCI), style specific ADL,

emphasis on dynamismemphasis on dynamismuu Still in prototype stageStill in prototype stage

nn SADL SADL uu Developed by Moriconi and Riemenschneider (SRI), emphasis Developed by Moriconi and Riemenschneider (SRI), emphasis

on refinement mappingson refinement mappings

3021-Oct-99

UML as an ADLUML as an ADL

nn The PositiveThe Positiveuu lowers entry barrier, mainstreams modeling, toolslowers entry barrier, mainstreams modeling, tools

nn Shortcomings of UML as an ADLShortcomings of UML as an ADLuu Encourages an Encourages an object connection architectureobject connection architecture rather than rather than

interface connection architectureinterface connection architectureuu Weakly integrated models with inadequate semantics for Weakly integrated models with inadequate semantics for

(automated) analysis(automated) analysisuu Connectors are not first class objectsConnectors are not first class objectsuu Visual notation with little generation support, hidden and Visual notation with little generation support, hidden and

ambiguous relationships between views, both too much and ambiguous relationships between views, both too much and too littletoo little

3121-Oct-99

Approaches to ArchitectureApproaches to Architecture

Academic Approach

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

nn individual modelsindividual models

nn rigorous modeling notationsrigorous modeling notations

nn powerful analysis techniquespowerful analysis techniques

nn depth over breadthdepth over breadth

nn specialspecial--purpose solutionspurpose solutions

Industrial Approach

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

nn families of modelsfamilies of models

nn practicality over rigorpracticality over rigor

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

nn breadth over depthbreadth over depth

nn generalgeneral--purpose solutionspurpose solutions

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

MCC’s roleMCC’s role

3221-Oct-99

Approaches to ArchitectureApproaches to Architecture

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

generalgeneral--purpose solutionspurpose solutionsspecialspecial--purpose solutionspurpose solutions

breadth over depthbreadth over depthdepth over breadthdepth over breadth

architecture as the “big picture” in architecture as the “big picture” in developmentdevelopment

powerful analysis techniquespowerful analysis techniques

practicality over rigorpracticality over rigorrigorous modeling notationsrigorous modeling notations

families of modelsfamilies of modelsindividual modelsindividual models

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

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

Industrial ApproachAcademic ApproachMCC’s roleMCC’s role

3321-Oct-99

ConclusionsConclusions

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

architecturesarchitecturesnn Effort is needed now to bring together the common Effort is needed now to bring together the common

knowledge and put it into practiceknowledge and put it into practice

3421-Oct-99

For More InformationFor More Information

nn ACME: ACME: http://www.cs.cmu.edu/~acmenn RapideRapide:: http://pavg.stanford.edu/rapide/nn Wright:Wright: http://www.cs.cmu.edu/afs/cs/project/able/www/wright/index.htmlnn AesopAesop::

http://www.cs.cmu.edu/afs/cs/project/able/www/aesop/aesop_home.htmlnn UniconUnicon: : http://www.cs.cmu.edu/afs/cs/project/vit/www/unicon/index.htmlnn C2 SADL:C2 SADL: http://www.ics.uci.edu/pub/arch/nn SSEP: SSEP: http://www.mcc.com/projects/sseppnn ADML: ADML: http://www.mcc.com/projects/ssepp/adml

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