1、软件构架实践教案本课程上课时间为 16 周，每周讲解一个主题第一周 构架商业周期学生开课的第一周，除了讲解专业知识之外，首先要简单介绍关于这本书的背景知识，让学生对这门课有所了解，增强其学习的兴趣；然后说明学习这门功课的意义以及教学安排；最后讲解构架商业周期的概念。第一堂课直接涉及的专业知识不要太多，否则学生会囫囵吞枣，也达不到教学的目的软件构架实践这本书是 CMU/SEI（卡内基.梅隆大学/软件工程研究所）编写的软件工程系列丛书之一，SEI（Software Engineering Institute）于 1984 年由美国国防部出资建立，其主要工作是研究软件过程能力成熟度模型（Capabi
2、lity Maturity Model, CMM） ，其目的使开发组织开发“正确的”和“无缺陷”的程序。CMM 已经成为衡量软件公司开发管理水平的重要参考因素，并成为软件过程改进的事实标准。学习本书的目的是:1、了解构架的基本概念2、了解保证软件构架正确的各种质量属性（Quality Attributes）和实现这些质量属性的战术（Tactics）3、学会创建软件构架的方法和评估的方法4、把学到的知识运用到将来的开发中去构架商业周期 软件构架是技术、商业和社会诸多因素作用的结果，而软件构架的存在反过来又会影响技术、商业和社会环境，从而影响到未来的构架。我们把这种相互影响的周期从环境到构架又返回
3、环境称为构架商业周期（Architecture Business Cycle, ABC） ，商业构架周期是本书的核心内容，所有的例子都围绕 ABC 展开。从构架商业周期的概念我们可以看出，构架与之交互的外界环境之间存在着密切的关系，他们相互影响，相互作用，相互促进。一方面构架受到多种因素的影响：1、涉众的影响；2、构架开发组织的影响；3、构架设计师素质和经验的影响； 4、技术环境的影响；5、其他影响因素。另一方面，环境反过来又会对构架的形成和发展产生影响：1、影响着开发组织的结构；2、影响着开发组织的目标；3、影响客户对下一个系统的要求；4、影响着构架设计师；5、构架影响着软件工程的发展第二周
4、 什么是软件构架首先简单介绍软件构架形成的背景和过程，然后通过一个简单线框图的例子引入软件构架的概念：某个软件或计算机系统的软件构架是该系统的一个或多个结构，他们由软件元素，这些元素之间的外部可见属性和这些元素之间的关系组成。我们要得到最终的构架需要一个循序渐进的过程，在最粗略的线框图和构架之间有很多中间步骤，逐步求精得到真正意义上的构架，这些中间步骤包括：1、构架模式是对元素和关系类型以及一组对其使用方式的限制的描述，我们可以把它看作是对构架的一组制约条件即对各元素类型及其交互模式的限制条件，而这些制约条件确定了一组或一系列能满足他们要求的构架，比如，客户机/服务器构架模式。构架模式最重要的
5、作用是它们展示了已知的质量属性。2、参考模型是一种考虑数据流的功能划分，它对已知问题进行分解，分解得到的各个部分相互协作，构成问题的解决方案3、参考构架是映射到软件元素及元素之间数据流上的参考模型三者之间的关系是：图 软件构架及其中间过程之间的关系软件构架对于一个系统而言，具有极其重要的意义，包括：1、软件构架是涉众之间交流的手段2、软件构架是系统的早期设计决策3、软件构架是可传递的系统抽象为了能够清晰的表达构架，我们引入了如下两个概念：参考模型构架模式参考构架 软件构架视图 视图是构架元素内聚集的表述，由系统涉众编写和阅读，它由一个元素集合表示和元素之间的关系组成，用于表示构架中的某个结构结
6、构 结构是元素本身的集合，他们存在于软件和硬件中，比如，模块结构是系统的模块和其组织的结构，模块视图是该结构的表示我们使用视图和结构来表示系统的构架，构架结构根据元素的主要特性可以分为三类：1、模块结构：表示一种考虑系统的基于代码的表示方法2、组件连接器结构：展示了软件运行是各个部分之间的交互3、分配结构：展示了软件元素和创建并执行软件的一个或多个外部环境中的元素之间的关系图 常见的软件构架结构第三周 A-7E 案例分析各种构架结构的运用A-7E 航空电子系统项目的开发主要展示了 3 种不同构架结构在一个系统中的作用和表述。该项目的目的：通过该项目的开发证实软件工程的理论研究成果适用于需求灵活
7、、内存占用少、开发时间短的软件系统，其指导思想：留下一个完整的工程模型，把相关的文档、设计方案、代码、方法和原则都公之于众，供相关人员模仿使用。从该项目的开发中获得了以下两条经验：1、信息隐藏是软件开发中可行的和明智的设计准则2、从实现系统质量指标的角度看，认真设计构架层次上的各种结构可以达到事半功倍的效果模块分解 类使用分层组件-连接器客户机/服务器共享数据并发进程模块工作分配实现部署图 A-7E 航空电子系统的构架商业周期构建 A-7E 系统构架时，设计并确定了构架层次上的 3 个结构结构 元素 元素间的关系 影响对象分解结构 模块 是一个子模块，共享秘密 更改容易程度使用结构 过程 要求
8、正确出现 实现子集和增量式开发的能力进程结构 进程、线程 同步、互斥，共享 CPU 可调度性；可并行实现性能目标A-7E 软件所满足的质量目标包括：1、实时性能，软件系统每秒钟显示内容的更新次数和武器投放的计算速度2、针对期望更改的可修改性，对武器、平台、显示屏上符号的变更，以及通过键盘数据新的内容容易更改A-7E 软件的三个结构分解结构将系统的功能划分为可以独立实现的模块，模块划分的具体目标：1、每个模块结构应足够简单，能够被充分理解2、应该能够在无需了解其他模块的具体实现，并且不影响其它模块的行为的情况下修改某个模块的实现3、对设计进行修改的容易程度应该与该修改可能发生的程度有合理的对应关
9、系4、应该能够把要对软件系统做的比较大的改动分解成对各个模块的一组独立的修改A-7E 软件的一级模块结构包括：硬件隐藏模块、行为隐藏模块和软件决策模块。使用结构的思想是建立在使用关系的基础上的。如果过程 A 的运行必须以过程 B 的正确运行为前提，则我们说过程 A 使用过程 B图 使用结构的分层图进程结构是以一组协同顺序的进程来实现的，这些协同顺序进程保持同步关系、以协调对共享资源的使用第四周 理解构架质量属性（上）我们开发一个系统是为了给用户使用，因此系统的质量好坏最终要由用户来评判。评判的依据：1、系统是否能够满足客户的功能需求（直接）2、系统是否能够满足一定的质量需求（间接，长期的影响）
10、功能性（functionality）是指系统能够完成所期望的工作的能力质量属性（quality attributes）是高于系统功能基本要求的，它是对多种更高层次需求的抽象描述，如安全、可靠、易用及易于修改等，显然它适用于多个特定系统而非一个。构架是实现质量需求的软件创建中的第一阶段，软件构架确定了该构架对特定质量属性的支持，比如实时性，安全性等。构架和质量属性的关系：1、对我们关心的许多系统质量属性的实现而言，构架具有重要意义FD：功能驱动模块SS：共享服务模块AT：应用数据类型模块EC：扩展的计算机模块DI：设备接口模块2、对一个构架而言，往往只支持某些质量属性3、构架并不能独立实现质量属
11、性，它为质量属性的实现提供了基础，但不是全部实际上，构架之所以重要，就是因为它能够保证设计系统的质量属性。质量属性是一个较为抽象的概念，为了能够清晰的表达质量属性，我们使用了质量属性场景的概念。质量属性场景（scenarios）是描述质量属性的手段，是一种面向特定的质量属性的需求，质量属性场景由以下 6 个部分组成：1、刺激源（Source of stimulus）：生成刺激的实体（人、计算机或其他）2、刺激（Stimulus）：当刺激源产生的刺激达到系统后需要考虑的条件，或指可能对系统的影响3、环境（Environment）：刺激到达时系统的状态，或指刺激在系统的某些条件内发生4、制品（Ar
12、tifact ）：被刺激的部分，可能是整个系统，也可能是其中的一部分5、响应（Response）：刺激到达后系统所采取的措施6、响应度量（Response measure）：当响应发生时，我们以某种方式对其进行度量，便于我们对需求进行测试一般质量属性场景是指那些独立于系统，很可能适合任何系统的场景，一般场景的集合描述了质量属性具体质量属性场景是指适合正在考虑的某个特定系统的场景图 质量属性、质量属性场景和系统的关系本书主要讨论 6 个质量属性及其一般场景：1、可用性（Availability） ，2、可修改性（Modifiability） ，3、性能（ Performance） ，4、安全性（
13、 Security） ，5、可测试性（Testability） ， 6、易用性（Usability）通用系统质量属性可修改性性能安全性一般质量属性场景特定系统质量属性抽取 特定系统组合1、可用性（Availability ）可用性与系统故障及其相关后果有关。当系统不再提供其规范中所说明的服务时，就出现了系统故障。可用性关注的问题：如何检测故障，发生故障的频度，出现故障时的现象，系统故障排除的时限，如何防止故障的发生以及发生故障时的处理图 可用性的一般场景2、可修改性（Modifiability）可修改性是关于变更的成本问题，可修改性包括两个关注点：1、可以修改什么？如修改系统功能、系统运行的平
14、台和环境、系统容量、质量属性等2、何时进行变更以及由谁进行变更？修改时间包括设计时修改（源代码） 、编译时修改（编译条件） ，部署时修改（系统配置）等第五周 理解构架质量属性（下）3、性能（Performance ）性能与事件发生时，将要耗费系统多长时间做出响应有关。影响性能的因素包括：事件源的数量和达到模式，到达系统的事件包括：周期性事件、随机事件或偶然事件性能的一般性场景场景部分 可用的值刺激源 大量独立源中的一个，可能来自系统内部刺激 定期、随机或偶然事件到达制品刺激源：刺激：制品：响应：响应度量：环境：内部、外部（错误）忽略、崩溃、时间、响应进程、存储、处理器、通信正常、降级操作记录、
15、通知、禁止、继续（正常/降级）或不可用修复时间、可用性、可获得/降级的时间间隔环境 正常模式；超载模式响应 处理刺激；改变服务级别相应度量 等待时间、时间期限、吞吐量、抖动、缺失率、数据丢失4、安全性（Security ）安全性是衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力安全性被刻画为一个提供认可（交易不能被交易的任何一方拒绝） 、机密性（未经授权不能访问数据或服务） 、完整性（根据计划来提交数据或服务） 、保证（交易各方是所声称的人） 、可用性（系统可用于合法用途）和审核（在系统内部跟踪系统活动）的系统安全性的一般性场景场景部分 可用的值刺激源 授权或非授权用户；访问了有限的资
16、源/大量资源刺激 试图修改数据，访问系统服务制品 系统服务、系统中的数据环境 在线或离线、直接或通过防火墙入网响应 对用户验证，阻止或允许访问数据或服务相应度量 避开安全措施所需要的时间或资源；恢复数据/服务5、可测试性（Testability）可测试性是指通过测试揭示软件缺陷的容易程度。如果要对系统进行正确的测试，那么必须能够“控制”每个组件的内部状态及其输入，然后“观察”其输出，测试可以由开发人员、测试人员、验证人员或用户进行；可以对代码、设计以及整个系统进行测试可测试性的一般性场景场景部分 可用的值刺激源 单元开发人员、系统集成人员、系统验证人员、测试人员、用户刺激 已完成的一个阶段，如
17、分析、构架、类和子系统的集成，所交付的系统制品 设计、代码段、完整的应用环境 设计时、开发时、编译时、部署时响应 可以控制系统执行所期望的测试相应度量 已执行的可执行语句的百分比；最长测试链的长度，执行测试的时间，准备测试环境的时间6、易用性（Usability）易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持种类。包括如下几个方面：1、学习系统的特性，2、有效地使用系统，提高用户操作效率，3、将错误的影响降到最低，4、使系统适应用户的需要，5、提高自信和满意度。易用性的一般性场景场景部分 可用的值刺激源 最终用户刺激 想要学习系统特性、有效使用系统、使错误的影响最低，
18、适配系统等制品 系统环境 在运行时或配置时响应 上下文相关的帮助系统，导航，撤销、取消操作，从系统故障中恢复，国际化，定制能力相应度量 任务时间，错误数量，用户满意度等本章除了讲述上面 6 种质量属性之外，还对商业质量属性和构架本身的质量属性作了介绍，以下是我们所关心的商业目标：1、上市时间2、成本和收益3、所希望的系统生命期的长短4、目标市场，通用市场还是专用市场5、推出计划6、与老系统的集成构架的质量属性包括：1、概念完整性，在各个层次上统一系统设计的根本指导思想2、正确性和完整性，是构架能够满足系统的各种需求及运行时的资源要求的必要条件3、可构建性，保证能够由指定的开发小组在规定的时间里
19、及时开发系统，并允许在开发过程中做某些更改，其目的是最大程度地实现并行开发第六周 实现质量属性（上）质量属性对于一个软件系统而言至关重要，那么我们如何来实现这些质量属性呢？首先我们来了解一些基本概念战术（tactics） 影响质量属性响应的设计决策构架策略（architectural strategy） 战术的集合构架模式（architectural pattern） 以某种方式将战术打包在一起战术是帮助我们实现质量属性的策略，下面我们就对每一种质量属性所采用的战术进行讨论1、可用性（Availability ）可用性战术将会阻止错误发展为故障，或者至少能够把错误的影响限制在一定范围内，从而使
20、修改成为可能。维持可用性的方法包括：1、错误预防某种类型的冗余2、错误检测用来检测故障的某种类型的健康监视3、自动恢复检测到故障时某种类型的恢复图 可用性战术2、可修改性（Modifiability）可修改性战术的目标是控制实现、测试和部署变更的时间和成本。根据其实现目标可可用性错误 所屏蔽的错误或所作的修改错误检测 恢复：监测和修复预防命令/响应心跳异常表决主动冗余被动冗余备件Shadow状态再同步回滚从服务中删除事物进程监视器恢复：重新引入以分为 3 组：1、局部化修改目标是减少由某个变更直接影响的模块的数量2、防止连锁反应目标是限制对局部化的模块的修改，以防止对某个模块的修改间接地影响到
21、其他模块3、延迟绑定时间目标是控制部署时间并允许非开发人员进行修改图 可修改性战术第七周 实现质量属性（下）3、性能（Performance ）性能战术的目标是对一定的时间限制内到达系统的事件生成一个响应，这些事件可以使消息到达、定时器到时，系统状态的变化。性能战术包括 3 个分类：1、资源需求分析影响性能的资源因素2、资源管理提高资源的应用效率3、资源仲裁解决资源的争用可修改性变更到达在时间和预算内实现、测试和部署的变更局部化变更 防止连锁反应语义一致性预期期望的变更泛化模块限制可能的选择抽象通用服务隐藏信息维持现有的接口限制通信路径使用仲裁者运行时注册配置文件多态组件更换遵守已定义的协议推
22、迟绑定时间事件到达在时间限制内生成响应性能资源需求 资源管理提高计算效率减少计算开销管理事件率控制采样频率引入并发维持多个副本增加可用资源调度策略：先进/先出固定优先级动态优先级静态调度资源仲裁4、安全性（Security ）安全性战术包括抵抗攻击的战术、检测攻击的战术和从攻击从恢复的战术图 安全性战术5、可测试性（Testability）可测试性战术的目标是允许在完成软件开发的一个增量后，轻松地对软件进行测试。测试的目标是发现错误图 可测试性战术6、易用性（Usability）易用性与用户完成期望任务的难易程度以及系统为用户提供的支持种类有关攻击 系统检测、抵抗或从攻击中恢复安全性抵抗攻击
23、检测攻击身份验证用户授权数据加密数据完整性限制暴露限制访问入侵检测从攻击中恢复恢复 识别冗余 审计追踪一个增量开发完成检测出错误可测试性管理输入/输出记录/回放将接口与实现分离特化访问路线/接口内部监视内置监视器用户请求 为用户提供适当的反馈和协助易用性分离用户接口支持用户主动取消撤销聚合用户模型用户模型系统模型任务模型图 易用性战术战术与构架模式的关系：战术用于响应某个特定的系统质量属性；构架模式是将战术以某种方式进行打包，以一个战术的集合来支持某种构架。比如，一个系统支持可用性和性能，那么我们可能会考虑冗余战术、同步战术、并发战术等等，这些特定于一类系统的战术集合我们称之为构架模式第九周设
24、计构架构架和质量属性之间是相互相成的，我们学习质量属性是为了更好地设计我们的构架，构架反过来又保证质量属性的实现。任何一个好的系统都具有的两个特性：1、存在一个强大的构架构想2、应用管理良好的迭代式增量开发周期演变交付生命期模型使开发的软件系统具有上述两个特征功能、质量和商业需求的某个集合塑造了构架。我们把这些塑造需求称为构架驱动因素我们这里讲解的构架设计方法就是属性驱动的设计方法（Attribute Driven Design, ADD） ，该方法可以用于设计一个满足一定质量需求和功能需求的构架ADD 把一组质量属性场景作为输入，并使用对质量属性实现和构架之间的关系的了解，对构架进行设计。A
25、DD 设计的结果是构架的模块分解视图和其他视图的最初几个层次。ADD 方法的步骤1、选择要分解的模块2、根据下面的步骤对模块进行求精a、从具体的质量场景和功能需求集合中选择构架驱动因素b、选择满足构架驱动因素的构架模式，根据用来实现驱动因素的战术创建模式c、实例化模块并根据用例分配功能，使用多个视图进行表示d、定义子模块的接口。该分解提供了模块和对模块交互类型的限制e、验证用例和质量属性场景并对其进行求精，使它们成为子模块的限制3、对需要进一步分解的每个模块重复上述步骤在构架的模块分解结构的最初几个层次稳定后，就可以把这些模块分配给开发小组，这就是工作分配视图，分配任务的原则：1、开发小组内部
26、是高内聚，外部是松耦合2、根据开发小组的特长进行分配3、尽量与模块的分界原则一致在使用 ADD 方法完成了系统的构架设计之后，就可以构建系统的骨架系统了。本章通过一个车库门系统设计的例子来加强对 ADD 构架设计方法的理解。第十一周 构架编档我们为系统设计的构架起到涉众之间交流的作用。为了得到我们的最终构架以及方便涉众之间的交流，我们需要对设计的构架进行编档。构架编档（Documenting Software Architectures）是对构架的描述，构架必然存在，构架编档不一定存在；构架的建立源于系统的需求，构架文档的编写源于构架描述、交流的需求，构架编写的基本规则是：从读者的角度进行编写
27、构架编档既然如此重要，我们该如何对构架进行编档呢？构架编档包括如下三部分内容：1、视图编档；2、接口编档；3、视图的组织下面就分别对这三部分对容进行详细介绍一、视图编档视图（View）就是构架元素的内聚集合的表示，由系统涉众编写和阅读；软件构架（Software Architecture）是由多个视图构成，并且表示了这些视图之间的关系。构架编档就是将相关视图编成文档，然后向其中添加适合多个视图的文件。我们需要对软件构架中的每一个视图进行编档，每个编档视图通常包含 7 部分的内容：1、展示视图中的元素和元素间关系的主要表示2、使用元素目录描述在主要表示中所描述的元素和他们之间的关系及其他。在这一
28、部分内容中我们将对元素的行为和元素接口进行描述3、展示在视图中描述的系统的环境相关上下文4、可变性指南展示了如何应用该视图中所展示的构架的一部分的任何变化点，应该包含每个变化点的文档5、解释视图中所反映的设计合理性的构架背景，包括：基本原理，分析结果，设计中所反映的假定6、视图中所使用的术语表7、其他信息，如管理信息等二、 、视图编档接口（Interface ）是两个独立的实体相遇并进行交互或通信的边界，由于接口展示了软件元素之间的交互关系，对于软件构架而言非常重要，因此需要对构架中的接口单独编档，接口编档属于视图编档的一部分内容。对接口进行编档就是在暴露太少信息和太多信息之间达到一个平衡，经
29、验就是把重点放在元素如何与其操作环境进行交互上，而非放在其实现方式上。接口文档的模板包括 9个部分的内容：1、接口身份，通常是接口命名2、所提供的资源，这是接口文档的核心，包括资源语法、语义和资源使用的限制3、数据类型的定义4、异常定义，描述可以由接口上资源引发的异常5、该接口提供的可变性，可变性示例包括可见数据结构的容量以及基础算法的性能等6、接口的质量属性特征，可以把接口元素的质量属性特征编成文档7、元素需求，可能是具体的、由其它元素提供的已命名资源8、基本原理和设计问题，对整个构架的基本原理、设计的动机、限制和折衷进行描述9、使用指南三、视图的组织视图组织是使视图文档完整所必需的。尽管我
30、们为软件构架中的每个视图和使用到的接口进行了编档，但是他们是零散的，涉众不容易从中找出所需要的信息。那么我们如何将这些分散的视图通过一定的方式组织起来呢？这就是视图组织，它由 3 个主要方面组成：1、如何安排和组织构架文档，以使构架的涉众能够有效可靠地找到所需要的信息，这部分的内容包括对视图目录（view catalog）与视图模板（ view template）的介绍视图目录（view catalog ）是对视图的介绍性信息，它告诉读者在什么地方找到需要的信息。视图模板（view template）是视图的标准组织结构，它定义了视图文档的标准部分以及每一部分的内容和规则2、阐述构架是什么？它
31、能够使涉众从整体上了解系统的目的，视图的关联方式等，这部分的内容包括：系统概述，视图之间的映射，元素列表和项目词汇3、说明为什么构架是这样的，它阐明了系统的上下文。构架实际上是其需求的一个解决方案，包括的内容有：关于满足需求和限制的设计决策的含义；当改变现有需求时对该构架的影响；在实现解决方案中对开发人员的限制；拒绝采用的决策方案等第十二周 ATAM 构架评估方法我们设计的构架是否正确，是否满足设计目标和要求？要回答这些问题，就需要进行构架评估。构架评估能够起到规避风险的作用，在我们的构架设计完成后需要尽早进行评估。ATAM（Architecture Tradeoff Analysis Met
32、hod ）构架权衡分析方法：这种方法不仅可以揭示出构架满足特定质量目标的情况，而且可以使我们更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。ATAM 构架评估包括以下三方面的内容一、评估人员组成1、评估小组：该小组是所评估构架项目外部的小组，通常由 35 人组成。该小组的每个成员都要扮演大量的特定角色。他们可能是开发组织内部的，也可能是外部的。任何时候，他们都应该是有能力、没有偏见而且私下没有其他工作要做的人员2、项目决策者对开发项目具有发言权，并有权要求进行某些改变，他们包括项目管理人员，重要的客户代表，构架设计师等。构架评估的一个基本准则就是构架设计师必须愿意参与评估3、构架涉众
33、完成工作的能力与支持可修改性、安全性、高可靠性等特性的构架密切相关。包括：开发人员、测试人员、集成人员、用户等二、ATAM 构架评估结果1、一个简洁的构架表述2、表述清楚的业务目标3、用场景集合捕获的质量属性4、所确定的敏感点和权衡点的集合5、有风险决策和无风险决策6、风险主题的集合敏感点（sensitivity points） 与某个质量属性相关的构架决策权衡点（tradeoff points ） 与多个质量属性相关的构架决策有风险决策（risk set） 根据所陈述的质量属性需求，可能导致不期望结果的构架决策无风险决策（nonrisk set） 根据分析被认为是安全的构架决策三、ATAM
34、构架评估的过程1、ATAM 评估包括 4 个阶段阶段 活动 参与人员 一般需要的时间1 关系和准备 评估小组负责人和主要的项目决策者 大约需要几周时间2 部分评估 评估小组和项目决策者 1 周，然后中断 2-3 周3 全体评估 评估小组、项目决策者以及涉众 2 天4 后续工作 评估小组和客户 1 周2、ATAM 评估的具体步骤包括以下八步：1） 、由评估负责人向参加会议的项目代表介绍 ATAM 评估方法，在这一步，要说明每个人将参与的过程，回答提出的问题，并为其他活动确定上下文和期望2） 、项目决策者从商业的角度介绍系统的概况，包括：系统最重要的功能；任何相关的技术、管理、经济和政治限制；与项
35、目相关的商业目标和上下文；主要的涉众；构架的驱动因素（主要质量属性目标）等 3） 、设计师使用各种视图来介绍构架的本质，促使形成构架的需求，构架受到的技术约束条件，以及系统与之交互的系统，构架方法、模式，采用的战术等4） 、ATAM 评估主要通过理解其构架方法来分析构架5） 、使用质量属性效用树对质量目标进行详细清晰地阐述。效用树的作用是使质量属性需求具体化，从而迫使设计师和客户代表准确地定义出他们将要提供的相关质量需求；效用树实际上就是使用最重要的质量属性场景来对质量属性进行讨论和评估。在这一步中还需要确定场景的优先级6） 、评估小组根据设计师的讲解分析每一个优先级高的场景，确定每个场景的敏
36、感点，权衡点，有风险和无风险决策等；评估小组为每一个场景生成一个评估表格上面的 6 个步骤由评估小组和项目决策者参加，下面的评估则增加了涉众的参与，这样能够得到更全面更合理的构架设计方案7） 、全体涉众确定进行评估的优先级8） 、全体涉众对每一个重要的质量属性场景进行讨论和提问。第十三周 CBAM 构架评估方法及软件产品线一、CBAM 构架评估方法ATAM 构架评估方法保证构架满足了我们设计目标中性能和质量属性的要求，但是对于商业软件系统而言，我们还需要对此构架生成系统的经济性进行评估，这就是 CBAM 评估。CBAM（ Cost Benefit Analysis Method）成本收益分析方
37、法是对软件系统进行经济建模的方法，它提供了对技术与经济问题以及构架决策的评估。相对于 ATAM 构架评估方法而言，CBAM 虽然为从经济的角度评估构架提供了一种方法原型，但不够成熟。另外，CBAM 评估以 ATAM 评估为基础，即它利用了 ATAM 评估方法得到的结果。CBAM 的基本思想：构架策略影响系统的质量属性，反过来这些质量属性又会为系统的涉众带来一定的收益，我们称该收益为效用。每个构架策略都为涉众提供了一特定级别的效用，同时，每个策略对应一个成本，我们将收益和成本的比值叫做 ROI（ Return on Investment）投资回报，CBAM 方法就是计算各种构架策略的 ROI，然
38、后协助涉众选择构架策略CBAM 使用场景来表达具体的质量属性，但是它不是使用一个单独的场景，而是通过改变响应值对某一质量属性生成一组场景，每个场景对应一个效用，那么一组响应值就对应一组效用，这样就形成了效用响应曲线图 几种不同的效用-响应曲线 通过以下几个值就可以描绘出效用- 响应曲线：1、最坏情况质量属性级别，效用为 02、最好情况质量属性级别，效用为 1003、当前效用级别，效用为 504、所期望的效用级别，效用为 905、对不同质量属性不同的响应生成不同的效用，这是一个根据响应得到的效用变化值有了效用-响应曲线，我们就可以计算各种构架策略的 ROI，从而为我们的构架决策提供一种经济上的依
39、据。对于每个构架策略而言，总收益为 Bi，总成本为 Ci，每个构架策略的 ROI 为 Ri，则：Ri = Bi / CiCBAM 评估方法的步骤：1、整理场景：确定场景的优先级，然后选择优先级最高的 1/3 场景2、对场景进行求精：确定该场景的最好情况、最坏情况、当前情况和期望情况的质量属性响应级别3、再次确定场景的优先级，只保留一半场景4、为每个场景的当前级别和期望级别分配效用5、为每个场景开发构架策略，并确定质量响应级别6、使用内插法确定所期望的构架策略效用值7、计算某个构架策略的总收益8、计算 ROI，根据 ROI 选择构架策略9、运用直觉来确认所得到的结果二、软件产品线：重用构架资产产
40、品线在制造业中得到广泛应用，包括汽车、飞机等大型设备的制造往往通过产品线来实现。1969 年，McIlroy 首先认识到了开创可重用软件组件行业的需要，但是，直到今天现在软件团体也没有实现这一目标。软件产品线（Software Product Lines） 一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足了某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集开发出来的，比如医学图像处理软件成功采用产品线能够带来的生产成本的降低、上市时间的缩短和生产效率的提高产品线的本质是在生产产品家族时，以一种规范的、策略性的方法重用资产产品线之所以有效，是因为可以通过重用充分利用产品的
41、共性，从而实现生产的经济性，可以重用的范围包括：1、需求：大多数需求与早期开发的系统相同，因此不再需要进一步的需求分析2、构架设计：已有成功系统的构架证明是合时的，设计产品线产品利用成功的构架可以节约大量的时间3、元素：软件产品的元素在产品线中是可重用的，包括元素接口、文档、测试计划等4、建模和分析：以前关于性能分析、可调度性分析等模型和分析均可重用5、测试：以前的测试计划、测试过程、测试用例、测试数据、测试工具均可重用6、过程、方法和工具等7、人员：开发相似系统的人员已经具有了开发此类系统的经验和技术积累8、样本系统：已开发系统可以作为新开发系统的样本9、缺陷消除：产品线可以提高产品质量，因
42、为以前的缺陷在新产品设计时可以避免 建立产品线构架在产品线的核心资产库中，软件构架是重中之重。构建一个成功产品线的本质就是区别在产品线家族所有成员中，什么会保持不变，什么会发生变化。确定产品的变化点和提供对这些变化点的支持是产品线构架的重要组成部分。产品线构架的评估重点应该放在产品线的变化点上，以确保：1、变化点是适当的，2、提供了足够的灵活性，从而能够覆盖产品线的预期范围3、支持快速构建产品4、不会产生不可接受的运行时性能成本导致产品线失败的因素尽管产品线的设计方法给我们带来很多好处，但不注意管理往往会造成产品线的失败1、在具有足够控制和管理权力的位置缺乏倡导者2、管理层未能持续提供坚定的支
43、持3、中层管理人员不愿放弃对项目的独立控制4、未能明确采用产品线方法的商业目标5、遇到困难就放弃6、未能就产品线方法对员工进行充分的培训，未能充分解释变化或进行变化的理由第十四周 用商业组件构建系统及未来的软件构架一、 用商业组件构建系统由于计算无处不在，因此使用外部开发的组件来实现某些系统目标的可能性大大提高，我们采用商业组件的原因包括：1、快速地构建系统2、专业知识的要求越来越高3、节约开发成本商业组件的应用改变了我们对系统构架的设计；除了最简单的组件外，所有组件都有一个很难违反的假定的构架模式。我们设计的构架需要满足组件的假定模式，因此，在理解选择组件的假定模式前，很难选择构架。商业组件
44、会带来构架不匹配的问题。构架不匹配（Architectural Mismatch）：不是专门针对您的系统开发的组件可能不会满足您的所有质量需求，它们甚至不会与您为之配对的组件协同工作，组件集成系统的这种现象被称为构架不匹配。构架不匹配是接口不匹配的特殊情况。即组件之间彼此的假设不合适应对接口不匹配的措施1、通过审查系统组件来避免接口不匹配2、通过对组件进行限定来检测没有避免的不匹配问题3、通过适配组件来修复不匹配问题修复接口不匹配的技巧一个明显的修复方法是改变不匹配的组件代码，但组件的源代码我们往往难于得到，一种替代的方案是在应用程序和组件之间插入一种修复不匹配的交互代码。有三类修复方式：包装
45、器、桥和中介器：1、包装器是将某个组件封装在一个可选的抽象中，而系统只能通过该包装器提供的替代接口访问已包装的组件服务。2、桥把任意一个组件的需求假设转换为另一个组件的提供假设；桥和包装器的区别在于组成桥的修复代码独立于任何特定的组件；桥必须由某个外部代理显示调用3、中介器展示了桥和包装器属性；桥和中介器的区别在于中介器集成了规定功能，具有足够的语义复杂性和运行时自适应性，以在软件构架中扮演角色三、 未来的软件构架从历史我们可以看到未来，编程的历史可以看作是为表达复杂的功能而不断增强的工具的历史，我们相信，未来的构架也是为了满足更加复杂系统的需要变得更加抽象图 程序设计的历史构架商业周期的几个阶段1、原始的构架商业周期，一家组织只为一个系统创建构架2、使公司能够赖以创建整个系统产品线而不是单个系统的构架所对应的商业周期3、全行业共同采用的标准构架或参考构架的商业周期4、其构架影响深远的构架商业周期，如万维网未来构架需要解决的问题1、质量属性场景和战术列表的完善2、如何更好地耦合质量属性场景和战术3、如何预测应用某个战术的结果4、如何将战术组合为模式5、如何将商业组件成功地添加到构架设计中对于上述问题的解决就逐渐地形成了未来构架的框架。另外，在最后一堂课上，我为学生讲解分析了一个实用、具体的示例生物信号采集与处理系统。通过对这个系统的需求、质量属性的分析，得出了其构架方案
