软件工程知识点总结

7.1软件的定义及特点

软件（ Software）是计算机系统中与硬件相互依存的另一部分，它是包括程序（Program） ，数据（Data）及其相关文档（ Document）的完整集合。

三个特点：

（1）软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性； （2）软件的生产与硬件不同，在它的开发过程中没有明显的制造过程； （3）在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。

7.2软件危机及其表现

软件危机（softward crisis）是指在计算机软件的开发和维护中所遇到的一系列严重问题。这些问题绝不仅仅是“不能正常运行的”软件才具有，实际上几乎所有软件都不同程度地存在这些问题。

具体地说，软件危机主要有下述一些表现。

（1）对软件开发成本和进度的估计常常很不准确。

（2）用户对“已完成的”软件系统不满意的现象经常发生。 （3）软件产品的质量往往靠不住。 （4）软件常常是不可维护的。

（5）软件通常没有适当的文档资料。

（6）软件成本在计算机系统总成本中所占的比例逐年上升。

7.3软件工程及三要素

软件工程：软件工程是采用工程的概念、原理、技术和方法来指导软件开发和维护的工程学科，以工程化的原理和方法来解决软件问题。

软件工程的特性：

（1） 软件工程关注于大型程序的构造 （2） 软件工程的中心课题是控制复杂性 （3） 软件经常变化

（4） 开发软件的效率非常重要 （5） 和谐地合作是开发软件的关键 （6） 软件必须有效地支持它的用户

（7） 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人

软件工程方法学包含3个要素：方法、工具和过程。

7.4软件生命周期

软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和 测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审 查、形成文档以供交流或备查，以提高软件的质量。 每个阶段的任务如下

问题定义阶段：该阶段的关键任务是要明确：要解决的问题是什么？ 可性行研究阶段：该阶段的关键任务是要明确：做不做？ 需求分析阶段：该阶段的关键任务是要明确：做什么？

概要设计(总体设计)阶段：该阶段的关键任务是要明确：怎么做？ 详细设计阶段：该阶段的关键任务是要明确：具体做法。

编码和单元测试阶段：该阶段的关键任务是：编码和单元测试。

综合测试阶段：该阶段的关键任务是通过各种类型的测试（及调试）使软件达到预定的要求。 软件维护阶段：该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的要求。

7.4.1瀑布模型

瀑布模型有以下优点

1）为项目提供了按阶段划分的检查点。

2）当前一阶段完成后，您只需要去关注后续阶段。 3）可在迭代模型中应用瀑布模型。

4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。

瀑布模型有以下缺点

1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 4）瀑布模型的突出缺点是不适应用户需求的变化。

“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。实际项目很少按照该模型给出的顺序进行，用户常常难以清楚地给出所有需求，用户必须有耐心，等到系统开发完成。

7.4.2 原型模型—快速原型模型

在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型（可运行的软件），然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。 优点：

（1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。 （2）缩短了开发周期，加快了工程进度。 （3）降低成本。

尽早发现需求，揭示风险 缺点：

⑴为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。

⑵为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。

⑶开发过程不便于管理。

7.4.3螺旋模型

螺旋模型的优点： （1）对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标

（2）减少了过多测试或测试不足 （3）维护和开发之间并没有本质区别 螺旋模型的缺点：

（1）风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大

（2）主要适用于内部开发的大规模软件项目，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险

（3）随着迭代次数的增加，工作量加大，软件开发成本增加

7.4.4增量模型

增量模型优点：

（1）在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。

（2）整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。 （3）逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。 （4）采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。 增量模型的缺点：

（1）在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。

（2）开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。 （3）多个构件并行开发，具有无法集成的风险。

7.4.5喷泉模型

主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征。 喷泉模型的优点

喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。

喷泉模型的缺点

由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

其特点如下：

（1）开发过程有分析、系统设计、软件设计和实现4个阶段。 （2）各阶段相互重叠，它反映了软件过程并行性的特点。 （3）以分析为基础，资源消耗成塔型。

（4）反映了软件过程迭代性的自然特性，从高层返回低层无资源消耗。 （5）强调增量开发，整个过程是一个迭代的逐步提炼的过程。

7.4.6构件组装模型

构件组装模型导致软件复用，而可复用性给软件工程师提供了大量的可见的益处。软件开发不

用一切从零开始，开发过程就是一个组装构件的过程，维护的过程就是对构件升级、替换和扩充的过程，大大提高了软件的开发效率。构件模型允许多个项目同时开发，降低了费用，提高了可维护性。

构件模型也存在一些缺点，如：由于存在多种构件标准，缺乏通用的构件组装结构标准，如果自行定义会引入较大的风险；构件可重用性和软件系统高效性之间不易协调；如果过分依赖构件，构件质量会影响最终的产品质量。

7.4.7 RUP

RUP是由Rational公司的Booch、Jacobson、Rumbaugh提出的软件过程模型，也称RUP（Rational Unified Process)。RUP重复一系列周期，每个周期由一个交付给用户的产品结束。

每个周期划分为初始、细化、构造和移交四个阶段，每个阶段围绕着五个核心工作流（需求、分析、设计、实现、测试）分别迭代。 模型见下图：

1.4个阶段

初始阶段：进行问题定义，确定目标，评估其可行性，降低关键风险。 细化阶段：制定项目计划、配置各类资源、建立系统架构（包括各类视图）。 构造阶段：开发整个产品，并确保产品可移交给用户。 移交阶段：产品发布、安装、用户培训。

在每个阶段的每次迭代的最后，用例模型、分析模型、设计模型、实现模型都会增量，每个阶段结束的里程碑处，管理层做出是否继续、进度、预算、是否给下一阶段提供资助等决定。

不同阶段工作流的侧重点不同，前两阶段大部分工作集中在需求、分析和架构设计上；在构造阶段，重点转移到详细设计、实现和测试上。

2.9个工作流

RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）。

商业建模：深入了解使用目标系统的机构及其商业运作，评估目标系统对使用它的机构的影响。 需求：捕获客户的需求，并且使开发人员和用户达成对需求描述的共识。 分析和设计：把需求分析的结果转化成分析模型与设计模型。 实现：把设计模型转换成实现成果。

测试：检查个子系统的交互与集成，验证所有需求是否都被正确地实现了，识别，确认缺陷并确保在软件部署之前消除缺陷。

部署：成功地生成目标系统的可运行版本，并把软件移交给最终用户。

配置和变更管理：跟踪并维护在软件开发过程中产生的所有制品的完整性和一致性。

软件项目管理：提供项目管理框架，为软件开发项目制定计划，人员配备，执行和监控等方面的实用准则，并为风险管理提供框架。

环境：向软件开发机构提供软件开发环境，包括过程管理和工具支持。

7.5 UML

UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具。 UML由以下5类图来定义： 第1类：用例图

第2类：静态图（包括类图、对象图和包图） 第3类：行为图（包括状态图和活动图） 第4类：交互图（包括时序图和协作图） 第5类：实现图（包括组件图和配置图）

第一类是用例图：从用户角度描述系统功能，并指出各功能的操作者。

第二类是静态图：包括类图，对象图，包图。类图描述系统中类的静态结构，不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等也包括类的内部结构（类的属性和动作）。

第三类是行为图：描述系统的动态模型和组成对象之间的交互关系，其中状态图描述类的对象所有可能的状态，以及事件发生时的状态的转移条件，通常，状态图为类图的补充，在实用上并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且状态发生改变的类画状态图，活动图描述满足用例要求所要进行的活动以及活动的约束关系，有利于识别并行的活动。

第四类是交互图：描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系，他强调对象之间消息发送的顺序。

第五类是实现图：其中构建图描述代码部件的物理结构和各部件之间的依赖关系，一个部件可能是一个资源代码部件，一个二进制部件或者一个可执行部件。它包含逻辑类和实际类的有关信息。部件图有利于分析和理解部件间的相互影响程度。

下面分别描述9个图。

7.5.1 类图

类图展示了一组类、接口和协作及它们间的关系，在建模中所建立的最常见的图就是类图。用类图说明系统的静态设计视图，包含主动类的类图——专注于系统的静态进程视图。系统可有多个类图，单个类图仅表达了系统的一个方面。要在高层给出类的主要职责，在低层给出类的属性和操作。

7.5.2对象图

对象图展示了一组对象及它们间的关系。用对象图说明类图中所反应的事物实例的数据结构和静态快照。对象图表达了系统的静态设计视图或静态过程视图，除了现实和原型的方面的因素外，它与类图作用是相同的。

7.5.3用例图

用例图展现了一组用例、参与者以及它们间的关系。可以用用例图描述系统的静态使用情况。在对系统行为组织和建模方面，用例图的是相当重要的。

用例(use case)：从用户的观点对系统行为的一个描述。 用来从用户的观察角度收集系统需求。

用例图表达系统的外部事物（参与者）与系统的交互，它表达了系统的功能，即系统所提供的服务。

整个软件项目的开发可以采用Use Case 驱动的方式进行。

7.5.4交互图

交互图展现了按一定的目的进行的一种交互，它由在一个上下文中的一组对象及它们间交互的信息组成。交互图也可用于描述一个用例的行为。顺序图和协作图都是交互图，顺序图和协作图可以相互转换。

顺序图和协作图都是交互图，它们既是等价的，又是有区别的。

顺序图和协作图都能等价的表现系统运行中对象通过消息发生的交互行为。

顺序图表示了时间的消息序列，便于分析交互的时序，但没有表示静态对象关系，顺序图可以有效地帮助人们观察系统的顺序行为。

协作图着重表示一个协作中的对象之间的联系和消息。

7.5.5顺序图

展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。用顺序

图说明系统的动态视图。

7.5.6协作图

展现了一组对象，这组对象间的连接以及这组对象收发的消息。它强调收发消息的

对象的结构组织，按组织结构对控制流建模。

协作图显示某组对象为了由一个用例描述的一个系统事件而与另一组对象进行协

作的交互图。

协作图只对相互间有交互作用的对象和这些对象间的关系建模，而忽略了其他对象

和关联。

协作图中包括如下元素：1.对象（Object）、2.链（Link）和3.消息（Message）。

协作图的用途：

如果按组织对控制流建模，应该选择使用协作图。协作图强调交互中实例间的结构关系以及所传送的消息。协作图对复杂的迭代和分支的可视化以及对多并发控制流的可视化要比时序图好。

协作图有别于时序图的两点特性： （1）协作图有路径 （2）协作图有顺序号

7.5.7状态图

展示了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态间的转移。一个状态图描述了一个状态机，用状态图说明系统的动态视图。它对于接口、类或协作的行为建模尤为重要，可用它描述用例实例的生命周期。 在任一给定的时刻，一个对象总是处于某一特定的状态。

状态图主要表现一个对象所经历的状态序列，引起状态或活动转移的事件，以及因状态或活动转移而伴随的动作。

7.5.8活动图

活动图是一种特殊的状态图，描述需要做的活动、执行这些活动的顺序（多为并行的）以及工作流（完成工作所需要的步骤）。它对于系统的功能建模特别重要，强调对象间的控制流程。

活动图实质上是一种流程图，只不过表现的是从一个活动到另一个活动的控制流。活动图描述活动的序列，并且支持对带条件的行为和并发行为表达。

7.5.9时序图

在一个运行的系统中，对象之间要发生交互，并且这些交互要经历一定的时间。

顺序图表达的正是这种基于时间的动态交互。重点是完成某个行为的对象类和这些对象类之间所传递的消息的时间顺序。

7.5.10构件图

构件图展现了一组构件之间的组织和依赖，用于对原代码、可执行的发布、物理数据库和可调整的系统建模。

组件图代表系统的一个物理实现块，代表逻辑模型元素如类、接口的物理打包。

7.5.11部署图

部署图展现了对运行时处理节点以及其中构件的配署。它描述系统硬件的物理拓扑结构(包括网络布局和构件在网络上的位置)，以及在此结构上执行的软件（即运行时软构件在节点中的分布情况）。用部署图说明系统结构的静态部署视图，即说明分布、交付和安装的物理系统

7.5.12区别

1.以描述系统状态转移为主的状态图和活动图

状态图：用来描述对象，子系统，系统的生命周期。通过状态图可以了解一个对象所能达到的所有状态，以及对象收到的事件对对象状态的影响。

活动图：显示动作及其结果。着重描述操作（方法）实现中所完成的工作以及用例实例或对象中的活动，它是状态图的一个变种。

状态图与活动图的区别：活动图主要描述动作及对象状态改变的结果。状态图主要描述的是事件对对象状态的影响。

2.以描述系统系统对象通讯和交互为主的协作图和序列图

序列图：描述对象是如何交互的。重点放在消息序列上，描述消息在对象间是如何收发的。

协作图：描述协作对象的交互与链接。

协作图和序列图的区别：协作图和序列图都是描述对象交互的，但是序列图强调的是时间，协作图强调的空间。

7.6需求分析与用例建模

7.6.1需求分析的任务

需求分析的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。---- 准确地回答“系统必须做什么?”。

需求分析的步骤： 需求获取 分析建模 文档编写 需求验证

7.6.2类图

类(Class)、对象(Object)和它们之间的关系是面向对象技术中最基本的元素。类图技术是OO方法的核心。

类图标加上它们之间的关系就构成了类图。

类图用于对系统静态设计视图建模。与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。

类图中可以包含接口，包，关系等建模元素，也可以包含对象，链等实例。

类图典型的应用在下面三类建模： （1）对系统的词汇建模 （2）对简单协作建模

（3）对逻辑数据库模式建模

类图通常包含下述内容：类、接口、协作、依赖、泛化和关联关系。

关系（Relationship）是事物间的关系。在类的关系中，最常用的4种分别为： 依赖（Dependency）：它表示类之间的使用关系 泛化（Generalization）：它表示类之间的一般和特殊的关系； 关联（Association）：它表示对象之间的结构关系 实现（Realization）：它是规格说明和其实现之间的关系。

类主要包含以下几个部分

（1）名称（Name）名称是每个类所必有的构成，用于和其他类相区分。 （2）属性（Attribute）类的一个组成部分描述了类所代表事物的属性 （3）操作（Operation）操作是对类的对象所能做的事务的抽象

类在UML中由专门的图符表达，是分成3个分隔区的矩形,顶端为类的名字，中间存放类的属性、属性的类型和值，第3个分隔区放操作、操作的参数表和返回类型，如下图：

7.6.3用例图

在UML中，一个用例模型由若干个用例图(use case diagram)描述。用例图是显示一组用例、参与者以及它们之间关系的图。

用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和行为，因此，对整个软件开发过程而言，用例图是至关重要的。

用例图定义和描述了系统的外部可见行为，是分析、设计直至组装测试的重要依据。 让用户参与前期的系统分析与设计。

用例图的组成： 用例（Use Case） 参与者（Actor） 关系(Relationship)

1.什么是参与者

参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物。 参与者可能是人、另外一个系统、时间的流逝等。

UML中，参与者用“人形”图标来表示，名字写在图标的下方。

参与者

2.什么是用例

用例（use case）一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能）。

参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题。 每个用例都必须有一个惟一的名字以区别于其他用例。 用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。用例的UML图标如图所示。 3.用例间、用例与参与者的关系

（1）泛化关系（Generalization）：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化：

（2）包含关系（Include）一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。

（3）扩展关系（Extend）：一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新行为插入到已有用例的方法。

（4）关联关系：关联关系表示参与者与用例之间的通信。

4.用例间的关系

（1）泛化关系

当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。

用例可以被特别列举为一个或多个子用例，这被称做用例泛化。 （2）包含关系

包含是指基本用例(base use case)会用到包含用例(inclusion)，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。包含用例是可重用的用例──多个用例的公共用例。

（3）扩展关系

将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。 扩展用例的行为是否被执行要取决于主事件流中的判定点。

扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。在以下几种情况下，可使用扩展用例：

a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；

b.表明只在特定条件（如例外条件）下才执行的分支流；

5.用例之间的关系

包含用例与扩展用例的区别

①相对于基础用例，扩展用例是可选的，而包含用例则不是。

②如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。 ③扩展用例的执行需要满足某种条件，而包含用例不需要。 ④扩展用例的执行会改变基础用例的行为，而包含用例不会。

6.识别用例的方法：

①参与者希望系统提供什么功能；

②系统是否存储和检索信息；如果是，这个行为由哪个参与者触发； ③当系统改变状态时，是否通知参与者；

④是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。

7.6.4活动图

1.什么是活动图

活动图是UML中描述系统动态行为的图之一，是描述系统或业务的一序列活动构成的控制流，它描述了系统从一种活动转换到另一种活动的整个过程。

2.活动图用途

活动图用于对系统的动态行为建模。

活动图常用来描述业务或软件系统的活动轨迹，描述了系统的活动控制流程。我们常用活动图对业务过程、工作流和用例实现进行建模。

活动图主要应用对两个方面建模：一是在业务分析阶段，对工作流程进行建模；二是在系统分析和设计阶段，对操作流程进行建模。

7.6.5面向对象分析建立的3类模型

对象模型、动态模型、功能模型

对象模型

对象模型表示了静态的、结构化的系统数据性质，描述了系统的静态结构，它是从客观世界实体的对象关系角度来描述，表现了对象的相互关系。该模型主要关心系统中对象的结构、属性和操作，它是分析阶段三个模型的核心，是其他两个模型的框架。[2]

⒈对象和类 ⑴对象。

对象建模的目的就是描述对象。 ⑵ 类。

通过将对象抽象成类，我们可以使问题抽象化，抽象增强了模型的归纳能力。 ⑶ 属性。

属性指的是类中对象所具有的性质（数据值）。 ⑷ 操作和方法。

操作是类中对象所使用的一种功能或变换。类中的各对象可以共享操作，每个操作都有一个目标对象作为其隐含参数。

方法是类的操作的实现步骤。 ⒉关联和链

关联是建立类之间关系的一种手段，而链则是建立对象之间关系的一种手段。 ⑴ 关联和链的含义。

链表示对象间的物理与概念联结，关联表示类之间的一种关系，链是关联的实例，关联是链的抽象。

⑵ 角色。

角色说明类在关联中的作用，它位于关联的端点。 ⑶ 受限关联。

受限关联由两个类及一个限定词组成，限定词是一种特定的属性，用来有效的减少关联的重数，限定词在关联的终端对象集中说明。

限定提高了语义的精确性，增强了查询能力，在现实世界中，常常出现限定词。 ⑷ 关联的多重性。

关联的多重性是指类中有多少个对象与关联的类的一个对象相关。重数常描述为“一”或“多”。 ⒊类的层次结构 ⑴ 聚集关系。

聚集是一种“整体－部分”关系。在这种关系中，有整体类和部分类之分。聚集最重要的性质是传递性，也具有逆对称性。

聚集可以有不同层次，可以把不同分类聚集起来得到一颗简单的聚集树，聚集树是一种简单表示，比画很多线来将部分类联系起来简单得多，对象模型应该容易地反映各级层次。

⑵一般化关系。

一般化关系是在保留对象差异的同时共享对象相似性的一种高度抽象方式。它是“一般---具体”的关系。一般化类称为你类，具体类又能称为子类，各子类继承了父类的性质，而各子类的一些共同性质和操作又归纳到你类中。因此，一般化关系和继承是同时存在的。一般化关系的符号表示是在类关联的连线上加一个小三角形。

⒋对象模型

⑴模板。模板是类、关联、一般化结构的逻辑组成。 ⑵对象模型。

对象模型是由一个或若干个模板组成。模板将模型分为若干个便于管理的子块，在整个对象模型和类及关联的构造块之间，模板提供了一种集成的中间单元，模板中的类名及关联名是唯一的

动态模型

动态模型是与时间和变化有关的系统性质。该模型描述了系统的控制结构，它表示了瞬间的、

行为化的系统控制

性质，它关心的是系统的控制，操作的执行顺序，它表示从对象的事件和状态的角度出发，表现了对象的相互行为。

该模型描述的系统属性是触发事件、事件序列、状态、事件与状态的组织。使用状态图作为描述工具。它涉及到事件、状态、操作等重要概念。

⒈事件

事件是指定时刻发生的某件事。 ⒉状态

状态是对象属性值的抽象。对象的属性值按照影响对象显著行为的性质将其归并到一个状态中去。状态指明了对象对输入事件的响应。

⒊状态图

状态图是一个标准的计算机概念，他是有限自动机的图形表示，这里把状态图作为建立动态模型的图形工具。

状态图反映了状态与事件的关系。当接收一事件时，下一状态就取决于当前状态和所接收的该事件，由该事件引起的状态变化称为转换。

状态图是一种图，用结点表示状态，结点用圆圈表示；圆圈内有状态名，用箭头连线表示状态的转换，上面标记事件名，箭头方向表示转换的方向。

功能模型

功能模型描述了系统的所有计算。功能模型指出发生了什么，动态模型确定什么时候发生，而对象模型确定发生的客体。功能模型表明一个计算如何从输入值得到输出值，它不考虑计算的次序。功能模型由多张数据流图组成。数据流图用来表示从源对象到目标对象的数据值的流向，它不包含控制信息，控制信息在动态模型中表示，同时数据流图也不表示对象中值的组织，值的组织在对象模型中表示。

数据流图中包含有处理、数据流、动作对象和数据存储对象。 ⒈处理

数据流图中的处理用来改变数据值。最低层处理是纯粹的函数，一张完整的数据流图是一个高层处理。

⒉数据流

数据流图中的数据流将对象的输出与处理、处理与对象的输入、处理与处理联系起来。在一个计算机中，用数据流来表示一中间数据值，数据流不能改变数据值。

⒊动作对象

动作对象是一种主动对象，它通过生成或者使用数据值来驱动数据流图。 ⒋数据存储对象

数据流图中的数据存储是被动对象，它用来存储数据。它与动作对象不一样，数据存储本身不产生任何操作，它只响应存储和访问的要求。

7.7设计阶段

7.7.1详细设计

详细设计阶段的根本目标是确定怎样具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。

详细设计的目标: 设计出的处理过程应该尽可能简明易懂。 详细设计的任务：

(1) 为每个模块确定采用的算法，选择某种适当的工具表达算法的过程，写出模块的详细过程性描述；

(2) 确定每一模块使用的数据结构；为以后的编写程序做好充分的准备。 (3) 确定模块接口的细节。

7.7.2总体设计

1.面向对象设计

面向对象设计的准则：优秀设计就是使得系统在其整个生命周期中的总开销最小的设计, 其主要特点就是容易维护。

面向对象设计（OOD，Object-Oriented Design）是面向对象分析到实现的一个桥梁。面向对象分析是将用户需求经过分析后，建立问题域精确模型的过程；而面向对象设计则根据面向对象分析得到的需求模型，建立求解域模型的过程。即分析必须搞清楚系统“做什么”，而设计必须搞清楚系统“怎么做”，从分析到设计不是传统方法的转换，而是平滑（无缝）过渡，而求解域模型是系统实现的依据。

静态结构设计：  类设计  包设计  接口设计

动态结构设计（行为和交互建模）：  对象如何进行交互的

2.GUI （图形用户界面）设计概述

对于用户来说，一个友好的界面是至关重要的。

用户界面（User Interface）的设计质量直接影响用户对软件产品的评价，从而影响软件产品的竞争力和使用寿命，因此，对人机界面的设计必须给予足够的重视。

良好的ＧＵＩ设计原则

1、关注用户及其任务，而不是技术 2、首先考虑功能，其次才是表现 3、与用户对任务的看法保持一致 4、设计要符合常见情况

5、不要分散用户对他们目标的注意力

6、促进学习，从外(用户)到里(设计人员)思考，而不是相反。 7、传递信息，而不仅仅是数据 8、设计应满足响应需求

9、通过用户试用发现错误，然后修复它

3.数据库设计

设计原则：

每一个类成为一个数据库表。 关系映射：

（1）一对多的关系映射为数据库表的主外键关联（1方的主键加入n方成为外键）

（2）一对一的关系映射为数据库表的主外键关联（1方的主键加入另一方成为外键）

（3）多对多的关系映射：产生第三张表，将两个多方的主键加入其中成为外键，两个外键的组合成为主键。

利用数据库三范式检查表，从而考察领域类图的分析是否合理，消除冗余数据。 检查数据是否能够反映用例视图的需要；进一步与用户再次确认使用的数据。

7.8注释

夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。注释决不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3到1/2，甚至更多。

注释分为两类：序言性注释和功能性注释。

1.序言性注释

通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。

序言性注释包括： 程序标题；

有关本模块功能和目的的说明； 主要算法；

接口说明：包括调用形式，参数描述，子程序清单；

有关数据描述：重要的变量及其用途，约束或限制条件，以及其它有关信息； 模块位置：在哪一个源文件中，或隶属于哪一个软件包；

开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。

2.功能性注释

功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样，而不要解释下面怎么做。

要点：

描述一段程序，而不是每一个语句； 用缩进和空行，使程序与注释容易区别；

7.9软件测试

软件测试的定义：软件测试是使用人工和自动手段来运行或测试某个系统的过程，其目的在于检测被测试软件系统是否满足规定的需要，或是弄清楚被测系统的预期结果与实际结果之间的差别。

黑盒测试：仅需要知道被测试对象的输入和预期输出，不需要了解代码实现的细节。测试方法

主要分为两类：功能层面的测试方法和函数层面的测试方法（边界值测试、等价类测试、基于决策表测试）。侧重于系统业务流程的梳理，是基于动态业务过程设计测试用例。

白盒测试：是针对程序代码展开的测试，分为静态测试和动态测试：关注对象包括源代码和程序结构。静态白盒测试的方法是代码检查。静态测试不需要运行程序和设计测试用例，侧重于源代码的检查和优化，直接查看源代码和执行代码，直接定位代码中的缺陷。动态测试侧重于程序结构的测试。

测试用例的定义：测试用例是一组测试输入，执行条件和预期结果。目的是要满足一个特定的目标。如果执行一条特定的程序路径或者检验是否符合一个特定的需求的用例。测试用例：输入+输出+测试环境测试环境包括：硬件环境，软件环境，网络环境，历史数据。

测试用例分为两个阶段：测试用例分析阶段，测试用例设计阶段。

7.9.1测试和调试的区别

1、目的不同

软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务，而是调试的任务.调试的目的是为了证明程序的正确，因此它必须不断地排除错误.它们的出发点不一样。前者是挑错，是一种挑剔过程，属于质盘保证活动。后者是排错，是一种排除过程，是编码活动的一部分。

2、任务不同

既然软件测试属于质量保证活动，因此它贯穿于整个开发过程.从需求分析开始，就要制订软件测试计划，软件设计时要设计系统软件测试、集成侧试用例，编码阶段要设计单元软件测试用例并进行单元软件测试，软件测试阶段要进行集成软件测试、系统软件测试等，直到产品交付。只要有修改就有软件测试，产品交付后同样。它是比较有规律的活动，有系统的方法、原则作指导。 而调试是编码活动的一部分，因此有编码就有调试.它的任务主要就是排错。调试的方法经常与使用的开发工具有关，例如:解释型的开发工具可以交互式调试，编译型开发工具就很难较好地查错。当然它有一些启发式的方法，它是一种比较依赖开发人员经验的活动。 3、指导原则和方法不同

软件侧试是一种有规律的活动，有一系列软件软件测试的原则.其中主要是制订侧试计划，然后严格执行.其次是一种挑剔性行为，因此它不但要侧试软件应该做的，还需要侧试软件不应该做的事情。调试所遵循的规律主要是一些启发式规则，是一个推理过程。例如使用归纳法、演绎法、回溯法等。

软件测试的输出是预知的，其软件测试用例必须包括预期的结果，而调试的输出大多是不可预见的，需要调试者去解释、去发现产生的原因。 4、操作者

因为心理状态是软件测试程序的障碍，所以执行软件测试的人一般不是开发人员，以使软件测试更客观、更有效，而调试人员一般都是开发人员.

7.9.2软件维护

软件维护活动类型总起来大概有四种：纠错性维护（校正性维护）、适应性维护、完善性维护或增强、预防性维护或再工程。

改正性维护

改正性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。这方面的维护工作量要占整个维护工作量的17%～21%。所发现的错误有的不太重要，不影响系统的正常运行，其维护工作可随时进行：而有的错误非常重要，甚至影响整个系统的正常运行，其维护工作必须制定计划，进行修改，并且要进行复查和控制。

适应性维护

适应性维护是指使用软件适应信息技术变化和管理需求变化而进行的修改。这方面的维护工作量占整个维护工作量的18%～25%。由于计算机硬件价格的不断下降，各类系统软件屡出不穷，人们常常为改善系统硬件环境和运行环境而产生系统更新换代的需求；企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。这些因素都将导致适应性维护工作的产生。进行这方面的维护工作也要像系统开发一样，有计划、有步骤地进行。

完善性维护

完善性维护是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。另外，还包括对处理效率和编写程序的改进，这方面的维护占整个维护工作的50%～60%，比重较大．也是关系到系统开发质量的重要方面。这方面的维护除了要有计划、有步骤地完成外．还要注意将相关的文档资料加入到前面相应的文档中去。

预防性维护

预防性维护为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。例如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。这方面的维护工作量占整个维护工作量的4%左右。

第一章

1.软件有哪些种类？

答：1.按功能特征进行划分：

(1)系统软件(2)支撑软件(3)应用软件

2.按规模大小进行划分

微型、小型、大型、甚大型、极大型

4.结合自己的亲身经历，谈谈软件工具在软件开发过程中的作用。 使软件开发更加模式化，工程化，从而提高软件开发的效率和封装性。

第二章

2.软件瀑布模型为什么要划分阶段？各个阶段的任务是什么？ 在软件开发早期，开发只是被简单地分成编写代码和修改代码两个阶段。往往在拿到项目后立刻编写程序，然后调试通过后直接交付给用户使用。如果应用中出现错误，或者有新的要求，都需要重新修改代码。这种小作坊式的软件开发方法有明显的弊端，如缺乏统的项目规划、不太重视需求的获取和分析、对软件的测试和维护考虑不周等，这些都会导致软件项目的失败。 概念阶段：计划、需求分析 开发阶段：设计、编码、测试 维护阶段：运行维护

3.举例说明哪些项目的开发适用于原型模型或螺旋模型，哪些不适于采用这两种模型。 螺旋模型适合于大型软件的开发，应该说它是最为实际的方法，它吸收了软件工程“演化”的概念，使得开发人员和客户对每个演化层出现的风险有所了解，继而做出应有的反应。 不适用:小型软件。 原型般是指对某种产品进行模拟的初始版本或者原始模型，在工程领域中具有广泛应用。 不适用:大型软件项目；含有对于计算量大、逻辑性较强的程序模块：

第三章

1.可行性研究的任务是什么？

可行性研究的任务是以最小的代价在尽可能短的时间内确定问题是否能够解决。简单的说，可行性研究的最终结果是决定项目y做还是小做”而不是“如何做”。 2.项目开发计划有哪些内容？ 引言(目的、背景、参考文献、术语)；项目概述(功能、条件、运行环境、产品、程序、文档、服务、验收标准、实施计划、工作任务分解、进度、预算、人员)

第四章

1.什么是需求工程？需求工程包括哪些活动？

需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的 门学科。它通过合适的工具和记号系统地描述待开发系统，及其行为特征和相关约束，形成需求文档；并对用户不断变化的需求演进给予支持。

一个良好的需求开发过程应该包括需求获取、需求分析与建模、编写需求规格说明书和需求评审4个主要活动。

2.需求工程过程包括哪些主要活动？ 需求开发过程应该包括需求获取、需求分析与建模、编写需求规格说明书和需求评审4个主要活动。 3.有哪两种主要的需求分析模型？它们的主要思想是什么？

答：面向对象分析模型，结构化分析模型。前者是采用面向对象的思想进行软件需求分析的建模过程，而后者模型的核心是DD，它是设计各种数据对象的总和。他们的模型分别起到了描述数据模型，功能模型与行为模型的作用。

4.需求规格说明书的主要作用是什么？应该包括哪些主要内容？ 作用： (1)作为用户方和开发方之间的合同，为双方相互了解提供基础。 (2)反映问题的结构，作为系统设计和编码的依据。 (3)作为测试和验收目标系统的依据。 内容： 用户可以通过需求规格说明书检查需求描述是否满足原来的期望。设计人员根据软件需求规格说明书的描述了解所需开发软件的功能和性能，以及开发软件时必须满足的约束，将其作为软件设计的依据。测试人员根据软件需求规格说明书中对产品的描述，设计测试计划、测试用例和测试过程。产品发布人员根据软件需求规格说明和用户界面设计编写用户手册和帮助信息

第五章

2.简述数据流图分解时的注意事项。

•上层可分解得快些（即分解成子数据处理个数多些），这是因为上层是综合性描述，对可读性的影(即分解成的子数据处理个数多些)，这是因为上层是综合性描述，对可读性的影响小。而下层应分解得慢性。

•在不影响可读性的前提下，应适当多分解成几部分，以减少分解层数。 3.数据字典的作用是什么？它有哪些基本内容？ •分解应自然，概念上要合理、清晰。 作用：数据字典作为分析阶段的工具，有助于改进分析人员和用户.间的通信，进而消除很多的误解，同时也有助于改进不同开发人员之间的通信；. 内容:数据字典的内容主要是对数据流图中的数据项、数据流、加工逻辑、数据存储和外部实体

第六章

1.什么是面向对象方法？与传统软件开发方法相比，面向对象方法有什么优点？ 是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法。 优点：

1.符合人们对问题的认识习惯 2.增强问题域与最终软件系统之间的衔接 3.易于维护和复用 4.易于开发大型软件产品

2.什么是模型？在软件开发过程中为什么需要建立模型？

在软件开发过程中，建立软件模型具有十分重要的作用，主要体现在以下几个方面：

有助于问题的简化，通过抽象降低复杂性；

有助于和其他开发小组成员，各种用户以及系统相关者进行交流；

有助于维护人员了解软件设计的思路和细节，为以后的维护和升级提供了文档。

第七章

1．面向对象分析包括哪些活动？应该建立哪些类型的模型？

面向对象分析OOA模型的过程包括理解用例模型、识别分析类、定义交互行为、建立分析类图、评审分析模型5个活动组成。

目标是建立一个符合问题域、满足用户需求的OOA模型。

2.什么是实体类、边界类和控制类？为什么将分析类划分成这3种类型？

实体类：用于描述必须存储的信息，同时描述相关的行为。实体类代表拟建系统中的核心信息。在RUP的有关文档中对实体类的解释为：“实体类是用于对必须存储的信息和相关行为建模的类。 边界类：在系统与外界之间，为它们交换各种信息与事件。边界类处理软件系统的输入和输出。在RUP的有关文档中对边界类的解释为：边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。

控制类：与业务过程相关，它们控制整个业务的流程和执行次序。在RUP的有关文档中对控制类的解释为：控制类用于对一个或几个用例所持有的控制行为进行建模。 控制类对象可以和边界对象交互，也可以和实体对象交互，但不能和用例的参与者直接进行交互。

第八章

1.什么是软件设计？它的目标和任务是什么？ <1>软件设计：在需求分析的基础上通过抽象和分解将系统分解成模块，确定系统功能的实现。即把软件需求转换为软件包表示的过程。 <2>目标：软件设计的最终目标是产生一个设计规约，该规约包括体系结构、描述数据、接口和构件的设计模型。 软件设计的任务，就是把分析阶段产生的软件需求规格说明转换为用适当手段表示的软件设计文档。

2.完成良好的软件设计应遵循哪些原则？

模块化与模块独立性；抽象与逐步求精；信息隐藏。 3.如何理解模块独立性？用什么指标来衡量模块独立性？

<1>模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他的模块的接口是简单的。

<2>一般采用两个准则度量模块独立性，即模块的内聚性和模块间的耦合性 4.说明软件设计阶段的任务和过程 软件设计分两步完成，即总体设计与详细设计。第个阶段是总体设计，即概要设计或初步设计。这、阶段主要确定实现目标系统的总体思想和设计框架，确定程序由哪些模块组成，以及模块与模块之间的关系，最后提出概要设计说明书。第二个阶段是详细设计，即过程设计或构件级设计，其任务是通过对结构表示进行细化，确定各个软件构件的详细数据结构和算法，产生描述各个软件构件的详细设计文档。

5.试说明软件体系结构在软件设计阶段中的重要性。

良好的体系结构设计是决定软件系统成功的重要因素。软件体系结构设计的好坏往往会成为一个系统设计成败的关键。通常，软件体系结构涉及软件的总体组织、全局控制、数据存取及子系统之间的通信协议等。

6.简述面向对象设计阶段要做的工作。

OOD主要包括三个方面的工作：系统体系结构设计、用例实现方案设计和用户界面设计。

第十一章

1.简述程序设计语言的基本特征及分类。

基本特征包括心理特性，工程特性和技术特性三个方面。语言的的—心理特性对人机通信的质量有主要的影响；语言的工程特性对软件开发成功与否有重要的影响，此外语言的技术特性也会影响软件设计的质量 •按程序设计语言的历史发展过程，计算机语言可分为机器语言、汇编语言、高级程序设计语言。 •按与机器的依赖程度，可分为低级、中级和高级语言。 •按应用范围，可分为通用语言与专用语言两大类，通用语言义可细分为系统程序设计语言、科学计算语言、事务处理语言和实时控制语言等。 •按程序的设计方法，可分为命令性语言和作用性语言。 •按语言的成分，可以分成顺序语言、并行语言和实时语言等。 •按语言的组成方法，可以分成汇集式语言和可扩充语言。 2.为了具有良好的程序设计风格，应该注意哪些方面的问题？

要形成良好的程序设计风格，应从源程序文档化、数据说明、语句构造、输入输出和追求效率几个方面加以注意。

3.什么是软件测试？软件I则试的原则有哪些？

软件测试是按照特定的规则，发现缺陷而执行程序的过程。

一个好的测试用例是指尽可能找到迄今为止尚未发现缺陷的用例。 一个成功的测试是指揭示了迄今为止尚未发现缺陷的测试。 软件测试的原则：

(l)所有的测试都应该能追溯到用户需求。 (Z)应该在测试之前就制定出测试计划。

(3)Pareto原理可应用于软件测试。

(4)测试应从“小规模”开始，逐步转向“大规模” (S)穷举测试是不可能的。

(6)既要做通过性测试，又要做失效性测试。

(D为了达到最佳的测试效果，应该由独立的第三方从事测试工作。

第十四章

1.为什么说软件维护是不可避免的？

因为软件的开发过程中，一般很难检测到所有的错误，其次软件在应用过程中需要随用户新的要求或运行环境的变化而进行软件的修改或纠正软件开发过程未发现的错误，增强、改进和完善软件的功能和性能，以适应软件的发展，延长软件的寿命，软件的维护是不可避免的。 2.什么是软件再工程？软件再工程的主要活动有哪些？

指在逆向工程所获信息的基础上修改重构已有的系统，产生的―个新版本，或者说利用这些信息修改或重构软件系统的工作。

它定义了6为活动r即库存目录分析、文档重构、逆向工程、代码重构、数据重构、正向工程。 3.软件调试与软件测试有什么区别？ 1、目的不同 软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务，而是调试的任务。调试的目的是为了证明程序的正确，因此它必须不断地挤除错误.它们的出发点不一样“前者是挑错，是一种挑剔过程，属于质盘保证活动。后者是排错，是-种排除过程，是编码活动的部分• 2、任务不同 既然软件测试属于质量保证活动，因此它贯穿十整个计发过程.从需求分析开始，就要制订软件测试计划，软件设计时要设计系统软件测试、集成侧试用例，编码阶段要设计单元软件测试用例并进行单元软件测试，软件测试阶段要进行集成软件测试、系统软件测试等，直到产品交付。只要有修改就有软件测试，产品交付后同样。它是比较有规律的活动，有系统的方法、原则作指导。

而调试是编码活动的部分，因此有编码就有调试它的任务主要就是排错。调试的方法经常与使用的开发工具有关，例如解释型的开发工具可以交互式调试，编译型开发工具就很难较好地查错。当然它有些启发式的方法，它是.种比较依赖开发人员经验的活动。 3、指导原则和方法不同 软件侧试是种有规律的活动，有一系列软件软件测试的原则.其中主要是制U侧试计划，然后严格执行。其次是种挑剔性行为，因此它不但要侧试软件应该做的，还需要侧试软件个应该做的事情。调试所遵循的规律主要是些启发式规则，是”个推理过程。例如使用归纳法、演绎法、回溯法等。

软件测试的输出是预知的，其软件测试用例必须包括预期的结果，而调试的输出大多是不可预见的，需要调试者去解释、去发现产生的原因。 4、操作者 因为心理状态是软件测试程序的障碍，所以执行软件测试的人一般不是开发人员，以使软件测试更客观、更有效，而调试人员一般都是开发人员•

5、操作环境、配置、工具不同 调试在开发的编码环境下进行。如果编码使用解释型语言，则可以进行人机交互式调试，设里断点、单步调试等。如果编码使用编译型语言，也可以设置断点、显示调试变量值等。而软件测试是在软件测试环境下进行，直接运行开发完成的程序，可能不再需要一些开发时的驱动程序、动态链接库等.使用不同的工具，环境配置也不同。

简答题，

1.什么是软件工程？请分析软件工程的目标是什么？ 答案：软件工程是：1将系统化的、规范的、可度量的方法应用于软件的升发、运行和维护过程，也就是说将工程化应用于软件开发和管理之中；2对1中所选方法的研究” 软件工程旨在开发满足用户需要、及时交付、不超过预算和无故障的软件，其主要目标如下: a)实现预期的软件功能，达到较好的软件性能，满足用户的需求。 b)增强软件过程的可见性和可控性，保证软件的质量。 c)提高所开发软件的可维护性，降低维护费用。 d)提高软件开发生产率，及时交付使用。 e)合理预算开发成本，付出较低的开发费用。

3.根据相关的法律，对于侵犯软件著作权的行为，根据情节应当给予什么处罚？ 对于侵犯软件著作权的行为，要根据情况承担停止侵害、消除影响、赔礼道歉、赔偿损失等民事责任；损害社会公共利益的，由著作权行政管理部门责令停止侵权行为，没收违法所得，没收、销毁侵权复制品，并处罚款；情节严重的，著作权行政管理部门可以没收用子制作侵权复制品的材料、工具、设备等；触犯刑律的，依法追究刑事责任。

4根据你的理解，列举出职业化软件工程师要注意的三个主要问题，请给出理由。 没有唯一答案。 1)不遵守标准和规范：职业化的重要特征是遵守行业标准，不能肆意按照自己的想象来发挥。自从人们认识到软件危机以来，总结软件开发的失败教训和成功经验，并把它们总结成为最佳实践，进而形成标准，要充分利用这些最佳实践和标准来指导软件过程。任何闭门造车、想当然的行为都是不被提倡的，注定要走弯路。 2)对待计划不严肃：软件工程强调计划性，计划的内容包括；设备资源、进度安排、人力资源、任务分配等等。在项目的进行中要跟踪计划执行情况，记录计划执行过程中的偏差，对任何变更都要经过评审和批准才能付诸行动。 3)不主动与人沟通：软件不可见的特性，需要软件工程师进行大量书面的、口头的或面对面的沟通，沟通的目的是为了使相关的人员了解项目的进展、遇到的问题、应用的技术、采用的方法。 5．软件工程为什么要强调规范化和文档化？. 软件工程强调规范化和文档化。规范化的目的是使众多的开发者遵守相同的规范，使软件生产摆脱个人生产方式，进入标准化、工程化的生产方式。文档化是将软件的设计思想、设计过程和实现过程完整地记录下来，以便于后人的使用和维护，在开发过程中各类相关人员借助于文档进行交流和沟通。另外，在开发过程中产生的各类文档使得软件的生产过程由不可见变为可见，便于管理

者对软件生产进度和开发过程进行管理。在用户最终验收时可以通过对提交的文档进行技术审查和管理审查，保证软件的质量。

6．请简单说明结构化分析的主要步骤。 根据用户的需求画出初始的数据流程图，写出数据字典和初始的加工处理说明(lPO图)，实体关系图。以初始数据流程图为基础，从数据流程图的输出端开始回溯。在对数据流程图进行回溯的过程中可能会发现丢失的处理和数据，应将数据流程图补充完善。对软件性能指标、接口定义、设计和实现的约束条件等逐一进行分析。系统分析人员与用户起对需求分析的结果进行复查。根据细化的需求修订开发计划。编写需求规格说明书和初始的用户手册，测试人员开始编写功能测试用的测试数据。

7．设计类的属性时必须要定义是哪两项？ 设计类的属性时必须要定义的内容： 1)属性的类型：设计属性时必须要根据开发语言确定每个属性的数据类型•如果数据类型不够，设计人员可以利用已有的数据类型定义新的数据类型。 2)属性的可见性。在设计属性时要确定公有属性、私有属性、受保护属性。活动图反映系统中从一个活动到另一个活动的流程，强调对象间的控制流程。活动图特别适合描述工作流和并行处理过程。具体地说活动图可以描述一个操作过程中需要完成的活动；描述一个对象内部的工作；描述如何执行组相关的动作，以及这些动作如何影响它们周围的对象；说明个业务活动中角色、工作流、组织和对象是如何工作的。 顺序图用于描述一组交互对象间的交互方式，它表示完成某项行为的对象和这些对象之间传递消息的时间顺序。

8面向对象的分析通常要建立三个模型， 请问三个模型的作用？ a)功能模型：表达系统的详细需求，为软件的进一步分析和设计打下基础。在面向对 象方法中，由用例图和场景描述组成。 b)对象模型：表示静态的、结构化的系统“数据”性质。描述现实世界中实体的对象以及它们之间的关系，表示目标系统的静态数据结构。在面向对象方法中，类图是构件对象模型的核心上具。 c)动态模型：描述系统的动态结构和对象之间的交互，表示瞬时的、行为化的系统的“控制”特性。面向对象方法中，常用状态图、顺序图、合作图、活动图构件系统的动态模型。

9.面向对象的设计活动中，有构架师、用例工程师和构件师参加，他们每个角色的职责是什么？ 构架设计的目的是要勾画出系统的总体结构，这项工作由经验丰富的构架设计师主持完成。该活动以用例模型、分析模型为输入，生成物理构架、子系统及其接口、概要的设计类(即设计阶段定义的类)。 根据分析阶段产生的高层类图和交互图，由用例设计师研究已有的类，将它们分配到相应的用例中。检查每个用例的功能，这些功能依靠当前的类能否实现，同时检查每个用例的.特殊需求是否有合适的类来实现。细化每个用例的类图，描述实现用例的类及其类之间的相互关系，其中的通用类和关键类可用粗线框区分，这些类将作为项目经理检查项目时的重点。 经过前面两个活动，构架设计师已经将系统的构架建立起来，用例设计师按照用例的功能将每个类分配给相应的用例。现在要由构件工程师详细设计每个类的属性、方法和关系。 10.提高程序可读性有哪些招数？对你来讲比较灵验的是哪些？ a)源程序文件头说明，函数应有函数头说明，内容包括：程序标题；有关该模块功能和目的说明；主要算法说明；接O说明，包括调用形式、参数描述、子程序清单、有关数据的说明。

b)主要变量(结构、联合、类或对象)的定义能够反映其内在含义。 c)变量定义最规范化，说明的先后次序固定。

d)处理过程的每个阶段和典型算法前都有相关注释说明。

三、简答题：

2、什么是软件工程？包括哪些内容？

答: 软件工程：用科学知识和技术原理来定义、开发、维护软件的一门学科。 软件工程的内容：

１）软件开发技术：软件开发方法、软件开发过程、软件开发工具和环境。 ２）软件开发管理：软件管理学、软件经济学、软件心理学。

软件工程的目标:是成功的建造一个大型软件系统，所谓成功是要达到以下几个目标：①付出较 低的开发成本;②面到要求的软件功能;③取得较好的软件性能;④开发的软件易于 移植;⑤需要较低的维护费用;⑥能按时完成开发任务，及时交付使用;⑦开发的软 件可靠性高;

软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工 程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、 确认以及维护等活动。

软件工程的框架可概括为：①目标、②过程和③原则。

软件工程的原则：是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。 基本原理：⑴用分阶段的生命周期计划严格管理；⑵坚持进行阶段评审；⑶实行严格的产品控制； ⑷采用现代程序设计技术；⑸结果应能清楚地审查；⑹开发小组的人员应该少而精； ⑺承认不断改进软件工程实践的必要性；（工程化的方法开发软件基本原理）

软件工程方法学：软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工 程学科。

软件工程方法学包括：①传统方法学（结构化范型）和②面向对象方法学。

面向对象的要点: ①把对象作为融合了数据及在数据上的操作行为的统一的软件构件。②把所 有对象都划分成类。③按子类与父类的关系,把类组成一个层次结构。④对象彼此之 间仅能通过传递消息互相联系。

软件工程方法学三要素是：①方法；②工具；③过程。 3、 软件生命周期由哪三个时期组成，又划分为哪8个阶段？

答：软件生存周期：一个软件从提出开发要求开始直到该软件报废为止的整个时期。软件生命周期是

由：⑴软件定义时期；⑵软件开发时期；⑶软件维护时期三个时期组成的。又划分为：①问题定义、②可行性研究、③需求分析、④总体设计、⑤详细设计、⑥编码和单元测试、⑦综合测试、⑧维护八个阶段。

1、问题的定义及规划 此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

2、需求分析 在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。\"唯一不变的是变化本身。\"，同样需

求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。 3、软件设计 此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。 4、程序编码 此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。

5、软件测试 在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。

6、运行维护 软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

4、 什么是白盒测试法？什么是黑盒测试法？

答：白盒测试：所谓白盒测试就是在知道产品内部工作过程或程序内部结构和处理过程的前提下,检

验产品内部动作是否按照规格说明书的规定正常进行或按照程序内部的逻辑测试程序,检验程序中的每条通路是否都能按照预定要求正确工作的测试方法.因此白盒测试又称为结构测试或逻辑测试。

从覆盖源程序语句的详尽程度分析，大致有以下一些不同的覆盖标准：⑴语句覆盖；⑵判定覆盖；⑶条件覆盖；⑷判定/条件覆盖；⑸条件组合覆盖；⑹点覆盖；⑺边覆盖；⑻路径覆盖。 黑盒测试：所谓黑盒测试是指在完全不考虑程序的内部结构和处理过程的前提下,在程序接口进行的测试,它只检查程序功能是否能按照规格说明书的规定正常使用,程序是否能适当地接受输入数据产生正确的输出信息,并且保持外部信息的完整性.因此,又称为功能测试。特点：等价类划分、边界值分析、因果图、错误推测。

优点 1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了 2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因 缺点 1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴

2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作

3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不

是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。 5、 什么是集成测试？非渐增式和渐增式有什么区别？渐增式如何组装模块？

答：将模块组合起来成为一个完整的系统对其进行测试。非渐增式是将模块先进行单元测试然后组装

在一起进行测试。渐增式是逐个将未测试的模块组装到已经测试过的模块上去进行集成测试，每加入一个就测试一次。非渐增式需要桩模块和驱动模块、非渐增式开始可以并行测试、渐增式可以及时的发现接口错误，非渐增式很难发现接口发现错误、渐增式开始不能并行测试、渐增式测试比较彻底。渐增式组装模块有自顶向下和自底向上两种组装方式。

6、 什么是确认测试？该阶段有那些工作？

答：调试的目的是发现错误的位置并改正错误。简单调试、演绎调试、递归调试、回溯调试。 7、 面向对象方法学与传统方法学有何区别？

答：面向对象方法学注重的是软件的重用性，而传统的方法学则在这一问题解决上不理想。面向对象

方法学和传统的方法学在问题分析上的切入点不同。面向对象里面，系统是长出来的，传统的方法学里面，系统是放进去的。传统方法：⑴结构化开发方法，注重的是系统功能，自顶向下，从大到小的功能分解，从DFD到MSD，

往往系统需求变化最大就是功能，一段较长的时间内，商业的流程可能已经发生了很大的变化，这样基于功能和过程的方法显然难以维护的，代码重用率可想而知，而商业过程中的数据可能变化不会很大，⑵信息工程法，注重的是数据，事件流－＞信息流，（资金流，物流）－＞数据流，数据的输入和转化输出，数据流程图，状态转化图，事件顺序图，过程依赖图，两者都是由事件驱动．面向的是问题，是为了要解决某一个具体问题，其观察事物的方法不是本体客体本身，而是对本体客体相互作用过程抽象，转化成逻辑模型。面向对象方法学：其切入点是客观世界的主体和客体，通过封装实现了信息交流的安全，抽象和继承使得事物的一完整表述和容易修改新的变化，聚合，关联反映事物间的相互作用和关系，通过关联类管理，这样把事物和事物间的关系分开．减少了复杂度，便于维护，大大提高了代码重用率。

8、 软件开发模型有几种?各有什么特点?

软件生存周期模型：是描述软件开发过程中各种活动如何执行的模型。（模型：是为了理解事物而 对事物做出一种抽象，它忽略不必要的细节，它也是事物的一种抽象形式、一个规划、一个程式。） 主要模型：①瀑布模型；②增量模型；③螺旋模型；④喷泉模型；⑤变换模型；⑥基于知识的模 型等

瀑布模型：①它提供了一个摸板，这个摸板使分析、设计、编码、测试和支持的方法可以在该摸 板下有一个共同的指导；②虽然有不少缺陷但比在软件开发中随意的状态要好得多。 快速原型模型：①开发速度快，质量有保证。②对信息系统特别有效。

增量模型：①人员分配灵活，刚开始不用投入大量人力资源，当核心产品很受欢迎时，可增加人

力实现下一个增量。②当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。③具有一定的市场。

螺旋模型：①对于大型系统及软件的开发，这种模型是一个很好的方法。开发者和客户能够较好

地对待和理解每一个演化级别上的风险。②对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试或测试不足所带来的风险。 9、 可行性研究：⑴系统流程图；⑵数据流程图；

系统流程图：系统流程图是概括地描绘物理系统的传统工具。基本思想是用图形符号以黑盒子形

式描绘组成系统的每个部件。其表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。

数据流程图：简称DFD,是描述数据处理过程的工具。数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程，是一种功能模型。作用：它以图形的方式描绘数据在系统中流动和处理的过程,反映系统必须完成的逻辑功能。基本符号有四种：→,箭头,表示数据流；○,圆或椭圆,表示加工； =,双杠,表示数据存储；□,方框,表示数据的源点或终点。

可行性研究的任务： (1)经济可行性。确定待开发系统是否值得投资开发。(2)技术可行性。对待

开发的系统进行功能、性能和限制条件的分析，确定在现有资源的条件下技术风险有多大，系统是否能实现。 (3)法律可行性。确认待开发系统可能会涉及的任何侵犯、妨碍、责任等问题。(4)抉择。对系统开发的不同方案进行比较评估。

10、 什么是字据字典？其作用是什么？它有哪些条目？

字据字典：简称ＤＤ，就是用来定义数据流图中的各个成分具体含义的，它以一种准确的、无二义性 的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。

作 用：⑴为系统的分析\\设计及维护提供了有关元素的一致的定义和详细的描述.⑵为分析人员查找

数据流图中有关名字的详细定义而服务的.⑶它和数据流图共同构成了系统的逻辑模型,是需求规格说明书的主要组成部分.

条 目：数据流、数据项、数据存储、基本加工。 11、 需求分析的任务是什么?

答: 需求分析是指：开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈 述转化为完整的需求定义，再由需求定义转换到相应的形式主义功能规约(需求规格说明)的过程。 需求分析的主要任务：⑴正确地确定对系统综合要求,充分理解和表达用户的需求。⑵通过结构分

析的方法对系统进行分解,以确定软件系统的主要成分或软件系统的构成。⑶是对以上已进行的两项工作进行描述,以形成需求文档。⑷编写用户手册；⑸编写验收计划；⑹修正可行性研究阶段所制订的软件项目开发计划。 12、结构化分析方法：结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系， 自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。

主要工具：数据流图、数据词典、结构化英语、判定表和判定树。 3种模型：①数据模型、②功能模型和③行为模型。

验证软件需求：⑴一致性；⑵完整性；⑶现实性；⑷有效性；

结构化分析方法步骤： ①了解当前系统的工作流程,获得当前系统的物理模型。②抽象出当前系 统的逻辑模型。③建立上标系统的逻辑模型。④作进一步补充和优化。

结构化程序设计基本要点：⑴采用自顶向下、逐步求精的程序设计方法；⑵使用三种基本程序控 制结构构造程序（①顺序方式；②选择方式；③循环方式；）。⑶主程序员组的组织形式。

13、总体设计过程由两个主要阶段组成：①系统设计阶段，确定系统的具体实现方案；②结构设计阶段， 确定软件结构。

模块：软件系统的层次结构正是模块化的具体体现。将整个软件划分成若干单独命名和可编址的部分，称之为模块。 模块化：就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集 成起来构成一个整体，可以完成指定的功能满足用户的需求。模块是构成程序的基本构件。

模块化的根据：把复杂的问题分解成许多容易解决的小问题，原来的问题也就容易解决了。这就是模块化的根据。 14、衡量模块独立性的两个标准是什么？它们各表示什么含义？ 两个定性的度量标准：耦合与内聚性。

耦合：是模块之间的相对独立性(互相连接的紧密程度)的度量。模块之间的连接越紧密，联系越多， 耦合性就越高，而其模块独立性就越弱。按耦合度从低到高依次有7种耦合方式：①非直接耦

合（独立运行）；②数据耦合（用参数表传递简单数据）；③标记耦合（传递数据结构或者一部分）；④控制耦合（传递的信息包括控制模块的信息）；⑤外部耦合（模块与软件之外的环境有关）；⑥公共耦合（多个模块引用同一全局的数据区）；⑦内容耦合（访问内部数据，代码重叠或者多个入口）。

内聚：是模块功能强度(一个模块内部各个元素彼此结合的紧密程度)的度量。一个模块内部各个元素

之间的联系越紧密，则它的内聚性就越高。按内聚度从低到高依次有7种内聚种类： ①偶然内聚（模块完成的多个任务，任务之间的关系松散）；②逻辑内聚（模块完成逻辑相关的一组任务）；③瞬时内聚（模块的所有任务必须在同一时间间隔内执行）；④过程内聚（模块的处理元素相关而且按照特定的次序执行）；⑤通信内聚（模块的所有元素集中在一个数据结构区域上）；⑥顺序内聚（模块的处理元素相关，必须顺序执行）；⑦功能内聚（模块完成单一的功能，各个部分协调工作，而且不可缺少）

耦合和内聚的关系：一般说来，在系统中各模块的内聚越大，则模块间的耦合越小。但这种关系并不

是绝对的。耦合小使得模块间尽可能相对独立，从而各模块可以单独开发和维护。内聚大使得模块的可理解性和维护性大大增强。因此，在模块的分解中应尽量减少模块的耦合，力求增加模块的内聚。

15、Jackson方法的步骤： (1)实体动作分析：从问题的描述中，提取软件系统要产生和运用的实体，以及

现实世界作用于实体上的动作。(2)实体结构分析：把作用于实体的动作或由实体执行的动作，按时间发生的先后次序排序，构成进程，并用一个层状的Jackson结构图表示。(3)定义初始模型：把实体和动作表示成一个进程模型，定

义模型与现实世界的联系。(4)功能描述：说明与已定义的动作相对应的功能，为已定义的动作加入功能函数。(5)决定系统时间特性：对进程加入时间因素，对进程调度特性进行评价和说明。(6)实现：设计组成系统的硬件和软件，实现系统的原型。

16、测试阶段的信息流：这个阶段的输入信息有两类： (1)软件配置，包括需求说明书、设计说明书和源 程序清单等；

(2)测试配置，包括测试计划和测试方案。

自顶向下集成：从主控制模块开始，沿着程序的控制

层次向下移动，逐渐把各个模块结合起来。在把附属于主控制模块的那些模块组装到程序结构中去时，或者使用深度优先的策略，或者使用宽度优先的策略。

深度优先的结合方法先组装在软件结构的一条主控制通路上的所有模块。选择一条主控制通路取决于应用的特点，并且有很大任意

性。而宽度优先的结合方法是沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。

集成测试的策略：当使用渐增方式把模块结合到程序中去时，有自顶向下和自底向上两种集成策略。 17、 决定软件可维护性的因素：⑴可理解性；⑵可测试性；⑶可修改性；⑷可移植性；⑸可重用性；

软件维护:是指在软件已经交付使用之后,为了改正错误或满足新的需要而修改软件的过程.软件维护 是软件生命周期的最后一个阶段,也是持续时间最长代价最大的一个阶段。 软件的可维护性可以定义为:维护人员理解,改正和改动软件的难易程度。

18、 对象：是对现实世界实体的正确抽象，它是由描述内部状态表示静态属性的数据，以及可以对这些数 据施加的操作，封装在一起所构成的统一体。对象之间通过传递消息互相联系，以模拟现实世界中不同事物彼此之间的联系。

对象的特点：①以数据为中心；②对象是主动的；③实现了数据封装；④本质上具有并行性；⑤模块 工程规模：此系统中应包含接受模块和信息处理与输出模块。 可能的解决方案及其评价 从三方面研究每种解决方法的可行性：

(1).技术可行性 使用现在的技术完全可以实现该系统

(2).经济可行性 这个系统的开发成本不高，节省的经济资源以及经济消息能够超过该系统的开发成本 (3).操作可行性 该教学事务管理系统在校院的各个办公室都可以实现，操作人员为在校师生，所以不存在技术、能力问题。 推荐行动方针 通过从技术，经济，可操作三方面的研究，分析的出结论，此系统是可行的。 16.构成E-R图的基本要素是实体型、属性和联系，其表示方法为：

· 实体型(Entity)：用矩形表示，矩形框内写明实体名；比如学生张三丰、学生李寻欢都是实体。如果是弱实体的话，在矩形外面再套实线矩形。

· 属性(Attribute)：用椭圆形表示，并用无向边将其与相应的实体连接起来；比如学生的姓名、学号、性别、都是属性。如果是多值属性的话，再椭圆形外面再套实线椭圆。如果是派生属性则用虚线椭圆表示。

· 联系(Relationship)：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型（1 : 1，1 : n或m : n）。 比如老师给学生授课存在授课关系，学生选课存在选课关系。如果是弱实体的联系则在菱形外面再套菱形。(猜考画图，或25题) 第一章 软件工程介绍  软件的特性

1． 软件是设计开发的，而不是传统意义上的生产制造的。 2． 软件不会“磨损”。 3． 虽然整个工业向着基于构件的构造模式发展，然而大多数软件扔是根据实际的顾客需

求定制的。  计算机软件的七大分类：系统软件、应用软件、工程/科学软件、嵌入式软件、产品线软件、Web应用软件、人工智能软件。 

遗留系统发生系统演化的原因：1.软件需要修改其适应性，从而满足新的计算环境或者技术的需求；2.软件必须根据新的业务需求进行升级；3.软件必须扩展以具有与更多现代系统和数据库的协作能力；4.软件架构必须进行改建以适应多样化的网络环境。  软件神话：管理者，用户，从业者  软件的定义：程序、数据和文档。 

软件工程的目的就是为开发高质量的软件产品提供一个工程框架。 第二章 过程综述

 软件工程的三个要素：工具，过程，方法。

 通用软件过程框架：沟通，策划，建模，构建，部署。 

能力成熟度模型：第0级，不完全级；第1级，已执行级；第2级，已管理级；第三级，已定义级；第4级，已定量管理级；第5级，优化级。

第三章 过程模型

 简述惯例框架包含的主要活动：沟通、策划、建模、构建、部署。  简述瀑布模型所包含的主要框架活动：策划、建模、构建、部署。 

简述瀑布模型在实际运用中所面临的问题（缺点）：“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。实际项目很少按照该模型给出的顺序进行；用户常常难以清楚地给出所有需求；用户必须有耐心，等到系统开发完成。

演化过程模型产生的背景：业务和产品需求经常变化、严格的交付时间、了解了核心产品和系统需求后没有定义产品或系统扩展的细节问题 

简述基于原型开发模型的软件开发过程：在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型（可运行的软件），然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。 沟通-》快速策划-》建模快速设计-》构建模型-》部署交付品及反馈

 简述原型开发的缺点：1.为了使原型尽快的工作，没有考虑软件的总体质量和长期的可

维护性。2.为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。3.开发过程不便于管理  统一过程的三个特点：用例驱动，以架构为核心，迭代并增量

 简述统一过程（UP）的5个阶段的主要内容：起始，细化，构建，转换和生产  螺旋模型强调了其他模型均忽略了的（风险分析） 

横切关注点的定义：一个信用卡处理系统的核心关注点是借贷/存入处理，而系统级的关注点则是日志、事务完整性、授权、安全及性能问题等许多关注点，我们叫它横切关注点 第四章 敏捷视角下的过程 

软件工程的敏捷理念强调4个关键问题：1.具有控制力的自我组织团队对所开展工作的重要性；2.团队成员之间、开

发参与者与客户之间的交流与合作；3.对“变更代表机遇”的认识；4.以及强调快速软件交付以让客户满意。 

简述极限编程（XP）过程模型所包含的4个主要框架活动：策划，设计，编码，测试 第五章 系统工程

 计算机系统的6个系统要素：软件，硬件，人员，数据库，文档，规程

 Hatley-Pirbhai建模方法：用户界面，输入，系统功能和控制，输出，维护和自检  系统环境图（System Context Diagram）的表示方法（实例） 第六章 需求工程

 需求工程的过程：起始，导出，精化，协商，规格说明，确认和管理 

在项目（起始）阶段，软件工程师会询问一些似乎与项目无直接关系的问题，目的是对

问题、方案需求方、期望方案的本质、客户和开发人员之间初步的交流和合作的效果建立基本的谅解。

 为什么导出需求这么困难：范围问题，理解问题，易变问题。  用例的定义：讲述了能表达主题场景的故事：最终用户如何在一特定环境下和系统交互 

在需求工程的导出阶段，三个主要的需求收集活动是：主持人会议、QFD和用户场景开发 第七章 构建分析模型

 分析模型在系统描述和设计模型之间建立桥梁。

 分析模型必须实现的目标：1。描述客户需要什么；2。为软件设计奠定基础；3。定义在软件完成后可以被确认的一组需求。

 分析模型的所有元素都可以直接跟踪到设计模型。

 分析模型的4个元素：基于场景的元素，面向信息流的元素，基于类的元素，行为元素  UML泳道图是活动图的一种变形，可以让建模人员表示用例所描述的活动流，同时指示哪个参与者或分析类对活动矩形所描述的活动负责。

 UML状态图为每个类表现活动状态和导致这些活动状态变化的事件  UML顺序图说明事件如何引发一个对象到另一个对象的转移

 简述CRC建模的内容：CRC提供了一个简单方法，可以识别和组织与系统或产品需求相关的类。  使用UML类图来举例说明组合和聚合之间的区别  使用UML类图举例说明关联和依赖之间的区别

系统分析的经验原则（1） 系统开发是面向客户的，应从客户的角度考虑。

（2） 诸如系统开发生命周期之类的产品更新换代机构应该在所有的信息系统开发项目中建立起来。

（3） 信息系统开发的过程并不是一个顺序的过程，它允许步骤的重叠和倒转等。 （4） 如果系统的成功可能性受到很大限制时，应取消整个项目。 （5） 文档材料是系统开发生命周期中重要的可递交成果，应加以重视 第八章 设计工程 

简述良好设计的三个特征：1。设计必须实现所有包含在分析模型中的明确需求，而且必须满足客户期望的所有隐含需求；2。对于那些生成代码的人和那些进行测试以及随后维护软件的人而言，设计必须是可读的、可理解的指南；3。设计必须提供软件的全貌，从实现的角度说明数据域、功能域和行为域。  设计模型包含的四种元素是什么：数据/类设计、体系结构设计、接口设计、构建级设计

 软件体系结构的定义：软件的整体结构和这种结构为系统提供概念上完整性的方式  模块应该详细说明且精心设计以求在某个模块中包含的信息不被不需要这些信息的其他模块访问



重构的定义：是使用这样一种方式改变软件系统的过程：不改变代码设计的外部行为而是改进其内部结构

 举例说明逐步求精 

框架和设计模式之间的区别：框架能使应用程序的开发简单，价格低廉，但是开发框架不

是一件容易的事。它是一个需要领域和设计经验的反复过程。设计模式可以简化这个过程，因为它提供了对过去经验的抽象。框架能高度抽象同一领域内的问题，进而降低开发难度和强度。因此，在软件开发过程中把框架和模式配合起来使用，可以极大地提高软件的重用。框架是软件，而设计模式是软件的知识 第九章 进行体系结构设计 

简述软件体系结构的作用：1。软件体系结构的表示有助于对计算机系统开发感兴趣的各方（共利益者）开发交流；2。体系结构突出了早期设计决策，这些决策对随后的所有软件工程工作有深远的影响，同时对系统作为一个可运行实体的最后成功有重要作用。3。体系结构“构建了一个相对小的，易于理解的模型，该模型描述了系统如何构成以及其构建如何一起工作”

 软件体系结构的典型分类：以数据为中心，数据流体系结构，调用和返回体系结构，面向对象体系结构，层次体系结构（以图例来说明） 

体系结构环境图所包含的要素，以图例来说明 第十二章 软件测试策略

 简述软件测试策略的螺旋模型：单元测试，集成测试，确认测试，系统测试 

简述单元测试中驱动程序和桩程序的作用：驱动程序只是一个“主程序”，它接收测试用例数据，将这些数据传递给（将要测试的）构件并打印相关结果。桩程序的作用是替换那些从属于将要测试的构件或被其调用的构件。  集成测试的两种方式：一步到位和增量集成

 试以图例描述自顶向下集成测试方法的过程  简述确认测试的两种主要方法：α测试和β测试  系统测试的主要方法：恢复测试，安全测试，压力测试，性能测试  三种调试方法：蛮力法，回溯法，原因排除法 第十三章 测试战术

 好的测试所具有的特性：1。好的测试具有较高的发现错误的可能性；2。好的测试是不冗余的；3。好的测试应该是“最佳品种”4。好的测试应该既不太简单也不太复杂。 

黑盒测试的定义：所谓黑盒测试是指在完全不考虑程序的内部结构和处理过程的前提下,在程序接

口进行的测试,它只检查程序功能是否能按照规格说明书的规定正常使用,程序是否能适当地接受输入数据产生正确的输出信息,并且保持外部信息的完整性.因此,又称为功能测试。

白盒测试的定义：所谓白盒测试就是在知道产品内部工作过程或程序内部结构和处理过程的前提下,

检验产品内部动作是否按照规格说明书的规定正常进行或按照程序内部的逻辑测试程序,检验程序中的每条通路是否都能按照预定要求正确工作的测试方法.因此白盒测试又称为结构测试或逻辑测试。  基本路径测试的环复杂度计算方法和独立路径集合的识别V(G)=E-N+2;其中E为流图

的边数，N为流图的结点数。  控制结构测试的3个主要方法：条件测试，数据流测试，循环测试  黑盒测试的两个主要方法：等价类划分，边界值分析  类级可应用的测试方法：随机测试，划分测试  面向对象的类级划分测试的主要方法：基于状态划分，基于属性划分，基于类别划分 

以图例说明从行为模型导出测试用例 第十四章 产品度量

 软件度量为产品内部属性的质量评估提供了一种（定量）方法，从而可以是软件工程师在产品开发出来之前进行质量评估

 软件测量的5个主要活动：公式化，收集，分析，解释，反馈 

面向目标的软件测量（GQM范型）的内容：1。确定特定过程活动的明确的测量目标或将要评估的产品特性；2。定义一组必须回答的问题以达到目标；3。确定被良好公式化的度量以帮助回答这些问题 

有效软件度量的属性1。简单的和可计算的2。在经验上和直觉上有说服力3。一致的和客观的4。单位和量纲的使用是一致的。5。编程语言的独立性6。高质量反馈的有效机制