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