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.