Modeling Software Architectures in the Unified Modeling Language

More documents

Recommendations

Info

Modeling Software Architectures in UML • 3Categories and Subject Descriptors: D.2.2 [Software Engineering]: Design Tools and Techniques;D.2.11 [Software Engineering]: Software ArchitecturesGeneral Terms: Design, Languages, StandardizationAdditional Key Words and Phrases: C2, formal modeling, Object Constraint Language, objectorienteddesign, Rapide, software architecture, Unified Modeling Language, Wright1. INTRODUCTIONSoftware architecture is an aspect of software engineering directed at developinglarge, complex applications in a manner that reduces developmentcosts, increases the potential for commonality among different members ofa closely related product family, and facilitates evolution, possibly at systemruntime [Garlan and Shaw 1993; Perry and Wolf 1992]. The primary focusof architecture-based software development is shifted from lines-of-code tocoarser-grained architectural elements, their high-level interactions, and theiroverall interconnection structure. This enables developers to abstract away unnecessarydetails and focus on the “big picture”—system structure, high-levelcommunication protocols, assignment of software components and connectorsto hosts, development process, and so on [Garlan and Shaw 1993; Kruchten1995; Luckham and Vera 1995; Perry and Wolf 1992; Soni et al. 1995; Tayloret al. 1996]. The basic promise of software architecture research is that bettersoftware systems can result from modeling their important architectural aspectsthroughout, and especially early in, the development lifecycle. Choosingwhich aspects to model and how to evaluate them are two decisions that framesoftware architecture research [Medvidovic and Rosenblum 1997].To date, the software architecture research community has focused predominantlyon analytic evaluation of architectural descriptions. Many researchershave come to believe that, to obtain the benefits of an explicit architecturalfocus, software architecture must be provided with its own body of specificationlanguages and analysis techniques [Garlan 1995; Garlan et al. 1995; Mageeand Perry 1998; Wolf 1996]. Such languages are needed to define and analyzeproperties of a system upstream in its development, thus minimizing the costsof detecting and removing errors. The languages are also needed to provideabstractions that are adequate for modeling a large system, while ensuringsufficient detail for establishing properties of interest. A large number of architecturedescription languages (ADLs) have been proposed [Allen and Garlan1997; Garlan et al. 1994; Luckham and Vera 1995; Magee and Kramer 1996;Medvidovic et al. 1999; Medvidovic et al. 1996; Moriconi et al. 1995; Shaw,De Line et al. 1995; Vestal 1996].Each ADL embodies a particular approach to the specification and evolutionof an architecture. Answering specific evaluation questions demands powerful,specialized modeling and analysis techniques that address specific systemaspects in depth. However, the emphasis on depth over breadth of the modelcan make it difficult to integrate these models with other development artifactsbecause the rigor of formal methods draws the modeler’s attention awayfrom day-to-day development concerns. The use of special-purpose modelingACM Transactions on Software Engineering and Methodology, Vol. 11, No. 1, January 2002.
4 • N. Medvidovic et al.Table I. Software Architecture Community FragmentationResearch CommunityPractitioner CommunityMajor Focus Analytic evaluation of architectural Wide range of development issuesmodelsArtifacts Individual models Families of models to span andrelate issuesRigor Formal modeling notations Practicality over formalityPrimary Goal Powerful analysis techniques Architecture as “big picture”in developmentScope Depth over breadth Breadth over depthOutcome Special-purpose solutions General-purpose solutionslanguages has made this part of the architecture community fairly fragmented,as revealed by a recent study of ADLs [Medvidovic and Taylor 2000].Another community, primarily from industry, has focused on modeling a widerange of issues that arise in software development, perhaps with a family of(often less formal) models that span and relate the issues of concern. By payingthe cost of making such models, developers gain the benefit of clarifyingand communicating their understanding of the system. However, emphasizingbreadth over depth potentially allows many problems and errors to go undetectedbecause lack of rigor allows developers to ignore some important details.These two predominant perspectives on software architecture are summarizedin Table I, which compares them along a number of important dimensions.We acknowledge that the positions of the two communities are significantlymore complex than represented in the table. However, we believe that the tableprovides a useful, if simplified, overview of the relationship between the twocommunities and shows the need to bridge the chasm between them.As in the case of the numerous ADLs produced by the research community,several competing notations have been used in the practitioner community.However, there now exists a concerted effort to standardize on notationsand methods for software analysis and design. Standardization provides aneconomy of scale that results in more and better tools, better interoperabilitybetween tools, a larger number of available developers skilled in using the standardnotation, and lower overall training costs. One hypothesis of this paper isthat the benefits of standardization need not be achieved at the expense of losingthe power afforded by specialized notations. Instead, when special-purpose notationsare needed, they can often be based on, or related to, standard notations.Specifically, in this paper we investigate the possibility of using the UnifiedModeling Language (UML) [Booch et al. 1998], an emerging standard softwaredesign language, as a starting point for bringing architectural modeling intowider, industrial use. At first glance, UML appears to be well suited for thisbecause it provides a large, useful, and extensible set of predefined constructs,is semiformally defined, has the potential for substantial tool support, and isbased on experience with mainstream development methods. The primary goalof this work is an assessment of UML’s expressive power for modeling softwarearchitectures in the manner in which existing ADLs model architectures.To this end, we have conducted an extensive examination of UML’s ability toACM Transactions on Software Engineering and Methodology, Vol. 11, No. 1, January 2002.
Page 1: Modeling Software Architectures in
Page 5 and 6: 6 • N. Medvidovic et al.architect
Page 7 and 8: 8 • N. Medvidovic et al.Fig. 3.An
Page 9 and 10: 10 • N. Medvidovic et al.Fig. 4.
Page 11: 12 • N. Medvidovic et al.Fig. 5.T
Page 14 and 15: Modeling Software Architectures in
Page 24: Modeling Software Architectures in
Page 27 and 28: 28 • N. Medvidovic et al.with the
Page 31 and 32: 32 • N. Medvidovic et al.Table II
Page 33 and 34: 34 • N. Medvidovic et al.self.par
Page 35 and 36: 36 • N. Medvidovic et al.placehol
Page 39 and 40: 40 • N. Medvidovic et al.(?A : Na
Page 43 and 44: 44 • N. Medvidovic et al.Rule2. U
Page 45 and 46: 46 • N. Medvidovic et al.componen
Page 47 and 48: 48 • N. Medvidovic et al.6.2 Arch
Page 49 and 50: 50 • N. Medvidovic et al.the “a
Page 51 and 52: 52 • N. Medvidovic et al.7.1.4 Ar
Page 53 and 54:
54 • N. Medvidovic et al.completi
Page 55 and 56:
56 • N. Medvidovic et al.MEDVIDOV
show all

Modeling Software Architectures in the Unified Modeling Language

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?