Capture and visualization of software architecture design decisions

点击翻译按钮获取中文摘要

This software engineering research program is about bringing design decisions, and in particular architectural decisions for large and long-lived software-intensive systems, to the front stage of the engineering process. The ultimate objectives are to support: 1) Reasoning about the decisions, 2) Supporting the decision process, 3) Providing a design rationale, 4) Supporting design reviews, in particular incremental design reviews, 5) Maintaining cohesion of large distributed development during its maintenance and evolution, 6) Impact analysis of proposed changes, and 7) Harvesting architectural experience from a project: reusing knowledge rather than just code. For many years software designers and architects have focused on the consequences of the design decisions they made, capturing them in the "design" or the "architecture" of the system under consideration, using often graphics such as UML diagrams. Representations of software architecture were centered on views, as captured by the IEEE 1471 standard, or the usage of an architecture description language. But doing so, we lose much of the knowledge that is attached to the decision itself, and to the decision process: rationale, eliminated alternatives, etc. By just looking at the design of a system, or in the code itself, we're likely to miss the dependencies between decisions, the scope of certain decisions, how the decisions are related to the requirements and needs, or to organizational constraints. As the system evolves and its original designers move on, the system is harder and harder to maintain, precisely because it is difficult to evaluate the impact of certain decisions. The solution often suggested is to diligently keep track of the Design Rationale: an explanation of the reasons of the choices, but this is hard to do in practice, as it requires additional work that has no immediate visible benefit or reward to the designer at the time the decision is made, and therefore it is almost never done in practice. Moreover, when designing a new system, it would be more useful often to be able to see sets of interconnected design decisions together with the actual design itself: Architectural Knowledge = Architectural Design + Architectural Design Decisions.