第 6 章 Web服务体系结构

6.1 Web服务概述

6.1.1 什么是Web服务

Web服务是使用标准技术在Internet上运行的商务流程，它可以使用标准的Internet协议，将功能纲领性地体现在Internet和Intranet上

6.1.3 Web服务的特点

• 使用标准协议规范
• 使用协约的规范性
• 高度集成能力
• 完好的封装性
• 松散耦合

6.2 Web服务体系结构模型

• Web服务模型

  一个完整的Web服务包括三种逻辑构件：服务提供者、服务代理和服务请求

• Web服务开发声明周期

  Web服务开发生命周期可分为构建、部署、运行和管理四个阶段

  • 构建：构建阶段包括开发和测试Web服务的实现，定义服务接口描述和定义服务实现描述
  • 部署：部署阶段包括向服务器请求者或服务注册中心发布服务接口和服务实现的定义，以及把Web服务的可执行文件部署到执行环境中
  • 运行：在运行阶段，可以调用Web服务
  • 管理：管理阶段包括持续的管理和经验Web服务应用程序
• Web服务栈
  

  发现服务	UDDI、DISCO
  描述服务	WSDL、XML、Schema
  消息格式层	SOAP
  编码格式层	XML
  传输协议层	HTTP、TCP/IP、SMTP等

• Web服务体系结构的优势
  • 高度的通用性和易用性：Web服务利用标准的Internet协议，解决了面向Web的分布式计算模型，提高了系统的开放性、通用性和可扩展性
  • 完全的平台、语言独立性：Web服务进行了更高程度的抽象，只要遵循Web服务的接口即可进行服务的请求和调用
  • 高度的集成性：Web服务实质上就是通过服务的组合来完成业务逻辑的，因此表现出高度的组装性和集成性
  • 容易部署和发布：Web服务体系结构方案通过UDDI、WSDL和SOAP等技术协议，很容易实现系统的部署

6.3 Web服务的核心技术

6.4 面向服务的软件体系结构

第 7 章 基于体系结构的软件开发

7.1 设计模式

7.1.1 设计模式概述

将设计面向对象软件的经验记录成“设计模式”。简单的理解，就是一些设计面向对象的软件开发的经验总结。

• 设计模式的定义：模式是指从某个具体的形式得到的一些抽象，在特殊的非任意性的环境中，该形式不断地重复出现。

7.1.2 设计模式的组成

• 设计模式的基本成分
  • 模式名称：通常用来描述一个设计问题、它的解法和后果，由一到两个词组成
  • 问题：问题告诉我们什么时候要使用设计模式、解释问题及其背景
  • 解决方案：解决方案描述设计的基本要素，它们的关系、各自的任务以及相互之间的合作
  • 后果：后果描述应用设计模式后的结果和权衡
• 设计模式的描述

  目前最常用的描述设计模式的格式：

  • 模式名称和分类：模式名称和一个简短的摘要
  • 目的：回答下面的问题，即本设计模式的用处、它的基本原理和目的、它针对的是什么特殊的设计问题
  • 别名：由于设计模式的提取是由许多专家得到的，同一个模式可能会被不同的专家冠以不同的别名
  • 动机：描述一个设计问题的方案，以及模式中类和对象的结构是如何解决这个问题
  • 应用：在什么情况下可以应用本设计模式，如何辨认这些情况
  • 结构：用对象模型技术对本模式的图像表示。另外，也给出了对象间相互的要求和合作的内在交互图
  • 成分：组成本设计模式的类和对象及它们的职责
  • 合作：成分间如何合作实现它们的任务
  • 后果：该模式如何支持它的对象；如何在使用本模式时进行权衡，即其结果如何；可以独立地改变系统结构的哪些方面
  • 实现：在实现本模式的过程中，要注意哪些缺陷、线索或者技术；是否与编程语言有关
  • 例程代码：说明如何使用C++或者其他语言来实现该模式的代码段
  • 已知的应用：现实系统中使用该模式的实例
  • 相关模式：与本模式相关的一些其他模式，它们之间的区别，以及本模式是否要和其他模式共同使用

7.1.3 模式和软件体系结构

判断模式取得成功的一个重要准则是它们在多大程度上达到了软件工程的目标

• 模式作为体系结构构造块
• 构造异构体系结构
• 模式和方法
• 实现模式

7.1.4 设计模式方法分类

• 创建性模式：处理的是对象的创建过程
• 结构性模式：处理的事对象/类的组合
• 行为性模式：处理类和对象的交互方式和任务分布

创建性模式

设计模式	简要说明	可改变的方面
Abstract Factory	提供创建相关的或相互依赖的一组对象的接口，使我们不需要指定类	产品对象族
Builder	将一个复杂对象的结构和它的描述隔离开来，使我们使用相同的结构可以得到不同的描述	如何建立一种组合对象
Factory Method*	定义一个创建对象的结构，但由子类决定需要实例化哪一个类	实例化子类的对象
Prototype	使用一个原型来限制要创建的类的类型，通过拷贝这个原型得到新的类	实例化类的对象
Singleton	保证一个类只有一个实例，并提供一个全局性的访问点	类的单个实例

结构性模式

设计模式	简要说明	可改变的方面
Adapter*	将一个类的接口转换成用户希望得到的另一种接口。它使原来本不相容的接口得以协同工作	与对象的结构
Bridge	将类的抽象概念和它的实现分离开来，使它们可以相互独立地变化	对象的实现
Composite	将对象组成树结构来表示局部和整体的层次关系。客户可以统一处理单个对象和对象组合	对象的结构和组合
Decorator	给对象动态地加入新的职责。它提供了用子类扩展功能的一个灵活的替代	无子类对象的责任
Facade	给一个子系统的所有结构提供一个统一的接口。它定义了更高层的接口，使该子系统更便于使用	与子系统的接口
Flyweight	提供支持大量细粒度对象共享的有效方法	对象的存储代价
Proxy	给另一个对象提供一个代理或定位符号，以控制对它的访问	如何访问对象，对象位置

行为性模式

设计模式	简要说明	可改变的方面
Chain of Responsibility	通过给多个对象处理请求的机会，减少请求的发送者与接收者之间的耦合。将接收对象链接起来，在链中传递请求，直到有一个对象处理这个请求	可满足请求的对象
Command	将一个请求封装为一个对象，从而将不同的请求对数化并进行排队或登记，以支持撤销操作	何时及如何满足一个请求
Interpreter*	给定一种语言，给出它的语法的一种描述方法和一个解释器，该解释器用这种描述方法解释语言中的句子	语言的语法和解释
Iterator	提供一种顺序性访问一个聚集对象中元素的方法，而不需要暴露它的底层描述	如何访问、遍历聚集的元素
Mediator	定义一个对象来封装一系列对象的交互。它保持对象间避免显式地互相联系，而消除它们间的耦合，还可以独立地改变对象间的交互	对象之间如何交互以及哪些对象交互
Memento	在不破坏封装的条件下，获得一个内部状态并将它外部化，从而可以在以后使对象恢复到这个状态	何时及哪些私有信息存储在对象之外
Observer	定义一个对象间一对多的信赖关系，当一个对象改变状态时，所有与它由信赖关系的对象都得到通知并自动更新	信赖于另一个对象的对象数量，信赖对象如何保持最新数据
State	允许一个对象在内部状态改变时的行为，对象看起来似乎能改变自己的类	对象的状态
Strategy	定义一族算法，对每一个都进行封装，使他们互相可交换。它使算法可以独立于它的用户而变化	算法
Template Method*	定义一个操作的算法骨架，使某些步骤决定于子类。它使子类重定义一个算法的某些步骤，但不改变整个算法的结构	算法的步骤
Visitor	描述在一个对象结构中对某个元素需要执行的一个操作。它使我们在不改变被操作的元素类的条件下定义新操作	无需改变其类可应用于对象的操作

其中带*为关于类的，其他是关于对象的

7.2 基于体系结构的设计方法

7.3 体系结构的设计与演化

7.3.1 设计和演化过程

基于体系结构的软件开发过程可以分为独立的两个阶段，这两个阶段分别是实验原型阶段和演化开发阶段

• 实验原型阶段：这一阶段首要考虑的问题是要获得对系统的问题域的理解
• 演化开发阶段：这一阶段的重点将转移到构件的精确化

7.3.2 实验原型阶段

实验原型阶段的第一个开发周期没有具体的、明确的目标。

实验原型阶段的第二个开发周期的任务是设计和建立一个正交软件体系结构，该结构具有的特征有：

• 必须足够灵活，不但能包含现有的元素，而且能包含新增的功能
• 必须提供一个相当稳定的结构，在这个结构中，原型能在实验原型阶段进行演化
• 必须支持一个高效的开发组织，允许所有开发人员并行地在原型的基础上进行开发

整个第二个开发周期又可细分为六个小阶段：

• 标识构件：为系统生成初始逻辑结构，包含大致的构件
• 提出软件体系结构模型
• 把已标识的构件映射到软件体系结构中
• 分析构件之间的相互作用
• 产生软件体系结构
• 软件体系结构正交化

7.3.3 演化开发阶段

• 需求变动归类：必须对用户需求的变动进行归类，使变化的需求与已有构件和线索对应
• 制定体系结构演化计划
• 修改、增加或删除构件
• 更新构件的相互作用
• 产生演化后的体系结构
• 迭代
• 对以上的步骤进行确认，进行阶段性技术评审
• 对所做的标记进行处理

7.4 基于体系结构的软件开发模型

7.4.1 体系结构需求

体系结构需求获取过程如图：

• 需求获取：定义开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务上的功能需求
• 标识构件
• 需求评审

7.4.2 体系结构设计

体系结构设计过程如图

• 提出软件体系结构模型
• 把已标识的构件映射到软件体系结构中
• 分析构件之间的相互作用
• 产生软件体系结构
• 设计评审

7.4.3 体系结构文档化

文档是系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证体系结构设计和提炼或修改这些设计所执行预先分析的基础

体系结构文档化过程的主要输出结果是体系结构需求规格说明和测试体系结构需求的质量设计说明书这两个文档

7.4.4 体系结构复审

复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等

7.4.5 体系结构实现

“实现”就是要用实体来显示出一个软件体系结构，即要符合体系结构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。实现过程如图：

7.4.6 体系结构演化

体系结构演化过程如图：

• 需求变动归类
• 制定体系结构演化计划
• 修改、增加或删除构件
• 更新构件的相互作用
• 构件组装与测试
• 技术评审
• 产生演化后的体系结构

7.6 基于体系结构的软件过程

7.6.1 有关概念

• 软件过程：软件过程式人们建立、维护和演化软件产品整个过程中所有技术活动和管理活动的集合
• Petri网：一种用于系统描述和分析的数学工具

第 8 章 软件体系结构的分析与测试

8.1 体系结构的可靠性建模

在基于构件的可靠性模型中，通过状态图来描述系统的行为。一个状态表示一个构件的执行，从一个状态到另一个状态的迁移概率通过系统的操作剖面而获得。软件系统的可靠性依赖状态的执行顺序和每一个状态的可靠性

四种常用的结构风格模型：顺序结构风格、并行/管道-过滤器结构风格、容错结构风格、调用-返回结构风格

• 顺序结构风格

  在顺序结构风格中，系统的运行按构件的顺序依次执行，顺序结构风格广泛应用于银行系统的日常数据更新。该风格的模型图如图：

  

• 并行/管道-过滤器结构风格

  在顺序执行环境中，某一时刻只有一个构件执行，然而在当前执行环境中构件通常是同时运行的，把这种行为成为并行/管道-过滤器结构风格，主要用来提高系统性能

  在并行/管道-过滤器体系结构风格中，多个构件可以同时执行，结构如图

  

• 容错结构风格

  容错体系结构风格是由一个原始构件和一系列的备份构件组成，包括原始构件和备份构件都被放置在一个并行结构下，使得当一个构件出现错误时，其他构件能够继续提供服务

  

• 调用-返回结构风格

  在调用返回结构风格中，一个构件在完成一次迁移之前，在执行过程可能需要调用其他构件提供的服务，因此必须在该调用完成之后并返回调用构件后，才执行当前构件剩下的下一个状态。在调用-返回结构风格中，被调用构件可能被多次调用，而调用构件只执行一次。

  

8.2 软件体系结构的风险分析

风险评估过程通常是用于验证需要详细检测的复杂模型，来估计潜在的模型问题和测试效果，在不同的开发阶段都可以执行分析评估

8.2.1 风险分析的方法

• 动态方法：用来评估执行中的软件体系结构的动态耦合度和动态复杂度，动态耦合度是用来度量在特定的执行场景中，两个相互连接的构件或连接件之间的活跃程度，动态复杂度方法是用来度量特定构件在给定场景下的动态行为
• 构件依赖图：用于在体系结构级进行可靠性分析的概率模型，是一个对基于构件的软件系统的可靠性分析模型，它是控制流图的一个扩展

8.2.2 风险分析的步骤

体系结构分析方法的主要步骤如下：

• 采用体系结构描述语言对体系结构进行建模
• 通过模拟方法进行复杂性分析
• 通过FMEA和模拟运行进行严重性分析
• 为构件和连接件开发其启发式风险因子
• 建立用户风险评估的CDG
• 通过图论中的算法进行风险评估和分析

8.3 基于体系结构描述的软件测试

8.3.1 测试方法

软件体系结构测试与程序测试有所不同，它是检查软件设计的适用性，这种测试不考虑软件的实现代码，所以基于实现和说明的程序测试方法对软件体系结构并不适用

• 测试内容

  与传统的软件测试一样，基于体系结构的软件测试也需要研究测试内容、测试准则、测试用例、测试充分性及测试方法等问题

• 测试准则

  测试应覆盖所有的构件及各个构件的接口、各个连接件的接口、构件之间的直接连接、构件之间的间接连接

• 测试需求和测试用例的生成

  几种测试路径：

  • 构件或连接件内部消息的传递路径
  • 构件或连接件内部端口的执行顺序路径
  • 构件之间到连接件或连接件到构件的消息传递路径
  • 构件之间的直接连接路径
  • 构件之间的间接连接路径
  • 所有构件的连接路径

  软件体系结构测试过程可分为单元测试、集成测试和系统测试

第 9 章 软件体系结构评估

9.1 软件体系结构评估概述

9.1.1 软件质量属性

• 性能：系统的响应能力
• 可靠性：软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性分为两个方面：
  • 容错：目的是在错误发生时确保系统正确的行为，并进行内部“修复”
  • 健壮性：只能保证软件按照某种已经定义好的方式终止执行
• 可用性：系统能够正常运行的时间比例
• 安全性：系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力
• 可修改性：能够快速地以较高的性能价格比对系统进行变更的能力。包含四个方面：
  • 可维护性：在错误发生后“修复”软件系统
  • 可扩展性：使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件
  • 结构重组：重新组织软件系统的构件及构件间的关系
  • 可移植性：使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器
• 功能性：系统所能完成所期望的工作的能力
• 可变性：体系结构经扩充或变更而成为新体系结构的能力
• 集成性：系统能与其他系统协作的程度
• 互操作性：系统组成部分的软件不是独立存在的，经常与其它系统或自身环境相互作用

9.1.2 几个基本概念

• 敏感点和权衡点

  敏感点和权衡点是关键的体系结构决策

• 风险承担者

  风险承担者在向上管理领域中通常翻译为“项目干系人”或“涉众”

• 场景

  从风险承担者的角度对与系统的交互的简短描述

9.2 评估的主要方式

• 基于调查问卷或检查表的评估方式

  这一评估方式比较灵活，可评估多种质量属性，也可在软件体系结构设计的多个阶段进行

• 基于场景的评估方式

  这一评估方式考虑到了包括系统的开发人员、维护人员、最终用户、管理人员、测试人员等在内的所有与系统相关的人员对质量的要求

• 基于度量的评估方式

  这一评估方式提供更为客观和量化的质量评估，需要在软件体系结构的设计基本完成以后才能进行

• 评估方式的比较：
  

  评估方式	调查问卷	检查表	场景	度量
  通用性	通用	特定领域	特定系统	通用或特定领域
  评估者对体系结构的了解程度	粗略了解	无限制	中等了解	精确了解
  实施阶段	早	中	中	中
  客观性	主观	主观	较主观	较客观

9.3 ATAM评估方法

使用ATAM方法对软件体系结构进行评估的目标是理解体系结构关于软件系统的质量属性需求决策的结果

9.3.1 ATAM评估的步骤

整个ATAM评估过程包括九个步骤，按其编号顺序分别是描述ATAM方法、描述商业动机、描述体系结构、确定体系结构方法、生成质量属性效用树、分析体系结构方法、讨论和分级场景、分析体系结构方法、描述评估结果

9.4 SAAM评估方法

9.4.1 SAAM评估的步骤

• 形成场景
• 描述体系结构
• 对场景进行分类和确定优先级
• 对间接场景进行单个评估
• 评估场景的相互作用
• 形成总体评估
• SAAM评估日程安排

第 10 章 软件产品线体系结构

10.1 软件产品线的出现和发展

10.2 软件产品线概述

10.2.1 软件产品线的基本概念

产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场货任务领域的特定需求。这些系统遵循一个预描述的方式，在公共的核心资源基础上开发

10.2.2 软件产品线的过程模型

• 双生命周期模型

  最初的和最简单的软件产品线开发过程式双声明周期模型，来自STARS，分成两个重叠的声明周期：领域工程和应用工程。两个周期内部都分成分析、设计和实现三个阶段，如图

  

  邻域工程阶段的主要任务如下：

  • 领域分析：利用现有系统的设计、体系结构和需求建立领域模型
  • 领域设计：用领域模型确定领域/产品线的共性和可变性，为产品设计体系结构
  • 领域实现：基于领域体系结构开发领域可重用资源

  应用工程经过以下阶段，生成新产品：

  • 需求分析：将系统需求与领域需求比较，划分成领域公共需求和独特需求两部分，得出系统说明书
  • 系统设计：在领域体系结构基础上，结合系统独特需求设计应用的软件体系结构
  • 系统实现：遵照应用体系结构，用领域可重用资源实现领域公共需求，用定制开发的构件满足系统独特需求，构件新的系统

  STARS的双生命周期模型定义了典型的产品线开发过程的基本活动、各活动内容和结果以及产品线的演化方式。这种产品线方法综合了软件体系结构和软件重用的概念，在模型中定义了一个软件工程化的开发过程，目的是提高软件生产率、可靠性和质量，降低开发成本，缩短开发时间

• SEI模型

  SEI将产品的基本活动分为三部分，分别是核心资源开发、产品开发和管理。主要特点如下：

  • 循环重复是产品线开发过程的特征，也是核心资源开发、产品线开发以及核心资源和产品之间协作的特征
  • 核心资源开发和产品开发没有先后之分
  • 管理活动协调整个产品线开发过程的各个活动，对产品线的成败负责
  • 核心资源开发和产品开发是两个互动的过程，三个活动和整个产品线开发之间也是双向互动的
• 三生命周期模型

  Fred针对大型软件企业的软件产品线开发对双生命周期模型进行了改进，提出了三生命周期软件工程模型，如图

  

10.2.3 软件产品线的组织结构

软件开发的组织结构分为两个基本组成部分：负责核心资源的小组、负责产品的小组

10.2.4 软件产品线的建立方式

软件产品线的建立需要希望使用软件产品线方法的软件组织有意识地、明显地努力才有可能成功

软件产品线的建立通常有四种方式，其划分依据有两个：

• 该组织是用演化方式还是革命方式引入产品线开发过程
• 是基于现有产品还是开发全新的产品线

	演化方式	革命方式
基于现有产品集	基于现有产品体系结构开发产品线的体系结构，经演化现有构件的文件一次开发一个产品线构件	产品线核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集
全新产品线	产品线核心资源随产品新成员的需求而演化	开发满足所有预期产品线成员的需求的产品线核心资源

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

  在基于现有产品体系结构设计的产品线体系结构的基础上，将特定产品的构件逐步地、越来越多地转化为产品线的共用构件，从基于产品的方法“慢慢地”转化为基于产品线的软件开发。主要优点是通过对投资回报周期的分解，对现有系统演化的维持，使产品线方法的实施风险降到最小，但完成产品线核心资源的总周期和总投资都比使用革命方式要大

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

  基本停止现有产品的开发，所有努力直接针对软件产品线的核心资源开发。这种方法的目标是开发一个不受现有产品集存在问题的限制的、全新的平台，总周期和总投资演化方法要少，但因重要需求的变化导致的初始投资报废的风险加大。另外，基于核心资源的第一个产品面世的时间将会推后

• 全新软件产品线的演化

  当一个软件组织进入一个全新的领域要开发该领域的一系列产品时，同样也有演化和革命两种方式。

• 全新软件产品线的开发

  体系结构设计师和工程师首先要得到产品线所有可能的需求，基于这个需求超集来设计和开发产品线核心资源

10.2.5 软件产品线的演化

产品线的演化包括产品线核心资源的演化、产品的演化和产品的版本升级

10.3 框架和应用框架技术

应用框架的描述：

• 应用框架解决的是一个领域或产品族的问题，规定了问题应该如何分解
• 包含了应用或子系统的设计，由一个互相协作的类或构件集合组成
• 可以通过继承或类的组合来创建应用

框架技术的基本特定：

• 反向控制：类库是客户代码调用库中已存在类的方法，框架内嵌了控制流，框架调用客户代码——加入框架的新构件和抽象类的方法实例
• 可重用性：框架提供了设计和代码的重用能力
• 扩展性：为规划的变化提供了“热点”或“钩子”等显式说明方式
• 模块化或构件化：框架有固定的、稳定的接口和封装的热点

一般框架有三种建立方式：自顶向下，自底向上和混合方式

框架的使用和扩展方式，可以将框架分为两大类：黑盒框架和白盒框架：

• 黑盒框架通过构建/类的组合来支持重用和扩展
• 白盒框架一般使用类的继承机制实现，由未完成的类（抽象类）组成，类有一个或多个抽象接口或虚方法

白盒重用需要对框架有很好的理解，生成紧耦合系统。黑盒重用不需要对框架的内部结构有太多的了解，产生松耦合系统。具体的框架实际上都是“灰色”的，是可继承和可组合方式的结合。

10.4 软件产品线基本活动

• 产品线分析

  产品线分析是产品线的需求工程，是商业机遇的确认和产品线体系结构的设计之间的桥梁。产品线分析强调：

  • 通过捕获风险承担者的观点来揭示产品需求
  • 通过系统的推理和分析、集成功能需求和非功能需求来完成产品线需求
  • 产品线设计师对产品线需求的可用性
• 产品开发

  产品开发活动取决于产品线范围、核心资源库、产品计划和需求的输出

  产品开发的输入如下

  • 特定产品的需求，通常由包含在产品线范围内的一些产品描述来表达
  • 产品线范围，指明正在考债的产品是否适合包含在产品线中
  • 构件产品所需的核心资源库
  • 产品计划指明核心资源如何应用到产品的构建中

从本质上说，产品线是一组相关产品的集合。但是，怎么实现却有很大的不同，这取决于资源、产品计划和组织环境

10.5 软件产品线体系结构的设计

10.5.1 产品体系结构简介

软件体系结构设计的主要目的是满足对软件的质量需求。软件体系结构的应用方式有三种：用于独立软件体系、软件产品体系结构、用户公共构件市场的标准软件体系结构

产品线体系结构的设计目的就是尽量扩展产品线中所有产品共享的共性部分，同时提供一个尽量灵活的体系结构变化机制

产品线体系结构主要需考虑一下因产品线的特殊性而出现的变化需求：

• 产品线的产品有着不同的质量属性
• 产品之间的差异可能体现在各个方面：行为、质量属性、平台和中间件技术、网络、物理配置、规模等，产品线体系结构需要对这些差异进行处理

产品线体系结构设计面临的主要困难和问题如下：

• 没有熟练的体系结构设计师
• 参数化问题
• 必须有良好的领域分析和产品规则基础做保证，对技术发展趋势要做出准确预测，还要注意吸取相关领域的教训
• 软件开发、管理和市场人员组织的管理和文化对基于软件体系结构开发的适应程度
• 目前，支持软件体系结构设计的CASE工具较少
• 产品线体系结构设计师和产品开发者之间的沟通

10.5.2 产品线体系结构的标准化和定制

软件体系结构是产品线所有可重用的核心资源中最重要的部分，是软件产品线成功的关键技术性资源

产品线体系结构的设计有两种方式：使用标准体系结构和体系结构定制

10.6 软件产品线体系结构的演化

产品线的演化可分为两个部分，一是企业如何组织其产品线结构的变化，另一个是实际的演化，该演化作为一个需求通过静态组织进行传播

10.6.3 需求和演化的分类

产品线体系结构的演化史一个复杂的、难以管理的问题。增加人们对产品线体系结构演化的理解，改进在产品线体系结构及其构件中引入新的需求的方式是十分重要的。

• 需求分类

  需求大致分为6类：

  • 构件新的产品族
  • 在产品线中增加新的产品
  • 改进已有功能
  • 扩展标准支持
  • 硬件、操作系统的新版本，或第三方增加了新功能
  • 改进框架的质量属性

  以上需求分类的关系如图：

  

• 产品线体系结构演化的分类

  把新的需求引入到所有产品中，将对产品线体系结构产生影响。产品线体系结构演化的8种情况：

  • 产品线体系结构的分解
  • 导出产品线体系结构
  • 新产品线体系结构构件
  • 修改产品线体系结构构件
  • 分解产品线体系结构构件
  • 代替产品线体系结构构件
  • 增加构件之间的关系
  • 修改构件之间的关系

  上述8类产品体系结构演化的关系如图：

  

• 产品线体系结构构件演化的分类

  产品线体系结构构件的修改细分为5类：

  • 新框架的实现
  • 修改框架的实现
  • 在框架实现中缩减功能
  • 增加框架功能
  • 使用其他的框架体系结构，增加外部构件

  上述5类产品线体系结构演化的关系如图：

  

  在很多情况下，演化类型并不是由需求变化直接引起的，而是需求变化的间接结果，一种类型的变化引起另一种类型的变化，后者与前者往往处于同一个级别，即在产品线体系结构中的变化会引起另一个产品线体系结构类型的变化

第 1 章 软件体系结构概论

1.1 从软件危机谈起

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题

1.1.1 软件危机的表现

• 软件成本日益增长
• 开发进度难以控制
• 软件质量差
• 软件维护困难

1.1.2 软件危机的成因

• 用户需求不明确
• 缺乏正确的理论指导
• 软件规模越来越大
• 软件复杂度越来越高

1.1.3 如何克服软件危机

采用工程的方法进行软件生产可以克服软件危机，于是诞生了软件工程

软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法

软件工程包括三个要素：方法、工具和过程

1.2 构件与软件重用

软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相近软件元素的过程。

软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识。这些可重用的元素称做软构件，简称构件

由于构件大都经过严格的质量认证，并在实际运行环境中得到检验，因此，重用构件有助于改善软件质量

1.2.1 构件模型及实现

构件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通信接口和实现代码的复合体。简单地说，构件是具有一定的功能，能够独立工作或能同其它构件装配起来协调工作的程序体。

构件模型是对构件本质特征的抽象描述

1.2.2 构件获取

在建立基于构件的软件开发（component-based software development, CBSD）中，构件获取可以有多种不同的途径：

• 从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用的构件
• 通过遗留工程，将具有潜在重用价值的构件提取出来，得到可重用的构件
• 从市场上购买现成的商业软件，即CTOS（commerical off-the-shell）构件
• 开发新的符合要求的构件

一个组织在进行以上决策时，必须考虑到不同方式获得构件的一次性成本和以后的维护成本，然后做出最优的选择

1.2.3 构建管理

对大量的构件进行有效的管理，以方便构件的存储、检索和提取，是成功重用构件的必要保证。构件管理的内容包括构建描述、构建分类、构件库组织、人员及权限管理和用户意见反馈等

1.3 软件体系结构的兴起和发展

1.3.1 软件体系结构的定义

软件体系结构为软件系统提供了一个结构，行为和属性的高级抽象，由构成系统的元素的描述，这些元素的相互作用，知道元素集成的模式以及这些模式的约束组成

1.3.2 软件体系结构的意义

• 体系结构是风险承担者进行交流的手段
• 体系结构是早期设计决策的体现
• 软件体系结构是可传递和可重用的模型

1.4 软件体系结构的应用现状

• 软件体系结构描述语言
• 体系结构描述构造与表示
• 体系结构分析、设计与验证
• 体系结构发现、演化和重用
• 基于体系结构的软件开发方法
• 特定领域的体系结构框架
• 软件体系结构支持工具
• 软件产品线体系结构
• 建立评价软件体系结构的方法

第 2 章 软件体系结构建模

2.1 软件体系结构建模概述

可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。最常用的是结构模型和动态模型

2.2 “4+1”视图模型

“4+1”视图模型从5个不同的视角，包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。每一个视图只关心一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容

2.2.1 逻辑视图

逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。逻辑视图中使用的符号集合如下

2.2.2 开发视图

开发视图也称模块视图，主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进行开发。下图是用来表示开发视图的符号

2.2.3 进程视图

进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。如下是进程视图使用的标记符号

2.2.4 物理视图

物理视图主要考虑如何把软件映射到硬件上，它通常要考虑系统性能、规模、可靠性等。下图是物理视图的标记元素集合

2.3 软件体系结构的核心模型

体系结构的核心模型由5种元素组成：构件、连接件、配置、端口和角色。其中构件、连接件和配置是最基本的元素

构件是具有某种功能的可重用的软件模块单元，表示系统中主要的计算元素和数据存储。构件有两种：复合构件和原子构件

连接件表示构件之间的交互，简单的连接件如：管道、过程调用、事件广播等，更为复杂的交互如：客户-服务器通信协议，数据库和应用之间的SQL链接等

配置表示构件和连接件的拓扑逻辑和约束

2.4 软件体系结构的生命周期模型

• 需求分析阶段
• 建立软件体系结构阶段
• 设计阶段
• 实现阶段

第 3 章 软件体系结构风格

3.1 软件体系结构风格概述

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

3.2 经典软件体系结构风格

3.2.1 管道和过滤

在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。

管道/过滤器风格的软件体系结构具有许多很好的特点：

• 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点
• 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成。
• 支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来
• 系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉
• 允许对一些如吞吐量、死锁等属性的分析
• 支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行

这样的系统也存在着若干不利因素：

• 通常导致进程称为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换
• 不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重
• 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性

3.2.2 数据抽象和面向对象组织

这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和他们的相应操作封装在一个抽象数据类型或对象中

面向对象的系统有许多的优点：

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

但是，面向对象的系统也存在着某些问题

• 为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象
• 必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么C对B的使用所造成的对A的影响可能是料想不到的

3.2.3 基于事件的隐式调用

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

基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响

隐式调用系统的主要优点如下：

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

隐式调用系统的主要缺点如下：

• 构件放弃了对系统计算的控制。一个构件出发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了那些构件的构成，它也不能保证这些过程被调用的顺序
• 数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题
• 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题

3.2.4 分层系统

层次系统组成成一个层次结构，每一层为上层服务，并作为下层客户。

层次系统的许多可取属性如下：

• 支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解
• 支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层
• 支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法

但是，层次系统也有不足之处，如下：

• 并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来
• 很难找到一个合适的、正确的层次抽象方法

3.2.5 仓库系统及知识库

在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化

黑板系统主要由一下三部分组成：

• 知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的交互只通过黑板来完成
• 黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题
• 控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识

3.2.6 C2风格

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

C2风格中的系统组织规则如下：

• 系统中的构件和连接件都有一个顶部和一个底部
• 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的
• 一个连接件可以和任意数目的其他构件和连接件连接
• 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部

C2风格具有以下特点：

• 系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起
• 所有构件之间的通信是通过以连接件为中介的异步消息交换机制来实现的
• 构件相对独立，构件之间依赖性较少，系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设

3.3 客户/服务器风格

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

服务器的主要任务是：

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

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

• 提供用户与数据库交互的界面
• 向数据库服务器提交用户请求并接受来自数据库服务器的信息
• 利用客户应用程序对存在客户端的数据执行应用逻辑要求

网络通信软件的主要作用是完成数据库服务器和客户应用程序之间的数据传输

C/S体系结构的优点主要在于系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小

C/S体系结构的缺点如下：

• 开发成本较高。C/S体系结构对客户端软硬件配置要求较高，尤其是软件的不断升级，对硬件要求不断提高，增加了整个系统的成本，且客户端变得越来越臃肿
• 客户端程序设计复杂。采用C/S体系结构进行软件开发，大部分工作量放在客户端的程序设计上，客户端显得十分庞大
• 信息内容和形式单一，因为传统应用一般为事务处理，界面基本遵循数据库的字段解释，开发之初就已确定，而且不能随时截取办公信息和档案等外部信息，用户获得的只是单纯的字符和数字，既枯燥又死板
• 用户界面风格不一，使用繁杂，不利于推广使用
• 软件移植困难。采用不同开发工具或平台开发的软件，一般互不兼容，不能或很难移植到其他平台上运行
• 软件维护和升级困难。采用C/S体系结构的软件升级，开发人员必须到现场为客户机升级，每个客户机上的软件都需维护。对软件的一个小小改动，每个客户端都必须更新
• 新技术不能轻易应用。因为一个软件平台及开发工具一旦选定，不可能轻易更改

3.4 三层C/S结构风格

3.4.1 三层C/S结构的概念

传统的二层C/S结构存在以下几个局限：

• 二层C/S结构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet
• 软、硬件的组合及集成能力有限
• 客户机的负荷太重，难以管理大量的客户机，系统的性能容易变坏
• 数据安全性不好。因为客户端程序可以直接方法数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁

三层C/S结构如图

三层C/S体系结构是讲应用功能分成表示层、功能层和数据层三个部分

• 表示层

  表示层是应用的用户接口部分，担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，显示应用输出的数据

• 功能层

  功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。通常，在功能层中包含确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能

• 数据层

  数据层就是数据库管理系统，负责管理对数据库数据的读写

3.4.3 三层C/S结构的优点

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

3.5 浏览器/服务器风格

浏览器/服务器风格就是三层C/S结构的一种实现方式，具体结构为浏览器/Web服务器/数据库服务器

B/S体系结构的不足之处：

• B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能
• B/S体系结构的系统扩展能力差，安全性难以控制
• 采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远低于C/S体系结构
• B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理应用

3.6 公共对象请求代理体系结构

公共对象请求代理(common object request broker architecture, CORBA)是由对象管理组织OMG制定的一个工业标准，其主要目标是提供一种机制，使得对象可以透明地发出请求和获得应答，从而建立起一个异质的分布式应用环境

3.7 正交软件体系结构

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

正交软件体系结构由组织层和线索的构件构成。组织层是一组有相同抽象级别的构件构成。线索是子系统的特定，它是由完成不同层次功能的构件组成，每一条线索完成整个系统中相对独立的一部分功能。简单来讲，就是不同线索中的构件之间没有相互调用，那么这个结构就是完全正交的

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

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

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

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

• 结构清晰，易于理解。正交软件体系结构的形式有利于理解。由于线索功能相互独立，不进行互相调用，结构简单、清晰，构件在结构图中的位置已经说明它所实现的是哪一级抽象，担负的是什么功能
• 易修改，可维护性强。由于线索之间是相互独立的，所以对一个线索的修改不会影响到其他线索。因此，当软件需求发生变化时，可以将新需求分解为独立的子需求，然后以线索和其中的构件为主要对象分别对各个子需求进行处理，这样软件修改就很容易实现。系统功能的增加或减少，只需响应的增删线索构件族，而不影响整个正交体系结构，因此能方便地实现结构调整
• 可移植性强，重用粒度大。因为正交结构可以为一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现体系结构级的重用

3.8 基于层次消息总线的体系结构风格

层次消息总线（hierarchy message bus, HMB）的风格的各个组成要素：构件模型、构件接口

3.8.1 构件模型

HMB风格的构件模型包括接口、静态接口和动态行为三个部分，如图

3.8.2 构件接口

在体系结构设计层次上，构件通过接口定义了同外界的信息传递和承担的系统责任，构建接口代表了构件同环境的全部交互内容，也是唯一的交互途径

3.8.3 消息总线

HMB风格的消息总线是系统的连接件，构件向消息总线等级感兴趣的消息，形成构件消息响应登记表

3.8.4 构件静态结构

3.8.5 构件动态行为

3.8.6 运行时刻的系统演化

HMB风格方便地支持运行时刻的系统演化，主要体现在以下三个方面：

• 动态增加或删除构件
• 动态改变构件响应的消息类型
• 消息过滤

3.9 异构结构风格

3.10 互联系统构成的系统及其体系结构

3.10.1 互联系统构成的系统

互联系统构成的系统(system of interconnected system, SIS)是指系统可以分成若干个不同的部分，每个部分作为单独的系统独立开发。整个系统通过一组互联系统实现，而互联系统之间相互通信，履行系统的职责

3.10.2 基于SASIS的软件过程

软件过程：系统分解，用例建模，分析和设计，实现，测试，演化和维护

• 系统分解

  将上级系统分解成几个从属系统

• 用例建模

  为每个系统在SIS系统中建立一个用例

• 分析和设计

  分析和设计的目的是为了获得一个健壮的系统体系结构

• 实现

  实现过程主要完成构件的开发和测试工作

• 测试

  组装不同从属系统时的集成测试，并测试每个上机用例是否根据其规约通过互联系统协作获得执行

• 演化和维护

  当某从属系统的需求发生变化时，不必开发新版本的上级系统，只需对该从属系统内部结构进行变更，不会影响其他从属系统

3.11 特定领域软件体系结构

3.11.3 DSSA的定义

特定领域软件体系结构(domain specific software architecture, DSSA)的必备特征：

• 一个严格定义的问题域和/或解决域
• 具有普遍性，使其可以用于领域中某个特定应用的开发
• 对整个领域的合适程度的抽象
• 具备该领域固定的、典型的在开发过程中可重用元素

从功能覆盖的范围角度有两种理解DSSA中领域的含义的方式：

• 垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构
• 水平域：定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能，无法为系统提供完整的通用体系结构

3.11.2 DSSA的基本活动

• 领域分析

  这个阶段的主要目标是获得领域模型。领域模型描述系统之间的共同的需求

• 领域设计

  这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计

• 领域实现

  这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到

3.11.4 DSSA的建立过程

DSSA的建立过程分为五个阶段：

• 定义领域范围：本阶段的重点是确定什么在感兴趣的领域中及本过程到何时结束。这个阶段的一个主要输出是领域中的应用需要满足一系列用户的需求
• 定义领域特定的元素：本阶段的目标是编译领域字典和领域术语的同义词词典。在领域工程过程的前一个阶段产生的高层块图将被增加更多的细节，特别是识别领域中应用间的共同性和差异性
• 定义领域特定的设计和实现需求约束：本阶段的目标是描述解决空间中有差别的特定。不仅要识别出约束，并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论
• 定义领域模型和体系结构：本阶段的目标是产生一般的体系结构，并说明构成它们的模块或构件的语法和语义
• 产生、搜集可重用的产品单元：本阶段的目标是为DSSA增加构件，使它可以被用来产生问题域中的新应用

DSSA的建立过程是并发的、递归的和反复进行的。该过程的目的是将用户的需求映射为基于实现限制集合的软件需求，这些需求定义了DSSA

第 4 章 软件体系结构描述

4.1 软件体系结构描述方法

• 图形表达工具
• 模块内连接语言
• 基于软构件的系统描述语言
• 软件体系结构描述语言

4.2 软件体系结构描述框架标准

4.3 体系结构描述语言

ADL是这样的一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架

4.3.1 ADL与其他语言的比较

4.4 典型的软件体系结构描述语言

4.4.1 UniCon

UniCon及其支持工具的主要目的有：

• 提供对大量构件和连接件的统一的访问
• 区分不同类型的构件和连接件以便对结构配置进行检查
• 支持不同的表示方式和不同开发人员的分析工具
• 支持对现有构件的使用

4.4.2 Wright

Wright支持对构件之间交互的形式化和分析。

Wright的主要特点为：对体系结构和抽象行为的精确描述、定义体系结构风格的能力和一组对体系结构描述进行一致性和完整性的插件

4.4.3 C2

4.4.4 Rapide

Rapide是一种可执行的ADL，其目的在于通过定义并模拟基于事件的行为对分布式并发系统建模

Rapide由五种子语言构成：

• 类型语言：定义接口类型和函数类型，支持通过继承已有的接口来构造新的接口类型
• 模式语言：定义具有因果、独立、时序等关系的事件所构成的事件模式
• 可执行语言：包含描述构件行为的控制结构
• 体系结构语言：通过定义同步和通信连接来描述构件之间的事件流
• 约束语言：定义构件行为和体系结构所满足的形式化约束，其中约束为需要的或禁止的偏序集模式

Rapide的优点在于能够提供多种分析工具

4.4.5 SADL

4.4.6 Aesop

Aesop的目的是建立一个工具包，为领域特定的体系结构快速构件软件体系结构设计环境，每个这样的环境都支持一下五个方面：

• 与风格词汇表相应的一系列设计元素类型，即特定风格的构件和连接件
• 检查设计元素的成分，满足风格的配置约束
• 优化设计元素的语义描述
• 一个允许外部工具进行分析和操作体系结构描述的接口
• 多个风格特定的体系结构的可视化，以及操作它们的图形编辑工具

4.4.7 ACME

ACME最初目的是为了创建一门简单的、具有一般性的ADL，该ADL能用来为体系结构设计工具转换形式，和/或为开发新的设计和分析工具提供基础

ACME支持从四个不同的方面对软件体系结构进行描述，分别是结构、属性、约束、类型和风格

• 结构

  在ACME中定义了七种体系结构实体，分别是构件、连接件、系统、端口、角色、表述和表述映射

• 属性
• 设计约束

  设计约束是体系结构描述的关键成分，它们决定体系结构设计使如何演化的。设计约束可以当做一种特殊的属性，但因为在体系结构中，设计约束起着核心作用，所以，ACME提供了特定的语法来描述设计约束

• 类型和风格

4.5 软件体系结构与UML

4.5.1 UML简介

统一建模语言(UML)是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。它记录了对必须构造的系统的决定和理解，可用于对系统的理解、设计、浏览、配置、维护和信息控制

4.5.2 UML的主要内容

• 用例图：用来显示若干角色乙级这些角色与系统提供的用例之间的连接关系
• 类图：用来表示系统中的类和类与类之间的关系，它是对系统静态结构的描述
• 对象图：类图的实例，几乎使用与类图完全相同的标识
• 顺序图：用来反映若干个对象之间的动态协作关系，也就是随着时间的推移，对象之间是如何交互的
• 协作图：描述对象间的协作关系，协作图跟顺序图相似，显示对象间的动态合作关系
• 状态图：描述类的对象所有可能的状态以及事件发生时状态的转移条件
• 活动图：描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动
• 构件图：描述代码构件的物理结构及各构件之间的依赖关系
• 部署图：定义系统中的物理体系结构

第 5 章 动态软件体系结构

5.1 动态软件体系结构概述

体系结构的动态性主要分为三类：

• 交互式动态性
• 结构化动态性
• 体系结构动态性

允许在系统运行时发生更新的软件体系结构称为动态软件体系结构，动态体系结构在系统被创建后可以被动态地更新

5.2 软件体系结构动态模型

5.2.1 基于构件的动态系统结构模型

• 模型简介：基于构件的动态系统结构模型支持运行系统的动态更新，该模型分为三层，分别是应用层、中间层和体系结构层
• 更新请求描述

  一般来说更新描述包括以下几个部分：

  • 更新类型：包括添加、删除和修改一个新的构件
  • 更新对象列表：需要更新对象类的ID号
  • 对象的新版本说明：对象的新版本执行情况
  • 对象更新方法：更替、动态和静态
  • 更新函数：用来更新一个执行对象进程的状态转换函数
  • 更新限制：描述更新和它们之间的关系的序列
• 更新执行步骤
  • 检测更新的范围：在执行更新之前，首先要判断是局部更新还是全局更新，局部更新作用域需要新构件的内部而不影响系统的其他部分。全局更新影响系统的其他部分，全局更新需要发送请求到更高的抽象层
  • 更新准备工作：如果更新发生在应用层，构件配置器等待参与的进程发出信号，以表明他们已处于可安全执行更新的状态；如果更新发生在配置层，就需要等待连接件中断通信，其他构件配置器已完成它们的更新
  • 执行更新：执行更新，并告知更新发起者更新的结果
  • 存储更新：将构件或体系结构所作的更新存储到构件或体系结构描述中

5.3 动态体系结构的描述

5.3.1 动态体系结构描述语言

5.3.2 动态软件体系结构的形式化描述

5.4 动态体系结构特征

• 可构造性动态特征
• 适应性动态特征
• 智能性动态特征

5.3 化学抽象机

• 化学抽象机是一种对动态软件体系结构的分析、测试非常有用的形式化描述技术

软件重用是指在两次或者多次不同的软件开发过程中重复使用相同或相近软件元素的过程。软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识。通常，把这种可重用的元素称为软构件，课重用的软件元素越大，我们就说重用的粒度（granularity）越大。