1 of 24

A Classification and Comparison Framework forSoftware Architecture Description Languages

Nenad Medvidovic and Richard N. Taylor

Abstract—Software architectures shift the focus of developers from lines-of-code to coarser-grained architectural elements and theiroverall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support archi-tecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architec-ture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, thedistinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation, and programminglanguages on the other. This paper attempts to provide an answer to these questions. It motivates and presents a definition and a classifica-tion framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations.The framework is used to classify and compare several existing ADLs, enabling us in the process to identify key properties of ADLs. Thecomparison highlights areas where existing ADLs provide extensive support and those in which they are deficient, suggesting a researchagenda for the future.

Index Terms—Software architecture, architecture description language, component, connector, configuration, definition, classification,comparison.

1 INTRODUCTION

Software architecture research is directed at reducing costs ofdeveloping applications and increasing the potential for common-ality between different members of a closely related product fam-ily [54], [66]. Software development based on commonarchitectural idioms has its focus shifted from lines-of-code tocoarser-grained architectural elements (software components andconnectors) and their overall interconnection structure. To sup-port architecture-based development, formal modeling notationsand analysis and development tools that operate on architecturalspecifications are needed. Architecture description languages(ADLs) and their accompanying toolsets have been proposed asthe answer. Loosely defined, “an ADL for software applicationsfocuses on the high-level structure of the overall applicationrather than the implementation details of any specific source mod-ule” [71]. ADLs have recently become an area of intense researchin the software architecture community [11], [16], [73], [37].

A number of ADLs have been proposed for modeling architec-tures both within a particular domain and as general-purposearchitecture modeling languages. In this paper, we specificallyconsider those languages most commonly referred to as ADLs:Aesop [14], [12], ArTek [69], C2 [39], [42], Darwin [35], [36],LILEANNA [70], MetaH [6], [72], Rapide [31], [32], SADL[46], [47], UniCon [62], [63], Weaves [20], [21], and Wright [2],

[4].1 Recently, initial work has been done on an architecture inter-change language, ACME [15], which is intended to support map-ping of architectural specifications from one ADL to another, andhence enable integration of support tools across ADLs. Although,strictly speaking, ACME is not an ADL, it contains a number ofADL-like features. Furthermore, it is useful to compare and dif-ferentiate it from other ADLs to highlight the difference betweenan ADL and an interchange language. It is therefore included inthis paper.

There is, however, still little consensus in the research commu-nity on what an ADL is, what aspects of an architecture should bemodeled by an ADL, and what should be interchanged in an inter-change language [43]. For example, Rapide may be characterizedas a general-purpose system description language that allowsmodeling of component interfaces and their externally visiblebehavior, while Wright formalizes the semantics of architecturalconnections. Furthermore, the distinction is rarely made betweenADLs on one hand and formal specification, module interconnec-tion (MIL), simulation, and programming languages on the other.Indeed, for example, Rapide can be viewed as both an ADL and asimulation language, while Clements contends that CODE [49], aparallel programming language, is also an ADL [8].

Another source of discord is the level of support an ADLshould provide to developers. At one end of the spectrum, it canbe argued that the primary role of architectural descriptions is toaid understanding and communication about a software system.As such, an ADL must have simple, understandable, and possiblygraphical syntax, well understood, but not necessarily formallydefined semantics, and the kinds of tools that aid visualization,understanding, and simple analyses of architectural descriptions(e.g., Argo [59]). At the other end of the spectrum, the tendency

1. The full name of the ADL for modeling architectures in the C2 architecturalstyle is “C2SADEL.” To distinguish it from SADL, which resulted from an unre-lated project,C2SADEL will be referred to simply as “C2” in this paper.

• N. Medvidovic is with the University of Southern California.Email: neno@usc.edu.

• R.N. Taylor is with the University of California, Irvine. E-mail: taylor@ics.uci.edu.

2 of 24

has been to provide formal syntax and semantics of ADLs, pow-erful analysis tools, model checkers, parsers, compilers, codesynthesis tools, runtime support tools, and so on (e.g., SADL’sarchitecture refinement patterns [47], Darwin’s use ofπ-calculusto formalize architectural semantics [36], or UniCon’s parser andcompiler [62]). While both perspectives have merit, ADLresearchers have generally adopted one or the other extremeview. It is our contention that both are important and should bereflected in an ADL.

Several researchers have attempted to shed light on theseissues, either by surveying what they consider existing ADLs [8],[27], [28], [71] or by listing “essential requirements” for an ADL[32], [62], [64], [65]. In our previous work we attempted tounderstand and compare ADLs based on problem areas withinsoftware architectures for which they are suited [40]. Each ofthese attempts furthers our understanding of what an ADL is;however, for various reasons, each ultimately falls short in pro-viding a definitive answer to the question.

This paper builds upon the results of these efforts. It is furtherinfluenced by insights obtained from studying individual ADLs,relevant elements of languages commonly not considered ADLs(e.g., programming languages), and experiences and needs of anongoing research project, C2. The paper presents a definition anda relatively concise classification framework for ADLs: an ADLmust explicitly modelcomponents, connectors, and theirconfigu-rations; furthermore, to be truly usable and useful, it must pro-vide tool support for architecture-based development andevolution. These four elements of an ADL are further brokendown into constituent parts.

The remainder of the paper is organized as follows. Section 2discusses contributions and shortcomings of other attempts atsurveying and classifying ADLs. Section 3 defines our taxonomyof ADLs and demonstrates its utility by determining whether sev-eral existing notations are ADLs. Section 4 assesses the above-mentioned ADLs based on the criteria established in Section 3.Discussion and conclusions round out the paper.

2 RELATED APPROACHES

Any effort such as this one is based on discoveries and conclu-sions of other researchers. We closely examined ADL surveysconducted by Clements and Kogut [8], [27], [28] and Vestal [71].We also studied several researchers’ attempts at identifyingessential ADL characteristics and requirements: Luckham andVera [32], Shaw and colleagues [62], Shaw and Garlan [64], [65],and Tracz [74]. As a basis for architectural interchange, ACME[15] gave us key insights into what needs to remain constantacross ADLs. Finally, we built upon our conclusions from earlierattempts to shed light on the nature and needs of architecturemodeling [40], [42].

2.1 Previous Surveys

Clements and Kogut [8], [27], [28] provide an extensive classi-fication of existing ADLs. The classification is based on anexhaustive questionnaire of ADL characteristics and features,completed by each language’s design team. The survey was con-ducted in a top-down fashion: the authors used domain analysis

techniques to decide what features an ADL should have and thenassessed existing languages with respect to those features.

While their taxonomy is valuable in bettering our understand-ing of surveyed ADLs, it comes up short in several respects.Domain analysis is typically used in well-understood domains,which is not the case with ADLs. The survey does not provideany deeper insight into what an ADL is, nor does it present itscriteria for including a particular modeling notation. Quite thecontrary, several surveyed languages are not commonly consid-ered ADLs, yet little justification is given for their inclusion. Per-haps most illustrative is the example of Modechart, aspecification language for hard-real-time computer systems [26].Clements labels Modechart “a language on the edge of ADLs,”whose utility to the architecture community lies in its sophisti-cated analysis and model checking toolset [7]. Tool support aloneis not a sufficient reason to consider it an ADL however.

Several of the criteria Kogut and Clements used for ADL eval-uation, such as the ability to model requirements and algorithms,are outside an ADL’s scope.2 This kind of survey also runs therisk of not asking all of the relevant questions. Finally, theauthors often have to extrapolate very specific information frommultiple, potentially subjective, vague, or misunderstood ques-tions.

Vestal’s approach [71] is more bottom-up. He surveyed fourexisting ADLs (LILEANNA, MetaH, Rapide, and QAD [22])and attempted to identify their common properties. He concludedthat they all model or support the following concepts to somedegree:

• components,• connections,• hierarchical composition, where one component contains an

entire subarchitecture,• computation paradigms, i.e., semantics, constraints, and non-

functional properties,• communication paradigms,• underlying formal models,• tool support for modeling, analysis, evaluation, and verifica-

tion, and• automatic application code composition.

Although “cursory” (as he qualifies it) and limited in its scope,Vestal’s survey contains useful insights that bring us closer toanswering the question of what an ADL is. In its approach, oursurvey is closer to Vestal’s than to Clements and Kogut’s.

In our previous work [40], we attempted to identify the prob-lems or areas of concern that need to be addressed by ADLs:

• representation,• design process support,• static and dynamic analysis,• specification-time and execution-time evolution,• refinement,• traceability, and• simulation/executability.

Understanding these areas and their properties is a key to betterunderstanding the needs of software architectures, architecture-

2. A discussion of the scope of software architectures, and therefore ADLs, isgiven by Perry and Wolf [54]. Their conclusions are largely mirrored in the defini-tion of architectures given by Shaw and Garlan [66].

3 of 24

based development, and architectural description and inter-change; a study of these areas is also needed to guide the devel-opment of next-generation ADLs. We demonstrated that eachexisting ADL currently supports only a small subset of thesedomains, and discussed possible reasons for that.

While we believe that this taxonomy gives the architect asound foundation for selecting an ADL and orients discoursetowards problem solving, it is still very much a preliminary con-tribution. Furthermore, our comparison of ADLs based on thesecategories did not reveal what specific characteristics and con-structs render an ADL well suited for solving a particular set ofproblems or whether certain constructs are complementary ormutually exclusive. Consequently, we believe that a feature-based classification and comparison of ADLs is also needed.

2.2 Insights from Individual Systems

In [32], Luckham and Vera list requirements for an ADL,based on their work on Rapide:

• component abstraction,• communication abstraction,• communication integrity, which mandates that only compo-

nents that are connected in an architecture may communicatein the resulting implementation,

• ability to model dynamic architectures,• hierarchical composition, and• relativity, or the ability to relate (map) behaviors between

architectures.As a result of their experience with UniCon, Shaw and col-

leagues list the following properties an ADL should exhibit [62]:• ability to model components, with property assertions, inter-

faces, and implementations,• ability to model connectors, with protocols, property asser-

tions and implementations,• abstraction and encapsulation,• types and type checking, and• ability to accommodate analysis tools.Clearly, the above features alone cannot be considered defini-

tive indicators of how to identify an ADL. They have resultedfrom limited experience of two research groups with their ownlanguages. However, they represent valuable data points in tryingto understand and classify ADLs.

2.3 Attempts at Identifying Underlying Concepts

In [74], Tracz defines an ADL as consisting of four “C”s: com-ponents, connectors, configurations, and constraints. This taxon-omy is appealing, especially in its simplicity, but needs furtherelaboration: justification for and definitions of the four “C”s,aspects of each that need to be modeled, necessary tool support,and so on. Tracz’s taxonomy is similar to Perry and Wolf’s origi-nal model of software architectures, which consists of elements,form, and rationale [54]. Perry and Wolf’s elements are Tracz’scomponents and connectors, their form subsumes an architecturalconfiguration, and the rationale is roughly equivalent to con-straints.

Shaw and Garlan have attempted to identify unifying themesand motivate research in ADLs. Both authors have successfully

argued the need to treat connectors explicitly, as first-class enti-ties in an ADL [4], [61], [64]. In [64], they also elaborate sixclasses of properties that an ADL should provide: composition,abstraction, reusability, configuration, heterogeneity, and analy-sis. They demonstrate that other existing notations, such as infor-mal diagrams, modularization facilities provided byprogramming languages, and MILs, do not satisfy the aboveproperties and hence cannot fulfill architecture modeling needs.

In [65], Shaw and Garlan identify seven levels of architecturespecification capability:

• capturing architectural information,• construction of an instance,• composition of multiple instances,• selection among design or implementation alternatives,• verifying adherence of an implementation to specification,• analysis, and• automation.

They conclude that, while ADLs invariably provide notations forcapturing system descriptions (level 1), few support other levels.It is unclear, however, what set of criteria they applied to the dif-ferent ADLs and how stringent those criteria were, particularlysince this paper will show that a number of ADLs do provide aconsiderable amount of support for most of the above capabili-ties.

Finally, in [43], Medvidovic and colleagues argue that, in orderto adequately support architecture-based development and analy-sis, one must model architectures at four levels of abstraction:internal component semantics, component interfaces, componentinterconnections in an architecture, and architectural style rules.This taxonomy presents an accurate high-level view of architec-ture modeling needs, but is too general to serve as an adequateADL comparison framework. Furthermore, it lacks any focus onconnectors.

2.4 Architecture Interchange

Perhaps the closest the research community has come to a con-sensus on ADLs has been the emerging endorsement by a seg-ment of the community of ACME as an architecture interchangelanguage [15]. In order to meaningfully interchange architecturalspecifications across ADLs, a common basis for all ADLs mustbe established. Garlan and colleagues believe that common basisto be their core ontology for architectural representation:

• components,• connectors,• systems, or configurations of components and connectors,• ports, or points of interaction with a component,• roles, or points of interaction with a connector,• representations, used to model hierarchical compositions,

and• rep-maps, which map a composite component or connector’s

internal architecture to elements of its external interface.

In ACME, any other aspect of architectural description is repre-sented with property lists (i.e., it is not core).

ACME has resulted from a careful consideration of issues inand notations for modeling architectures. As such, it could beviewed as a good starting point for studying existing ADLs anddeveloping new ones. However, ACME represents the least com-

4 of 24

mon denominator of existing ADLs rather than a definition of anADL. It also does not provide any means for understanding orclassifying those features of an architectural description that areplaced in property lists. Finally, certain structural constraintsimposed by ACME (e.g., a connector may not be directlyattached to another connector), satisfy the needs of someapproaches (e.g., Aesop, UniCon, and Wright), but not of others(e.g., C2).

3 ADL CLASSIFICATION AND COMPARISONFRAMEWORK

Individually, none of the above attempts adequately answer thequestion of what an ADLis. Instead, they reflect their authors’views on what an ADLshould haveor should be able to do.However, a closer study of their collections of features andrequirements shows that there is a common theme among them,which is used as a guide in formulating our framework for ADLclassification and comparison. To complete the framework, thecharacteristics of individual ADLs and summaries of discussionson ADLs that occurred at the three International Software Archi-tecture Workshops [11], [73], [37], were studied. To a largedegree, our taxonomy reflects features supported by all, or most,existing ADLs. In certain cases, we also argue for characteristicstypically not supported by current ADLs, but which have eitherbeen identified in the literature as important for architecture-based development or have resulted from our experience with ourown research project in software architectures, C2. Finally, wehave tried to learn from and, where relevant, apply the extensiveexperience with languages for modeling other aspects of softwarein formulating our framework.

To properly enable further discussion, several definitions areneeded. There is no standard, universally accepted definition ofarchitecture, but we will use as our working definition the oneprovided by Shaw and Garlan [66]:

Software architecture [is a level of design that] involvesthe description of elements from which systems are built,interactions among those elements, patterns that guidetheir composition, and constraints on these patterns.

An ADL is thus a language that provides features for modelinga software system’sconceptual architecture, distinguished fromthe system’simplementation. ADLs provide both a concrete syn-tax and a conceptual framework for characterizing architectures[15]. The conceptual framework typically reflects characteristicsof the domain for which the ADL is intended and/or the architec-tural style. The framework typically subsumes the ADL’s under-lying semantic theory (e.g, CSP, Petri nets, finite state machines).

3.1 Framework Categories

We introduce the top-level categories of our ADL classifica-tion and comparison framework in this section. The buildingblocks of an architectural description are (1)components, (2)connectors, and (3)architectural configurations.3 An ADL mustprovide the means for theirexplicit specification; this enables usto determine whether or not a particular notation is an ADL. In

3. “Architectural configurations” will, at various times in this paper, be referredto simply as “configurations” or “topologies.”

order to inferany kind of information about an architecture, at aminimum, interfaces of constituent components must also bemodeled. Without this information, an architectural descriptionbecomes but a collection of (interconnected) identifiers, similarto a “boxes and lines” diagram with no explicit underlyingsemantics. Several other aspects of components, connectors, andconfigurations are desirable, but not essential: their benefits havebeen acknowledged and possibly demonstrated in the context of aproblem domain or a style, but their absence does not mean that agiven language is not an ADL.

Even though the suitability of a given language for modelingsoftware architectures is independent of whether and what kindsof tool support it provides, an accompanying toolset will renderan ADL both more usable and useful. Conversely, the desiredmanipulations of architectural models by tools may influence themodeling features provided in an ADL. A large segment of theADL research community is actively studying the issue of toolsupport; an effort to identify a canonical “ADL toolkit” is cur-rently under way [17].

The ADL classification and comparison framework is depictedin Fig. 1. It is intended to be extensible and modifiable, which iscrucial in a field that is still largely in its infancy. The remainderof this section motivates and further elaborates on each categoryof the framework.

The categories identified in the framework are orthogonal to anADL’s scope of applicability. As a model of a system at a highlevel of abstraction, an ADL is intended (and can only beexpected) to provide apartial depiction of the system. The typesof information on which the ADL focuses may be the characteris-tics of an application domain, a style of system composition (i.e.,an architectural style), or a specific set of properties (e.g., distri-bution, concurrency, safety, and so on). Regardless of the focus

ADLArchitecture Modeling Features

ComponentsInterfaceTypesSemanticsConstraintsEvolutionNon-functional properties

ConnectorsInterfaceTypesSemanticsConstraintsEvolutionNon-functional properties

Architectural ConfigurationsUnderstandabilityCompositionalityRefinement and traceabilityHeterogeneityScalabilityEvolutionDynamismConstraintsNon-functional properties

Tool SupportActive SpecificationMultiple ViewsAnalysisRefinementImplementation GenerationDynamism

Fig. 1. ADL classification and comparison framework. Essentialmodeling features are in bold font.

5 of 24

and nature of the ADL, in general the desired kinds of representa-tion, manipulation, and qualities of architectural modelsdescribed in the ADL, and identified in in Fig. 1, remain constant.

3.1.1 Modeling Components

A component in an architecture is a unit of computation or adata store. Therefore, components are loci of computation andstate [62]. Components may be as small as a single procedure oras large as an entire application. Each component may require itsown data or execution space, or it may share them with othercomponents. As already discussed, explicit componentinterfacesare a feature required of ADLs. Additional comparison featuresare those for modeling componenttypes, semantics, constraints,evolution, and non-functional properties. Each is discussedbelow.

Interface — A component’s interface is a set of interactionpoints between it and the external world. The interface specifiesthe services (messages, operations, and variables) a componentprovides. In order to support reasoning about a component andthe architecture that includes it, ADLs may also provide facilitiesfor specifying component needs, i.e., services required of othercomponents in the architecture. An interface thus defines compu-tational commitments a component can make and constraints onits usage.

Types —Component types are abstractions that encapsulatefunctionality into reusable blocks. A component type can beinstantiated multiple times in a single architecture or it may bereused across architectures. Component types can be parameter-ized, further facilitating reuse. Explicit modeling of types alsoaids understandability and analyzability of an architecture in thatthe properties of a type are shared by all of its instances.

Semantics —We define component semantics as a high-level model of a component’s behavior. Such a model is neededto perform analysis, enforce architectural constraints, and ensureconsistent mappings of architectures from one level of abstrac-tion to another. Note that a component’s interface also allows acertain, limited degree of reasoning about its semantics. How-ever, the notion of semantics used in this paper refers strictly tomodels of component behavior.

Constraints — A constraint is a property of or assertionabout a system or one of its parts, the violation of which will ren-der the system unacceptable (or less desirable) to one or morestakeholders [9]. In order to ensure adherence to intended compo-nent uses, enforce usage boundaries, and establish dependenciesamong internal parts of a component, constraints on them mustbe specified.

Evolution — As architectural building blocks, componentswill continuously evolve. Component evolution can be infor-mally defined as the modification of (a subset of) a component’sproperties, e.g., interface, behavior, or implementation. ADLscan ensure that evolution happens in a systematic manner, byemploying techniques such as subtyping of component types andrefinement of component features.

Non-Functional Properties —A component’s non-func-tional properties (e.g., safety, security, performance, portability)typically cannot be directly derived from the specification of its

behavior. Early specification of such properties (at the architec-tural level) is needed to enable simulation of runtime behavior,perform analysis, enforce constraints, map component imple-mentations to processors, and aid in project management.

3.1.2 Modeling Connectors

Connectors are architectural building blocks used to modelinteractions among components and rules that govern those inter-actions. Unlike components, connectors may not correspond tocompilation units in an implemented system. They may be imple-mented as separately compilable message routing devices, butmay also manifest themselves as shared variables, table entries,buffers, instructions to a linker, dynamic data structures,sequences of procedure calls embedded in code, initializationparameters, client-server protocols, pipes, SQL links between adatabase and an application, and so forth [15], [62]. The featurescharacterizing connectors are theirinterfaces, types, semantics,constraints, evolution, and non-functional properties.4 Each isdefined and motivated below.

Interface — A connector’s interface is a set of interactionpoints between the connector and the components and other con-nectors attached to it. Since a connector does not perform anyapplication-specific computations, it exports as its interface thoseservices it expects of its attached components. Connector inter-faces enable proper connectivity of components and their interac-tion in an architecture and, thereby, reasoning about architecturalconfigurations.

Types —Connector types are abstractions that encapsulatecomponent communication, coordination, and mediation deci-sions. Architecture-level interactions may be characterized bycomplex protocols. Making these protocols reusable both withinand across architectures requires that ADLs model connectors astypes. This is typically done in two ways: asextensible type sys-tems, defined in terms of interaction protocols, or as built-in,enu-merated types, based on particular implementation mechanisms.

Semantics —Similarly to components, connector semanticsis defined as a high-level model of a connector’s behavior. Unlikecomponents, whose semantics express application-level function-ality, connector semantics entail specifications of (computation-independent) interaction protocols. ADLs may support modelingof connector semantics in order to enable component interactionanalysis, consistent refinement of architectures across levels ofabstraction, and enforcement of interconnection and communica-tion constraints.

Constraints — Connector constraints ensure adherence tointended interaction protocols, establish intra-connector depen-dencies, and enforce usage boundaries. An example of a simpleand easily enforceable constraint is a restriction on the number ofcomponents that interact through the connector. Establishingadherence to more complex connector constraints (e.g., minimalthroughput) may require access to information external to thegiven connector (e.g., a model of the attached components’dynamic semantics).

4. Although the comparison categories for components and connectors areidentical, they were derived and refined independently of each other.

6 of 24

Evolution — Analogously to component evolution, the evo-lution of a connector is defined as the modification of (a subsetof) its properties, e.g., interface, semantics, or constraints on thetwo. Component interactions in architectures are governed bycomplex and potentially changing and expanding protocols. Fur-thermore, both individual components and their configurationsevolve. ADLs can accommodate this evolution by modifying orrefining existing connectors with techniques such as incrementalinformation filtering, subtyping, and refinement.

Non-Functional Properties —A connector’s non-func-tional properties are not entirely derivable from the specificationof its semantics. They represent (additional) requirements forcorrect connector implementation. Modeling non-functionalproperties of connectors enables simulation of runtime behavior,analysis of connectors, constraint enforcement, and selection ofappropriate off-the-shelf (OTS) connectors (e.g., message buses)and their mappings to processors.

3.1.3 Modeling Configurations

Architectural configurations, or topologies, are connectedgraphs of components and connectors that describe architecturalstructure. This information is needed to determine whetherappropriate components are connected, their interfaces match,connectors enable proper communication, and their combinedsemantics result in desired behavior. In concert with models ofcomponents and connectors, descriptions of configurationsenable assessment of concurrent and distributed aspects of anarchitecture, e.g., potential for deadlocks and starvation, perfor-mance, reliability, security, and so on. Descriptions of configura-tions also enable analyses of architectures for adherence todesign heuristics (e.g., direct communication links between com-ponents hamper evolvability of an architecture) and architecturalstyle constraints (e.g., direct communication links between com-ponents are disallowed).

Characteristic features at the level of architectural configura-tions fall in three general categories:

• qualities of the configuration description:understandability,compositionality, refinement and traceability, andheteroge-neity;

• qualities of the described system:heterogeneity, scalability,evolvability, anddynamism;

• properties of the described system:dynamism, constraints,andnon-functional properties.5

Note that the three categories are not entirely orthogonal: hetero-geneity and dynamism each appear in two categories. Heteroge-neity may be manifested in multiple employed formalisms inconfiguration descriptions and multiple programming languagesin system implementations. Anticipated dynamism is a systemproperty in that the system may be architected specifically toaccommodate the (expected) dynamic change; unanticipateddynamism is aquality that refers to a system’s general suitabilityfor dynamic change.

5. The term “quality” is used in the conventional, application-independentmanner, e.g., as defined by Ghezzi and colleagues [18]. The term “property”refers to the characteristics of an application introduced to address specificrequirements.

The differences between the two pairs of features are subtle,particularly in the case of dynamism. While keeping the abovecategorization in mind, in order to maintain the conceptual sim-plicity of our framework and avoid confusion, we proceed bydescribing individual features; we include both notions of hetero-geneity and dynamism under single respective headings. Wemotivate and, where appropriate, define the configuration fea-tures below.

Understandable Specifications —One role of softwarearchitecture is to serve as an early communication conduit fordifferent stakeholders in a project and facilitate understanding of(families of) systems at a high level of abstraction. ADLs mustthus model structural (topological) information with simple andunderstandable syntax. The structure of a system should ideallybe clear from a configuration specification alone, i.e., withouthaving to study component and connector specifications.

Compositionality — Compositionality, or hierarchicalcomposition, is a mechanism that allows architectures to describesoftware systems at different levels of detail: complex structureand behavior may be explicitly represented or they may beabstracted away into a single component or connector. Situationsmay also arise in which an entire architecture becomes a singlecomponent in another, larger architecture. Such abstractionmechanisms should be provided as part of an ADLs modelingcapabilities.

Refinement and Traceability —In addition to providingarchitects with semantically elaborate facilities for specifyingarchitectures, ADLs must also enable correct and consistentrefinement of architectures into executable systems and traceabil-ity of changes across levels of architectural refinement. This viewis supported by the prevailing argument for developing and usingADLs: they are necessary to bridge the gap between informal,“boxes and lines” diagrams and programming languages, whichare deemed too low-level for application design activities.

Heterogeneity —A goal of software architectures is tofacilitate development of large-scale systems, preferably withpre-existing components and connectors of varying granularity,possibly specified in different formal modeling languages andimplemented in different programming languages, with varyingoperating system requirements, and supporting different commu-nication protocols. It is therefore important that ADLs beopen,i.e., that they provide facilities for architectural specification anddevelopment with heterogeneous components and connectors.

Scalability — Architectures are intended to provide develop-ers with abstractions needed to cope with the issues of softwarecomplexity and size. ADLs must therefore directly support speci-fication and development of large-scale systems that are likely togrow further.

Evolvability — New software systems rarely provideentirely unprecedented functionality, but are rather “variations ona theme.” An architecture evolves toreflect andenable evolutionof a family of software systems. Since evolution (i.e., mainte-nance) is the single costliest software development activity [18],system evolvability becomes a key aspect of architecture-baseddevelopment. ADLs need to augment evolution support at thelevel of components and connectors with features for their incre-

7 of 24

mental addition, removal, replacement, and reconnection in aconfiguration.

Dynamism —Evolution, as we define it, refers to “off-line”changes to an architecture (and the resulting system). Dynamism,on the other hand, refers to modifying the architecture and enact-ing those modifications in the systemwhile the system is execut-ing. Support for dynamism is important in the case of certainsafety- and mission-critical systems, such as air traffic control,telephone switching, and high availability public informationsystems. Shutting down and restarting such systems for upgradesmay incur unacceptable delays, increased cost, and risk [52]. Tosupport architecture-based run-time evolution, ADLs need toprovide specific features formodeling dynamic changes and tech-niques foreffecting them in the running system.

Constraints — Constraints that depict dependencies in aconfiguration complement those specific to individual compo-nents and connectors. Many global constraints are derived fromor directly depend upon local constraints. For example, con-straints on valid configurations may be expressed as interactionconstraints among constituent components and connectors, whichin turn are expressed through their interfaces and protocols; per-formance of a system described by a configuration will dependupon the performance of each individual architectural element;safety of an architecture is a function of the safety of its constitu-ents.

Non-Functional Properties —Certain non-functionalproperties are system-level, rather than individual component orconnector properties. Configuration-level non-functional proper-ties are needed to select appropriate components and connectors,perform analysis, enforce constraints, map architectural buildingblocks to processors, and aid in project management.

3.1.4 Tool Support for Architectural Description

The motivation behind developing formal languages for archi-tectural description is that their formality renders them suitablefor reasoning and manipulation by software tools. A supportingtoolset that accompanies an ADL is, strictly speaking, not a partof the language. However, the usefulness of an ADL is directlyrelated to the kinds of tools it provides to support architecturaldesign, analysis, evolution, executable system generation, and soforth. The importance of architectural tools is reflected in the on-going effort by a large segment of the community to identify thecomponents that comprise a canonical “ADL toolkit” [17].Although the results of this work are still preliminary, severalgeneral categories have emerged. They reflect the kinds of toolsupport commonly provided by existing architectural approaches:active specification, multiple views, analysis, refinement, imple-mentation generation, and dynamism. Each is discussed below.

Active Specification —ADL tools provide active specifica-tion support by reducing the space of possible design optionsbased on the current state of the architecture. Such tools providedesign guidance and can significantly reduce a software archi-tect’s cognitive load. They can be either proactive, by suggestingcourses of action or disallowing design options that may result inundesirable design states, or reactive, by informing the architectof such states once they are reached during design. Active speci-fication tools can deliver their feedback intrusively, forcing the

architect to acknowledge it before continuing, or non-intrusively,allowing the architect to view the feedback at his discretion.

Multiple Views — When defining an architecture, differentstakeholders (e.g., architects, developers, managers, customers)may require different views of the architecture. The customersmay be satisfied with a high-level, “boxes-and-lines” description,the developers may want detailed (formal) component and con-nector specifications, while the managers may require a view ofthe corresponding system development process. Providing themost appropriate view to a given stakeholder and ensuring inter-view consistency are key issues to be addressed by an ADL tool-kit.

Analysis —Architectural descriptions are often intended tomodel large, distributed, concurrent systems. The ability to evalu-ate the properties of such systems upstream, at an architecturallevel, can substantially lessen the cost of any errors. Given thatmany details are abstracted away in architectures, this task mayalso be easier than at source code level. Analysis of architectureshas thus been a primary focus of ADL toolset developers.

Refinement —The importance of supporting refinement ofarchitectures across levels of detail was briefly argued above andmore extensively by Garlan [13] and Moriconi and colleagues[47]. Refining architectural descriptions is a complex task whosecorrectness and consistency cannot always be guaranteed by for-mal proof, but adequate tool support can give architects increasedconfidence in this respect.

Implementation Generation —The ultimate goal of anysoftware design and modeling endeavor is to produce the execut-able system. An elegant architectural model is of limited valueunless it can be converted into a running application. Doing somanually may result in many problems of consistency and trace-ability between an architecture and its implementation. It istherefore desirable, if not imperative, for an ADL toolkit to pro-vide tools to assist in producing source code.

Dynamism —We have argued for the need to modeldynamic changes at the level of architecture. However, an ADL’sability to model dynamic changes is insufficient to guarantee thatthey will be applied to the executing system in a property-pre-serving manner. Software tools are needed to analyze the modi-fied architecture to ensure its desirable properties, correctly mapthe changes expressed in terms of architectural constructs to theimplementation modules, ensure continuous execution of theapplication’s vital subsystems and preservation of stateduringthe modification, and analyze and test the modified applicationwhile it is executing.

3.2 Differentiating ADLs from Other Languages

In order to clarify whatis an ADL, it may be useful to pointout several notations that, though similar, arenot ADLs accord-ing to our definition: high-level design notations, MILs, program-ming languages, object-oriented (OO) modeling notations, andformal specification languages.

The requirement to modelconfigurations explicitly distin-guishes ADLs from some high-level design languages. Existinglanguages that are sometimes referred to as ADLs can be groupedinto three categories based on how they model configurations:

8 of 24

• implicit configuration languagesmodel configurationsimplicitly through interconnection information that is dis-tributed across definitions of individual components andconnectors;

• in-line configuration languagesmodel configurations explic-itly, but specify component interconnections, along with anyinteraction protocols, “in-line;”

• explicit configuration languagesmodel both components andconnectors separately from configurations.

The first category, implicit configuration languages, are, by thedefinition given in this paper,not ADLs, although they may serveas useful tools in modeling certain aspects of architectures. Twoexamples of such languages are LILEANNA and ArTek. InLILEANNA, interconnection information is distributed amongthe with clauses of individual packages, package bindings (viewconstruct), and compositions (make). In ArTek, there is no con-figuration specification; instead, each connector specifies compo-nent ports to which it is attached.

The focus onconceptual architecture and explicit treatment ofconnectors as first-class entities differentiate ADLs from MILs[55], programming languages, and OO notations and languages(e.g., Unified Modeling Language, or UML [57], [58]). MILstypically describe theuses relationships among modules in animplemented system and support only one type of connection [4],[64]. Programming languages describe a system’s implementa-tion, whose architecture is typically implicit in subprogram defi-nitions and calls. Explicit treatment of connectors alsodistinguishes ADLs from OO languages, as demonstrated in [34].

It is important to note that there is less than a firm boundarybetween ADLs and MILs. Certain ADLs, e.g., Wright andRapide, model components and connectors at a high level ofabstraction and do not assume or prescribe a particular relation-ship between an architectural description and an implementation.We refer to these languages asimplementation independent. Onthe other hand, several ADLs, e.g., Weaves, UniCon, and MetaH,require a much higher degree of fidelity of an architecture to itsimplementation. Components modeled in these languages aredirectly related to their implementations, so that a module inter-connection specification may be indistinguishable from an archi-tectural description in such a language. These areimplementationconstraining languages.

We have also recently shown that an OO language, such asUML, can be used to model software architectures if it supportscertain extensions [41], [60]. These extensions are used to repre-sent architectural abstractions that either differ (e.g., topologicalconstraints) or do not exist (e.g., connectors) in OO design.Extending UML in such a manner is clearly useful in that it sup-ports mapping of an architecture to a more familiar and widelyused notation, therefore facilitating broader understanding of thearchitecture and enabling more extensive tool support for manip-ulating it. However, it is unrealistic to expect that UML could beextended to model every feature of every ADL; our initial experi-ence indeed confirms this [60]. Moreover, although UML mayprovide modeling power equivalent to or surpassing that of anADL, the abstractions it provides will not match an architect’smental model of the system as faithfully as the architect’s ADLof choice. If the primary purpose of a language is to provide avehicle of expression that matches the intuitions and practices of

users, then that language should aspire to reflect those intentionsand practices [65]. We believe this to be a key issue and one thatargues against considering a notation like UML an ADL: a givenlanguage (e.g., UML) offers a set of abstractions that an architectuses as design tools; if certain abstractions (e.g., components andconnectors) are buried in others (e.g., classes), the architect’s jobis made more (and unnecessarily) difficult; separating compo-nents from connectors, raising them both to visibility as top-levelabstractions, and endowing them with certain features and limita-tions also raises them in the consciousness of the designer.

An ADL typically subsumes a formal semantic theory. Thattheory is part of the ADL’s underlying framework for characteriz-ing architectures; it influences the ADL’s suitability for modelingparticular kinds of systems (e.g., highly concurrent systems) orparticular aspects of a given system (e.g., its static properties).Examples of formal specification theories are Statecharts [23],partially-ordered event sets [33], communicating sequential pro-cesses (CSP) [24], model-based formalisms (e.g., chemicalabstract machine, or CHAM [25], Z [67]), algebraic formalisms(e.g., Obj [19]), and axiomatic formalisms (e.g., Anna [30]). Ofthe above-mentioned formal notations, Z has been demonstratedappropriate for modeling only certain aspects of architectures,such as architectural style rules [1], [42]. Partially-ordered eventsets, CSP, Obj, and Anna have already been successfully used byexisting modeling languages (Rapide, Wright, and LILEANNA,respectively).

Modeling capabilities of the remaining two notations, State-charts and CHAM, are somewhat similar to those of ADLs.Although they do not express systems in terms of components,connectors, and configurations per se, their features may be castin that mold and they have indeed been referred to as examples ofADLs [8], [25]. We discuss in the remainder of the section why itis inappropriate to do so.

3.2.1 Statecharts

Statecharts is a modeling formalism based on finite statemachines (FSM) that provides a state encapsulation construct,support for concurrency, and broadcast communication. To com-pare Statecharts to an ADL, the states are viewed as components,transitions among them as simple connectors, and their intercon-nections as configurations. However, Statecharts does not modelarchitectural configurations explicitly: interconnections andinteractions among a set of concurrently executing componentsare implicit in intra-component transition labels. In other words,as was the case with LILEANNA and ArTek, the topology of an“architecture” described as a Statechart can only be determinedby studying its constituent components. Therefore, Statecharts isnot an ADL.

There is an even deeper issue in attempting to model architec-tures as FSMs: although it may be useful to represent componentor connector semantics with Statecharts, it is doubtful that anadequate architectural breakdown of a system can be achievedfrom a state-machine perspective. Harel [23] agrees with thisview, arguing that

one has to assume some physical and functionaldescription of the system, providing, say, a hierarchicaldecomposition into subsystems and the functions and

9 of 24

activities they support... Statecharts can then be used tocontrol these internal activities... We assume that thiskind of description is given or can be produced using anexisting method.

3.2.2 Chemical Abstract Machine

In the chemical abstract machine (CHAM) approach, an archi-tecture is modeled as an abstract machine fashioned after chemi-cals and chemical reactions. A CHAM is specified by definingmolecules, their solutions, and transformation rules that specifyhow solutions evolve. An architecture is then specified with pro-cessing, data, and connecting elements. The interfaces of pro-cessing and connecting elements are implied by (1) theirtopology and (2) the data elements their current configurationallows them to exchange. The topology is, in turn, implicit in asolution and the transformation rules. Therefore, even thoughCHAM can be used effectively to prove certain properties ofarchitectures, without additional syntactic constructs it does notfulfill the requirements to be an ADL.

4 COMPARISON OF ADLS

This section presents a detailed comparison of existing ADLsalong the dimensions discussed in Section 3.1. We highlight rep-resentative approaches and support our arguments with exampleADL specifications. The chosen examples are deliberately keptsimple. They are intended to give the reader a flavor of the kindof solutions an ADL may provide for a particular problem, inde-pendently of the ADL’s overall syntax and semantics.

Our decision to provide multiple examples instead of a singlerepresentative example is motivated by the the inability of theresearch community to identify a model problem for which allADLs are likely to be well suited [68]. Thus, selecting any onecandidate problem would likely draw the (justified) criticism offocusing on the strengths of only certain languages. This point isrelated to the discussion from Section 3: different ADLs focus ondifferent application domains, architectural styles, or aspects ofthe architectures they model. This is certainly the case with theADLs we have studied, and which represent a large cross-sectionof existing work in the area, as shown in Table 1.

4.1 ADL Support for Modeling Components

Each surveyed ADL models components. ACME, Aesop, C2,Darwin, SADL, UniCon, and Wright share much of their vocabu-lary and refer to them simply ascomponents; in Rapide they areinterfaces; in Weaves,tool fragments; and in MetaH,processes.

In this section, we discuss the support provided by ADLs for dif-ferent aspects of components.

4.1.1 Interface

All surveyed ADLs support specification of component inter-faces. They differ in the terminology and the kinds of informationthey specify. For example, an interface point in SADL or Wrightis aport, and in UniCon aplayer. On the other hand, in C2 theentire interface is provided through a single port; individual inter-face elements aremessages. Weaves combines the twoapproaches by allowing multiple componentports, each of whichcan participate in the exchange of interface elements, orobjects.

ADLs typically distinguish between interface points that referto provided and required functionality. MetaH and Rapide makethe additional distinction between synchronous and asynchro-nous interfaces. For example,provides and requires interfaceconstituents in Rapide refer to functions and specify synchronouscommunication, whilein and out actions denote asynchronousevents.

Interface points are typed in a number of ADLs: ACME,Aesop, Darwin, MetaH, SADL, and UniCon. UniCon supports apredefined set of common player types, includingRoutineDef,RoutineCall, GlobalDataDef, GlobalDataUse, ReadFile, Write-File, RPCDef, andRPCCall. On the other hand, ports in C2 andWeaves are type-indifferent in order to maximize the flexibility ofinterconnection. Weaves ports perform wrapping and unwrappingof data objects by means ofenvelopes, which hide the types ofthe underlying data objects, while C2 ports are designed to han-dle any C2 messages.

Finally, Wright and UniCon allow specification of expectedcomponent behavior or constraints on component usage relevantto each point of interaction. For example, UniCon allows specifi-cation of the number of associations in which a player can beinvolved. Fig. 2 depicts the constraint that theinput player of theStreamIn type is bound to standard input and participates inexactly one association in a given architecture.

TABLE 1ADL SCOPE ANDAPPLICABILITY

ADL ACME Aesop C2 Darwin MetaH Rapide SADL UniCon Weaves Wright

Focus

Architecturalinterchange,predomi-nantly at thestructural level

Specificationof architec-tures in spe-cific styles

Architecturesof highly-dis-tributed,evolvable, anddynamic sys-tems

Architecturesof highly-dis-tributed sys-tems whosedynamism isguided bystrict formalunderpinnings

Architec-tures in theguidance,navigation,and control(GN&C)domain

Modeling andsimulation ofthe dynamicbehaviordescribed byan architecture

Formal refine-ment of archi-tecturesacross levelsof detail

Glue codegeneration forinterconnect-ing existingcomponentsusing com-mon interac-tion protocols

Data-flow archi-tectures, charac-terized by high-volume of dataand real-timerequirementson its process-ing

Modeling andanalysis (spe-cifically, dead-lock analysis)of the dynamicbehavior ofconcurrent sys-tems

PLAYER input IS StreamInMAXASSOCS (1)MINASSOCS (1)SIGNATURE (“line”)PORTBINDING (stdin)

END input

Fig. 2. Specification of a component player in UniCon.

10 of 24

Wright specifies the protocol of interaction at each port in CSP[24]. In the example given in Fig. 3,DataRead is a simple input(read only) port.6

4.1.2 Types

All of the surveyed ADLs distinguish component types frominstances. Rapide does so with the help of a separate types lan-guage [31]. Weaves distinguishes betweensockets and tool frag-ments that populate them. With the exception of MetaH andUniCon, all ADLs provide extensible component type systems.MetaH and UniCon support only a predefined, built-in set oftypes. MetaH component types areprocess, macro, mode, system,and application.7 Component types supported by UniCon areModule, Computation, SharedData, SeqFile, Filter, Process,SchedProcess, andGeneral.

Several ADLs (ACME, Darwin, Rapide, SADL, and Wright)make explicit use of parameterization of component interface sig-natures. This is typically done in the manner similar to program-ming languages such as Ada and C++. Rapide and Wright alsoallow the behavior associated with a particular type to be parame-terized. Rapide does so by specifying event patterns, discussedbelow. Wright allows parameterization of a component by itscomputation, a CSP specification that defines the component’sbehavior. This allows the architect to vary the behavior of a com-ponent in a systematic manner.

4.1.3 Semantics

All ADLs support specification of component semantics,although to varying degrees. The ADLs’ underlying semanticmodels range from expressing semantic information in compo-nent property lists (UniCon) to the models of dynamic compo-nent behavior (Rapide and Wright).8 Other points along thisspectrum are arbitrarily complex behavioral specifications thatare treated as uninterpreted annotations (ACME); an accompany-ing language for modeling algorithms in the ADL’s domain(MetaH); specification of static component semantics via invari-ants and operation pre- and post-conditions (C2); and models ofinteraction and composition properties of composite componentsexpressed in theπ-calculus [44] (Darwin).

Rapide introduces a unique mechanism for expressing both acomponent’sbehavior and its interaction with other components:partially ordered sets of events (posets). Rapide uses event pat-terns to recognize posets. During poset recognition, free variablesin a pattern are bound to specific matching values in a poset.

6. In all examples, we adhere to each ADL’s presentation conventions (naming,capitalization, highlighting, etc.).

7. As MetaH is used to specify both the software and the hardware architectureof an application,system is a hardware construct, whileapplication pertains toboth.

8. As discussed in the preceding section, Wright uses CSP to specify a compo-nent’scomputation.

Event patterns are used both as triggers and outputs of compo-nent state transitions. Fig. 4 shows an example of a simple Rapidecomponent with a causal relationship between events: when theApplication component observes aReceive event, it generates aResults event in response; the two events have the same stringparameter.

4.1.4 Constraints

All ADLs constrain the usage of a component by specifying itsinterface as the only legal means of interaction. Formal specifica-tion of component semantics further specifies relationships anddependencies among internal elements of a component. Severaladditional means for constraining components are common.

A number of ADLs provide stylistic invariants (Aesop, C2,SADL, and Wright). An example stylistic invariant is C2’srequirement that a component have exactly two communicationports, one each on its top and bottom sides. A component canalso be constrained via attributes. Fig. 2 shows how a UniConcomponent is constrained by restricting the number of associa-tions in which its players can participate. MetaH also constrainsthe implementation and usage of a component by specifying its(non-functional) attributes, such asExecutionTime, Deadline, andCriticality. Finally, Rapide enables specification of pattern con-straints on event posets that are generated and observed from acomponent’s interface. In the example shown in Fig. 5, the con-straint implies that all, and only, messages taken in by theResource component are delivered.

4.1.5 Evolution

A number of ADLs view and model components as inherentlystatic. For example, MetaH and UniCon define component typesby enumeration, allowing no subtyping, and hence no evolutionsupport; Weaves considers tool fragment evolution outside itsscope. Several ADLs support component evolution via subtyping.They typically support a limited notion of subtyping or rely onthe mechanisms provided by the underlying programming lan-guage. For example, ACME supports strictly structural subtypingwith its extends feature, while Rapide evolves components viaOO inheritance. SADL allows the specification of high-levelproperties that must be satisfied by subtypes: the example in Fig.

port DataRead = get DataRead→Fig. 3. Interaction protocol for a component port in Wright:

denotes event transitions, a successfully terminatingprocess, non-deterministic choice, and deterministicchoice.

→

type Application is interfaceextern action Request(p : params);public action Results(p : params);

behavior(?M in String) Receive(?M) => Results(?M);;

end Application;

Fig. 4. A Rapide component’s behavior specified with posets.

type Resource is interfacepublic action Receive(Msg : String);extern action Results(Msg : String);

constraintmatch

((?S in String)(Receive(?S) -> Results(?S)))^(*~);end Resource;

Fig. 5. A pattern constraint in Rapide.

11 of 24

6 specifies thatLocal_Client is the subtype ofClient such that allof its instances satisfy the predicateLocal.

Aesop and C2 provide more extensive component subtypingsupport. Aesop enforces behavior-preserving subtyping to createsubstyles of a given architectural style. An Aesop subclass mustprovide strict subtyping behavior for operations that succeed, butmay also introduce additional sources of failure with respect toits superclass. C2, on the other hand, supports multiple subtypingrelationships among components:name, interface,behavior, andimplementation [39], [42]. Different combinations of these rela-tionships are specified using the keywordsand and not. Fig. 7demonstrates two possible subtyping relationships:Well_1 pre-serves (and possibly extends) the behavior of the componentMatrix, but may change its interface and implementation;Well_2’s subtyping relationship mandates that itmust alterMatrix’s interface:

Rapide and SADL also provide features for refining compo-nents across levels of abstraction. This mechanism may be usedto evolve components by explicating any deferred design deci-sions, which is somewhat similar to extending inherited behaviorin OO languages. Indeed, subtyping is simply a form of refine-ment in a general case. This is, however, not true of Rapide andSADL, both of which place additional constraints on refinementmaps in order to prove or demonstrate certain properties of archi-tectures. Refinement of components and connectors in Rapideand SADL is a byproduct of the refinement of configurations,their true focus. Therefore, we will defer further discussion ofthis issue until Section 4.3.

4.1.6 Non-Functional Properties

Despite the need for and benefits of specifying non-functionalproperties, there is a notable lack of support for them in existingADLs. ACME, Aesop, and Weaves allow specification of arbi-trary component properties and/or annotations. However, none ofthem interprets such properties, nor do they make direct use ofthem.

MetaH and UniCon provide more advanced support for model-ing non-functional properties. They require such information toanalyze architecture for real-time schedulability (both ADLs) andreliability and security (MetaH). Both also use source code loca-tion attributes for implementation generation. Several representa-tive non-functional properties in MetaH areSourceName,SourceFile, ClockPeriod, Deadline, and Criticality. UniConallows specification ofPriority, Library, ImplType (source,object, executable, data, orwhatever), andProcessor.

4.1.7 Summary of ADL Components

Overall, surveyed ADLs provide comprehensive support formodeling components. All of them regard components as first-class entities. Furthermore, all model interfaces and distinguishbetween component types and instances. On the other hand, amajority of the ADLs do not support evolution or non-functionalproperties. It is illustrative that Aesop is the only ADL that pro-vides at least some support for each of the six classification cate-gories and that, of the five ADLs that support five of thecategories, C2 and Rapide do not model non-functional proper-ties, and MetaH, UniCon, and Weaves do not support evolution.Every ADL supports or allows at least four of the six categories.A more complete summary of this section is given in Table 2.

4.2 ADL Support for Modeling Connectors

ADLs model connectors in various forms and under variousnames. For example, ACME, Aesop, C2, SADL, UniCon, andWright model connectors explicitly and refer to them asconnec-tors. Weaves also models connectors explicitly, but refers to themastransport services. Rapide and MetaHconnectionsand Darwinbindingsare modeled in-line, and cannot be named, subtyped, orreused (i.e., connectors are not first-class entities). Darwin andRapide do allow abstracting away complex connection behaviorsinto “connector components.” In this section, we compare exist-ing ADLs with respect to the support they provide for differentaspects of connectors.

4.2.1 Interface

In general, only the ADLs that model connectors as first-classentities support explicit specification of connector interfaces.Most such ADLs model component and connector interfaces inthe same manner, but refer to them differently. Thus, connectorinterface points in ACME, Aesop, UniCon, and Wright areroles,which are named and typed. Explicit connection of componentports (players in UniCon) and connector roles is required in anarchitectural configuration. Wright supports CSP specificationsof each role’s interaction protocol in the same manner as portprotocols (see Fig. 3). This allows compatibility analysis of con-nected ports and roles.

In UniCon, each role may include optional attributes, such asthe type of players that can serve in the role and minimum andmaximum number of connections. UniCon supports only a pre-defined set of role types, includingSource, Sink, Reader, Readee,Writer, Writee, Definer, andCaller. An example UniCon role isshown in Fig. 8. It belongs to thePipe connector type and is con-strained to be connected to at most a single player. Note that,unlike the player shown in Fig. 2, which must participate inexactly one association, this role does not have to be connected toa player.

Local_Client : TYPE = { c : Client | Local(c) }

Fig. 6. A subtype specification in SADL.

component Well_1 is subtype Matrix (beh)component Well_2 is subtype Matrix (beh \and \not int)

Fig. 7. Specification of component subtypes in C2.

ROLE output IS SourceMAXCONNS (1)

END input

Fig. 8. Specification of a connector role in UniCon.

12 of 24

SADL, C2, and Weaves model connector interfaces differentlyfrom component interfaces. A SADL connector is defined as partof the design vocabulary for a particular architectural style. Thespecification of the connector in an architecture only specifies thetype of data the connector supports (e.g., the connector declaredin Fig. 9a expects a token sequence). Other information about the

connector, such as its arity and the constraints on its usage, isgiven in the definition of its style (Fig. 9b).

The interfaces of C2 and Weaves connectors are generic: theconnectors are indifferent to the types of data they handle; theirmain task is to mediate and coordinate the communication amongcomponents. Additionally, a C2 connector can support an arbi-trary number of components. In C2, this feature is referred to ascontext-reflection: the interface of a connector is determined by(potentially dynamic) interfaces of components that communi-cate through it, as depicted in Fig. 10.

4.2.2 Types

Only ADLs that model connectors as first-class entities distin-guish connector types from instances. This excludes Darwin,MetaH, and Rapide. Although MetaH does not support connectortypes, it does define three broad categories of connections:portconnections, which connect anout port of one component to anin port of another;event connections, which connect outgoingevents to incoming events (event-to-event) or to their recipientcomponents (event-to-process and event-to-mode); andequiva-

TABLE 2ADL SUPPORT FORMODELING COMPONENTS

Characteristics Interface Types Semantics Constraints EvolutionNon-Functional

Properties

ACMEComponent;implementationindependent

interface points areports

extensible type sys-tem; parameterizationenabled with tem-plates

no support; canuse other ADLs’semantic modelsin property lists

via interfaces only structural subtyp-ing via theextends feature

allows any attributein property lists, butdoes not operate onthem

AesopComponent;implementationindependent

interface points areinput andoutputports

extensible type system (optional) style-specific languagesfor specifyingsemantics

via interfaces and seman-tics; stylistic invariants

behavior-preserv-ing subtyping

allows association ofarbitrary text withcomponents

C2

Component;implementationindependent

interface exportedthrough top and bot-tomports; interfaceelements arepro-vided andrequired

extensible type system component invari-ants and operationpre- and postcon-ditions in 1st orderlogic

via interfaces and seman-tics; stylistic invariants

heterogeneoussubtyping

none

DarwinComponent;implementationindependent;

interface points areservices (providedandrequired)

extensible type sys-tem; supports parame-terization

π-calculus via interfaces and semantics none none

MetaH

Process; imple-mentation con-straining

interface points areports

Predefined, enumer-ated set of types

ControlH for mod-eling algorithms inthe GN&Cdomain; imple-mentation seman-tics via paths

via interfaces and seman-tics; modes; non-functionalattributes

none attributes neededfor real-time schedu-lability, reliability,and security analysis

RapideInterface; imple-mentation inde-pendent

interface points areconstituents (pro-vides, requires,action, andservice)

extensible type sys-tem; contains a typessublanguage; sup-ports parameterization

partially orderedevent sets (posets)

via interfaces and seman-tics; algebraic constraints oncomponent state; patternconstraints on event posets

inheritance(structural sub-typing)

none

SADL

Component;implementationindependent;

interface points areinput and outputports (iportsandoports)

extensible type sys-tem; allows parame-terization ofcomponent signatures

none via interfaces; stylisticinvariants

subtyping byconstrainingsupertypes;refinement viapattern maps

requires componentmodification (seeSection 4.3.9)

UniConComponent;implementationconstraining

interface points areplayers

predefined, enumer-ated set of types

event traces inproperty lists

via interfaces and seman-tics; attributes; restrictionson players that can be pro-vided by component types

none attributes for sched-ulability analysis

WeavesTool fragments;implementationconstraining

interface points areread andwrite ports;interface elementsareobjects

extensible type sys-tem; types are compo-nentsockets

partial orderingover input andoutput objects

via interface and semantics none allows association ofarbitrary, uninter-preted annotationswith components

WrightComponent;implementationindependent;

interface points areports; port interac-tion semantics speci-fied in CSP

extensible type sys-tem; parameterizablenumber of ports andcomputation

not the focus;allowed in CSP

protocols of interaction foreach port in CSP; stylisticinvariants

via differentparameter instan-tiations

none

Features

ADL

(a)CONNECTORS

ch : DF_Chanl <SEQ(token)>CONFIGURATION

tok_flow : CONNECTION = Connects(ch, oport, iport)

(b)DF_Chanl : TYPE <= CONNECTORConnects : Predicate(3)connects_argtype_1 : CONSTRAINT =

(/\ x)(/\ y)(/\ z) [ Connects(x,y,z) => DF_Chanl(x) ]connects_argtype_2 : CONSTRAINT =

(/\ x)(/\ y)(/\ z) [ Connects(x,y,z) => Outport(y) ]connects_argtype_3 : CONSTRAINT =

(/\ x)(/\ y)(/\ z) [ Connects(x,y,z) => Inport(z) ]

Fig. 9. SADL connector interfaces. (a) Definition and instantiationof a connector in the specification of a SADL architecture. (b)Specification of the connector’s type in the definition of thedataflow style; all connectors of the DF_Chanl type will supportinteractions between two components.

13 of 24

lence connections, which specify objects that are shared amongcomponents.

ACME, Aesop, C2, SADL, and Wright base connector typeson interaction protocols. UniCon, on the other hand, only allowsconnectors of prespecified enumerated types:Pipe, FileIO, Pro-cedureCall, DataAccess, PLBundler, RemoteProcCall, andRTScheduler. ACME and SADL also provide parameterizationfacilities that enable flexible specification of connector signaturesand of constraints on connector semantics. Similarly to its com-ponents, Wright allows a connector to be parameterized by thespecification of its behavior (glue).

4.2.3 Semantics

It is interesting to note that ADLs that do not model connectorsas first-class objects, e.g., Rapide, may model connector seman-tics, while languages that do model connectors explicitly, such asACME, do not always provide means for defining their seman-tics. ADLs tend to use a single mechanism for specifying thesemantics of both components and connectors. For example,Rapide uses posets to describe communication patterns among itscomponents; Wright models connectorglue and event trace spec-ifications with CSP, as shown in Fig. 11; and UniCon allowsspecification of semantic information for connectors in propertylists (e.g., a real-time scheduling algorithm or path traces throughreal-time code). Additionally, connector semantics in UniCon areimplicit in their (predefined) connector types. For example,declaring a connector to be apipe implies certain functionalproperties.

Several ADLs use a different semantic model for their connec-tors than for components. For example, as demonstrated in Fig. 9,SADL provides a constraint language for specifying style-spe-cific connector semantics. C2 models a connector’s message fil-tering policy:message_sink, no_filtering, message_filtering, andprioritized. Finally, Weaves employs a set of naming conventionsthat imply its transport services’ semantics. For example, a sin-gle-writer, single-reader queue transport service is namedQueue_1_1.

4.2.4 Constraints

With the exception of C2 and Weaves, whose connector inter-faces are a function of their attached components (seeSection 4.2.1), ADLs that model connectors as first-class objectsconstrain their usage via interfaces. None of the ADLs that spec-ify connections in-line (Darwin, MetaH, and Rapide) place any

such constraints on them. Implementation and usage of connec-tors is further constrained in those ADLs that model connectorsemantics.

Aesop, C2, SADL, and Wright also impose stylistic invariants,such as C2’s restriction that each connector port may only beattached to a single other port. UniCon restricts the number ofcomponent players attached to a connector role by using theMin-Conns andMaxConns attributes. Additionally, the types of play-ers that can serve in a given role are constrained in UniCon viatheAccept attribute and in Wright by specifying interaction pro-tocols for the role (see Fig. 11). For example, theoutput UniConrole from Fig. 8 can be constrained to accept theStreamIn playerof theFilter component type (see Fig. 2) as follows:

4.2.5 Evolution

ADLs that do not model connectors as first-class objects (Dar-win, MetaH, and Rapide) also provide no facilities for their evo-lution. Others focus on configuration-level evolution (Weaves) orprovide a predefined set of connector types with no language fea-tures for evolution support (UniCon).

Several ADLs employ identical mechanisms for connector andcomponent evolution: ACME supports structural connector sub-typing, Aesop supports behavior preserving subtyping, andSADL supports subtyping of connectors and their refinementsacross styles and levels of abstraction. C2 connectors are inher-ently evolvable because of their context-reflective interfaces; C2connectors also evolve by altering their filtering policies. Finally,Wright supports connector evolution via parameterization,where, e.g., the same connector can be instantiated with a differ-entglue.

4.2.6 Non-Functional Properties

UniCon is the lone ADL that supports explicit specification ofnon-functional connector properties, using such information toanalyze an architecture for real-time schedulability. ItsSchedPro-cess connector has anAlgorithm attribute. If the value ofAlgo-rithm is set to RateMonotonic, UniCon uses trace, period,

Conn1Conn1Conn1

C1

Fig. 10. C2 connectors have context reflective interfaces. Each C2 connector is capable of supporting arbitrary addition, removal, andreconnection of any number of C2 components. (a) Software architect selects a set of components and a connector from a designpalette. The connector has no communication ports, since no components are attached to it. (b-d) As components are attached to theconnector to form an architecture, the connector creates new communication ports to support component intercommunication.

C2 C3 C1 C1

C2 C2

C3C1

Conn1

(a) (b) (c) (d)

ROLE output IS SourceMAXCONNS (1)ACCEPT (Filter.StreamIn)

END input

Fig. 11. Constraining a UniCon connector role to accept aspecific component player.

14 of 24

execution time, and priority information for schedulability analy-sis. As with their components, ACME, Aesop, and Weaves allowspecification of arbitrary, but uninterpreted connector annota-tions.

4.2.7 Summary of ADL Connectors

The support provided by the ADLs for modeling connectors isconsiderably less extensive than for components. Three ADLs(Darwin, MetaH, and Rapide) do not regard connectors as first-class entities, but rather model them in-line. Their connectors arealways specified as instances and cannot be manipulated duringdesign or reused in the future. Overall, their support for connec-tors is negligible, as can be observed in Table 3.

All ADLs that model connectors explicitly also model theirinterfaces and distinguish connector types from instances. It isinteresting to note that, as in the case of components, support forevolution and non-functional properties is rare, and that Aesop isagain the only ADL that provides at least some support for eachclassification category. A more complete summary of this sectionis given in Table 3.

4.3 ADL Support for Modeling Configurations

Explicit architectural configuration facilitates communicationamong a system’s many stakeholders, who are likely to have var-ious levels of technical expertise and familiarity with the problemat hand. This is accomplished by abstracting away the details ofindividual components and connectors and representing the sys-tem’s structure at a high level. In this section, we discuss the keyaspects of explicit configurations and compare surveyed ADLswith respect to them.

4.3.1 Understandable Specifications

Configuration descriptions inin-line configuration ADLs (e.g.,Rapide) tend to be encumbered with connector details. On theother hand,explicit configuration ADLs (e.g., Wright) have thebest potential to facilitate understandability of architectural struc-ture. Clearly, whether this potential is realized or not will alsodepend on the particular ADL’s syntax. For example, UniConfalls in the latter category, but it allows the connections betweenplayers and roles to appear in any order, possibly distributed

TABLE 3ADL SUPPORT FORMODELING CONNECTORS

Characteristics Interface Types Semantics Constraints EvolutionNon-Functional

Properties

ACMEConnector; explicit interface points are

rolesextensible type sys-tem, based on proto-cols; parameterizationvia templates

no support; canuse other ADLs’semantic modelsin property lists

via interfaces andstructural for typeinstances

structural sub-typing via theextends feature

allows anyattribute in prop-erty lists, but doesnot operate on them

AesopConnector; explicit interface points are

rolesextensible type sys-tem, based on proto-cols

(optional) seman-tics specified usingWright

via interfaces andsemantics; stylisticinvariants

behavior-pre-serving subtyp-ing

allows associationof arbitrary textwith connectors

C2

Connector; explicit interface with eachcomponent via a sep-arateport; interfaceelements arepro-vided andrequired

extensible type sys-tem, based on proto-cols

partial semanticsspecified via mes-sage filters

via semantics; stylis-tic invariants (eachport participates inone link only)

context-reflec-tive interfaces;evolvable fil-tering mecha-nisms

none

DarwinBinding; in-line; noexplicit modeling ofcomponent interactions

none; allows “con-nection components”

none none none none none

MetaHConnection; in-line;allows connections to beoptionally named

none none; supports threegeneral classes of con-nections: port, event,and equivalence

none none none none

RapideConnection; in-line;complex reusable con-nectors only via “connec-tion components”

none; allows “con-nection components”

none posets; condi-tional connections

none none none

SADLConnector; explicit connector signature

specifies the sup-ported data types

extensible type sys-tem; parameterizedsignatures and con-straints

axioms in the con-straint language

via interfaces; stylis-tic invariants

subtyping;connectorrefinement viapattern maps

requires connectormodification (seeSection 4.3.9)

UniCon

Connector; explicit interface points areroles

predefined, enumer-ated set of types

implicit in connec-tor’s type; seman-tic information canbe given in prop-erty lists

via interfaces;restricts the type ofplayers that can beused in a given role

none attributes forschedulability anal-ysis

Weaves

Transport services;explicit

interface points arethe encapsulatingsocketpads

extensible type sys-tem; types are connec-tor sockets

via naming con-ventions

via interface none allows associationof arbitrary, unin-terpreted annota-tions withtransport services

Wright

Connector; explicit interface points areroles; role interac-tion semantics speci-fied in CSP

extensible type sys-tem, based on proto-cols; parameterizablenumber of roles andglue

connectorgluesemantics in CSP

via interfaces andsemantics; protocolsof interaction foreach role in CSP;stylistic invariants

via differentparameterinstantiations

none

Features

ADL

15 of 24

among individual component and connector instantiations, asshown in Fig. 12.

Several languages provide a graphical notation as anothermeans of achieving understandability. An example of an architec-ture modeled using C2’s graphical notation was shown in Fig. 10.A graphical architectural description may actually hinder under-standing unless there is a precise relationship between it and theunderlying model, i.e., unless the textual and graphical descrip-tions are interchangeable. Languages like C2, Darwin, and Uni-Con support such “semantically sound” graphical notations,while ACME, SADL, and Wright do not.9

4.3.2 Compositionality

Most ADLs provide explicit features to support hierarchicalcomposition of components, where the syntax for specifyingcomposite components typically resembles that for specifyingconfigurations. Wright allows both composite components andconnectors: the computation (glue) of a composite component(connector) is represented by an architectural description, ratherthan in CSP. It is interesting to note that Darwin and UniCon donot have explicit constructs for modeling architectures. Instead,they both model architectures as composite components. Thestatement sequence shown in Fig. 12 occurs inside the specifica-tion of a UniCon composite component. An example of a Darwincomponent illustrating its support for compositionality is shownin Fig. 13.

4.3.3 Refinement and Traceability

Architectural refinement and traceability of architectural deci-sions, properties, and relationships across refinements is still verymuch an open research area. Support for them in existing ADLsis limited. Several ADLs enable system generation directly froman architectural specification. These are typically theimplemen-tation constraining languages (see Section 3), in which a sourcefile corresponds to each architectural element. There are severalproblems with this approach to refining an architecture. Prima-rily, there is an assumption that the relationship between elementsof an architectural description and those of the resulting execut-able system will be 1-to-1. This may be unnecessary, and evenunreasonable, as architectures describe systems at a higher levelof abstraction than source code modules. There is also no guaran-

9. Note that a graphical specification of an architecture may not contain all theinformation in its textual counterpart (e.g., formal component and connector spec-ifications), and vice versa (e.g., graphical layout information). Additional supportis needed to make the two truly interchangeable (see Section 4.4.2).

tee that the specified source modules will correctly implement thedesired behavior. Finally, even if the specified modules currentlyimplement the needed behavior correctly, this approach providesno means of ensuring that future changes to those modules aretraced back to the architecture and vice versa.

SADL and Rapide support refinement and traceability moreextensively. They provide maps for refining architectures acrossdifferent levels of abstraction. SADL uses its maps (see Fig. 14)to prove the correctness of architectural refinements, whileRapide generates comparative simulations of architectures at dif-ferent levels. Both languages thus provide the means for tracingdesign decisions and changes from one level of architecturalspecification (or implementation) to another. They enforce differ-ent refinement rules, however: SADL’s stringent correctness-pre-serving criterion ensures that all decisions made at a given levelare maintained at all subsequent levels, but disallows new deci-sions to be introduced; Rapide’s maps allow new decisions, butmay also eliminate high-level behaviors at the lower levels. Gar-lan has recently argued for a marriage of the two approaches [13].

4.3.4 Heterogeneity

No ADL provides explicit support for multiple formal specifi-cation languages. Of those ADLs that support implementation ofarchitectures, several are also tightly tied to a particular program-

USES p1 PROTOCOL Unix-pipeUSES sorter INTERFACE Sort-filterCONNECT sorter.output TO p1.sourceUSES p2 PROTOCOL Unix-pipeUSES printer INTERFACE Print-filterCONNECT sorter.input TO p2.sink

Fig. 12. Configuration specification in UniCon. The twoconnections are separated by component and connectorinstantiations. All instantiations in this figure (preceded by theUSES keyword) are trivial; UniCon also allows specification ofcomponent and connector instance attributes, which wouldfurther obscure the structure of this configuration.

component Composite {provide provserv;require reqserv;inst

C1 : CompType1;C2 : CompType2;

bindprovserv -- C1.pserv;C2.rserv -- reqserv;

}

Fig. 13. Top: a Darwin composite component. Bottom: graphicalview of the component. Definitions of basic components C1 andC2, which themselves may be composite, are omitted forsimplicity.

Composite

C1

C2

pserv

rserv

provserv

reqserv

arch_map MAPPING FROM arch_L1 TO arch_L2BEGIN

comp --> (new_comp)conn --> (new_comp!subcomp)port --> ( ). . .

Fig. 14. A refinement mapping declared in SADL. Level 1architecture’s component comp is mapped to Level 2architecture’s new_comp. Level 1 connector conn is implementedby new_comp’s subcomponent subcomp. Level 1 port has beeneliminated from the Level 2 architecture; SADL ensures that thefunctionality associated with the port is provided elsewhere inarch_L2.

16 of 24

ming language. For example, Aesop and Darwin only supportdevelopment with components implemented in C++, whileMetaH is restricted to Ada and UniCon to C. On the other hand,C2 currently supports development in C++, Ada, and Java, whileWeaves supports interconnection of tool fragments implementedin C, C++, Objective C, and Fortran.

Several ADLs place restrictions that limit the number andkinds of components and connectors they can support. For exam-ple, MetaH requires each component to include a loop with a callto the predeclared procedureKERNEL.AWAIT_DISPATCHto periodi-cally dispatch a process. Any existing components have to bemodified to include this construct before they can be used in aMetaH architecture. Similarly, UniCon allows certain types ofcomponents and connectors (e.g., pipes, filters and sequentialfiles), but requires wrappers for others (e.g., spreadsheets, con-straint solvers, or relational databases).

Finally, another aspect of heterogeneity is the granularity ofcomponents. Most surveyed ADLs support modeling of both fineand coarse-grain components. At one extreme are componentsthat describe a single operation, such ascomputations in UniConor procedures in MetaH, while the other extreme can be achievedby hierarchical composition, discussed in Section 4.3.2.

4.3.5 Scalability

We consider the impact of scaling an architecture along twogeneral dimensions: adding elements to the architecture’s interior(Fig. 15a) and adding them along the architecture’s boundaries(Fig. 15b). To support the former, ADLs can, minimally, employcompositionality features, discussed in Section 4.3.2: the originalarchitecture is treated as a single, composite component, which isthen attached to new components and connectors. Objectivelyevaluating an ADLs ability to support the latter is more difficult,but certain heuristics can be of help.

It is generally easier to expand architectures described inexplicit configuration ADLs than in-line configuration ADLs:connectors in the latter are described solely in terms of the com-ponents they connect and adding new components may requiremodifications to existing connector instances. Additionally,ADLs that allow a variable number of components to be attachedto a single connector are better suited to scaling up than those thatspecify the exact number of components a connector can service.

For example, ACME and Aesop could not handle the extension tothe architecture shown in Fig. 15a without redefiningConn1 andConn2, while C2 and UniCon can.

To properly evaluate an ADL’s support for scalability, theseheuristics should be accompanied by other criteria. The ultimatedeterminant of scalability support is the ability of developers toimplement and/or analyze large systems based on the architec-tural descriptions given in an ADL. For example, as anin-lineconfiguration language, Rapide has been highlighted as an ADLwhose features may hamper scalability, yet it has been used tospecify architectures of several large, real world systems. Severalother ADLs have been applied to large-scale examples:

• Wright was used to model and analyze theRuntime Infra-structure (RTI) of the Department of DefenseHigh-LevelArchitecture for Simulations[5], whose original specificationwas over 100 pages long.

• SADL ensured the consistency between the reference archi-tecture and the implementation of a power-control systemused by the Tokyo Electric Power Company, implemented in200,000 Fortran 77 lines of code (LOC).

• C2 has been used in the specification and implementation ofits supporting environment, consisting of a number of largecustom-built and OTS components [42], [52]. The custom-built components comprise over 100,000 Java LOC; the OTScomponents comprise several million LOC.

• Weaves has been used in satellite telemetry processing appli-cations, whose size has ranged between 100,000 and over1,000,000 LOC.

• A representative example of Rapide’s use is the X/Open Dis-tributed Transaction Processing Industry Standard, whosedocumentation is over 400 pages long. X/Open’s referencearchitecture and subsequent extensions have been success-fully specified and simulated in Rapide [31].

4.3.6 Evolvability

Evolvability of an architectural configuration can be viewedfrom two different perspectives. One is its ability to accommo-date addition of new components in the manner depicted in Fig.15. The issues inherent in doing so were discussed in the preced-ing subsection. Another view of evolvability is an ADL’s toler-ance and/or support for incomplete architectural descriptions.Incomplete architectures are common during design, as somedecisions are deferred and others have not yet become relevant. Itwould therefore be advantageous for an ADL to allow incompletedescriptions. However, most existing ADLs and their supportingtoolsets have been built around the notion that precisely thesekinds of situations must be prevented. For example, Darwin,MetaH, Rapide, and UniCon compilers, constraint checkers, andruntime systems have been constructed to raise exceptions if suchsituation arise. In this case, an ADL, such as Wright, whichfocuses its analyses on information local to a single connector isbetter suited to accommodate expansion of the architecture than,e.g., SADL, which is very rigorous in its refinement ofentirearchitectures.

Another aspect of evolution is support for families of applica-tions. One way in which all ADLs support families is by separat-ing component and connector types from instances. For example,

Comp1

Comp4

Comp3

Conn1

Conn2

Conn3

(a)

(b)Comp6

Comp5Comp2

Fig. 15. An existing architecture is scaled up: (a) by adding newcomponents/connectors to its interior and (b) by expanding it“outward”. C2’s graphical notation is used for illustration.

17 of 24

Weaves supports specification of architecturalframeworks, whichare populated with sockets, rather than actual tool fragments andtransport services. Each instantiation of an architecture can thenbe considered a member of the same family. This is a limitednotion of family, as it does not allow the architecture itself to bemodified. Furthermore, the family to which an applicationbelongs is implicit in its architecture.

ACME is the only surveyed language that specifies architec-tural families explicitly, as first-class language constructs, andsupports their evolution. The component and connector typesdeclared in a family provide a design vocabulary for all systemsthat are declared as members of that family. The example given inFig. 16 shows the declaration of a simple ACME family and itsevolution.

4.3.7 Dynamism

The majority of existing ADLs view configurations statically.The exceptions are C2, Darwin, Rapide, and Weaves. Darwin andRapide support onlyconstrained dynamic manipulation of archi-tectures, where all runtime changes must be known a priori [51],[52]. Darwin allows runtime replication of components viadynamic instantiation, as well as deletion and rebinding of com-ponents by interpreting Darwin scripts. An example of dynamicinstantiation in Darwin is given in Fig. 17: invoking the servicecreate_inst with a data parameter results in a new instance ofcomponentcomp to whichdata is passed.

Rapide supports conditional configuration: itswhere clauseenables architectural rewiring at runtime, using thelink andunlink operators. Recently, Wright has adopted a similarapproach to dynamic architecture changes: it distinguishesbetween communication and control events, where the controlevents are used to specify conditions under which dynamicchanges are allowed [3]. The reconfiguration actions that are trig-gered in response to control events arenew, del, attach, anddetach.

C2 and Weaves support dynamic manipulation without anyrestrictions on the types of permitted changes. Instead, arbitrarymodifications are allowed in principle; their consistency isensured at system runtime. C2’s architecture modification(sub)language (AML) specifies a set of operations for insertion,removal, and rewiring of elements in an architecture at runtime:addComponent, removeComponent, weld, andunweld [38], [52].For example, the extension to the architecture depicted in Fig.15a is specified in C2’s AML as shown in Fig. 18. Weaves pro-vides similar support by exporting an application programmableinterface (API) to a model of a weave.

4.3.8 Constraints

Most ADLs enforce built-in constraints on what they considerto be valid configurations. For example, UniCon always requiresa connector role to be attached to a component player, while Dar-win only allows bindings between provided and required ser-vices. On the other hand, several ADLs provide facilities forspecifying arbitrary global constraints. For example, Rapide’stimed poset language [33] can be used to constrain configurationsin the same manner as components (see Fig. 5). Similarly, as withindividual components, MetaH explicitly constrains configura-tions with non-functional attributes. Refinement maps in SADLprovide constraints on valid refinements of a configuration (seeSection 4.3.3). Finally, Wright allows specification of structuralinvariants corresponding to different architectural styles. Anexample Wright style constraint is given in Fig. 19.

4.3.9 Non-Functional Properties

All ADLs that support specification of non-functional proper-ties of components and connectors also support hierarchical com-position. Hence, they can specify such properties on architecturesby treating them as composite components. MetaH and Rapidealso support direct modeling of non-functional properties ofarchitectures: MetaH allows specification of properties such asthe processor on which the system will execute, while Rapideallows modeling of timing information in its constraint language.SADL has been used to model security in a software architectureby adopting a different approach: instead of providing security

Family fam = {Component Type comp1 = { Port p1; }Component Type comp2 = { Port p2; }Connector Type conn1 = { Roles (r1,r2); }

}

Family sub_fam extends fam with {Component Type sub_comp1 extends comp1 with {

Port p1 = { Property attach : int <<default = 1>>; }}Component Type comp3 = { ... }

}

Fig. 16. Declaration of a family of architectures, fam, and itssubfamily, sub_fam, in ACME. fam is evolved into sub_fam byadding a new component and a property to one of famcomponentports.

component composite {provide create_inst< dyn data>;bind

create_inst -- dyn comp;}

Fig. 17. Dynamic component instantiation in Darwin.

Sample_Arch.addComponent(Comp5);Sample_Arch.weld(Conn1, Comp5);Sample_Arch.weld(Comp5, Conn2);Comp5.start();

Fig. 18. Dynamic insertion of a component into a C2 architectureSample_Arch. The start command informs the C2 implementationinfrastructure (see Section 4.4.5) to start executing Comp5.

Style Pipe-Filter. . .Constraints

c : Connectors Type( c) = Pipec : Components; p : Port | p Ports( c)Type( p) = DataInput Type( p) = DataOutput

∀ •∧ ∀ ∈ •∨

Fig. 19. The pipe-and-filter style declared in Wright. Theconstraint on the style specifies that all connectors are pipes andthat all component ports are either data input or data output ports.

18 of 24

modeling features in SADL, the “original” architecture is modi-fied by adding the necessary component and connector parame-ters and architectural constraints [48]. It is unclear whether thisapproach is applicable to other non-functional properties or howsimple the needed modifications are in a general case.

4.3.10Summary of ADL Configurations

It is at the level of configurations that the foci of some ADLscan be more easily noticed. For example, SADL’s particular con-tribution is in architectural refinement, while Darwin mostlyfocuses on system compositionality and dynamism. No singleADL satisfies all of the classification criteria, although Rapideand Weaves come close. Coverage of several criteria is sparseacross ADLs: refinement and traceability, evolution, dynamism,and non-functional properties. These are good indicators ofwhere future research should be directed. On the other hand,most ADLs allow or also provide explicit support for understand-ability, compositionality, and heterogeneity. A more completesummary of this section is given in Table 4.

4.4 Tool Support for ADLs

The need for tool support in architectures is well recognized.However, there is a definite gap between what the research com-munity identifies as desirable and the state of the practice. Whileevery surveyed ADL provides some tool support, with the excep-tion of C2 and Rapide, they tend to focus on a single area ofinterest, such as analysis (e.g., Wright), refinement (e.g., SADL),or dynamism (e.g., Weaves). Furthermore, within these areas,ADLs tend to direct their attention to a particular technique (e.g.,Wright’s analysis for deadlocks), leaving other facets unexplored.This is the very reason ACME has been proposed as an architec-ture interchange language: to enable interaction and cooperationamong different ADLs’ toolsets and thus fill in these gaps. Thissection surveys the tools provided by the different languages,attempting to highlight the biggest shortcomings.

4.4.1 Active Specification

Only a handful of existing ADLs provide tools that activelysupport specification of architectures. In general, such tools canbe proactive or reactive. Proactive specification tools act in a pro-scriptive manner, similar to syntax-directed editors for program-ming languages: they limit the available design decisions basedon the current state of architectural design. For example, suchtools may prevent selection of components whose interfaces donot match those currently in the architecture or disallow invoca-tion of analysis tools on incomplete architectures.

UniCon’s graphical editor operates in this manner. It invokesUniCon’s language processing facilities toprevent errors duringdesign, rather than correct them after the fact. Furthermore, theeditor limits the kinds of players and roles that can be assigned todifferent types of components and connectors, respectively. Simi-larly, C2’s DRADEL development environment proactively guidesthe “architecting” process by disallowing certain operations (e.g.,architectural type checking) before others are completed (e.g.,topological constraint checking) [42]. Darwin’sSoftware Archi-tect’s Assistant [50] is another example of a proactive specifica-

tion tool. The Assistant automatically adds services (i.e.,interface points) of appropriate types to components that arebound together. It also maintains the consistency of data types ofconnected ports: changing one port’s type is automatically propa-gated to all ports which are bound to it.

Reactive specification tools detectexisting errors. They mayeither only inform the architect of the error (non-intrusive) oralso force him to correct it before moving on (intrusive). In theformer case, once an inconsistency is detected, the tool informsthe architect, but allows him to remedy the problem as he sees fitor ignore it altogether. C2’sDRADEL environment includes a typechecker that provides non-intrusive support: the architect canproceed to the implementation generation phase even in the pres-ence of type mismatches. In the latter case, the architect is forcedto remedy the current problem before moving on. Certain fea-tures of MetaH’s graphical editor can be characterized as intru-sive: the MetaH editor gives the architect full freedom tomanipulate the architecture until theApply button is depressed,after which any errors must be rectified before the architect maycontinue with the design.

4.4.2 Multiple Views

Most ADLs support at least two views of an architecture—tex-tual and graphical—and provide automated support for alternat-ing between them. Aesop, MetaH, UniCon, and Weaves alsodistinguish different types of components and connectors iconi-cally and allow both top-level and detailed views of compositeelements.

Support for other views is sparse. C2’sArgo design environ-ment provides a view of the architecture-centered developmentprocess [59]. Darwin’sSoftware Architect’s Assistant provides ahierarchical view of the architecture which shows all the compo-nent types and the “include” relationships among them in a treestructure. Rapide and C2 allow visualization of an architecture’sexecution behavior by building an executable simulation of thearchitecture and providing tools for viewing and filtering eventsgenerated by the simulation. In particular, Rapide uses itsSimula-tor tool to build the simulation and itsAnimation Tools to animateits execution. Rapide also providesPoset Browser, a tool thatallows viewing events generated by the simulation. Weavesadopts a similar approach: it allows insertion of low-overheadobservers into a weave to support real-time execution animation.

4.4.3 Analysis

The types of analyses for which an ADL is well suited dependon its underlying semantic model and, to a lesser extent, its spec-ification features. For example, Wright uses CSP to analyze indi-vidual connectors and components attached to them fordeadlocks; Aesop and C2 ensure style-specific topological con-straints and type conformance among architectural elements;MetaH and UniCon support schedulability analysis by specifyingnon-functional properties, such as criticality and priority; finally,SADL can establish relative correctness of two architectures withrespect to a refinement map.

Another set of analysis techniques involves simulation of thebehavior described in an architecture. Examples are Rapide’s,

19 of 24

C2’s, and Weaves’ event monitoring and filtering tools. Similarly,Darwin allows instantiation of parameters and dynamic compo-nents to enact “what if” scenarios. A related technique, com-monly employed in Weaves, is to insert into the architecture a“listener” component whose only task is to analyze the data itreceives from adjacent components.

Language parsers and compilers are another kind of analysistools. Parsers analyze architectures for syntactic correctness,while compilers establish semantic correctness. All of the sur-veyed languages have parsers. Several (Darwin, MetaH, and Uni-Con) also have “compilers,” enabling them to generateexecutable systems from architectural descriptions, provided that

TABLE 4ADL SUPPORT FORMODELING ARCHITECTURAL CONFIGURATIONS

Charact. Understand. Compos.Refine./Trace.

Heterogen. Scalability Evolution Dynamism ConstraintsNon-Func.Properties

ACME

Attach-ments;explicit

explicit, con-cise textualspecification

providedvia tem-plates, rep-resentations, and rep-maps

rep-maps open propertylists; requiredexplicit map-pings acrossADLs

aided by explicitconfigurations;hampered byfixed number ofroles

aided by explicitconfigurations;first-class families

none ports may onlybe attached toroles and viceversa

allows anyattribute inpropertylists, butdoes notoperate onthem

Aesop

Configu-ration;explicit

explicit, con-cise graphicalspecification;parallel typehierarchy forvisualization

providedvia repre-sentations

none allows multiplelanguages formodeling seman-tics; supportsdevelopment inC

aided by explicitconfigurations;hampered byfixed number ofroles

no support for par-tial architectures;aided by explicitconfigurations

none ports may onlybe attached toroles and viceversa; program-mable stylisticinvariants

none

C2

Architec-turalTopology;explicit

explicit, con-cise textualand graphicalspecification

allowed;supportedvia inter-nal compo-nentarchitec-ture

none enabled by inter-nal componentarchitecture; sup-ports develop-ment in C++,Java, and Ada

aided by explicitconfigurationsand variablenumber of con-nector ports;used in the con-struction of itsown tool suite

allows partial archi-tectures; aided byexplicit configura-tions; minimalcomponent inter-dependencies; het-erogeneous connec-tors

unanticipateddynamism:element inser-tion, removal,and rewiring

fixed stylisticinvariants

none

Darwin

Binding;in-line

in-line textualspecificationwith many con-nector details;provides graph-ical notation

supportedby lan-guage’scompositecomponentfeature

supports sys-tem genera-tion whenimplementa-tion con-straining

allows multiplelanguages formodeling seman-tics of primitivecomponents;supports devel-opment in C++

hampered by in-line configura-tions

no support for par-tial architectures;hampered by in-lineconfigurations

constraineddynamism:runtime repli-cation of com-ponents andconditionalconfiguration

provided ser-vices may onlybe bound torequired ser-vices and viceversa

none

MetaH

Connec-tions; in-line

in-line textualspecificationwith many con-nector details;provides graph-ical notation

supportedvia macros

supports sys-tem genera-tion;implementa-tion con-straining

supports devel-opment in Ada;requires all com-ponents to con-tain a processdispatch loop

hampered by in-line configura-tions

no support for par-tial architectures;hampered by in-lineconfigurations

none applications areconstrained withnon-functionalattributes

supportsattributessuch as exe-cution pro-cessor andclock period

Rapide

Connect;in-line

in-line textualspecificationwith many con-nector details;provides graph-ical notation

mappingsrelate anarchitec-ture to aninterface

refinementmaps enablecomparativesimulationsof architec-tures at dif-ferent levels

supports devel-opment of exe-cutablesimulations inRapide’s execut-able sublanguage

hampered by in-line configura-tions; used inlarge-scaleprojects

no support for par-tial architectures;hampered by in-lineconfigurations;

constraineddynamism:conditionalconfigurationand dynamicevent genera-tion

refinement mapsconstrain validrefinements;timed poset con-straint language

timed posetmodel allowsmodeling oftiming in theconstraintlanguage

SADL

Configu-ration;explicit

explicit, con-cise textualspecification

mappingsrelate anarchitec-ture to acomponent

refinementmaps enablecorrectrefinementsacross styles

supports bothfine- and coarse-grain elements

aided by explicitconfigurations;used in large-scale project

no support for par-tial architectures;aided by explicitconfigurations;

none programmablestylistic invari-ants; refinementmaps constrainvalid refinements

architecturemodified byadding con-straints

UniCon

Connect;explicit

explicit textualand graphicalspecification;configurationdescriptionmay be distrib-uted

supportedthroughcompositecompo-nents andconnectors

supports sys-tem genera-tion;implementa-tion con-straining

supports onlypredefined com-ponent and con-nector types;supports compo-nent wrappers

aided by explicitconfigurationsand variablenumber of con-nector roles

some support forpartial architec-tures; aided byexplicit configura-tions;

none players may onlybe attached toroles and viceversa

none

Weaves

Weave;explicit

explicit, con-cise graphicalspecification

supportedthroughcompositesockets

supports sys-tem genera-tion;implementa-tion con-straining

development inC, C++, Objec-tive C, and For-tran; requires alltool fragmentsto provide a setof methods

aided by explicitconfigurations,sockets, andvariable numberof socket pads;used in large-scale project

allows partial archi-tectures; aided byexplicit configura-tions; support forfamilies via socket-populatedframe-works

unanticipateddynamism:element inser-tion, removal,and rewiring

precludes directcomponent-to-component links

allows asso-ciation ofarbitrary,uninter-preted anno-tations withweaves

Wright

Attach-ments;explicit

explicit, con-cise textualspecification

computa-tion andglue areexpress-ible asarchitec-tures

none supports bothfine- and coarse-grain elements

aided by explicitconfigurationsand variablenumber of roles;used in large-scale project

suited for partialspecification; aidedby explicit configu-rations

constraineddynamism:element inser-tion, removal,and rewiring

ports can only beattached to rolesand vice versa;programmablestylistic invari-ants

none

Features

ADL

20 of 24

component implementations already exist. Rapide’s compilergenerates executable simulations of Rapide architectures. C2’sDRADEL environment, on the other hand, provides a tool that gen-erates executable implementation skeletons from an architecturalmodel; the skeletons are completed either by developing new orreusing OTS functionality.

Another aspect of analysis is enforcement of constraints. Pars-ers and compilers enforce constraints implicit in type informa-tion, non-functional attributes, component and connectorinterfaces, and semantic models. Rapide also supports explicitspecification of other types of constraints, and provides means fortheir checking and enforcement. ItsConstraint Checker analyzesthe conformance of a Rapide simulation to the formal constraintsdefined in the architecture. C2’s constraint checker currentlyfocuses only on the topological rules of the style; an initial inte-gration with the architecture constraint checking tool, Armani[45], allows specification and enforcement of arbitrary con-straints.

4.4.4 Refinement

Several ADLs support direct refinement of architectural mod-els to executable code via “compilation.” Darwin, MetaH, andUniCon achieve this in a manner similar to MILs: architecturalcomponents are implemented in a programming language and thearchitectural description serves only to ensure proper intercon-nection and communication among them. The drawbacks of thisapproach were discussed in Section 4.3.3. Rapide, on the otherhand, provides an executable sublanguage that contains manycommon programming language control structures. C2 goesbeyond linking existing modules, but not as far as to provide exe-cutable language constructs: an architecture is refined into a par-tial implementation, which contains completion guidelines fordevelopers derived from the architectural description. For exam-ple, each method is accompanied by specifications of its precon-dition and postcondition, as shown in Fig. 20; the developer mustonly ensure their satisfaction when implementing the method andneed not worry about the rest of the system.

Only SADL and Rapide provide tool support for refiningarchitectures acrossmultiple levels of abstraction and specificity.SADL’s support is partial. It requires manual proofs of mappingsof constructs between an abstract and a more concretearchitec-tural style. Such a proof is performed only once; thereafter,SADL provides a tool that automatically checks whether any twoarchitectures described in the two styles adhere to the mapping.Rapide, on the other hand, supports event maps between individ-ual architectures. The maps are compiled by Rapide’sSimulator,so that theConstraint Checker can verify that the events gener-

ated during simulation of the concrete architecture satisfy theconstraints in the abstract architecture.

4.4.5 Implementation Generation

A large number of ADLs, but not all, support generation of asystem from its architecture. Exceptions are SADL, ACME, andWright, which are currently used strictly as modeling notationsand provide no implementation generation support. It is interest-ing to note that, while SADL focuses on refining architectures, itdoes not take the final refinement step from architectural descrip-tions to source code.

Several ADLs employ architectural “compilers,” as alreadydiscussed above. Aesop adopts a different approach: it provides aC++ class hierarchy for its concepts and operations, such as com-ponents, connectors, ports, roles, and attachments. This hierarchyforms a basis from which an implementation of an architecturemay be produced; the hierarchy is in essence a domain-specificlanguage for implementing Aesop architectures.

A similar approach is used in C2, which provides a frameworkof abstract classes for C2 concepts [42]. Components and con-nectors used in C2 applications are subclassed from the appropri-ate framework classes. The framework has been implemented inC++, Java, and Ada; several OTS middleware technologies havebeen integrated with the framework to enable interactionsbetween C2 components implemented in different languages[10]. Application skeletons produced by C2’s code generationfacilities discussed in above result in instantiated, but partiallyimplemented framework classes.

4.4.6 Dynamism

The limited support for modeling dynamism in existing ADLs,discussed in Section 4.3.7, is reflected in the limited tool supportfor dynamism. Darwin and Rapide can model only planned mod-ifications at runtime: both support conditional configuration; Dar-win also allows component replication. Their compilation toolsensure that all possible configuration alternatives are enabled.

C2 and Weaves toolsets support dynamism more extensively.Weaves provides a visual editor,Jacquard, which uses the pro-vided API to the architectural model to dynamically manipulate aweave in an arbitrary fashion. C2’sArchStudio tool [52] enablesarbitrary interactive construction, execution, and runtime-modifi-cation of C2-style architectures implemented in Java.ArchStudiosupports modification of an architecture at runtime by dynami-cally loading and linking new components or connectors into thearchitecture. Both C2 and Weaves exploit their flexible connec-tors (see Section 4.2) to support dynamism.

4.4.7 Summary of ADL Tool Support

Existing ADLs span a broad spectrum in terms of the designand development tools they provide. On the one hand, ACMEcurrently only facilitates visualization of its architectures,SADL’s toolset consists primarily of a refinement consistencychecker, and Weaves has focused on interactive specification andmanipulation of architectures. On the other hand, Darwin,Rapide, and UniCon provide powerful architecture modelingenvironments; C2 and Darwin are the only ADLs that provide

// PRE: pos \greater 0.0 \and pos \eqless numpublic Color GetTile(Integer pos) {

/*** METHOD BODY ***/return well_at_pos;

}// POST: \result = well_at_pos \and ~num = num - 1.0

Fig. 20. Each method generated by C2 is preceded by itsprecondition and followed by its postcondition.

21 of 24

tool support in all classification categories. Overall, existingADLs have put the greatest emphasis on visualization and analy-sis of architectures and the least on refinement and dynamism. Amore complete summary of this section is given in Table 5.

5 CONCLUSIONS

Classifying and comparing any two languages objectively is adifficult task. For example, a programming language, such asAda, contains MIL-like features and debates rage over whetherJava is “better” than C++ and why. On the other hand, there existboth an exact litmus test (Turing completeness) and ways to dis-tinguish different kinds of programming languages (imperativevs. declarative vs. functional, procedural vs. OO). Similarly, for-mal specification languages have been grouped into model-based,state-based, algebraic, axiomatic, and so forth. Until now, how-ever, no such definition or classification existed for ADLs.

The main contribution of this paper is just such a definition andclassification framework. The definition provides a simple litmustest for ADLs that largely reflects community consensus on whatis essential in modeling an architecture: an architectural descrip-tion differs from other notations by itsexplicit focus on connec-tors and architectural configurations. We have demonstrated howthe definition and the accompanying framework can be used todetermine whether a given notation is an ADL and, in the pro-cess, discarded several notations as potential ADLs. Some(LILEANNA and ArTek) may be more surprising than others(CHAM and Statecharts), but the same criteria were applied toall.

Of those languages that passed the litmus test, several strad-dled the boundary by either modeling their connectors in-line (in-line configuration ADLs) or assuming a bijective relationshipbetween architecture and implementation (implementation con-straining ADLs). We have discussed the drawbacks of both cate-gories. Nevertheless, it should be noted that, by simplifying the

ActiveSpecification

Multiple Views Analysis RefinementImplementation

GenerationDynamism

ACME

none textual; “weblets” inACME-Web; architec-ture views in terms ofhigh-level (template), aswell as basic constructs

parser none none none

Aesop

syntax-directed editor forcomponents; visualizationclasses invoke specializedexternal editors

textual and graphical;style-specific visualiza-tions; component andconnector types distin-guished iconically

parser; style-specificcompiler; type checker;cycle checker; checkerfor resource conflictsand scheduling feasibil-ity

none build tool constructssystem glue code inC for pipe-and-filterstyle

none

C2

proactive “architecting” pro-cess inDRADEL; reactive,non-intrusive type checker;design critics and to-do listsin Argo

textual and graphical;view of developmentprocess

parser; style rulechecker; type checker

generates applicationskeletons which can becompleted by reusingOTS components

class frameworkenables generation ofC/C++, Ada, andJava code;DRADELgenerates applica-tion skeletons

ArchStudio allows unan-ticipated dynamicmanipulation of architec-tures

Darwin

automated addition of ports tocommunicating components;propagation of changes acrossbound ports; dialogs to spec-ify component properties;

textual, graphical, andhierarchical systemview

parser; compiler; “whatif” scenarios by instan-tiating parameters anddynamic components

compiler; primitive com-ponents are implementedin a traditional program-ming language

compiler generatesC++ code

compilation and runtimesupport forconstraineddynamic change of archi-tectures (replication andconditional configura-tion)

MetaH

graphical editor requires errorcorrection once architecturechanges areapplied; con-strains the choice of compo-nent properties via menus

textual and graphical;component types distin-guished iconically

parser; compiler; sched-ulability, reliability,and security analysis

compiler; primitive com-ponents are implementedin a traditional program-ming language

DSSA approach;compiler generatesAda code

none

Rapide

none textual and graphical;visualization of execu-tion behavior by ani-mating simulations

parser; compiler; analy-sis via event filteringand animation; con-straint checker to ensurevalid mappings

compiler for executablesublanguage; tools tocompile and verify eventpattern maps during sim-ulation

executable simula-tion construction inRapide’s executablesublanguage

compilation and runtimesupport forconstraineddynamic change of archi-tectures (conditionalconfiguration)

SADL

none textual only parser; analysis of rela-tive correctness ofarchitectures withrespect to a refinementmap

checker for adherence ofarchitectures to a manu-ally-proved mapping

none none

UniCongraphical editor preventserrors during design byinvoking language checker

textual and graphical;component and connec-tor types distinguishediconically

parser; compiler; sched-ulability analysis

compiler; primitive com-ponents are implementedin a traditional program-ming language

compiler generates Ccode

none

Weaves

none graphical only; compo-nent and connectortypes (sockets) distin-guished iconically

parser; real-time execu-tion animation; lowoverhead observers;analysis/debuggingcomponents in a weave

none dynamic linking ofcomponents in C,C++, Objective C,and Fortran; no codegeneration

Jacquard allows unantic-ipated dynamic manipu-lation of weaves

Wright

none textual only; modelchecker provides a tex-tual equivalent of CSPsymbols

parser; model checkerfor type conformance ofports to roles; analysisof individual connectorsfor deadlock

none none none

Features

ADL

22 of 24

relationship between architecture and implementation,implemen-tation constraining ADLs have been more successful in generat-ing implementations than “mainstream” (implementationindependent) ADLs. Thus, for example, although C2 is imple-mentation independent, we assumed this 1-to-1 relationship inbuilding the initial prototype of our implementation generationtools [42].

The comparison of existing ADLs highlighted several areaswhere they provide extensive support, both in terms of architec-ture modeling capabilities and tool support. For example, a num-ber of languages use powerful formal notations for modelingcomponent and connector semantics. They also provide a pleth-ora of architecture visualization and analysis tools. On the otherhand, the survey also pointed out areas in which existing ADLsare severely lacking. Only a handful support the specification ofnon-functional properties, even though such properties may beessential for system implementation and management of the cor-responding development process. Architectural refinement andconstraint specification have also remained largely unexplored.Finally, both tools and notations for supporting architecturaldynamism are still in their infancy. Only two ADLs have evenattempted to achieve unanticipated dynamism thus far.

Perhaps most surprising is the inconsistency with which ADLssupport connectors, especially given their argued primary role inarchitectural descriptions. Several ADLs provide only minimalconnector modeling capabilities. Others either only allowmodel-ing of complex connectors (e.g., Wright) or implementation ofsimple ones (e.g., UniCon). C2 has provided the initial demon-stration of the feasibility of implementing complex connectors byemploying existing research and commercial connector technolo-gies, such as Polylith [56] and CORBA [53]. However, thisremains a wide open research issue.

Finally, neither the definition nor the accompanying frame-work have been proposed as immutable laws on ADLs. Quite thecontrary, we expect both to be modified and extended in thefuture. We are currently considering several issues: providing aclearer distinction between descriptive languages (e.g., ACME)and those that primarily enable semantic modeling (e.g., Wright);comparing software ADLs to hardware ADLs; and expanding theframework to include other criteria (e.g., support for extensibil-ity). We have had to resort to heuristics and subjective criteria incomparing ADLs at times, indicating areas where future workshould be concentrated. But what this taxonomy provides is animportant advance towards answering the question of what anADL is and why, and how it compares to other ADLs. Suchinformation is needed both for evaluating new and improvingexisting ADLs, and for targeting future research and architectureinterchange efforts more precisely.

ACKNOWLEDGMENTS

We wish to thank the following people for their insightful com-ments on earlier drafts of this paper: R. Allen, K. Anderson, P.Clements, R. Fielding, D. Garlan, M. Gorlick, W. Griswold, D.Hilbert, A. van der Hoek, P. Kammer, J. Kramer, D. Luckham, J.Magee, R. Monroe, M. Moriconi, K. Nies, P. Oreizy, D. Red-miles, R. Riemenschneider, J. Robbins, D. Rosenblum, R. Selby,

M. Shaw, S. Vestal, J. Whitehead, and A. Wolf. We also thank thereferees of TSE for their helpful reviews.

Effort sponsored by the Defense Advanced Research ProjectsAgency, and Rome Laboratory, Air Force Materiel Command,USAF, under agreement number F30602-97-2-0021. The U.S.Government is authorized to reproduce and distribute reprints forGovernmental purposes notwithstanding any copyright annota-tion thereon. The views and conclusions contained herein arethose of the authors and should not be interpreted as necessarilyrepresenting the official policies or endorsements, eitherexpressed or implied, of the Defense Advanced ResearchProjects Agency, Rome Laboratory or the U.S. Government.

REFERENCES

[1] G. Abowd, R. Allen, and D. Garlan. “Using Style to UnderstandDescriptions of Software Architecture.” InProceedings of the FirstACM SIGSOFT Symposium on the Foundations of SoftwareEngineering, pages 9-20, Los Angeles, CA, December 1993.

[2] R. Allen. “A Formal Approach to Software Architecture.” Ph.D.Thesis, Carnegie Mellon University, CMU Technical Report CMU-CS-97-144, May 1997.

[3] R. Allen, R. Douence, and D. Garlan. “Specifying Dynamism inSoftware Architectures.” InProceedings of the Workshop onFoundations of Component-Based Systems, pages 11-22, Zurich,Switzerland, September 1997.

[4] R. Allen and D. Garlan. “A Formal Basis for ArchitecturalConnection.” ACM Transactions on Software Engineering andMethodology, vol. 6, no. 3, pp. 213-249, July 1997.

[5] R. Allen, D. Garlan, and J. Ivers. “Formal Modeling and Analysis ofthe HLA Component Integration Standard.” InProceedings of theSixth ACM SIGSOFT Symposium on the Foundations of SoftwareEngineering, pages 70-79, Lake Buena Vista, FL, November 1998.

[6] P. Binns, M. Engelhart, M. Jackson, and S. Vestal. “Domain-Specific Software Architectures for Guidance, Navigation, andControl.” International Journal of Software Engineering andKnowledge Engineering, vol. 6, no. 2, 1996.

[7] P. C. Clements. “Formal Methods in Describing Architectures.” InProceedings of the Workshop on Formal Methods and Architecture,Monterey, CA, 1995.

[8] P. C. Clements. “A Survey of Architecture Description Languages.”In Proceedings of the Eighth International Workshop on SoftwareSpecification and Design, Paderborn, Germany, March 1996.

[9] P. C. Clements. “Working Paper for the Constraints Sub-Group.”EDCS Architecture and Generation Cluster (http://www.sei.cmu.edu/~edcs/CLUSTERS/ARCH/index.html), April1997.

[10] E. M. Dashofy, N. Medvidovic, and R. N. Taylor. “Using Off-the-Shelf Middleware to Implement Connectors in Distributed SoftwareArchitectures.” InProceedings of the 21st International Conferenceon Software Engineering (ICSE’99), Los Angeles, CA, May 1999.

[11] D. Garlan, editor.Proceedings of the First International Workshopon Architectures for Software Systems, Seattle, WA, April 1995.

[12] D. Garlan. “An Introduction to the Aesop System.” July 1995.http://www.cs.cmu.edu/afs/cs/project/able/www/aesop/html/aesop-overview.ps

[13] D. Garlan. “Style-Based Refinement for Software Architecture.” InA. L. Wolf, ed.,Proceedings of the Second International SoftwareArchitecture Workshop (ISAW-2), pages 72-75, San Francisco, CA,October 1996.

[14] D. Garlan, R. Allen, and J. Ockerbloom. “Exploiting Style inArchitectural Design Environments.” InProceedings ofSIGSOFT’94: Foundations of Software Engineering, pages 175–188, New Orleans, Louisiana, USA, December 1994.

[15] D. Garlan, R. Monroe, and D. Wile. “ACME: An ArchitectureDescription Interchange Language.” InProceedings ofCASCON’97, November 1997.

23 of 24

[16] D. Garlan, F. N. Paulisch, and W. F. Tichy, editors.Summary of theDagstuhl Workshop on Software Architecture, February 1995.Reprinted inACM Software Engineering Notes, pages 63-83, July1995.

[17] D. Garlan, J. Ockerbloom, D. Wile. “Towards an ADL Toolkit.”EDCS Architecture and Generation Cluster (http://www.cs.cmu.edu/~spok/adl/index.html), December 1998.

[18] C. Ghezzi, M. Jazayeri, D. Mandrioli.Fundamentals of SoftwareEngineering. Prentice Hall, 1991.

[19] J. A. Goguen and T. Winkler. “Introducing OBJ3.” TechnicalReport SRI-CSL-88-99, SRI International, 1988

[20] M. Gorlick and A. Quilici. “Visual Programming in the Large versusVisual Programming in the Small.” InProceedings of the 1994 IEEESymposium on Visual Languages, pages 137-144, St. Louis, MO,October 1994.

[21] M. M. Gorlick and R. R. Razouk. “Using Weaves for SoftwareConstruction and Analysis.” InProceedings of the 13thInternational Conference on Software Engineering (ICSE13), pages23-34, Austin, TX, May 1991.

[22] P. Hagger. “QAD, a Modular Interconnection Language for DomainSpecific Software Architectures.” Technical Report, University ofMaryland, June 1993.

[23] D. Harel. “Statecharts: A Visual Formalism for Complex Systems.”Science of Computer Programming, 1987.

[24] C. A. R. Hoare.Communicating Sequential Processes. PrenticeHall, 1985.

[25] P. Inverardi and A. L. Wolf. “Formal Specification and Analysis ofSoftware Architectures Using the Chemical Abstract MachineModel.” IEEE Transactions on Software Engineering, vol. 21, no. 4,pages 373-386, April 1995.

[26] F. Jahanian and A. K. Mok. “Modechart: A Specification Languagefor Real-Time Systems.” IEEE Transactions on SoftwareEngineering, vol. 20, no. 12, pages 933-947, December 1994.

[27] P. Kogut and P. C. Clements. “Features of Architecture DescriptionLanguages.” Draft of a CMU/SEI Technical Report, December1994.

[28] P. Kogut and P. C. Clements. “Feature Analysis of ArchitectureDescription Languages.” InProceedings of the Software TechnologyConference (STC’95), Salt Lake City, April 1995.

[29] C. W. Krueger. “Software Reuse.”Computing Surveys, vol. 24, no.2, pages 131-184, June 1992.

[30] D. Luckham.ANNA, a Language for Annotating Ada Programs:Reference Manual, volume 260 ofLecture Notes in ComputerScience. Springer-Verlag, Berlin, 1987.

[31] D. C. Luckham, J. J. Kenney, L. M. Augustin, J. Vera, D. Bryan, andW. Mann. “Specification and Analysis of System ArchitectureUsing Rapide.”IEEE Transactions on Software Engineering, vol.21, no. 4, pages 336-355, April 1995.

[32] D. C. Luckham and J. Vera. “An Event-Based ArchitectureDefinition Language.”IEEE Transactions on Software Engineering,vol. 21, no. 9, pages 717-734, September 1995.

[33] D. C. Luckham, J. Vera, D. Bryan, L. Augustin, and F. Belz. “PartialOrderings of Event Sets and Their Application to PrototypingConcurrent, Timed Systems.”Journal of Systems and Software, vol.21, no. 3, pages 253-265, June 1993.

[34] D. C. Luckham, J. Vera, and S. Meldal. “Three Concepts of SystemArchitecture.” Technical Report, CSL-TR-95-674, StanfordUniversity, Palo Alto, July 1995.

[35] J. Magee, N. Dulay, S. Eisenbach, and J. Kramer. “SpecifyingDistributed Software Architectures.” InProceedings of the FifthEuropean Software Engineering Conference (ESEC’95), Barcelona,September 1995.

[36] J. Magee and J. Kramer. “Dynamic Structure in SoftwareArchitectures.” In Proceedings of ACM SIGSOFT’96: FourthSymposium on the Foundations of Software Engineering (FSE4),pages 3-14, San Francisco, CA, October 1996.

[37] J. Magee and D. E. Perry, editors.Proceedings of the ThirdInternational Software Architecture Workshop, Orlando, FL,November 1998.

[38] N. Medvidovic. “ADLs and Dynamic Architecture Changes.” In A.

L. Wolf, ed., Proceedings of the Second International SoftwareArchitecture Workshop (ISAW-2), pages 24-27, San Francisco, CA,October 1996.

[39] N. Medvidovic, P. Oreizy, J. E. Robbins, and R. N. Taylor. “UsingObject-Oriented Typing to Support Architectural Design in the C2Style.” InProceedings of ACM SIGSOFT’96: Fourth Symposium onthe Foundations of Software Engineering (FSE4), pages 24-32, SanFrancisco, CA, October 1996.

[40] N. Medvidovic and D. S. Rosenblum. “Domains of Concern inSoftware Architectures and Architecture Description Languages.”In Proceedings of the USENIX Conference on Domain-SpecificLanguages, pages 199-212, Santa Barbara, CA, October 1997.

[41] N. Medvidovic and D. S. Rosenblum. “Assessing the Suitability ofa Standard Design Method for Modeling Software Architectures.”In Proceedings of the First Working IFIP Conference on SoftwareArchitecture (WICSA1), pages 161-182, San Antonio, TX, February1999.

[42] N. Medvidovic, D. S. Rosenblum, and R. N. Taylor. “A Languageand Environment for Architecture-Based Software Developmentand Evolution.” InProceedings of the 21st International Conferenceon Software Engineering (ICSE’99), Los Angeles, CA, May 1999.

[43] N. Medvidovic, R. N. Taylor, and E. J. Whitehead, Jr. “FormalModeling of Software Architectures at Multiple Levels ofAbstraction.” InProceedings of the California Software Symposium1996, pages 28-40, Los Angeles, CA, April 1996.

[44] R. Milner, J. Parrow, and D. Walker.A Calculus of MobileProcesses, Parts I and II. Volume 100 ofJournal of Information andComputation, pages 1-40 and 41-77, 1992.

[45] R. Monroe. Capturing Software Architecture Design Expertise WithArmani. Technical Report CMU-CS-98-163, Carnegie MellonUniversity, October 1998.

[46] M. Moriconi and R. A. Riemenschneider. “Introduction to SADL1.0: A Language for Specifying Software Architecture Hierarchies.”Technical Report SRI-CSL-97-01, SRI International, March 1997.

[47] M. Moriconi, X. Qian, and R. A. Riemenschneider. “CorrectArchitecture Refinement.” IEEE Transactions on SoftwareEngineering, vol. 21, no. 4,, pages 356-372, April 1995.

[48] M. Moriconi, X. Qian, R. A. Riemenschneider, and L. Gong.“Secure Software Architectures.” InProceedings of the 1997 IEEESymposium on Security and Privacy, Oakland, CA, May 1997.

[49] P. Newton and J. C. Browne. “The CODE 2.0 Graphical ParallelProgramming Language.” InProceedings of the ACM InternationalConference on Supercomputing, July 1992.

[50] K. Ng, J. Kramer, and J. Magee. “A CASE Tool for SoftwareArchitecture Design.” Journal of Automated Software Engineering(JASE), Special Issue on CASE-95, vol. 3, no. 3-4, pp. 261-284,1996.

[51] P. Oreizy. “Issues in the Runtime Modification of SoftwareArchitectures.” Technical Report, UCI-ICS-96-35, University ofCalifornia, Irvine, August 1996.

[52] P. Oreizy, N. Medvidovic, and R. N. Taylor. “Architecture-BasedRuntime Software Evolution.” InProceedings of the 20thInternational Conference on Software Engineering (ICSE’98),pages 177-186, Kyoto, Japan, April 1998.

[53] R. Orfali, D. Harkey, and J. Edwards.The Essential DistributedObjects Survival Guide. John Wiley & Sons, Inc., 1996.

[54] D. E. Perry and A. L. Wolf. “Foundations for the Study of SoftwareArchitectures.”ACM SIGSOFT Software Engineering Notes, vol.17, no. 4, pages 40-52, October 1992.

[55] R. Prieto-Diaz and J. M. Neighbors. “Module InterconnectionLanguages.”Journal of Systems and Software, vol. 6, no. 4, pages307-334, October 1989.

[56] J. Purtilo. “The Polylith Software Bus.”ACM Transactions onProgramming Languages and Systems, vol. 16, no. 1, pages 151-174, January 1994.

[57] Rational Partners. “UML Semantics.” Object Management Groupdocument ad/97-08-04. September 1997. Available from http://www.omg.org/docs/ad/97-08-04.pdf.

[58] Rational Partners. “UML Notation Guide.” Object ManagementGroup document ad/97-08-05. September 1997. Available from

24 of 24

http://www.omg.org/docs/ad/97-08-05.pdf.[59] J. E. Robbins, D. M. Hilbert, and D. F. Redmiles. “Extending Design

Environments to Software Architecture Design.” InProceedings ofthe 1996 Knowledge-Based Software Engineering Conference(KBSE), pages 63-72, Syracuse, NY, September 1996.

[60] J. E. Robbins, N. Medvidovic, D. F. Redmiles, and D. S.Rosenblum. “Integrating Architecture Description Languages with aStandard Design Method.” InProceedings of the 20th InternationalConference on Software Engineering (ICSE’98), pages 209-218,Kyoto, Japan, April 1998.

[61] M. Shaw. “Procedure Calls are the Assembly Language of SystemInterconnection: Connectors Deserve First Class Status.” InProceedings of the Workshop on Studies of Software Design, May1993.

[62] M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G.Zelesnik. “Abstractions for Software Architecture and Tools toSupport Them.”IEEE Transactions on Software Engineering, vol.21, no. 4, pages 314-335, April 1995.

[63] M. Shaw, R. DeLine, and G. Zelesnik. “Abstractions andImplementations for Architectural Connections.” InProceedings ofthe Third International Conference on Configurable DistributedSystems, May 1996.

[64] M. Shaw and D. Garlan. “Characteristics of Higher-LevelLanguages for Software Architecture.” Technical Report, CMU-CS-94-210, Carnegie Mellon University, December 1994.

[65] M. Shaw and D. Garlan. “Formulations and Formalisms in SoftwareArchitecture.” Jan van Leeuwen, editor,Computer Science Today:Recent Trends and Developments, Springer-Verlag Lecture Notes inComputer Science, Volume 1000, 1995.

[66] M. Shaw and D. Garlan.Software Architecture: Perspectives on anEmerging Discipline. Prentice Hall, April 1996.

[67] J. M. Spivey.The Z notation: a reference manual. Prentice Hall,New York, 1989.

[68] M. Shaw, D. Garlan, R. Allen, D. Klein, J. Ockerbloom, C. Scott, M.Schumacher. “Candidate Model Problems in SoftwareArchitecture.” Unpublished manuscript, November 1995. Availablefrom http://www.cs.cmu.edu/afs/cs/project/compose/www/html/ModProb/.

[69] A. Terry, R. London, G. Papanagopoulos, and M. Devito. “TheARDEC/Teknowledge Architecture Description Language (ArTek),Version 4.0.” Technical Report, Teknowledge Federal Systems, Inc.and U.S. Army Armament Research, Development, andEngineering Center, July 1995.

[70] W. Tracz. “LILEANNA: A Parameterized ProgrammingLanguage.” InProceedings of the Second International Workshopon Software Reuse, pages 66-78, Lucca, Italy, March 1993.

[71] S. Vestal. “A Cursory Overview and Comparison of FourArchitecture Description Languages.” Technical Report, HoneywellTechnology Center, February 1993.

[72] S. Vestal. “MetaH Programmer’s Manual, Version 1.09.” TechnicalReport, Honeywell Technology Center, April 1996.

[73] A. L. Wolf, editor. Proceedings of the Second InternationalSoftware Architecture Workshop (ISAW-2), San Francisco, CA,October 1996.

[74] A. L. Wolf. “Succeedings of the Second International SoftwareArchitecture Workshop (ISAW-2).”ACM SIGSOFT SoftwareEngineering Notes, vol. 22, no. 1, pages 42-56, January 1997.