Part 3

Design Rationale and Software Architecting

I Mistrík
I.

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 with a large particle accelerator. The chapter explains why as-
sumptions are unbounded in number: it is impossible to record and monitor
all the assumptions. However, in order to reduce the risk of software fail-
ure, 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 tech-
niques 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 archi-
tectures 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 architec-
ture. ACM SIGSOFT, Software Engineering Notes 17(4): 40–52
[15] Tyree J, Akerman A (2005) Architecture decisions: Demystifying architec-
ture. IEEE Software 22(2): 19–27