第 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类产品线体系结构演化的关系如图：

  

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

❤ 点击这里 -> 订阅《PAT | 蓝桥 | LeetCode学习路径 & 刷题经验》by 柳婼

❤ 点击这里 -> 订阅《从放弃C语言到使用C++刷算法的简明教程》by 柳婼

❤ 点击这里 -> 订阅PAT甲级乙级、蓝桥杯、GPLT天梯赛、LeetCode题解离线版