系统架构设计师-软件架构设计（4）

目录

一、软件架构评估

        1、敏感点

        2、权衡点

        3、风险点

        4、非风险点

        5、架构评估方法

                5.1 基于调查问卷或检查表的方式

                5.2 基于度量的方式

                5.3 基于场景的方式

        6、基于场景的评估方法

                6.1 软件架构分析法（SAAM）

                6.2 架构权衡分析法（ATAM）

                6.3 成本效益分析法（CBAM）

        7、质量效用树 

二、软件产品线

        1、基本概念 

        2、双生命周期模型

        3、建立方式

        4、组织结构

---

一、软件架构评估

        1、敏感点

                敏感点是一个或多个构件（和 / 或构件之间的关系）的特性，它能影响系统的某个质量属性。

        2、权衡点

                 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

        3、风险点

                 风险点是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

        4、非风险点

                非风险点是指不会带来隐患，一般以 “XXX要求是可以实现（或接受）的” 方式表达。

        例如：

        （1）对交易请求处理时间的要求将影响系统数据传输协议和处理过程的设计；（敏感点）

        （2）假设每秒钟用户交易请求的数量是10个，处理请求的时间为30毫秒，则 “在1秒内完成用户的交易请求” 这一要求是可以实现的；（非风险点）

        （3）目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性；（风险点）

        （4）更改加密级别将对安全性和性能产生影响；（权衡点）

        5、架构评估方法

                5.1 基于调查问卷或检查表的方式

                5.2 基于度量的方式

                5.3 基于场景的方式

                【场景】是从风险承担者的角度与系统交互的简短描述。

                场景可从六个方面进行描述：刺激源、刺激、制品、环境、响应、响应度量

                【性能场景示例】

                质量属性场景的六个构成部分：

                【刺激源（Source）】这是某个生成该刺激的实体（人、计算机系统或者任何其他刺激器）。

                【刺激（Stimulus）】该刺激是当刺激到达系统时需要考虑的条件。

                【环境（Environment）】该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。

                【制品（Artifact）】某个制品被激励。这可能是整个系统（或系统的一部分）。

                【响应（Response）】该响应是在激励到达后所采取的行动。

                【响应度量（Measurement）】当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

                例1：系统能够连续运行的时间不小于1000小时，闪退后能在15s内自动重启。

                        刺激源：系统故障

                        刺激：闪退

                        环境：系统正常运行

                        制品：系统

                        响应：自动重启

                        响应度量：连续运行时间不小于1000小时、15s内自动重启

                例2：更改Web界面接口必须在2人周内完成。

                        刺激源：提出Web界面接口修改需求的人

                        刺激：Web界面接口修改

                        环境：系统设计时

                        制品：Web界面接口相关模块

                        响应：完成Web界面接口修改

                        响应度量：2人周内完成

                例1：正常负载情况下系统必须在0.5s内对用户的交易请求进行响应。

                        刺激源：用户的交易请求

                        刺激：交易请求

                        环境：系统正常负载

                        制品：系统

                        响应：响应用户的交易请求

                        响应度量：0.5s内响应用户的交易请求

                例1：测试人员在开发期间针对一个代码单元，执行一个测试序列，获取结果，并在20分钟内完成测试。

                        刺激源：测试人员

                        刺激：执行测试序列

                        环境：开发期间

                        制品：代码单元

                        响应：完成测试获取结果

                        响应度量：20分钟内

                例1：新用户学习使用系统的时间不超过2小时。

                        刺激源：新用户

                        刺激：学习使用系统

                        环境：系统运行时

                        制品：系统

                        响应：学会使用系统

                        响应度量：2小时

                例1：信用卡支付必须保证99.999%的安全性。

                        刺激源：信用卡用户

                        刺激：信用卡支付

                        环境：系统正常运行

                        制品：系统支付相关服务

                        响应：安全完成支付

                        响应度量：99.999%

        6、基于场景的评估方法

                6.1 软件架构分析法（SAAM）

                         最初关注可修改性，后扩充到可移植性、可扩充性，最早形成文档并得到广泛使用的软件架构分析方法。

                6.2 架构权衡分析法（ATAM）

                         由SAAM发展而来，主要针对：性能、实用性（可用性）、安全性、可修改性，在系统开发之前，对这些质量属性进行评价和折中。

                6.3 成本效益分析法（CBAM）

                         在ATAM（架构权衡分析法）基础上建立的，软件的 “经济” 模型。

        7、质量效用树 

二、软件产品线

        1、基本概念 

                软件产品线是指具有一组可管理的公共特性的软件密集性系统的合集，这些系统满足特定的市场需求或任务需求，并且按预定义的方式从一个公共的核心资产集开发得到。

        2、双生命周期模型

                分成两个重叠的生命周期：领域工程和应用工程。

                领域工程使用DSSA（特定领域软件架构），主要任务有领域分析，领域设计，领域实现。

                应用工程领域：需求分析，系统设计，系统实现。

        3、建立方式

        （1）将现有产品演化为产品线

        （2）用软件产品线替代现有产品集

        （3）全新软件产品线的演化

        （4）全新软件产品线的开发

        4、组织结构

                组织结构类型：

                （1）设立独立的核心资源小组

                （2）不设立独立的核心资源小组

                （3）动态的组织结构

                要成功实施产品线，主要取决于以下因素

                （1）对该领域具备长期和深厚的经验

                （2）一个用于构建产品的好的核心资源库

                （3）好的产品线结构

                （4）好的管理（软件资源、人员组织、过程）支持