Capture and visualization of software architecture design decisions

这个软件工程研究计划是关于将设计决策，特别是大型和长寿命软件密集型系统的架构决策，带到工程过程的前端阶段。最终的目标是支持：1)关于决策的推理，2)支持决策过程，3)提供设计原理，4)支持设计审查，特别是增量设计审查，5)在维护和发展期间维护大型分布式开发的内聚性，6)建议更改的影响分析，以及7)从项目中获取架构经验：重用知识而不仅仅是代码。多年来，软件设计师和架构师一直关注他们所做的设计决策的结果，在考虑中的系统的“设计”或“体系结构”中捕获它们，通常使用UML图等图形。软件体系结构的表示以视图为中心，正如IEEE 1471标准所捕获的那样，或者使用体系结构描述语言。但是这样做，我们失去了很多与决策本身和决策过程相关的知识：基本原理、淘汰的替代方案等。通过仅仅查看系统的设计，或者代码本身，我们很可能会错过决策之间的依赖关系，某些决策的范围，决策如何与需求和需求相关，或者与组织约束相关。随着系统的发展和其原始设计者的移动，系统越来越难以维护，正是因为很难评估某些决策的影响。通常建议的解决方案是努力跟踪设计原理：解释选择的原因，但这在实践中很难做到，因为它需要额外的工作，在做出决定时对设计师没有直接的好处或奖励，因此在实践中几乎从未这样做过。此外，当设计一个新系统时，能够将相互关联的设计决策集与实际设计本身结合在一起会更有用：体系结构知识=体系结构设计+体系结构设计决策。

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.