2021-软件系统设计-Exam1-ADD

Exam1-ADD

1. Step 3 ADD的输入与输出

1. ADD的输入包括：
   1. 功能需求
   2. 设计约束
   3. 质量属性需求
2. ADD的输出
   1. 文档中使用的描述
      1. Software Element
      2. role
      3. responsibility
      4. property
      5. relationship
   2. 需要文档化的视图
      1. 视图类型
         1. Module View
         2. Component-and-Connector View
         3. Allocation View
         4. cross view
      2. 视图需要描述清楚的
         1. 系统如何被划分为主要计算和开发元素
         2. 系统不同的结构的元素、元素的类型以及他们拥有的属性和结构关系。
         3. 元素之间的交流沟通是如何发生的，以及相关属性

2. ADD方法

2.1. Step 1 确定需求的信息充足

1. 需要确定需求的优先级列表，来决定关注系统的哪个元素
2. 对每一个需求都需要使用如下的方式来描述
   1. 刺激源
   2. 刺激
   3. 制品(工件)
   4. 环境
   5. 响应
   6. 响应度量
3. 没有设计决定

2.2. Step 2 选择系统的一个元素来进行分解

1. 进行这一步的前提条件
   1. 系统还没有被分解过，可以被分解的只有系统本身，所有的需求都是该系统的。
   2. 系统已经被分解成几个元素，并且需求也被指派给了元素，我们必须要选择一个元素作为之后子步骤的关注点，选择的依据：
      1. 架构设计的当前知识
         1. 只有一个元素可以选择
         2. 根据他的依赖数量
      2. 风险和困难
         1. 实现要素相关需求的困难程度
         2. 是否熟悉如何实现要素相关需求的
         3. 实现要素相关需求的风险
      3. 商业标准
         1. 要素在整个系统中发挥的作用
         2. 要素在持续集成中可能的影响
         3. 是否是创建、购买、认证和被开源使用的
         4. 上线运行的影响
         5. 是否使用已有模块
         6. 是否全体成员可以来明确组件
      4. 组织标准
         1. 对资源利用的影响
         2. 开发需要的技能级别
         3. …
2. 没有设计决定

2.3. Step 3 识别候选架构驱动因素

1. 在这一步，我们需要再次基于他们和架构的相关影响性进行优先级排序，只需要划分为H(High)、M(Medium)、L(Low)
2. 划分为(H, H) …
   1. 第一个表示需求对涉众的优先级程度
   2. 第二个表示这个需求对架构的潜在影响程度。
3. 对于(H, H)
   1. 我们需要选择5或6个高优先级需求作为之后设计过程的关注点。
   2. 被选择出来的高优先级需求被称为当前要素分解所需要的"候选架构驱动因素"
4. 最终目的是识别出所有的架构驱动因素(可能在分解过程中，发现需求并不是高优先级的)
5. 这一步没有做出设计决定

2.4. Step 4 选择满足架构驱动因素的设计原则

1. 这一步需要选择可能出现在架构的重要要素类型和他们之间的关系类型。
2. 设计约束和质量属性需求会被用来决定上述要素类型、关系和他们之间的交互方式
3. 包含以下子步骤
   1. 从候选架构因素中选择设计关注点。比如关于可用性的质量需求的主要设计关注点就是错误避免、错误发现和错误恢复。
   2. 然后
      1. 对于每一个设计关注点，列出解决这个关注点的候选模式，模式来自于
         1. 你的知识、技能和经验
         2. 质量属性的架构策略，如果一个候选架构驱动因素关注了多个质量属性，那么很多的策略就会被适用
         3. 其他来源
      2. 对于你列出的每一个模式，你应该
         1. 识别每一个模式的判别参数来帮助你从列表中选择模式和策略。比如任何重启策略都会有重启时间这个判别参数；可迁移型就与模式中各元素之间存在的依赖关系有关
         2. 评估所有判别参数的值
   3. 从列表中选择你认为合适且满足候选架构驱动因素的模式。记录你的选择理由
      1. 创建一个模式与驱动因素的矩阵（见Table 1）来评估应用每一个模式的优缺点，考虑
         1. 使用每一个策略时的折中？
         2. 如果将不同模式之间进行合并？
         3. 是否有模式是互斥的？只能用A或B，而不是A和B
      2. 选择最能满足架构驱动因素的模式
   4. 考虑到目前为止确定的模式并决定它们之间的关系。所选模式的组合产生一个新模式
      1. 决定哪些不同模式的要素相关
      2. 决定哪些不同模式的要素不相关
      3. 寻找重叠功能并将其用作如何组合模式的指标
      4. 识别模式融合结果中的新要素
      5. 在本届最终回顾设计决策清单来确定完成了所有相关的决定
   5. 使用不同架构视图来描述你选择模式
      1. 不需要创建完备的文档化的架构视图
      2. 记录所有你认为有价值的或者设计架构选择
      3. 需要使用视图模板
   6. 评估和解决设计中的不一致
      1. 基于架构驱动因素进行设计评估，可以使用模型、实验、模拟、形式化验证
      2. 确定是否有架构驱动因素没有被考虑到
      3. 如果设计没有满足架构驱动因素，则评估候选模式或易用补充的策略
      4. 对照架构中其他元素的设计评估当前元素的设计并解决任何不一致之处。例如，在设计当前元素时，您可能会发现某些必须传播到架构中其他元素的属性。
4. 设计决定
   1. 你决定了整体的设计概念，包括架构中出现的主要类型的元素和他们之间的关系
   2. 你已经确定了与不同类型元素相关的一些功能（例如，在 Ping-Echo 模式中 ping 的元素将具有 ping 功能）。
   3. 你明确如何以及何时一些类型的设计要素会和其他关联（动态或静态）
   4. 你已经考虑过各种类型元素（内部软件元素和外部实体）之间的通信，但可能推迟了有关它的决策。 你考虑过
      1. 哪些类型的要素需要互相交流
      2. 哪种类型的机器、协议在软件模块与外部实体交互时会被使用(比如同步、异步、混合、远程调用等等)
      3. 质量属性需求与通讯机器的相关性
      4. 通信使用的数据模型（XML、JSON）
      5. 计算元素的类型支持各种类型的系统使用
      6. 如何将遗留组件和现成组件 (COTS) 集成到设计中
   5. 您已经对软件元素和系统资源进行了推理，但可能推迟了有关它们的决策。你考虑过
      1. 软件要素需要哪些资源
      2. 哪些资源会被管理
      3. 资源上限
      4. 资源会被如何管理
      5. 什么调度策略会被使用
      6. 哪些资源是有状态/无状态
      7. 操作的主要模式
   6. 您已经考虑了各种类型的内部软件元素之间的依赖关系，但可能推迟了对它们的决定。你考虑过
      1. 元素之间存在的执行依赖关系
      2. 如何以及在何处解决元素之间的执行依赖性
      3. 软件元素之间的激活和去激活相关性
   7. 你也考虑过或者延迟决定过如下
      1. 使用的抽象机制
      2. 哪些系统要素知道时间
      3. 采用什么样的进程/线程模型
      4. 如何解决质量需求要求

2.5. Step5 实例化架构元素并分配职责

1. 实例化架构元素是将职责根据要素类型进行分类，比如Ping-echo模型，部分组件有ping的职责，部分组件由echo的职责。
2. 职责分类来自于功能性需求、候选架构驱动因素和父要素、
3. 这一步最后，每个与父元素相关的功能需求都必须由子元素内的一系列职责来表示。
4. 具体执行步骤
   1. 实例化上一步中选择的每一个类型的要素。这些实例被称为您当前正在分解的元素（即父元素）的“子元素”或“子元素”。
   2. 根据类型将职责分配给子元素。例如ping类型元素就会被分配职责，包括ping功能、ping频率、ping信号数据内容，以及他们要发送ping信号的要素
   3. 根据步骤 4 中记录的理由和元素属性，在其子元素之间分配与父元素相关的职责。
      1. 例如，如果银行系统中的父元素负责管理现金分配、现金收款和交易记录，则在它的孩子之间分配这些责任。请注意，此时会考虑分配给父级的所有职责，无论它们在架构上是否重要。
      2. 在这一点上，考虑系统通常处理的用例可能会很有用——无论它们是否作为需求明确给出。这个练习可能会揭示新的职责（例如，资源管理）。 此外，您可能会发现新的元素类型并希望创建它们的新实例。这些用例包括1个用户同时做2个工作、2个用户同时做1个工作等等。
   4. 在这两种情况下创建元素类型的其他实例：
      1. 分配给元素的职责的质量属性特性存在差异。例如，如果一个子元素负责实时收集传感器数据并在稍后传输该数据的摘要，与数据收集相关的性能要求可能会提示我们实例化一个新元素来处理数据收集而原始元素处理传输摘要。
      2. 您想达到其他质量属性要求；例如，您将一个元素的功能重新分配给两个元素以提高可修改性。
      3. 此时，您应该查看本节末尾列出的设计决策列表，并确认您做出了所有相关决策。
   5. 使用各种视图（例如以下三个）分析并记录您在第 5 步中做出的设计决策：
      1. 模块视图对于推理和记录系统的非运行时属性（例如，可修改性）很有用。
      2. 组件和连接器视图可用于推理和记录系统的运行时行为和属性（例如，元素在运行时将如何相互交互以满足各种要求以及这些元素应该表现出哪些性能特征）。
      3. 分配视图对于推理软件和非软件之间的关系很有用（例如，软件元素将如何分配给硬件元素）。
5. 做出的设计决策
   1. 每种类型的元素有多少将被实例化，它们将拥有哪些单独的属性和结构关系
   2. 将使用哪些计算元素来支持各种类型的系统使用
   3. 哪些元素将支持主要的操作模式
   4. 如何在基础设施和应用程序中满足质量属性要求
   5. 如何划分功能并将其分配给软件元素，包括如何跨基础架构和应用程序分配功能
   6. 软件要素如何互相关联
      1. 不同架构结构中的系统元素如何相互映射（例如，模块如何映射到运行时元素以及运行时元素如何映射到处理器）
      2. 一个系统元素到另一个系统元素的映射是静态的还是动态的（即，当映射被确定时——在构建时、部署时、加载时或运行时）
   7. 各种元素之间的通信，包括内部软件元素和外部实体
      1. 哪些软件元素需要相互通信
      2. 软件元素和外部实体之间的通信将使用什么机制和协议
      3. 将用于软件元素和外部实体之间通信的机制所需的属性（例如，同步、异步、混合耦合）
      4. 与通信机制相关的质量属性要求
      5. 通信所依赖的数据模型
      6. 哪些计算元素支持各种类型的系统使用
      7. 遗留组件和 COTS 组件将如何集成到设计中
   8. 内部软件元素和系统资源
      1. 软件元素需要哪些资源
      2. 需要管理哪些资源
      3. 资源限制
      4. 如何管理资源
      5. 将采用什么调度策略
      6. 哪些元素是有状态/无状态的
      7. 主要操作模式
   9. 内部软件元素之间的依赖关系
      1. 元素之间存在哪些执行依赖
      2. 如何以及在何处解决元素之间的执行依赖性
      3. 软件元素之间的激活和停用相关性
   10. 使用了哪些抽象机制
   11. 系统元素对时间了解多少
   12. 将采用什么进程/线程模型
   13. 如何解决质量属性要求

2.6. Step6 定义实例化元素的接口

1. 在第6步中，您定义我们设计中的软件元素所需和提供的服务和属性。在 ADD 中，这些服务和属性被称为元素的接口。请注意，接口不仅仅是操作签名的列表。接口描述了软件元素对彼此做出的 PROVIDES 和 REQUIRES 假设。接口可能包括以下任何一项：
   1. 操作语法（例如，签名）
   2. 操作的语义（例如，描述、前置和后置条件、限制）
   3. 信息交换（例如，事件信号、全球数据）
   4. 单个元素或操作的质量属性要求
   5. 错误处理
2. 您应该继续执行以下三个步骤：
   1. 执行涉及您在步骤 5 中实例化的元素的功能需求。
   2. 观察由一个元素产生并由另一个元素消耗的任何信息。从不同视图的角度考虑接口。例如，模块视图将允许您对信息流进行推理；并发视图将允许您推理性能和可用性；部署视图将允许您推理安全性和可用性。
   3. 在每个元素的接口文档中记录您的发现。
3. 有些决定可能与您的特定系统类型无关。但是，您的决定可能涉及以下几个方面：
   1. 系统的外部接口
   2. 高级系统分区之间的接口
   3. 高级系统分区内的应用程序之间的接口
   4. 基础设施的接口

Step 7 验证和细化需求并使它们成为实例化元素的约束

1. 在步骤 7 中，您验证到目前为止的元素分解是否满足功能要求、质量属性要求和设计约束。您还可以为进一步分解准备子元素。
2. 您应该继续执行以下三个子步骤：
   1. 验证分配给父元素的所有功能需求、质量属性需求和设计约束已分配给分解中的一个或多个子元素。
   2. 将分配给子元素的任何职责转化为单个元素的功能需求。
   3. 根据需要细化各个子元素的质量属性要求。
3. 没有做出设计决策