A Survey of Software Architecture Viewpoint Models Nicholas May nick [email protected] Abstract They went on to show that designing software architectures includes determining which patterns of components and in- The documentation of software architecture is carried teractions to use and what constraints are placed on those out in many different ways. One method is to break up patterns. the description into separate perspectives that address the As well as the design process, an important aspect of different concerns that stakeholders have with software software architecture is the production of the relevant docu- architecture. These perspectives, sometimes called view- mentation. A recent summary of the need for documenting points, can contain multiple diagrams to describe the com- software architecture is provided by Bass et al. [2]. They plete system. Various models have been proposed that detail identified three motivating factors which were, to enable viewpoints and specify the stakeholders and concerns that communication of the software architecture among stake- they will satisfy. holders, to capture early design decisions, and to provide In this paper we survey five viewpoint models to deter- re-useable abstractions of software systems [2, p26]. mine the extent to which they cover the software architecture It is a common feature of graphical documentation to domain. We attempt to identify a set of viewpoints from dif- use multiple, concurrent diagrams to describe the entire ferent models can be combined to provide the widest possi- software architecture of a system. This overcomes the prob- ble coverage. lems of crowded diagrams, inconsistent notation, mixing of We found that no model has complete coverage, but an architectural styles, over emphasis of one aspect and the optimal set of viewpoints can be selected from the models. overlooking of individual stakeholder concerns [10, p42]. This optimal set, whilst not providing complete coverage, However, some basis of organization of the diagrams is re- has a greater coverage than any of the individual viewpoint quired. Many informal approaches are used to document models. software architecture, including boxes and lines and simple class diagrams [6]. In addition, at least half a dozen more formal methods for documenting software architecture have 1 Introduction been proposed. These range from notations to systems of diagram classification. A subset of these systems includes In this section we provide an overview of the area of in- those that seek to separate the diagrams based on the needs vestigation, the motivation for this work and the results ob- of the stakeholders. The separation of stakeholder concerns, tained. or requirements, leads to a grouping of diagrams by the per- spective of the software architecture that they show. These 1.1 What is Software Architecture and how is it groups are variously called perspectives, views and view- documented? types, but here we will refer to a perspective as a view- point. The classification systems that utilize these perspec- tives will be called viewpoint models in this paper. Software architecture is the high level structure of a sys- tem. A simple definition of software architecture was pro- vided by Shaw and Garlan [13, p3]: 1.2 What is the purpose of this paper? “The architecture of a software system defines Various models have been proposed of how to create that system in terms of computational compo- documentation by the separation of the concerns. Each nents and interactions among those components.” model describes a set of viewpoints and identifies the con- ¡ cerns that each of them address. The different models cover This paper is an expansion of a dissertation of the same title submitted the same software architecture domain, including the asso- by the author in partial fulfillment of the requirements for the degree of Master of Technology (Information Technology) at RMIT University ciated organizational, business and technological environ- (Melbourne, Australia) in 2004. ments. However, they are not compatible because each 13 model assigns a different significance to each of the en- can be differentiated by the software architecture structures vironments [14], and the vocabulary used to describe the that they can show. The viewpoints will be assessed for their stakeholders and concerns varies between models. coverage of the structures of software architecture, instead The primary purpose of this paper is to gain an under- of the specific models that they can use. standing of the different viewpoint models, their compar- To analyze the viewpoint models, we compare the cover- ative strengths, and their relative coverage of the software age of each viewpoint against a reference framework, con- architecture domain. Due to the limited scope, it is not sisting of lists of elements, including stakeholders, concerns the intention to provide an authoritative comparison frame- and architectural structures. The elements identified are work, but to base the comparison on a standard framework translated into the elements, from the reference list with and a relatively independent set of well documented ele- which they equate. The framework comprises of an initial ments. arbitrary list for each type of element, selected from a rel- In addition to a comparison of models, the classification atively comprehensive source, and additional elements as of viewpoints within a common framework would allow to identified in the viewpoints. combine the viewpoints from different models and deter- mine an optimum set of viewpoints with the greatest cov- 1.3 What were the findings? erage of the software architecture domain. This could form the basis of future documentation techniques. Using the comparison framework, we found that there In this paper we survey five viewpoint models based on was considerable overlap between the viewpoint models. such a framework to determine whether we can combine Then, an optimum set of viewpoints was selected that pro- viewpoints from different models to create an optimum set vided the greatest combined coverage. This primarily con- of with the fewest viewpoints. sisted of the three viewpoints from the SEI model. An ad- The models selected for this survey are as follows: ditional viewpoint, from the Rational ADS, was included to Kruchten’s “4+1” View Model [10]. complement the SEI model with viewpoints focusing on the end user and standard writers. Software Engineering Institute (SEI) set of views [5]. We found that the combined coverage of the surveyed models did not cover the entire software architecture do- ISO Reference Model of Open Distributed Processing main and, therefore, no set could be selected with complete (RM-ODP) [9]. coverage. Siemens Four View model [16]. Rational Architecture Description Specification 2 Background (ADS) [11]. In this section we will answer several questions. What All these models focus on describing software are the structures of software architecture? What is an ar- architecture from multiple perspectives. They each chitectural description? Who are the system stakeholders? specify target stakeholders and recognize the separation What are the stakeholder concerns? The answers to these of concerns. In addition, all these models concentrate on questions will provide a foundation on which to build a describing the structures of software architecture and not classification of software architecture documentation tech- on defining specific notations for each of these structures. niques. To be able to compare the methods of documentation, a common framework is required. This framework should 2.1 What are the structures of software assess the models for the depth of description they pro- architecture? vide, the communication needs they satisfy, and the con- cerns they address. The comparison framework is based Another definition of software architecture is provided on the IEEE Standard 1471-2000 (IEEE 1471), called the by Bass et al. [2, p21]: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems [8]. This defines the con- “The software architecture of a program or com- cepts and their relationships for methods of documenting puting system is the structure or structures of the software architecture. The important part of the standard, system, which comprise software elements, the for this survey, is the relationship that viewpoints have with externally visible properties of those elements, other elements in the framework, specifically stakeholders, and the relationships among them.” concerns and models. The stakeholders and concerns relat- ing to a particular viewpoint are usually explicitly stated, This definition is similar to one proposed by Perry and but the models are not always defined. However, models Wolf [12], as both define software architecture in terms of 14 "£ ¦ ¢ ¦¨( # elements, their properties and relationships. However, they ¢ ) iption ¡£¢¤§¦ © ¢ ¤ ¢ ¡ suggest that the software architecture description is a con- sequence of early design decisions, and so the rationale is ¢ * / ¦ ¢¥" external to and not a part of the architecture itself. 10 ¢ ¦ older ¢¥ w The components and connectors described in the struc- ¡£¡ ¢ ¢ ¢ ¢ tures provide us with a classification of the basic concepts ¢,+-' ¤ * t ¨¤ ¢ ¦ ¢ of software architecture to be documented. sists ¡£¢¥¤§¦¨ © ¢ ¨ of In addition to the structures of software architecture, sys- has ers tems often share common patterns of organization, called establishes! ¢ ¦"¡£ ¥© ¡ &£¤§§¢¥ architectural styles [13,