这是我参与8月更文挑战的第5天，活动详情查看：8月更文挑战
五 基于架构的软件开发方法
5.1 基于架构的软件开发ABSD
ABSD方法是架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求(或侧重于非功能需求)。
使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成，就开始了软件设计。
ABSD方法有三个基础。第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术;第二个基础是通过选择架构风格来实现质量和业务需求;第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。
5.2 开发过程
架构设计是在需求分析之后，概要设计之前，是为了解决需求分析和软件设计之间的鸿沟问题。基于架构的软件开发过程可分为下列六步:
架构需求：重在掌握标识构件的三步。
架构设计:将需求阶段的标识构件映射成构件，进行分析。
架构(体系结构)文档化:主要产出两种文档，即架构(体系结构)规格说明，测试架构(体系结构)需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。
-
架构复审:由外部人员(独立于开发组织之外的人，如用户代表和领域专家等)参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审。
-
架构实现:用实体来显示出架构。实现构件，构件组装成系统。
-
架构演化:对架构进行改变，按需求增删构件，使架构可复用。
六 软件架构评估
6.1 质量属性
-
性能:指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。设计策略:优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。”
-
可靠性:是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF。设计策略:心跳、Ping/Echo、 冗余、选举。
-
可用性:是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。设计策略:心跳、Ping/Echo、 冗余、选举。
-
安全性:是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。设计策略:入侵检测、用户认证、用户授权、追踪审计。
-
可修改性:指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。设计策略:接口-实现分类、抽象、信息隐藏。
-
功能性:是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
-
可变性:指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为- - 系列相关产品的基础时，可变性是很重要的。
-
互操作性:作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。
6.2 架构评估方式
- 敏感点:是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
- 权衡点:是影响多个质量属性的特性，是多个质量属性的敏感点。 风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念,即可能引起风险的因素,可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点;而如果某件事是可行的可接受的，则为非风险点。
三种常用的评估方式
- 基于调查问卷(检查表)的方式:类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
- 基于度量的方式:制定一些定量来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。
- 基于场景的方式:主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于体现待评估质量属性的场景(即4+1视图中的场景),最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。
从三个方面对场景进行设计:
刺激(事件);
环境(事件发生的环境);
响应(架构响应刺激的过程)。
三种评估方式的比较:
由上表可知，场景最不通用，度量要求对构架精确了解，调查问卷实施阶段最早，度量最客观。其中，基于场景的方式是主流，其有三种具体评估方法:
6.3 基于场景的评估方式
确定应用领域的功能和软件架构的结构之间的映射。
设计用于体现待评估质量属性的场景(即4+1视图中的场景)。
分析软件架构对场景的支持程度。
6.3.1 基于场景的架构分析方法SAAM
SAAM是一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。SAAM的主要输入是问题描述、需求说明和架构描述。有下列六个步骤:
场景分为直接场景(直接可以实现的)和间接场景(该做哪些修改才能实现)。形成了场景之后，也可以对场景进行分类和单个评估，六个步骤有交叉点。
若要比较多个架构，就要形成权值，对多个架构的功能和数量进行比较。
6.3.2 架构权衡分析法ATAM
让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人。
ATAM被分为四个主要的活动领域，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。整个评估过程强调以属性作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。
6.3.3 成本效益分析法CBAM
用来对架构建立的成本来进行设计和建模，让决策者根据投资收益率来选择合适的架构，可以看 做对ATAM的补充，在ATAM确定质量合理的基础上，再对效益进行分析。有下列步骤:
- 整理场景(确定场景，并确定优先级，选择三分之-优先级最高的场景进行分析);
- 对场最进行细化(对每个场景详细分析，确定最好、最坏的情况);
- 确定场景的优先级(项目干系人对场景投票，根据投票结果确定优先级);
- 分配效用(对场景响应级别确定效用表，建立策略、场景、响应级别的表格);
- 形成“策略-场景-响应级别的对应关系”;
- 确定期望的质量属性响应级别的效用(根据效用表确定所对应的具体场景的效用表);
- 计算各架构策略的总收益; 根据受成本限制影响的投资报酬率选择架构策略(估算成本，用上-步的收益减去成本，得出收 益，并选择收益最高的架构策略)。
