架构分析

一、架构分析
架构分析是在功能性需求过程中，有关识别非功能性需求的活动，事实上非功能需求就是质
量需求，这些信息对于架构设计来说，是最值得关注的。
1，架构分析需要解决的问题
下面说明在架构级别上，需要解决的诸多问题的一些示例：
可靠性和容错性需求是如何影响设计的？
购买的子组件的许可成本将如何影响收益？
分布式服务如何影响有关软件质量需求和功能需求的？
适应性和可配置性是如何影响设计的？
2．架构分析的一般步骤
架构分析有多种方法，大多数方法都是以下步骤的变体。
辨识和分析影响架构的非功能性需求。
对于那些具有重要影响的需求而言，分析可选方案，并做出处理这些影响的决定，这就是架
构决策
二、识别和分析架构因素
1，架构因素
2，质量场景
3，架构因素的描述
架构分析的一个重要目标，是了解架构因素的影响、优先级和可变性（灵活性以及未来
演变的直接需要）。因此，大多数架构方法，都提倡对以下信息建立一个架构因素表。
因素 测量和质量场景 可变性（当前灵活性和未来演化） 因素（和其变化）对
客户的影响，架构和
其它因素
优
先
级
困难
或风
险
可靠性 --- 可恢复性
从
远 程
服 务
失 败
中 恢
复。
当远程服务失败
的时候，侦听到远程
服务重新在线的一
分钟内，重新与之建
立联系，在产品环境
下实现正常的存储
装载。
当前灵活性—我们的 SME 认为
直到重新建立连接前，本地客户简
化的服务是可以接受的（也是可取
的）。
演化—在 2 年之内，一些零售商
可能选择支付本地完全复制远程服
务的功能（如税金计算器）。可能
性？高。
对大规模设计影
响大。
零售商确实不愿
意远程服务失败，因
为这将限制或阻止
它们使用 POS 进行
销售。
高 低
…… …… …… ……
注：SME 表示主题专家。
4，从需求文档中获取架构因素
在架构设计中，中心功能需求库就是用例，它的构想和补充规范，都是创建因素表的重
要源泉。在用例中，特殊需求、技术变化、未决问题应该被反复审核。其隐含或者清晰的架
构因素要被统一整理到补充规范里面去。
三、架构因素的解析
架构设计的技巧就是根据权衡、相互依赖关系和优先级对架构因素的解决做出合适的选
择。但这还不全面，老练的架构师具有多种领域的知识（例如：架构样式和模式、技术、产
品、缺陷和趋势），并且能把这些知识应用在它们的决定中。
1，记录架构的可选方案、决定和动机
技术备忘录的格式并不重要，关键是简单、清楚、表达信息完整。
技术备忘录
问题：可靠性---从远程服务故障中恢复
解决方案概要：通过使用查询服务实现位置透明，实现从远程到本地的故障恢复和本地服务的部分复制
架构因素
从远程服务中可靠恢复
从远程产品数据库的故障中可靠恢复
解决方案
在服务工厂创建一个适配器……
动机
零售商不想停止零售活动……
遗留问题
无
考虑过的备选方案
与远程服务厂商签订“黄金级”服务协议……
2，优先级
下面是指导做出架构决定目标：
不可改变的约束，包括安全和法律方面的事务
业务目标
其它全部目标
四、模块化设计策略
1，模块化设计的概念
也就是说，模块并不是越多越好，只有模块数量适当的时候，总体成本才可能下降。
2．实现模块化的手段
抽象：抽出事物的本质特性而暂时不考虑它们的细节。
信息隐蔽：应该这样设计和确定模块，使得一个模块内包含的信息（过程和数据）
对于不需要这些信息的模块来说，是不可访问的。
模块独立性问题：
模块独立是指开发具有独立功能而且和其它模块之间没有过多的相互作用的模块。
模块独立的意义：
1）功能分割，简化接口，易于多人合作开发同一软件；
2）独立的模块易于测试和维护。
模块独立程度的衡量标准：
1）耦合性：对一个软件结构内不同模块间互连程度的度量。
2）内聚性：标志一个模块内各个处理元素彼此结合的紧密程度，理想的内聚模块只
做一件事情。
3，模块化设计的一般准则
1）改进软件结构，提高模块独立性。
2）模块规模应该适中（最好能写在一页纸上）。
大模块分解不充分；小模块使用开销大，接口复杂。
3）尽量减少高扇出结构的数目，随着深度的增加争取更多的扇入。
扇出过大意味着模块过分复杂，需要控制和协调过多的下级模块。一般来说，顶层扇出
高，中间扇出少，低层高扇入。
4）模块的作用范围保持在该模块的控制范围内。
模块的作用范围是指该模块中一个判断所影响的所有其它模块；模块的控制范围指该模
块本身以及所有直接或间接从属于它的模块。
5）力争降低模块接口的复杂程度
模块接口的复杂性是引起软件错误的一个主要原因。接口设计应该使得信息传递简单并
且与模块的功能一致。
6）设计单入口单出口的模块
避免内容耦合，易于理解和维护。
7）模块的功能应该可以预测
相同的输入应该有相同的输出，否则难以理解、测试和维护。