A rationale-based model for architecture design reasoning

Large systems often have a long life-span and their system and software architecture design comprise many intricately related elements. The verification and maintenance of these architecture designs require an understanding of how and why the system are constructed. Design rationale is the reasoning behind a design and it provides an explanation of the design. However, the reasoning is often undocumented or unstructured in practice. This causes difficulties in the understanding of the original design, and makes it hard to detect inconsistencies, omissions and conflicts without any explanations to the intricacies of the design. Research into design rationale in the past has focused on argumentation-based design deliberations. Argumentation-based design rationale models provide an explicit representation of design rationale. However, these methods are ineffective in communicating design reasoning in practice because they do not support tracing to design elements and requirements in an effective manner. In this thesis, we firstly report a survey of practising architects to understand their perception of the value of design rationale and how they use and document this knowledge. From the survey, we have discovered that practitioners recognize the importance of documenting design rationale and frequently use them to reason about their design choices. However, they have indicated certain barriers to the use and documentation of design rationale. The results have indicated that there is no systematic approach to using and capturing design rationale in current architecture design practice. Using these findings, we address the issues of representing and applying architecture design rationale. We have constructed a rationale-based architecture model to represent design rationale, design objects and their relationships, which we call Architecture Rationale and Element Linkage (AREL). AREL captures both qualitative and quantitative rationale for architecture design. Quantitative rationale uses costs, benefits and risks to justify architecture decisions. Qualitative rationale documents the issues, arguments, alternatives and tradeoffs of a design decision. With the quantitative and qualitative rationale, the AREL model provides reasoning support to explain why architecture elements exist and what assumptions and constraints they depend on. Using a causal relationship in the AREL model, architecture decisions and architecture elements are linked together to explain the reasoning of the architecture design. Architecture Rationalisation Method (ARM) is a methodology that makes use of AREL to facilitate architecture design. ARM uses cost, benefit and risk as fundamental elements to rank and compare alternative solutions in the decision making process. Using the AREL model, we have proposed traceability and probabilistic techniques based on Bayesian Belief Networks (BBN) to support architecture understanding and maintenance. These techniques can help to carry out change impact analysis and rootcause analysis. The traceability techniques comprise of forward, backward and evolution tracings. Architects can trace the architecture design to discover the change impacts by analysing the qualitative reasons and the relationships in the architecture design. We have integrated BBN to AREL to provide an additional method where probability is used to evaluate and reason about the change impacts in the architecture design. This integration provides quantifiable support to AREL to perform predictive, diagnostic and combined reasoning. In order to align closely with industry practices, we have chosen to represent the rationale-based architecture model in UML. In a case study, the AREL model is applied retrospectively to a real-life bank payment systems to demonstrate its features and applications. Practising architects who are experts in the electronic payment system domain have been invited to evaluate the case study. They have found that AREL is useful in helping them understand the system architecture when they compared AREL with traditional design specifications. They have commented that AREL can be useful to support the verification and maintenance of the architecture because architects do not need to reconstruct or second-guess the design reasoning. We have implemented an AREL tool-set that is comprised of commercially available and custom-developed programs. It enables the capture of architecture design and its design rationale using a commercially available UML tool. It checks the well-formedness of an AREL model. It integrates a commercially available BBN tool to reason about the architecture design and to estimate its change impacts