软件体系结构（02）

（个人复习用）

2024春考题回忆
大题：ABSDM方法
填空题：管道过滤器与仓库风格特性，可用性、安全性、性能的具体判断
选择题：开闭原则，prototype，IaaS，PaaS和SaaS，……
判断题：里氏替换原则，良好的软件设计特征……

基于体系结构的软件开发

设计原则

不良设计的特征

• 刚性
• 脆弱性
• 不动性
• 粘性
• 不必要的复杂性
• 不必要的重复
• 不透明度

OO设计中SOLID 原则

• SRP - 单一职责原则
• OCP - 开闭原则
• LSP - 里氏替换原则
• ISP - 接口分离原则
• DIP - 依赖倒置原则

设计模式

• Creational创建型模式
• Structural 结构型模式
• Behavioral行为型模式
  创建型模式

◦ 工厂模式：根据提供给工厂的外部数据或环境变量，确定创建哪个 类的实例。 ◦ 抽象工厂模式：是工厂的工厂，可以用来创建相关的或互相依赖的
一系列产品。 ◦ 建造者模式：可以用统一的构建过程构造出不同的复杂对象。 ◦ 单例模式：可以确保只有一个对象实例，并且该实例可被全局访问。
◦ 原型模式：当创建新实例成本较高时，复制或克隆已存在类实例而 不是创建新的实例。

Structural 结构型模式

代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。客户端通过代理间接地访问该对象， 从而限制、增强或修改该对象的一些特性。
•适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而 不能一起工作的那些类能一起工作。
•装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能。
•外观（Facade）模式：将一组复杂的子系统功能封装在一个单一的接口中，使得客户端可以更方便地调
用这些功能，而不需要了解子系统的内部细节。
•组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
•桥接（Bridge）模式：将抽象与实现进行分离，使得它们可以独立地变化。这种设计模式适用于那些抽 象和实现都需要独立扩展的场景。
•享元（Flyweight）模式：通过共享内部状态，减少内存使用量，分享信息给尽可能多的相似对象。

Behavioral行为型模式

1.策略（Strategy ）模式：定义一系列算法，并将每一个算法封装起来，使它们可以互相替换。策略模式使得算法可以独立于使用它的客户端变化。
2.模板方法（Template Method ）模式：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结 构即可重新定义该算法的某些特定步骤。
3.观察者（Observer）模式：定义对象之间的一对多依赖关系，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
4.迭代器（Iterator）模式：它提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。
5.职责链（Chain of Responsibility ）模式：使多个对象都有机会处理请求，从而避免请求的发送者和多个请求处理者耦合在一起。将这些对象
连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
6.状态（State ）模式：允许一个对象在其内部状态改变时改变它的行为。对象看起来好像修改了它的类。
7.访问者（Visitor ）模式：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操 作。
8.命令（ Command ）模式：将请求（命令）封装成对象，使得可以用不同的请求对客户端进行参数化，具体的请求可以在运行时更改、排队或记录。
9.中介者（ Mediator ）模式：减少对象之间互相通信的复杂性，通过创建一个中介者对象，将对象之间的通信集中交给该对象来处理，而不是直 接相互交流。
10.备忘录（ Memento ）模式：在不破坏封装的前提下，保存和恢复对象的内部状态。

基于体系结构的设计方法 ABSD

Architecture-Based Software Design
ABSD方法为产生软件系统的概念体系结构提供基础
概念体系结构描述了系统的主要设计元素及其关系
概念体系结构代表了在开发过程中作出的第一个选择，是达到系统质量和业务目标的关键，为达到预定功能提供了一个基础

** ABSD**

体系结构驱动，是指构成体系结构的业务、质量和功能需求的组合。
使用ABSD方法，设计活动可以在体系结构驱动一决定就开始，这意味着需求抽取和分析还没有完成，就开始了软件设计。设计活动的开始并不意味着需求抽取和分析活动就可以终止，而是应该与设计活动并行。特别是在不可能预先决定所有需求时，例如产品线系统或长期运行的系统，快速开始设计是至关重要的。

相关概念

用例和质量场景

用例已经成为推测系统在一个具体设置中的行为的重要技术。用例使功能需求具体化，使质量需求具体化。
通过定义特定场景来捕获质量需求，并称这些场景为质量场景。
质量场景必须包括预期的和非预期的刺激。 例如，一个预期的性能场景是估计每年用户数量增加10%的影响， 一个非预期的场景是估计每年用户数量增加100%的影响。非预期场景可能不能真正实现，但它们在决定设计的边界条件时很有用。

步骤
（1）功能分解
（2）选择体系结构风格
（3）为风格分配功能
（4）细化模板
（5）功能校验
（6）创建并发视图
（7）创建配置视图
（8）验证质量场景
（9）验证约束

体系结构的设计和演化过程

实验原型阶段

第一个开发周期

• 第一个开发周期没有具体的、明确的目标。此时，为了提高开发效率，缩短开发周期，所有开发人员可以分成了两个小组，一个小组创建图形用户界面，另一个小组创建一个问题域模型。两个小组要并行地工作，尽量不要发生相互牵制的现象。
• 在第一个周期结束时，形成了两个版本，一个是图形用户界面的初始设计，另一个是问题域模型，该模型覆盖了问题域的子集。用户界面设计由水平原型表示，也就是说，运行的程序只是实现一些用户界面控制，没有实现真正的系统功能。

第二个开发周期

• 标识构件
• 提出软件体系结构风格
• 把已标识的构件映射到软件体系结构中
• 分析构件之间的相互作用
• 产生软件体系结构
• 软件体系结构正交化

演化开发阶段

• 需求变动归类
• 制订体系结构演化计划
• 修改、增加或删除构件
• 更新构件的相互作用
• 产生演化后的体系结构
• 迭代
• 对以上步骤进行确认，进行阶段性技术评审
• 对所做的标记进行处理

软件体系结构的测试与评估

可靠性建模

顺序结构风格

并行/管道-过滤器结构风格

容错结构风格

调用-返回结构风格

系统的可靠性模型化步骤

• 通过系统的详细说明书，确定系统所采用的体系结构风格。
• 把每一种体系结构风格转换成状态视图，并计算状态视图中每一个状态的可靠性及其相应的迁移概率。
• 通过整个系统的体系结构视图，把所有的状态视图集成为一个整体状态视图。
• 通过整体状态视图构造系统的迁移矩阵，并计算系统的可靠性。
  软件体系结构风险分析方法
  • 采用体系结构描述语言ADL对体系结构进行建模
  • 通过模拟方法执行复杂性分析（Cyclomatic Complexity）
  • 通过FMEA（Failure Mode and Effects Analysis）和模拟运行执行
  严重性分析
  • 为构件和连接件开发其启发式风险因子
  • 建立用于风险评估的CDG
  • 通过图论中的算法执行风险评估和分析

软件体系结构的测试

测试内容

• 构件端口行为与连接件约束是否一致、兼容
• 单元间的消息是否一致、可达
• 相关端口是否可连接
• 体系结构风格是否可满足

测试准则
测试应覆盖所有的构件及各个构件的接口、各个连接件的接口、构件之间的直接连接、构件之间的间接连接

测试需求与测试用例测生成

• 构件或连接件内部消息的传递路径
• 构件或连接件内部端口的执行顺序路径
• 构件之间到连接件或连接件到构件的消息传递路径
• 构件之间的直接连接路径
• 构件之间的间接连接路径
• 所有构件的连接路径

软件体系结构评估