基于模式的架构评审

　　量属性描述的是系统的易用性、可维护性、性能以及可靠性(虽然不是功能性的)。这些内容可以提高客户满意度，并更好地与类似产品区分。
　　质量属性是全系统级的，所以架构必将对这些属性造成巨大的影响。保罗•克莱门茨(Paul Clements)和他的同事曾这样描述，“一旦架构成型，可变性、性能、安全性、可用性、可靠性也就固定了。如果系统早期架构拙劣，即使再多的后期优化和奇技淫巧也无法对质量做出补救”[1] 不幸的是，这意味着，只有到系统基本开发完成并可以做系统级验收的时候，这些质量才能够得到充分的验证。然而，在系统验收之前，鉴定有关质量问题是非常重要的。
　　架构评审将是一种可行的解决方案：它将能找出潜在的问题,[2], [3], [4] 特别是针对那些相关质量属性的问题。然而，尽管已经证实，这样做很有价值，但很多项目还是不会或不愿意去实施评审。这些项目具有以下特征：
　　时间表很短，还可能包括一系列短周期的迭代开发;
　　项目期限非常紧张，除了生产之外几乎没有空闲时间;
　　忽视文档，特别是像架构文档这样的内部文档;
　　频繁的更改技术或用户需求;
　　小团队;
　　这些特征导致团队关注生产一个仅仅“可工作的”软件，或“只要做出产品”——其他的活动的优先级都很低。由于没有更好的说法，我们用专注生产式来描述这些项目。很多这样的项目(尽管不是全部)遵循敏捷和精益软件开发方法论中的实践。[5], [6], [7]
　　我们创建了一种轻量级的适合专注生产式项目的架构评审过程。它可以确认架构模式并检查这些模式给质量属性带来的作用效果。我们曾使用它评审过九个项目;它并不仅仅可以用来发现重要的架构问题，同时也提高了开发团队对架构的理解。
　　架构评审和专注生产式项目
　　在很多软件架构评审实践中，我们都可以全面地检查架构中的质量属性。[8] 然而，它们在针对专注生产式项目进行架构评审时非常不协调，这体现在以下几个方面：
　　人力资源。 专注生产的项目通常仅有满足简单编写软件的人力资源。即使对小项目进行基于构架权衡分析方法(ATAM-based)的架构评估的近似成本也需要32个员工日(staff day)。[9] 在AT&T，一次架构评审的平均成本是70个员工日(staff day)。[10]
　　成本。已发布推行中的架构评审方法一般都很昂贵。
　　架构文档。 即使很多的架构评审方法都基于对文档的分析，[11] 专注生产式的项目却几乎没有架构文档——这是一个被广泛意识到的问题。[12]
　　需求。 架构评审方法需要详细的需求说明书和相应需求的稳定性——一个过程会需要2到6个星期。 [13] 需求变更带来的大量准备工作会阻碍评审的执行。
　　这些不协调情况致使项目经理们无法评审他们的架构，从而放弃了评审带来的应有的好处。然而，轻量级的评审过程将解决这些不协调情况，同时让这些项目重新受益于架构评审。
　　基于模式的架构评审
　　软件架构模式是指那些处理频繁出现的设计问题的通用解决方案。基于模式的架构评审(PBAR)是一种轻量级的基于软件架构模式的评估方法。这种评审方法提供了一种已被验证的使用模式解决方案的方式，以及如何适应解决方案的效果。[14] 虽然最著名的软件模式是面向对象的设计模式，但在这里我们更关心的是那些涉及系统架构的模式。[15]
　　架构模式关注整个软件系统的设计以及高层次的模块化拆分。[16], [17], [18] 应用现有的架构模式可能使实现某些质量属性更容易或更困难。举个例子，分层模式将系统划分为不同的层次，使得每一层都向它的上一层提供一系列的服务，同时又使用下一层提供的服务。[19]这种结构对故障容错提供了支持，你可以使用分层，从而在出现错误时方便地回滚以实现事务。可是，这种模式需要所有的请求都经历多个层次到达目的地，这使得性能受到了损失。
　　PBAR(基于模式的架构评审)平衡了模式与质量属性的关系，同时产生了一种适用于专注生产式项目的评审。它解决了这些项目与传统架构评审之间的不协调情况：
　　PBAR仅仅需要很少的时间和精力。这非常适合于让小项目专注于编写产品代码。
　　PBAR不需要架构文档。取而代之的是，它总结了正在使用中的架构模式与任何已存在的项目文档，从而推断在这样的情况下，质量属性将如何实现。
　　专注生产式项目允许需求变更。PBAR只需要简短的准备时间，一次简短的评审就可以在1到2天内给项目作出反馈。这使得它可以迅速对需求变更做出响应。
　　此类评审的基本元素与重量级的架构评审并无二致，但是显得更简单，并且更专注。
　　要素和计划
　　评审者需要具备架构，架构模式，质量属性等专业知识和一般的领域常识。评审者应该来自团队之外，这样才能在系统架构设计方面带来新颖的观点——这项工作与其说是内部回顾，更大程度上不如说是一次审核。
　　规划评审
　　在开发周期的早期，一旦确定了系统的基础结构，那么就应该准备规划架构评审了。所有开发人员以及对项目感兴趣的利益相关者都应该被邀请参加评审。参加者不需要做什么正式的准备，但是评审者需要提前掌握好所有相关的架构和需求文档，比如用户故事(user stories)和用例。
　　评审会议及跟踪
　　评审是一次面对面的会议，在其间以下几步将会迭代执行：
　　确定系统中最重要的质量属性并加以讨论。梳理用户故事(user stories)并浏览一遍相关质量属性对应的场景。
　　讨论系统架构(甚至将它画在白板上)。
　　确定出要使用的架构模式。(由评审者完成这个任务，但是其他懂架构模式的参与者可以帮忙)主要的技术是将系统结构与模式结构进行匹配。你希望找到一种成熟的模式，而不是一种新模式，因为我们已经了解这些成熟的模式将对质量属性有何影响，而后者则不然。
　　综合检查架构与质量属性，以确定每种模式对系统的质量属性的作用。评审过去的场景、实现方式以及在架构实现过程中发生的情况。用现有的模式文档去发现模式与质量属性之间的匹配之处(或不匹配的地方)。
　　找出并讨论质量属性的议题，包括哪些质量属性没有被处理，或哪些被充分满足了，哪些模式没有用到但是会带来帮助，以及在模式与质量属性之间存在的冲突。举个例子，分层的架构往往无法符合高性能的需求。

原文转自：http://www.ltesting.net