OK York!

步骤4 主要危险区域

确定架构中最容易出错的区域。可以通过质量属性和交叉问题对危险区域进行整理。

质量属性

找出对于应用和场景很重要的质量属性。比如，大部分应用程序都需要解决安全性与性能的问题，而这些问题还需要根据易用性、灵活性等可能更为重要的属性进行权衡分析。

以下是需要注意的重要的质量属性。

范畴	注意事项
有效性	如何设计故障转移支持
	如何设计一个备用站点
	怎样计划备份与恢复
	如何设计运行时的更新
概念完整性	如何分离对外部的依赖性
	如何整合旧技术
	如何在不打断客户的情况下发展系统
灵活性	如何处理动态业务规则
	如何处理动态UI
	如何处理数据与逻辑过程中的变化
	如何处理业务需要的变化
互操作性	如何让应用在独立发展的同时实现互操作
	如何通过服务接口分离系统
	如何通过层的映射分离系统
易维护性	如何减少层与组件之间的依赖性
	如何实现一个插件式的架构
	如何选择合适的通信模型
易管理性	如何了解主要的失败模式
	如何对系统操作与健康状态进行监控
	如何根据负载对系统进行调整
性能	如何确定缓存策略
	如何设计层间的高性能通信
	如何设计高性能数据存取
	如何有效地管理资源
可靠性	如何处理不可靠的外部系统
	如何审查请求与任务
	如何对负载进行重定向
	如何处理失效的通信
	如何处理失效的操作
	如何处理异常
重用性	如何减少层与组件之间的重复性
	如何实现跨系统的共享
	如何实现组件和层之间的功能共享
可扩展性	如何设计可扩展的层与级
	如何扩展
	如何处理传输与负载的测试点
安全性	如何解决认证与授权问题
	如何防止恶意输入
	如何保护敏感数据
支持	如何设计审查与记录
	如何设计使用问题信息的记录
易测性	如何设计才能方便测试
	如何设计单元测试
	如何设计UI自动化
可用性	如何设计才能让用户有更多的权限
	如何改善响应性
	如何避免常见的用户体验问题

架构框架

架构框架代表了你在层与级上可能会遇到的交叉问题。这些也是最容易出现重大设计错误的区域。可以通过架构框架来发现需要额外注意危险区域。

你可以使用以下架构框架来发现需要额外注意的交叉问题。

领域	描述
认证与授权	如何选择认证策略
	如何选择授权策略
	如何在不同层与级之间传递身份消息
	如何在不使用活动目录的情况下存储用户的身份信息
缓存与状态	如何选择合适的缓存技术
	如何决定缓存哪些数据
	如何决定在哪里缓存数据
	如何检查过期策略
通信	如何为不同的层与级选择合适的通信协议
	如何设计层之间的松耦合
	如何实现异步通信
	如何传送敏感数据
组合	如何为用户界面选择组合模式
	如何避免UI模块之间的依赖性
	如何处理UI模块之间通信问题
并发与事件	如何处理并发线程
	如何选择积极并行与保守并行
	如何处理分布式事件
	如何处理长期事件
配置管理	如何确定需要配置的信息
	如何确定在哪里储存配置信息
	如何保护敏感配置信息
	如何处理簇中的配置信息
耦合与内聚	如何选择合适的层策略来分离问题
	如何在层里设计高内聚的组件并对其分组
	如何确定松耦合是否适合层里的组件
数据存取	如何管理数据库的连接
	如何处理异常
	如何改善性能
	如何处理二进制大对象（blob）
异常管理	如何处理异常
	如何记录异常信息
	如何在需要的时候进行通知
日志与器械	如何决定记录哪些信息
	如何让日志可修改
	如何确定需要什么等级的器械
用户体验	如何提高任务的有效性与效率
	如何改善响应性
	如何提高用户权限
	如何改善外观与体验
验证	如何确定在什么位置怎样执行验证
	如何验证长度、范围、格式、类型
	如何限制及拒绝输入
	如何整理输出
工作流	如何选择合适的工作流技术
	如何处理同一工作流中的并发问题
	如何处理工作流中的错误
	如何编排工作流中的过程

步骤5 可用方案

定义了危险区域之后，你就可以创建第一个高层次的设计并着手创建一个可用架构。你可以返回第二步对可用方案及你所定义的关键场景和需求进行再次验证。

架构测试点一种是用来确定具体的设计方式的可行性的设计原型。你可以使用架构测试点来减少风险并迅速检验各种方式的健全性。根据关键场景和危险区域对架构测试点进行测试。

迭代与递增式的架构

这个架构过程应该是迭代和、递增式的。你的第一个可用方案是一个高层次的设计，可以根据针对关键场景、需求、各种限制等进行测试。在你创建了可选架构和架构测试点之后，你将会了解到更多的细节，从而丰富你的场景、应用视图和解决危险区域的方法。每个迭代周期都应该为你的设计添加更多的细节。

下一步怎么做

在你结束了架构建模之后，你可以这样：

如果你把可用架构和架构的测试用例保存在了一个文件里，那么请不要随便往这个文件添加任何多余的东西、避免过分的格式化，这样你可以随时对其进行更新。其主要内容应该包括你的目标、应用类型、部署方式、关键场景、需求、技术、质量属性和测试。

使用质量属性来帮助你的设计与实现。比如，开发人员应该注意与已确定的架构风险相关的反模式，并使用模式协助解决这个问题。

使用架构框架来计划并整理架构测试。

与相关团队成员交流你得到的信息。包括你的应用开发团队、测试团队、以及网络与系统管理员。

如何实现架构的敏捷

使用系统需求和用户需求对可以再次测试的用例的实例进行检验。一个优秀的需求应该能够贯穿架构中用户、业务和系统三个方面。使用用例来对设计进行测试，确定系统中虚弱的部分。系统需求从系统的角度描述应用场景。用户需求从客户的角度描述应用应该可以完成什么任务。这样，你就会根据用途描述需求，并根据质量属性进行检验。你应该在一个迭代周期内完成一个需求所描述的功能。随着架构模型的更新，你可能还需要创建新的需求描述。

在你制定需求描述的时候请注意以下几点：

·在项目的早期创建能够对架构的所有层进行检验的可选架构，从而减少风险。

·关于利用架构模型，根据场景、功能需求、技术需求、质量属性和限制条件调整架构、设计和代码。

·根据你当前的知所创建架构模型，并写出在接下来的需求和迭代周期中必须解决的问题。

·对架构做出足够多的调整后，可以考虑写一个能够反映这些调整的需求描述。把这些调整放到一起解决。

在创建架构的测试点的时候，请考虑以下几点：

·了解你所面临的最大风险，根据这些风险对设计进行调整。

·在敏捷方法中，信息共享是非常重要的；让你的交付成果能够实现更好的信息交流。

·创建架构的时候要考虑到灵活性与重构的问题。你可能需要对架构进行多次调整。

审查架构

对应用架构进行审查是一项非常重要的任务，因为它能够减少错误、尽早地发现并修复架构问题。架构审查是公认的可以降低项目成本、减少架构故障的有效措施。因此在创建架构的时候要让其尽可能地方便交流和审查。这不仅可以提高架构质量，也能减少每次审查所需的时间。

架构审查的主要目标是确定架构能够正确地实现所需的功能并符合质量属性。此外，它还能帮助发现并解决问题。

场景评估

场景评估是进行架构审查的有效方法。在场景评估中，主角是对业务最重要的场景，也是对架构影响最大的场景。以下是几种常用的审查方法：

软件架构分析方法（SAAM）

最初，SAAM是用来评估可修改的特性的。但是后来这一方法被延用到架构审查中，主要面向可修改性、可移植性、可扩展性、整合性以及功能覆盖率等质量属性。SAAM也被用来审查架构的性能、可靠性。

软件架构权衡分析法（ATAM）

ATAM法是SAAM的精炼、改进版本，用于审查架构决策的质量属性、以及具体质量目标的完成度。

主动设计审查（ADR）

这种架构审查方法最适用于未完成或正在进行中的架构。其主要不同点在于每次的审查目标是架构的某个区域而不是架构的整体。

设计中主动审查（ARID）

这种架构审查技术组合了ARD对进行中架构的一系列问题的审查，和ATAM与SAAM的对质量属性的场景审查。

成本效益分析法（CBAM）

这种架构审查方法主要是分析架构决策的成本、收益和对进度的影响。

软件可变性分析（ALMA）

对商业信息系统（BIS）架构的可变性进行评估。

架构系评估方法（FAAM）

这种架构审查技术评估的是信息系统类架构的互通性和扩展性。

沟通

架构设计完成之后，你必须和其他利益相关人讨论这个设计。利益相关人包括开发团队、系统管理员和操作人员、业主以及其它相关团体。有许多关于如何向别人描述架构的方法，下面就是其中一种：

4－1法 这种方法使用了架构的五种视图。其中四种是以不同的方式对架构进行描述。逻辑视图（比如对象模型）、过程视图（比如从并行和同步的角度）、物理视图（软件各层与功能的分布式硬件配置图）和开发视图。第五种视图展示的是软件的场景与用例。这可以让利益相关人了解到他们更为关心的某些方面。

原文链接：How To – Design Using Agile Architecture

转载自IT168 [ http://www.it168.com/ ]
本文链接：http://tech.it168.com/a2009/0427/273/000000273974_7.shtml