软件体系结构知识点总结除设计模式

第1章 软件体系结构的相关概念

---

软件体系结构

• 软件体系 = 构件 + 连接件 + 约束
• 构件：是某种功能的可复用的结构单元
• 连接件：是构件之间建立和维护行为关联与信息传递的途径，连接需要两方面的支持：连接发生和维持的机制和规则。
  • 方向性
  • 角色
  • 继发性
  • 响应特性

软件架构结构

• 模块结构：系统如何被构造为一组代码或数据单元的决策。
  • 常见模块结构举例：
  • 分解结构：大模块分为小模块更易于理解。
  • 使用结构：
  • 分层结构
  • 类泛化结构
• 构件和连接件结构：系统如何被设计为一组具有运行时行为(构件)和交互(连接件)的元素。
  • 常见举例：
  • 服务结构：
  • 客户机/服务器结构
  • 共享数据或存储结构
  • 并发结构
• 分配结构：展示如何将来自于模块结构或者构件-连接件的单元映射到非软件结构
  • 常见举例：
  • 部署结构：
  • 实现结构：
  • 工作分配结构：

软件体系结构风格

• 概念：一种体系结构风格定义了构件类型和连接件类型的词汇表，以及它们如何组合的约束条件。
• 分类：下面风格案例介绍

---

第2章 软件质量属性

---

什么是软件质量属性

• 软件质量属性指的是一个系统的可度量、可测试的属性，这些属性会影响到系统的运行时行为、系统设计方式以及用户的体验等。质量属性的优劣程度反映了设计是否成功以及软件系统的整体质量。

质量属性需求说明

• 刺激源：某个生成该刺激的实体
• 刺激：当到达时引起系统进行响应的条件
• 环境：刺激到达时，系统所处的状态
• 制品：被刺激的部分
• 响应：系统再刺激到达后采取的行动或措施
• 响应度量：响应发生时，我们以某种方式对其进行度量，便于我们对需求进行测试

软件质量属性具体介绍

• 功能正确性：软件系统能按照功能需求正确执行
• 设计时质量属性
  • 概念完整性：架构设计一致性。
  • 可维护性：指系统可以承受一定程度修改能力
  • 可重用性：组件和子系统在其他应用程序或场景中进行重用的能力。
• 运行时质量属性
  • 可用性 Availablity：系统正常运转并发挥功能的能力
    • 平均故障时间 MTBF :指相邻两次故障之间的平均工作时间。衡量可靠性。
    • 平均修复时间 MTTR:是描述产品由故障状态转为工作状态时修理时间的平均值。
    • 公式：

  Availability = \frac {MTBF} {MTBF + MTTR}
  
  MTBF = \frac {总正常运行时间}   {故障次数}
  
  MTTR = \frac {总宕机时间} {故障次数}
  
  Availability = \frac {累计正常工作时间}  {总工作时间}
  

  • 可靠性：
    • 狭义可靠性：软件无失效运行的定量度量，常代表为软件在规定的运行环境中和规定的时间内无失效运行的概率。
    • 广义可靠性：指一切旨在避免、减少、处理、度量软件故障的分析、设计、测试方法、技术和实践活动。

  e^{-(\frac {t}{\theta})}
  
  \theta 可以是 MTBF 或者 MTTR
  

  • 可管理性：指查看和修改指定系统或软件状态的能力，描述了系统管理员应用程序的难易程度。
  • 互操作性：描述两个或多个软件构件协作的能力，即不同来源的构件能相互协调、通信，共同完成更复杂的功能的能力。
  • 性能：系统的响应速度
  • 可伸缩性:衡量软件系统适应系统规模增长的能力，目标是在负载增加的情况下维护系统可用性、可靠性、性能。
  • 安全性：在软件生命周期中，系统向合法用户提供服务的同时，阻止非授权使用和防止信息泄露和丢失的能力
• 系统质量属性
  • 可支持性：系统在不正常工作下，提供信息以确定和解决问题的能力。
  • 可测试性：通过测试解释软件缺陷的能力
• 用户质量属性
  • 易用性： 分为：易理解性、易学习性、易操作性。
• 其他质量属性
  • 可变性
  • 可执行性
  • 开发时可分布性
  • 可部署性
  • 多语言适用性

---

第3章软件体系结构风格案例

---

概述

• 面向一类给定环境的架构设计决策的集合，这些形成特定模式，为一组系统提供粗粒度的抽象框架
• 每个都包含构件和连接件

数据流风格

• 原理：系统在数据到达时即被激活，无数据不工作。数据的可用性决定着处理是否执行，数据在各处理之间有序移动，纯数据风格只有数据交换，没有其他交互。
• 图解
• 构件：处理
• 连接件：数据流
• 管道流-过滤器风格
  • 简介:包括过滤器(构件)和管道(连接件)
  • 特点：
    • 无上下文信息
    • 不保留状态
    • 对其他过滤器无任何了解
    • 可使用数据缓冲区临时保存数据流
• 批处理风格
  • 简介：是管道流过滤器的一种特例，即输入输出限制为单一，每一步顺序执行，必须前一步执行完后者才可进行。
  • 特点

过程调用风格

• 原理：都没讲 - -！！
• 图
• 主程序/子程序风格
  • 简介：将大系统分为若干块模块，主程序调用这些模块实现完整的系统功能
    • 构件：主程序和子程序
    • 连接件：调用-返回机制
  • 特点
    • 优点：层次性鲜明，具有逻辑性。
    • 缺点：程序过大时，由于子程序过多，导致开发效率下降，测试困难。
• 数据抽象和面向兑现风格
  • 简介：系统被看作对象的集合；每个对象都有他一个功能集合
    • 构件：类和对象
    • 连接件：对象之间通过功能与函数调用实现交互
  • 特点
    • 优点：面向对象：封装继承多态抽象
    • 缺点：大量对象的管理麻烦，对象身份必须明确，继承导致混乱。
• 层次风格
  • 简介
  • 特点

独立构件风格

• 原理
• 进程通信风格
  • 简介：
    • 构件：独立的进程
    • 连接件：消息传递，实现进程之间的同步和共享资源的互斥操作
  • 特点
• 基于事件的隐式风格
  • 简介：构件不直接调用一个过程，而是触发或广播事件，系统自动调用在这个事件中其他的所有过程。
  • 特点
    • 不区分调用次序，不清楚谁调用谁。无直接联系，相互独立，不确定处理顺序。
    • 支持交互式系统
    • 为软件复用提供强大支持
    • 位系统动态演化带来了方便
    • 对时间的并发处理将提高系统性能
    • 健壮性：一个构件出错不影响其他构件
    • 以下缺点：分布式控制让系统同步验证调试困难
    • 构建放弃了对系统计算的控制
    • 触发事件的语义存在问题
    • 先验后验无法验证
    • 数据交换存在问题
    • 中间层的消耗降低事件响应速度

层次风格

• 原理：系统被分为若干个层次，每个层次由一系列构件组成。层次之间存在接口，通过接口调用返回形成关系。
• 分类：
  • 严格分层严格分层系统要求严格遵循分层原则，限制一层中的构件只能与对等实体以及与它紧邻的下面一层进行交互，第N 层只能与第 N-1 和N+1层中的构件进行交互，第N-1 层只能与第 N和N-2 层进行交互，依次类推
  • 影响范围小，修改简单，同时效率低下
  • 松散分层：允许构件与位于它下面的任意层中的组件进行交互（注意:交互的方向依旧未变）
  • 提高效率，影响范围大，不宜于修改。
• 逻辑分层：表现层 业务层 数据层
• 物理分层：两层部署 三层部署
• 特点：
  • 抽象
  • 隔离
  • 可扩展性
  • 可管理性
  • 性能
  • 可重用性
  • 可测试性
  • 标准化
  • 缺点：运行效率不高
  • 缺点：架构时困难复杂：无法确定正确的分层抽象

虚拟机风格

• 原理：

  • 虚拟机：一种软件，创建了虚拟的环境，将用户与底层平台隔离开来
  • 解释器：将高抽象层次的程序翻译为低抽象层次所能理解的指令，以消除在程序语言与硬件之间存在的语义差异。
  • 基于规则的系统：将业务逻辑中可能频繁发生变化的代码从源代码中分离出来；

• 特点

  • 可以实现非本机平台功能
  • 有助于软件的可移植性
  • 软件具有很强的灵活性
  • 有助于优化系统结构
  • 便于学习和使用
  • 缺点：
  • 额外的层次导致性能下降
  • 额外的软件层的正确性需要验证
  • 无法最大限度的发挥系统和硬件的性能

客户机/服务器风格

• 原理结构：将服务器和客户端划分任务和工作负载，其中资源或服务的提供者时服务器，而服务的请求者是客户。
  • 构件：客户机 服务器
  • 连接件：网络协议提供网络连接和服务
• 特点
• 分类：
  • 胖瘦客户端
    • 胖客户端：客户端执行大部分的数据处理操作
      • 较低的服务器需求
      • 离线工作
      • 更好的多媒体性能
      • 更灵活
      • 充分利用已有设备资源
      • 更高的服务器容量
    • 瘦客户端：客户端具有很少或没有业务逻辑
      • 单点故障 ，服务器承担大部分业务逻辑，易维护，不安全可靠
      • 廉价的客户端硬件
      • 有限的显示性能
  • 传统C/S风格
    • 基本构件：
      • 数据库服务器：存放数据的数据库、负责数据处理的业务逻辑
      • 客户机应用程序：GUI：用户界面；业务逻辑：利用客户机上的应用程序对数据进行处理；
    • 连接件：经由网络的调用返回机制或事件机制
    • 特点：伸缩性差 互操作性差 系统管理与配置成本高
  • 多层C/S风格：瘦客户端
    • 三层：分为客户端，服务端，数据库端。
      • 优点：灵活性高，性能好，
  • B/S风格：特殊的三层架构，瘦客户端，胖服务器
    • 大部分业务逻辑在服务器端运行，维护成本低
    • 客户端使用浏览器，0维护，操作方便
    • 客户端无法直接访问客户端，增加了安全性。
    • 服务统一管理，具有容错能力和负载平衡能力
    • 缺点：执行效率低，受协议限制，性能差，数据交互能力弱
  • CS BS 区别
    • 网络环境差异
    • 数据存储模式差异
    • 安全要求差异
    • 系统维护差异
    • 处理问题差异
    • 服务相应及时性差异

表示分离风格

• 简介：用户的显示和系统关键功能分开解耦。
• MVC风格：
  • 莫：模型市地图 控制了
• MVP风格：
• 特点：
  • 模型从UI组件种分离出来，同样的数据可以用到不同的视图
  • 底层模型数据改变会影响到试图玩减仓
  • 灵活性
  • UI更改

SOA风格

• 原理结构：面向服务的架构
• 特点
  • 松散耦合
  • 粗粒度服务
  • 标准化接口
  • 与敏捷过程结合

---

第4章 软件体系结构描述与建模

---

常用描述方法

• 框线图描述
• 形式化描述
• UML描述

4+1 视图(概念层次)

• 逻辑视图
  • 分类：类图、对象图、包图、组合结构图、状态机图
• 开发视图
  • 分类：组件图
• 进程视图
  • 分类：时序图、通信图、活动图、计时图、交互概述图
• 部署视图
• 用例视图

---

第5章 软件体系结构设计和评估

---

概述

架构为中心的软件开发过程

• 软件体系生命周期模型
  • 捕获架构需求 -> 设计架构 -> 编档架构 -> 分析架构 -> 实现架构 -> 维护架构
  • 迭代循环过程： 分析架构 - > 设计架构 维护架构 -> 捕获架构需求
• 核心活动
  • 架构需求：用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。一般可以根据系统的质量目标，商业目标来获取
• 架构中心方法常见过程模型融合
  • SAAM：软件架构分析法
  • ATAM：软件架构权衡分析法

属性驱动的设计方法

• 英文简称ADD，是定义软件架构的一种方法，可根据软件质量属性需求实施架构设计的过程。
• 中间设计流程
  • 确认有充足的需求信息
  • 选择系统一个元素进行分解
  • 识别候选架构驱动
  • 选择一个满足架构驱动的设计构想
  • 实例化架构元素并分配职责
  • 定义实例化元素的接口
  • 验证并完善需求
• 输入是 功能需求 设计约束 质量属性需求
• 输出是软件架构设计

基于模式的设计方法

注：关注设计步骤

• 设计步骤
  1. 选择一个需要细化设计的构件
  2. 为该构件定义需求
  3. 针对上一步中定义的需求和交互，找出最合适的架构风格或模式
     • 更细致的小步骤——在设计中如何选择一种模式：
     • 制定问题
     • 选择模式类别
     • 选择问题类别
     • 比较问题描述
     • 比较优点与不足
     • 选择最佳模式变种 如不成功，寻找其他问题类别继续迭代。
  4. 使用与问题相匹配的模式来指导类和构件的设计
  5. 在构件中进行迭代，为每个构建重复2-4步

模块设计与评估方法

注： 关注5个原则

• 模块化设计步骤
  • 选定问题
  • 使用设计方法将该问题分解为多个构件
  • 描述各个构件的交互机制
  • 重复上述步骤，知道满足终止标准为止
• 模块化质量评价标准
  • 可分解行
  • 可组合型
  • 可理解性
  • 连续性
  • 可保护性
• 模块化设计规则
  • 直接映射
  • 少的接口
  • 小的接口
  • 显式接口
  • 信息隐藏
• 类设计原则
  • 单一职责
  • 开闭
  • 里氏替换：所有引用基类的地方必须能够透明的使用其子类对象
  • 依赖倒置：高层模块不能依赖于底层模块，两者都应该依赖于抽象。细节依赖于抽象
  • 接口隔离
• 包聚合设计原则
  • 重用/发布等价原则：重用的粒度就是发布的粒度
  • 共同重用原则：一个包内的所有类都是共同复用的
  • 共同封闭：包中所有的类对同一个性质的变化应该都是共同封闭的。
• 包耦合设计原则
  • 无圈依赖原则
  • 稳定依赖原则
  • 稳定抽象原则

软件体系结构评估 (结合项目记忆一个)

• 概念
• 分类：
  • 基于场景的评估方法
  • 基于度量-预测评估方法
  • 基于特定软件体系结构描述语言的评估方法
  • 选的3

SAAM 2选1

ATAM

• 步骤：
  • 介绍 ： 通过介绍进行信息交流，包括ATAM方法介绍，商业动机介绍，软件体系结构介绍 ------包括以上三个步骤
  • 调查分析：包括确定软件体系结构、生成质量属性效用树、分析软件体系结构方法 ------三个步骤
  • 测试：包括集体讨论并确定场景的优先级，分析软件体系结构方法 ---------两个步骤
  • 形成报告

---

附加 对于一个项目的完整思考

---

质量属性 及 设计策略

• 安全性
  • 检测攻击：入侵检测、检测拒绝服务、验证消息完整性、检测消息延迟
  • 抵御攻击：识别参与者、验证参与者、授权参与者、限制访问、限制暴露、加密数据、分离实体
  • 攻击反应：撤销访问权限、锁定计算机、通知参与者
  • 从攻击中恢复：恢复服务、维护记录轨迹、参照可用性策略
  • 结合项目：1.当有人通过域名强制访问管理平台的时候，先检测到此入侵，然后需要用户提供相关账户密码等信息，如果验证失败则撤销该用户的访问权限。
• 可测试性
  • 控制和观察系统状态：专用接口、记录回访、本地化存储、抽象数据源、沙盒、可执行的断言
  • 限制复杂性：限制结构复杂性限制非确定性
  • 结合项目：该架构中集成了 JUnit测试类，可以调用该方法将不同的方法函数体放入测试类中进行运行。然后查看其操作结果来确定是否正确。可以对不同层次的代码模块进行测试，例如：mapper层可以使用beanfactory实例化一个实体进行测试，可以更好的追踪问题，快速定位。
• 易用性
  • 支持用户主动：撤销取消恢复聚集
  • 支持系统主动：维持任务模型、维持用户模型、维持系统模型
  • 结合项目：用户的每一个操作都会由确认提出弹出窗用以恢复到之前的状态或者进行下一个状态。用户可以批量进行工资发放功能，符合聚集。

架构

• springMVC架构：随机发挥吧

评估

• ATAM
  • 通知每个人介绍流程，明确职责
  • 评估人员全部理解该系统，介绍商业环境
  • 通过4+1视图讲解架构
  • 确定体系结构
  • 细化质量属性
  • 分析结构体系方法
  • 讨论场景确定场景优先级
  • 分析体结构方法
  • 得到结果

存在问题及改进方法

• 自由发挥吧
• 可以从前端、数据、后台某些逻辑等简略介绍

软件体系结构