详谈软件架构设计(三)之软件开发方法、质量属性以及软件架构评估

题外话：本篇文章主要讲的是软件架构体系中的软件开发方法、质量属性以及软件架构评估等方面的内容。

一：基于架构的软件开发方法

1、开发过程

基于架构的软件开发主要分为架构需求、架构设计、架构文档化、架构复审、架构实现、架构演化等六个阶段。

（1）架构需求：架构需求受架构师的经验以及技术环境的影响。主要分为需求获取、标识构件、需求评审三个阶段。

（2）架构设计：架构设计是一个迭代的过程，可以分为提出架构模型、映射架构、分析架构相互作用、产生架构、设计评审五个阶段。

架构需求以及架构设计的结构步骤图如下所示：

（3）架构文档化：架构文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书这两个文档。

（4）架构复审：架构设计、文档化和复审是一个迭代过程。复审的主要目的是标识潜在风险，及早发现架构设计中的错误和缺陷。

（5）架构实现：所谓架构实现就是要用实体来显示出一个软件架构，即要符合架构所描述的结构性设计决策，分割成规定的构件，按规定方式相互交互。

（6）架构演化：一个架构设计完成之后，为了适用于新需求所经历的演化过程。

架构实现和架构演化的详细流程图如下：

二：软件架构的评估

软件架构评估主要是要能够回答出三个问题。即

• 为什么要进行评估？

• 架构评估到底要评估些什么东西？

• 架构评估怎么评？

  
  

1、软件架构评估-质量属性

（1）性能：

性能（ performance ）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能负载的事件的个数。

代表参数：响应时间、吞吐量 设计策略：优先级队列、资源调度

（2）可靠性：可靠性（ reliability ）是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力．

代表参数：MTTF、MTBF设计策略：冗余、心跳线

（3）可用性

可用性（ availability ）是系统能够正常运行的时间比例．经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

代表参数：故障间隔时间设计策略：冗余、心跳线

（4）安全性

安全性（ security ）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性

设计策略：追踪审计

（5）可修改性

可修改性（ modifiability ）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

主要策略：信息隐藏

（6）功能性

功能性（ functionality ）是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

（7）可变性

可变性（ changeability ）是指体系结构经扩充或变更而成为新体系结构的能力．这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构．当要将某个体系结构作为一系列相关产品（例如，软件产品线）的基础时，可变性是很重要的．

（8）互操作性

作为系统组成部会的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性（ interoperation ），软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口．程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。

质量属性中最重要的四个：性能，可用性，安全性，可修改性。其他的了解相关的知识就行.

例题分析

• 用户提交搜索请求后，系统必须在1秒内显示结果；

答案解析：性能

• 用户信息数据库授权必须保证99.9%可用；

答案解析：安全性（强调的是数据库的授权）

• 系统由MySQL数据库升级为Orade数据库，必须在 1人/月内完成；

答案解析：可修改性

• 主服务器出现严重问题无法提供服务时，备用系统10分钟内能接替其工作；

答案解析：可用性

• 需要在3人周内为系统添加一种新的支付方式一一支付宝；

答案解析：可修改性

• 视频点播时，超清模式必须保证画面具有1280*720的分辨率；

答案解析：性能

• 主站点断电后，需要在3秒内将访问请求重定向到备用站点。

答案解析：可用性

2、软件架构评估

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

敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。

权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点（提高安全级别会带来性能的降低和安全性的提高）。

非风险点：用户要求完成***功能，这个要求是可以接受的。

软件结构评估有三种评估方式，其之间的区别如下图所示：

其中，目前普遍都用用基于场景的评估方式。

（1）基于场景的评估方式

• 确定应用领域的功能和软件架构的结构之间的映射

• 设计用于体现待评估质量属性的场景

• 分析软件架构对场景的支持程度

主要的评估方法有：架构权衡分析法（ ATAM) 、软件架构分析法（ SAAM)、成本效益分析法（ CBAM)。

a、架构权衡分析法（ ATAM)：

b、软件架构分析法（ SAAM)：

c、成本效益分析法（ CBAM)

• 整理场景

• 对场景进行求精

• 确定场景的优先级

• 分配效用

• 形成”策略－场景－响应级别”的对应关系

• 确定期望的质量属性响应级别的效用

• 计算各架构策略的总收益

• 根据受成本限制影响的投资报酬率选择架构策略

  
  

题外话：架构评估的方法不能够评估代码，评估的是架构的情况如何的，并且不是很精确的，他会有点偏差，也不能用来做测试。主要了解ATAM，其余的两种方法大致的了解一下即可。

三、软件产品线

根据CMU/SEI的定义，软件产品线（softwareproductline）是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。这些系统遵循一个预描述的方式，在公共的核心资源（core assets）基础上开发的。

软件产品线主要由两部分组成，分别是核心资源和产品集合。

软件产品线开发有4个基本技术特点，即过程驱动、特定领域、技术支持和以架构为中心。

软件产品线的适用范围：适合于专注于某个领域，在领域中有所积累，以后也是往这个领域发展，沉淀、固化这个领域的东西。

1、软件产品线的过程模型－双生命周期模型

双生命周期模型是目前用的最多的一种模型，分为两个重要的生命周期，即领域工程和应用功能。

领域工程阶段的主要任务有：

• 领域分析：利用现有系统的设计、架构和需求建立领域模型。

• 领域设计：用领域模型确定领域、产品线的共性和可变现，为产品线设计架构

• 领域实现：基于领域架构开发领域可重用资源（构件、文档、代码生成器）

应用工程阶段的主要任务有：

• 需求分析：将系统需求和领域需求比较，划分为领域公共需求和独特需求两大部分。

• 系统设计：在领域架构基础上，结合系统的独特需求设计应用的软件架构。

• 系统实现：根据应用架构，用领域可重用资源实现公共需求，用定制开发的构件满足系统独特需求，构建新的系统。

  
  

2、软件产品线的过程模型－SIE模型

3、软件产品线的过程模型－三生命周期模型

4、软件产品线的建立方式

• 将现有产品演化为产品线

• 用软件产品线代替现有产品集

• 全新软件产品线的演化

• 全新软件产品线的开发

  
  

5、软件产品线的组织结构

软件产品线组织结构类型分为三种：设立独立的核心资源小组、不设立独立的核心资源小组、动态的组织结构。

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

• 对该领域具备长期和深厚的经验

• 一个用于构建产品的好的核心资源库

• 好的产品线架构

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

更多资讯请扫描以下二维码或关注微信公号“愿为最亮星”，为您提供更深层次的解答。