软件体系结构 重点复习

软件体系结构概念及ABC

软件体系结构概念

• 某个软件或计算机系统的软件体系结构是该系统的一个或多个结构，它们由软件元素、这些元素的外部可见属性以及这些元素之间的关系组成。

ABC(软件架构的商业周期)

• 软件架构是技术、商业和社会等诸多因素作用的结果，而软件架构的存在反过来又会影响技术、商业和社会环境，从而影响到未来的构架。我们把这种相互影响的周期——从环境到架构又返回到环境——称作架构的商业周期。
• 架构的商业周期：
  • 组织目标如何影响需求和开发策略
  • 如何从需求得出架构
  • 如何对构架进行分析
  • 构架如何产生体现新的组织能力和需求的系统
• 简单描述一下架构设计可以怎样改变商业环境
  • 软件架构影响软件开发组织的结构。
    • 软件架构规定了要开发的软件单元。
      软件团队通常根据软件单元进行组织。
      组织团队倾向于专门化并嵌入到软件团队组织结构中
  • 软件架构影响软件开发组织的目标。
    • 成功开发一个系统使得公司在市场上占有一席之地，该系统所用的架构可以为类似系统的生产和部署提供良好机会，因此，开发组织可用该架构来拓宽市场
  • 软件架构会影响客户对新产品的需求。
    • 现有产品的体系结构可以作为产品线的基础。
      客户认识到通过重用现有体系结构可以降低成本和缩短上市时间。
      为了实现这些好处，客户可能愿意放松功能需求。
  • 软件架构影响未来架构的设计。
• 软件架构影响开发过程
  • 软件架构是整个软件开发过程的重要组成部分。
  • 架构知识对于理解产品的业务案例所涉及的约束和假设至关重要
  • 通常，确定一组完整的需求至少需要一个参考体系结构，因此迭代需求工程过程几乎总是必要的
  • 架构分析技术帮助软件团队评估架构
  • 软件架构师需要确保实现始终忠实于体系结构设计。
  • 随着体系结构的成熟和发展，它必须与设计文档保持同步。
  • 在不存在适当的设计文档的情况下，软件架构重构工具可能是有用的。
• 为什么说软件架构非常重要
  • 架构是涉众进行交流的手段
  • 架构是早期设计决策的体现
  • 架构是可传递、可重用的模型
• 架构师的职责
  • 指导技术方向
  • 管理冲突的影响
  • 减少不可预见的困难

软件体系结构的质量属性及其战术（重点！）

• 软件系统功能性和质量属性之间的关系
  • 软件系统功能性是指系统能够完成所期望的工作的能力，而质量属性则是高于系统功能基本要求的，它是对多种更高层次需求的抽象描述，如安全、可靠、易用及易于修改等，显然它适用于多个特定系统而非一个。由此我们可以看出，功能性和质量属性是正交的关系，即对应于相同的功能可以具有不同的质量属性。
• 质量属性场景是一种面向特定的质量属性的需求。它由以下6部分组成。
  • 刺激源：生成该刺激的实体（人、计算机系统或其他激励器）；
  • 刺激：刺激达到系统时可能产生的影响（即需要考虑和关注的情况）；
  • 环境：该刺激在某条件内发生。如系统可能正处于过载情况；
  • 制品：系统中受刺激的部分；
  • 响应：刺激到达后所采取的行动；
  • 响应度量：当响应发生时，以某种方式对响应的效果进行度量。
    
    
• 质量属性及相关战术
  • 是什么使一个设计具有了可移植性，一个设计具有了高性能，而另一个设计具备了可集成性？实现这些质量属性依赖于基本的设计决策。战术就是影响质量属性的设计决策，战术的集合称为“架构策略”。架构模式以某种方式将战术打包在了一起。
  • 可用性：
    • 可用性是指系统正常工作的时间所占的比例。从根本上讲，可用性是通过减少错误来最小化服务中断时间。
    • 
    • 可用性关注的问题：如何检测故障；发生故障的频度；出现故障时的现象；系统故障排除的时限；如何防止故障的发生；发生故障时的处理。
    • 
    • 当系统不再提供与其规范一致的服务时，故障就发生了；该系统的用户可以观察到这个故障。错误可能会导致故障的发生。可用性战术将会阻止错误发展成故障，至少能够把错误的影响限制在一定范围内，从而使修复成为可能。
      1. 错误检测：命令/响应；心跳（dead man 计时器）；异常；
      2. 错误恢复-检测和修复：表决；主动冗余（热重启）；被动冗余（暖重启/双冗余/三冗余）；备件；
      3. 错误恢复-重新引入：shadow操作；状态再同步；检查点/回滚
      4. 错误预防：从服务中删除；事务；进程监视器
  • 互操作性:
    • 互操作性是指两个或多个系统能够有效地交换有意义的信息的程度。
    • 
    • 为了让两个或多个系统有效地交换信息，它们必须这样做: 了解彼此。这就是定位战术背后的目的;以语义上有意义的方式交换信息。这就是管理接口策略背后的目的。
      1. 定位：发现服务
      2. 管理接口：接口编排(按正确的顺序提供服务)；调整界面(将一个参与者生成的信息修改为另一个参与者可接受的形式)
  • 可修改性:
    • 可修改性是关于变更的成本问题。可修改性主要包括：能改变什么？ 改变的可能性有多大？ 什么时候进行更改，由谁进行更改？
    • 
    • 控制可修改性的战术，其目标是控制实现、测试和部署变更的时间和成本。
      1. 减少模块的大小：分解模块
      2. 增加内聚(SRP)：维持语义的一致性
      3. 降低耦合((OCP)：加强封装；使用一个中介；限制依赖关系；重构；抽象通用服务；
      4. 推迟绑定时间
  • 性能
    • 性能与时间有关，是软件系统满足时间需求的能力。事件发生时，系统必须对其作出响应。描述可能发生的事件(以及它们可能在什么时候发生)以及系统或元素对这些事件的基于时间的响应是讨论性能的关键。
    • 
    • 性能战术的目标就是对在一定的时间限制内到达系统的事件生成一个响应。
      1. 控制资源需求：管理采样率；限制事件响应；对事件进行优先级排序；减少开销；限定执行时间；提高资源效率
      2. 资源管理：增加可用资源；提高并发性；维护计算的多个副本；维护多个数据副本；控制排队队列大小；调度资源
  • 安全性
    • 安全性是衡量系统在向合法用户提供服务的同时，阻止非法授权使用的能力。
    • 
    • 考虑系统安全性的一种方法是考虑物理安全性。这就引出了我们的四类战术:探测、抵抗、反应和恢复。
      1. 检测攻击：检测入侵；检测服务否认；验证消息的完整性；检测信息延迟。
      2. 抵抗攻击：标识用户；对用户进行身份验证；对用户进行授权；限制访问；限制暴露的信息；加密数据；独立实体；更改默认设置
      3. 应对攻击：权限收回；锁定计算机；通知用户
      4. 从攻击中恢复：（恢复）查看可用性；（识别）审计追踪；
  • 易用性
    • 易用性与用户完成期望任务的难易程度以及系统位用户提供的支持种类有关。
    • 
    • 我们使用用户和系统主动性之间的这种区别来讨论架构师用于实现各种场景的战术。
      1. 支持用户主动：确认；取消；暂停/恢复；撤销；聚合；默认设置
      2. 支持系统主动：维护任务模型；维护用户模型；维护系统模型

  参考文章：
  https://www.cnblogs.com/kangzhijia/p/8575298.html
  https://blog.csdn.net/qq_40536623/article/details/88653869
  https://www.cnblogs.com/luohaochi/p/10523759.html

常见软件体系结构模式及其特点

• 架构模式是在特定环境下软件体系结构中常见问题的通用可重用解决方案。

• 战术是原子，模式是分子。大多数模式由几种不同的战术组成。因此，在进行设计决策时，它们给予架构师比模式更精确的控制。

• 一个架构模式建立了以下关系:

  1. 上下文。引起问题的反复出现的情况。
  2. 问题。
  3. 解决方案。一个成功的解决问题的架构由以下几个因素确定：
     • 一组元素类型
     • 一组交互机制，它们确定元素将如何通过允许的拓扑进行协调
     • 指出其相互关系的元素的拓扑布局
     • 一组语义限制

• 架构模式

  模块的模式

  • 分层模式
    
    
  • OOP模式

  组件和连接器模式

  • 代理模式
    
    
  • MVC模式
    
    
  • 管道-过滤器模式
    
    
  • 客户端-服务器模式
    
    
  • 点对点模式
    
    
  • SOA模式(面向服务的体系结构模式)
    
    
  • 发布-订阅模式
    
    
  • 数据共享模式
    
    
    分隔布局
  • 映射-规约模式
    
    
  • 多层模式
    
    

软件体系结构设计方法

• 属性驱动设计法

  是一种定义软件架构的方法，该方法将分解过程建立在软件必须满足的质量属性智商。ADD的步骤如下。

• ADD的步骤如下:

  • 选择要分解的模块
  • 根据如下步骤对模块进行求精：
    1. 从具体的质量场景和功能需求集合中选择架构驱动因素。并不是同等看待所有需求，而是在满足了最重要的需求的条件下，才满足不太重要的需求，即针对架构需求有优先级。
    2. 选择满足架构驱动因素的架构模式，根据前面的战术创建（或选择）模式。其目标是建立一个由模块类型组成的总体架构模式。
    3. 实例化模块并根据用例分配功能，使用多个视图进行表示。
    4. 定义子模块的接口。
    5. 验证用例和质量场景，并对其进行求精，使他们成为子模式的限制。
  • 对需要进一步分解的每个模块重复上述步骤。

软件体系结构评审方法（ATAM）

• 架构的权衡分析法

  • 从技术的角度对软件架构进行评估，旨在通过分析来遇见软件的质量，通过分析来创建、选择、评估与比较不同的架构。ATAM方法不但能够揭示架构如何满足特定的质量需求，而且还提供了分析这些质量需求之间交互作用的方法。使用ATAM方法评价一个软件架构的目的是理解架构设计满足系统质量需求的结果。

• ATAM产生如下结果:

1. 一个简洁的架构描述
2. 表述清楚的业务目标。
3. 用场经济和捕捉质量需求。
4. 架构决策到质量需求的映射。
5. 所确定的敏感点和权衡点集合：这个集合是一些对一个或多个质量属性具有显著影响的架构。
6. 有风险角色和无风险决策
7. 风险主题的集合。
8. 产生一些附属结果
9. 还产生一些无形结果。

• ATAM的九个步骤如下：

1. ATAM方法的表述
2. 商业动机的表述
3. 架构的表述
4. 对架构方法进行分类
5. 生成质量属性效用树。
6. 分析架构方法
7. 集体讨论并确定场景的优先级
8. 分析架构方法
9. 结果的表述