软考时间安排 >>

软考指定教材 >>

软考视频教程 >>

软考历年真题在线测试 >>

希赛网软考网上辅导招生 >>

希赛网软考串讲面授班招生 >>

希赛网软考冲刺辅导班招生 >>

  3.9.3 ATAM的阶段

  ATAM的活动分四个阶段：1)第0 阶段：为合作关系和准备阶段，评估小组负责人和主要项目决策者进行非正式会议，以确定此次评估的细节，项目代表向评估人简要概述项目，以使评估小组具备适当的专业技术人员的协助。另外对于会议的地点、时间以及后勤保障需要实现达成一致，对于需要什么样的架构文档也需要达成一致。2)第1 和第 2 阶段：为评估阶段，第一阶段，评估小组和项目决策者会晤（通常一天时间），以开始信息收集和分析工作。第二阶段，构架涉众加入到评估中，分析继续进行（一般用两天时间），后面会详细讨论这两个阶段的步骤。3)第3 阶段：小组需要生成一个最终的书面报告。在总结会议中，需要讨论哪些活动比较理想，还有什么需要自我检查和改进的问题，以使评估工作一次比一次更好。下面对第 2和第 3 阶段进行讨论，这就是评估阶段的步骤。第1 步：ATAM 方法的表述 评估负责人需要向参加会议的项目代表介绍ATAM，说明每个人要参与的过程，回答有关问题，负责人需要使用一个简单的演示来简要描述 ATAM步骤和评估的结果。第 2 步： 商业动机的表述评估小组成员需要了解促成这个项目开发的主要商业动机，介绍的问题包括：1)系统最重要的功能。2) 相关技术、管理、经济和政治的限制。3) 该项目相关的商业目标。主要的涉众。4) 架构驱动因素，也就是形成该构架的主要质量属性目标。第 3 步：构架的表述 设计师表述架构的本质，在表述中，设计师首先必须谈到架构的约束条件，以及满足这些条件所使用的模式。在表述中应该抓住重点和本质，讲述构架最重要的方面，而不需要面面俱到甚至关注自己感兴趣但不太重要的方面。在讲述的时候尽可能使用视图而不是文字。第 4 步：对架构方法进行分类 通过对每个质量属性使用的模式，可以对架构方法进行分类，评估小组应该对这些模式和方法进行明确的命名。应该注意到每个方法都影响特定的质量属性，但也可能造成其它不良的影响。比如分层模式提供了可移植性，但很可能是牺牲性能为代价的。这个分类表应该由记录员记录下来，以供所有人传阅。第 5 步：生成质量属性效用树 由于质量属性极大的影响了架构设计，而且不同的架构设计方法对不同的质量属性的影响可能是矛盾的，比如对安全性要求极高的系统，性能极高的架构可能完全是错误的。 所以，我们必须对质量属性的优先级进行分配，可以生成质量属性效用树，这种树实际上是一个鱼骨图，从不同的动机中寻找最主要的原因，具体的方法在系统分析中已经讨论过了，这里不再重复。第 6 步：分析架构方法 在这里，评估小组每次分析一个较高优先级的场景。方法是设计师解释架构如何支持个场景，小组成员通过提问探查设计师用来实现场景的构架方法。在这个过程中，评估小组把相关架构决策编成文档，确定它的有风险决策、无风险决策、敏感点、权衡点，并且对它进行分类。必要时说明设计师是如何避开这种架构的弱点并保证该方法满足要求的。 评估小组的目标是，确信这个方法能够达到质量属性的要求。 下面给出一个场景构架方法分析的表格，需要整体上把有风险决策、无风险决策、敏感点、权衡点列成单独的表，表中 R8、T3、S4 等代表这个表中的条目。

  附件 1：架构图

  至此第一阶段结束，评估小组需要对所获得的知识进行总结，并在 1到 2周的中断时间内与设计师进行非正式会晤（通常用电话形式），如果必要，在这个阶段可以分析更多的场景，也可以解决已澄清的问题。当评估决策者准备就绪，把评估组成员再召集到一起的时候，第二阶段就开始了。此时应该重复前面的第一步，重申在这个阶段每个人所扮演的角色，而且需要概述一下第 2~6 步的结果，并给每个人一份有风险决策、无风险决策、敏感点、权衡点的当前列表，当大家熟悉了以评估结果以后，就可以进行下面的3 步了。第 7 步：集体讨论并确定架构的优先级 上面第 5 步生成的质量属性效用树，主要是为了了解架构设计师是如何看待质量属性构架驱动因素的，对场景进行集体讨论，则是为了了解多数涉众的看法，在参与评估的人员比较多的时候，对场景进行集体讨论非常有效，可以创造出一个人的想法激发其他人灵感的氛围。这种讨论过程，能够促进相互交流、发挥创造性、并起到表达参评人员共同意愿的作用。如果集体讨论确定了优先级的一组场景与效用树进行比较，如果相同，则说明设计师所想的与大多数涉众的想法基本是一致的。如果又发现了其它驱动场景，则可能存在一个风险，表明涉众与设计师的想法不一致。在集体讨论中，不同的涉众对场景的要求可能是不一样的，比如，维护人员可能会更关注易修改性，最终用户可能会关注一个功能或者易操作性，这就需要讨论和平衡。我们鼓励涉众考虑在效用树中尚未分析过的场景，或者是在前面的分析中被认为没有引起足够重视的场景。确定了场景以后，就必须划分优先级，我们必须注意把有限的评估时间用在最重要的地方。首先把涉众认为代表相同行为或者质量属性的场景合并起来，然后投票。投票的方法是，每个涉众拿到总场景数 30%的选票（此数只入不舍，比如 20 个场景，每个人 6 张选票），投票时可以任意使用这些选票，可以全投给一个场景，也可以一个场景投一张。每个涉众都要公开投票，然后评估负责人对场景进行排序，选择“某得票数之上的”场景，供后续步骤使用。第 8 步：分析架构方法 对于已经收集的若干场景并且确定了优先级以后，评估小组引导设计师实现第 7 步中得到的优先级较高的场景。设计师对相关的构架决策如何有助于实现每个场景作出解释。理想情况下，设计师使用已经讨论过的构架方法对这些场景作出解释。第 9 步：结果的表述 最后，把 ATAM分析中得到的各种信息进行归纳总结，并且呈现给涉众。一般来说应该有一个书面报告，包括商业环境、促成该构架的主要需求、约束条件和架构策略等，然后表述如下结果：1)已经写了文档的构架方法。2) 经过讨论得到的场景和优先级。 3) 效用树。4) 所发现的风险决策。5) 已经编成文档的无风险决策。6) 所发现的敏感点和权衡点。我们在评估过程中得到了这些结果，并且对它进行了讨论分类，同时还可以根据一些常见的基本问题或者系统缺陷把风险分解为风险主题，比如没有足够的重视文档编写、未提供备份能力或者为提高可用性等。在这个过程中，很可能把某个经理认为是技术层面的风险，提高为他该关心的某个问题的威胁，这都可能改变后期很多问题的做法。

　相关文章：软件架构设计的思想与模式[3]