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