软件体系结构
大纲
- 绪论
- 软件体系结构风格
- 数据流体系结构风格
- 调用/返回体系结构风格
- 以数据为中心体系结构风格
- 虚拟机体系结构风格
- 事件系统体系结构风格
- 软件体系结构建模和文档化
- 质量属性及质量属性策略
- 可用性及其策略
- 性能及其策略
- 可修改性及其策略
- 安全性及其策略
- 可测试性及其策略
- 易用性及其策略
- 软件体系结构评估
绪论
软件体系结构定义：
软件体系结构 = 组件 + 连接件 + 约束
组件为具有某种功能的可重用的软件模块单元，表示了系统中主要的计算单元和数据存储。
连接件：表示了组件之间的交互。
约束：表示了组件和连接件的拓扑逻辑和约束
软件体系结构风格
软件体系结构风格定义：
描述特定领域中软件系统家族的组织方式的惯用模式，反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效 地组织成一个完整的系统。
数据流体系结构风格
特征：
- 数据的可用性决定着计算单元是否执行
- 系统结构由数据在各处理之间的有序移动决定
- 在纯数据流系统中，处理之间除了数据交换没有任何其他的交互
基本构件：
- 构件接口：输入接口和输出接口
- 计算模型：从输入端口读数，经过计算/处理，然后写到输出端口
连接件：
- 单向，通常是异步，有缓冲
- 接口角色：reader和writer
- 计算模型：把数据从一个处理的输出端口传送到另一个处理的输入端口
典型数据流风格：
- 批处理
- 管道-过滤器
批处理体系结构风格
定义：
- 基本构件：独立的应用程序
- 连接件：某种类型的媒质
- 拓扑结构：连接件定义相应的数据流图
- 每个处理步骤是一个独立的程序
- 每一步必须在前一步结束后才能开始
- 数据必须是完整的，以整体的方式传递
管道-过滤器体系结构风格
构件：过滤器，处理数据流
连接件：管道，连接一个源和一个目的过滤器
过滤器对数据流的五种变换类型：丰富、精炼、转换、融合、分解
无上下文信息，不保留状态，对其他过滤器无任何了解
批处理和管道-过滤器的区别
批处理：
- 整体传递数据
- 构件粒度较大
- 延迟高，实时性差
- 无并发
管道：
- 增量传递数据
- 构件粒度较小
- 实时性好
- 可并发
调用/返回体系结构风格
基本构成：
- 构件：主程序、子程序
- 连接器：调用-返回机制
- 拓扑结构：层次化结构
本质：将大系统分解为若干模块，主程序调用这些模块实现完整的功能。
主程序/子过程风格
对系统进行功能分界，是面向过程编程的主要思路
面向对象风格
系统被看作对象的集合
每个对象都有一个它自己的功能集合。数据及作用在数据上的操作被封装成抽象数据类型（对象）。
基本构成：
- 构件：类和对象
- 连接件：对象之间通过消息和方法调用实现交互
优点：
- 复用和维护：利用封装和聚合提高生产力
- 反映现实世界
- 容易分解一个系统
缺点：
- 管理大量对象：怎样确立大量对象的结构
- 必须知道对象的身份（对比：在管道/过滤器系统中，一个过滤器无需知道其他过滤器的任何信息）
- 继承引起复杂度
分层风格
系统被组织成若干个层次，每个层次由一系列构件组成。
下层构件向上层构件提供服务。
上层构件被看作是下层构件的客户。
分层原则：分离关注、抽象、隐藏。
层次之间存在接口，通过接口形成call/return的关系。
基本构成：
- 构件：各层次内部包含的构件
- 连接件：层间的交互协议
- 拓扑结构：分层
- 拓扑约束：对相邻层间交互的约束
由上而下的交互模式：外部实体与系统中的最高层交互，最高层使用较低级别层的服务。（请求request）
由下而上的交互模式：外部实体与系统中的最底层交互，低层回调高层的服务。（通知notify）
优点：
- 支持基于抽象程度递增的系统设计
- 局部依赖性：功能的改变通常影响相邻的上下层
- 可复用性：某独立层保证功能完整性并提供了文档化的接口，便可在多个语境中复用
- 可替换性：只要服务接口定义不变，同一层的不同实现可以交换使用。
- 对标准化的支持
- 可测试性
缺点：
- 并不是每个系统都可以很容易地划分为分层的模式
- 效率降低：相关数据必须通过一些中间层的若干次转化，才能传到
- 难以抽象
客户机/服务器风格
两层C/S结构：
- 客户程序直接访问数据库，每个客户机都必须安装数据库驱动程序，增加了系统安装和维护工作量。
- 数据库由众多客户程序直接访问，系统数据完整性与安全性难以维护。
- 可扩展性较差，功能修改要求在所有客户机重新部署。
三层C/S结构：
增加了一个应用服务器。
应用功能分为表示层、功能层、数据层三层。
B/S结构是三层C/S结构的特例。
以数据为中心体系结构风格
定义：共享数据源以进行数据传递
仓库体系结构风格
基本构成：
- 构件：中心数据结构，表示当前数据的状态；一组对中心数据进行操作的独立构件。
- 连接件：仓库与独立构件之间的交互。两种交互机制：数据库方式、黑板结构。
黑板体系结构风格
一个大问题被分解为若干个子问题。
每个子问题的解决需要不同的问题表达方式和求解模型，分别设计求解程序。
黑板结构：中心数据结构的当前状态触发并选择需要执行的过程。
基本结构：
- 黑板：输入/解空间求解状态
- 知识源：读取/更新黑板，策略知识/求解知识
- 控制器：监视黑板状态，激活知识源
虚拟机体系结构风格
解释器
解释器是一个用来执行其他程序的程序
解释器通常用来在程序语言定义的计算和有效硬件操作确定的计算之间建立对应和联系。
基本构件：
- An interpretation engine（解释器引擎）
- A Memory that contains：
- 被解释的源代码
- 解释器引擎当前的控制状态的表示
- 程序当前执行状态的表示
连接器：对存储区的数据访问
基于规则的系统
固定部分与可变部分分离
业务逻辑=固定业务逻辑（source code）+可变业务逻辑（rules）+规则引擎
核心思想：将业务逻辑中可能频繁发生变化的代码从源代码中分离出来。
优点：
- 降低了修改业务逻辑的成本
- 缩短了开发时间
- 将规则外部化，可在多个应用之间共享
- 对规则的改变将非常迅速并且具有较低的风险
事件系统体系风格
事件：能够激活对象功能的动作，当发生这种动作后，给涉及的对象发送一个消息，对象可执行相应的功能。
隐式调用：
- 构件不直接调用一个过程
- 不能假定构件的处理顺序
- 各个构件之间相互独立。
事件系统：
- 分离的交互：事件源（发布者）不会意识到事件处理器（订阅者）的存在。
- 一对多通信：一个特定事件可以影响多个事件处理器。
- 基于事件的触发器：由事件触发过程调用。
- 异步：支持异步操作。
事件源：一个构件可以广播一些事件。
事件处理器：构件可以注册自己感兴趣的事件，并将自己的某个过程与相应的事件进行关联。
事件管理器：当一个事件被发布，系统自动调用该事件中注册的所有过程。（协调事件源和事件处理器）
优点：
- 可重用性：当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
- 可修改性：当用一个构件代替另一个构建时，不会影响到其他构件的接口。
缺点：
- 构件放弃了对系统计算的控制：一个构件触发一个事件时，不能确定其他构件的响应。
事件派遣机制设计
无独立调度派遣模块：被观察者/观察者模式
有独立调度派遣模块：事件发送给派遣器，派遣器负责接收事件并转发给其他模块。
软件体系结构描述方法
软件体系结构描述
软件体系结构由一定形式的结构化元素组成，即是构件的集合。包括处理构件、数据构件和连接构件。处理构件负责加工数据，数据构件代表被加工的信息，连接构件则负责组合连接不同的构件。
软件体系结构建模
视图
分解视图、使用视图、分层视图、类/泛化视图、进程视图、并发视图、共享数据视图、客户端-服务器视图、部署视图、实施视图、工作分配视图…
UML
4+1视图：从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。
- 用例视图：从外部世界的角度描述系统功能
- 逻辑视图：描述系统各部分的抽象描述，用于建模系统的组成部分以及各组成部分之间的交互方式
- 过程视图：描述系统中的进程
- 开发视图：描述系统的各部分如何被组织为模块和组件
- 物理视图：描述如何将前三个视图中所述的系统设计实现为一组现实世界的实体。
用例图（Use Case）：用于显示若干角色以及这些角色与系统提供的用例之间的连接关系。
重要的是记住用例代表了系统的外部视图，因此，不要期望用例与系统内部的类之间存在任何关联。
类图、对象图、状态图、协作图、序列图、活动图、包图、组件图、部署图、复合结构、交互概述图、时序图…
质量属性及质量属性策略
属于非功能性需求
质量属性场景的六个组成部分：
- 刺激源（source）：谁造成的刺激
- 刺激（stimulus）：一个影响系统的情况
- 制品（artifact）：系统被影响的部分
- 环境（environment）：刺激发生时系统所处的状态
- 响应（response）：刺激所产生的结果
- 响应衡量指标（response measure）：如何评估响应
可用性
定义：在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。
Availability = MTBF / (MTBF + MTTR)
MTBF：Mean Time Between Failure 平均故障间隔时间
MTBR：Mean Time Between Repari 平均修复时间
当用户使用系统时，系统可用的概率。
可用性场景：
- 刺激源：故障的迹象
- 刺激：系统出错、崩溃、给出结果不准时、给出错误结果
- 制品：计算、存储、网络传输
- 环境：正常状态、亚健康状态
- 响应：记录日志、通知管理员、关闭系统
- 响应衡量指标：故障时间百分比、修复故障所需时间、平均无故障时间
提升可用性的策略：
- 故障检测：Heartbeat心跳、Exceptions catch异常捕获
- 故障恢复：投票、主动冗余（AB完成同样的运算，当A故障时可以快速切换到B）、被动冗余（A完成运算后的一定时间内把自身状态告知B，B再把自身状态更新为A的状态）、内测、检查点/回滚
- 故障避免：服务下线、事务、进程监控
可修改性
关注点：修改的成本、哪些部分被修改、修改发生的事件、修改由谁来进行
可修改性场景：
- 刺激源：谁进行的修改
- 刺激：要进行的具体修改
- 制品：修改系统的功能、UI
- 环境：什么时间进行修改
- 响应：如何修改、测试、部署
- 响应衡量指标：时间、成本
提升可修改性的策略：
- 限制修改范围（模块高内聚低耦合、考虑可能会发生的修改、让模块通用、隐藏信息、维持接口不见、限制通信路径、使用中介、命名服务器、按需创建实例）
- 延迟绑定时间：让软件运行期间仍可灵活修改（配置文件、发布-订阅模式、多态）
性能
关注点：系统响应事件的速度，和事件的数量、到达模式有关
性能场景：
- 刺激源：可能来自系统内部或外部
- 刺激：事件到来
- 制品：系统提供的服务
- 环境：系统所处的状态（正常/紧急/超载）
- 响应：系统处理到来的事件，可能会导致状态的变化
- 响应衡量指标：处理事件所花的时间，单位时间内处理事件的数目，处理的错误率/丢失率
提升性能的策略：
- 资源的需求（提高计算效率、减少要处理的数据总量、限制执行时间、限制待处理事件队列长度）
- 资源的管理（并发、增加可用资源）
- 资源的仲裁（先来先服务、固定优先级制度、动态优先级）
安全性
关注点：在保证合法用户使用系统的前提下，抵抗对系统的攻击
安全性场景：
- 刺激源：攻击可能由人或其他系统发起
- 刺激：对系统的攻击
- 制品：系统所提供的服务或系统中的数据
- 环境：系统可能处于不同的情况下（联网/未联网、在线/下线、在防火墙内/外）
- 响应：合法用户正常使用，拒绝非法用户使用
- 响应衡量指标：发起攻击的难度，从攻击中恢复的难度
提升安全性的策略：
- 抵抗攻击（用户的证实、用户的授权、维持数据保密性、维持数据完整性、减少暴露、限制访问）
- 检测攻击
- 从攻击中恢复
可测试性
关注点：让软件的bug容易被测试出来，验证功能是否匹配需求，用最小的成本验证软件的质量。
可测试性场景：
- 刺激源：测试可能由不同角色发起
- 刺激：系统开发到达了里程碑
- 制品：一个设计、一段代码、整个系统
- 环境：系统可能处于设计阶段/开发阶段/部署阶段/正常运行时
- 响应：可以进行测试，并且可以观察到测试结果
- 响应衡量指标：白盒测试中的覆盖率、未来继续发现bug的概率
提升可测试性的策略：
- 黑盒测试（记录/回放、把接口和实现分离开、提供专用的测试路径）
- 白盒测试（内部监控）
易用性
关注点：让用户使用软件的难度降低
易用性场景：
- 刺激源：终端用户
- 刺激：终端用户希望学习系统的使用、提高系统使用效率、减少出错
- 制品：整个系统
- 环境：系统处于运行时或配置时
- 响应：系统响应用户的要求
- 响应衡量指标：用户完成任务的时间、出错的次数、满意度、操作的成功率
提升易用性的策略：
- 运行时策略：系统猜测用户要完成的任务（搜索联想）、给用户适当的反馈（提示剩余时间、进度）、支持撤销操作
- 设计时策略：将用户界面和系统其他部分隔离开（MVC）
软件体系结构评估
定义：架构评估是软件开发生命周期中一个活动，在此活动中，相关项目干系人使用评估技术，在一个正式或非正式的过程中一起分析软件架构。
SAAM
要求系统的各种风险承担者列举出若干场景
对场景划分优先级
更多地关注功能性和可修改性。
六个步骤：
- 场景开发
- 体系结构描述
- 场景的分类和优先级的确定
- 单个场景评估
- 场景交互评估
- 形成总体评估
ATAM
这种方法不仅可以揭示出软件架构对特定质量目标的满足情况，而且能够更清楚地认识到质量属性之间的联系，即如何权衡诸多质量属性。
ATAM是SAAM的一个细化，特别关注可修改性、性能、可用性和安全性
目标：
- 不是提供精确的分析，是发现由体系结构决策产生的风险
- 希望找到趋势：体系结构决策和系统属性预测之间的相关性
优点：
- 确定风险
- 明确质量属性需求
- 完善体系结构文档
- 体系结构决策的文档化基础
- 加强利益相关者之间的沟通
四个阶段：
- 阶段0：合作与准备
- 阶段1：初步评估
- 评估小组对ATAM进行介绍
- 客户描述系统的功能需求、质量属性需求
- 设计师介绍技术约束条件，用以满足质量属性的体系结构方法设计
- 确定核心体系结构方法
- 通过构建效用树来实别、确定优先级并优化最重要的质量属性目标
- 评估团队从特定质量属性的角度探索体系结构方法以识别风险
- 阶段2：完成评估
- 阶段3：后续工作
风险（Risks），非风险（Non-Risks），敏感点（Sensitivities），权衡点（Tradeoffs）：
- 风险是一个存在潜在问题的体系结构决策
- 非风险是经分析认为安全的良好体系结构决策
- 敏感点是影响一个或多个组件（或组件关系）的特性，对于实现特定质量属性响应至关重要。
- 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
总结：
ATAM是
- 一种根据多个质量属性评估体系结构的方法
- 发现体系结构决策后果的有效策略
- 一种识别趋势的方法，而不是进行精确分析的方法