软件系统设计2023 期末复习

发表于 更新于 分类于 阅读次数： Waline： 本文字数： 4.1k 阅读时长 ≈ 8 分钟

设计原则

  1. 单一职责原则：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中；或就一个类而言，应该仅有一个引起他变化的原因。是实现高内聚、低耦合的指导方针 。
  2. 开闭原则：一个软件实体应当对扩展开放，对修改关闭。
  3. 里氏替换原则：软件中如果能够使用基类对象，那么一定能够使用其子类对象。
  4. 依赖倒转原则：高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该 依赖于细节，细节应该依赖于抽象；或针对接口或抽象类编程，而不是针对实现或具体类编程。
  5. 接口隔离原则：客户端不应该依赖那些它不需要的接口。一旦一个接口太大，则需要将它分割成一些更细小的接口， 使用该接口的客户端仅需知道与之相关的方法即可。
  6. 合成复用原则：要尽量使用组合/聚合关系，少用继承。
  7. 迪米特法则/最小知识原则：每一个软件单位对其他的单位都只有最少的知识，而 且局限于那些与本单位密切相关的软件单位；一个软件实体应当 尽可能少的与其他实体发生相互作用。

策略模式

工厂方法模式

image-20230613134245193

​ 当系统扩展需要添加新的产品对象时，仅仅需要添加一个具体产品对象以及一个具体工厂对象，原有工厂对象不需要进行任何修改，也不需要修改客户端，很好地符合了“开闭原则”。

抽象工厂模式

产品等级结构：抽象电视机-具体电视机属于一个产品等级结构；抽象冰箱-具体冰箱属于另一个产品等级结构

产品族：海尔电视机-海尔冰箱-海尔空调属于一个产品族

抽象工厂模式与工厂方法模式最大的区别在于，工厂方法模 式针对的是一个产品等级结构，而抽象工厂模式则需要面对多 个产品等级结构。

开闭原则的倾斜性：增加新的工厂和产品族容易， 增加新的产品等级结构麻烦

image-20230613135326968

状态模式

image-20230613140303006

状态模式对“开闭原则”的支持并不太好，对于可以切换状 态的状态模式，增加新的状态类需要修改那些负责状态转换 的源代码，否则无法切换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码。

命令模式

命令模式可以对发送者和接收者完全解耦，发送者与接收者之间没有直接引用关系，发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。这就是命令模式的模式动机。

image-20230613140638866 image-20230613140752866 image-20230613141152027

观察者模式/发布订阅模式/模型视图模式

image-20230613141748317

中介者模式

image-20230613145233659

模板方法模式

适配器模式

适配器模式(Adapter Pattern) ：将一个接口转换成 客户希望的另一个接口，适配器模式使接口不兼容的 那些类可以一起工作，其别名为包装器(Wrapper)。 适配器模式既可以作为类结构型模式，也可以作为对 象结构型模式。

组合模式

组合模式(Composite Pattern)：组合多个对象形成 树形结构以表示“整体-部分”的结构层次。组合模 式对单个对象（即叶子对象）和组合对象（即容器对 象）的使用具有一致性。 • 组合模式又可以称为“整体-部分”(Part-Whole)模 式，属于对象的结构模式，它将对象组织到树结构中， 可以用来描述整体与部分的关系。

image-20230613145805181

装饰模式

image-20230613145907914

与继承关系相比，关联关系的主要优势在于不会破坏类的封装性， 而且继承是一种耦合度较大的静态关系，无法在程序运行时动态扩 展。在软件开发阶段，关联关系虽然不会比继承关系减少编码量， 但是到了软件维护阶段，由于关联关系使系统具有较好的松耦合性， 因此使得系统更加容易维护。当然，关联关系的缺点是比继承关系 要创建更多的对象。

使用装饰模式来实现扩展比继承更加灵活，它以对客户透明的方式 动态地给一个对象附加更多的责任。装饰模式可以在不需要创造更 多子类的情况下，将对象的功能加以扩展。

外观模式

引入外观角色之后，用户只需要直接与外观角色交互，用户与子系统 之间的复杂关系由外观角色来实现，从而降低了系统的耦合度。

image-20230613150031540

根据“单一职责原则” ，在软件中将一个系统划分为若干个子系统 有利于降低整个系统的复杂性，一个常见的设计目标是使子系统间 的通信和相互依赖关系达到最小，而达到该目标的途径之一就是引 入一个外观对象，它为子系统的访问提供了一个简单而单一的入口。

外观模式也是“迪米特法则”的体现，通过引入一个新的外观类可 以降低原有系统的复杂度，同时降低客户类与子系统类的耦合度。

在不引入抽象外观类的情况下，增加新的子系统可能需 要修改外观类或客户端的源代码，违背了“开闭原则”。

代理模式

通过引入一个新的对象（如小图片和远程代理对 象）来实现对真实对象的操作或者将新的对象作 为真实对象的一个替身，这种实现机制即为代理 模式，通过引入代理对象来间接访问一个对象， 这就是代理模式的模式动机

image-20230613150215598

随便默默

软件架构文档包

  1. Beyond

    a. 文档路线图：包含了范围、总结和简明摘要

    b. 视图的文档组织方式：描述了文档内的视图是如何组织的

    c. 系统概要：从整体上描述当前架构的简要介绍、业务驱动因素等

    d. 不同视图的映射关系

    e. 系统原理：从整体上描述当前架构的设计原理

    f. 目录-索引、词汇表、首字母缩略表

  2. View

    a. 体系结构风格和视图

    b. 结构视图，包含模块视图、组件和连接器视图、部署视图

    c. 质量视图

  3. 在每个View内包含

    a. 主视图：显示视图的元素和关系，以及图例

    b. 元素列表：详细介绍a中的每个元素、元素属性、关系属性、元素接口以及行为

    c. 上下文图：描述了系统如何与环境相关

    d. 可变性指引：描述视图中可能变化的地方

    e. 基本原理：描述设计是如何映射到视图中的，以及其合理性

ATAM中每个阶段的输出：

  1. step-0 准备和建立团队

    a. 评估计划

  2. step-1 评估1

    a. 架构的简明介绍

    b. 业务目标（驱动因素）的阐释

    c. 作为场景的特定质量属性所要求的优先级列表

    d. 效用树

    e. 风险点和无风险点

    f. 敏感点和均衡点

  3. step-2 评估-2

    a. 涉众们的场景优先级列表

    b. 风险主题和业务驱动因素各种受到的威胁

  4. step-3 后续

    a. 最终的评估报告

ATAM中每个阶段参与的stakeholders与其职责

  1. step-0 准备和建立团队

    参与者：评估团队领导、关键项目决策者

    职责：根据体系架构文档生成评估计划

  2. step-1 评估1

    参与者：评估团队、项目决策者

    职责：

    a. 评估负责人介绍ATAM方法

    b. 项目经理或客户从业务角度介绍业务驱动因素

    c. 首席架构师介绍体系结构

    d. 评估团队确定架构方法

    e. 评估团队和项目决策者生成质量属性效用树

    f. 评估团队分析架构方法

  3. step-2 评估2

    参与者：评估团队、项目决策者 、项目涉众

    职责：

    a. 评估负责人再次介绍ATAM方法，并展示之前取得成果

    b. 涉众头脑风暴确定场景优先级

    c. 评估团队分析架构方法

    e. 评估团队展示架构方法，并提交给涉众

  4. step-3 后续

    参与者：评估团队、主要涉众

    职责：评估团队制作最终评估报告，并交给主要涉众审核后，递交给委托评估的人

软件架构过程中的一般活动，以及每个活动的输入、输出

  1. 识别ASRS：

    输入：涉众

    输出：优先的质量属性场景

  2. 架构设计：

    输入：优先的质量属性场景、需求和约束、策略和模式

    输出：一组由模式决定的选场景的草图

  3. 架构文档化：

    输入：一组由模式决定的选场景的草图、涉众

    输出：view & beyond

  4. 架构评估：

    输入：view & beyond、涉众、优先的质量属性场景

    输出：view & beyond

软件架构的来源
  1. 非功能需求 NFRs
  2. 架构攸关需求 ASRs
  3. 质量属性
  4. 涉众和组织
  5. 技术环境
  6. 业务目标
  7. 商业与技术决策组合
有哪些通用设计策略（generic design strategies），给每个策略提供一个简明工作示例
  1. 抽象：使用抽象让设计师关注本身结构而不关注实现，例如将系统抽象为组件-连接器
  2. 分解：针对某一系统关注点分解后处理，例如将整个系统或某个模块分解
  3. 分而治之：将每个模块分别处理
  4. 生成与测试：将一个特定的设计看作是一个假设；根据测试路径生成测试
  5. 迭代与细化：使用迭代的方法，例如ADD方法多次迭代直至满足所有ASR
  6. 复用元素：重用在设计过程中出现了可以复用的元素，例如重用现有架构
什么是ASR，列举提取和识别ASR的四种来源和方法

ASRs 架构攸关需求是对体系结构产生了深远影响的需求

四种来源和方法：

  1. 从需求文档获取ASRs：MoScoW方法，用户故事
  2. 从采访涉众获取ASRs：软件质量工作坊
  3. 从业务目标获取ASRs：
  4. 用质量属性效用树管理ASRs：
ADD过程
  1. 确定由足够的需求信息
  2. 选择要分解的系统要素
  3. 确定选择的要素的ASR
  4. 选择符合ASR的设计
    1. 找出设计问题
    2. 列出子关注点替代模式/决策
    3. 从清单中选择模式/决策
    4. 确定模式/决策与ASR之间的关系
    5. 记录初步的架构视图
    6. 评估并解决不一致问题
  5. 实例化架构元素并分配职责
  6. 实例化元素定义接口
  7. 验证和完善需求
  8. 重复2-7步直到满足所有的ASR
风险点、权衡点、敏感点
  1. 识别风险：发现对所需的质量属性有负面影响的架构决策，例如使用分层模式会导致性能损耗
  2. 发现权衡：发现对多个质量属性有影响的架构决策，例如使用分层模式会损耗性能，但也会解耦增加系统的可修改性
  3. 发现敏感：发现特定质量属性对其敏感的架构决策， 例如对性能敏感的系统，使用缓存中间件
设计、体系结构（架构）、结构的关系

  1. 设计包含架构，架构包含结构

  2. 结构是静态的、逻辑的，是关于系统如何组成的

  3. 架构除了包含结构，还包含了组件之间的相关的关系结构，并定义一些动态的行为

  4. 架构是关于软件设计的，所有架构都是软件设计，但不是所有的设计都是架构，架构是软件设计的一部分

为什么使用不同视图，给出4种视图

原因：

  1. 不同视图支持不同的目标和用户，突出不同的系统元素和关系
  2. 不同视图将不同的系统元素暴露出不同的程度

视图：

  1. 模块视图：提供一组连贯职责的实现单元
  2. 组件连接器视图：显示具有某些运行时存在的元素
  3. 部署视图：反映了软件单元到软件开发或运行环境元素的映射
  4. 质量视图：安全视图、性能视图、可靠性视图、沟通视图、异常视图
  5. 组合视图
描述4+1视图
  1. 逻辑视图：描述架构中的重要元素和关系
  2. 过程视图：描述元素的并发和交互
  3. 物理视图：描述主要过程和组件如何映射到硬件上
  4. 发展视图：描述软件组件的内部组织联系
  5. 用例场景：捕获架构需求，与一个或多个视图有关
SOA：

核心：

  1. 服务契约
  2. 服务封装
  3. 服务重用
  4. 服务组合
  5. 服务自治
  6. 服务无状态

对互操作性：支持服务自动识别、注册、调用

对可伸缩性：服务高内聚，松耦合，易于可伸缩

对安全性：中间件可能被攻击；多服务导致追踪溯源困难

微服务

在SOA基础上

  1. 取消ESB，改用轻量级通信协议
  2. 部署和管理结合devops实现自动化
  3. 增加API网关
  4. 增加熔断器