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 software 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 representing 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 design 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 architecture design knowledge and the experience of using it [1]. − By using design decisions as first class entities to build architecture, rationale management systems can be combined with software architecture, 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 architecture design knowledge. This framework consists of techniques for capturing design knowledge, an approach to distilling design knowledge from patterns, and a data model to characterize the architecture knowledge domain. 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 patterns 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 repository 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 stakeholders throughout the life of the system to determine why important design 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 reasoning. 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, assumptions 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 design, 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 inferencing 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 underlying 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 environment 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 with a large particle accelerator. The chapter explains why assumptions are unbounded in number: it is impossible to record and monitor all the assumptions. However, in order to reduce the risk of software failure, software developers and maintainers should manage the assumptions they are conscious of. They will benefit from using techniques that support the systematic recording of assumptions that they reflect in the software as they make design and implementation decisions. Design rationale techniques can contribute to make explicit many implicit assumptions that are made during software design, and to systematically review the validity of these assumptions over time and releases, helping to reduce the risk of un- anticipated software failure and its consequences. Chapter 16 “Design Decisions: The Bridge between Rationale and Ar- chitecture” by Jan van der Ven, Anton Jansen, Jos Nijhuis, and Jan Bosch presents an approach in which the design decisions underlying software architectures are made explicit. Currently, the design decisions that drive the software architecture design remain implicit and are therefore easily lost and forgotten. This decreases the understandability of the architecture over time. Consequently, it is hard to make changes to the architecture when unknowledgeable about the underlying design decisions. Explicitly describing design decisions in software architecture design deals with these problems. In this new perspective, software architectures are seen as the result of the design decisions underlying them. The design decisions contain rationale, ranging from the issue(s) the decision tries to address to rationale explaining why certain alternative were (not) chosen. In this sense, design decisions act as a bridge between rationale and architecture. Part 3 Design Rationale and Software Architecting 235

As a first step, the Archium tool illustrates that designing architectures with design decisions is feasible. In Archium, a component and connector view of the system can be generated by creating a set of design decisions. The rationale is represented in the design decisions and is made traceable to the architecture. The authors envision that this close integration will help architects to represent the rationale of their decisions, making architectures easier to use and communicate.

References

[1] Basili VR, Caldiera P (1995) Improving software quality reusing knowledge and experience. Sloan Management Review 37(1): 55–64 [2] Bass L, Clements P, Kazman R (2003) Software architecture in practice, 2nd edition. Addison-Wesley, Reading, MA [3] Bosch J (2004) Software architecture: The next step. In: Proceedings of the European workshop on software architecture (EWSA 2004), May 21–22, pp. 194–199 [4] Clements P, Bachmann F, Bass L, Garlan D, Ivers J, Little R, Nord R, Staf- ford J (2002) Documenting Software Architectures: Views and Beyond. Addison-Wesley, Reading, MA [5] Clements P, Kazman R, Klein M (2002) Evaluating Software Architectures: Methods and Case Studies. Addison-Wesley, Reading, MA [6] Curtis B, Krasner H, Iscoe N (1988) A field study of the software design process for large systems. Communications of the ACM 31(11): 1268–1287 [7] Garlan D, Shaw M (1993) An Introduction to Software Architecture. Advances in Software Engineering and Knowledge Engineering 1. World Scientific Publishing, Singapore [8] Gruber T, Russell D (1991) Design knowledge and design rationale: A framework for representation, capture, and use. Technical Report KSL 90- 45, Knowledge Laboratory, Stanford University [9] Hersleb JD, Kuwana E (1993) Preserving knowledge in design projects: What designers need to know. In: Proceedings of the SIGCHI conference on Human factors in computing systems, Amsterdam, pp. 7–14 [10] IEEE (2000) Recommended Practices for Architectural Description of Soft- ware-Intensive Systems. IEEE Standard No. 1471 [11] Moran TP, Carroll JM (1996) Overview of design rationale. In: Design Ra- tionale: Concepts, Techniques, and Use, Moran TP, Carroll JM (eds) Law- rence Erlbaum Associates, pp. 1–19 [12] Obbink H et al (2001) Software architecture review and assessment. Techni- cal Report SARA WG [13] Pena-Mora F, Vadhavkar S (1977) Augmenting design patterns with design rationale. Artificial Intelligence for Engineering Design, Analysis and Manu- facturing 11(2): 93–108 236 I. Mistrík

[14] Perry DE, Wolf AL (1992) Foundations for the study of software architecture. ACM SIGSOFT, Software Engineering Notes 17(4): 40–52 [15] Tyree J, Akerman A (2005) Architecture decisions: Demystifying architecture. IEEE Software 22(2): 19–27