New version page

ADL-TSE

This preview shows page 1-2-23-24 out of 24 pages.

View Full Document
View Full Document

End of preview. Want to read all 24 pages?

Upload your study docs or become a GradeBuddy member to access this document.

View Full Document
Unformatted text preview:

A Classification and Comparison Framework forSoftware Architecture Description LanguagesNenad Medvidovic and Richard N. Taylor, Member, IEEE Computer SocietyAbstractÐ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 supportarchitecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of anarchitecture 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 aclassification framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modelingnotations. The framework is used to classify and compare several existing ADLs, enabling us, in the process, to identify key propertiesof ADLs. The comparison highlights areas where existing ADLs provide extensive support and those in which they are deficient,suggesting a research agenda for the future.Index TermsÐSoftware architecture, architecture description language, component, connector, configuration, definition,classification, comparison.æ1INTRODUCTIONSOFTWARE architecture research is directed at reducingcosts of developing applications and increasing thepotential for commonality between different members of aclosely related product family [54], [66]. Software develop-ment based on common architectural idioms has its focusshifted from lines-of-code to coarser-grained architecturalelements (software components and connectors) and theiroverall interconnection structure. To support architecture-based development, formal modeling notations and analy-sis and development tools that operate on architecturalspecifications are needed. Architecture description lan-guages (ADLs) and their accompanying toolsets have beenproposed as the answer. Loosely defined, ªan ADL forsoftware applications focuses on the high-level structure ofthe overall application rather than the implementationdetails of any specific source moduleº [71]. ADLs haverecently become an area of intense research in the softwarearchitecture community [11], [16], [73], [37].A number of ADLs have been proposed for modelingarchitectures, both within a particular domain and asgeneral-purpose architecture modeling languages. In thispaper, we specifically consider those languages mostcommonly 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].1Recently, initial work has been done on an architectureinterchange language, ACME [15], which is intended tosupport mapping of architectural specifications from oneADL to another and, hence, enable integration of supporttools across ADLs. Although, strictly speaking, ACME isnot an ADL, it contains a number of ADL-like features.Furthermore, it is useful to compare and differentiate itfrom other ADLs to highlight the difference between anADL and an interchange language. It is therefore, includedin this paper.There is, however, still little consensus in the researchcommunity on what an ADL is, what aspects of anarchitecture should be modeled by an ADL, and whatshould be interchanged in an interchange language [43]. Forexample, Rapide may be characterized as a general-purposesystem description language that allows modeling ofcomponent interfaces and their externally visible behavior,while Wright formalizes the semantics of architecturalconnections. Furthermore, the distinction is rarely madebetween ADLs on one hand and formal specification,module interconnection (MIL), simulation, and program-ming languages on the other. Indeed, for example, Rapidecan be viewed as both an ADL and a simulation language,while Clements contends that CODE [49], a parallelprogramming 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 can be argued that the primary role of architecturaldescriptions is to aid understanding and communicationabout a software system. As such, an ADL must have70 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 26, NO. 1, JANUARY 2000. N. Medvidovic is with the Department of Computer Science, University ofSouthern California, Los Angeles, CA 90007-4313. E-mail: [email protected] R.N. Taylor is with the Department of Information and Computer Science,University of California, Irvine, CA 92697-3425. E-mail: [email protected] received 13 Feb. 1998; revised 29 Dec. 1998; accepted 18 Feb.1999.Recommended for acceptance by M. Jazayeri.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number 106346.1. The full name of the ADL for modeling architectures in the C2architectural style is ªC2SADEL.º To distinguish it from SADL, whichresulted from an unrelated project,C2SADEL will be referred to simply asªC2º in this paper.0098-5589/00/$10.00 ß 2000 IEEEsimple, understandable, and possibly graphical syntax,well-understood, but not necessarily formally definedsemantics, and the kinds of tools that aid visualization,understanding, and simple analyses of architectural de-scriptions (e.g., Argo [59]). At the other end of the spectrum,the tendency has been to provide formal syntax andsemantics of ADLs, powerful analysis tools, model check-ers, parsers, compilers, code synthesis tools, runtimesupport tools, and so on (e.g., SADL's architecture refine-ment patterns [47], Darwin's use of -calculus to formalizearchitectural semantics [36], or UniCon's parser andcompiler [62]). While both perspectives have merit, ADLresearchers have generally adopted one or the otherextreme view. It is our contention that both are importantand should be reflected in an ADL.Several researchers have attempted to shed light on theseissues, either by surveying what they consider existingADLs [8], [27], [28], [71] or by listing ªessential require-mentsª for an ADL [32], [62], [64], [65]. In our previouswork, we attempted to understand and


Loading Unlocking...
Login

Join to view ADL-TSE and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view ADL-TSE and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?