什么是进行轻量级体系结构评估的好方法？

Question

我熟悉体系结构评估方法，如技术建筑权衡分析法(阿塔姆)和更面向业务的成本效益分析法(CBAM)。然而，这些方法的规模相当大:它们规定了几次头脑风暴会议、演示、开发一系列描述权衡的场景，等等。虽然对一定规模的项目有用，但对于通常由少数开发人员(或更少的)开发的内部项目或桌面应用程序来说，它们太大了，尽管它们很小，但质量约束相当严重(性能、可伸缩性、适应性)。

我在过去使用过的一个典型实践是让一个开发人员(或者如果一个团队有一个开发人员)为应用程序提出一个通用的体系结构，然后在白板上与团队的其他成员讨论它，通常使用一些易于绘制和理解的伪UML符号。这通常会导致对体系结构的反馈和一些迭代。但这往往是有点过于非正式，导致各种假设的作出，后来可能是错误的决定。

像ATAM这样的方法通常会迫使所有涉众对体系结构进行深入的思考，这将导致讨论，直到每个人至少就体系结构到底是什么达成一致。

有人有做轻量级的前期架构评估的经验吗？如果是的话，什么是好做法？

Answer 1

轻量级评估的关键是在正确的时间对正确的事物进行评估。我知道有两种方法可以有效地做到这一点。对于基于场景的评估，您可以使用质量属性场景和用例来驱动评估，只关注高优先级的质量属性。通过基于风险的评估，您可以识别风险，并让已识别的风险驱动您的架构设计活动。

我可以推荐两本书，探讨这两种(有些相关的)方法。

安东尼·拉坦泽( Anthony Lattanze )的构建软件密集型系统介绍了以架构为中心的设计方法，并涵盖了基于轻量级场景的评估。您可以从SEI的质量属性研讨会中识别Lattanze，并且涉及到类似的想法。

乔治·费尔班克斯( George )的仅仅足够的软件体系结构:一种风险驱动的方法介绍了一种设计和评估软件系统体系结构的风险驱动方法。如果您想要预览，也有一些免费章节可在他的网站上查阅。。虽然这本书中的原则是立即适用的，但这种方法并没有具体的方法，所以你需要结合其他领域的想法。我强烈建议采用SEI公司持续风险管理方法来识别/确定风险的优先级。

这些方法背后的基本思想是，您可以通过评估来降低评估(和设计)的成本，而不是等到最后。虽然这肯定比在白板上闲聊要重一些，但它并不像完全吹嘘的阿塔姆那样昂贵。如果你感到舒服，你可以选择适合你的特定需求的练习。

不管你用哪种方法来进行评估，总的想法都是一样的.

在开始之前：

• 质量属性方案或风险，按优先级排列(如果只有这些，则可以是非正式的)
• 明确定义go/no-go决策(您如何知道体系结构“足够好”)
• 架构描述的最新片段(您正在评估的工件)

坐下来参加一次评估会议：

• 架构师介绍了架构的概述。
• 浏览视图，展示场景或风险是如何满足的。
• 问题将记录下来，待以后再解决。
• 角色和一般程序类似于Fagan检查(架构师或作者、版主、记录器)。
• 根据系统的大小，会话可能只需一到两个小时。

会议结束后：

• 审查已确定的问题，并确定是否符合go/no-go标准。通常情况下，每件事都要经过3次审查才能解决。如果不满足，继续改进和试验(或减轻体系结构风险)。
• 这不是一个“全部或无”的评估--您的体系结构的不同部分可能会“通过”，而其他部分仍然需要改进。

为了帮助您了解基于场景的方法可能是什么样子，我在研究生院工作过的来自一个顶点项目的一些公开文件。文档有点粗糙，但它可以帮助提供一些ACDM背景下基于场景的方法的示例。我们是一个由5人组成的团队，构建了一个典型的基于web的应用程序，大约35 KLOC Java/GWT。

Answer 2

首先，我喜欢非正式的白板讨论。我喜欢只编写今天需要的应用程序的一部分，然后在实现过程中逐渐让体系结构出现。这更像是“找到架构”，而不是试图事先发明它。这种方法不需要太多的预先评估，它可以帮助您将注意力集中在重要的(交付工作软件)上。

当然，如果您的非功能性需求需要它(内存约束、响应时间、并发用户数量等)，那么在实现系统时必须考虑到这一点。