《软件构架》复习大纲.docx

1、软件构架复习大纲软件构架复习大纲成绩评定：考勤10% + 平时作业20% + 期末考试70%第一章 构架商业周期1.构架的产生受影响的因素 构架商业周期软件构架是技术、商业和社会诸多因素作用的结果，而软件构架的存在反过来又会影响技术、商业和社会环境，从而影响到未来的构架。我们把这种相互影响的周期从环境到构架又返回环境称为构架商业周期（Architecture Business Cycle, ABC）从构架商业周期的概念我们可以看出，构架与之交互的外界环境之间存在着密切的关系，他们相互影响，相互作用，相互促进。一方面构架受到多种因素的影响：1、涉众的影响；2、构架开发组织的影响；3、构架设计师素

2、质和经验的影响；4、技术环境的影响；5、其他影响因素。另一方面，环境反过来又会对构架的形成和发展产生影响：1、影响着开发组织的结构；2、影响着开发组织的目标；3、影响客户对下一个系统的要求；4、影响着构架设计师；5、构架影响着软件工程的发展第二章1. 理解软件构架，构架模式的定义 软件构架某个软件或计算机系统的软件构架是该系统的一个或多个结构，他们由软件元素，这些元素之间的外部可见属性和这些元素之间的关系组成 视图视图是构架元素内聚集的表述，由系统涉众编写和阅读，它由一个元素集合表示和元素之间的关系组成，用于表示构架中的某个结构 三个模型 1、构架模式 2、参考模型 3、参考构架 构架模式是对

3、元素和关系类型以及一组对其使用方式的限制的描述，我们可以把它看作是对构架的一组制约条件即对各元素类型及其交互模式的限制条件，而这些制约条件确定了一组或一系列能满足他们要求的构架，比如，客户机/服务器构架模式。构架模式最重要的作用是它们展示了已知的质量属性。 参考模型是一种考虑数据流的功能划分，它对已知问题进行分解，分解得到的各个部分相互协作，构成问题的解决方案 参考构架是映射到软件元素及元素之间数据流上的参考模型 三者之间的关系是：参考模型实现了系统的功能划分，而参考构架则将这种功能划分与系统分解对应起来，这种对应一般是一一对应关系，也可能不是。图 软件构架及其中间过程之间的关系2. 理解构架

4、模式，参考模型，参考构架和软件构架的区别和联系3. 软件构架重要性的原因软件构架对于一个系统而言，具有极其重要的意义，包括：(1)、软件构架是涉众之间交流的手段(2)、软件构架是系统的早期设计决策(3)、软件构架是可传递的系统抽象为了能够清晰的表达构架，我们引入了如下两个概念：视图视图是构架元素内聚集的表述，由系统涉众编写和阅读，它由一个元素集合表示和元素之间的关系组成，用于表示构架中的某个结构结构结构是元素本身的集合，他们存在于软件和硬件中，比如，模块结构是系统的模块和其组织的结构，模块视图是该结构的表示4. 三种构架结构及其详细分类我们使用视图和结构来表示系统的构架，构架结构根据元素的主要

5、特性可以分为三类：(1)、模块结构：表示一种考虑系统的基于代码的表示方法(2)、组件连接器结构：展示了软件运行是各个部分之间的交互(3)、分配结构：展示了软件元素和创建并执行软件的一个或多个外部环境中的元素之间的关系图 常见的软件构架结构第四章 理解质量属性（*）我们开发一个系统是为了给用户使用，因此系统的质量好坏最终要由用户来评判。评判的依据：(1)、系统是否能够满足客户的功能需求（直接）(2)、系统是否能够满足一定的质量需求（间接，长期的影响）功能性（functionality）是指系统能够完成所期望的工作的能力质量属性（quality attributes）是高于系统功能基本要求的，它是

6、对多种更高层次需求的抽象描述，如安全、可靠、易用及易于修改等，显然它适用于多个特定系统而非一个。1. 什么是质量属性场景（比如可用性的一般场景表示） 质量属性场景（scenarios是描述质量属性的手段，是一种面向特定的质量属性的需求2. 质量属性场景由以下6个部分组成：(1) 刺激源（Source of stimulus）：生成刺激的实体（人、计算机或其他）(2) 刺激（Stimulus）：当刺激源产生的刺激达到系统后需要考虑的条件，或指可能对系统的影响(3) 环境（Environment）：刺激到达时系统的状态，或指刺激在系统的某些条件内发生(4) 制品（Artifact）：被刺激的部分，

7、可能是整个系统，也可能是其中的一部分(5) 响应（Response）：刺激到达后系统所采取的措施(6) 响应度量（Response measure）：当响应发生时，我们以某种方式对其进行度量，便于我们对需求进行测试一般质量属性场景是指那些独立于系统，很可能适合任何系统的场景，一般场景的集合描述了质量属性具体质量属性场景是指适合正在考虑的某个特定系统的场景图 质量属性、质量属性场景和系统的关系3. 理解可用性，可修改性，安全性，性能，可测试性和易用性的质量属性的场景表示本书主要讨论6个质量属性及其一般场景：1、可用性（Availability），2、可修改性（Modifiability），3、性

8、能（Performance），4、安全性（Security），5、可测试性（Testability），6、易用性（Usability）(1)、可用性（Availability）可用性与系统故障及其相关后果有关。当系统不再提供其规范中所说明的服务时，就出现了系统故障。可用性关注的问题：如何检测故障，发生故障的频度，出现故障时的现象，系统故障排除的时限，如何防止故障的发生以及发生故障时的处理 可用性的表示场景部分可能的值刺激源系统内部、外部刺激 错误：疏忽、崩溃、时间、响应制品系统的处理器、通信通道、持久性存储器、进程环境 正常、降级模式响应 系统检测到事件，进行以下活动之一记录故障，通知用户或系

9、统；根据已定义的规则禁止故障源等响应度量系统修复时间，系统可以在降级模式下运行的时间间隔等图 可用性的一般场景(2)、可修改性（Modifiability）可修改性是关于变更的成本问题，可修改性包括两个关注点：a、可以修改什么？如修改系统功能、系统运行的平台和环境、系统容量、质量属性等b、何时进行变更以及由谁进行变更？修改时间包括设计时修改（源代码）、编译时修改（编译条件），部署时修改（系统配置）等。(3)、性能（Performance）性能与事件发生时，将要耗费系统多长时间做出响应有关。影响性能的因素包括：事件源的数量和达到模式，到达系统的事件包括：周期性事件、随机事件或偶然事件。性能的一般

10、性场景：场景部分可用的值刺激源大量独立源中的一个，可能来自系统内部刺激定期、随机或偶然事件到达制品系统环境正常模式；超载模式响应处理刺激；改变服务级别相应度量等待时间、时间期限、吞吐量、抖动、缺失率、数据丢失(4)、安全性（Security）安全性是衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力安全性被刻画为一个提供认可（交易不能被交易的任何一方拒绝）、机密性（XX不能访问数据或服务）、完整性（根据计划来提交数据或服务）、保证（交易各方是所声称的人）、可用性（系统可用于合法用途）和审核（在系统内部跟踪系统活动）的系统安全性的一般性场景：场景部分可用的值刺激源授权或非授权用户；访问了有

11、限的资源/大量资源刺激试图修改数据，访问系统服务制品系统服务、系统中的数据环境在线或离线、直接或通过防火墙入网响应对用户验证，阻止或允许访问数据或服务相应度量避开安全措施所需要的时间或资源；恢复数据/服务(5)、可测试性（Testability）可测试性是指通过测试揭示软件缺陷的容易程度。如果要对系统进行正确的测试，那么必须能够“控制”每个组件的内部状态及其输入，然后“观察”其输出，测试可以由开发人员、测试人员、验证人员或用户进行；可以对代码、设计以及整个系统进行测试。可测试性的一般性场景场景部分可用的值刺激源单元开发人员、系统集成人员、系统验证人员、测试人员、用户刺激已完成的一个阶段，如分析

12、、构架、类和子系统的集成，所交付的系统制品设计、代码段、完整的应用环境设计时、开发时、编译时、部署时响应可以控制系统执行所期望的测试相应度量已执行的可执行语句的百分比；最长测试链的长度，执行测试的时间，准备测试环境的时间(6)、易用性（Usability）易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持种类。包括如下几个方面：1、学习系统的特性，2、有效地使用系统，提高用户操作效率，3、将错误的影响降到最低，4、使系统适应用户的需要，5、提高自信和满意度。易用性的一般性场景场景部分可用的值刺激源最终用户刺激想要学习系统特性、有效使用系统、使错误的影响最低，适配系统等制品

13、系统环境在运行时或配置时响应上下文相关的帮助系统，导航，撤销、取消操作，从系统故障中恢复，国际化，定制能力相应度量任务时间，错误数量，用户满意度等第五章 实现质量属性（*）1. 什么是战术？ 战术（tactics）影响质量属性响应的设计决策 构架策略（architectural strategy）战术的集合 构架模式（architectural pattern）以某种方式将战术打包在一起2. 实现可用性的战术？可用性（Availability）可用性战术将会阻止错误发展为故障，或者至少能够把错误的影响限制在一定范围内，从而使修改成为可能。维持可用性的方法包括：(1)、错误预防某种类型的冗余(2

14、)、错误检测用来检测故障的某种类型的健康监视(3)、自动恢复检测到故障时某种类型的恢复图 可用性战术3. 实现可修改性的战术？可修改性（Modifiability）可修改性战术的目标是控制实现、测试和部署变更的时间和成本。根据其实现目标可以分为3组：1、局部化修改目标是减少由某个变更直接影响的模块的数量2、防止连锁反应目标是限制对局部化的模块的修改，以防止对某个模块的修改间接地影响到其他模块3、延迟绑定时间目标是控制部署时间并允许非开发人员进行修改4. 实现安全性的战术？安全性（Security）安全性战术包括抵抗攻击的战术、检测攻击的战术和从攻击从恢复的战术5. 实现性能的战术？性能（Per

15、formance）性能战术的目标是对一定的时间限制内到达系统的事件生成一个响应，这些事件可以使消息到达、定时器到时，系统状态的变化。性能战术包括3个分类：1、资源需求分析影响性能的资源因素2、资源管理提高资源的应用效率3、资源仲裁解决资源的争用6. 实现可测试的战术？可测试性（Testability）可测试性战术的目标是允许在完成软件开发的一个增量后，轻松地对软件进行测试。测试的目标是发现错误7. 实现易用性的战术？易用性与用户完成期望任务的难易程度以及系统为用户提供的支持种类有关8. 一些重要的概念：连锁反应，接口等 连锁反应（ripple effects）修改某个模块却影响到其他并没有被修

16、改的模块，我们必须修改所有相关模块（直接影响和间接影响）才能够实现我们的变更目标 接口是两个独立的实体相遇并进行交互或通信的边界第七章 设计构架（*）1. 什么是属性驱动因素？功能、质量和商业需求的某个集合塑造了构架。我们把这些塑造需求称为构架驱动因素2. ADD构架设计方法(属性驱动的设计方法（Attribute Driven Design, ADD）)该方法可以用于设计一个满足一定质量需求和功能需求的构架ADD把一组质量属性场景作为输入，并使用对质量属性实现和构架之间的关系的了解，对构架进行设计。ADD设计的结果是构架的模块分解视图和其他视图的最初几个层次。ADD方法的步骤1、选择要分解的

17、模块2、根据下面的步骤对模块进行求精a、从具体的质量场景和功能需求集合中选择构架驱动因素b、选择满足构架驱动因素的构架模式，根据用来实现驱动因素的战术创建模式c、实例化模块并根据用例分配功能，使用多个视图进行表示d、定义子模块的接口。该分解提供了模块和对模块交互类型的限制e、验证用例和质量属性场景并对其进行求精，使它们成为子模块的限制3、对需要进一步分解的每个模块重复上述步骤在构架的模块分解结构的最初几个层次稳定后，就可以把这些模块分配给开发小组，这就是工作分配视图，分配任务的原则：1、开发小组内部是高内聚，外部是松耦合2、根据开发小组的特长进行分配3、尽量与模块的分界原则一致在使用ADD方法

18、完成了系统的构架设计之后，就可以构建系统的骨架系统了。本章通过一个车库门系统设计的例子来加强对ADD构架设计方法的理解。第九章 构架编档1. 构架视图的7个组成部分？书本p207我们为系统设计的构架起到涉众之间交流的作用。为了得到我们的最终构架以及方便涉众之间的交流，我们需要对设计的构架进行编档。 构架编档（Documenting Software Architectures）是对构架的描述，构架必然存在，构架编档不一定存在；构架的建立源于系统的需求，构架文档的编写源于构架描述、交流的需求，构架编写的基本规则是：从读者的角度进行编写构架编档既然如此重要，我们该如何对构架进行编档呢？构架编档包括

19、如下三部分内容：1、视图编档；2、接口编档；3、视图的组织构架编档就是将相关视图编成文档，然后向其中添加适合多个视图的文件。我们需要对软件构架中的每一个视图进行编档，每个编档视图通常包含7部分的内容：1、展示视图中的元素和元素间关系的主要表示2、使用元素目录描述在主要表示中所描述的元素和他们之间的关系及其他。在这一部分内容中我们将对元素的行为和元素接口进行描述3、展示在视图中描述的系统的环境相关上下文4、可变性指南展示了如何应用该视图中所展示的构架的一部分的任何变化点，应该包含每个变化点的文档5、解释视图中所反映的设计合理性的构架背景，包括：基本原理，分析结果，设计中所反映的假定6、视图中所使

20、用的术语表7、其他信息，如管理信息等 视图就是构架元素的内聚集合的表示，由系统涉众编写和阅读软件 构架编档的基本原则：构架编档就是将相关视图编成文档，然后向其中添加适合多个视图的文件第十一章 ATAM（*）1. ATAM的参与人员（评估小组组成，项目决策人和涉众）ATAM要求以下3个小组的参与和合作：(1) 评估小组：该小组是所评估构架项目外部的小组，通常由35人组成。该小组的每个成员都要扮演大量的特定角色。他们可能是开发组织内部的，也可能是外部的。任何时候，他们都应该是有能力、没有偏见而且私下没有其他工作要做的人员 评估小组包括如下角色的人员：评估小组负责人，评估负责人，场景书记员，进展书记

21、员，计时员，过程观察员，过程监督者，提问者等(2) 项目决策者对开发项目具有发言权，并有权要求进行某些改变，他们包括项目管理人员，重要的客户代表，构架设计师等。 构架评估的一个基本准则就是构架设计师必须愿意参与评估 （3）构架涉众完成工作的能力与支持可修改性、安全性、高可靠性等特性的构架密切相 关。包括：开发人员、测试人员、集成人员、用户等2. 构架视图文档的7个组成部分？3. ATAM的评估过程可以分为4个阶段：(1) 评估准备阶段(2) 部分评估阶段(3) 全体评估阶段(4) 评估后续阶段阶段活动参与人员一般需要的时间1关系和准备评估小组负责人和主要的项目决策者大约需要几周时间2部分评估评

22、估小组和项目决策者1周，然后中断2-3周3全体评估评估小组、项目决策者以及涉众2天4后续工作评估小组和客户1周5. ATAM产生如下的结果：(1) 一个简洁的构架表述(2) 表述清楚的业务目标(3) 用场景集合捕获的质量属性(4) 所确定的敏感点和权衡点的集合(5) 有风险决策和无风险决策(6) 风险主题的集合6. 一些重要的概念：敏感点，权衡点，质量属性效应树敏感点与某个质量属性相关的构架决策权衡点与多个质量属性相关的构架决策有风险决策根据所陈述的质量属性需求，可能导致不期望结果的构架决策无风险决策根据分析被认为是安全的构架决策效用树的作用是使质量属性需求具体化，从而迫使设计师和客户代表准确

23、地定义出他们将要提供的相关质量需求效用树实际上就是使用最重要的质量属性场景来对质量属性进行讨论和评估第十四章 软件产品线1. 什么是软件产品线？ 软件产品线（Software Product Lines）组软件密集型系统，它们共享一个公共的、可管理的特性集，满足了某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集开发出来的，比如医学图像处理软件2. 软件产品线的产品个数要求？3. 软件产品线的开发组织结构类型 产品线的两个主要模型(1) 前瞻性模型需要初始投资，很少返工(2) 反应性模型没有初始投资，需要大量返工 产品线开发的组织结构(1) 开发部门：所有软件的开发都集中在一个单元中进行，30人以下的小型项目比如：我们开发的项目，Linux的原型等(2) 业务单元：每个业务单元负责产品家族中系统的一个子集，子集具有相似性；30100人的中型项目比如，程控交换机的软件，银行数据库应用软件等(3) 领域工程单元：指定一个专门的单元负责核心资产库的开发和维护，业务单元根据这些核心资产构建产品，超过100人的大项目比如：SAP ERP项目等(4) 分层次的领域工程单元：巨型项目 比如：Windows操作系统，Oracle数据库等