第四章理解质量属性

架构和需求
- 系统的需求可能会有很多的表现方式，比如以文本，模型，用例等等来表示，虽然系统的需求的表现类型有很多，但是它们基本都围绕以下几种类型
  - 功能性需求(Functional requirements)
    这类需求表明了系统应该做什么，在真正运行的时候应该如何响应。
  - 质量属性需求(Quality attribute requirements)
    这个是对功能性需求或者说是对整个系统性能等方面的评估和验证
  - 约束(Constraints)
    表示系统已经存在的那些设计决定，比如用什么开发语言，或者重用某个已经存在的模块
- 软件架构对以上系统需求是如何响应的
  - 将提出的功能性需求在对架构的设计中落实到架构中的哪些元素进行实现
  - 就像第二章说的那样，架构中设计一系列的结构来处理系统的质量属性
  - 在约束下提出设计决定使其和在约束下必须存在的决定保持一致，没有冲突
明确对质量属性的需求
- 质量属性场景
- 触发事件的来源(source of stimulus)
  对系统的触发可以是人，电脑系统等。
- 触发事件(Stimulus)
  就是当有触发事件到达系统需要一系列的系统响应来响应触发。
- 环境(environment)
  触发事件在某个特定环境发生，比如系统过载，或者正在运行或者是其他情况
- 制品(Artifact)
  有些制品是可以积累的，制品可能是系统的某个部分也可能是整个系统
- 响应(Response)
  指的是触发事件发生时系统的响应
- 响应度量(Response measure)
  需要记录响应的发生，把这个作为对系统需求的评估。
- 根据对质量属性场景的定义，可以对系统不同的质量属性进行分析，比如可用性场景，可测试性场景，可修改性场景等等。这样就可以通过不同的质量属性场景对不同的质量属性进行明确。
使用架构战术来获得质量属性
- 通过使用架构战术就可以是一个设计真正的具有可移植性，或者高性能，或者是可移植性。
架构战术就是一个可以影响到某一个质量属性响应控制的设计决策，架构战术的集合就是架构模式，架构战术是架构分析中不可分割的最小单元，因为一个战术只针对一个特定的质量属性。
触发事件->控制响应的战术->响应
质量设计决定概览
- 可以将设计决定分为以下七种类型
  - 分配职责
    - 识别重要的职责
    - 如何将识别出来的职责进行分配
  - 模块间协作
    - 识别出需要进行交互的系统元素
    - 决定交互中需要需要满足的属性
    - 选择满足这些属性的交互机制
  - 数据模型
    - 选择主要的数据抽象，数据之间的操作和数据的属性
    - 为系统的数据编写元数据
    - 将数据进行组织，用关系数据库还是对象等
  - 管理资源
    - 即对共有资源进行管理，比如CPU，内存等
    - 首先识别哪些资源市共有的
    - 决定由哪个系统元素对资源进行管理
    - 理解不同资源在饱和的时候会带来哪些影响
  - 架构元素间存在的映射
    - 架构必须要提供两种映射
      - 不同类型元素间的映射
      - 软件元素和硬件元素之间的映射
  - 基于时间的决定(变更处理)
    - 其他的六种设计决定都可以允许范围的变更
    - 在做变更决定的时候要考虑变更带来的后果
  - 选择技术
    - 在能达到剩下的六个设计决定提出的目标的情况下选择可行的技术，并且选择技术后反过来又会对这六个设计决定有一定的限制。

第四章 理解质量属性

推荐阅读更多精彩内容

第四章理解质量属性