A Rationale-based Model for Architecture Design Reasoning

Chapter 9
Architecture rationale and
traceability
In this chapter, we introduce the traceability methods to support change impact analysis
and root-cause analysis for AREL. Through these traceability methods, we explore
the reasoning support provided by AREL to explain why design objects exist and what
assumptions and constraints they depend on. The results enable software architects to
better understand and reason about an architecture design. Three traceability methods
are discussed in this chapter and the EFT case study is used to demonstrate their applications
1 .
System and software architecture design often involves many implicit assumptions
[135] and convoluted decisions that cut across different parts of the system [109]. A
change in one part of the architecture design could affect many different parts of the
system. A simple shift of an implicit assumption might affect seemingly disparate design
objects and such change impacts could not be identified easily. This intricacy is quite
different from detailed software design where usually the design or program specifications
are self-explanatory. At the system and software architecture level, there are a multitude
of influences that can be implicit, complex and intractable. Without traceable design
rationale, the implicit relationships between the design objects might be lost, therefore
creating potential problems:
• The reconstruction of the design rationale through analysis might be expensive.
• Design criteria and environmental factors that influence the architecture might be
unclear.
1 This chapter is based on our work published in [161].
150