运行期质量属性核心定义指在软件运行阶段所关注的质量属性。主要内容运行期质量属性主要包含以下七个方面属性核心定义与说明性能软件系统及时提供相应服务的能力。包括对速度、吞吐量和容量等指标的要求。安全性软件系统同时兼顾向合法用户提供服务以及阻止非授权使用的能力。可伸缩性(可扩展性)当用户数和数据量增加时软件系统维持高服务质量的能力。例如通过增加服务器来提升系统处理能力。互操作性本软件系统与其他系统交换数据和相互调用服务的难易程度。可靠性软件系统在一定的时间内持续无故障运行的能力。可用性系统在一定时间内正常工作的时间所占的比例。会受到系统错误、恶意攻击、高负载等问题的影响。鲁棒性(健壮性/容错性)软件系统在非正常情况下如用户进行了非法操作、相关的软硬件系统发生了故障等仍能够正常运行的能力。总结运行期质量属性关注软件在生产环境中的行为表现。它们共同决定了系统在面对真实用户、数据和复杂环境时的稳定性、效率和安全水平是终端用户最能直接感知到的软件质量维度。12.1.2 面向架构评估的质量属性在软件架构评估过程中通常关注以下八种核心质量属性。属性核心定义关键要点与细分(1) 性能指系统的响应能力。即要经过多长时间才能对某个事件做出响应或者在某个时间段内系统所能处理的事件个数。衡量指标响应时间、吞吐量。设计策略优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。(2) 可靠性是软件系统在应用或系统错误面前在意外或错误使用的情况下维持其功能特性的基本能力。衡量指标平均失效等待时间MTTF、平均失效间隔时间MTBF。在失效率为常数和修复时间很短的情况下两者几乎相等。两个层面•容错错误发生时确保系统行为正确并进行内部“修复”。•健壮性使系统不受错误使用和错误输入的影响能按既定程序忽略错误。设计策略冗余、心跳、选举、Ping/Echo。(3) 可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。衡量指标如故障间隔时间。设计策略冗余、心跳、选举、Ping/Echo。(4) 安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。可细分为•机密性保证信息不泄露给未授权的用户、实体或过程。•完整性保证信息的完整和准确防止信息被非法修改。•不可否认性信息交换的双方不能否认其在交换过程中发送或接收信息的行为。•可控性保证对信息的传播及内容具有控制的能力防止为非法者所用。设计策略入侵检测、用户认证、用户授权、追踪审计。(5) 可修改性指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准通过考查这些变更的代价来衡量。可细分为•可维护性在错误发生后“修复”软件系统的难易程度。•可扩展性软件为适应新需求或需求变化而增加新功能的能力。•结构重组重新组织软件系统的构件及构件之间的关系的难易程度。•可移植性将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。设计策略接口-实现分离、抽象、信息隐藏。(6) 功能性是系统所能完成所期望的工作的能力。核心一项任务的完成需要系统中许多或大多数构件的相互协作。(7) 可变性指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则在某些具体方面不同于原有的架构。应用场景当要将某个架构作为一系列相关产品的基础时可变性很重要。(8) 互操作性作为系统组成部分的软件通常需要与其他系统或自身环境相互作用。核心要求为了支持互操作性软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。典型问题程序和用其他编程语言编写的软件系统的交互作用就是互操作性问题这种互操作性也影响应用的软件架构。12.1.3 质量属性场景描述1. 概念引入为了精确描述软件系统的质量属性通常采用质量属性场景 (Quality Attribute Scenario)作为描述和定义质量需求的具体手段。它是一种面向特定质量属性的、结构化的需求描述方式。2. 质量属性场景的六个组成部分一个完整的质量属性场景由以下六个部分构成它们共同定义了一个具体的、可评估的质量需求实例。组成部分核心定义刺激源 (Source)产生该刺激的实体可以是人、计算机系统或任何其他刺激器。刺激 (Stimulus)当刺激到达系统时所需考虑的具体条件或事件。环境 (Environment)刺激发生时系统所处的特定条件如正常运行、过载、维护等。制品 (Artifact)被刺激的对象可能是整个系统也可能是系统的某个特定部分。响应 (Response)刺激到达后系统或制品所必须采取的行动。响应度量 (Response Measure)用于对响应进行度量的具体指标以便对该需求进行验证和测试。3. 实例可修改性质量属性场景以淘宝APP为例以下以“淘宝APP功能更新”为例展示一个可修改性质量属性场景的具体应用。场景组成部分对应实例描述刺激源淘宝APP的开发团队开发人员修改代码。刺激淘宝APP需要进行版本更新以增加新功能或修复已知问题。环境APP运行平台如iOS、Android的应用商店发布环境。制品新版本的淘宝APP安装包。响应成功发布新版本增添了计划中的功能或修复了特定的BUG。响应度量用户可以观察到过去的某个BUG已消失或者应用中出现了承诺的新功能。总结质量属性场景通过刺激-响应模型将抽象的质量属性如可修改性、性能、安全性等转化为包含具体角色、条件、对象、行动和验收标准的实例。这种描述方法使质量需求变得具体、可评估、可测试是架构设计与评估的重要沟通与验证工具。12.1.3 质量属性场景描述 - 可修改性场景实例可修改性质量属性场景描述实例下表展示了一个完整的、用于描述“可修改性”质量属性的通用场景模板。它通过定义场景的六个要素及其可能的具体情况为评估系统的可修改性提供了清晰的分析框架。场景要素可能的情况 / 描述刺激源最终用户、开发人员、系统管理员刺激希望增加、删除、修改、改变功能、质量属性、容量等环境系统设计时、编译时、构建时、运行时制品系统用户界面、平台、环境或与目标系统交互的系统响应查找架构中需要修改的位置进行修改且不会影响其他功能对所做的修改进行测试部署所做的修改响应度量根据所影响元素的数量度量的成本、努力、资金该修改对其他功能或质量属性所造成影响的程度实例应用说明此模板定义了评估系统“可修改性”时需考虑的核心维度。在实际分析中可根据具体变更需求刺激选择或组合“可能的情况”来构建一个具体的评估场景。例如当“开发人员”刺激源在“编译时”环境希望“增加一个新功能”刺激时评估其“响应”如定位、修改、测试的难易程度和“响应度量”如修改所影响的代码模块数、所需人天即可形成一个具体的可修改性评估用例。12.1.3 质量属性场景描述质量属性场景主要用于描述和定义系统的特定质量需求。它主要关注以下六类质量属性并明确了每类属性在场景描述中需要考察的核心方面。质量属性场景主要关注点可用性系统故障发生的频率、故障发生时的表现、允许系统非正常运行的时间长度、何时可以安全地出现故障、如何防止故障发生以及故障发生时的通知要求。可修改性系统在改变功能、质量属性时需要付出的成本和难度。此类场景可能发生在系统设计、编译、构建、运行等多种情况和环境下。性能系统的响应速度可通过效率、响应时间、吞吐量、负载等指标客观评价性能的好坏。可测试性系统测试过程中的效率以及发现系统缺陷或故障的难易程度。易用性用户使用系统时的容易程度包括系统的学习曲线、完成操作的效率、用户对使用过程的满意程度等。安全性系统在向合法用户提供服务的同时阻止非授权用户使用的能力。总结质量属性场景是一种结构化的需求描述方法它将抽象的、非功能性的质量要求如“系统要可靠”、“界面要友好”转化为针对具体属性、包含明确关注点的、可评估和验证的具体场景从而为架构设计和测试提供明确的依据。12.2 系统架构评估12.2.1 系统架构评估中的重要概念1. 系统架构评估定义系统架构评估是在对架构分析、评估的基础上对架构策略的选取进行决策的过程。2. 三个核心概念(1) 敏感点与权衡点核心定义是关键的架构决策。敏感点指为了实现某种特定的质量属性一个或多个构件所具有的特性。权衡点是影响多个质量属性的特性是多个质量属性的敏感点。典型示例 (加密级别)提高加密级别可以提高安全性但可能需要耗费更多的处理时间从而影响性能。如果对机密消息的处理有严格的时间延迟要求则加密级别就可能成为一个权衡点。(2) 风险承担者 (利益相关人)核心定义系统的架构涉及很多人的利益这些人都对架构施加各种影响以保证自己的目标能够实现。核心角色 - 软件系统架构师是风险承担者之一。职责是负责在软件架构的质量需求间进行权衡。所关心的问题是对其他风险承担者提出的质量需求进行折中和调停。(3) 场景核心作用在进行架构评估时一般首先要精确地得出具体的质量目标并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制称之为场景。核心描述是从风险承担者的角度对与系统的交互所做的简短描述。在架构评估中一般采用刺激、环境和响应三方面来对场景进行描述。总结理解敏感点/权衡点有助于识别关键设计决策明确风险承担者及其目标特别是架构师的调和角色是评估的社会维度运用场景则是将抽象的质量目标具体化、可评估化的核心方法。三者共同构成了进行有效架构评估的基础认知框架。12.2.1 系统架构评估中的重要概念1. 评估的时间点与目的时间点系统架构评估通常位于架构设计之后系统设计之前。关联性因此它与后续的设计、实现、测试阶段没有直接关系。核心目的评估所采用的架构是否足以解决软件系统的需求。2. 系统架构评估的三种方法评估方法核心特点与描述关键要素/备注(1) 基于调查问卷或检查表的方法类似于需求获取中的问卷调查但侧重于架构方面。要求评估人员必须对评估的领域非常熟悉。(2) 基于场景的评估方法主要方法。通过分析架构对特定场景使用或修改活动的支持程度来判断其对质量需求的满足度。场景设计三要素1.刺激事件2.环境事件发生条件3.响应架构应对过程应用ATAM架构权衡分析方法、SAAM软件架构分析方法。(3) 基于度量的评估方法制定定量指标如代码行数来直接度量架构。核心活动1. 建立质量属性与度量间的映射原则2. 从文档中获取度量信息3. 分析推导出系统质量属性。要求评估人员需对架构熟悉。12.2.2 系统架构评估方法1. 基于场景的架构分析方法 SAAMSAAM (Software Architecture Analysis Method) 是一种针对非功能质量属性的架构分析方法是最早形成文档并得到广泛使用的软件架构分析方法。(1) 特定目标对描述应用程序属性的文档进行审查以验证基本的架构假设和原则。(2) 评估技术采用的核心技术是场景技术。场景代表了描述架构属性的基础详细描述了各种系统必须支持的活动和可能存在的状态变化。(3) 质量属性该方法的基本特点是把任何形式的质量属性都具体化为场景。可修改性是 SAAM 分析的主要质量属性核心关注点。(4) 风险承担者SAAM 旨在协调不同参与者风险承担者之间感兴趣的共同方面。作为后续架构决策的基础以达成对架构的共识。(5) 架构描述时间点SAAM 通常在架构的最后版本确定后使用但早于详细设计阶段。形式要求架构的描述形式应当被所有参与者理解。描述维度架构的功能、结构和分配被定义为描述架构的 3 个主要方面。(6) 方法活动主要输入问题描述、需求声明和架构描述。分析流程SAAM 分析评估架构的过程包括以下 5 个步骤场景开发架构描述单个场景评估场景交互评估总体评估逻辑关系“场景开发”通过迭代生成“体系结构描述”。“单个场景评估”与“场景交互评估”通过逻辑或OR汇聚为“单个体系结构评估”。结合比较多个体系结构的需求最终输出“总体评估”。(7) 已有知识库的可重用性SAAM不考虑这个问题。(8) 方法验证SAAM 是一种成熟的方法已被广泛应用到众多系统中包括但不限于空中交通管制系统嵌入式音频系统WRCS修正控制系统KWIC根据上下文查找关键词系统12.2.2 系统架构评估方法2. 架构权衡分析方法 ATAMATAM (Architecture Tradeoff Analysis Method) 是在 SAAM 的基础上发展起来的主要针对性能、安全性、可修改性和可用性在系统开发之前对这些质量属性进行评价和折中。核心目标与参与者核心目标让架构师明确如何权衡多个质量目标。主要参与者评估小组、项目决策者和其他项目相关人。四大活动领域ATAM 被分为四个主要的活动领域整个评估过程强调以质量属性作为架构评估的核心场景和需求收集体系结构视图和场景实现属性模型构造和分析折中ATAM 分析评估过程九步法ATAM 的评估过程通常分为四个阶段共包含九个具体步骤阶段1场景和需求收集收集场景收集需求约束环境阶段2体系结构视图和场景实现3. 描述体系结构视图4. 实现场景阶段3属性模型构造和分析5. 特定属性分析优秀的分析理论阶段4折中6. 标志敏感度7. 标志折中8. 产生分析最终输出形成行动计划12.2.2 系统架构评估方法2. 架构权衡分析方法 ATAM续补充ATAM 方法的评估实践阶段划分用 ATAM 方法评估软件架构其工作分为 4 个基本阶段即演示、调查和分析、测试和报告。(1) 阶段1演示Presentation这是使用 ATAM 评估软件体系结构的初始阶段。① 介绍 ATAM描述 ATAM 的评估过程。② 介绍业务驱动因素着重业务视角提供有关系统功能、主要利益相关方、业务目标和其他限制等信息。③ 介绍要评估的体系结构侧重可用性以及体系结构的质量要求。(2) 阶段2调查和分析Investigation and Analysis在这个阶段人们对评估期间需要重点关注的一些关键问题进行彻底调查。① 确定架构方法涉及能够理解系统关键需求的关键架构方法。② 生成质量属性效用树确定最重要的质量属性并确定有限次序。③ 分析体系结构方法彻底调查和分析找出处理相应质量属性架构的方法。包括4个主要阶段调查架构方法 - 创建分析问题 - 分析问题的答案 - 找出风险、非风险、敏感点和权衡点。(3) 阶段3测试① 头脑风暴和优先场景将头脑风暴的优先列表与生成质量属性效用树中所获取的优先方案进行比较。② 分析架构方法。(4) 阶段4报告 ATAM提供评估期间收集的所有信息呈现给利益相关者。12.2.2 系统架构评估方法质量属性效用树 (Utility Tree)ATAM 方法采用效用树Utility tree这一工具来对质量属性进行分类和优先级排序。效用树的结构树根质量属性下一层属性分类叶子节点质量属性场景ATAM 主要关注的质量属性ATAM 主要关注以下 4 类质量属性因为这 4 个质量属性是利益相关者最为关心的性能 (Performance)安全性 (Security)可修改性 (Modifiability)可用性 (Usability)12.2.2 系统架构评估方法3. 成本效益分析法 CBAM基本概念全称Cost-Benefit Analysis Method。基础在 ATAM 的基础上构建。核心目的对架构设计决策的成本和收益进行建模让决策者根据投资回报率 (ROI)来选择合适的架构。应用时机在 ATAM 确定质量合理的基础上再对效益进行分析。分析流程8个步骤整理场景确定场景并确定优先级。选择优先级最高的1/3场景进行分析。对场景进行细化对每个场景进行详细分析。确定最好、最坏的情况。确定场景的优先级项目干系人对场景投票。根据投票结果生成场景的权值。分配效用对场景响应级别确定效用表。建立策略、场景、响应级别的表格。形成“策略-场景-响应级别”的对应关系使用内插法确定期望的质量属性响应级别的效用根据效用表确定所对应的具体场景的效用表。计算各架构策略的总收益根据受成本限制影响的投资回报率 ROI 选择架构策略估算成本。用上一步的收益减去成本计算 ROI 并排序。从而选择收益最高的架构策略。中间件1. 定义中间件是指在一个分布式系统环境中处于操作系统和应用程序之间的系统级软件。它可以在不同的技术之间共享资源将不同的操作系统、数据库、异构的网络环境以及若干应用结合成一个有机的协同工作整体。2. 位置与特点中间件位于客户机/服务器的操作系统之上管理计算机资源和网络通信。(1) 软件类别中间件是一类软件而非一种软件。(2) 核心功能不仅仅实现互连还要实现应用之间的互操作。(3) 架构特性基于分布式处理的软件最突出的特点是其网络通信功能。3. 任务中间件的任务是使应用程序开发变得更容易通过提供统一的程序抽象隐藏异构系统和分布式系统下低级别编程的复杂度。4. 架构图示分层结构顶层应用...中间层中间件分布式系统服务底层操作系统...、网络、数据库5. 支持的两方面内容中间件提供的支持通常包括两方面(1) 交互支持作用协调系统中不同组件之间的通信和数据交换。机制消息队列远程过程调用RPC对象请求代理ORB目的实现分布式环境中的进程间通信IPC。优势使得应用程序不必关心底层网络细节能够更专注于业务逻辑。(2) 提供公共服务服务内容中间件提供对服务的可复用的实现如事务管理安全服务命名和目录服务持久化服务负载均衡故障恢复和容错能力等。解决问题有助于解决分布式系统中常见的问题如一致性、可用性和伸缩性。中间件中间件的功能负责连接与通信负责客户机与服务器之间的连接和通信。负责客户机与应用层之间的高效率通信机制。提供互操作与控制机制提供应用层不同服务之间的互操作机制。提供应用层与数据库之间的连接和控制机制。提供开发与运行平台提供多层架构的应用开发和运行的平台。提供应用开发框架支持模块化的应用开发。屏蔽底层差异屏蔽硬件、操作系统、网络和数据库的差异。提供高级管理与安全功能提供应用的负载均衡和高可用性。提供安全机制与管理功能。提供交易管理机制保证交易的一致性。提供通用服务提供一组通用的服务去执行不同的功能。避免重复的工作使应用之间可以协作。中间件中间件的分类通信处理消息中间件功能保证系统能在不同平台之间通信利用消息传递机制实现分布式系统中可靠的、高效的、实时的跨平台数据传输。示例IBM 的 MQSeries。事务处理交易中间件功能实现协调处理顺序、监视和调度、负载均衡等功能。示例BEA 的 Tuxedo。数据存取管理中间件功能为不同种类数据的读写和加解密提供统一的接口。示例Windows 平台的 ODBC 和 Java 平台的 JDBC 等。Web 服务器中间件功能提供 Web 程序执行的运行时容器。示例Tomcat、JBOSS 等。安全中间件功能用中间件屏蔽操作系统的缺陷提升安全等级。示例Kerberos、SSL/TLS。跨平台和架构的中间件功能用于开发大型应用软件。示例CORBA、JavaBeans、COM模型。专用平台中间件功能为解决特定应用领域的开发设计问题提供构件库。示例Android SDK、iOS SDK。网络中间件功能包括网管、接入、网络测试、虚拟社区和虚拟缓冲等也是当前最热门的研发项目。示例TCP/IP协议栈、HTTP服务器。13.1 软件可靠性基本概念-13.1.1 软件可靠性定义1. 软件可靠性定义软件可靠性Software Reliability是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。2. 软件可靠性和硬件可靠性区别(1) 复杂性软件复杂性比硬件高。大部分失效来自于软件失效。(2) 物理退化软件不存在物理退化现象。硬件失效主要是由于物理退化所致。(3) 唯一性软件是唯一的每个复制版本都一样。两个硬件不可能完全一样。(4) 版本更新周期硬件较慢。软件较快。13.1.2 软件可靠性的定量描述1. 规定时间自然时间运行时间执行时间占用CPU2. 失效概率软件运行初始时刻失效概率为0随着时间增长单调递增不断趋向于1。3. 可靠度定义软件系统在规定的条件下、规定的时间内不发生失效的概率。计算公式等于1 - 失效概率。4. 失效强度单位时间软件系统出现失效的概率。5. 平均失效前时间 (MTTF)定义平均失效等待时间即系统从开始运行到发生第一次故障所经历的平均时间。6. 平均恢复前时间 (MTTR)定义平均修复时间即从出现故障到修复成功的时间。7. 平均故障间隔时间 (MTBF)
12.1.1 质量属性概念 (续) - 运行期质量属性
运行期质量属性核心定义指在软件运行阶段所关注的质量属性。主要内容运行期质量属性主要包含以下七个方面属性核心定义与说明性能软件系统及时提供相应服务的能力。包括对速度、吞吐量和容量等指标的要求。安全性软件系统同时兼顾向合法用户提供服务以及阻止非授权使用的能力。可伸缩性(可扩展性)当用户数和数据量增加时软件系统维持高服务质量的能力。例如通过增加服务器来提升系统处理能力。互操作性本软件系统与其他系统交换数据和相互调用服务的难易程度。可靠性软件系统在一定的时间内持续无故障运行的能力。可用性系统在一定时间内正常工作的时间所占的比例。会受到系统错误、恶意攻击、高负载等问题的影响。鲁棒性(健壮性/容错性)软件系统在非正常情况下如用户进行了非法操作、相关的软硬件系统发生了故障等仍能够正常运行的能力。总结运行期质量属性关注软件在生产环境中的行为表现。它们共同决定了系统在面对真实用户、数据和复杂环境时的稳定性、效率和安全水平是终端用户最能直接感知到的软件质量维度。12.1.2 面向架构评估的质量属性在软件架构评估过程中通常关注以下八种核心质量属性。属性核心定义关键要点与细分(1) 性能指系统的响应能力。即要经过多长时间才能对某个事件做出响应或者在某个时间段内系统所能处理的事件个数。衡量指标响应时间、吞吐量。设计策略优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。(2) 可靠性是软件系统在应用或系统错误面前在意外或错误使用的情况下维持其功能特性的基本能力。衡量指标平均失效等待时间MTTF、平均失效间隔时间MTBF。在失效率为常数和修复时间很短的情况下两者几乎相等。两个层面•容错错误发生时确保系统行为正确并进行内部“修复”。•健壮性使系统不受错误使用和错误输入的影响能按既定程序忽略错误。设计策略冗余、心跳、选举、Ping/Echo。(3) 可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。衡量指标如故障间隔时间。设计策略冗余、心跳、选举、Ping/Echo。(4) 安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。可细分为•机密性保证信息不泄露给未授权的用户、实体或过程。•完整性保证信息的完整和准确防止信息被非法修改。•不可否认性信息交换的双方不能否认其在交换过程中发送或接收信息的行为。•可控性保证对信息的传播及内容具有控制的能力防止为非法者所用。设计策略入侵检测、用户认证、用户授权、追踪审计。(5) 可修改性指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准通过考查这些变更的代价来衡量。可细分为•可维护性在错误发生后“修复”软件系统的难易程度。•可扩展性软件为适应新需求或需求变化而增加新功能的能力。•结构重组重新组织软件系统的构件及构件之间的关系的难易程度。•可移植性将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。设计策略接口-实现分离、抽象、信息隐藏。(6) 功能性是系统所能完成所期望的工作的能力。核心一项任务的完成需要系统中许多或大多数构件的相互协作。(7) 可变性指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则在某些具体方面不同于原有的架构。应用场景当要将某个架构作为一系列相关产品的基础时可变性很重要。(8) 互操作性作为系统组成部分的软件通常需要与其他系统或自身环境相互作用。核心要求为了支持互操作性软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。典型问题程序和用其他编程语言编写的软件系统的交互作用就是互操作性问题这种互操作性也影响应用的软件架构。12.1.3 质量属性场景描述1. 概念引入为了精确描述软件系统的质量属性通常采用质量属性场景 (Quality Attribute Scenario)作为描述和定义质量需求的具体手段。它是一种面向特定质量属性的、结构化的需求描述方式。2. 质量属性场景的六个组成部分一个完整的质量属性场景由以下六个部分构成它们共同定义了一个具体的、可评估的质量需求实例。组成部分核心定义刺激源 (Source)产生该刺激的实体可以是人、计算机系统或任何其他刺激器。刺激 (Stimulus)当刺激到达系统时所需考虑的具体条件或事件。环境 (Environment)刺激发生时系统所处的特定条件如正常运行、过载、维护等。制品 (Artifact)被刺激的对象可能是整个系统也可能是系统的某个特定部分。响应 (Response)刺激到达后系统或制品所必须采取的行动。响应度量 (Response Measure)用于对响应进行度量的具体指标以便对该需求进行验证和测试。3. 实例可修改性质量属性场景以淘宝APP为例以下以“淘宝APP功能更新”为例展示一个可修改性质量属性场景的具体应用。场景组成部分对应实例描述刺激源淘宝APP的开发团队开发人员修改代码。刺激淘宝APP需要进行版本更新以增加新功能或修复已知问题。环境APP运行平台如iOS、Android的应用商店发布环境。制品新版本的淘宝APP安装包。响应成功发布新版本增添了计划中的功能或修复了特定的BUG。响应度量用户可以观察到过去的某个BUG已消失或者应用中出现了承诺的新功能。总结质量属性场景通过刺激-响应模型将抽象的质量属性如可修改性、性能、安全性等转化为包含具体角色、条件、对象、行动和验收标准的实例。这种描述方法使质量需求变得具体、可评估、可测试是架构设计与评估的重要沟通与验证工具。12.1.3 质量属性场景描述 - 可修改性场景实例可修改性质量属性场景描述实例下表展示了一个完整的、用于描述“可修改性”质量属性的通用场景模板。它通过定义场景的六个要素及其可能的具体情况为评估系统的可修改性提供了清晰的分析框架。场景要素可能的情况 / 描述刺激源最终用户、开发人员、系统管理员刺激希望增加、删除、修改、改变功能、质量属性、容量等环境系统设计时、编译时、构建时、运行时制品系统用户界面、平台、环境或与目标系统交互的系统响应查找架构中需要修改的位置进行修改且不会影响其他功能对所做的修改进行测试部署所做的修改响应度量根据所影响元素的数量度量的成本、努力、资金该修改对其他功能或质量属性所造成影响的程度实例应用说明此模板定义了评估系统“可修改性”时需考虑的核心维度。在实际分析中可根据具体变更需求刺激选择或组合“可能的情况”来构建一个具体的评估场景。例如当“开发人员”刺激源在“编译时”环境希望“增加一个新功能”刺激时评估其“响应”如定位、修改、测试的难易程度和“响应度量”如修改所影响的代码模块数、所需人天即可形成一个具体的可修改性评估用例。12.1.3 质量属性场景描述质量属性场景主要用于描述和定义系统的特定质量需求。它主要关注以下六类质量属性并明确了每类属性在场景描述中需要考察的核心方面。质量属性场景主要关注点可用性系统故障发生的频率、故障发生时的表现、允许系统非正常运行的时间长度、何时可以安全地出现故障、如何防止故障发生以及故障发生时的通知要求。可修改性系统在改变功能、质量属性时需要付出的成本和难度。此类场景可能发生在系统设计、编译、构建、运行等多种情况和环境下。性能系统的响应速度可通过效率、响应时间、吞吐量、负载等指标客观评价性能的好坏。可测试性系统测试过程中的效率以及发现系统缺陷或故障的难易程度。易用性用户使用系统时的容易程度包括系统的学习曲线、完成操作的效率、用户对使用过程的满意程度等。安全性系统在向合法用户提供服务的同时阻止非授权用户使用的能力。总结质量属性场景是一种结构化的需求描述方法它将抽象的、非功能性的质量要求如“系统要可靠”、“界面要友好”转化为针对具体属性、包含明确关注点的、可评估和验证的具体场景从而为架构设计和测试提供明确的依据。12.2 系统架构评估12.2.1 系统架构评估中的重要概念1. 系统架构评估定义系统架构评估是在对架构分析、评估的基础上对架构策略的选取进行决策的过程。2. 三个核心概念(1) 敏感点与权衡点核心定义是关键的架构决策。敏感点指为了实现某种特定的质量属性一个或多个构件所具有的特性。权衡点是影响多个质量属性的特性是多个质量属性的敏感点。典型示例 (加密级别)提高加密级别可以提高安全性但可能需要耗费更多的处理时间从而影响性能。如果对机密消息的处理有严格的时间延迟要求则加密级别就可能成为一个权衡点。(2) 风险承担者 (利益相关人)核心定义系统的架构涉及很多人的利益这些人都对架构施加各种影响以保证自己的目标能够实现。核心角色 - 软件系统架构师是风险承担者之一。职责是负责在软件架构的质量需求间进行权衡。所关心的问题是对其他风险承担者提出的质量需求进行折中和调停。(3) 场景核心作用在进行架构评估时一般首先要精确地得出具体的质量目标并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制称之为场景。核心描述是从风险承担者的角度对与系统的交互所做的简短描述。在架构评估中一般采用刺激、环境和响应三方面来对场景进行描述。总结理解敏感点/权衡点有助于识别关键设计决策明确风险承担者及其目标特别是架构师的调和角色是评估的社会维度运用场景则是将抽象的质量目标具体化、可评估化的核心方法。三者共同构成了进行有效架构评估的基础认知框架。12.2.1 系统架构评估中的重要概念1. 评估的时间点与目的时间点系统架构评估通常位于架构设计之后系统设计之前。关联性因此它与后续的设计、实现、测试阶段没有直接关系。核心目的评估所采用的架构是否足以解决软件系统的需求。2. 系统架构评估的三种方法评估方法核心特点与描述关键要素/备注(1) 基于调查问卷或检查表的方法类似于需求获取中的问卷调查但侧重于架构方面。要求评估人员必须对评估的领域非常熟悉。(2) 基于场景的评估方法主要方法。通过分析架构对特定场景使用或修改活动的支持程度来判断其对质量需求的满足度。场景设计三要素1.刺激事件2.环境事件发生条件3.响应架构应对过程应用ATAM架构权衡分析方法、SAAM软件架构分析方法。(3) 基于度量的评估方法制定定量指标如代码行数来直接度量架构。核心活动1. 建立质量属性与度量间的映射原则2. 从文档中获取度量信息3. 分析推导出系统质量属性。要求评估人员需对架构熟悉。12.2.2 系统架构评估方法1. 基于场景的架构分析方法 SAAMSAAM (Software Architecture Analysis Method) 是一种针对非功能质量属性的架构分析方法是最早形成文档并得到广泛使用的软件架构分析方法。(1) 特定目标对描述应用程序属性的文档进行审查以验证基本的架构假设和原则。(2) 评估技术采用的核心技术是场景技术。场景代表了描述架构属性的基础详细描述了各种系统必须支持的活动和可能存在的状态变化。(3) 质量属性该方法的基本特点是把任何形式的质量属性都具体化为场景。可修改性是 SAAM 分析的主要质量属性核心关注点。(4) 风险承担者SAAM 旨在协调不同参与者风险承担者之间感兴趣的共同方面。作为后续架构决策的基础以达成对架构的共识。(5) 架构描述时间点SAAM 通常在架构的最后版本确定后使用但早于详细设计阶段。形式要求架构的描述形式应当被所有参与者理解。描述维度架构的功能、结构和分配被定义为描述架构的 3 个主要方面。(6) 方法活动主要输入问题描述、需求声明和架构描述。分析流程SAAM 分析评估架构的过程包括以下 5 个步骤场景开发架构描述单个场景评估场景交互评估总体评估逻辑关系“场景开发”通过迭代生成“体系结构描述”。“单个场景评估”与“场景交互评估”通过逻辑或OR汇聚为“单个体系结构评估”。结合比较多个体系结构的需求最终输出“总体评估”。(7) 已有知识库的可重用性SAAM不考虑这个问题。(8) 方法验证SAAM 是一种成熟的方法已被广泛应用到众多系统中包括但不限于空中交通管制系统嵌入式音频系统WRCS修正控制系统KWIC根据上下文查找关键词系统12.2.2 系统架构评估方法2. 架构权衡分析方法 ATAMATAM (Architecture Tradeoff Analysis Method) 是在 SAAM 的基础上发展起来的主要针对性能、安全性、可修改性和可用性在系统开发之前对这些质量属性进行评价和折中。核心目标与参与者核心目标让架构师明确如何权衡多个质量目标。主要参与者评估小组、项目决策者和其他项目相关人。四大活动领域ATAM 被分为四个主要的活动领域整个评估过程强调以质量属性作为架构评估的核心场景和需求收集体系结构视图和场景实现属性模型构造和分析折中ATAM 分析评估过程九步法ATAM 的评估过程通常分为四个阶段共包含九个具体步骤阶段1场景和需求收集收集场景收集需求约束环境阶段2体系结构视图和场景实现3. 描述体系结构视图4. 实现场景阶段3属性模型构造和分析5. 特定属性分析优秀的分析理论阶段4折中6. 标志敏感度7. 标志折中8. 产生分析最终输出形成行动计划12.2.2 系统架构评估方法2. 架构权衡分析方法 ATAM续补充ATAM 方法的评估实践阶段划分用 ATAM 方法评估软件架构其工作分为 4 个基本阶段即演示、调查和分析、测试和报告。(1) 阶段1演示Presentation这是使用 ATAM 评估软件体系结构的初始阶段。① 介绍 ATAM描述 ATAM 的评估过程。② 介绍业务驱动因素着重业务视角提供有关系统功能、主要利益相关方、业务目标和其他限制等信息。③ 介绍要评估的体系结构侧重可用性以及体系结构的质量要求。(2) 阶段2调查和分析Investigation and Analysis在这个阶段人们对评估期间需要重点关注的一些关键问题进行彻底调查。① 确定架构方法涉及能够理解系统关键需求的关键架构方法。② 生成质量属性效用树确定最重要的质量属性并确定有限次序。③ 分析体系结构方法彻底调查和分析找出处理相应质量属性架构的方法。包括4个主要阶段调查架构方法 - 创建分析问题 - 分析问题的答案 - 找出风险、非风险、敏感点和权衡点。(3) 阶段3测试① 头脑风暴和优先场景将头脑风暴的优先列表与生成质量属性效用树中所获取的优先方案进行比较。② 分析架构方法。(4) 阶段4报告 ATAM提供评估期间收集的所有信息呈现给利益相关者。12.2.2 系统架构评估方法质量属性效用树 (Utility Tree)ATAM 方法采用效用树Utility tree这一工具来对质量属性进行分类和优先级排序。效用树的结构树根质量属性下一层属性分类叶子节点质量属性场景ATAM 主要关注的质量属性ATAM 主要关注以下 4 类质量属性因为这 4 个质量属性是利益相关者最为关心的性能 (Performance)安全性 (Security)可修改性 (Modifiability)可用性 (Usability)12.2.2 系统架构评估方法3. 成本效益分析法 CBAM基本概念全称Cost-Benefit Analysis Method。基础在 ATAM 的基础上构建。核心目的对架构设计决策的成本和收益进行建模让决策者根据投资回报率 (ROI)来选择合适的架构。应用时机在 ATAM 确定质量合理的基础上再对效益进行分析。分析流程8个步骤整理场景确定场景并确定优先级。选择优先级最高的1/3场景进行分析。对场景进行细化对每个场景进行详细分析。确定最好、最坏的情况。确定场景的优先级项目干系人对场景投票。根据投票结果生成场景的权值。分配效用对场景响应级别确定效用表。建立策略、场景、响应级别的表格。形成“策略-场景-响应级别”的对应关系使用内插法确定期望的质量属性响应级别的效用根据效用表确定所对应的具体场景的效用表。计算各架构策略的总收益根据受成本限制影响的投资回报率 ROI 选择架构策略估算成本。用上一步的收益减去成本计算 ROI 并排序。从而选择收益最高的架构策略。中间件1. 定义中间件是指在一个分布式系统环境中处于操作系统和应用程序之间的系统级软件。它可以在不同的技术之间共享资源将不同的操作系统、数据库、异构的网络环境以及若干应用结合成一个有机的协同工作整体。2. 位置与特点中间件位于客户机/服务器的操作系统之上管理计算机资源和网络通信。(1) 软件类别中间件是一类软件而非一种软件。(2) 核心功能不仅仅实现互连还要实现应用之间的互操作。(3) 架构特性基于分布式处理的软件最突出的特点是其网络通信功能。3. 任务中间件的任务是使应用程序开发变得更容易通过提供统一的程序抽象隐藏异构系统和分布式系统下低级别编程的复杂度。4. 架构图示分层结构顶层应用...中间层中间件分布式系统服务底层操作系统...、网络、数据库5. 支持的两方面内容中间件提供的支持通常包括两方面(1) 交互支持作用协调系统中不同组件之间的通信和数据交换。机制消息队列远程过程调用RPC对象请求代理ORB目的实现分布式环境中的进程间通信IPC。优势使得应用程序不必关心底层网络细节能够更专注于业务逻辑。(2) 提供公共服务服务内容中间件提供对服务的可复用的实现如事务管理安全服务命名和目录服务持久化服务负载均衡故障恢复和容错能力等。解决问题有助于解决分布式系统中常见的问题如一致性、可用性和伸缩性。中间件中间件的功能负责连接与通信负责客户机与服务器之间的连接和通信。负责客户机与应用层之间的高效率通信机制。提供互操作与控制机制提供应用层不同服务之间的互操作机制。提供应用层与数据库之间的连接和控制机制。提供开发与运行平台提供多层架构的应用开发和运行的平台。提供应用开发框架支持模块化的应用开发。屏蔽底层差异屏蔽硬件、操作系统、网络和数据库的差异。提供高级管理与安全功能提供应用的负载均衡和高可用性。提供安全机制与管理功能。提供交易管理机制保证交易的一致性。提供通用服务提供一组通用的服务去执行不同的功能。避免重复的工作使应用之间可以协作。中间件中间件的分类通信处理消息中间件功能保证系统能在不同平台之间通信利用消息传递机制实现分布式系统中可靠的、高效的、实时的跨平台数据传输。示例IBM 的 MQSeries。事务处理交易中间件功能实现协调处理顺序、监视和调度、负载均衡等功能。示例BEA 的 Tuxedo。数据存取管理中间件功能为不同种类数据的读写和加解密提供统一的接口。示例Windows 平台的 ODBC 和 Java 平台的 JDBC 等。Web 服务器中间件功能提供 Web 程序执行的运行时容器。示例Tomcat、JBOSS 等。安全中间件功能用中间件屏蔽操作系统的缺陷提升安全等级。示例Kerberos、SSL/TLS。跨平台和架构的中间件功能用于开发大型应用软件。示例CORBA、JavaBeans、COM模型。专用平台中间件功能为解决特定应用领域的开发设计问题提供构件库。示例Android SDK、iOS SDK。网络中间件功能包括网管、接入、网络测试、虚拟社区和虚拟缓冲等也是当前最热门的研发项目。示例TCP/IP协议栈、HTTP服务器。13.1 软件可靠性基本概念-13.1.1 软件可靠性定义1. 软件可靠性定义软件可靠性Software Reliability是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。2. 软件可靠性和硬件可靠性区别(1) 复杂性软件复杂性比硬件高。大部分失效来自于软件失效。(2) 物理退化软件不存在物理退化现象。硬件失效主要是由于物理退化所致。(3) 唯一性软件是唯一的每个复制版本都一样。两个硬件不可能完全一样。(4) 版本更新周期硬件较慢。软件较快。13.1.2 软件可靠性的定量描述1. 规定时间自然时间运行时间执行时间占用CPU2. 失效概率软件运行初始时刻失效概率为0随着时间增长单调递增不断趋向于1。3. 可靠度定义软件系统在规定的条件下、规定的时间内不发生失效的概率。计算公式等于1 - 失效概率。4. 失效强度单位时间软件系统出现失效的概率。5. 平均失效前时间 (MTTF)定义平均失效等待时间即系统从开始运行到发生第一次故障所经历的平均时间。6. 平均恢复前时间 (MTTR)定义平均修复时间即从出现故障到修复成功的时间。7. 平均故障间隔时间 (MTBF)
