05-架构设计

1. ASR

Architecturally SIgnificant Requirement(ASR)：对架构有重要影响的需求

1.1. 获取

1.1.1. 从需求文档

• MoSCoW：需求的四个级别，判断优先级和重要性
  1. Master
  2. Should
  3. Could
  4. Won’t

仅仅从需求文档无法获得完整、充分、详细的信息

1.1.2. 座谈会/研讨会

Quality Attribute Workshop(QAW)

2. 设计决策👍

七要素：

2.1. 分解

把系统为了实现功能需求和非功能需求的责任进行分解，分配给被分解的元素

2.2. 设计ASR

• 适用非ASR需求
  1. 架构设计不影响非ASR的需求
  2. 需要对架构设计做调整，小范围调整
  3. 非ASR需求无法满足，要做一些妥协
     1. 接近满足需求
     2. 调整需求
     3. 无法满足这些需求
• 是否要一次性设计所有的ASR？
  1. 从经验判断
  2. 是完全从零开发，还是已经完成一部分，或是有框架

2.3. 生成和测试

验证和评估

• 如何测试

  1. 分析技术：静态建模，动态仿真技术
  2. 设计checklist

• 什么时候完成验证

  1. 设计满足ASR
  2. 预算不够，实现目前为止最佳的设计

3. Attribute-Driven Design(ADD)

通用场景下的软件系统设计

3.1. ADD的输入

1. 是否有足够的需求？
2. 是否已经筛选出ASR？
3. 是否已经排序？
4. 使用基于场景（刺激响应）的描述方式精确描述？

3.2. 选择一个系统元素进行分解

• 分类
  1. greenfield开发：所有需求，整个系统作为设计焦点
  2. partially designed system：在当前已经设计过的系统里选择一些元素作为设计焦点

3.3. 选择和当前迭代相关的ASR

说明对用户的重要程度
说明对开发者的难易程度

排序：
(H,H)(H,M)(H,L)(M,H)…

3.4. 生成局部设计

1. 设计焦点承载的ASR怎么解决
2. 列出所有patterns和tactics
   1. 定义可配置的参数。e.g.ping/echo的timeout时间
   2. 估计参数值
3. 选择pattern和tactic
   1. 对整体（当前设计焦点的各个ASR）的影响
   2. 
4. 决定pattern/tactic和ASR的关系
   1. 哪些要做调整，结合
5. 设计决定可视化成一个或一组视图
6. 评估
   1. 哪些ASR没有被考虑到
   2. 是否需要做额外修正
   3. 所有设计决定会不会不一致

3.5. 实例化架构元素，分配职责

1. 实例化每一个架构元素
2. 把设计焦点承担的责任分配到架构元素
3. 把实例化和责任记录下来

3.6. 为实例化元素定义接口

交互哪些数据
元素之间的交互关系

3.7. 验证和完善需求，并使其成为实例化元素的约束

1. 验证设计需求是不是都分配到元素上
2. 把每个元素的职责翻译成功能需求

3.8. 重复直到所有ASR都满足

每一次迭代都满足一些ASR，如果还有ASR没有完成回到第二步，选择系统中一个元素作为设计新的焦点

3.9. ADD的输出

1. 软件元素：履行各种角色和职责，具有预定属性并与其他软件元素相关以组成系统架构的计算或开发工件
2. 角色
3. 职责
4. 性质
5. 关系：使用视图表示元素之间的关联

ADD例子

2021-软件系统设计-Lec15-Design - SpriCoder的博客