Abstract

Large systems often have a long life-span and comprise many intricately related elements. The verification and maintenance of these systems require a good understanding of their architecture design. Design rationale can support such understanding but it is often undocumented or unstructured. The absence of design rationale makes it much more difficult to detect inconsistencies, omissions and conflicts in an architecture design. We address these issues by introducing a rationale-based architecture model that incorporates design rationale, design objects and their relationships. This model provides reasoning support to explain why design objects exist and what assumptions and constraints they depend on. Based on this model, we apply traceability techniques for change impact analysis and root-cause analysis, thereby allowing software architects to better understand and reason about an architecture design. In order to align closely with industry practices, we choose to represent the rationale-based architecture model in UML. We have implemented a tool-set to support the capture and the automated tracing of the model. As a case study, we apply this approach to an real-world electronic payment system.

Keywords: Design rationale; Architecture design; Traceability

Article Outline

1. Introduction

2. Background

2.1. Design rationale

2.2. Requirements and design traceability

2.3. Why have traceable design rationale?

3. An architecture model for design rationale capture and tracing

3.1. A conceptual model for design reasoning

3.2. Architecture rationale and elements linkage

3.3. Architecture elements

3.3.1. Architecture element as a motivational reason

3.3.2. Architecture element as a design outcome

3.4. Architecture rationale

3.4.1. Qualitative rationale

3.4.2. Quantitative rationale

3.4.3. Alternative architecture rationale

3.5. Extending AREL to support evolution

4. Traceability support

5. A case study

5.1. Design rationale representation

5.2. Forward and backward tracing

5.2.1. Forward tracing

5.2.2. Backward tracing

5.3. Tracing architecture design evolution

6. Tool support

7. Conclusion

Acknowledgements

References