目录
[7.1 软件架构的概念](#7.1 软件架构的概念)
[7.2 架构发展历程-架构"4+1"视图](#7.2 架构发展历程-架构”4+1”视图)
[7.3 架构描述语言ADL (Architecture Description Language)](#7.3 架构描述语言ADL (Architecture Description Language))
[7.4 基于架构的软件开发方法（ABSD）-概念](#7.4 基于架构的软件开发方法（ABSD）-概念)
[7.5 基于架构的软件开发方法（ABSD）-开发过程](#7.5 基于架构的软件开发方法（ABSD）-开发过程)
[7.6 软件架构演化](#7.6 软件架构演化)
[7.7 软件架构风格](#7.7 软件架构风格)
[7.8 软件架构风格-数据流风格](#7.8 软件架构风格-数据流风格)
[7.9 软件架构风格-调用/返回风格](#7.9 软件架构风格-调用/返回风格)
[7.9.1 分层架构风格](#7.9.1 分层架构风格)
[7.10 软件架构风格-独立构件风格](#7.10 软件架构风格-独立构件风格)
[7.10.1 进程通信](#7.10.1 进程通信)
[7.10.2 事件驱动架构风格（隐式调用）](#7.10.2 事件驱动架构风格（隐式调用）)
[7.11 软件架构风格-虚拟机风格](#7.11 软件架构风格-虚拟机风格)
[7.12 软件架构风格-以数据为中心（仓库风格）](#7.12 软件架构风格-以数据为中心（仓库风格）)
[7.13 软件架构风格-闭环控制架构(过程控制)](#7.13 软件架构风格-闭环控制架构(过程控制))
[7.14 软件架构风格-C2风格](#7.14 软件架构风格-C2风格)
[7.15 软件架构风格-模型驱动架构（MDA）](#7.15 软件架构风格-模型驱动架构（MDA）)
[7.16 特定领域软件架构(DSSA)-基本概念](#7.16 特定领域软件架构(DSSA)-基本概念)
[7.17 特定领域软件架构(DSSA)-建立过程](#7.17 特定领域软件架构(DSSA)-建立过程)
[7.18 特定领域软件架构(DSSA)-三层次模型](#7.18 特定领域软件架构(DSSA)-三层次模型)
[7.19 软件架构评估-质量属性（重点）](#7.19 软件架构评估-质量属性（重点）)
[7.20 软件架构评估](#7.20 软件架构评估)
[7.21 软件架构评估-架构评估方法（重点）](#7.21 软件架构评估-架构评估方法（重点）)
[7.22 软件架构评估-SAAM（Software Architecture Analysis Method）（重点）](#7.22 软件架构评估-SAAM（Software Architecture Analysis Method）（重点）)
[7.23 软件架构评估-ATAM（Architecture Tradeoff Analysis Method)（重点）](#7.23 软件架构评估-ATAM（Architecture Tradeoff Analysis Method)（重点）)
[7.25 软件产品线-基本概念](#7.25 软件产品线-基本概念)
7.1 软件架构的概念
架构的本质
1、软件架构为软件系统提供了一个结构、行为和属性的高级抽象。
2、软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。
架构的作用
1、软件架构是项目干系人进行交流的手段。
2、软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
3、软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
软件架构=软件体系结构
架构设计就是需求分配，即将满足需求的职责分配到组件上。
7.2 架构发展历程-架构"4+1"视图
架构的"4+1"视图
视角与视图
从不同的视角来检查，所以会有不同的视图。
多视图表示从不同的视角描述特定系统的体系结构从而得到多个视图，并将这些视图组织起来以描述整体模型。系统的每一个不同侧面的视图反映了一组系统相关人员所关注的系统的特定方面，多视图体现了关注点分离的思想。
其中，4+1模型是描述软件体系结构的常用模型"4+1"视图模型从逻辑视图、进程视图、物理视图、开发视图和场景来描述软件架构。每个视图只关心系统的一个侧面，结合在一起才能反映系统软件架构的全部内容。在该模型中，"1"指的是统一场景。
|------------------------|----------------------------------------|
| "4+1"视图及其功能表 ||
| 视图 | 功能 |
| 逻辑视图(Logical View) | 描述了设计的对象模型，支持系统的功能需求 |
| 进程视图(Process View) | 描述了设计的并发和同步特征，支持系统的运行特性 |
| 物理视图 (Physical view) | 描述了软件到硬件的映射，反映了分布式特性，支持系统的拓扑、安装和通信需求 |
| 开发视图(Developnent view) | 描述了在开发环境中软件的静态组织结构，支持软件开发的内部需求 |
| 场景(Scenario) | 用来说明重要的系统活动，是其他4个视图在用例(Use Case)驱动下的综合 |
7.3 架构描述语言ADL (Architecture Description Language)
ADL是这样一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。
如：Aesop、MetaH、C2、Rapide、SADL、Unicon等。
++ADL的三个基本元素++
++构件++：计算或数据存储单元。
++连接件++：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则。
++架构配置++：描述体系结构的构件与连接件的连接图。
7.4 基于架构的软件开发方法（ABSD）-概念
ABSD(Architecture-Based Software Design Model)方法是架构驱动，即强调由**++业务【商业】、质量和功能需求++**的组合驱动架构设计。
ABSD是以体系结构为核心的软件开发方法，其中体系结构的设计需求主要来自以下三方面：
1.++系统的质量目标++：质量目标（如性能、可靠性、可扩展性等）是软件系统成功的重要指标。体系结构设计需要确保这些质量属性在开发中被满足。
2.++系统的商业目标++：商业目标决定了系统开发的总体方向和优先级，如降低成本、缩短上市时间、增加市场竞争力等。
3.++系统开发人员的商业目标++：开发人员的目标可能包括技术可行性、开发效率、代码可复用性等，与商业目标和质量目标密切相关。
基于架构的软件开发模型(Architecture-Based Software Design Model,ABSDM)把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等6个子过程。
ABSD方法有三个基础。第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求；第三个基础是软件模板的使用。
视角与视图：从不同的视角来检查，所以会有不同的视图
用例用来捕获功能需求、特定场景【刺激、环境、响应 】用来捕获质量需求
ABSD强调采用视角和视图来描述软件架构。采用用例和质量属性场景来描述需求。进一步来说用例描述的是功能需求，质量属性场景描述的是质量需求(或侧重于非功能需求)。
7.5 基于架构的软件开发方法（ABSD）-开发过程
ABSD能很好的【支持软件重用】
ABSD方法是一个自顶向下，递归细化的方法。
软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。
在ABSD模型中，标识构件过程可分为3步来实现：
++（1）生成类图。++
++（2）对类进行分组。++
++（3）把类打包成构件。++
架构文档化过程的主要输出结果是架构规格说明和测试架构需求的质量设计说明书这两个文档。
文档的完整性和质量是软件架构成功的关键因素。
关于文档的三大注意事项：
文档要从使用者的角度进行编写
必须分发给所有与系统有关的开发人员
且必须保证开发者手上的文档是最新的
架构复审【架构评估】的目的是标识潜在的风险，及早发现架构设计中的缺陷和错误
7.6 软件架构演化
软件架构演化时期：
(1) 设计时演化：发生在体系结构模型与之相关的代码编译之前。
(2) 运行前演化：发生在执行之前、编译之后。
(3) 有限制运行时演化：只发生在某些特定约束满足时。
(4) 运行时演化：发生在运行时不能满足要求时。
软件架构演化方式的分类：
软件架构静态演化
(1) 静态演化需求：设计时演化需求、运行前演化需求。
(2) 静态演化的一般过程：软件理解→需求变更分析→演化计划→系统重构→系统测试。
(3) 静态演化的原子演化操作。
软件架构动态演化
(1) 软件动态性的等级：交互动态性、结构动态性、架构动态性。
(2) 动态演化的内容：++属性改名、行为变化、拓扑结构改变、风格变化++。
(3) 动态演化需求：软件内部执行所导致的体系结构改变、软件系统外部的请求对软件进行的重配置。
++拓扑结构改变通常被认为是软件动态演化中最复杂且影响最大的类型++
软件架构演化原则（18个）：
在软件架构演化过程中，进度可控原则 的度量方案为ttask=lTtask-T|taskl，其中Ttask为实际完成时间，T|task为预期完成时间，时间差ttask越小越好。
在软件架构演化过程中，关于演化成本控制原则 的度量方案，CoE<< CoRD，其中CoE为演化成本，CoRD为重新开发成本
在软件架构演化过程中，主体维持原则 要求软件演化的平均增量增长须保持平稳，以保证软件系统主体行为稳定。该原则的度量方案AIG(对称稳走增长)的计算公式是AIG=主体规模的变更量/主体的规模
在软件架构演化过程中，模块独立演化原则 主要关注的是各模块自身演化相互独立，影响范围可控
在软件架构演化过程中，关于风险可控原则 ，经济、时间、人力、技术和环境等多种风险都需要在可控范围内
7.7 软件架构风格
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
以数据为中心表示仓库风格
|--------------------------------|--------------------------------------|------------------------------------|
| 架构风格 | 子风格 | 应用示例 |
| 数据流风格【Data Flow】 | 批处理【Batch Sequential】 | 传统编译器、网络报文处理 |
| 数据流风格【Data Flow】 | 管道-过滤器【Pipes and Filters】 | |
| 调用/返回风格【Call/Return】 | 主程序/子程序【Main Program and Subroutine】 | |
| 调用/返回风格【Call/Return】 | 面向对象【Object-oriented】 | |
| 调用/返回风格【Call/Return】 | 分层架构【Layered System】 | ++物联网系统、客户端-服务器++ |
| 独立构件风格【Independent Components】 | 进程通信【Communicating Processes】 | |
| 独立构件风格【Independent Components】 | 事件驱动系统（隐式调用）【Event system】 | Windows操作系统在图形用户界面处理方面 |
| 虚拟机风格【Virtual machine】 | 解释器【interpreter】 | 需要"自定义规则"的场合（比如，定义游戏对象的行为和对象之间的关系） |
| 虚拟机风格【Virtual machine】 | 规则系统【Rule-based System】 | 专家系统 |
| 以数据为中心【Data-centered】 仓库风格 | 数据库系统【Database System】 | |
| 以数据为中心【Data-centered】 仓库风格 | 超文本系统【Hypertext System】 | |
| 以数据为中心【Data-centered】 仓库风格 | 黑板系统【Blackboard System】 | 语音识别、模式识别、图像处理、知识推理 |
| 闭环控制架构 | 过程控制 | 空调温控，定速巡航 |
| C2风格 | C2风格 | GUI软件开发、用户界面管理、分布式交互系统、可视化系统等 |
7.8 软件架构风格-数据流风格
在批处理风格软件体系结构中，每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以（++整体++）的方式传递。
7.9 软件架构风格-调用/返回风格
7.9.1 分层架构风格
7.10 软件架构风格-独立构件风格
7.10.1 进程通信
进程通信体系结构风格中，构件是独立的过程，连接件是消息传递。根据系统架构设计师知识体系，其消息传递的方式包括点到点 、异步或同步 方式及远程过程调用等。
7.10.2 事件驱动架构风格（隐式调用）
在事件驱动架构中：
事件队列：负责接收事件的入口。
分发器(Event Mediator)：是将不同的事件分发到不同的业务逻辑单元。
事件通道：负责连接分发器与处理器。
事件处理器：负责实现具体的业务逻辑。
7.11 软件架构风格-虚拟机风格
解释器体系结构分格（2025年案例分析题）
一个解释器的核心组件包括：
①解释引擎：这是解释器的"大脑"，负责读取源代码、分析并执行每条指令。
②被解释的代码存储区：用于存放需要解释执行的源代码。
③记录源代码解释执行进度的数据结构：这通常指的是程序计数器，它跟踪下一条将要被解释执行的指令地址。
④**++解释器引擎的内部状态存储++**：用于维护解释器在执行过程中的运行环境，例如：存储变量名和其对应的值的符号表，用于函数调用、存储局部变量和控制流程的栈，以及用于动态内存分配的堆。这些内部状态共同记录了程序在执行到某一时刻的"快照"，是解释器能够逐步执行并理解程序逻辑的基础。
基于规则的系统构成：++规则集、规则解释器、规则/数据选择及工作内存++，一般用在人工智能领域和DSS(决策支持系统)中。
专家系统的学习机制主要依赖其核心组成部分：++知识库和推理机++。
1)知识库
专家系统的核心，用于存储领域知识，包括事实和规则。
学习机制：通过不断更新和扩展知识库，增强系统的知识储备。
2)推理机
专家系统的推理与决策核心，负责根据知识库中的规则进行推理和问题求解。
学习机制：通过优化推理过程，提高系统的推理效率和正确性。
7.12 软件架构风格-以数据为中心（仓库风格）
在仓库风格中，有两种不同的构件：++中央数据结构说明当前状态++ ++，独立构件在中央数据存储上执行。++
仓库系统体系结构风格是一种通过共享数据的方式进行构件间通信的架构模式。在这种架构中，中央数据结构是共享数据存储的核心，用于记录和反映当前数据的状态，所有的操作
都围绕它进行。
中央数据结构 ：是仓库系统的核心，它**++存储系统中的共享数据，明确反映当前数据状态++**。数据的添加、修改、删除等操作都由系统中的独立构件对中央数据结构进行操作，因此它
准确描述了当前数据的状态。
知识源：在黑板体系结构中，知识源是执行特定功能的独立模块
独立构件 ：这些是系统中**++负责执行操作的组件，但它们通过访问中央数据结构获取和更新数据++**。
7.13 软件架构风格-闭环控制架构(过程控制)
适合于嵌入式系统，用于解决简单闭环控制问题
经典应用：空调温控，定速巡航。
7.14 软件架构风格-C2风格
1995 年加州大学 Irvine 分校的 Richard N. Taylor 等人在提出该架构时，直接借鉴了他们此前开发的 Chiron-1 用户界面系统的设计经验；新风格被视为 Chiron 系列的第二代，于是取名 Chiron-2，缩写即为 C2
C2风格用于GUI软件开发，用以构建灵活和可扩展的应用系统等
C2架构的基本规则：
（1）构件和连接件都有一个顶部和一个底部。
（2）构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。
（3）一个连接件可以和任意数目的其他构件和连接件连接。
（4）当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
7.15 软件架构风格-模型驱动架构（MDA）
Model Driven Architecture
- Model ?
客观事物的抽象表示
-Architecture ?
构成系统的部件、连接件及其约束的规约
-Model-Driven ?
使用模型完成软件的分析、设计、构建、部署、维护等各开发活动
-MDA起源于分离系统规约和平台实现的思想
-MDA的主要目标：
Portability(可移植性)，interoperability(互通性)，Reusability(可重用性)
MDA的3种核心模型：
平台独立模型(PIM)：具有高抽象层次、独立于任何实现技术的模型。
平台相关模型(PSM)：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
代码Code：用源代码对系统的描述(规约)。每个PSM都将被变换成代码。
7.16 特定领域软件架构(DSSA)-基本概念
定义：特定领域软件架构（Domain-Specific Software Architecture ）以一个特定问题领域为对象，形成由**++领域参考模型、参考需求、参考架构++** 等组成的开发基础架构，支持一个特定领域中多个应用的生成。
DSSA的建立过程是并发的、递归的、反复的螺旋模型，强调逐步优化和迭代。
DSSA类型
垂直域：相同领域，深入
水平域：不同领域，平移
DSSA特征
特定领域软件架构(DSSA)的特征包括领域性、普遍性、抽象性和可复用性。
DSSA基本活动及产出物：
DSSA的基本活动包括领域分析、领域设计和领域实现 。其中领域分析的主要目的是获得领域模型 ，领域模型描述领域中系统之间共同的需求，即领域需求；领域设计的主要目标是获得DSSA ，DSSA描述领域模型中表示需求的解决方案；领域实现的主要目标是依据领域模型和DSSA开发和组织可重用信息并对基础软件架构进行实现。
特定领域软件架构(DSSA)-参与人员
参与DSSA的人员
1、领域专家：有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。
领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识。
2、领域分析人员：领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。
3、领域设计人员：领域设计人员应由有经验的软件设计人员来担任。
4、领域实现人员：领域实现人员应由有经验的程序设计人员来担任
7.17 特定领域软件架构(DSSA)-建立过程
7.18 特定领域软件架构(DSSA)-三层次模型
DSSA是在一个特定应用领域中，为一组应用提供组织结构参考的标准软件体系结构。它通常是一个具有3个层次的系统模型，包括领域开发环境、领域特定应用开发环境和应用执行环境 ，其中应用工程师主要在领域特定应用开发环境中工作。
7.19 软件架构评估-质量属性（重点）
基于软件系统的生命周期，可以将质量属性分为**++开发期质量属性++** 和**++运行期质量属性++** 。++开发期质量属性包括可修改性、可测试性等，而运行期质量属性包括性能、可靠性、可用性等++。
1、性能(Performance)
性能(performance)是指系统的响应能力，即要经过多长时间才能对某个事件故出响应，或者在某段时间内系统所能处理的事件的个数。
例如:
（1）同时支持1000并发;
（2）响应时间小于1s;
（3）显示分辨率达到4K。
2、可用性(Availability)
可用性(availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
例如:
(1)主服务器故障，1分钟内切换至备用服务器；
(2)系统故障，1小时内修复;
(3)系统支持7x24小时工作。
3、安全性(security)
安全性(security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性【信息不泄露给未授权的用户】、完整性【防止信息被篡改】、不可否认性【不可抵赖】及可控性【对信息的传播及内容具有控制的能力】等特性。
例如:
(1)可抵御SQL注入攻击;
(2)对计算机的操作都有完整记录;
(3)用户信息数据库授权必须保证99.9%可用
4、可修改性(Modification)
可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
例如:
(1)更改系统报表模块，必须在2人周内完成;
(2)对Web界面风格进行修改，修改必须在4人月内完成;
5、易用性
易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。
例如:
(1)界面友好;
(2)新用户学习使用系统时间不超过2小时。
6、可测试性
软件可测试性是指通过测试揭示软件缺陷的容易程度。
例如:
(1)提供远程调试接口，支持远程调试。
7.20 软件架构评估
敏感点是一个或多个构件(和/或构件之间的关系)的特性，它能影响系统的某个质量属性。
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
风险点是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
非风险点是指不会带来隐患，一般以"XXX要求是可以实现(或接受)的"方式表达。
7.21 软件架构评估-架构评估方法（重点）
基于调查问卷(检查表)的方式
基于度量的方式
基于场景的方式
【场景】是从**++风险承担者++** 的角度与系统交互的简短描述。场景可从六个方面进行描述：++刺激源、刺激、制品、环境、响应、响应度量++
刺激源：某个生成该刺激的实体（人，计算机，其它任何刺激器）；
刺激：指当刺激达到系统时需要考虑的条件；
环境：指该刺激在某些条件哪发生；
制品：某个制品被激励，可能是整个系统，也可能是系统的一部分；
响应：指在激励达到后所采取的行动；
响应度量：当响应发生时，应当能够以某种方式对其进行度量。
基于场景的方法，具体包含下面3种方法，
【软件架构分析法(SAAM)】（Software Architecture Analysis Method）
最初关注可修改性，后扩充到可移植性、可扩充性等。
【架构权衡分析法(ATAM)】（Architecture Tradeoff Analysis Method）
由SAAM发展而来，主要针对:性能、实用性、安全性、可修改性
【成本效益分析法(CBAM)】（Cost-Benefit Analysis Method）
在ATAM基础上建立的，软件的"经济"模型。
CBAM 可以看作是 ATAM的补充，在 ATAM 评估结果的基础上对架构的经济性进行评估。评估过程包括整理场景、对场景进行细化、确定场景的优先级、分配效用等 7 个步骤。
7.22 软件架构评估-SAAM（Software Architecture Analysis Method）（重点）
SAAM：最初用于分析架构可修改性，后扩展到其他质量属性。
SAAM(软件架构分析方法)是卡耐基梅隆大学于1983年提出的，是最早形成文档并广泛应用的软件架构分析方法。
基于场景的架构分析方法，通过场景描述、架构描述和场景交互分析，评估系统架构的质量属性，特别是可修改性，最终进行总体评估和决策。
软件架构分析方法（SAAM）分析过程包括**++场景开发、 架构描述、单个场景评估、场景交互和总体评估++**
7.23 软件架构评估-ATAM（Architecture Tradeoff Analysis Method)（重点）
ATAM：在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性 ，在系统开发之前，对这些质量属性进行评价和折中。
评估参与者:
评估小组：组织内部或外部的、扮演特定的角色
项目决策者：项目管理人员、重要客户代表、架构师
项目干系人：模块开发人员、测试人员、用户
评估活动步骤：
用ATAM方法评估软件体系结构，其工作分为4个基本阶段，即演示、调查和分析、测试、报告ATAM，
1)演示阶段，是使用ATAM评估软件体系结构的初始阶段，包括3个步骤:①介绍ATAM;②介绍业务驱动因素;③介绍要评估的体系结构,
2)调查和分析，对一些关键问题彻底调查，包括3个步骤:①确定架构方法;②生成质量属性效用树; ③分析体系结构方法.
3)测试，包括:①头脑风暴和优先场量:②分析架构方法
4)报告ATAM，提供评估期间收集的所有信息，呈现给利益相关者。
具体的步骤（重点）：
1.描述ATAM方法：评估小组负责人向参加会议的项目干系人介绍ATAM评估方法;
2.描述业务动机：项目决策者从业务的角度介绍系统的况。该描述应该包括系统最重要的功能、技术/管理/经济和政治方面的任何相关限制、与该项目相关的业务目标和上下文、主要的项目千系人，以及架构的驱动因素等;
3.描述架构：包括技术约束(例如:操作系统、硬件和中间件等)、将与本系统进行交互的其他系统、用以满足3质量屈性要求的架构方法等;
4.确定架构方法：通过理解架构方法来分析架构，在这一步，由架构师确定架构方法;
**5.生成质量属性效用树：**评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量目标设置优先级和细化(质量效用树:性能、安全性、可用性、可修改性);
6.分析架构方法：这一步的主要结果是一个架构方法或风格的列表，与之相关的一些问题，以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表;
**7.讨论场景和场景分级：**项目干系人进行两项相关的活动，分别是集体讨论用例场景和改变场景。用例场景是场景的一种，在用例场景中，项目干系人是一个终端用户，使用系统执行的一些功能。一旦收集了若干个场景后，必须设置优先级。评估人员通过投票表决的方式来完成。
8.分析架构方法：在收集并分析了场景之后，设计师可把最高级别的场景映射到所描述的架构中，并对相关的架构如何有助于该场景的实现做解释。在这一步中，评估小组要重复第六步中的工作，把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第7步中，如果未产生任何以前的分析步骤中都没有发现的高优先级场景，则在第8步就是测试步骤。
9.描述评估结果：最后，要把ATAM分析中所得到的各种信息进行归纳，并反馈给项目干系人。ATAM的评估结果包括一个简洁的架构描述、表达清楚的业务目标、用场景集合捕获的质量属性、所确定的敏感点和权衡点的集合、有风险决策和无风险决策、风险主题的集合。
在架构权衡分析方法(ATAM)中，头脑风暴的三种场景类型为：
++用例场景++：表示系统在典型工作负载或使用情况下的行为。
++增长场景++：描述系统随着需求变化或规模扩展的能力。
++探索性场景++：表示非典型或异常使用情况下的表现，强调鲁棒性和边界条件。
7.24 软件架构评估-质量效用树（重点）
质量属性效用树结构为：++根------质量属性------属性求精（细 分类） ------场景（叶）++
7.25 软件产品线-基本概念
软件产品线主要由两部分组成，分别是++核心资源++ 和**++产品集合++**。核心资源是领域工程的所有结果的集合，是产品线中产品构造的基础。核心资源必定包含产品线中所有产品共享的产品线架构，包括新设计开发的或者通过对现有系统再工程得到的、需要在整个产品线中系统化复用的构件，与构件相关的测试计划、测试实例以及所有设计文档，需求说明书、领域模型、领域范围的定义等。
软件产品线-双生命周期模型
软件产品线-建立方式
★ 将现有产品演化为产品线
★ 用软件产品线替代现有产品集
★ 全新软件产品线的演化
★ 全新软件产品线的开发
软件产品线-组织结构
组织结构类型
★设立独立的核心资源小组
★不设立独立的核心资源小组
★动态的组织结构
要成功实施产品线，主要取决于以下因素
★ 对该领域具备长期和深厚的经验
★ 一个用于构建产品的好的核心资源库
★ 好的产品线架构
★ 好的管理(软件资源、人员组织、过程)支持
构件与中间件技术-概念
构件的定义
定义1：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
定义2：构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能。
定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。
构件与中间件技术-概念
构件系统架构特性
（1）构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。（2）构件框架是一种专用的体系结构(通常围绕一些关键的机制)，同时，也是一组固定地作用于构件层次机制的策略。
（3）概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则。
（4）构件是一组通常需要同时部署的原子构件。构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。
原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署，但是它也能够被单独部署。
（5）一个原子构件是一个模块和一组资源。
（6）模块是一组类和可能的非面向对象的结构体，比如过程或者函数。
（7）资源是一个类型化的项的固定集合。
（8）资源这个概念可以包含代码资源，进而包含模块。问题在于除了编译器编译一个模块或包生成的资源外，还可能存在其他的资源。在"纯对象"的方法中，资源是外部化的不可改变的对象--不可改变是因为构件没有持久化的标志，而且复制不能被区分。
中间件
中间件是一类构件
中间件是一类系统软件
简化结构、屏蔽差异、利于复用
中间件是独立的系统级软件，连接操作系统层和应用程序层，将不同操作系统提供应用的接口标准化，协议统一化，屏蔽具体操作的细节，中间件一般提供如下功能：
1、通信支持。中间件为其所支持的应用软件提供平台化的运行环境，该环境屏蔽底层通信之间的接口差异，实现互操作，所以通信支持是中间件一个最基本的功能。
2、应用支持。中间件的目的就是服务上层应用，提供应用层不同服务之间的互操作机制。
3、公共服务。公共服务是对应用软件中共性功能或约束的提取。将这些共性的功能或者约束分类实现，并支持复用，作为公共服务，提供给应用程序使用。
消息中间件支持点对点模式、订阅发布模式、推拉模式
点对点（Queue）
快递柜里只有一个箱子，件放进去，谁先来扫码谁拿走；箱子空了才算结束。
特点：一条消息只被"一个消费者"消费一次，用完即没。
发布/订阅（Topic）
快递员把杂志扔到小区门口书架，所有订阅了这本杂志的住户都能各自拿一份。
特点：一条消息可被"多个订阅者"同时收到，每个订阅者都拿到完整副本。
推/拉（Push vs Pull）
推：快递小哥主动上门把包裹塞你手里------消息中间件收到数据立即写给消费者。
拉：你自己去快递柜输入取件码拿包裹------消费者按需轮询或长轮询去"拉"消息。
推/拉不是"消息模型"，而是"消息到达方式"，可以叠加在点对点或发布/订阅之上。
采用中间件技术的优点
(1)面向需求。即设计师集中精力于业务逻辑本身。
(2)业务的分隔和包容性。应用开发人员可以按照不同的业务进行功能的划分，体现为不同的接口或交互模式。
(3)设计与实现隔离。构件对外发生作用或构件间的交互，都是通过接口进行的，构件使用者只需要知道构件的接口，而不必关心其内部实现，这是设计与实现分离的关键。
(4)隔离复杂的系统资源。架构很重要的一个功能就是将系统资源与应用构件隔离，这是保证构件可复用甚至"即插即用"的基础，与中间件的意图也是一致的。
(5)符合标准的交互模型。中间件则实现了架构的模型，实现了标准的协议。
(6)软件复用。中间件提供了构件封装、交互规则、与环境的隔离等机制，这些都为软件复用提供了方便的解决方案。
(7)提供对应用构件的管理。基于中间件的软件可以方便地进行管理，因为构件总可以通过标识机制进行划分。
构件与中间件技术-软件复用
软件复用【重用】是多次不同的软件开发过程中重复使用相同或相似【软件元素】的过程。
软件元素包括：需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识
复用的历史发展线路
复用的维度
水平复用：不分行业领域，通用
垂直复用：分行业领域，专用
构件与中间件技术-构件标准
构件与中间件技术-CORBA
CORBA = Common Object Request Broker Architecture（公共对象请求代理体系结构）
由 OMG 组织 1991 年发布，目标是在任意硬件、任意操作系统、任意编程语言之间，让对象可以像本地一样调用远程方法------当年真正的"跨语言、跨平台、分布式中间件老祖"。
伺服对象(Servant)：CORBA对象的真正实现，负责完成客户端请求。
对象适配器(Object Adapter)：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
对象请求代理(Object Request Broker)：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。