理解质量属性

一、体系结构和需求

通常,系统的需求可以被分为:

  • 功能需求
    这些要求说明了系统必须做什么,它在外界情况的刺激下如何表现或在运行时作出反应。
  • 质量属性需求
    这些需求注解了(限定)功能需求。 质量认证可能是程序执行的有多快,错误输入时系统由多大的弹性,学习功能的容易程度等等。
  • 约束
    约束是具有零自由度的设计决策。 也就是说,这是一个已经做好的设计决策。

 

二、功能

功能是系统完成预期工作的能力。

功能与体系结构有着微妙的关系:

一方面,功能不能确定体系结构。给定一组必须的功能,可以创建的无数中体系结构满足该功能

另一方面,功能和质量属性是正交的。

 

三、质量属性的注意事项

如果功能性需求是“当用户按下绿色按钮时,会出现‘选项’(性能,可用性,可用性......)对话框”:

  • 性能质量属性可以描述对话框的显示速度
  • 可用性质量属性可以描述此功能失效的频率,以及修复的速度
  • 可用性质量属性可以描述此功能是多么易用。

讨论质量属性前,我们先考虑三个问题:

  • 1、质量属性的定义本身是不可测试的。 所以将说系统将是“可修改的”是毫无意义的。
  • 2、争论关注属于哪种质量是无休止浪费时间。 由于拒绝服务攻击导致的系统故障是可用性,性能,安全性或可用性的一个方面?
  • 3、每个属性社区(attribute community)都开发了自己的词汇表。

解决前两个问题(不可测定义和质量属性的交织重叠问题)的方法是使用质量属性场景作为表达质量属性的手段。

第三个问题的解决方案是对每种属性提供讨论 —— 集中于其潜在的关注点,且足以说明这个概念对属性社区至关重要。

 

四、指定质量属性需求

我们列一个表单来给出所有质量属性需求指定为场景。

我们对质量属性场景的表示包含以下部分:

  • 刺激(Stimulus)
  • 刺激源(Stimulus source)
  • 响应(Response)
  • 响应度量(Response measure)
  • 环境(Environment)
  • 制品(Artifact)

刺激源。这是产生刺激的某个实体(人,计算机系统或任何其他可能的对象)。

刺激。 刺激是指外界请求到达系统且需要响应的一种情景或事件。

环境。系统当前的状态。系统可能处于过载状态或正常操作,或某些其他相关状态。对于许多系统,“正常”操作可以指多种模式中的一种。

制品。系统中对事件作出反应的部分,可以是整个系统或系统的某一部分。

响应。响应是刺激到达后系统开展的活动。

响应度量。当响应发生时,它应该可以以某种方式测量,以便测试是否满足需求。

理解质量属性

我们将一般质量属性场景(即一般场景,那些独立于系统并且可能属于任何系统的场景)与具体质量属性场景(即具体场景,那些特定于考虑中的特定系统的场景)区分开来。

下面我们给出一个关于可用性(availability)的一般场景:

理解质量属性

 

五、通过一些策略(Tactics)来达成质量属性

体系结构工程师可以使用一系列基本的设计技术来实现质量属性响应。

我们称这些为体系结构的设计原语策略。

策略,同设计模式一样,是体系结构工程师多年来一直使用的技术。我们不发明策略,只是捕捉并学习他们在实践中所做的事情。

我们为什么要这样做? 原因有三:

  • 设计模式很复杂:它们是一系列设计决策且通常难以应用。体系结构工程师需要修改和调整它们。通过了解这些策略,体系结构工程师可以评估并扩展现有模式,以实现质量属性目标。
  • 如果没有模式来实现体系结构工程师的设计目标,那么策略将允许体系结构工程师参照“第一原理”来设计一个设计片段。
  • 通过分类策略,我们使设计更加系统化。 可以自由的选择多种策略来改善特定的质量属性。选择使用哪种策略是其他质量属性和实施成本等因素权衡的结果。

 

六、指导质量设计决策

体系结构设计是制定设计决策的系统方法。

我们将体系结构工程师需要做出的设计决策分类如下:

  • 责任分配
  • 协作模型
  • 数据模型
  • 资源管理
  • 体系结构元素之间的映射
  • 绑定时间
  • 技术抉择

1、职责分配

涉及责任分配的决定包括:

  • 确定重要职责,包括基本系统功能,体系结构基础设施和质量属性满意度。
  • 确定如何将这些职责分配给非运行时和运行时元素(即模块 Modules,组件 Components 和连接器 Connectors)。

2、协作模型

关于协调模型的决定包括:

  • 确定必须协作或禁止协作的系统元素
  • 确定协作的属性,例如及时性(timeliness),通用性(currency),完整性(completeness),正确性(correctness)和一致性(consistency)。
  • 选择实现这些属性的通信机制。 通信机制的重要属性包括有状态与无状态,同步与异步,有保证与无保证的传递,以及性能相关的属性(如吞吐量和延迟)。

3、数据模型

有关数据模型的决策包括:

  • 选择主要数据进行抽象处理,包括它们的操作和属性。 这包括确定如何创建,初始化,访问,持久化,操作,转义和销毁数据项。
  • 保证数据解释一致性所需的元数据
  • 数据的组织形式。这包括决定将数据保存在关系数据库、对象集合还是两者都保存。

4、资源管理

资源管理决策包括:

  • 确定必须管理的资源,并确定针对每个资源的限制
  • 确定哪个(哪些)系统元素管理哪个(哪些)资源
  • 确定如何共享资源以及在存在争用时采用的仲裁(arbitration)策略
  • 确定饱和度(saturation)对不同资源的影响。

5、体系结构元素之间的映射

实用的映射包括:

  • 模块和运行时元素之间的映射——即运行时元素从哪一个元素创建,每个模块为得到其运行时元素所包含的代码。
  • 将运行时元素分配给处理器
  • 将数据模型中的项目分配给数据存储
  • 模块和运行时元素到交付单元的映射

6、绑定时间

其他类别中的决策可能会同绑定时间相关联。 此类绑定时间决策的示例包括:

  • 对于职责分配,可以通过参数化构建脚本来构建模块。
  • 对于协作模型的选择,可以设计运行时协商的协议。
  • 对于资源管理,您可以设计一个系统来接受在运行时插入的新外围设备。
  • 对于技术的选择,您可以为智能手机构建应用商店,来自动下载相应版本的应用。

7、技术抉择

技术决策的选择包括:

  • 决定哪些技术可用于实现其他类别的决策
  • 确定支持该技术的工具(IDE,模拟器,测试工具等)是否足够
  • 确定内部熟悉程度和对技术的外部支持(例如课程,教程,示例,合同方的可用性)
  • 确定选择技术的副作用,例如所需的协作模型或受限的资源管理机会
  • 确定新技术是否与现有技术堆栈兼容
分享