The Architecture Based Design Method * Felix Bachmann Len Bass Gary Chastek Patrick Donohoe * Fabio Peruzzi January 2000 TECHNICAL REPORT CMU/SEI-2000-TR-001 * Fellix Bachmann and Fabio Peruzzi are employees ESC-TR-2000-001 of Robert Bosch, GmBH. blank page (to be thrown out immediately before production) Pittsburgh, PA 15213-3890 The Architecture Based Design Method CMU/SEI-2000-TR-001 ESC-TR-2000-001 Felix Bachmann Len Bass Gary Chastek Pat Donohoe Fabio Peruzzi January 2000 Program Affiliation Len Bass, Gary Chastek and Pat Donohoe work in the Product Line Systems program of the Software Engineering Institute. Felix Bachmann and Fabio Peruzzi are employees of Robert Bosch, GmBH. Unlimited distribution subject to the copyright. This report was prepared for the SEI Joint Program Office HQ ESC/DIB 5 Eglin Street Hanscom AFB, MA 01731-2116 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. FOR THE COMMANDER Norton L. Compton, Lt Col., USAF SEI Joint Program Office This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. Copyright 2000 by Carnegie Mellon University. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works. External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent. This work was created in the performance of Federal Government Contract Number F19628-95-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 52.227-7013. For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site (http://www.sei.cmu.edu/publications/pubweb.html). Table of Contents 1 Introduction 1 2 Quick Overview of the ABD Method 3 3 Terminology 5 3.1 Design Elements 5 3.2 Perspectives and Views 6 3.3 Use Cases and Quality Scenarios 7 4 Architecture Design Considerations 9 4.1 Variabilities and Commonalities 9 4.2 Software Templates and System Infrastructure 10 4.3 Architectural Drivers 11 4.4 Requirements, Quality Attributes, Functionality and Architectural Styles 12 5 The ABD Method Within the Life Cycle 15 5.1 Abstract Functional Requirements 16 5.2 Use Cases 16 5.3 Abstract Quality and Business Requirements 17 5.4 Architecture Options 17 5.5 Quality Scenarios 18 5.6 Constraints 18 6 The ABD Method 19 6.1 Design Elements Defined by the Method 19 6.2 Order of Generation of Design Elements 20 6.3 Activities within a Design Element 22 6.3.1 Divide Functionality 23 6.3.2 Choose Architectural Style 25 6.3.3 Allocate Functionality to Style 26 6.3.4 Refine Templates 26 6.3.5 Verify Functionality 27 6.3.6 Generate Concurrency View 28 CMU/SEI-2000-TR-001 i 6.3.7 Generate Deployment View 28 6.3.8 Verify Quality Scenarios 29 6.3.9 Verify Constraints 29 6.4 Next Steps 29 7 Conclusions and Further Work 31 8 References 33 Appendix A - Rose Model of an Example 35 A.1 Rose Constructs 35 A.2 Directory Structure 36 Appendix B. Example 41 B.1 Logical View 41 B.2 Concurrency View 42 B.3 Deployment View 43 ii CMU/SEI-2000-TR-001 List of Figures Figure 1: Labeling of Decomposition 6 Figure 2: The ABD Method within the Life Cycle 15 Figure 3: Decomposition of System into Design Elements 20 Figure 4: Design Element A Decomposed into Design Elements B and C 21 Figure 5: Steps within Decomposition of a Design Element 22 Figure 6: Defining Logical View 23 Figure 7: Top Level Package Structure 36 Figure 8: Requirement Sub-Structure 38 Figure 9: Subdirectory Structure for the Architecture Directory 40 Figure 10: Example Subsytem Structure 41 Figure 11: Thread View During Initialization 42 Figure 12: Mapping of Design Elements to Units of Deployment 44 Figure 13: Alternative Node Structures 45 Figure 14: Distribution of the Units of Distribution and Processes for the Product Based on Node Structure 1 45 Figure 15: Distribution of the Units of Distribution and Processes for the Product Based on Node Structure 2 46 Figure 16: Communication Mechanisms for the Product Based Node Structure 1 47 Figure 17: Communication Mechanisms for the Product Based on Node Structure 2 47 Figure 18: Virtual Threads vs. Physical Threads 49 Figure 19: Use Case Mapping 50 CMU/SEI-2000-TR-001 iii iv CMU/SEI-2000-TR-001 Abstract This paper presents the Architecture Based Design (ABD) method for designing the high- level software architecture for a product line or long-lived system. Designing an architecture for a product line or long-lived system is difficult because detailed requirements are not known in advance. The ABD method fulfills functional, quality, and business requirements at a level of abstraction that allows for the necessary variation when producing specific prod- ucts. Its application relies on an understanding of the architectural mechanisms used to achieve this fulfillment. The method provides a series of steps for designing the conceptual software architecture. The conceptual software architecture provides organization of function, identification of synchro- nization points for independent threads of control, and allocation of function to processors. The method ends when commitments to classes, processes and operating system threads be- gin to be made. In addition, one output of the method is a collection of software templates that constrain the implementation of components of different types. The software templates include a description of how components interact with shared services and also include “citi- zenship” responsibilities for components. CMU/SEI-2000-TR-001 v vi CMU/SEI-2000-TR-001 1 Introduction Designing a software architecture for a product line of systems is a difficult undertaking. Product lines must be long lived and flexible. Moreover, they must support a set of require- ments that are known only in broad scope—the details are unknowable until the actual prod- ucts are created. Furthermore, the initial stages of architecture design are where the most fun- damental design decisions are made; these are the decisions that are the most difficult to correct when they are in error. In order to effectively design a product line architecture, the architect needs a disciplined design method that focuses the creative process; provides a strategy for coping with the uncertainty in requirements; provides guidance in organizing the decisions made during the design process; and makes clear why the steps of the method exist and how they relate to each other. In this report, we present the Architecture Based Design (ABD) method. The ABD method provides structure in producing the conceptual architecture of a system. The conceptual ar- chitecture is one of four different architectures identified by Hofmeister, Nord, and Soni [Hofmeister 00]. It describes the system(s) being designed in terms of the major design ele- ments and the relationships among them. The conceptual architecture represents the first de- sign choices made during a development process. Consequently, it is pivotal to achieving the quality and business goals for the system(s) and in providing a basis for the achievement of the desired functionality. The ABD method depends on determining the architectural drivers for a system. The archi- tectural drivers are the combination of business, quality and functional requirements that “shape” the architecture. With the ABD method, design activities can begin as soon as the architectural drivers have been determined with confidence. This means that the requirements elicitation and analysis activities do not have to be completed (or even very far along) prior to beginning the design. The beginning of design activities does not mean that requirement elicitation and analysis can be discontinued, only that they can go on in parallel with design activities. Especially in situations where determining all of the requirements in advance is not possible, such as for product lines or long-lived systems, the ability to quickly begin design (and hence some level of construction) is important. The ABD method has three foundations. First is the decomposition of function. For this the method uses well-established techniques based on coupling and cohesion. The second foun- dation is the realization of quality and business requirements through the choice of architec- ture style. The third foundation is the use of software templates. Software templates have CMU/SEI-2000-TR-001 1 been utilized in the construction of some systems [Bass 98, Chastek 96].