体系结构--第2章-质量属性

• 可集成性
可集成性是使独立开发的系统组件能够协同运行的能力， 集成性依赖与： § 组件的外部复杂性 § 组件之间的交互机制和协议 § 组件功能划分的清晰程度 § 组件接口的定义是否完整、合理 可集成性表明了一个系统内个组件之间相互协作的能力， 而互操作性衡量的则是一个系统与另一个系统的协作能力。
平均正常工作时间的加长是设计不易出错的系统，即在构 架层次上把相关部分分离而实现。 平均（脱机）修复时间的缩短主要通过设计容错性较好的 构架来实现，也就是通过在构架中重复设置关键处理单元及其 之间的通讯信道而实现，这是通过快速确定故障症结并快速替 换故障组件来实现的。因此要设计易于更改的组件、易于确定 故障症结的组件。 下面是银行曾经使用过的双机热备份的例子。 IBM RS/6000 RAID IBM RS/6000
下面的场景图表现了一个学生选课系统的性能。
选课系统 500 用户 试图同时 登陆系统 正常 运行 请求被 处理 平均响应 时间5秒
• 安全性
安全性是衡量系统在向合法用户正常提供服务的情况下， 阻止非授权使用和抗拒拒绝服务攻击的能力。 系统受到的威胁有多种，例如： § 拒绝服务 § IP源地址欺骗 下面场景表现了病毒攻击上网计算机时系统的安全性。
法律限制如系统必须采用正版软件。
社会限制如限制塑料袋，车辆分单双号，网络传播内容的分 级。
商业限制包括：
• 投放市场时间 投放市场时间的缩短可以通过采用商用产品或以前项目中 所构建的组件，如系统注册模块。 将一个以前构建好的组件插入到系统中的能力依赖于系统 的分解。
• 成本
不同的构架会导致不同的开发成本。 • 预计的系统生命周期的长短 一个可更改和可移植的系统会具有更长的生命周期, 但显然 会延长投放市场的时间。
第 2章
质量属性
• 2.1 需求分析与架构的关系 • 2.2 功能和架构的关系 • 2.3 架构和质量属性的关系 • 2.4 质量属性及其场景描述 • 2.5 限制条件 • 2.6 架构本身的质量属性 • 2.7 小结
“当一个人无法温饱的时候，确实很难思虑精神层面的事情。 但是不缺温饱的任何人，都应该有机会能够做一个高品德、有世 界观、有社会责任感的人。” ---李开复 站在石头上许愿
通过调整整星工作模式，月食期间尽量让功率负载降下来； 同时，运用了一些新技术，在热控方面进行调整，以弥补整星 热量补充不够的问题。
当“嫦娥”卫星进入地球阴影区时，按照预设程序自行关 闭遥测系统，卫星蓄电池的电量将合理分配，关闭能关的星载 设备，节约能源，就像进入“冬眠”，只保证大脑和心脏运行。 下面的场景图表示了嫦娥一号针对月食发生时的可用性。
有一个故事：一艘船在大海中被困，风雨飘摇，一个船员 对另一个船员说，现在最想做的事，是在沙发上抱着小女儿， 看一场球赛。 这个冬天，雪花飘得最密的时候，被困在停电停水的城市 里的朋友对我说，现在最想得到的东西，是一根蜡烛。 许愿，常被电影美化成想星星想月亮的浪漫，但事实是， 愿望只是我们眼睛上方的一个苹果，看得到，摸不到。是的， 全境是这样：我们脚踏在石头上，眼望苹果而许愿。 每个人的石头都会不同，石头是我们拥有的东西。如果衣 食住行都不愁，也许会想其他，饱暖以后还会有欲念。这是人 之常情，人的欲望水涨船高，永无止境。
只修改界 面代码或 配置文件
修改不产生 副作用，在2 小时内完成
• 可移植性
可移植性是系统能够在不同计算环境下运行的能力。这里 所说的环境可能是硬件、软件或两者的组合。
如果对任何特定计算环境的所有假设都仅包含在一个或几 个组件中，那么就说该系统是可移植的。
在构架中对与平台相关问题的封装常采用一个可移植层， 它是一组软件服务的集合，使上层应用软件与其环境具有抽象 接口，并且在移植时接口不变。 可移植层是信息隐藏原则运用的结果。
· 负责项目实施的单位—开发组织
2.4 系统质量属性的场景
• 可用性 可用性(Availability)是指系统正常运行时间的比例，是通过 两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运 行的速度来衡量的。 平均正常工作时间 X100% α = 平均正常工作时间 + 平均修复时间 可靠性是指系统能够保持正常运行的能力，通常用平均无 故障工作时间来衡量。可靠性和可用性都与构架密切相关。 日常生活中，洗衣机、电冰箱等是用无故障工作时间来衡 量。但对故障修复时间要求很短的系统，则常用可用性来衡量， 如银行、证券和航天飞行等系统。
制品
刺激
环境 刺激源
反应
反应度量
质量场景图
Biblioteka Baidu
质量属性不是处于隔离状态，只有在一定的上下文环境中 才能做出有意义的评判。生成质量属性场景的目的和意义： • 帮助构架师生成有意义的质量属性需求。 • 使质量属性需求的描述规范化。
• 某一场景是一类场景的代表，系统将以完全相同的方式 对这些场景做出反应。
质量场景创建的参与人员： · 负责软件执行的人员—最终用户 · 负责管理系统的人员—系统管理员 · 负责更改系统运行时功能的人员—维护人员 · 负责系统规划的单位—客户
心理测试题根据人们对某一情景的不同反应来判断其心理。 预案则对不同状况进行假设并准备采取相应措施。 小小说则用一个小故事说明一个（大）道理。
在软件开发中，我们借助场景说明用户对功能和质量的要 求，对应为用例场景和质量场景。这里的场景就是对某个实体 与系统的一次交互的简要描述。
质量属性场景就是通过对某个实体与系统的一次交互的简 要描述说明一个有关质量属性的特定需求，它由六部分组成： • 刺激源：可以是风险承担者、计算机系统等。 • 刺激：可以看作是一个事件。 • 环境：系统当前的状态。 • 制品：系统中对事件作出反应的部分，可以是整个系统或 系统的某一部分。 • 反应：事件到达后系统的相关行为。 • 反应度量：对反应结果提供某种形式的衡量。
2.5 限制条件
限制条件包括商业限制、技术限制、法律限制、社会限制等。 限制条件会对系统架构产生直接影响，也会对系统功能和质量产 生影响。从而间接影响架构。 功能需求 限制条件 质量属性
例如，“税务征收必须严格执行税务总局统一规定的税率” 是税务系统必须遵守的一项限制。这项限制引出一个质量要求， 即系统要具有可修改性，能根据要求调整税率设置；也引出一个 功能，即提供税率设置功能。 技术限制如系统必须运行在Linux操作系统上。
2 质量属性之间的关系：
• 一个质量属性的获取对其他质量属性可能产生正面或负面 的影响。
• 任何质量属性都不可能在不考虑其他属性情况下单独获取。
例如：最开始银行没有为网上银行的客户提供从客户端到网 站之间的加密手段，银行获得了性能和成本上的好处，但牺牲了 客户的安全性，导致假网站频出，很多人不敢使用网银业务。后 来，银行给客户提供了各种加密手段，如支付宝、UKey等，花 费了一定的成本和牺牲了部分性能，但客户获得了安全。现在网 银用户和网上交易额逐年递增。
系统
嫦娥一号 月食使之 不能获得 太阳能 正常 运行 尽可能降低 工作负载 90%的概率 进入冬眠
• 性能
性能是指系统的响应能力—即对外部刺激（事件）做出反 应时所需要的时间或在某段时间内所处理的事件个数。 在硬件条件一定的情况下，性能通常是系统中各组件间进 行通信或交互的次数与数据量的函数，如函数之间的调用，参 数的传递等。因此，性能与构架密切相关。 我们可以通过观察服务请求的到达速率、处理时间、队列 大小和延迟时间长短等指标了解系统性能。 我们可以根据预计的工作负载，通过构建系统的随机队列 模型来模拟该系统的性能并进行分析。
磁盘 阵列
某银行储蓄系统
可用性针对的是过错(fault)而不是失败(failure) 。
过错的例子：美国的勇气号火星探测器2004年在火星上出 现故障时能自动进入故障运行模式，并通过地面技术人员得以 修复。
失败的例子：2006年10月我国发射的鑫诺二号直播卫星， 由于技术上的原因导致卫星天线、 太阳能帆板无法打开，2007 年12月对鑫诺二号直播卫星进行了最后一次“抢救”，仍然无 济于事，20亿投资打了水漂。 嫦娥一号绕月卫星针对可能出现的错误就准备了148种预案。 下面是嫦娥一号针对月食问题的解决方案—月食期冬眠。 月食发生时，太阳光被挡住，嫦娥一号有近3小时无法通过 太阳帆板吸收太阳能，失去了能量的源泉。而且如果温度太低， 卫星上的仪器将有可能冻结，无法工作。在此期间需要蓄电池 供给整星电源。此外，由于月球表面红外辐射复杂，造成绕月 卫星的外部条件极为多变，保持内部设备温度十分困难。
采用可移植层的缺陷是什么？
可能不能发挥特定系统的最大效率！
• 可重用性
可重用性是指要合理地设计系统，使系统的结构或其某些组 件能够在以后的应用开发中重复使用。 构架的各个组件就是重用的单位，一个组件的可重用程度依 赖于它与其它组件的耦合程度。 可重用性与构架密切相关，它还可以看作是可修改性或可集 成性的特例。这相当于一个硬币的两面：建立的系统可修改导 致了系统可重用。
系统 病毒 试图修改 系统数据 上网 检测并 杀毒 95%的病毒 可被杀掉
• 易用性
易用性可分为如下几个方面： § 可学习性
§ 可记忆性
§ 错误避免 § 错误处理 § 满意度 易用性与构架是密不可分的。
• 可修改性
可修改性是进行快速修改并使修改代价尽可能低的能力，这 种能力直接受到构架的限制。 可修改性主要是所做修改的局部性的函数。 构架决定了各个组件及其职责，因此也定义了各个组件需要 修改时所处的状态，这些修改可以分为3类：
§ 涉及一个组件的修改
§ 涉及几个组件的修改 § 涉及整个构架的修改
对系统的更改一般是由于拥有该系统的组织的商业目的发生了 变化，这些变化包括: § 功能的扩展或改变 § 删除不需要的功能 § 适应新的操作环境 § 结构的重新调整
可修改性有时也称做可维护性。
下面场景表现了学生选课系统的修改性。
代码 用户 希望改变 操作界面 维护时
互操作性案例分析
楚天都市报2008年12月24号的新闻 --客户名字太长，难住多家银行
来自新疆湖北大学学生吐尔逊· 司马义最近遇到一件难事： 因为名字太长，到多家银行均无法办理业务，营业员要么称他 的名字太长，要么说名字中间的间隔号打不出来，只能以“.” 代替，其中某行电脑系统的客户姓名项最多只能输入4个汉字。 此问题是2007年下半年开始出现的。当时银行与公安户政 信息系统联网，银行系统无法显示姓名类似“吐尔逊· 司马义” 这样的客户在公安部门登记的户政信息，导致业务无法办理。 此前，各银行遇到类似问题时，都通过变通办法办理业务。他 们曾向上级单位反映，要求对系统进行升级，但一直未得到解 决。
3 质量属性可以分为两类：
• 运行时可见属性 包括：可用性、性能、安全性、易用性 • 维护时可见属性 包括：可修改性、可扩展性、可移植性、可集成性
4 质量属性的场景描述法
传统关于质量属性的讨论中存在问题： • 定义不具可操作性 • 可能会关注同一问题 可用性、易用性和安全性都可能关心一个系统故障
生活中我们通常根据情景（场景）对事物做出判断，它由 人物、环境、事件、反应和结果等要素组成。
随着软件开发水平的提高，如何满足功能已不是软件开发的 主要矛盾，也不是构架层次上主要考虑的问题，构架设计主要考 虑如何满足质量上的要求，但软件构架会限制各模块的功能划分， 功能对架构设计有间接的影响。
2.3 构架和质量属性
什么是质量属性 —系统在其生命周期过程中所表现出的各种特征。 1 架构和质量属性的关系： • 架构是获取许多质量属性的基础（上梁不正下梁歪） 在架构设计过程中就应考虑到这些质量属性，并在架构层次 上进行评估。 • 质量属性既和架构有关，也和具体实现有关。 例如，系统设计时一般都会考虑设置密码来提供安全性，可 是如果实现时SQL语句没写好，则可能被注入攻击。
2.1 需求分析和架构的关系
需求包括三要素：
• 功能
• 质量 • 限制条件 需求是架构设计的基础，但在需求阶段是无法弄清全部需求 的，因此需求和架构设计之间的迭代是必要和有意义的。
2.2 功能和架构
• 功能
功能是指系统所能完成的工作。
功能是构架设计的必要条件而非充分条件，因为不同架构具 有相同的功能，它们的差别在于质量。