四川大学软件工程考点

第一章——软件工程介绍

1.一个包含过程(process)、一系列方法(methods)和工具(tools)的框架，我们称之为软件工程(software engineering)。

2.软件开发人员面临的问题： ①软件开发时间长

②软件开发成本居高不下

③在软件交付给用户之前，我们无法找到所有的错误。 ④维护已有的程序花费高昂的时间和人力代价 ⑤软件开发和维护的过程难以度量。

3.软件的定义：

①程序(program)：通过执行包含在程序中的指令可以满足预期的特征、功能和性能需求 ②数据结构(data structure)：使得程序充分利用信息。 ③文档(ducoment)：描述程序操作和使用。

4.What is the difference between software and hardware? ①软件是开发设计的，而不是生产制造的。

②软件不会磨损(wear out)，但是会退化(deteriorate)。不断的变更是软件退化的根本原因。硬件会磨损，磨损的部分可以用备用的构件替换，而软件缺不存在备用构件。

③虽然整个工业向着基于构件的构造模型发展，然而大多数的软件还是主要采用用户定制(custom buildt)的方式（Because off-the-shell software components are unavailable in many

application domains）。在硬件设计中，构件复用是工程进程中通用的方法。而在软件设计中，大规模的复用还刚刚开始尝试。

5.软件的确定性（determinate）是指系统的输入、处理和输出的顺序及时间是可以预测的；软件的不确定性是指系统的输入、处理和输出的顺序及时间是无法提前预测的。

6.遗留软件(legacy software)——旧的软件

①生命周期长(longevity) ②业务关键性(business criticality) ③质量差(poor quality)

遗留软件发生系统演化的原因：

①软件需要修改其适应性，从而可以满足新的计算环境或者技术的需求。 ②软件必须根据新的业务需求进行升级。

③软件必须扩展以具有与更多现代系统和数据库协作的能力。 ④软件构架必须进行改建以适应多样化的网络环境。

7.软件演化（evolution）

变更(change)（通常称为软件维护）推动了软件演化，它通常是由以下情况引发的：程序纠错，调整软件以适应新的环境，满足用户新特性和功能的需求，以及对软件实施再工程以便在现代应用中发挥作用。

8.软件危机

软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题，如软件费用、软件可靠性、软件维护、软件生产、软件重用等。

1

第二章——过程综述

1.软件过程定义为一个建造高质量软件所需要完成的任务的框架（framework）。 软件生命周期：软件产品或软件系统从设计、投入使用到被淘汰的全过程。

2.**软件工程的定义：

①将系统化（systematic）、规范化（disciplined）、可量化（quantifiable）的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。 ②对①中所述方法的研究。

3.软件工程是一种层次化的技术，软件工程层次图如下：

工具tools 方法 methods 过程 process 质量关注点 a quality focus ①软件工程的根基(bedrock)在于质量关注点。

②软件工程的基础(foundation)是过程层。软件过程将各个层次的技术结合在一起，并实施合理地、及时地开发计算机软件。并且过程定义一个框架。

③软件工程方法为建造软件提供技术上的解决方法，包括沟通、需求分析、设计建模、编程、测试和支持。

④软件工程工具：为过程和方法提供自动化或半自动化的支持。

4.过程框架定义了若干小的框架活动，为完整的软件开发建立了基础。 五个通用过程框架活动(generic process framework activity)： ①communication沟通 ②planning策划

③modeling建模：包括分析（analysis）和设计（design）两个动作 ④construction构建 ⑤deployment部署

5.stakeholder（共利益者）就是可在项目成功中分享利益的人，包括业务经理、最终用户、软件工程师、支持人员等。

6.不同的项目需要不同的任务集(task set)，软件开发根据问题和项目的特点选择任务集。

7.软件工程的通用框架由很多普适性活动（umbrella activity）来实现，普适性活动贯穿于整个软件过程。(across/throughout the entire software process)

2

尽管有很多种不同的软件工程过程模型，但它们都定义了：一组框架活动，完成每个活动所包含的任务集，任务完成所形成的工作产品，以及一组可以用于整个过程的普适性活动。

8.不同模型之间的区别：

①活动和任务的总体流程，以及相互之间的关系 ②在框架中的每一个活动中任务细化的程度 ③对所需要提交的工作产品的定义 ④质量保证活动应用的方式

⑤过程跟踪和控制活动应用的方式 ⑥过程描述的详细和严谨程度

⑦客户和共享利益者对项目参与的深度 ⑧软件项目队伍所赋予的自主权 ⑨队伍组织和角色明确程度

9.能力成熟度模型（CMMI）能力成熟度模型集成，是一个过程元模型，定义了如何建立完整的软件过程，软件组织所应该具备的过程特征。分为不完全级、已执行级、已管理级、已定义级、已定量管理级、优化级。每个过程域的capability levels： ①第0级：incomplete（不完全级） ②第1级：performed(已执行级) ③第2级：managed(已管理级) ④第3级：defined(已定义级)

⑤第4级：quantitatively managed(已定量管理级) ⑥第5级：optimized(优化级)

10.软件过程可以定义为一系列模式（pattern）的组合，这些模式定义了一系列的软件开发中所需的活动、动作、工作任务、工作产品及相关的行为。

Pattern template provides a consistent means for describing a pattern。

11. formal techniques are available for assessing the software process： SCAMPI、CBI IPI、SPICE、ISO 9001

SCAMPI提供了五步的过程评估模型：启动（initiating）、诊断（diagnosing）、建立（establishing）、执行（acting）、学习（learning）

SPICE和其他的标准定义了指导软件过程评估的要求，ISO对过程中的质量管理进行检查

3

12. ISO 9001:2000采用“计划-实施-检查-行动”（plan-do-check-act）循环，将其应用于软件项目的质量管理环节。

A. 计划（plan）是为实现高质量的软件产品并最终提高用户满意度，建立必须的过程目标、活动和任务。

B. 实施是执行软件过程，包括框架活动和普适性活动。

C. 检查监督并测量过程，以保证所有为质量管理所建立的需求均已实现。 D. 行动启动软件过程改进活动，并持续地改进进程。

13.个人过程模型PSP定义的五个框架活动： ①策划（planning）

②高层设计（high-level design）

③高层设计评审（high-level design review） ④开发（development） ⑤后验（postmortem）

PSP强调对所犯的错误类型进行记录和分析，以便于制定避免错误的策略。

14.团队软件过程TSP定义的框架活动： ①项目启动（launch）

②高层设计（high-level design） ③实现（implementation） ④集成（integration） ⑤测试（test）

⑥后验（postmortem）

个人和团队模型都强调了成功软件过程的关键因素：测量、计划、自我管理

第三章——过程模型

1.惯例过程模型：惯例模型规定了一套过程元素——框架活动、软件工程动作、任务、工作产品、质量保证以及每个项目的变更控制机制。每个过程还定义了工作流

2. **瀑布模型waterfall model（经典生命周期classical life circle）、

是一种基于软件生存周期的线性（linear）开发模型。它提出了一个系统的、顺序

（sequential）的软件开发方法，从用户需求规格说明开始，通过策划、建模、构件和部署的过程，最终提供一个完整的软件并提供持续的技术支持。

①适用于需求定义清晰(requirements are fixed)且稳定的软件开发 不足之处：

①实际的项目很少遵守瀑布模型提出的顺序。 ②用户常难以清楚地描述所有的需求。

③客户必须要有耐心，只有在项目接近尾声的时候，他们才能得到可执行的程序。

3.**增量模型(incremental)：以迭代的方式运用瀑布模型，在每个阶段运用线性序列。这种模型把软件看作是一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量。

①第一个增量是一个核心产品，每个增量都提交一个可以操作的产品。

②如果在既定的商业要求之前不可能找到足够的开发人员，增量模型显得特别有用。

4

4.RAD模型：

①是一种侧重于短暂的开发周期的增量过程模型，为大型且必须在严格的时间内提交的项目而设计的。

②是瀑布模型的高速变体，通过基于构件的构建方法实现快速开发。 ③是一种linear sequential model RAD的不足之处(drawbacks)：

①对于大型的可伸缩项目，RAD需要大量的人力资源来创建多个相对独立的RAD团队。 ②如果没有为短时间内急速完成整个系统做好准备，RAD项目将会失败。 ③如果一个系统不能合理地模块化，RAD构建会有很多问题。 ④如果系统需求是高性能，不能采用RAD模型。 ⑤技术风险很高的时候，不宜采用RAD。

演化过程模型(evolutionary process model)每次迭代产生软件的一个更完整的版本。

5.原型开发(prototyping)：用于需求很模糊的时候(requirements are fuzzy，cant define requirement clearly)

**原型模型的思想是：先建立一个能够放映用户主要需求的原型，让用户实际看一下未来系统的面貌，以便判断哪些功能是符合需要的，哪些方面还需要改进，然后将原型反复改进，直至建立完全符合用户要求的新系统。

6.螺旋模型(spiral)

①结合了原型的迭代（iterative）特性、瀑布模型的系统性（systematic）和可控性（controlled）特点。采用循环的方式逐步加深系统定义和实现的深度。

②其他过程模型在软件交付之后就结束了，螺旋模型则不同，它应用在计算机软件的整个生命周期，从概念开发到维护。

③把原型开发作为降低风险的机制，它依赖大量的风险评估专家来保证成功。If a major risk is not uncovered and managed ，problems will undoubtedly occur。

7.协同开发模型：适合于不同的工程团队开发的系统工程项目。 8.专用过程模型：应用较窄，只适合于某些特定的软件工程方法。

①基于构件的开发：本质上是演化模型，需要以迭代方式构建软件。the process to apply when reuse is development objective。

②形式化方法模型：主要活动是生成计算机软件形式化的数学规格说明，意义在于提供无缺陷的软件。

③面向方面的软件开发(AOSD)：以用户跨越多个系统功能、特性和信息为关注点。

9.统一过程（UP）是一种增量模型，determined iterativelly，span more than one of the process。定义了五个阶段（phase）：

①起始（inception）：包括客户沟通和策划活动，强调定义和细化用例，并将其作为主要模型 ②细化（elaboration）：包括用户沟通和建模活动，重点是创建分析和设计模型，强调类的定义和体系结构的表示

③构建（construction）：细化设计模型，并将设计模型转化为软件构件实现

④转换（translation）：将软件从开发人员传递给最终用户，并由用户完成Beta测试和验收测试

⑤生产（production）：持续地监控软件的运行，并提供技术支持

5

第四章——敏捷开发（agile process）

1.软件敏捷开发宣言（Manifesto） ①个体和交互胜过过程和工具 ②可工作软件胜过宽泛的文档 ③用户合作胜过合同谈判 ④响应变化胜过遵循计划

普遍存在的变化是敏捷的基本动力。所有敏捷方法都或多或少的遵循以上的原则。

2.Agility is more than ①an effective response to change。 ②effective communication among stakeholders ③drawing the custom onto the team

③organizing a team so that it's control of the work performed

Agile alliance 的12条准则中，第一条是最优先要做的是通过尽早、持续交付valuable software来满足用户的要求

敏捷可用于任何软件过程，实现要点是将软件过程设计为如下方式： ①允许项目团队调整并合理安排任务 ②理解敏捷开发方法的易变性并制定计划 ③精简并维持最基本的工作产品 ④强调增量交付策略

3.敏捷过程的三个假设（Assumption）：

①提前预测哪些需求是稳定的和哪些需求会变化非常困难。

②对许多软件来说，设计和构建是交错进行的。事实上，两种活动应顺序开展（tandem）以保证通过构建实施来验证设计模型，而在通过构建验证之前很难估计到应当设计到什么程度。 ③从制定计划的角度来看，设计、分析、构建和测试并不像我们所设想的那么容易预测。 以上说明敏捷过程必须具有自适应性（adaptable）。

4.软件开发团队及成员应具有的特点： ①competence ②common focus

6

③collaboration

④decision-making ability

⑤fuzzy problem-sloving ability ⑥mutual trust and respect ⑦self-organization

5.极限编程XP

①XP使用面向对象方法作为推荐的开发范型

②XP的四个框架活动：planning、design、coding、testing（计划、设计、编码和测试）

③Planning始于建立一系列描述待开发软件必要特征与功能的故事（story or user story）。项目速度是第一个发行版本中实现的用户故事个数。

④XP design遵循kis原则（Keep-it-simple）；鼓励使用CRC作为有效机制；如果在某个故事设计中碰到困难，实现并评估原型；XP估计既是构建技术又是设计中的重构。

⑤XP coding中的关键概念之一是结对编程（pair programming）。

⑥在编码之前建立单元测试是XP方法的关键因素，XP验收测试（也称用户测试），由客户确定，根据用户故事得到的。

6.重构（ ）：是以不改变代码外部行为而进行改进其内部结构的方式来修改软件系统的过程。简而言之，重构是在编码完成之后改进代码设计。

7.自适应软件开发（ASD）强调human collaboration和team self-organization。 ASD的三个阶段：①speculation（思考）②collaboration ③learning

8.动态系统开发方法（DSDM）

①DSDM建议使用修改版Pareto原则。在这种情况下，如果交付整个应用系统需用100%时间，那么80%的应用系统可以用20%的时间交付。 ②像XP和ASD一样，DSDM建议使用迭代软件过程。

9.Scrum（橄榄球）

①每一个框架活动中，发生于一个过程模式中的工作任务称为一个冲刺。 ②每一个过程模式定义的一系列问题：待定项（backlog）、冲刺（sprint） ③十五分钟例会回答的基本问题：

A.上次例会之后做了什么 B.遇到什么困难

C.下次例会之前做些什么

10.Crystal提倡一种机动性的软件开发方法。

11.特征驱动开发（FDD）

①特征是可以在两周或更短的时间实现的具有客户价值的功能。 ②FDD更强调项目管理原则和技术。

12.敏捷建模（AM）认为对所有的系统都是有必要的。AM给实践者(practitioner)的分析和任务设计以非常有用的指导。

7

13.敏捷理念强调的四个关键问题：

①具有控制力的自我组织团队对所开展工作的重要性 ②团队成员之间、开发参与者与客户之间的交流与合作 ③对变更代表机遇的认识

④强调快速软件交付让客户满意

第五章——软件工程实践综述

1.软件工程实践的精髓： ①理解问题（交流和分析）

②计划解决方案（建模和软件设计） ③实施计划（代码生成）

④检查结果的精确度（测试和质量保证）

2.David hooker提出的关注软件工程整体实践的核心原则：

①存在价值 ②保持简洁 ③维护视图 ④生产者要让消费者理解 ⑤面向未来 ⑥计划复用 ⑦认真思考

3.WHH原则——开发一个实际项目计划所必须提出和回答的问题是：

①为什么要开发 ②要做什么东西 ③什么时候完成 ④功能由谁负责 ⑤组织位于哪里 ⑥怎样才能在工作中体现技术和管理 ⑦需要多少资源

4.在软件工程中，需要建立两类模型：分析建模（analysis ）和设计建模（design），建模的目的是加深对所要完成的工作的理解并为开发人员提供技术指导。

①分析模型通过三个不同域描述来表达用户的需求：the information domain（信息域）、the functional domain（功能域）、the behavioral domain（行为域）

②设计模型可以帮助开发者高效开发软件的特征：the architecture（构架）、the user interface（用户界面）、component-level detail（构件细节）

5.构造活动包括一系列编码和测试任务

①最初的测试是构件级的，称为单元测试（unit test） ②集成测试（integration test）——在构建系统的时候进行

③确认测试（validation test）——是测试系统是否完全按照需求开发

④验收测试（acceptance test）——由用户检验系统是否按照需求实现了所有的功能

6.测试规则：

①测试是一个以查找程序错误为目的的程序执行过程

②一个好的测试（good test）用例能最大限度地找到尚未发现的错误 ③一个成功的测试（successful test）能找到那些尚未发现的错误

7. 部署活动包括三个动作：交付（delivery）、支持（support）和反馈（feedback） 部署活动并不只是发生一次，而是在软件完全开发完成之前要进行许多次。

8.叙述软件构造和软件部署的区别

软件构建包括编码和测试，是在开发阶段由开发人员来完成；

软件部署是将所完成的部分交付给客户，由客户对其进行评测和反馈意见，此时开发人员提供技术支持和维护。

5 8

第六章——系统工程（System engineering）

1.计算机的系统：组织在一起通过处理信息来实现预定目标的要素集合或排列。

2.系统要素（system element）： ①software（软件） ②hardware（硬件） ③people（人员） ④database（数据库） ⑤documentation（文档） ⑥procedure（规程）

宏要素是指基于计算机系统，它作为更大的基于计算机的系统的一部分。

3.the system hierarchy：world view→domain view→element view→detailed view 4.建立模型工程师要考虑的restraining factor： ①Assumption ②simplification ③limitation ④construction ⑤preferences

5.业务过程工程（BPE）

①The goal of business process engineering is to define architectures that will enable a business to use information effectively。

②BPE定义和开发的三种架构：data architecture、application architecture、technology architecture

③业务过程工程层次：信息战略计划→业务区域分析→业务系统设计→构建和集成

6.产品工程

①the goal of product engineering is to translate the customer's desire for a set of defined capabilities into working product。（定义一个能有效利用信息进行业务活动的体系） ②产品工程是从系统分析开始的系统工程，软件工程师确定用户需求。

③产品工程给出构架的不同系统构件：software、hardware、database、people ④产品工程层次图：需求工程→构件工程→分析和设计建模→构建和集成

7.系统建模：每个基于计算机的系统都可按“输入-处理-输出”模板进行信息转换。

8.Hatley-Pirbhai建模模板： ①user interface ②input

③system function and control ④output

⑤maintenance and self-test

系统环境图a system context diagram（SCD）resides at the top level of the hierarchy。

9.Unified Modeling Language (UML)

9

**统一建模语言，对软件进行可视化、规约、构造、文档化的一种语言。 UML大量的图表表示法，用于在系统和软件层次分析和设计。涉及到的图：

Deployment diagram（硬件）、activity diagram（软件）、class diagram（软件）、use-case diagram

第七章——需求工程（requirement engineering）

1. RE is a software engineering action that can begins during the communication activity and continues into the modeling activity。是design和construction的桥梁。 目的：在设计和构造之间建立起联系的桥梁

任务：启始、导出、精化、协商、规格说明、确认和管理

2.需求工程通过执行7个不同的活动来完成： ①Inception（起始）

A.establish basic problem requirements B.define overriding project constrains C.address major features and functions

②Elicitation （导出）：elicit requirements from all stakeholders ，在此阶段利用facilitate meetings、QFD、the development of user scenarios 来进行需求收集活动。 需求导出困难的原因： A. problem of scope

B. problems of understanding

C. problems of volatility（易变性）

③elaboration（细化）：create an analysis model that identifies data 、function and behavioral requirement。

④negotiation（谈判）：agree on a deliverable system that is realistic for customer and developer ⑤specification（规格说明）：is the final work product produced by the requirement

engineering，描述了一个基于计算机系统的功能和性能，以及那些将影响开发系统的约束。 规格说明的形式和格式随着待开发的规模和复杂度的不同而变化。

⑥validation（确认）：检查规格查找内容或解释上的错误，以及可能进一步需要解释澄清的地方、丢失的信息，不一致性（consistency是重点）、冲突的需求或不显示的需求。以保证所有系统需求已被无歧义地说明。

⑦management(管理)：需求管理是用于帮助项目组进展中标识、控制和跟踪需求以及变更需求的一组活动。

3. 项目初始时的提问应该是context-free（与环境无关的）。The first set of context-free

questions focuses on the customer and other stakeholder,overall goals,and benefits。需求工程师可能会问：

①who is behind the request for this work？ ②who will use the solution？

③what will be economic benefit of a successful solution？ ④is there another source for the solution that you need？

4.质量功能部署（QFD）是一种将用户要求转化成软件技术需求的技术，QFD以最大限度地满足客户的方式来定义需求，贯穿于整个软件工程。QFD确认了三类需求：

10

①Normal requirement ②Expected requirement ③Exciting requirement QFD的三种deployment ①function deployment ②information deployment ③task deployment

5.The scenarios，often call use-case，provide a description of how the system will be used。

6. **Use-case：产生了一个参与者与系统的交互。从参与者的角度定义用例，用例从最后用户的角度描述了软件或系统。参与者（Actor）是人员或设备在和软件交互时所扮演的角色。Stakeholder可以访问每个用例而且可 以指定每个用例的相对优先级。

写一个完整的use-case：①文字②图 （P161）

7. 精化阶段进一步把需求扩展为分析模型（analysis model）

the intent of analysis model is to provide a description of the required information、functional、and behavioral domains for a computer-based system.

Analysis model中用到的UMLdiagram：

①activity diagram（活动图）： 描述某个受限环境中处理过程的活动序列 ②class diagram（类图）：列出传感器的属性和可以用于修改这些属性的操作

③uml state diagram （状态图）：一种表现系统行为的方法，该方法描绘系统状态以及导致系统改变状态的事件

④use-case diagram（用例图）：从用户的视角描述系统

8.The best negotiation strive for a \双赢)result。That is，the customer wins by getting the system or product that satisfies the majority of the customer's needs（获得满足大多数需求的系统或产品），and the software team wins by working to realistic and achievable budgets and deadlines（按照实际情况，在可实现的预算和时间期限内完成工作）。

第八章——创建分析模型

1. Requirements analysis

①results in the specification of software's operational characteristics ②indicates software's interface with other system elements ③establish constrains that software must meet

2. 需求分析向软件设计者提供信息（information）、功能（function）和行为（behavior）的表示，这些表示可以被转化为结构（architectural）、接口（interface）和构件级（component-level）的设计

3. 软件完成之后，analysis model和requirements specification 提供了a means for assessing quality。

4. 分析模型是系统描述和系统设计模型之间的桥梁

11

分析模型的三个主要目标（objective）： ①描述客户需要什么 ②为软件设计奠定基础

③定义在软件完成后可以被确认的一组需求

5. 域分析(domain analysis）是识别分析和详尽说明来自某个特定应用领域的公共需求（common requirements），特别是那些在应用领域内被多个项目重复使用的。

6. 两种analysis model的approach

①结构化分析（structure analysis）：是一种考虑数据和处理的分析建模方法，数据作为独立的实体转换。数据对象建模定义了对象的属性和关系，操作数据对象的处理建模应表明当数据对象在系统内流动时处理如何转换数据。

②面向对象分析（objected-oriented analysis）：就是检查定义为一组用例的问题域，尽量提取定义问题的类。关注于定义类和影响客户需求的类之间的协作方式。UML和统一过程主要是面对对象的。

7. Analysis modeling begin with data modeling（数据建模） ①data objects(数据对象)：

A. 数据对象是任何必须被软件理解的复合信息的表示

B. 数据对象只（only）封装数据，在数据对象内没有任何对数据操作的引用。 ②data attribute（数据属性）定义了数据对象的性质，可以用来： A. 为数据对象的实例（instance）命名 B. 描述这个实例（instance）

C. 建立对另一个表中的另一个实例的引用

③relationship（关系）指明数据对象相互连接的方式

④Cardinality（基数）描述了一个对象的出现次数与另一个对象出现次数的关联，有三种 A. 1：1 B. 1：n C. m：n

12

Modality（形态）A. 没有明确的必要性或关系是可选的，那么关系的形态是0 B如果关系必须出现一次，则形态是1

⑤ERD的三个元素：attributes、object、relationship。ERD主要目的是represent data objects and their relationships。

8.面对对象（object-oriented）分析

①attributes ：a collection of data values that describe a class

②class：encapsulate the data and procedural abstraction required to describe the behaviour of some real word entity。

③object：instance of a specific class。Objects inherit a class's attributes and operations。 ④operations：are objects procedures that're invoke when an object receives a message。

9. Scenario-based modeling

①analysis modeling with UML begins with the creation of scenarios in the form of use-case、activity diagram and swimlane diagrams。

②use-case的概念：describe a specific usage scenario in straightforward language from the point of view of a defined actor。

③一个UML activity diagram表现了实施某个功能时发生的活动和判定。

④一个UML swimlane diagram表现了活动流和一些判定，并指明由哪个参与者实施。

10. Flow-oriented modeling

①数据流图DFD采取系统的输入-处理-输出观点，流入软件的数据对象，经过处理元素转换，最后以结果数据对象的形式流出软件。数据或控制对象（带标记的箭头label arrow），转换（圆圈bubble），外部实体（方框boxes）

第一个数据流模型从整体上表现系统，随后的数据流图改进环境图，提供每个后续层增加的细节。

②Data flow modeling is a core modeling activity in structure analysis。 ③control flow model用到的地方：

A. 一大类应用问题是事件驱动（driven by events） B. 这类问题产生控制信息（control information） C. 处理信息非常关注时间和性能

11. Class-based model

①operation的大概分类（broad category）：

A. Manipulate data

B. Perform a manipulation

C.inquire about the sate of an object

D.monitor an object for the occurrence of a controlling event

②CRC(类、职责、协作者)可以用于定义类之间的联系，有三个部分：

A.class

B.responsibility C.collaborator

③A package(分析包) involves the categorization of analysis model elements into useful groupings. A packet is used to assemble a collection of related classes。

如果某个类实现一个解决方案，那么这个类就是解决方案的一部分；如果某个类只需要说明一个解决方案，那么这个类就是问题空间的一部分。

12. Behavioral model

13

①系统状态可以表现特定的外部可观察（externally observable）行为。 ②类的状态可以表现当系统执行功能时的行为。

13. 解释在面向对象系统中重要的特征： ①封装（encapsulation）： ②继承（inheritance）： ③多态（polymorphism）：

14. 类之间三种不同的通用联系： ①is-part-of（是??的一部分）

②has-knowledge-of（有??的知识） ③depends-upon（依赖??）

第九章——设计工程（design engineering）

1.四种设计：

①data/class design ②architectural design ③interface design ④component design

2.评价良好设计演化的三个特征：

①设计必须实现所有包含在分析模型中的明确需求

②对于代码生成人员、测试维护人员，设计必须是可读的、可理解的指南 ③设计必须提供软件的全貌，从实现的角度说明数据域、功能域和行为域

3.五个质量属性quality attributes（FURPS）功能性、易用性、可靠性、性能、可支持性 ①functionality ②usability ③reliability ④performance ⑤supportalility

4.集成成本与模块数成正比，工作量与模块数成反比

14

5.**信息隐藏（Information Hiding）：这是把系统分解为模块时的思想，即模块内部的数据与过程，应该对不需要了解这些数据与过程的模块隐藏起来。只有为了完成软件的总体功能而必须在模块间交换的信息，才允许在模块间进行传递。模块应该详细说明且精心设计以求在某个模块中包含的信息（算法和数据）不被不需要这些信息的其他模块访问。

6.内聚与耦合

①cohesion：is a qualitative indication of the degree to which a module focus on just one thing。显示了某个模块相关功能的强度，a cohesion module should just do one thing。

The higher the level cohesion，the easier the component is to implement，test，and maintain。 ②coupling：is a qualitative indication of the degree to which a module is connected to other modules and to the outside world。显示了模块间的相互依赖性。 应当尽量高内聚、低耦合

7.组织良好的设计类的四个特征： ①完整性与充分性 ②原始性 ③高内聚性 ④低耦合性

8.data design creates a module and/or information that is represented at a high level of abstraction(the customer/user's view of data)

9.The architectural design for software is the equivalent to the floor plan （平面图）of the house。 10. The interface design for software is the equivalent to a set of detailed drawings for the doors、windows、and external utilities of a house。

11.The component-level design for software is equivalent to a set of detailed for each room in a house.

10.叙述设计模式和框架的区别

基于模式的设计可以复用那些在过去已经被证明是成功的设计元素。

框架则是作为模式的拓展，为某个特定应用域内完整的子系统设计提供体系结构骨架。

第十章——体系结构设计

1.数据设计的目标

把在分析模型中定义的数据对象转化成软件构件级的数据结构，并且在必要时转化为应用程序级的数据库体系结构。

2.**软件体系结构：一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件外部可见属性以及他们之间的相互关系。体系结构并非可运行软件。

3.每种风格的体系结构包含： ①a set of components ②a set of connectors ③constraints

④semantic models(语义模型)

4. 与目标系统(target system)交互的系统表示为：

15

①superordinate systems（上级系统） ②subordinate systems（下级系统） ③peer-level systems（同级系统） ④Actors（参与者）

5. 原始模型（archetype）是一个类或者一个模式，描述了一个目标系统体系结构设计的核心抽象。但是随着体系结构设计的进行，这些抽象必须被进一步精化。

6. 体系机构设计中的三种依赖：

①sharing dependency（共享依赖）：消费者间或生产者间的依赖关系 ②flow dependency（流依赖）：生产者和消费者间的依赖关系

③constrained dependency（约束依赖）：在一组活动间相关控制流上的约束。

7.转换流（transform flow）：the overall flow of data occurs in a sequential manner and follows one，Or only a few，\straight line\。

8.事务流（transaction flow）：with a single item that triggers other data flow among one of many paths of a data flow diagram，transaction flow characterizes the information flow。

Within a DFD for a large system，both transform flow and transaction flow may be present。（在一个大的DFD中，交换流和事务流可能会同时出现）

9.在一些面向流模型中这两种类型的数据流都会经常遇到（encounter），这些流被分割成段，并且使用适当的映射获取程序结构。

10. 事务映射第一级分解分出软件控制层，第二级分解在合适的控制器下分布“第一线工作者模块”。

第十一章——构件级设计建模

1.在面向对象软件工程环境中，构件包括一个协作类集合。 2.传统构件承担的三个角色：

①control component（控制构件）

②problem domain component（问题域构件） ③infrastructure component（基础设施构件）

3.构件开发的原则

OCP原则的内容、优点和实现方法

开关原则（OCP）：模块应该对外延具有开放性，对修改具有封闭性 优点：无需对构件自身内部做修改就可以进行扩展的方式来说明构件

实现方法：设计者在那些可能需要扩展的功能与设计类本身之间分离出一个缓冲区 LSP、DIP、ISP、REP、CCP、CRP

4.那些体现出功能、层和通信等内聚性的类和构件，相对来说易于实现、测试和维护。 5.Persistent data source 包含①databases ②files

6.OCL对象约束语言complements UML by allowing a software engineer to use a formal grammar and syntax to construct unambiguous statements about various design model language。

OCL的四个最简单组成：语境（context）、特性（property）、操作（operation）、关键字（keyword）

16

7. 结构化编程是局限于逻辑流的设计技术，它有三种构造： ①顺序型（sequence） ②条件型（condition） ③重复型（repetition）

结构化设计的优点：reduce complexity，enhances readability、testability、and maintainability

8. 传统构件的三种设计表示： ①graphical——flowchart

②tabular——resultant decision table ③text-based formats

9. 在构建级设计中，面向对象的观点和传统的观点的区别?

面向对象的观点注重细化来自于问题域和基础设施域的设计类；而传统的观点则细化三种不同的构建或模块。

第十二章——user interface design

1. 用户接口设计的黄金法则（golden rule） ①place the user in control(置用户于控制之下)

②reduce the user's memory load（减少用户的记忆负担） ③make the user interface consistent（保持界面一致）

2.用户必须记住的东西越多，则越容易出错。减少用户记忆负担： ①减少对短期记忆的要求。

②建立有意义的缺省（meaningful defaults）

③定义直观的快捷方式（shortcuts that are intuitive） ④界面的布局应当基于真实世界的象征

⑤以不断进展（progressive）的方式揭示信息

3. 至于用户控制之下：

①以不强迫用户进入用户不必要的或不希望的动作的方式来定义交互方式 ②提供灵活的交互

③允许用户交互可以被中断和撤消

④当技能级别增加时可以使交互流水化并允许定制交互 ⑤使用户隔离内部技术细节

⑥设计应允许用户和出现在屏幕上的对象直接交互

4. 界面一致（interface consistent）的设计原则： ①允许用户将当前任务放入有意义的语境 ②在应用系列内保持一致性

③如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变它

用户以一致的方式展示和获取信息，意味着

①all visual information is organized according to a design standard

②input mechanisms are constrained to a limited set that is used consistently throughout the application。

③mechanisms for navigating from tasks to tasks are consistently defined and implemented

17

5. 用户界面设计的四种模型：

①user model：establish the profile of end-users of system。（建立系统最终用户的轮廓） ②design model：包括对软件的数据、体系结构、界面和程序上的表示。

③mental model心理模型（system perception系统感觉）：the image of the system that end-user carry in their heads。

④implementation model：结合了计算机的外在表现（界面的感觉），结合了所有用来描述系统语法和语义的支撑信息。

6. 用户界面设计分析的四个框架活动：

①user、task、and environment analysis and modeling ②interface design

③interface construction（implementation） ④interface validation

7. 用户界面设计模式（pattern）：Each of the example patterns presented would also have a complete component-level design，including design classes、attributes、operations、and interfaces。

8. 用户界面设计时遇到的问题： ①system response time ②user help facilities

③error information handling ④menu and command labeling

9. 评估时观察用户与界面交互，记录如下数据：

①number of tasks correctly completed over a standard time period ②frequency of actions ③sequence of actions

④time spent looking at the display ⑤number and types of error ⑥error recovery time ⑦time spent using help

⑧number of help references per standard time period

十三章——测试策略

1.测试的顺序：

①unit testing：充分利用测试技术，检查构件中每个控制结构的特定路径以确保完全覆盖，并最大可能地发现错误。

②integration testing：处理并验证与程序构造相关的问题。

③validation testing ：为满足所有的功能、行为和性能需求提供最后的保证

④system testing：验证所有的成分能合适地结合在一起，且能满足整个系统的功能/性能需求。

2. Guidelines lead to a successful software testing strategy （P361）

①specify product requirements in a quantifiable manner long before commence。（在最早开始测试之前，要以量化的方式规定产品需求）

18

②conduct formal technical reviews to assess the testing strategy and test cases themselves。（实施正式技术评审以评估测试策略和测试用例本身·）

3. unit test（单元测试）要测的单元： ①interface

②local data structure

③boundary conditions：确保模块在达到边界值的极限或受限处理的情形下仍能正确执行 ④independent paths（execution path） ⑤error handing paths

Because a component is not a stand-alone program（独立程序），driver and/or stub software （驱动软件和或桩软件）must be developed for each unit test。

4. Integration test（集成测试）：is a systematic technique for constructing the software architecture while at the same time conducting tests to uncover errors associated with interfacing 。 ①top-down（自顶向下）integration：

A. no drivers need to be written，但还是要stubs

B. The top down integration strategy verifies major control or decision points early in the process。

C.主控模块用作测试驱动程序，所有的桩模块替换为直接从属于主控模块的模块。

②bottom-up integration（自底向上）：the need for stubs is eliminated（不需要stubs )，排除了对复杂桩的需求。

③regression test（回归测试），为什么说回归测试是集成测试流程中的关键部分？

因为在集成测试策略的环境下，每加入一个新的模块作为测试的一部分时，软件会发生变更，这些变更可能会是使本来可以正常工作的功能产生问题，而回归测试只是重新执行已进行测试的某个子集，以确保变更没有传播不期望的副作用。

④smoking testing（冒烟测试）：一种滚动（rolling）的集成测试方法，是时间关键性（time-critical）项目的步进机制，它让软件团队频繁地对项目进行评估。

5.面对对象环境中的集成测试：

①基于线程的测试（thread-based），集成响应系统的一个输入或事件所需的一组类 ②基于使用的测试（use-based）

6. 调试使错误清除，发生在测试之后。三种调试方法（debugging tactics）： ①brute force（蛮力法）：最常用但最低效的方法 ②backtracking（回溯法）：常用用于小程序

③cause elimination（原因排除）：通过归纳演绎引入二分法 7.为什么需要“独立测试组”

独立测试组（ITG）的作用是为了避免开发人员进行测试所引发的固有问题，它可以消除可能存在的认识差异。

第十四章

1.可测性（testability）的特征

①operability ②observability ③controllability ④decomposability(可划分) ⑤simplicity ⑥stability ⑦understandability

19

2. A good test

①high probability of finding an error ②is not redundant

③should be best breed（最佳品种）

④should be neither too simple or too complex

3. 黑盒测试：knowing the function that a product has been designed to perform，可执行显示每个功能是可操作的，同时查找在每个功能中的错误。暗指在软件接口处执行测试，很少关心软件的内部结构。

黑盒测试找到的错误类型： ①功能不正确或遗漏 ②接口错误

③数据结构或外部数据库访问错误 ④行为或性能错误 ⑤初始化和终止错误

Equivalence partitioning（等价划分）是一种黑盒测试，divides the input domain of a program into classes of data from which test cases can be derived。

4. 白盒测试：knowing the internal working of a product，可以测试以保证内部操作依据规格说明执行，而且对所有的内部构件已进行了充分的说明。基于过程细节的封闭检查。

5. 黑盒测试与白盒测试的比较

黑盒测试是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例,是根据程序外部特征进行测试。

白盒测试是根据程序内部逻辑结构进行测试。 黑盒测试 白盒测试 ①适用于各阶段测试 ①可构成测试数据使特定程序部分得到测试 优 ②从产品功能角度测试 ②有一定的充分性度量手段 点 ③容易入手生成测试数 据 ③可或较多工具支持 ①不易生成测试数据(通常) ①某些代码得不到测试 缺 ②无法对未实现规格说明的部分进行测试 ②如果规格说明有误，则无法发现 点 ③工作量大，通常只用于单元测试，有应用局③不易进行充分性测试 限 性 是一种确认技术，回答 是一种验证技术，回答 质 “我们在构造一个正确的系统吗？” “我们在正确 地构造一个系统吗？”

6. Cyclomatic complexity（环复杂性）is a software metric that provides a quantitative measure of the logical complexity of a program（环复杂性是一种软件度量，它为程序的逻辑复杂度提供一个量化的测度）。When used in the context of the basis path testing method，the value computed for Cyclomatic complexity defines the number of independent paths。（环复杂性的值是独立路径的条数）

环复杂性V(G)=E-N+2 （E是流图边数，N是流图节点数）

20

6.scenario-based testing（基于场景的测试，是一种面对对象测试方法） concentrates on what the user does，not what the product does。意味着捕获用户必须完成的任务，然后在测试时使用它们及其变体。

问答题：

1.What is the difference between software and hardware?

①软件是设计开发的，而不是传统意义上生产制造的。 ②软件部会“磨损”。

③虽然整个工业向着基于构件的构造模式发展，然而大多数软件仍是根据实际的顾客需求定制的。

2.For the waterfall model, describe situations where this model can and cannot be used and why.

瀑布模型：通常用于需要对一个已有的系统进行明确定义的适应性调整或增强的时候；也可用于发生在一些新的开发项目上，但是需求必须是准确定义和相对稳定的。

在实际的不遵守瀑布模型的顺序，客户通常难以清楚描述所有的需求，以及软件工作是一个高速的，永不停止的变化流，特性，功能和信息内容都会变化的情况下不适合用瀑布模型（38）

3.Describe the conditions under which Incremental models should be used and what an “increment” means in terms of project work and delivery.

增量过程模型：初始软件需求有明确的定义，但是整个开发过程却不宜单纯用线性模型。同时，可能迫切需求为用户迅速提供一套功能有限的软件产品，然后再后续版本中再细化和扩展功能。在这种条件下，需要选用一种以增量的形式生产软件产品的过程模型。

4. Discuss the pros and cons of prototyping model and how it differs from the spiral model.

21

快速原型的优点在于尽可能快速地建造出软件原型，然后给用户评价，通过反馈可以确定客户的真正需求。

缺点是：①一种可能来自用户，他们舍不得将“活生生”的原型废弃不用，要求开发者仅作“少量修改”就可以使用，这使得软件管理往往陷入失效。②对于开发者，当他们熟悉原型后，明知它有许多不足，却不愿全部推倒重来，宁可在最终系统中保留一部分不理想的程序，结果造成并不完美的选择变成了系统的组成部分。

快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果，和瀑布模型不同的是，采用瀑布模型时候，软件的需求分析也可以再用户和系统分析员之间反复讨论，使之逐步趋于完善。但这种讨论始终是纸上谈兵，而原型模型则是“真枪实弹”，能够使用户立刻与想象中的目标系统作出比较。

5. List the key issues stressed by an agile philosophy of software engineering. （Page71）

软件工程的敏捷理念强调4个关键问题：具有控制力的自我组织团队对所展开工作的重要性；团队成员之间，开发参与者与客户之间的交流与合作；对“变更代表机遇”的认识；以及强调快速软件交付以让客户满意。

6. Describe the differences between software construction and software deployment.

软件的构造包括了编码和测试任务，从而为向客户和最终用户交付可运行软件做好准备。部署则包括了三个动作：交付，支持和反馈。用于现代软件工程本质上是演变的，因此部署并不是只发生一次。两者都是软件工程的通用框架活动，但是构件肯定是发生在部署之前，部署是构件的下一个活动。

7. What is the goal of business process engineering?（P102）

业务过程目标是定义一个能有效利用信息进行业务活动的体系。是一种系统工程方法，用以确定能够有效使用信息的业务架构。业务过程工程的目的是提供易于理解的数据结构，应用架构，还有满足业务战略和每个业务领域目标的基础设施。

8. In the context of systems engineering what is product engineering?

产品工程的目的是将用户期望的已定义的一组能力转变成真实产品。产品工程是从系统分析开始的系统工程，系统工程师确认用户需求，确定经济和技术可行性，将功能和性能分配到软件，硬件，人员，数据库等关键工程构建中。

9. What are the six steps for requirements engineering?

需求工程的六个步骤是：起始，导出，精化，协商，规格说明，确认和管理

10. What is equivalence partitioning as it applies to software testing? What is scenario-based testing? 等价划分是一种黑盒测试方法，它将程序的输入划分为若干的数据类，从中生成测试用例。理想的测试用例是可以单独的发现一类错误，否者在观察到一般错误之前需要进行许多测试用例，等价划分试图定义一个测试用例以发现一类错误，由此减少所需测试用例的总数。 基于场景的测试：它关心的是用户做什么，而不是产品做什么，捕获用户完成的任务，然后在测试时候使用它们及其变体。场景用来发现交互错误。这种测试倾向于用单一测试检查多个子系统。

11. Describe the general process of creating a data flow diagram (DFD).

从系统的基本功能模型（把整个系统看成是一个加工）开始，逐层地对系统进行分解。没分解一次，系统的加工数量就增多一些，加工的功能也具体一些。继续重复这种分解，直到所有的加工都足够简单为止。最终为待开发的系统画出一组分层的数据流图，以替代一张含有系统全部加工的包罗万象的总数据流图。

22

12. Which UML (unified modeling language) diagrams are useful in object-oriented analysis modeling?

静态图：用例图，类图，对象图，构件图，部署图。 动态度：状态图，时序图，协作图，活动图。

13. List the four design models required for a complete specification of a software design and the role of each.

14. How is a transaction center different from a transform center in a data flow diagram? （问题翻译：在数据流图中，事务中心和变换中心怎么样不同的呢）

答案：变换型结构由传入路径、变换中心和传出路径3部分组成，变换中心在其中起中间转换作用。事务型结构是指当外部信息沿着接受路径进入系统后，经过事物中心获得某一个特定值，就能据此启动某一条动作路径的操作。

15. Describe the differences between the software engineering terms coupling and cohesion? （coupling）耦合性：指一个模块与其他模块间的联系，也称为块件联系。 （cohesion）内聚性：指模块内部各个成分之间的联系，也称为块内联系。

16.What is the Unified Modeling Language (UML)?

统一建模语言，对软件进行可视化、规约、构造、文档化的一种语言。

17. What’s a Use-Case Diagram? Please give an example in UML.

用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于描述软件系统和外部参与者之间的交互，由系统边界、用例、参与者和关联等符号组成。

18. What’s an Activity Diagram? Please give an example in UML.

活动图显示动作流程及其结果，阐明了业务用例实现的工作流程。

19. What’s a Sequence Diagram, Collaboration Diagram respectively? What’s the difference between them?

Sequence Diagram（顺序图）：也叫时序图，用来描述对象之间的动态交互，着重体现对象间消息传递的时间顺序。以垂直轴表示时间，水平轴表示不同的对象。

（Collaboration Diagram）协作图：用于描述相互协作的对象间的交互和链接。

二则区别是：顺序图（时序图）着重体现交互的时间顺序，而协作图着重体现交互间的静态链接。

20. What are the steps needed to build an object-behavior model?

Evaluate the use-cases to understand the interaction sequence within the system.

Identify events that drive the interaction sequence and how the events relate to specific objects. Create an event trace for each use-case. Build a state transition diagram for the system.

Review the object-behavior model to verify accuracy and consistency.

21. Describe the differences between black-box testing and white-box testing? 黑盒测试：（也叫功能测试）根据被测试程序的功能来进行的测试。

白盒测试：（也叫结构设计）是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正 确工作。

区别：黑盒测试：主要从用户的输入和系统输出进行软件外部的测试。 白盒测试：主要对软件内部的逻辑业务进行测试。

23

本文来源：https://www.bwwdw.com/article/ruva.html