Part 3 Design Rationale and Software Architecting I. Mistrík Design rationale as it applies to software architecture has become an established area of software engineering research. Design rationale can be defined as an expression of the relationships between a design product (in this case, an architecture), its purpose, the designer’s (architect’s) concep- tualization and the contextual constraints on realizing the purpose [12]. It represents knowledge that provides the answers to questions about a particular design choice or the process followed to make that choice [8]. Software architecture is concerned with the study of the structure of software, including topologies, properties, constituent components and relationships and patterns of interaction and combination [7,14]. A modern definition of software architecture is given by Bass et al. in [2]: “The soft- ware architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them”. The importance of relating design rationale and software architecting has been recognized by many researchers and practitioners [5,14,15]. Design rationale researchers have developed different representation sche- mas, capture methods, repository models, and use cases for recording design decisions. However, most approaches represent only arguments surrounding design decisions [11]; more work remains to be done in repre- senting domain knowledge in terms that are understandable to the domain experts [9]. During the last 10 years it has been recognized that the quality requirements are heavily influenced by the architecture of the system [2,3] and capturing the relationship between architectural design decisions and quality attributes provides an important new role for rationale. There are important issues that need further research: − Architecture decisions are seldom documented in a rigorous and consis- tent manner. Meaningful explanations should include information explaining the context, reasoning, tradeoffs, criteria, and decision making that led to the selection of a particular design from various de- sign options [3,6]. − Design rationale represents knowledge that provides the answers to questions about a particular design choice or the process followed to make that choice [8]. 232 I. Mistrík − If design rationale is not documented, knowledge concerning the domain analysis, design options evaluated, and decisions made are lost, and so is unavailable to support subsequent decisions in the development lifecycle [3,13]. − The IEEE 1471 Standard [10] and the SARA WG [12] identify design rationale as an important part of descriptions of software architecture and advocate capturing and maintaining rationale. There has been only one significant support mechanism for capturing and managing rationale about architectural decisions namely, the Views and Beyond [4]. How- ever, there is neither sufficient support for all necessary architectural constructs nor conceptual guidance to develop a repository of architec- ture design knowledge and the experience of using it [1]. − By using design decisions as first class entities to build architecture, ra- tionale management systems can be combined with software architec- ture, making architecture easier to use and communicate. Chapters in this part of the book are reporting on advances on the issues mentioned above. In particular, four chapters (Chaps. 11, 12, 14, 16) in this part deal with various aspects of relating design rationale and software architectures. Chap. 13 discusses design rationale in the context of the maintenance and evolution of a designed software product. It presents SEURAT, a system that supports entry and display of the rationale as well as inferences over the rationale. Chapter 15 argues that assumptions management is critical for evolving software, not only at the architectural level, but at all the lev- els of representation of the software and provides high-level recommenda- tions on how this could be achieved. The architectural level is one of the first places in which assumptions management should be done. Chapter 11 “A Framework for Supporting Architecture Knowledge and Rationale Management” by Muhammad Ali Babar, Ian Gorton, and Bar- bara Kitchenham proposes a framework for capturing and managing archi- tecture design knowledge. This framework consists of techniques for cap- turing design knowledge, an approach to distilling design knowledge from patterns, and a data model to characterize the architecture knowledge do- main. The data model not only provides guidelines as to what constitutes architecture rationale but can also be implemented to build a knowledge repository. Their approach to distilling architecture knowledge from pat- terns is one of the means of populating such a repository. The other objec- tive of mining patterns is to capture and represent pattern-based design knowledge at an appropriate level of abstraction. The proposed template is an effective way of representing such knowledge. A design knowledge re- pository can provide a strong motivation for using and capturing rationale Part 3 Design Rationale and Software Architecting 233 during architecture design or evaluation. The novelty of this approach re- sides in its ability to incorporate all three components into an integrated approach to capturing and managing architecture design knowledge. Chapter 12 “Capturing and Using Rationale for Software Architecture” by Len Bass, Paul Clements, Robert Nord, and Judith Stafford presents an approach focused on software architecture rationale that allows stake- holders throughout the life of the system to determine why important de- sign decisions were made, by tracing a design decision causally and as it relates to architectural structures. The architect needs some way to remem- ber the conceptual path he or she has taken during the architecting process, as well as a way not to repeat dead-end design paths. Developers and maintainers can gain important insights from reading the architect’s rea- soning. Testers can design tests to validate the architect’s precepts. Cus- tomers can examine the rationale to convince themselves that their busi- ness goals are being met by the design. Stakeholders in general can read the rationale to make sure their interests have been addressed. Chapter 13 “Rationale-based Support for Software Maintenance” by Janet Burge and David Brown describes SEURAT (Software Engineering Using RATionale) which is a prototype system that provides both retrieval of and inferencing over, rationale. The main goal in developing SEURAT was to study uses of rationale during software maintenance. SEURAT checks for the likely completeness and consistency of design decisions by inferencing over the recorded rationale. The maintainer can also perform “what-if” inferencing by changing the priorities of rationale elements, as- sumptions and requirements to see the impact on the support for previous decisions. Entry and editing screens are provided for rationale capture. While SEURAT was designed for the maintenance phase, it could be used in other phases of development. Decisions made at the early stages of de- sign, such as architecture, are the most risky to change. SEURAT supports software architecting in two ways: (1) it allows the software developer to record their rationale in an argumentation format that captures where se- lecting one alternative spawns additional decisions and (2) it performs in- ferencing over the rationale to check the impact on the system of changing those decisions further along in the development process. Chapter 14 “The Role of Rationale in the Design of Product Line Archi- tectures – A Case Study from Industry” by Jens Knodel and Dirk Muthig reports on an evaluation of alternative architectural concepts for a graphics component, which is a subsystem of an embedded system. The product line engineering aims at an efficient production of variants mainly enabled by large-scale and systematic reuse of artifacts throughout all development phases. A product line’s central artifact is its architecture that defines fun- damental concepts, abstractions, and mechanisms that hold for all products 234 I. Mistrík of an organization (if successful) for a long period of time. Therefore, key developers in organizations must fully agree on all decisions related to the definition of the product line architecture, as well as always reunderstand their rationales during architecture evolution. This chapter describes an in- dustrial case of architecture evolution where one of the key mechanisms of an existing architecture was revisited as the potential subject of change. Chapter 15 “Role and Impact of Assumptions in Software Engineering and its Products” by Meir (Manny) Lehman and J.C. Fernández-Ramil presents the Principle of Software Uncertainty and the reasoning underly- ing it. The principle states that the validity of the results of executing real- world software cannot be absolutely guaranteed. A key argument in the chapter is that every program used in the real-world reflects an unbounded set of assumptions about the environment where it operates. The environ- ment is subject to change and assumptions may become invalid at any time. There have been software failures clearly due to “assumptions which became invalid”. Examples include the software-related destruction of the Ariane 501 rocket and the failure to provide the expected results of experiments