【软件体系结构】软件体系结构笔记

概论

什么是软件架构(Software Architecture)

​ 有关软件整体结构与组件的的抽象描述，用于知道大型软件系统各个方面的设计

软件架构产生的背景

软件架构的主要思想和特征

主要焦点

1. 系统的总体结构
2. 需求和实现的对应

主要思想

1. 运用抽象方法屏蔽错综复杂的模块间连接

特征

1. 注重可重用性：关注组件级重用，提高软件质量
2. 利益相关者多：
3. 关注点分离：将复杂的问题分而治之，降低复杂度
4. 质量驱动
5. 概念完整性
6. 循环风格

软件架构的发展阶段

大致流程

提出阶段

概念体系和核心技术形成阶段

1. 软件组件技术：组件之间状态独立

理论体系丰富发展阶段

1. 架构的描述与表示
2. 软件架构分析、设计、测试
3. 软甲架构发现、演化、重用
4. 基于软件架构的开发方法

理论完善和普及应用阶段

软件架构研究和应用现状

软件架构理论和方法研究

架构的表示

1. 各种ADL
2. 4+1架构模型
3. UML
4. IEEE架构描述规范

软件架构的分析、设计、测试

分析

1. 目的是预测质量属性
2. 内容可分为：结构分析、功能分析、非功能分析
3. 常见方法有：基于场景的架构分析 SAAM,架构折中分析方法 ATAM

分析

测试

1. 着重于仿真系统模型，解决架构层的主要问题
2. 由于测试的抽象层次不同，架构测试策略可分为：单元、子系统、集成、验收等阶段的测试策略

软件架构发现、演化、复用

发现

​ 从已有的系统提取软件的架构，属于逆向工程

演化

​ 由于系统需求、技术、环境、分布等因素的变化而最终导致软件架构的变动

重用

​ 结构重用属于设计重用，是一种比代码重用更抽象的重用

基于软件架构的开发模型

软件架构的风格与模式

产品线架构

软件架构支持工具

1. 静态分析工具
2. 类型检查工具
3. 架构层次依赖分析工具
4. 动态动态特性仿真工具
5. 支持架构性能仿真工具

软件架构的概念

定义

1. 组成派：关注与软件本身，组件和交互的集合

   1. Dawayne Perry 和 Alexander Wolf
      1. 软件架构=元素+组成+原理
      2. 架构元素：具有一定形式的结构化元素，包括处理元素、数据元素和廉洁元素
      3. 架构组成：由加权的属性和关系构成。属性用来约束架构元素的选择，关系用来约束架构元素的放置
      4. 架构原理：捕获在选择架构风格、架构元素和架构形式的选择动机
   2. Mary Shaw 和 David Garlan
      1. 软件架构是软件设计过程的层次之一，该层次超越计过程中的算法设计和数据结构设计
      2. 软件架构包含：组件、连接件、和约束三大要素
      3. 组件：可以是一组代码，也可以是独立的程序
      4. 连接件：可以是过程调用、管道和消息等，用于表示组件之间的相互关系
      5. 约束：一般为组件连接时的条件

2. 决策派：关注与软件架构中的实体，一系列重要设计决策的集合

   1. Booch，Rumbaugh and jacobson 的定义

      1. 软件架构是一系列重要决策的集合，这些决策关于：
      2. 软件系统的组织
      3. 组成系统的结构元素和他们之间的接口，以及当这些元素相互协作时所体现的行为
      4. 如何组合这些元素，使他们逐渐合成为一个更大的子系统
      5. 架构风格
      6. 这些元素以及他们的接口、协作和组合

   2. 等等等等

3. 参考定义框架：组件、连接件、配置、端口、角色五种元素构成

   1. 组件：具有某种功能的可重用的软件模块单元，表示了系统中主要的计算单元和数据存储

      1. 组件主要有两种：复合组件和原子组件

   2. 连接件：表示了组件之间的交互

      1. 简单的连接件有：管道，过程调用，事件广播
      2. 复杂的连接件有：客户-服务器通信协议，数据库和应用之间的SQL连接等

   3. 配置：表示了组件和连接件的拓扑逻辑和约束

   4. 端口：组件作为一个封装的实体，只能通过其接口与外部交互，组件的接口由一组端口组成，每个端口表示了组件和外部环境的交汇点

      1. 通过不同的端口类型，一个组件可以提供多重接口
      2. 端口可以很简单，如过程调用；也可以很复杂，如通信协议

   5. 角色：连接件作为建模软件体系结构的主要实体，同样也有接口，连接件的接口由一组角色组成，连接件的每个角色定义了该连接件表示的交互参与者。

      1. 二元连接件有两个角色

         1. RPC的角色为caller和callee
         2. pipe的角色是reading和writing
         3. 消息传递的角色是sender和receiver

      2. 有的连接件有多于两个角色

         1. 如事件广播有一个事件发布者角色和任意多个事件接受者角色

软件架构的模型

引言

软件架构

1. 软件架构不仅是系统的蓝图，也是开发系统的蓝图
2. 架构建模是对架构设计决策的具象化和文档化

软件架构可视化建模方法

基于图形可视化的建模方法

1. 非正式图形 如盒线图

2. 正式图形：如属性结构、冰块图等

3. 4+1视图

4. 用例视图：从外部世界的角度描述正在建模的系统的功能，通常包含用例图、描述、概述图

5. 逻辑视图：描述系统各部分的抽象描述，建模系统的组成部分以及各部分之间的交互方式，通常包含类图、对象图、状态图、协作图

6. 过程视图：描述系统中的进程：通常包含活动图、顺序图等

7. 开发视图：描述各个部分如何被组织为模块和组件，通常包含包图、组件图

8. 物理视图：将前三个视图中所述的系统设计实现为一组现实世界的实体，通常包含部署图

基于UML的建模方法

1. 用例图：帮助理解系统功能需求的工具
2. 类图：表示类和类与类之间的关系，描述系统的静态结构
3. 对象图：类图某个时间点的一个快照
4. 状态图：状态转移条件，通常是对类图的补充
5. 协作图：是一种交互图，强调的是发送和接收消息的对象之间的组织结构
6. 顺序图：对象交互的一种表达方式，强调交互发生的顺序
7. 活动图：描述活动以及活动间的约束关系，有利于识别并行活动
8. 包图：类似于UML中的文件夹
9. 组件图：描述代码构建的物理结构及构件之间的依赖关系
10. 部署图：描述软件和硬件组件之间的物理关系以及处理节点的组件分布情况 还可以描述配置和部署
11. 交互概览图：活动图和序列图的组合
12. 时序图：描述对象状态变化之间的时序约束

途径

1. 将UML看做是一种软件架构描述语言直接对架构建模
2. 通过扩展机制约束UML的元模型以支持软件架构建模的需要
3. 对UML的元模型进行扩充

特点

1. 优点
   1. 统一标准
   2. 支持多视图结构
   3. 存在相关工具
   4. 统一的交叉引用
2. 缺点
   1. 建模能力不强，缺乏对架构风格和显示连接件的直接支持
   2. 虽然交互图、状态图、活动图描述系统行为，但精确度不足
   3. 使用UML多视图可能会产生信息冗余和不一致
   4. 只能达到非形式化的层次，不能保证开发过程中的可靠性，不能充分表现软件架构的本质

形式化建模方法

Z语言

Petri网

其他语言

基于UML形式化建模方法

1. 类图的形式化
   1. 类的形式化
   2. 关联形式化
   3. 泛化形式化
2. 用例图的形式化
   1. 角色形式化
   2. 用例形式化
   3. 系统形式化
3. 状态图的形式化
   1. 迁移形式化
   2. 状态形式化
4. 顺序图的形式化
   1. 实例形式化
   2. 消息形式化

类的形式化

关联形式化

泛化形式化

迁移形式化

状态形式化

文本语言建模方法

1. 语法高亮显示
2. 文本的静态检查
3. 自动补全
4. 代码折叠

特点

1. 优点
   1. 单个文档中描述整体架构，并且存在众多文本编辑器方便用户与文本文档的交互
   2. 许多工具能够生成程序库来对使用该语言的文本文档进行句法分析和检查
   3. 许多此案及其附带额外的开发支持工具
2. 缺点
   1. 用文本语言建模方法表示类图形结构不易于理解
   2. 文本编辑器通常限于显示满屏的文本，很难以另外的方式组织文本

软件架构的风格与模式

软件架构风格定义

定义

1. 风格：经过长时间的时间，被证明具有良好的工艺可行性、性能与实用性，并且可以直接用来遵循与模仿
2. 软件架构风格：
   1. 描述一类体系结构
   2. 独立于实际问题
   3. 在实践中被多次应用
   4. 是若干设计思想的综合
   5. 具有已经被熟知的特性，并且可以复用

基本属性

1. 设计元素的词汇表 包括组件、连接件的类型以及数据元素，例如：管道、过滤器、对象、服务等
2. 配置规则：决定元素组合的拓扑约束
3. 元素组合的语义解释以及使用某种风格构建的系统的相关分析

优势

1. 极大地促进设计的重用性和代码的重用性，并且使得系统的组织结构易被理解
2. 使用标准的架构风格可较好地支持系统内部的互操作性，以及针对特定风格的分析

软件架构风格的分类

数据流风格

特征

1. 数据的可用性决定这处理是否执行
2. 数据结构有数据在各处理之间有序移动决定
3. 在纯数据流系统中，处理之间除了数据交换没有任何其他的交互

基本组件

1. 基本组件：数据处理单元（Comp）
2. 组件的端口：输入端口（I)和输出端口（O)
3. 组件的计算模型：从输入端口读书，经过计算（处理），然后写到输出端口
4. 连接件：数据流
5. 接口角色：reader和writer

典型实例

管道过滤器

1. 应用场景：数据源不断的产生，系统需要对这些数据进行若干处理
2. 基本组件：过滤器
   1. 每个过滤器组件中都封装了一个处理步骤
   2. 数据源点和数据终点可以看做是特殊的过滤器
3. 连接件：管道 本质上还是数据流
4. 过滤器的作用：将数据源变换成目标数据
5. 过滤器的变化那方式：增加、删减、改变、分解、合并
6. 过滤器的特点：
   1. 过滤器独自完成自身功能，相互之间无状态交互
   2. 过滤器自身无状态
   3. 过滤器对其上下游过滤器无知
7. 管道的特点：
   1. 作用：将一个过滤器的输出断后转移到另一个过滤器的输入口
   2. 过滤器是单向流动的
   3. 过滤器可以有缓冲区
8. 结构的正确性不依赖于各个过滤器的运行先后次序
9. 优点
   1. 每个组件不受其他组件的影响
   2. 组件具有良好的隐蔽性、高内聚低耦合的特点
   3. 管道过滤器支持功能模块的复用
   4. 具有较强的可维护性和可拓展性
   5. 支持一些特定的分析 如吞吐量计算和死锁检测
   6. 具有并发性
10. 缺点
    1. 往往导致系统处理过程成批操作
    2. 某些特定场景，过滤器的具体实现可能过于复杂，系统性能不高 如需要数据加密，每个过滤器都要加密解密
    3. 交互处理能力弱 系统没有一个共享的数据区，当涉及到多个过滤器同时对同一个数据进行操作时，其实现较为复杂
11. 实例
    1. DOS 中more命令
    2. 编译器

批处理

1. 基本组件：独立的应用程序
2. 连接件：某种类型的介质，完整的数据
3. 特点：
   1. 近乎线性
   2. 每个处理步骤后是一个独立的程序
   3. 每一步在前一步结束后才开始
   4. 数据必须是完整的，以整体的方式传播
4. 实例
   1. Eclipse代码重复检测工具

批处理与管道过滤器对比

批处理	管道过滤器
传递整体数据	增量传递
构件粒度较大	构件粒度较小
延迟高，实时性差	实时性好
无并发	可并发

调用返回风格

主程序/子程序风格

1. 基本组件
   1. 组件：主程序和子程序
   2. 连接件：调用返回机制
   3. 拓扑结构：层次化结构
2. 应用场景
   1. 层次化流程
3. 优点
   1. 结构化程序设计的典型风格，相对于非结构化设计逻辑清晰、易于理解
   2. 开发过程采用逐步细化，将大系统分解成若干模块
4. 缺点
   1. 对数据存储格式的变化将会影响到几乎所有模块
   2. 结构化程序在规模变大时会难以理解、难以测试、难以维护
   3. 这种分解方案难以支持有效的复用
5. 实例
   1. key word in contex

面向对象风格

1. parnas:

   1. hide secrets
   2. try to localize future change
   3. use functions to allow for change

2. booch:

   1. object’s behavior is characterized by actions that it suffers and that it requires

3. 应用场景：

   1. It is suitable for applications in which a central issues is identified and protecting related bodies fofinformation especially representation information

4. 系统模型：localized state maintenance

5. 基本组件：

   1. managers eg. servers, objects, abstract data types
   2. 连接件：procedure call
   3. 约束：decentralized, usually single thread

6. 特点

   1. 对象负责维护其表示的完整性
   2. 对象的表示对其他对象而言是隐蔽的

7. 优点:

   1. 隐藏实现细节，可以在不影响其他对象的情况下改变对象的实现，使得对象的使用变得简单、方便，而且具有很高的安全性和可靠性
   2. 设计者可以将一些数据存取操作的问题分解成一些交互的代理程序的集合

8. 缺点

   1. managing many objects: vast sea of objects requires additional structuring
   2. managing many interactions:
      1. single interface can be limiting and unwieldy
      2. some language permit multiple interfaces
   3. Distributed responsibility for behavior
      1. makes system hard to understand
      2. interaction diagrams now used to design
   4. Capturing families of related design
      1. Types are often not enough
      2. design patterns as an emerging off-shoot

层次结构风格

1. 基本思想：系统被组织成若干层次，每个层次有一系列组件组成，层次之间通过调用返回交流，下层组件向上层组件提供服务，上层组件被看做下层组件客户端

2. 应用场景

   1. It is suitable for applications that involve distinct classes of services that can be arranged hierarchically

3. 基本组件

   1. 系统模型：hierarchy of opaque layers
   2. 组件： usually composites, composites are most often collections of procedures
   3. 连接件：depends on structures of components, often procedure calls under restricted visibility
   4. 约束：single thread

4. 特点

   1. 分层架构中每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层
   2. 大问题分解成小问题，逐步解决，隐藏了很多复杂度
   3. 修改一层最多影响两层，通常只影响上层。 接口稳固
   4. 上层无需知道下层的身份，不能调整层次之间的顺序

5. 优点

   1. 支持局域可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列实现
   2. 支持扩展。每一层的改变最多只影响相邻层
   3. 支持重用。只要给相邻层提供相同的接口，他允许系统中同一层的不同实现相互交换使用

6. 缺点

   1. 不是所有系统都能用这种模式构建
   2. 定义一个合适的抽象层次非常困难 ISO框架
   3. 层层相调，影响性能

风格变种

客户机/服务器风格

1. 基本概念
   1. 客户机和服务器是两个相互独立的逻辑系统，为了完成特定的任务而形成一种协作关系
   2. 客户机（前端）：业务逻辑、与服务器通讯的接口
   3. 服务区（后端）：与客户机通信的接口、业务逻辑、数据管理
2. 两层CS架构
   1. 优点
      1. 客户机组件和服务器组件分别运行在不同计算机上，有利于分布式数据的组织和处理
      2. 组件之间的位置是相互透明的
      3. 客户机程序和服务器程序可运行在不同操作系统上，便于实现异构环境和多种不同开发技术的配合
      4. 软件环境和硬件环境的配置具有极大的灵活性，易于系统功能的扩展
      5. 将大规模的业务逻辑分不到多个通过网络连接的低成本的计算机上，降低了系统的整体开销
   2. 缺点
      1. 开发成本高，对客户机要求高
      2. 客户机程序设计复杂度大，客户机负荷重
      3. 信息内容和形式单一
      4. 架构升级需要开发人员到现场更新客户机程序，对运行环境进行重新配置，增加了维护费用
      5. 两层架构采用了单一的服务器，同时以局域网为中心，难以扩展到互联网
      6. 数据安全性不高，客户端程序可以直接访问数据库服务器
3. 三层CS架构
   1. 优点
      1. 合理地划分三层结构的功能，可以使用系统的逻辑结构更加清晰，提高软件的可维护性和可扩充性
      2. 在实现三层CS架构时，可以有效地选择运行平台和硬件环境，从而使每一层都具有清晰的逻辑结构、良好的负荷处理能力和较好的开放性
      3. 在CS架构中，可以分别选择合适的编程语言进行过开发
      4. 系统具有较高的安全性
   2. 缺点
      1. 通信效率会影响到系统的整体性能，所以要慎重考虑三层之间的通信方法、通信频率、传输数据量

浏览器/服务器风格

1. 优点
   1. 客户端只需要安装浏览器，操作简单，能够发布动态信息和静态信息
   2. 运用HTTP标准协议和统一客户端软件，能够实现跨平台通信
   3. 开发成本较低，只需要维护Web服务器程序和中心数据库。客户端升级可以通过升级浏览器来实现
2. 缺点
   1. 个性化程度低，所有客户端程序的功能都是一样的
   2. 客户端数据处理能力比较差，加重了web服务器的工作负担，影响系统的整体性能
   3. 在BS架构中，数据提交一般以页面为单位，动态交互不强，不利于在线事物处理
   4. 扩展性比较差，系统安全性难以保障
   5. BS架构的应用查询中心数据库，其速度要远低于CS架构

数据中心风格

1. 组件：
   1. 中心数据结构组件，表示当前数据的状态
   2. 相对独立的组件集合 即各个功能模块
2. 连接件
   1. 数据库性知识库：输入流中的事物触发系统相应的进程执行
   2. 黑板知识库：中心数据结构的当前状态触发系统相应的进程执行

仓库风格

1. 基本思想

   1. 仓库是存储和维护数据的中心场所

2. 组成

   1. 组件：

      1. 中心数据结构组件，表示当前数据的状态
      2. 相对独立的组件集合，各个功能模块

   2. 连接件

      1. 数据仓库与独立组件之间的交互

3. 应用场景

   1. 核心问题是建立、扩充和维护一个复杂的中央信息体的情况

4. 典型应用

   1. 数据处理：主要需要用传统的数据库来搭建业务决策系统
   2. 软件开发环境, 主要需要表示和操作相关的程序和设计。

5. 应用实例

   1. 现代编译器

6. 优点

   1. 便于模块间的数据共享
   2. 方便模块的添加更新删除
   3. 避免了知识源的不必要的重复存储等

7. 缺点

   1. 需要一定的同步机制保证数据结构的完整性一致性等

黑板风格

1. 应用场景

   1. 没有直接的算法
   2. 没有唯一的解答
   3. 需要多个领域的专门知识解决

2. 特点

   1. 一个大问题被分解为若干个子问题
   2. 不同的子问题有不同的问题表达方式和求解模型
   3. 每个求解程序具有某一特定领域的知识，可解决某一方面的问题
   4. 这些程序是相互独立的，之间不存在相互调用，也不存在可事先确定的操作顺序
   5. 根据问题求解过程中的状态来动态决定各个专门程序之间的操作顺序，他们之间通过协同工作共同完成整个问题的求解
   6. 专门的控制程序负责根据问题求解的状态来调用最恰当的求解程序，从而形成一种随机性的执行次序

3. 组成部分

   1. 黑板
      1. 全局数据库，用于存储数据、传递信息、包含解域的全部状态
      2. 解决问题过程中的状态数据以层次形式组织起来
      3. 知识源对黑板进行修改，逐渐找到问题的解
      4. 各知识源的交互和通信通过黑板
   2. 知识源
      1. 知识源是描述某个独立领域问题的知识及其处理方法的知识库
      2. 知识源分别存放且相互独立
      3. 他们通过黑板进行通信，合作求出问题的解
      4. 通常知识源具有"条件-动作"的形式，当条件满足时，知识源被触发，其动作部分增加或修改黑板上的内容
   3. 控制器
      1. 时刻监视黑板状态的变化

4. 优点

   1. 便于多用户共享数据
   2. 便于扩展
   3. 知识源可重用
   4. 容错性、健壮性

5. 缺点

   1. 不同的知识源要对共享数据达成一致，对数据结构的修改较为困难
   2. 需要同步机制，保证结构的完整性和一致性

虚拟机风格

解释器风格

1. 基本思想：将高抽象层次的程序翻译为低抽象层次所能理解的指令
2. 优点
   1. 有利于实现程序的可移植性和语言的跨平台能力
   2. 可以对未来的硬件进行模拟和仿真，能够降低测试所带来的的复杂性的昂贵花费
3. 缺点：
   1. 额外的间接层次导致了系统性能的下降
4. 解释器的三种策略
   1. 传统解释器：纯粹的解释执行 ASP，JS，MATLAB
   2. 基于字节码的解释器：先编译，再解释执行 java perl php python
   3. JIT：编译得到字节码，字节码解释执行或直接编译成目标码 .NET JIT

基于规则的系统风格

1. 问题背景
   1. 业务需求经常发生过变化，因此代码效率低，成本高。最好的办法是把频繁变化的业务逻辑抽取出来，形成独立的组件库
   2. 这些规则可独立于软件系统而存在，可以随时被更新
   3. 系统运行时，读取规则库，根据当前运行状态，从规则库中选择与之匹配的规则，对规则进行解释，根据结果控制系统的运行流程
2. 核心思想：将业务逻辑中可能频繁发生变化的代码从源代码中分离出来
3. 基本过程
   1. 使用规则定义语言，将这些变化部分定义为规则
   2. 在程序运行时，规则引擎根据程序执行的当前状态，判断需要调用并执行那些规则，进而通过“解释器‘的方式来解释执行这些规则
   3. 其他直接写在源代码中的程序，仍然可以通过传统的“编译”或“解释”的办法加以执行
4. 应用实例
   1. 专家系统
   2. 业务规则引擎
5. 优点
   1. 降低了修改业务逻辑的成本
   2. 缩短了开发时间
   3. 将规则外部化，可在多个应用之间共享
   4. 对规则的改变将非常迅速，且具有较低的风险
6. 与解释器风格的对比
   1. 相同点
      1. 都是通过“解释器”（规则引擎）在两个不同的抽象层次之间建立起一种虚拟环境
   2. 不同点
      1. 基于规则的系统是在自然语言/XMl和高级语言的程序代码之间建立虚拟机环境
      2. 解释器风格是在高级语言程序源代码和OS/硬件平台之间建立虚拟机环境

事件驱动风格

1. 基本思想：

   1. 组件不直接调用一个过程，而是发布或广播一个或多个事件
   2. 系统中的其他组件通过注册与一个事件关联起来的过程，来表示对某一个事件感兴趣。当这个事件发生时，系统本身会调用所有注册了这个事件的过程。这样一个事件的激发会导致其他模块中过程的隐式调用
   3. 

2. 特点

   1. 没有特定的处理顺序，甚至不知道那些过程会被调用
   2. 各构件之间没有直接的联系关系，各自独立存在，通过对时间的发布和注册实现关联

3. 调度策略

   1. 

   2. 分派模块的功能：负责接受到来的时间，并派遣他们到其他的模块

   3. 分类

      1. 广播式：发送给所有人
      2. 选择广播式：只发送给那些已经注册过的订阅者
         1. 点对点选择广播式：配置一个消息队列，消息队列存储消息，消费者消费后删除事件
         2. 发布-订阅的选择广播式：事件可以被多个订阅者消费，事件发送给订阅者后不会直接删除，而是有其他的删除机制

   4. 编程的一般步骤

      1. 确定响应事件的元素
      2. 为指定元素确定需要响应的事件类型
      3. 为该元素的响应事件编写事件处理程序
      4. 将事件处理程序绑定到指定元素的指定事件

   5. 应用实例

      1. Field系统
      2. Win32 GUI程序

   6. 优点

      1. 事件声明者不需要知道哪些组件会影响时间，组件之间关联较弱。一个组件出错不会影响到其他构建
      2. 提高软件复用能力。只要在系统事件中注册组件的过程，就可以将该组件集成到系统中
      3. 系统便于升级。只要组件名和时间中所注册的过程名保持不变，原有组件就可以被新组建替代

   7. 缺点

      1. 组件放弃了对计算的控制权，完全由系统决定
      2. 存在数据交换问题
      3. 存在正确性验证问题

其他软件架构风格

C2风格

1. C2架构风格是一种常见的层次体系架构风格

2. 主要可以概括为：
   3. 通过连接件绑定在一起的按照一组规则运作的并行组件网络
   4. 所有组件之间的交互必须通过异步消息机制来实现

3. 模式结构图：

4. 组织规则：

   1. 组件之间不能直接连接
   2. 组件和连接件都有一个顶部和一个底部
   3. 组件的顶部应连接到某个连接件的底部，而某个连接件的底部应连接到某个组件的顶部
   4. 一个连接件可以和任意数目的其他组件和连接件连接
   5. 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部

5. 优点

   1. 可以用任何变成语言开发组件，组件的重用和替换易实现
   2. 组件之间相对独立，依赖较小，因此具有一定的可拓展能力，支持不同粒度的组件
   3. 组件不需要共享得知空间
   4. 可以实现多个用户和多个系统之间的交互
   5. 可以使用多个工具集和多种媒体类型，动态更新系统框架结构

6. 缺点

   1. 不大适合大规模流失风格系统，以及对数据库使用比较频繁

平台/插件风格

1. 插件：遵循统一的预定义接口规约编写出来的程序，应用程序在运行时通过接口规约对插件进行调用，以扩展应用程序的功能

2. 特点：允许第三方软件开发者通过开发插件对软件的功能进行扩展，而无需对整个程序代码进行重新编译

3. 插件收到的约束

   1. 可以动态拔插，不影响系统运行
   2. 系统插入插件后，功能得到扩展和升级
   3. 多个插件之间、插件和平台之间不会发生冲突

4. 实现

   1. 定义平台扩展接口：完全由平台实现，插件只是调用和使用
   2. 定义插件接口：完全由插件实现，平台只是调用和使用

5. 结构模式图：

6. 优点

   1. 减低各个模块之间的互依赖性
   2. 系统模块独立开发、部署、维护
   3. 根据需求动态的组装、分离系统

7. 缺点

   1. 插件是别人开发的可以用到某主程序中的，只服务于该主程序，可重用性差

8. 应用实例

   1. Eclipse平台

面向Agent风格

1. 基本思想：不仅仅用对象的思维思考问题，而是用Agent智能体的思维去考虑问题
2. 构成
   1. Agent：一个能够根据它对其环境的感知，主动采取决策和行为的软件实体
   2. Agent组件：对系统处理的高度抽象，具有高度令狐和高度只能的软件实体
   3. Agent连接件：对复合型组件的连接，该连接可以提供通信、协调、转换、接通等服务
3. 优点
   1. 利于解决复杂问题，特别是对于分布式开放异构的软件环境
4. 缺点
   1. 大多数结构中的Agent自身缺乏社会性结构描述和与环境的交互
5. 应用实例
   1. LASP物流管理系统

面向方面软件架构风格

1. 面向方面的编程（AOP）：
   1. 在传统的软件架构基础上增加了方面组件这一新的构成单元，通过方面组件来封装系统的横切关注点
   2. 系统的有些特性和需求是横切与系统的每一个层面中，并融于系统的每一个组件中，这种特性为系统方面需求特性或关注点
   3. 特点
      1. 尽量分离技术问题和业务问题
      2. 允许开发者能够对横切关注点进行模块化设计
      3. 能够实现分散关注，将通用需求功能从不相关类之中分离出来
      4. 能够实现代码重用
   4. 优点
      1. 可以跨模块地调用
      2. 层次化功能性而非嵌入化功能性，从而使代码具有更好的可读性和维护性
      3. 能更好的与面向对象的编程很好的合作
   5. 应用实例
      1. 日志功能

面向服务架构风格

1. 程序由不同的功能通过定义好的接口联系起来

   1. 服务是一个粗粒度的可发现的软件实体
   2. 接口是采用中立的方式进行定义的，应用独立于实现服务的硬件平台、操作系统和编程语言，便于不同系统中的服务以一种统一的通用的方式进行交互

2. 架构模式图：

   1. 服务请求这：可以是服务或者第三方用户，通过查询服务提供者提供的接口描述，再通过接口描述通过RPC或SOAP进行绑定服务提供者所提供的业务或服务
   2. 服务提供者：服务的创建者或管理者，必须将服务描述的接口发布到服务注册中心才能被潜在的服务请求发现。
   3. 相当于服务接口的管理中心，服务请求者通过其查询服务注册中心的数据库来找到需要的服务调用方式和接口描述信息
   4. 发布：服务提供者将对服务接口的描述信息发布到服务注册中心上
   5. 发现：通过查询服务注册中心的数据库来找到需要的服务服务注册中心能够对服务进行分类，以便能够更快定义服务范围
   6. 绑定和调用：服务请求者在查询到所需要的服务描述信息，根据这些信息服务请求者能够调用服务

3. 特点

   1. 基于标准
   2. 松散耦合
   3. 共享服务
   4. 粗粒度
   5. 易于集成到现有系统
   6. 具有标准化结构
   7. 提升开发效率
   8. 降低维护复杂度

4. 优点

   1. 灵活性：根据需求变化，重新编排法务
   2. 对IT资产的复用
   3. 使企业的信息化建设真正以业务为核心。业务人员根据需求编排服务，而不必考虑技术细节

5. 缺点

   1. 服务划分困难
   2. 接口标准有问题
   3. 对IT硬件资产难以服用
   4. 主流接口实现方式很多，难以统一
   5. 只局限于不带界面服务的共享

微服务架构

1. 将单个应用陈故乡开发为一组小型服务的方法，每个小型服务都在自己的进程中运行，并使用轻量级通常是HTTP资源API进行通信
2. 特点
   1. 围绕业务能力组织系统
   2. 自动化部署
   3. 智能化
   4. 对程序和数据的去中心化控制
   5. 松耦合
   6. 架构设计复杂
3. 优点
   1. 每个服务都是独立部署维护的，每次更新不会对整体业务有影响
   2. 在部署或扩容的时候只需要对瓶颈部分进行扩容，这样可以更细粒度地节省资源
4. 缺点
   1. 分布式系统天生的复杂性：网络延迟、容错性、不可靠的网络、异步机制
   2. 运维成本增加，一个服务被拆分成了多个服务
   3. 隐式接口及接口匹配问题，不同组件间协作需要统一可管理的接口
   4. 代码重复：为了尽量实现松耦合，相同功能的底层功能会在不同服务内多次实现
   5. 异步机制：微服务往往使用异步编程、消息、与并行机制会引入新的故障点
   6. 其他的像不可变基础设施、管理难度、微服务架构的推进等

正交架构风格

1. 由组织层、线索、和组件构成
   1. 层：具有相同抽象级别的组件构成
   2. 线索是子系统的特立，他是有完成不同功能层次功能的组件组成的，每一条线索完成整个系统中相对独立的一部分功能鞥
   3. 线索之间是相互独立的，即没有相互调用，则这个结构是正交的
2. 特点：
   1. 有完成不同功能的线索组成
   2. 系统柜具有多个不同抽象层
   3. 线索之间是独立的
   4. 系统有一个公共驱动层 一般为最高层和一个公共数据结构 一般为最低层
3. 优点
   1. 结构清晰，易于理解
   2. 易修改，可维护性强
   3. 可移植性强，重用力度大
4. 缺点
   1. 实际过程中，难以完全正交化或正交化成本太大

异构风格

1. 多种架构相互融合，形成更复杂的架构，称为异构架构
2. 异构方式
   1. 使用层次结构
   2. 允许单一组件使用复合连接件
3. 优点
   1. 选择异构架构风格可以实现对遗留代码的重用
   2. 在某一单位中，规定了共享软件包的某些标准，但仍会存在解释和表示习惯上的不同，选择异构架构风格，可以解决这一问题
4. 缺点
   1. 不同风格之间的兼容问题优势难以解决
5. 应用实例

   1. 

   2. 

   3. 

基于层次消息总线的架构风格

1. 背景

   1. 网络和分布式构件技术日趋成熟，具有分布和并发特点的软件系统成为普遍需求
   2. 基于实践驱动的编程模式在图形界面程序设计中得到广泛应用
   3. 硬件总线体系结构具有良好的扩展性和适应性

2. 基本思想：

   1. 基于层次消息总线，支持组件的分布和并发，组件之间通过消息总线进行通讯
   2. 消息总线是系统的连接件，负责消息的分派、传递和过滤以及处理结果的返回
   3. 各组件挂接在消息总线上，向总线登记感兴趣的消息类型
   4. 不要求各个构建的物理分布，可较好的描述分布式并发系统

3. 体系结构图：

4. 优点

   1. 降低耦合性，增强重用性
   2. 可以动态增加和删除构件

5. 缺点

   1. 重用要求高，可重用性差

模型-视图-控制器风格

1. 主要包含三个部分：模型、视图、控制器

   1. 模型：应用程序的核心，封装了问题的核心数据、逻辑关系和计算功能，提供了处理问题的操作过程
   2. 视图：模型的表示，提供了交互界面，为用户显示模型信息
   3. 控制器：负责处理用户与系统之间的交互，为用户提供操作接口

2. 架构模式图：

3. 优点

   1. 多个视图与一个模型相对应，变化-传播机制确保相关视图都能够及时获取模型变化信息，从而使所有视图和控制器同步，便于维护
   2. 具有良好的一致性，由于模型独立于视图，因此可以方便的实现不同部分的移植
   3. 系统被分割成三个独立的部分，当功能发生变化时，改变其中的一个部分就能满足要求

4. 缺点

   1. 增加了系统设计和运行复杂性
   2. 视图与控制器连接过于紧密，妨碍了二者的独立重用
   3. 视图访问模型的效率比较低，由于模型具有不同的操作接口，因此视图需要多次访问模型才能够获得足够的数据
   4. 频繁访问伪变化的数据，也将降低系统的性能

ADL （Archetecture description language）

引言

1. 定义：用于描述软件架构的语言
2. 与其他语言的区别
   1. 与需求语言的区别：前者更关注解空间，而需求更关注与问题空间
   2. 与建模语言相比：更关注在组件的描述上
3. 核心元素
   1. 组件
   2. 连接件
   3. 软件架构配置
   4. 约束元素

软件架构与敏捷开发

软件开发的发展简史

1. 松散的软件开发
2. 基于软件工程思想的开发
3. 敏捷开发
4. 智能化软件开发

敏捷开发的基本理念

1. 强调个体和交互比强调过程和工具好
2. 强调获得可运行的软件比详尽的文档好
3. 强调与客户合作比强调进行详谈的合同好
4. 强调相应变化比强调遵循既定的计划好

敏捷开发与架构设计的关系

1. 软件开发与敏捷开发的出发点是一致的：
   1. 软件结构与敏捷开发都是一个权衡的过程
   2. 软件架构与敏捷开发的目的都是为了提高软件开发效率、提高软件质量、降低软件成本，将开发团队的价值最大化
2. 敏捷开发也要重视软件架构
3. 敏捷开发改变了软件架构的设计方式
   1. 敏捷开发将传统的架构设计分成了：种子架构设计+详细架构设计
   2. 种子架构设计关注软件系统的骨架或轮廓的设计
   3. 敏捷开发的详细架构设计转移到Code编码阶段、重构阶段、单元测试阶段
   4. 分离后，敏捷软件种子架构的内容包括：软件的架构成粉刺，重要模块、重要类的说明

敏捷开发中的架构设计

1. 重视架构设计，但是不做详细设计
2. 架构设计=种子架构+详细架构
3. 原则
   1. 关键决策必须提前决定
   2. 利益相关者须在一起
   3. 需求文档化
   4. 时常验证
   5. 若需要修改，越早越好
   6. 不要突发奇想的修改架构，需要一起讨论
4. 需求分析
   1. 先分析主干再分析枝干
5. 团队设计
   1. 群体决策：避免理论完美但无法实现的架构设计，这样设计出来的架构为原始架构
6. 简单设计
   1. 表达方式简单化
   2. 现实抽象简单化

初始阶段设计

软件架构设计与实现

目标

1. 模块化
2. 适应需求
3. 对运行有良好规划
4. 对数据有良好规划
5. 对部署有良好规划

面向架构的需求工程

1. 确定问题空间范围
2. 确定系统用户及他们的职责
3. 从用户角度探索整体外部行为
4. 确定组件和连接件
5. 规约组件和连接件
6. 建立面向架构的需求规约
7. 检查其规约

基于体系结构的软件设计

基础

1. 功能分解
2. 选择体系结构风格来实现质量和业务需求
3. 软件模板的使用 利用一些软件系统的结构

步骤

功能分解

1. 将设计元素的功能分组，使其能够代表独立的元素 分解可以进一步细化
2. 标准：
   1. 功能聚合
   2. 数据或计算行为的类似模式
   3. 类似的抽象级别
   4. 功能的局部性，公共功能区分出来
   5. 选择体系结构风格
   6. 为风格分配功能
   7. 细化模板
   8. 功能校验
   9. 创建并发视图创建配置视图
   10. 验证质量场景
   11. 验证约束

软件架构到详细设计

基于模型驱动软件架构（MDA）

分类

1. 计算无关模型（computation independent model)
2. 平台无关模型 (platform independent models)
3. 平台特定模型 (platform specific models)

关键原则

1. 关注点分离
2. 单一职责原则
3. 最少知识原则（迪米特法则）
4. 不重复自身原则
5. 尽量减小前期设计

主要威胁及其对策

1. 被忽略的非功能需求：全面认识需求
2. 频繁变化的需求及其对策：关键需求决定架构
3. 考虑不全面的架构设计：多视图探寻架构
4. 不及时的架构验证及其对策：今早验证架构
5. 较高创造性的架构比重及其对策：合理分配经验架构和创新架构的比重
6. 架构的低可执行性：验证架构的可执行性

软件架构设计和实现

目的 良好的软件应具有以下品质

1. 良好的模块化
2. 适应功能需求的变化，适应技术的变化
3. 对系统的动态运行有良好的规划
4. 对数据的良好规划
5. 明确、灵活的部署规划

基于软件体系结构的软件设计方法（ABSD）

1. 基础

   1. 功能分解：在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术
   2. 通过选择体系结构风格来实现质量和业务需求
   3. 软件模板的使用：利用一些软件系统的结构

2. 软件模板

   1. 软件模板是一个特殊类型的软件元素，包括所有这种类型的元素在共享服务和底层构造的基础上如何进行交互
   2. 软件模板还包括属于这种类型的所有元素的功能例如：重大时间、运行期间的外部诊断的测试点等

3. 目的

   1. 组织最早的设计策略，不包括形成实际的软件构件和类。但要做出有关功能划分和达到不同质量属性机制的决策

4. ABSD方法是一个递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构建和类

5. ABSD方法与生命周期

   1. 抽象功能需求：包括变化的需求和通用的需求
   2. 用例：功能需求具体化，在体系结构设计阶段，重要的用例才有用
   3. 抽象的质量和商业需求：质量需求尽量具体化
   4. 质量因素：实际质量和商业需求。采用质量场景可以对质量需求进行特定扩充，使质量因素具体化
   5. 体系结构选项：对于每个质量和业务需求，都要例举出能满足该需求的所有可能的体系结构
   6. 约束：前置的设计决策。 如必须考虑遗产系统的某些特征

6. 方法步骤

   1. 功能分解：一个设计元素有一组功能，这些功能必须分组。分解的目的是使每个组在体系结构内代表独立的元素。
   2. 选择体系结构风格
   3. 为风格分配功能
   4. 细化模板：被分解的设计元素有属于他的模板。在模板细化了后，就要把功能增加上去。
   5. 功能校验：验证设计元素是否能够通过一定的结构达到目的
   6. 创建并发视图
   7. 创建配置视图
   8. 验证质量场景
   9. 验证约束：验证所有的约束是否有互相矛盾的地方，是否都能实现等。

7. 引入的好处

   1. 用传统方法产生需求规约，不考虑软件架构概念和原则，则在软件架构设计阶段建立需求规约与架构的映射相对困难
   2. 若把架构概念引入需求分析阶段，有助于保证需求规约、系统设计之间的可追踪性和一致性，有效保持软件质量将软件架构概念和原则引入需求分析，也可以让我们获得更有结构型的可重用的需求规约

需求与架构的协同演化

1. 软件需求和软件架构两者是相辅相成的关系，一方面软件需求影响软件架构设计，另一方面软件架构帮助需求分析的明确和细化
2. 需求与架构的互相影响可以看成一个螺旋过程，也是一个双峰过程：在发展需求和架构规约的同事，继续从解决方案的结构和规约总分离问题的机构和规约。在一个反复的过程中，产生更详细的需求规约和设计规约，最终吧交织在软件开发过程中的设计规约和需求规约分离开来

详细设计对软件架构的影响

1. 详细设计主要集中在架构表达式的细化，选择详细的数据结构和算法
2. 但经常出现以下问题：
   1. 确实重要架构视图，片面强调功能需求
   2. 不够深入，架构设计方案过于笼统，基本还停留在概念性架构层面，没有提供明确的技术蓝图
   3. 名不副实的分层架构，确实层次之间的交互接口和交互机制，只进行职责划分
   4. 在某些方面过度设计
3. 解决方法：
   1. 对于确实重要架构视图难问题，可以针对遗漏的架构视图进行设计
   2. 对于不够深入问题，需要将设计决策细化到和技术相关的层面
   3. 对于名不副实的分层架构问题，需要步步深入，明确各层之间的交互接口和交互机制
   4. 虽然我们必须考虑到系统的扩展性和可维护性等，但切忌过度设计

基于模型驱动的软件架构（Model Driven Architecture MDA）

1. 大致分类
   1. 计算无关模型
   2. 平台无关模型
   3. 平台特定模型
2. 开发步骤
   1. 用计算不管模型（CIM）捕获需求
   2. 创建平台无关模型（PIM）
   3. 将PIM转化成为一个或多个平台特定模型（PSM），并加入平台特定的规则和代码
   4. 将PSM转化为代码
3. 根本思想
   1. 将软件系统分成模型和实现两个部分
   2. 模型是对系统的概述，实现是利用特定技术在特定平台或环境中对模型的解释
   3. 模型仅仅负责对系统的描述，与实现技术无关。这是模型的实现技术无关性
4. 好处
   1. 将模型与实现分离后，能够很好的适应技术易变性。由于实现往往高度依赖特定技术和特定平台，当技术发生迁移时，只需要针对技术做相应的实现，编写相应的运行平台或变换工具。所以，能够较好地应对实现技术发展带来的挑战
5. 架构设计原则
   1. 一般原则：商业原则、数据原则等
   2. 关键设计原则：关注点分离、单一职责原则、最少只是原则等

软件体系结构评估

概述

1. 评估原因：
   1. 软件架构的好坏关系到软件产品的好坏
   2. 评估能够了解架构的重要属性，能够屏蔽风险 目前没有较好的自动化评估系统
2. 质量属性
   1. 可修改性：
   2. 可用性：度量正常运行的时间比例
   3. 性能：度量响应速度 及相关因素，如并发性等
   4. 可测试性
   5. 易用性
   6. 安全性
3. 评估时机
   1. 前期：发现型评估，找出难以实现的需求
   2. 后期：评估老系统，明确是否可以通过更改老系统来满足需求
4. 必要性
   1. 减少后期测试和纠错的开销
   2. 挖掘隐形需求，并将其补充到设计的最后机会
   3. 体系结构是开发的中心，不良的体系结构会极大影响产品质量
5. 评估方式
   1. 基于问卷调查
   2. 基于场景
   3. 基于度量

评估方式

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

1. 优点
   1. 灵活，自由，可以在多个阶段和多个属性上评估
2. 缺点
   1. 比较主观：经验和领域都会影响评估结果
3. 实际应用
   1. 作为一个评估的补充

基于场景的评估方式

1. 主要方法
   1. 体系结构权衡分析法（ATAM）
   2. 软件体系结构分析方法（SAAM）

特点

1. 优点
   1. 考虑到所有人
2. 缺点
   1. 评估方式基于特定领域，不可移植
   2. 所有人都要有一个全局的理解

ATAM方法

1. 目标
   1. 理解SA关于质量属性需求的决策结果
   2. 理解这些决策对生命周期后续开发中的影响
2. 特点
   1. 各个质量之间的权衡
3. 基本概念
   1. 敏感点：一个或多个构件的特征 如提高加密级别可以提高系统的安全性
   2. 权衡点：多个质量属性的敏感点 提高加密会提高安全性，提高加密级别降低性能
   3. 风险承担者
      • 开发人员。。。。。。
   4. 场景：评估过程中采用的机制
      1. 刺激：风险承担者如何与系统交互
      2. 环境：描述刺激发生的情况
      3. 相应：体系结构对刺激做出的反应
      4. 示意图：

基于度量的评估方式

​ 为某一属性赋予数值，如代码行、调用层数、构件个数等

评估方式的对比

ATAM

ATAM的步骤 必考

1. 陈述
   1. ATAM方法的陈述
   2. 商业动机陈述
   3. 软件架构陈述
2. 调查与分析
   1. 确定架构方法
   2. 生成质量效用树
   3. 以效用树为基础，对架构分析
3. 测试
   1. 确定优先级
   2. 再分析架构 优先级可能变化
4. 报告
   1. 表述结果

ATAM步骤解析

1. ATAM方法陈述： 评估负责人向参加会议的相关人员介绍ATAM方法。在这一步，要对每个人解释参与的过程，使每个人都知道要收集哪些信息，如何描述信息，将向谁报告等等。

2. 业务动机陈述：从业务角度，向相关人员介绍系统概况 如商业环境、历史等，商业约束条件、技术约束条件、质量属性需求、术语表等

3. 体系结构陈述：架构师或设计小组详略得当地描述体系结构。这些体系结构信息直接影响可能的分析及分析的质量。在进行更实质的分析之前，评估小组通常需要询问更多的有关体系结构的信息，包括：

   1. 驱动体系结构的需求 如性能、可修改性等
   2. 高层体系结构视图
      1. 功能：关键的系统抽象、领域元素及其相关依赖、数据流等
      2. 模块/层/子系统：描述系统功能组成的子系统、层、模块， 以及对象、过程、函数及他们之间的关系
      3. 进程/线程：进程、线程及其同步，数据流和与之相联的时间
      4. 硬件：CPU、存储器、外设、传感器，以及连接这些硬件的网络和通信设备
   3. 所采用的的体系结构方法或风格 包括他们强调的质量属性和如何实现的描述
   4. CTOS （Commercial off the shelf）的使用，以及如何选择和集成
   5. 介绍1-3个最重要的用例场景 如可能，应包括对每个场景运行资源的介绍
   6. 介绍1-3个最重要的变更场景 如果可能应描述通过变更构建、连接点或接口所带来的的影响
   7. 与满足驱动体系结构需求相关的体系结构问题或风险
   8. 术语表

4. 确定体系结构方法：体系结构方法定义了系统的重要结构，描述了系统演化、对更改的响应、对攻击的防范以及与其他系统的集成等

5. 生成质量属性效用树：评估小组与项目决策者合作，共同确定出该系统的最重要的质量属性目标，并设置优先级，进行进一步的细化，该步指导其他的分析

6. 分析体系结构方法：针对划分了优先级的质量需求（第5步）和采用的体系结构方法（第4步），评估它们的匹配情况

   1. 吧效用树中的每个高优先级的质量属性需求与实现他们的体系结构方法关联起来
   2. 为每一个效用树生成的高级场景确定构件、连接件、配置、约束
   3. 体系结构设计师通过问一系列方法特定和质量属性特定的问题来实现每个体系结构方法
   4. 产生一个体系结构方法或风格的风险列表 包括风险决策、无风险决策、敏感点、权衡点
   5. 

7. 集体讨论并确定场景优先级：这一步是从相关人员的角度讨论场景，其中需讨论的场景包括：

   1. 用例场景：描述风险承担者期望使用系统的方式
   2. 成长场景：体系结构在中短期的改变，包括功能和非功能的修改
   3. 考察场景：描述系统成长的极端情形 如性能中数量级的改变，任务的重大变更等确定优先级场景收集

   具体步骤

   1. 相关人员对场景投票确定优先级
   2. 比较场景讨论结果和质量效用树，比较相同点和不同点 存在不同点，则需要调整或解释
   3. 将场景讨论结果放到质量效用树当中，即系统体系结构设计与系统需求一致

8. 再分析体系结构：在经过第7步之后，引导出最高优先级的场景，对相关的体系结构决策如何有助于该场景的实现做出解释 对于新增场景分析，不变场景进行检查，方法同第6步

9. 陈述结果：将分析结果归纳总结，并呈现给相关人员

   1. 主要内容：各个步骤和得到的各种信息
   2. 主要结果：
      1. 文档化的体系结构方法
      2. 若干场景及优先级
      3. 基于质量属性的若干问题
      4. 效用树
      5. 风险决策、无风险决策、敏感点、权衡点

SAAM （Software Architecture Analysis Method）

1. 主要分析体系结构的可修改性；也可以对系统属性及系统功能进行分析
2. 评估方法：描述场景、划分优先级、分析体系结构问题
3. 评估步骤
   1. 场景的形成：集体讨论形成场景
   2. 体系结构的表述：描述系统静态特征和动态特征，场景的形成和体系结构的表述相互促进反复迭代
   3. 场景的分类和优先级的确定
   4. 对场景的单个评估
   5. 场景相互作用评估
   6. 形成总评估
4. 优点
   1. SAAM考察的是SA的单独的质量属性
   2. 而ATAM提供从多个竞争的质量属性方面来理解SA，使用户能认识到在多个质量属性目标间权衡的必要性

软件架构的相关课题

软件架构的演化和维护

1. 对象变化
   1. 接口、类型、语义等等的变化，但不包括对象之间的交互过过程 只包含addObject和deleteObject
2. 消息演化
   1. 对象之间的交互发生改变
   2. 消息自身的属性，如接口、类型等等发生变化
3. 复合片段演化
   1. 复合片段本身的信息包括：类型、成立条件、内部之星序列 内部执行序列的演化等价于消息序列的演化
   2. 会产生分支的符合片段包括：ref、loop、 break、阿勒泰、opt、par
   3. 主要分为：add fragment、delete fragment、type change
4. 约束演化
   1. 对应着架构配置的演化，一般源于系统属性的改变，更多情况下约束会伴随着消息的改变而发生改变
   2. 即对约束信息的添加、删除

软件架构演化方式的分类

1. 静态演化需求
   1. 设计时演化需求：开发过程和实现过程中对原有架构进行调整
   2. 运行前演化需求：软件发布之后由于系统运行环境的变化，需要对软件进行修改升级
   3. 一般演化过程：
      1. 软件理解
      2. 需求变更分析
      3. 演化计划
      4. 系统重构
      5. 系统测试
2. 动态演化需求
   1. 软件内部执行所导致的体系结构的改变 如服务器端软件会在客户请求到达时创建新的组件来响应用户的请求
   2. 是软件系统外部的请求对软件进行重配置 操作系统在升级时无需重新启动，在运行过程中就可以完成对软件体系结构的修改
   3. 动态演化的内容
      1. 属性改名
      2. 行为变化 如添加加密算法
      3. 拓扑结构的改变 增减连接件和组件
      4. 风格变化

软件架构的腐蚀

在软件架构变化存在一下两种情况：向更好的方向变化，和向更坏的方向演化。即当软件系统经过一系列的演化之后，软件架构原来能保持的一些软件架构属性就会变差甚至不再保持；这就是我们所常说的软件架构腐蚀现象。

预防控制的方法

1. 腐蚀最小化
2. 腐蚀预防
3. 腐蚀修补

软件技术债

现实中可能的情况

1. 编译器升级，但是没有跟进使用
2. 没有完全依照要求开发，将在下个开发周期完成
3. 没有时间重构代码，下个周期再重构

技术栈的定义

1. 开发人员为了加速开发或由于自身经验的缺乏，有意无意在采用最佳方案是进行了妥协，使用了短期内可以加速软件开发的方案，从而在未来给自己带来额外的开发负担
2. 只要软件持续变化，总的技术债就会一直增加。知道技术债达到无法偿还的底部，使得不得不放弃软件产品，这种情况成为技术破产

技术栈的分类

1. 代码债：开发过程没有遵守代码规范导致的债务
2. 设计债：未采用最优解决方案导致的债务，来源包括臭味和违背设计规则的行为
3. 测试债：测试环节产生的债务，一般由于测试的缺乏、覆盖不充分、不恰当的测试导致
4. 文档债：由于技术文档问题产生的债务，包括缺少重要技术文档、较差的文档、未及时修改更新的文档

产生技术债的一些根本原因

1. 进度压力
2. 设计师缺乏足够的经验和技巧
3. 不注重设计原则的应用
4. 缺乏对设计坏味和重构的意识
5. 开发中有意代用非最优的选择

偿还技术债

1. 发现项目中包含的技术债
2. 将技术债加入到产品列表当中
3. 根据债务的影响和偿还成本进行优先级排序
4. 在核实的开发周期中对不同技术债进行偿还+

软件坏味道

1. 坏味道可能存在于程序的代码中，也可能存在于软件设计中，还可能存在于系统的模型、文档和数据中
2. 代码坏味道：程序中有一段代码不稳定或存在潜在问题，例如：
   1. 过长方法
   2. 过多参数
   3. 过长标识符等等
3. 架构坏味道：与代码坏味道类似，只是架构坏味道在系统粒度下出现的层次要高于代码坏味道，如
   1. 连接件极度
   2. 过度分散的功能
   3. 模糊接口等等

架构脆弱性

1. 定义：通常情况下，我们认为软件脆弱性是导致破坏系统安全策略的系统同安全规范、系统设计、实现和内部控制等方面弱点
2. 特点：
   1. 脆弱性是软件系统中隐藏的一个弱点，本身不会引起危害，但被利用后会产生严重的安全后果
   2. 在软件开发过程中，自觉或比自觉引入的逻辑错误是大多是脆弱性的根本来源
   3. 与具体的系统环境密切相关，系统环境的任何差异都有可能导致不同的脆弱性问题
   4. 旧的脆弱性得到修补或纠正的同时可能会引入新的脆弱性
3. 成因
   1. 软件开发过程中的错误，也可能是系统配置过程中的错误。