软件体系结构1~5章知识点整理

绪论

案例一：圣·玛丽亚大教堂
案例二：瑞典瓦萨战舰
由建筑体系架构——>软件体系结构。
总体的系统结构设计比计算算法和数据结构更为重要。

1.软件体系结构发展史
高级语言 面向过程开发 面向对象开发 面向服务开发 云和移动服务开发 智能化软件开发。

无体系结构——>概念和理论体系形成——>理论完善且普及应用
体系结构出现：1968年北大西洋公约组织（NATO）会议上第一次出现词语“Software Architecture”（软件体系结构/软件架构）。

概念体系和理论体系形成：软件体系结构定义逐渐明确，相关书籍出版。

理论完善与普及应用：1999年，1st IFIP软件架构会议召开；Markup架构描述语言提出，支持广泛的模型架构共享；软件产品线被提出，引起了大量大型企业的关注；IEEE 1471—2000发布，为软件架构普及定制标准化规范。

2.软件体系结构定义
软件体系结构=组件+连接件+约束
组件：具有某种功能的可重用的软件模块单元，表示了系统中重要的计算单元和数据存储。
连接件：表示组件之间的交互。简单连接件有：管道，过程调用，事件广播等；复杂连接件有：客户—服务器通信协议，数据库和应用之间SQL连接。
约束：表示组件和连接件的拓扑逻辑和约束。

3.软件体系结构的研究活动
软件体系结构要解决的问题，软件体系结构研究的内容，自适应软件体系结构。

4.软件体系结构的作用
软件生命周期中的作用

第一章 软件工程和软件设计概述

1.1软件的本质
软件是一系列按照特定顺序组织的计算机数据和指令的集合。
软件不是有形的物理产品，而是人类思维的产物。
软件不是被制造出来的 ，而是思考出来的。
软件的限制—>软件的复杂性

软件特质和分类：

• 软件是设计开发的
• 软件不会磨损和老化
• 随着构建构造模式的发展，软件需要根据客户需要定制
• 不断变更是软件退化的根本原因

软件分类：

• 系统软件
• 应用软件
• 嵌入式软件
• 科学和工程计算软件产品线软件
• 产品线软件
• 人工智能软件
• Web应用软件

2.软件工程
2.1软件工程是：（1）将系统化的，规范化的，可量化的方法应用于软件开发、运行和维护，即将工程化方法应用于软件。（2）对（1）中所述的方法进行研究。

2.2软件过程和软件工程实践
软件过程：是工作产品构建时所执行的一系列活动、动作、任务的集合。

• 活动：实现宽泛的目标。
• 动作：包含了主要工作产品生产过程中的一系列任务。
• 任务：关注小而明确的目标，能够产生实际产品。

2.一个通用的软件工程过程包含一下5个内容活动：沟通，策划，建模，构建，部 署。
3.软件工程和软件过程实践——七条原则：存在价值，保持简简洁，保持愿景，关 注 使用者，面向未来，计划复用，认真思考。

2.3网络环境带来的影响
（1）计算机软件 = 程序 + 数据结构 + 文档
（2）计算机软件 = 满足需求的信息 + 服务工具

3.软件设计
3.1软件工程过程中的设计
软件设计在软件工程过程中处于核心技术。

• 分析模型
• 数据/类设计
• 体系结构设计
• 接口设计
• 构建级设计

3.2软件设计原则

• 抽象（过程抽象/数据抽象）
• 体系结构
• 模式
• 模块化
• 信息隐蔽
• 功能独立（内聚/耦合）
• 求精
• 重构
• 设计类（用户接口类/业务域类/过程类/持久类/系统类）

软件设计原则——设计类：完整性和充分性，原始性，高内聚性，低耦合性。
体系结构与设计：体系结构是系统设计的一部分，突出了某些细节，并通过抽象省略掉一些细节。所以，体系结构是设计的一个子集。

3.3软件体系结构的内容——体系结构的研究领域
(1)通过提供一种新的体系结构描述语言解决体系结构描述问题
(2)体系结构领域知识的总结性研究
(3)针对特定领域的框架的研究
(4)软件体系结构形式化支持的研究

3.4软件体系结构设计方法：是指通过一系列的设计活动，获得满足系统功能性需求，并符合一定非功能性需求约束的软件体系结构模型。
软件体系结构设计方法分类：
(1)FR驱动的软件体系结构设计
(2)NFR驱动的软件体系结构设计
(3)集合FR和NFR的方法

3.5软件体系结构设计经验总结与复用
软件体系结构所采用的主要手段：
（1）体系结构风格和模式

• 非形式化描述模型，并将其引入到体系结构设计过程中。
• 提供形式化规约，精确的说明风格的特征，并用于高层性质验证

（2）领域特定的软件体系结构和软件产品线

第二章 软件模型和描述

2.1什么是软件模型

• 模型：一般指客观世界中事物存在的一种抽象，事物可以是具体的，也可以是抽象的。
• 模型表达方法：用数学语言表达的模型称为数学模型（形式化最高级别）；使用自然语言或图形语言表达的模型是定性的描述（形式化级别较低）。
• 软件模型：软件的一种抽象，一般通过非数学模型来描述。

软件模型可以看作是一种元模型。
软件模型作为软件组成的最基本单元的抽象，既反映软件体系结构构建的核心思想，也奠定了软件体系结构构建的基础。

2.2软件模型的发展历程
功能模型—>对象模型—>组件模型—>配置型组件模型—>服务模型—>抽象模型

2.3软件模型解析
1.功能模型
功能模型也可以成为过程模型或函数模型，它是模型化软件构件方法的第一基本模型。
功能模型的基本原理：将一个系统分解为若干个基本功能模块，基本功能模块之间可以根据需求进行调用。
基本功能模型的抽象和耦合
功能模型的核心
递归思想的具体实现

2.对象模型
对象模型：以对象为核心，通过对象进行数据组织的抽象并实现数据组织和数据处理的统一，并在此基础上建立面向对象的软件构造方法。
对象模型的基本原理：将一个系统分解为若干个对象，对象之间可以通过发送消息按需求进行协作。
数据类型的抽象：允许用户按需根据定义自己的数据类型：

• 对象模型的核心
• 同构（或同族）
• 对象关系的定义：体现在继承和多态两方面

3.组件模型
3.1组件模型：在对象模型的基础之上，强调异族对象关系以及独立性问题。
异族对象关系：组件内部完成组件功能的对象可以是同族的，也可以是异族的。
独立性：组件建立在二进制基础之上并独立封装，可以独立部署。

3.2组件模型以接口为核心，通过接口抽象组件行为，并在此基础上建立面向接口 的软件构造方法。接口：值对象动态行为的集合，支持继承机制。组件：能完成特 定功能并能独立部署的软件合成单元，一个组件一般具有一个多个接口，每个 接口的功能由一个或多个方法实现。

3.3组件对象模型是基于Windows平台的一套组件对象接口标准，由一组构造规范 和组件对象库组成。

3.4一般的对象由数据成员和作用在其上的方法组成，而组件对象与一般的对象虽 有相似性，但也有较大不同。组件对象不使用方法而是接口描述自身。

3.5接口被定义为“在对象上实现的一组语义上相关的功能”，其实质是一组由组件 实现的提供给客户使用的函数，是一个包含函数指针数组的内存结构，数组元素是 一个由组件实现的函数地址。

3.6一个组件对象实现的接口数量没有限制。
3.7框架：已实现部分功能的某类程序结构的实现。

3.8框架分类：（1）水平型：一般面向通用类程序的构造，与特定的应用领域无关。 （2）垂直型：一般面向特定应用领域，它抽象和封装了该应用领域程序的基本构 造和共性基本组件。（3）符合文档型：是一种比较通用的框架，它将一个程序抽象 为一个文档，将构造程序的各个组件看作是文档中不同的的独立元素，这些独立元 素通过事件消息相互联系。

4.配置型组件模型
配置型组件模型又称为服务器组件模型，它专门针对应用服务器，定义其基于组件 的基础结构模型。
配置型组件模型的基本原理：将应用业务逻辑与系统基础服务两者解耦，由系统基 础服务构成一个服务容器，自动隐式的为各种业务逻辑按需统一提供相应的基础服 务。应用业务逻辑可以按需提出不同的基础服务要求，即他是可配置的。

5.服务模型
服务：指一个封装着高级业务概念、实现公共需求功能、可远程访问的独立应用程 序模块。
服务一般由数据、业务逻辑、接口及服务描述构成。
服务模型的基本原理：明确服务提供者和服务使用者，并通过服务中介实现两者的 耦合。
服务模型的标准主要是Web Services.

6.抽象模型
基于归纳思维策略的可恢复程序语句组件模型
抽象模型
基于演绎思维策略的元模型
两者都是面向抽象层的应用业务逻辑的描述，而不关注描述的具体实现平台和环境，具有完整的技术独立性和应用发展的适应性。

2.4深入认识软件模型
２.４.１软件体系结构的描述

• 软件体系结构的描述指的是通过某种语言表达软件体系结构。
• 描述的目的是为了实现对软件体系结构的认识、理解和交流。
• 进而，基于描述，可以对软件系统的各种行为和特征进行各种理论分析和仿真模拟， 以及实现软件系统代码的自动生成。

２.４.２软件体系结构的描述—非形式化描述
典型代表——UML（一种通用的可视化建模语言）
非形式化描述的缺陷：

• 语义含糊
• 由语义含糊引起的沟通障碍
• 无法实现系统验证

不适于描述体系结构行为
２.４.３软件体系结构的描述—形式化描述
用于软件和硬件系统的说明、开发和验证的数学化方法。
理论基础是数学化理论。

形式化的特点：

• 可以用于系统描述，并且可以在不同层次上进行描述
• 在体系结构行为描述上更胜一筹
• 使得系统验证变得可行

２.４.４软件体系结构的描述—典型的形式化描述

• Petri网
• Z语言
• 形式化描述的本质在于抽象，抽象的级别不同将导致方法的适用的范围不同。

形式化描述存在的问题：

• 说明与实际代码间的差距仍然巨大
• 受本身性质所限，形式化描述方法很难与软件开发过程整合

２.４.５软件体系结构的设计

• 基本任务：识别出构成系统的子系统并建立子系统控制和通信的基本框架，以满足 系统功能性和非功能性需求。
• 软件体系结构设计：使用某种体系结构描述方法或语言，通过某种设计工具和环境， 针对一个特定的软件系统的构造，为其逻辑构成做出决策的一种创造性活动。
• 水平型设计：运用通用建模设计工具和表达语言所进行的软 件体系结构的设计。
• 垂直型设计：运用面向体系结构的专用建模设计工具及其表 达模型所进行的软件体系结构的设计。

２.５ADL简介
体系结构描述语言：一种用于描述体系与体系结构的计算机语言，它可以在指定的抽象 层次上描述软件体系结构。
ADL关注抽象层次上的整体结构而不是任意代码模块的实现细节，作为一种经典理论， Shaw和Garland定义了ADL的元素：

• 构件：抽象级别上组成系统的计算模块。
• 操作：构件之间的交互机制。
• 模式：构建元素依照特定方式进行的组合。
• 闭包用于实现分层描述的概念。
• 规格说明：包括功能、性能、容错能力等。

第三章 软件体系结构建模和UML

3.1软件体系结构建模概述
体系结构模型分为以下五类：

• 结构模型

• 框架模型

• 动态模型

• 过程模型

• 功能模型

3.2基于软件体系结构的开发
体系结构的软件开发过包括以下主要活动：
1.通过对特定领域应用软件进行分析，提炼其中的稳定需求和易变需求，建立可 复用的领域模型。
2.在领域模型的基础上提炼特定领域的软件体系结构。
3.低层设计主要解决具体构件和连接件的设计问题，通过复用设计件库中存放的 设计模式、对象和其他类型的可复用设计件，或根据情况设计情的构件，并提炼入 库。低层设计的结果可以直接编程实现。

体系结构——>宏观上描述系统的总体构件——>高层设计
设计模式和对象——>从微观上解决设计的问题——>低层设计

3.3UML概述
3.3.1UML的特点和用途

• 统一标准
• 面向对象的特征
• UML在演变过程中还提出一些新的概念
• 独立于过程
• UML对系统的逻辑模型和实际模型都能清楚地表示，可以用于复杂软件系统 的建模

3.3.2UML2.0的建模机制

• 语言定义精确度提高
• 改良的语言组织
• 重点改进大规模的软件系统模型性

3.4面向对象方法
面向对象方法学的出发点和基本原则是尽可能模拟人类习惯的思维方式，使开发软件的 方法与过程尽可能接近人类认识世界、解决问题的方法与过程。
面向对象构造法则：

• 区分对象及其属性
• 区分整体对象及其组成部分
• 不同对象类的形成以及区分

3.4.1 面向对象方法中的基本概念
（1）对象：对象指的是一个独立的、异步的、并发的实体。
（2）类：类的定义，包括一组数据属性和在数据上的一组合法操作。
（3）继承性：广义地说，继承是指能够直接获得已有的性质和特性，而不必反复 定义他们。
（4）多态性：指子类对象可以向父类对象那样使用，同样的消息既可已发送给父 类对象也可以发送给子类对象。
（5）重载：有两种重载：函数重载是指在同一作用域内的若干个参数特征不同的 函数可以使用相同的函数名；运算符重载是指同意运算符可以施加于不同类型的操 作数上面。
（6）消息和方法：在面向对象领域，两个对象的贾湖是通过消息的发送和接收来 完成的。消息分为简单消息、同步消息和异步消息。
（7）聚集：在客观世界中有若干类，这些类之间有一点的结构联系。通常有两种 主要的结构联系，即一般——具体结构关系，整体——部分结构关系。

3.4.2 面向对象方法的优势

• 支持软件的重用性
• 提高软件可维护性和安全性

3.5 UML2.0中的结构建模
UML2.0中的结构建模包括：

• 类图
• 包图
• 对象图
• 构件图
• 组合结构图
• 部署图

3.5.1 类图——类
（1）类是来描述具有相同特征、约束和语义的一乐对象，这些对象具有共同的操 作和属性。
（2）类图中的类可以简单的只给出类名，也可以具体的列出该类拥有的成员变量 和方法，甚至更详细的描述可见性、方法参数、变量类型等信息。

3.5.2 类图——抽象类
（1）抽象类是指只提供操作名，而不对其进行实现。
（2）对这些操作的实现可以由其子类实现，并且不同的子类可以对同一操作具有 不同的实现。

3.5.3 类图——接口
3.5.4 类图——关联关系
（1）描述了类结构之间的关系。
（2）当关联使双向的，那么就可以用无向连线表示。
（3）一般的关联关系语义较弱。也有两种语义较强，分别是聚合和组合。

3.5.5 类图——依赖关系
（1）两个类之间存在依赖关系，表明一个类使用或需要知道另一个类中包含的信 息。
（2）有多种形式，例如绑定、友元等。

3.5.6 类图——聚合关系
3.5.7 类图——合成关系
3.5.8 类图——聚合关系与合成关系的区别
（1）聚合关系使has-a关系，组合关系是contains-a关系。
（2）聚合关系表示整体与部分的关系较弱，组合关系表示比较强。

3.5.9 类图——泛化关系
泛化关系在面向对象中一般称为继承关系，存在于父类与子类，父接口与子接口之间。

3.5.10 对象图
对象是类的实例，对象图可以看作类图的实例，对象之间的连接是类之间关联关系 的实例。
对象图显示类的多个对象实例而不是真实的类。

3.5.11 构件图
(1)构件图用于静态建模，是表示构建类型的组织以及各种构件之间依赖关系的图。
(2)构建通过对构件间依赖关系的描述来估计修改系统构件可能给系统带来的影响。
(3)构件的根本特征在于它的封装性和可复用性，其内部构件被隐藏起来，只能通过接口向外部提供服务或请求外部的服务。
(4)构件是系统中遵从一组接口且提供其实现的物理的、可替换的部分。
(5)构件能独立完成功能，它是软件系统的组成部分。

3.5.12 部署图
（1）部署图描述的是系统运行时的，展示了硬件的配置及其软件如何部署到网络 结构中。
（2）一个系统模型只有一个部署，部署图通常用来理解分布式系统。

3.5.13 行为建模（动态建模）
行为建模：刻画系统中的动态行为、动作和过程。
UML行为建模中提供的试图可以从不同侧面描述软件系统的动作过程。
1.用例图
（1）用例图定义：

• 被称为参与者的外部用户所能观察到的系统功能的模型图
• 用例图列出了系统中的用例和系统外的参与者，并显示哪个参与者参与了哪个用例的执行
• 用例图多用于静态建模阶段（主要业务建模和需求建模）
• 参与者：指在系统外部与系统直接交互的人或事物。

用例：

• 用例的定义：是系统外部可见的一个系统单元。
• 参与者与用例之间的关系：关联表示参与者与用例之间的交互、通信途 径。

用例之间的关系：

• 包含：箭头指向的用例为被包含的用例，称为包含用例；箭头出发 的 用例为基用例。包含用例是必选的，如果缺少包含用例，基用例 就不完整；包含用例必须被执行，不需要满足某种条件，器质性不会 改变基用例的行为。
• 拓展：箭头执行的用例为被拓展的用例，称为拓展用例；箭头出发 的用例为基用例。拓展用例是可选的，如果缺少拓展用例，不会影响 基用例的完整性，拓展用例在一定条件下才会执行，并且其执行会改 变基用例的行为。
• 参与者之间的关系：泛化关系是一般和关系，发出箭头的一方表示特殊 的一方，箭头指向的一方代表一般的一方，特殊的一方继承了一般方的特 性并增加了新的特性。

2.顺序图

• 顺序图描述对象之间的动态交互关系，着重表现对象间消息传递的时间顺序。
• 顺序图有两个坐标轴：纵坐标轴表示时间，横坐标轴表示不同的对象。
• 顺序图中的对象用一个矩形框表示，框内表有对象名。从表示对象的矩形框向下的垂直虚线是对象的“生命线”，用于表示在某段时间内该对象是存在的。

3.通信图
通信图主要关注参与交互的对象通过连接组成的结构。

4.交互概览图
交互概览图有两种形式：

• 以活动图为主线
• 以顺序图为主线

5.时序图
时序图是显示对象之间交互的图。这些对象是按时间排列的，时序图中显示的是参与交互的对象及其对象之间消息交互的顺序。

6.状态图
状态图使用有穷状态变迁图的方式刻画系统或元素的离散行为，可以用来描述一个类的实例、子系统甚至整个系统在其生存周期内，所处状态如何随外部刺 激而发生变化。

7.活动图

• 活动图是UML用于对系统的动态行为建模的另一种常用工具，他描述活动的顺序，展现从一个活动到另一个活动的控制流。
• 活动图在本质上是一种流程图，是内部处理驱动的流程。
• 活动图主要用于：业务建模时，用于详述业务用例，描述一项业务的执行过程；设计时，描述操作的流程。
• UML活动图包含的元素有动作状态、活动状态、动作流、分支与合并（分叉与汇合）、泳道和对象流等。

第四章 软件设计过程

4.1软件设计基础
软件设计主要针对需求分析过程得到的软件需求规格说明，综合考虑各种制约因素，探 求切实可行的软件解决方案并最终给出方案的逻辑表示，包括文档、模型等。
软件设计的主要活动：
（1）软件设计计划

• 明确设计过程的输入制品并使其处于就绪状态

• 定义设计过程的目标、输出制品及验收准则

• 确定覆盖设计过程中各个阶段的全局性设计策略

• 分配设计过程中相关人员的职责

• 针对设计过程中的活动指定设工作计划

（2）体系结构设计
目标是建立软件系统的体系结构，有时也称“顶层设计”。
在软件体系结构设计过程中，需要注意以下规则：

• 改进软件结构，提高模块独立性
• 模块规模应该适中
• 深度、宽度、扇入、扇出都应该适当
• 模块的作用域应该在控制域之内
• 力争降低模块接口的复杂程度
• 设计单入口、单出口模块
• 模块功能应该可以预测

（3）界面设计

• 结构设计
• 交互设计
• 视觉设计

良好的用户界面一般都符合下列用户界面规范：

• 易用性原则
• 规范性原则
• 帮助设施原则
• 合理性原则
• 美观与协调性原则
• 容错性考虑原则

（4）模块/子系统设计
设计目标：

• 确定模块的具体接口定义，并设计模块的内部结构
• 尽量保持模块的功能独立性，遵循“高内聚，低耦合”的设计思想
• 力求将模块的影响限制在模块的控制范围之内，使得软件的日后修改和维护工作更加简单

（5）过程/算法设计
主要任务是对模块内部工作和执行过程进行描述，给出有关处理的精确说明。
（6）数据模型设计

• 把数据结构设计，数据库设计，甚至数据文件设计都统一称为数据模型设计
• 持久数据操作

4.2软件体系结构设计
软件设计一般首先设计软件体系结构设计，然后再逐步精化进行更详细的设计，知道设计可以被实现的程度。
软件体系结构的设计方法是指通过一系列的设计活动，获得满足系统能性需求，并且符合一定非功能性需求约束的软件体系结构模型。
（1）多重视图建模（包含逻辑、开发、物理、过程视图）
（2）基于评估与转换的设计方法
对体系结构进行转换可以通过下述三种方式实现：

• 使用合适的体系结构分割和模式，或者设计模式来改进体系结构设计。
• 把非功能性需求转换为功能性解决方案，该功能性方案可以与问题与无关，但可以满足质量属性的要求。

（3）模式驱动的设计方法
常用的软件体系结构风格如下：

• 数据流风格：批处理和管道/过滤器
• 调用/返回风格：主程序/子程序、层次结构和客户机/服务器
• 面向对象风格
• 独立部件风格：进程通讯和事件驱动
• 虚拟机风格：解释器和基于规则的系统
• 数据共享风格：数据库系统和黑板系统

（4）领域特定的软件体系结构设计方法
领域特定的软件体系结构是领域工程的核心部分，领域工程分析应用领域的共同特征和可变特征，对刻画这些特征的对象和操作进行选择和抽象，形成领域模型，并进一步生成DSSA。
DSSA与体系结构风格的区别：

• DSSA和软件体系结构风格是从不同角度出发研究问题的两种结果，前者从问题域出发，后者从解决域出发。
• DSSA只在某个特定的领域中进行经验知识的提取、总结和组织，但可以使用多种软件体系结构风格；而一种软件体系结构风格所呈现的公共结构和设计方法可以拓展到多个应用领域。
• DSSA的体系结构表示和工具一般只适用于较小的范围，在其他领域中是不适用并难以复用的。

（5）软件产品线
指一组可管理的，具有公共特性的软件应用系统的集合。
软件产品线的主要组成部分：核心资源和软件产品集合。
软件产品的基本活动包括核心资源开发，利用核心资源的产品开发以及在这两部风 中所需要的技术协调和组织管理。
在一个软件产品线中，新产品形成的步骤如下：

• 从公共资产库中选取合适的构件
• 使用预定义变化机制进行裁剪，如参数化，继承等
• 必要时增加新的构件
• 在整个产品线范围内公共的体系结构指导下进行构件的组装，形成系统

（6）其他软件体系结构设计方法
（1）基于目标图推理的体系结构设计方法：该方法的目标是使模式背后的推理显 示化，并且服从于系统的分析；该方法使用目标图，表达模式在各种需求上的应用 效果。
（2）基于属性的体系结构设计方法：是对通常体系结构风格描述的一种扩充，用 于获取结构化分析SA层次上的结构和分析技巧，显式地把推理框架（定性或定量） 与体系结构风格关联起来。

4.3高可信软件设计
（1）可信软件的特点：

• 可信软件：是指软件系统的的运行行为及其结果总是符合人们的预期，而且在受到干扰时仍能提供联系服务。
• 软件系统的可信性质：只是该系统需要满足的关键性质，当软件系统一旦违背这些性质，会造成不可容忍的损失时，称这些性质为高可信性质。

（2）软件可信性质分为以下几种：

• 可靠性：在规定的环境下、规定的时间内软件无失效运行的能力。
• 可靠安全性：软件运行不引起危险、灾难的能力。
• 保密安全性：软件系统对数据和信息提供保密性、完整性、可用性、真实性保障的能力。
• 生存性：软件在受到攻击或失效出现时连续提供服务并在规定时间内恢复所有服务的能力。
• 容错性：软件在故障（硬件，环境异常）出现时保证提供服务的能力。
• 实时性：软件在规定时间内完成反应或提交输出的能力。

（3）容错设计

• 完全防止软件失效在实践中不可能的，任何试图消除软件失效的方法都会导致很高的成本，并且不能保证时效不会发生。
• 为了保证高可信系统即使在极端条件下也能按其规格说明执行，对硬件和软件同时采用容错计算非常重要。
• 为了达到硬件容错，需要对所有关键硬件部件进行备份，为了软件免受故障的影响，软件逻辑和数据也必须备份。

恢复块
软件容错设计方法
N—板块编程
设计多样性可以通过以下几种方式达到：

• 使用不同的设计方法来实现需求
• 使用不同的程序设计语言来完成
• 使用不同的开发工具，且在不同的开发环境中完成
• 明确要求在实现某些关键过程时使用不同的算法

（4）软件失效模式和影响分析
软件失效模式和影响分析主要是在软件开发阶段的早期，通过识别软件失效模式，研究分析各种失效模式产生的原因及其造成的后果，寻找消除和减少有害 后果的方法，以尽早发现潜在问题，并采取相应措施，从而提高软件的可靠性 和安全性。

• 软件失效：泛指程序在运行中丧失了全部或部分功能、出现偏离预期的正常状态的事件。
• 软件失效模式：指软件失效的不同类型，通常用来描述软件失效发生的方式，以及对设备运行可能产生的影响。
• 软件失效的影响：指软件失效模式对软件系统的运行、功能或状态等造成的后果。

（5）软件故障树分析
软件故障树是在软件系统设计过程中，通过对可能造成系统故障的因素（包括硬件、软件、环境、人为等因素）进行分析，画出逻辑框图（即故障树），从而确定系统故障原因的各种可能组合，采取相应的纠正措施，提高系统可靠性的一种设计分析方法。
（6）形式化方法
形式化方法是在计算系统的开发中进行严格推理的理论、技术和工具，主要包括形式规约技术和形式验证技术。
形式规约技术：使用具有严格数学定义语法和语义的语言刻画软件系统及其性质，可以尽早发现需求和设计中的错误、歧义、不一致和不完全。、
形式验证技术：是在行使规约的基础上建立软件系统及其性质的关系，即分析系统是否具有所期望性质的过程，主要分为模型检验和定理证明。

4.4软件设计规格说明

• 软件设计过程中的各个活动的结果应该文档化，形成正式的软件规格说明，作为软件设计的输出。
• 形成的软件规格说明将被评审，并作为后续软件实现的依据。
• 软件设计规格说明并没有统一的格式，例如IEEE标准、IOS标准、各行业标准所建议的格式不尽相同。
• 使用不同的软件设计方法学所得的设计模型也会有很大不同，导致设计规格的说明也会明显不同。

4.5软件设计评审
软件设计评审的目标是确保软件设计规格说明书能够实现所有的软件需求，及早发现设计中的缺陷和错误，并确保设计模型已经精化到合格的软件实现工程师能够构造出符合软件设计者期望的目标软件系统。
设计评审中需要重点关注的内容包括：

• 设计模型是否能够充分地、无遗漏地支持所有软件需求的实现。
• 设计模型是否已经精化至合理的程度，可以确保合格的软件实现工程师能够构造出符合软件设计者期望的目标软件系统。
• 设计模型的质量属性，即设计模型是否都已经充分的优化，以确保依照设计模型构造出来的软件产品能够表现出良好的软件质量属性。

为了使设计评审达到预期效果，下面给出设计评审的一些建议性原则：

• 对产品进行评审，而不是开发人员
• 要有针对性，不要漫无目的
• 进行有限的争辩
• 阐述问题所在，但不要尝试去解决问题
• 要求事先准备，如果评审人你没有准备好，则取消会议重新安排时间
• 为被评审的产品开发一个检测表
• 缺点软件元素是否遵循规格说明或标准，记录任何不一致的地方
• 列出发现的问题、给出建议和解决该问题的负责人
• 坚持记录并文档化

第五章 软件体系结构风格

5.1软件体系结构风格概述

• 软件体系结构设计的一个核心问题是能否使用重复的体系结构模式，即能否达到体系结构级的软件重用。

• 能否在不同的软件系统中使用同一种体系结构。

• 软件体系结构风格是描述某一特定应用领域系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一种约束。

• 体系结构风格反映了领域中众多系统所共有的结构和语义特征，并指导如何讲各个模块和子系统有效地组织成一个完整的系统。

• 按照这种方式理解，软件体系结构风格定义了描述系统的术语表和知道构建系统的规则。

5.2管道—过滤器
在管道—过滤器模式下，功能模块成为过滤器；功能模块间的连接看作是输入、输出数据流的通道，所以称为管道。
（1）适应的设计问题
如果要建立一个必须处理或转化输入数据流的系统，用单个组件实现会显得臃肿，需求不容易变动，所有可能要通过替换或重新排列处理步骤为灵活性做规划。处理步骤的内部链接必须考虑一下步骤：

• 未来系统的升级通过替换处理步骤或重组处理步骤就能完成
• 不同的语境中小的处理步骤要比组件更易于重用
• 不相连的处理步骤不共享信息
• 存在不同的输入数据源，例如网络连接或通过硬件传感器提供读数
• 可以用多种方式给出或存放最终结果
• 明确存放中间结果
• 可能有并行或异步处理的要求

（2）解决方案

• 管道—过滤器的体系结构模式把系统任务分成几个连贯的处理步骤。这些步骤通过系统的数据流链接，一个步骤的输出是下一个步骤的输入。
• 每个处理步骤由一个过滤器组件实现
• 过滤器消耗或转发增长的数据，在产生输出之前消耗它的所有输入以达到低延迟并能够真正的处理。
• 数据源、过滤器和数据汇点由管道顺序连接起来，实现相连处理步骤间的数据流动。
• 通过管道联合的过滤器序列称为处理流水线。
• 从整个系统的输入和输出关系来看，各个过滤器对其输入进行局部的地理处理交换，就可以产生部分计算结果。
• 过滤器按照激活方式可以分为被动式过滤器（通过函数或过程调用激发）和主动式过滤器（作为独立的线程任务激发工作）。
• 过滤器是独立运行的部件，不受其他过滤器的影响；非临近的过滤器不共享任何状态，自身也是无状态的。
• 整个结果的正确性不依赖于各个过滤器运行的先后次序。

每种风格具有以下特征：

• 构建即过滤器，对输入流进行处理转换，处理的结果在输出端流出。而这种计算常常是递进的，所以可能在所有输入接受完之前就开始输出，可以并行地使用过滤器。
• 连接件位于过滤器之间，起到信息流的导管作用，即管道。
• 每个管道都有输入/输出集合 ，构建在输入处读取数据流，在输出出生成数据流。
• 过滤器必须是独立的实体。

采用管道—过滤器模式建立的系统具有如下优点：

• 由于每个构建的行为不受其他构建的影响，因此整个系统的行为比较易于理解。
• 支持功能模块的复用。任意两个过滤器只要在相互的输入、输出管道管道格式上达成一致，就可以连接在一起。
• 具有较强的可维护性和可拓展性。可维护性体现在系统过滤器部件的更新或升级。
• 支持特殊的分析：如吞吐量计算和死锁检测等。
• 支持并发执行。

管道—过滤器的不足：

• 往往会导致系统处理的成批操作。
• 在处理两个独立但又相关的数据流时可能会遇到困难。
• 在需求对数据传输处理进行特定的处理时，会导致对于每个过滤器的解析输入和格式化输出要做更多的工作，从而带来系统复杂性的上升。根据实际设计的要求，需求对数据传输进行特定处理（如为了防止数据泄露而采取加密手段），导致过滤器必须对输入、输出管道中的数据流进行解析或反解析，增加了过滤器具体实现的复杂性。
• 并行处理获得的效率往往是一种假象。

5.3数据抽象和面向对象风格

• 该风格建立在数据抽象和面向对象的基础之上，数据的表示方法和它们相应的操作封装在一个抽象数据类型或对象中。
• 该风格的构建是对象，或者说是抽象数据类型的实例。
• 对象是一种被称为管理者的构件，因为它负责保持资源的完整性。
• 对象是通过函数和过程调用来交互的。

优点：

• 因为对相对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他的对象。
• 设计者可以将一些数据存取操作的问题，分解为一些交互代理程序的集合。

缺点：

• 为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识，只要一个对象的标识变了，就必须修改所有其他明确调用它的对象。
• 必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。

5.4基于事件的隐式调用风格

• 基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。
• 系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致另一个模块中的过程调用。

主要特点：事件的触发者并不知道哪些构件会被这些事件影响。
优点：

• 为软件重用提供了强大的支持。当需要将一个构件加入现存系统时，只需将它注册到系统的事件中。
• 为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响其他构件的接口。

缺点：

• 构件放弃了对系统计算的控制。
• 数据交换的问题。
• 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。

5.5分层系统风格

• 所谓分层系统，就是按层次组织软件的一种软件体系结构，其中，每一层软件建立在第一的软件层上。
• 位于同一层的软件系统或子系统具有同等的通用性，在下一层的软件比在上一层的软件通用性更强。
• 一个层次可以视为同等通用档次的一组系统。
• 一个分层的系统按照层次结构组织，每一层向它的上层提供服务，同时又是它下层的客户。
• 在某些系统中，除了邻接的层，一个内部层次对于其他外部层次是隐藏的，对体系结构的约束包括把系统的交互限制在邻接层次之间。
• 交互只在相邻的层间发生，并且，这些交互按照一定协议进行。
• 连接件可以用交互键的协议定义。
• 每一层是由不同的部件构成的实体集合。层内的部件可以交互。
• 相邻层的部件可以直接从上向下调用，还可以设计统一的曾调用接口对层进行保护。

优点：

• 由于对层次的邻接层进行限制，所以系统易于改进和拓展。
• 每一层的软件都易于重用，并可为某一层次提供可互换的具体实现。
• 分层系统所支持的设计体现了不断增加的抽象层次，这样，一个复杂问题的求解被分解为一系列递增的步骤。
• 标准化支持。
• 局部性依赖。
• 可替换性。

缺点：

• 如何界定层次间的划分是一个较为复杂的问题。
• 更改行为的重叠。
• 降低效率。
• 不必要的工作。

5.6仓库风格和黑板风格
仓库风格的体系结构由两个构件组成：一个中央数据结构，它表示当前状态；一个独立构件的集合，它对中央数据结构进行操作。
对于系统中数据和状态的控制方法有两种：一个传统的方式是，由输入事务进行选择进行何种处理，并把执行结果作为当前状态存储到中央数据结构中，这时，仓库是一个传统的数据库体系结构；另一种方法是，由中央数据结构的当前状态决定进行何种处理。这时，仓库是一个合办体系结构，即黑板体系结合是仓库体系结构的特殊化。

5.7模式—视图—控制器风格——MVC模式

• MVC结构是为那些需要为同样的数据提供多个视图的应用程序而设计的，它很好地实现了技术层与表现层的分离。
• 作为一种开发模型，MVC通常用于分布式系统的设计和分析中，以及用于确定系统各部分间的组织关系。
• 对于界面可变性的需求，MVC把交互系统的组成分解为模型、视图、控制器三种部件。
• 模型部件：是软件所处理问题逻辑在独立与外在显示内容和形式情况下的内在抽象，封装了问题的核心技术数据、逻辑和功能的计算关系，它独立于具体的界面表达和I/O操作。
• 视图部件：把表示模型数据及逻辑关系和状态的信息吉他顶形式展示给用户，它从模型获得显示信息，对于相同的信息可以有多个不同的显示形式或视图。
• 控制部件：用于处理用户和软件的交互操作，其职责是控制所提供模型中任何变化的传播，确保用户界面和莫相间的对应关系。通常，一个视图具有一个控制器。
• 模型类：包含了应用问题的核心数据、逻辑关系和计算功能。它封装了解决应用问题所需的数据，提供了问题处理的操作过程。
• 视图类：通过显示信息的形式把信息传达给用户，不同试图通过不同的显示来表达数据和状态信息。
• 控制类：通过实践处理过程对输入事件进行处理，并为每个事件提供操作服务，把事件转换成对模型或相关使徒的激发操作。

MVC的实现：

• 分析应用问题，对系统进行分离
• 设计和实现每个视图
• 设计和实现每个控制器
• 使用和安装、卸载控制器

5.8解释器风格
解释器风格通常用于建立一种虚拟机以弥合程序的语义与作为计算引擎的硬件的间隙。又有解释器时间上建立了一个软件虚拟出来的机器，所以这种风格又常常被称为虚拟机风格。
程序设计语言的编译器；基于规则的系统，；脚本语言。
由一个执行引擎+三个存储器，一共四个构件组成：

• 正在被解释的程序
• 执行引擎
• 被解释的程序的当前状态
• 执行引擎的当前状态

优点：

• 有助于应用程序的可移植性与程序设计语言的跨平台能力。
• 可以对为实现的硬件进行仿真。

缺点：
额外的间接层次带来的系统性能的下降。

5.9C2风格
C2体系结构风格可以概括为通过连接件绑定在一起的、按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：

• 该系统的构建与连接件都有一个顶部和一个底部。
• 构件的顶部应连接到某连接件的底部，构件的底部应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的。
• 一个连接件可以和任意数目的其他构件和连接件连接。
• 当两个连接件进行直接连时，必须由其中一个的底部到另一个的顶部。
• C2风格是最常用的一种软件体系结构风格。

C2风格具有如下特点：

• 系统中的构建可以实现应用需求，并能将任意复杂度的功能封装在一起。

• 所有构件之间的通信时通过以连接件为终结的异步信息交互机制来实现的。

• 构件相互独立，构件之间依赖性较少。

5.10 C/S风格

• C/S体系结构有3各主要组成部分： 数据库服务器、客户应用程序和网络。

服务器负责有效的管理系统的资源，其任务集中于以下几个方面：

• 数据库安全性的要求
• 数据库访问并发行的控制
• 数据库前端的客户应用程序的全局数据完整性规则
• 数据库的备份与恢复

客户端应用程序的主要任务：

• 提供用户与数据库交互的界面
• 向数据库服务器提交用户请求并接受来自数据服务器的信息
• 利用客户端应用程序对存在与客户端的数据执行应用逻辑要求
• 网络通信软件主要作用是完成数据库服务器和客户端应用程序之间的数据传输。

优点：

• 系统的客户端应用程序和服务器构件分别运行在不同的计算机上，系统中的每台服务器都可以是合格构件的要求，这对于硬件与软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。
• 在C/S体系结构中，系统中的功能充分分离，客户端应用程序的开发集中于数据的现实和分析，儿数据服务器的开发则集中于数据的管理，不必在每个新的应用程序中都对DBMS进行编码。
• C/S体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。

缺点：

• 开发成本高
• 客户端程序设计复杂
• 信息内容和形式单一
• 用户界面风格不一，使用复杂，不利于推广使用。
• 软件移植困难
• 软件维护和升级困难
• 新技术不能轻易应用

5.11 三层C/S结构风格
表示层：

• 表示层是应用的用户接口部分，它担负着应用与用户之间的对话功能，用于检查用户从键盘等输入的数据，显示应用输出的数据。
• 再变更用户界面时，只需改写显示控制和数据检查程序，而不影响其他两层。
• 检查的内容也仅限于数据得形式和取值范围，不包括业务本身的处理逻辑。

功能层：

• 功能层相当于应用的本体，用于将具体的业务处理逻辑编入程序。
• 表示层和功能层之间的数据交互要尽可能简洁。
• 在功能层中包含确认用户对应用与数据库存取权限的功能以及记录系统处理日志的功能。

数据层：

• 数据层就是数据库管理系统，负责管理对数据库的读写操作。
• 数据库管理系统必须能迅速执行大量数据的更新和检索。
• 中间件：一个用API定义的软件层，是具有强大通信能力与良好可扩展性的分布式软件 管理框架。
• 功能：在客户机和服务器或者服务器和服务器之间传送数据，实现客户集群和服务器群之间的通信。
• 工作流程：在客户机中的某个应用程序选哟驻留网络上某个服务器的数据或服务时，搜 索此程序的C/S应用程序需要访问中间件系统，该系统将查找数据源或服务，并在 发送应用程序请求后重新响应，将其传送回应用程序。

三层C/S结构的优点：

• 允许合理的划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统与软件的可维护性和可拓展性。
• 允许更灵活有效的选用相应的平台与硬件系统，使之在处理负荷能力上和处理特征上分别适应于结构清晰的三层，而且这些平台与各个组成部分可以具有良好的可升级性和开放性。
• 应用的各层可以并行开发，各层也可以选择各自最适合的开发语言，使之能并行的而且高效率的进行开发，达到较高的性价比，对每一层的处理逻辑的开发和维护也会更容易一些。
• 允许充分利用功能层有效的隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客工具去非法的访问数据层，这就为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理和可控。

5.12B/S风格
B/S软件体系结构是随着Internet技术的兴起，对C/S结构改进后得到的一种结构。
在B/S体系结构下，用户界面完全通过WWW浏览器实现，部分事务逻辑在前端实现，但主要是无逻辑在服务器端实现。
他利用浏览器技术，结合浏览器的多种脚本语言并通过浏览器就实现了原本需要复杂的专业软件才能实现的强大功能，是一种全新的软件体系结构。

• 优点：
  简化了客户端，无需像C/S模式那样在不同的客户机安装不同的客户端应用程序，而只需安装通用的浏览器软件，就可以享受到无限丰富的永远在不断变化和发展中的信息服务。

特别适用于网上信息的发布。
通过Internet技术统一访问不同种类的数据库，提供了异种机器、异种网络、异种应用服务之间的统一服务 的最现实开发基础。

5.13C/S与B/S混合结构风格

• 优点： 外部用户不直接访问数据库，从而能保证企业数据库的相对安全， 企业内部的交互性较强，数据查询和修改的的响应速度较快。
• 缺点： 企业外部用户修改和维护数据时的速度较慢，较繁琐，数据的动态交互性不强。

5.14 正交软件体系结构的概念

• 正交软件结构由组织层和线索的构件构成。
• 层是由一组具有相同抽象级别的构件构成的。
• 线索是子系统的特例，它由完成不同层次功能的构件构成（通过相互调用来关联），每一条线索完成整个系统中相对独立的一部分功能。
• 每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的构件之间是不存在相互调用的。

正交软件体系结构的主要特征：

• 正交软件体系结构有完成不同功能的n（n>1）个线索（子系统）组成。
• 系统具有m（m>1）个不同抽象级的层。
• 线索之间是相互独立的。（正交的）
• 系统有一个公共驱动层（一般为最高层），和公共数据结构（一般为最底层）。

正交软件体系结构的优点：

• 结构清晰，易于理解
• 易修改，可维护性强
• 可维护性强，重用粒度大

5.15 异构结构风格
使用异构结构的原因：

• 从最根本上来说，不同的结构由不同的处理能力的强项和弱点，一个系统的体系结构应该根据实际需要进行选择，已解决实际问题。
• 软语软件包、框架、通信以及其他一些体系结构上的问题，目前存在多种标准。
• 实际工作中，总会遇到一些遗留下来的代码，它们仍有效用，但是却与信系统有某种程度上的不协调。
• 即使在某一单位中，规定了共享共同的软件包或相互关系的一些标准，仍会存在解释或表示习惯上的不同，在UNIX中就可以发现这类问题：即使规定用单一的标准（ASCII）来保证过滤器之间的通信，但不同人对关于在ASCII流中信息如何表示的不同假设，不同的过滤器之间仍可能不协调。

异构体系结构实例——“内外有别”模型
优点：

• 外部用户不直接访问数据库服务器，能保证企业数据库的相对安全。
• 企业内部用户的交互性较强，数据查询和修改的速度较快。

缺点：

• 企业外部用户修改和维护数据时的速度较慢，较繁琐，数据的动态交互性不强。

异构体系结构实例——“查改有别”模型
缺点：

• 外部用户能够直接通过Internet连接到数据库服务器，企业数据容易暴露给外部用户，给数据安全造成一定威胁。