《软件构架》复习大纲.docx
《《软件构架》复习大纲.docx》由会员分享，可在线阅读，更多相关《《软件构架》复习大纲.docx（18页珍藏版）》请在冰豆网上搜索。
《软件构架》复习大纲
《软件构架》复习大纲
第一章构架商业周期
构架商业周期的定义?
构架商业周期——软件构架是技术、商业和社会诸多因素作用的结果，而软件构架的存
在反过来又会影响技术、商业和社会环境，从而影响到未来的构架。
我们把这种相互影响的周期——从环境到构架又返回环境称为构架商业周期（ArchitectureBusinessCycle,ABC）
构架的影响因素有哪些？
从构架商业周期的概念我们可以看出，构架与之交互的外界环境之间存在着密切的关系，他们相互影响，相互作用，相互促进。
一方面构架受到多种因素的影响：
1、涉众的影响；2、构架开发组织的影响；3、构架设计师素质和经验的影响；4、技术环境的影响；5、其他影响因素。
另一方面，环境反过来又会对构架的形成和发展产生影响：
1、影响着开发组织的结构；2、影响着开发组织的目标；3、影响客户对下一个系统的要求；4、影响着构架设计师；5、构架影响着软件工程的发展
软件构架的定义，构架所包含的内容?
◆软件构架——某个软件或计算机系统的软件构架是该系统的一个或多个结构，他们由软
件元素，这些元素之间的外部可见属性和这些元素之间的关系组成
第二章
构架模式、参考模型，参考构架的定义、内容和区别，哪具说法包含的范围最广?
♦三个模型——1、构架模式2、参考模型3、参考构架
♦构架模式——是对元素和关系类型以及一组对其使用方式的限制的描述，我们可以把它看作是对构架的一组制约条件——即对各元素类型及其交互模式的限制条件，而这些制约条件确定了一组或一系列能满足他们要求的构架，比如，客户机/服务器构架模式。
构架模式最重要的作用是它们展示了已知的质量属性。
♦参考模型——是一种考虑数据流的功能划分，它对已知问题进行分解，分解得到的各个部分相互协作，构成问题的解决方案
♦参考构架——是映射到软件元素及元素之间数据流上的参考模型
三者之间的关系是：
参考模型实现了系统的功能划分，而参考构架则将这种功能划分与系统分解对应起来，这种对应一般是一一对应关系，也可能不是。
图软件构架及其中间过程之间的关系
1.软件构架重要性的原因?
软件构架对于一个系统而言，具有极其重要的意义，包括：
（1）、软件构架是涉众之间交流的手段
（2）、软件构架是系统的早期设计决策
（3）、软件构架是可传递的系统抽象
为了能够清晰的表达构架，我们引入了如下两个概念：
视图——视图是构架元素内聚集的表述，由系统涉众编写和阅读，它由一个元素集合表示和元素之间的关系组成，用于表示构架中的某个结构
结构——结构是元素本身的集合，他们存在于软件和硬件中，比如，模块结构是系统的模块和其组织的结构，模块视图是该结构的表示
2.三种构架结构及其详细分类
我们使用视图和结构来表示系统的构架，构架结构根据元素的主要特性可以分为三类：
（1）、模块结构：
表示一种考虑系统的基于代码的表示方法
（2）、组件—连接器结构：
展示了软件运行是各个部分之间的交互
（3）、分配结构：
展示了软件元素和创建并执行软件的一个或多个外部环境中的元素之间的关系
图常见的软件构架结构
第三章A-7E航空电子系统
1.A-7E软件所满足的质量目标包括：
（1）实时性能，软件系统每秒钟显示内容的更新次数和武器投放的计算速度
（2）针对期望更改的可修改性，对武器、平台、显示屏上符号的变更，以及通过键盘数据新
的内容容易更改
第四章理解质量属性（*）
我们开发一个系统是为了给用户使用，因此系统的质量好坏最终要由用户来评判。
评判的依据：
（1）、系统是否能够满足客户的功能需求（直接）
（2）、系统是否能够满足一定的质量需求（间接，长期的影响）
功能性（functionality）是指系统能够完成所期望的工作的能力
质量属性（qualityattributes）是高于系统功能基本要求的，它是对多种更高层次需求的抽象描述，如安全、可靠、易用及易于修改等，显然它适用于多个特定系统而非一个。
1.什么是质量属性场景（比如可用性的一般场景表示）
♦质量属性场景（scenarios是描述质量属性的手段，是一种面向特定的质量属性的需求
2.质量属性场景由以下6个部分组成：
（1）刺激源（Sourceofstimulus）：
生成刺激的实体（人、计算机或其他）
（2）刺激（Stimulus）：
当刺激源产生的刺激达到系统后需要考虑的条件，或指可能对系统的影响
（3）环境（Environment）：
刺激到达时系统的状态，或指刺激在系统的某些条件内发生
（4）制品（Artifact）：
被刺激的部分，可能是整个系统，也可能是其中的一部分
（5）响应（Response）：
刺激到达后系统所采取的措施
（6）响应度量（Responsemeasure）：
当响应发生时，我们以某种方式对其进行度量，便于我们对需求进行测试
一般质量属性场景是指那些独立于系统，很可能适合任何系统的场景，一般场景的集合描述了质量属性
具体质量属性场景是指适合正在考虑的某个特定系统的场景
图质量属性、质量属性场景和系统的关系
每种质量属性的定义是什么，所关注的方面有哪些，度量标准一般是什么？
3.理解可用性，可修改性，安全性，性能，可测试性和易用性的质量属性的场景表示
本书主要讨论6个质量属性及其一般场景：
1、可用性（Availability），2、可修改性（Modifiability），3、性能（Performance），4、安全性（Security），5、可测试性（Testability），6、易用性（Usability）
（1）、可用性（Availability）
可用性与系统故障及其相关后果有关。
当系统不再提供其规范中所说明的服务时，就出现了系统故障。
可用性关注的问题：
如何检测故障，发生故障的频度，出现故障时的现象，系统故障排除的时限，如何防止故障的发生以及发生故障时的处理
◆可用性的表示
场景部分
可能的值
刺激源
系统内部、外部
刺激
错误：
疏忽、崩溃、时间、响应
制品
系统的处理器、通信通道、持久性存储器、进程
环境
正常、降级模式
响应
系统检测到事件，进行以下活动之一记录故障，通知用户或系统；根据已定义的规则禁止故障源等
响应度量
系统修复时间，系统可以在降级模式下运行的时间间隔等
图可用性的一般场景
（2）、可修改性（Modifiability）可修改性是关于变更的成本问题，可修改性包括两个关注点：
a、可以修改什么？
如修改系统功能、系统运行的平台和环境、系统容量、质量属性等
b、何时进行变更以及由谁进行变更？
修改时间包括设计时修改（源代码）、编译时修改（编译条件），部署时修改（系统配置）等。
（3）、性能（Performance）
性能与事件发生时，将要耗费系统多长时间做出响应有关。
影响性能的因素包括：
事件源的数量和达到模式，到达系统的事件包括：
周期性事件、随机事件或偶然事件。
性能的一般性场景：
场景部分
可用的值
刺激源
大量独立源中的一个，可能来自系统内部
刺激
定期、随机或偶然事件到达
制品
系统
环境
正常模式；超载模式
响应
处理刺激；改变服务级别
相应度量
等待时间、时间期限、吞吐量、抖动、缺失率、数据丢失
（4）、安全性（Security）
安全性是衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力
安全性被刻画为一个提供认可（交易不能被交易的任何一方拒绝）、机密性（XX不能访问数据或服务）、完整性（根据计划来提交数据或服务）、保证（交易各方是所声称的人）、可用性（系统可用于合法用途）和审核（在系统内部跟踪系统活动）的系统
安全性的一般性场景：
场景部分
可用的值
刺激源
授权或非授权用户；访问了有限的资源/大量资源
刺激
试图修改数据，访问系统服务
制品
系统服务、系统中的数据
环境
在线或离线、直接或通过防火墙入网
响应
对用户验证，阻止或允许访问数据或服务
相应度量
避开安全措施所需要的时间或资源；恢复数据/服务
（5）、可测试性（Testability）——可测试性是指通过测试揭示软件缺陷的容易程度。
如果要对系统进行正确的测试，那么必须能够“控制”每个组件的内部状态及其输入，然后“观察”其输出，测试可以由开发人员、测试人员、验证人员或用户进行；可以对代码、设计以及整个系统进行测试。
可测试性的一般性场景
场景部分
可用的值
刺激源
单元开发人员、系统集成人员、系统验证人员、测试人员、用户
刺激
已完成的一个阶段，如分析、构架、类和子系统的集成，所交付的系统
制品
设计、代码段、完整的应用
环境
设计时、开发时、编译时、部署时
响应
可以控制系统执行所期望的测试
相应度量
已执行的可执行语句的百分比；最长测试链的长度，执行测试的时间，准备测试环境的时间
（6）、易用性（Usability）
易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持种类。
包括如下几个方面：
1、学习系统的特性，2、有效地使用系统，提高用户操作效率，3、将错误的影响降到最低，4、使系统适应用户的需要，5、提高自信和满意度。
易用性的一般性场景
场景部分
可用的值
刺激源
最终用户
刺激
想要学习系统特性、有效使用系统、使错误的影响最低，适配系统等
制品
系统
环境
在运行时或配置时
响应
上下文相关的帮助系统，导航，撤销、取消操作，从系统故障中恢复，国际化，定制能力
相应度量
任务时间，错误数量，用户满意度等
商业质量属性有哪些？
1、上市时间
2、成本和收益
3、所希望的系统生命期的长短
4、目标市场，通用市场还是专用市场
5、推出计划
6、与老系统的集成
构架的质量属性包括：
1、概念完整性，在各个层次上统一系统设计的根本指导思想
2、正确性和完整性，是构架能够满足系统的各种需求及运行时的资源要求的必要条件
3、可构建性，保证能够由指定的开发小组在规定的时间里及时开发系统，并允许在开发过程中做某些更改，其目的是最大程度地实现并行开发
第五章实现质量属性（****）
1.什么是战术？
◆战术（tactics）——影响质量属性响应的设计决策
◆构架策略（architecturalstrategy）——战术的集合
◆构架模式（architecturalpattern）——以某种方式将战术打包在一起
每种质量属性的所有战术的具体内容和方法。
（也可能反过来考，告诉你内容，然后问你战术的名字）
2.实现可用性的战术？
可用性（Availability）
可用性战术将会阻止错误发展为故障，或者至少能够把错误的影响限制在一定范围内，从而使修改成为可能。
维持可用性的方法包括：
（1）、错误预防——某种类型的冗余
（2）、错误检测——用来检测故障的某种类型的健康监视
（3）、自动恢复——检测到故障时某种类型的恢复
图可用性战术
3.实现可修改性的战术？
可修改性（Modifiability）
可修改性战术的目标是控制实现、测试和部署变更的时间和成本。
根据其实现目标可以分为3组：
1、局部化修改——目标是减少由某个变更直接影响的模块的数量
2、防止连锁反应——目标是限制对局部化的模块的修改，以防止对某个模块的修改间接地影响到其他模块
3、延迟绑定时间——目标是控制部署时间并允许非开发人员进行修改
4.实现安全性的战术？
安全性（Security）
安全性战术包括抵抗攻击的战术、检测攻击的战术和从攻击从恢复的战术
5.实现性能的战术？
性能（Performance）
性能战术的目标是对一定的时间限制内到达系统的事件生成一个响应，这些事件可以使消息到达、定时器到时，系统状态的变化。
性能战术包括3个分类：
1、资源需求——分析影响性能的资源因素
2、资源管理——提高资源的应用效率
3、资源仲裁——解决资源的争用
6.实现可测试的战术？
可测试性（Testability）
可测试性战术的目标是允许在完成软件开发的一个增量后，轻松地对软件进行测试。
测试的目标是发现错误
7.实现易用性的战术？
易用性与用户完成期望任务的难易程度以及系统为用户提供的支持种类有关
8.一些重要的概念：
连锁反应，接口等
◆连锁反应（rippleeffects）——修改某个模块却影响到其他并没有被修改的模块，
我们必须修改所有相关模块（直接影响和间接影响）才能够实现我们的变更目标
◆接口是两个独立的实体相遇并进行交互或通信的边界
（4）虚拟机（VM）支持什么质量属性？
如何支持。
（6）CS结构支持什么质量属性，（可修改性和性能），用什么战术支持这些质量属性。
战术与构架模式的关系：
战术用于响应某个特定的系统质量属性；构架模式是将战术以某种方式进行打包，以一个战术的集合来支持某种构架。
比如，一个系统支持可用性和性能，那么我们可能会考虑冗余战术、同步战术、并发战术等等，这些特定于一类系统的战术集合我们称之为构架模式
第六章空中交通管制
◆1.本节讨论的构架为初始区段组系统（InitialSectorSuiteSystem,ISSS），它是对美国22
个中途中心的软硬件升级系统。
◆ISSS系统的质量属性要求：
◆
（1）极高的可用性：
保证系统不能正常工作的状态只延续极短的时间（全年5分钟）
◆
（2）高性能：
系统必须在不“丢失”任何数据的情况下对大量数据（2440架飞机）进行处
理
◆其他需求：
1、开放性：
系统必须能够与按商业运作开发出来的其它软件进行集成，比
如航图显示系统，2、可提交的子系统，3、能够更改功能和处理软硬件的升级，4、能
够与众多的外部系统相接并协同工作
◆为了实现ATC系统极高的可用性，在构架中大量的采样了冗余战术，包括硬件冗余和
软件冗余。
◆为了实现高性能，采用了并发和资源调度等战术。
第七章设计构架（*）
1.什么是属性驱动因素？
功能、质量和商业需求的某个集合塑造了构架。
我们把这些塑造需求称为构架驱动因素
2.ADD构架设计方法（属性驱动的设计方法（AttributeDrivenDesign,ADD））
该方法可以用于设计一个满足一定质量需求和功能需求的构架
ADD把一组质量属性场景作为输入，并使用对质量属性实现和构架之间的关系的了解，对构架进行设计。
ADD设计的结果是构架的模块分解视图和其他视图的最初几个层次。
ADD方法的步骤
1、选择要分解的模块
2、根据下面的步骤对模块进行求精
a、从具体的质量场景和功能需求集合中选择构架驱动因素
b、选择满足构架驱动因素的构架模式，根据用来实现驱动因素的战术创建模式
c、实例化模块并根据用例分配功能，使用多个视图进行表示
d、定义子模块的接口。
该分解提供了模块和对模块交互类型的限制
e、验证用例和质量属性场景并对其进行求精，使它们成为子模块的限制
3、对需要进一步分解的每个模块重复上述步骤
在构架的模块分解结构的最初几个层次稳定后，就可以把这些模块分配给开发小组，这就是工作分配视图，分配任务的原则：
1、开发小组内部是高内聚，外部是松耦合
2、根据开发小组的特长进行分配
3、尽量与模块的分界原则一致
在使用ADD方法完成了系统的构架设计之后，就可以构建系统的骨架系统了。
本章通过一个车库门系统设计的例子来加强对ADD构架设计方法的理解。
第九章构架编档
1.构架视图的7个组成部分？
书本p207
我们为系统设计的构架起到涉众之间交流的作用。
为了得到我们的最终构架以及方便涉众之间的交流，我们需要对设计的构架进行编档。
构架编档（DocumentingSoftwareArchitectures）是对构架的描述，构架必然存在，构架编档不一定存在；构架的建立源于系统的需求，构架文档的编写源于构架描述、交流的需求，构架编写的基本规则是：
从读者的角度进行编写
构架编档既然如此重要，我们该如何对构架进行编档呢？
构架编档包括如下三部分内容：
1、视图编档；2、接口编档；3、视图的组织
构架编档就是将相关视图编成文档，然后向其中添加适合多个视图的文件。
我们需要对软件构架中的每一个视图进行编档，每个编档视图通常包含7部分的内容：
1、展示视图中的元素和元素间关系的主要表示
2、使用元素目录描述在主要表示中所描述的元素和他们之间的关系及其他。
在这一部分内容中我们将对元素的行为和元素接口进行描述
3、展示在视图中描述的系统的环境相关上下文
4、可变性指南展示了如何应用该视图中所展示的构架的一部分的任何变化点，应该包含每个变化点的文档
5、解释视图中所反映的设计合理性的构架背景，包括：
基本原理，分析结果，设计中所反映的假定
6、视图中所使用的术语表
7、其他信息，如管理信息等
◆视图就是构架元素的内聚集合的表示，由系统涉众编写和阅读软件
◆构架编档的基本原则：
构架编档就是将相关视图编成文档，然后向其中添加适合多个视图的文件
第十一章ATAM（*）
1.ATAM的参与人员（评估小组组成，项目决策人和涉众）
ATAM要求以下3个小组的参与和合作：
（1）评估小组：
该小组是所评估构架项目外部的小组，通常由3~5人组成。
该小组的每
个成员都要扮演大量的特定角色。
他们可能是开发组织内部的，也可能是外部的。
任何时候，他们都应该是有能力、没有偏见而且私下没有其他工作要做的人员
评估小组包括如下角色的人员：
评估小组负责人，评估负责人，场景书记员，进展书记员，计时员，过程观察员，过程监督者，提问者等
（2）项目决策者对开发项目具有发言权，并有权要求进行某些改变，他们包括项目管理
人员，重要的客户代表，构架设计师等。
构架评估的一个基本准则就是构架设计师必须愿意参与评估
（3）构架涉众完成工作的能力与支持可修改性、安全性、高可靠性等特性的构架密切相关。
包括：
开发人员、测试人员、集成人员、用户等
2.构架视图文档的7个组成部分？
3.ATAM的评估过程可以分为4个阶段：
（1）评估准备阶段
（2）部分评估阶段
（3）全体评估阶段
（4）评估后续阶段
阶段
活动
参与人员
一般需要的时间
1
关系和准备
评估小组负责人和主要的项目决策者
大约需要几周时间
2
部分评估
评估小组和项目决策者
1周，然后中断2-3周
3
全体评估
评估小组、项目决策者以及涉众
2天
4
后续工作
评估小组和客户
1周
5.ATAM产生如下的结果：
（1）一个简洁的构架表述
（2）表述清楚的业务目标
（3）用场景集合捕获的质量属性
（4）所确定的敏感点和权衡点的集合
（5）有风险决策和无风险决策
（6）风险主题的集合
6.一些重要的概念：
敏感点，权衡点，质量属性效应树
敏感点——与某个质量属性相关的构架决策
权衡点——与多个质量属性相关的构架决策
有风险决策——根据所陈述的质量属性需求，可能导致不期望结果的构架决策
无风险决策——根据分析被认为是安全的构架决策
效用树的作用是使质量属性需求具体化，从而迫使设计师和客户代表准确地定义出他们将要提供的相关质量需求
效用树实际上就是使用最重要的质量属性场景来对质量属性进行讨论和评估
第十二章CBAM
1.CBAM（CostBenefitAnalysisMethod）成本收益分析方法是对软件系统进行经济建模的方
法，它提供了对技术与经济问题以及构架决策的评估。
2.构架策略影响系统的质量属性，反过来这些质量属性又会为系统的涉众带来一定的收益，
我们称该收益为效用。
每个构架策略都为涉众提供了一特定级别的效用，同时，每个策略对
应一个成本，我们将收益和成本的比值叫做ROI（ReturnonInvestment）投资回报，CBAM
方法就是计算各种构架策略的ROI，然后协助涉众选择构架策略
3.CBAM使用场景来表达具体的质量属性，但是它不是使用一个单独的场景，而是通过改变
响应值对某一质量属性生成一组场景，每个场景对应一个效用，那么一组响应值就对应一组
效用，这样就形成了效用响应曲线
4.CBAM评估方法的步骤：
1、整理场景：
确定场景的优先级，然后选择优先级最高的1/3场景
2、对场景进行求精：
确定该场景的最好情况、最坏情况、当前情况和期望情况的质量
属性响应级别
3、再次确定场景的优先级，只保留一半场景
4、为每个场景的当前级别和期望级别分配效用
5、为每个场景开发构架策略，并确定质量响应级别
6、使用内插法确定所期望的构架策略效用值
7、计算某个构架策略的总收益
8、计算ROI，根据ROI选择构架策略
9、运用直觉来确认所得到的结果
第十四章软件产品线
1.什么是软件产品线？
◆软件产品线（SoftwareProductLines）——组软件密集型系统，它们共享一个公共的、可管理的特性集，满足了某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集开发出来的，比如医学图像处理软件
2.软件产品线的产品个数要求？
3.软件产品线的开发组织结构类型
◆产品线的两个主要模型
（1）前瞻性模型——需要初始投资，很少返工
（2）反应性模型——没有初始投资，需要大量返工
◆产品线开发的组织结构
（1）开发部门：
所有软件的开发都集中在一个单元中进行，30人以下的小型项目
比如：
我们开发的项目，Linux的原型等
（2）业务单元：
每个业务单元负责产品家族中系统的一个子集，子集具有相似性；30~100
人的中型项目
比如，程控交换机的软件，银行数据库应用软件等
（3）领域工程单元：
指定一个专门的单元负责核心资产库的开发和维护，业务单元根据
这些核心资产构建产品，超过100人的大项目
比如：
SAPERP项目等
（4）分层次的领域工程单元：
巨型项目
比如：
Windows操作系统，Oracle数据库等
第十八章构架不匹配
1.构架不匹配（ArchitecturalMismatch）：
不是专门针对您的系统开发的组件可能不会满
足您的所有质量需求，它们甚至不会与您为之配对的组件协同工作，组件集成系统的这种现
象被称为构架不匹配。
构架不匹配是接口不匹配的特殊情况。
即组件之间彼此的假设不合适
2.应对接口不匹配的措施
1、通过审查系统组件来避免接口不匹配
2、通过对组件进行限定来检测没有避免的不匹配问题
3、通过适配组件来修复不匹配问题
修复接口不匹配的技巧
一个明显的修复方法是改变不匹配的组件代码，但组件的源代码我们往往难于得到，一
种替代的方案是在应用程序和组件之间插入一种修复不匹配的交互代码。
有三类修复方式：
包装器、桥和中介器：
1、包装器是将某个组件封装在一个可选的抽象中，而系统只能通过该包装器提供的替代接
口访问已包装的组件服务。
2、桥把任意一个组件的需求假设转换为另一个组件的提供假设；桥和包装器的区别在于组
成桥的修复代码独立于任何特定的组件；桥必须由某个外部代理显示调用
3、中介器展示了桥和包装器属性；桥和中介器的区别在于中介器集成了规定功能，具有足
够的语义复杂性和运行时自适应性，以在软件构架中扮演角色
升级会员 