全套电子课件：软件工程-第九套

1SoftwareEngineering软件工程精品课程2第三章传统软件工程技术简介结构化程序的发展3.1结构化程序的开发流程与特点3.2结构化程序与面向对象程序开发的比较3.3结构化程序的应用3.433.1结构化程序的发展结构化程序设计(StructuredProgramming)是瑞士计算机科学家尼克劳斯·沃思（NiklausWirth）于1971年，基于其开发程序设计语言和编程的实践验，首次提出了“结构化程序设计”的概念。 结构化程序的定义如下：

“如果一个程序的代码仅通过顺序、选择和循环这三种控制结构组合、连接而成，并且仅有一个入口和一个出口，则称这个程序是结构化的。”4结构化程序的控制结构结构化程序设计循环顺序选择5只使用“顺序”、“选择”和“循环”3种基本控制结构进行程序设计是结构化程序设计的主要内容。随着IBM公司1971年在《纽约时报》系统中成功使用了结构化程序设计。结构化程序设计成为上世纪70年代初到90年代初，最为成功的软件设计与开发模型。但在面向对象方法的广泛使用后，大型软件开发基本上抛弃了结构化程序设计方法，而只在较小的模块一级使用。63.2结构化程序开发的流程与特点结构化软件开发方法

即所谓的SASD方法，也称为面向功能的软件开发方法或面向数据流的软件开发方法。它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，并用结构图来描述软件的结构，最后是结构化编程（SP）。

7结构化开发的特点

结构化开发方法产生过程的抽象，这些抽象把软件视为处理流，定义构成一系列步骤的算法，每一步骤都是带有预定义输入和特定输出的一个过程，把这些步骤串联在一起可产生合理的稳定的贯通于整个程序的控制流。在结构化开发方法中，数据结构是应算法步骤的要求而开发的。数据结构贯穿于过程，提供过程需要传送给它的操作的信息。系统的状态是一组全局变量，这组全局变量保持了状态的值，把它们从一个过程传送到另一个过程。83.2.1结构化程序设计的分析与建模分析原则与软件需求规约

结构化分析是结构化软件开发的第一步，结构化分析确定了软件要做什么。软件需求规约又叫软件需求说明，是结构化分析的最终产物。数据建模

数据建模是组织数据使其结构化的过程。一般来说，软件开发的早期关注于概念数据模型，细化后得到逻辑数据模型。实体-关系图

实体-联系图（E-R图），提供了表示实体型、属性和联系的方法，用来描述现实世界的概念模型。是概念数据模型的高层描述所使用的数据模型或模式图，它为表述这种实体联系模式的数据模型提供了图形符号。构成E-R图的基本要素是实体型、属性和联系，其表示方法如图3-1所示。9图3-1实体联系图的基本成分10数据流图(DFD)

数据流图是软件设计开发过程中概念模型设计的重要图形表示法，它是从数据传递和加工的角度，以图形的方式来刻画数据流和转换的信息建模技术。它提供层次结构，让分析人员能够方便的表示任意抽象级别上的信息系统或其子系统，并支持问题分解、逐步求精的分析方法。数据流图中具有四种基本成分，如图3-2所示。11图3-2数据流图的基本成分及其表达符号12haha数据流表示数据的流动情况；加工表示对数据的加工处理过程，它的名字应能简明扼要地表明所完成的是什么加工；数据存贮在数据流图中起着保存数据的作用，指向数据存贮的数据流可以理解为写数据，从数据存贮引出的数据流可以理解为读数据，双向数据流可以理解为修改数据。在数据流图中，如果有两个以上数据流指向一个加工或从一个加工中引出，则这些数据流之间往往存在一定的关系。我们通常用图3-3所示符号表示这种关系。13图3-3多个数据流与加工关系的表示14状态转换图状态转换图是描述一个实体基于事件反应的动态行为，显示了该实体是如何根据当前所处的状态，对不同的事件做出反应的。状态转换图与数据流图有本质的不同，数据流图侧重于状态的描述。状态转换图的条件和一个过程的输入数据流相对应，并且还与控制的流出相对应。状态图的符号集包括5个基本元素：初始起点，它使用实心圆来绘制；状态之间的转换，它使用具有开箭头的线段来绘制；状态，它使用圆角矩形来绘制；判断点，它使用空心圆来绘制；以及一个或者多个终止点，它们使用内部包含实心圆的圆来绘制。15数据字典数据字典是包含所有系统数据元素定义的仓库。在这里，数据元素的定义必须是精确的、严格的和明确的。数据字典的定义包括过程描述、数据流定义、数据元素定义和数据存储定义。

163.2.2结构化程序设计的原则与方法模块化模块化就是把程序划分成若干个模块，每个模块都具有某个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能，实现问题的求解。层次图层次图用树状层次结构描述系统各个组成部分之间的关系，层次图中的一个矩形框代表一个模块，方框间的连线表示调用关系。层次图十分清晰的反映了系统结构。结构图系统结构图是软件系统的模块层次结构，表达了程序模块之间的关系，反映了整个系统的功能实现，即将来程序的控制层次体系。系统结构往往用树状或网状结构的图形来表示。17数据结构数据结构是指同一数据元素类中各个数据元素之间的关系。数据结构分别为逻辑结构、存储结构（物理结构）和数据的运算。程序流程图程序流程图(ProgramFlowDiagram简称PFD图)又称为程序框图。使用程序流程图的主要优点是，很直观地描述了程序的控制逻辑，便于初学者掌握，而且其表现方式较为灵活，使用起来非常方便。PAD图问题分析图(ProblemAnalysisDiagram,简称PAD)是由日本日立公司设计的,它针对程序流程图的某些特点，进行了适当的改进。它把程序过程控制结构表示成二维树的图形，是一种具有很强的结构化特征的分析工具。183.2.3测试单元测试（Unittest）单元测试是对程序最小单元——模块的测试。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。初步的单元测试是由程序员自己来完成，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试用例。执行单元测试，就是为了证明这段代码的行为和期望的一致。

集成测试(Integrationtest)

集成测试是在单元测试的基础上，将所有的软件单元按照概要设计规格说明的要求组装成子系统，然后测试子系统各部分是否达到或实现相应技术指标及要求的活动。在集成测试之前，单元测试应该已经完成。集成测试最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。19系统测试(Systemtest)

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否能够提供系统方案说明书中指定功能的有效方法。它目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计要求。203.2.4软件维护定义：所谓软件维护，就是指在软件交付使用之后，为了改正软件错误或者满足用户新的需要而修改软件的过程。特点：软件维护需要的工作量很大，平均来说，大型软件的维护成本高达开发成本的4倍左右。许多软件开发组织把60％以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命的延长，这个百分比还在持续上升。总的来说有以下三点：

1、结构化维护与非结构化维护差别巨大。

2、维护的代价高昂。

3、维护的问题很多。213.3结构化程序与面向对象程序开发的比较空格上个世纪60年代后期，开始出现面向对象的概念。到80年代中期，面向对象的设计与分析技术逐步成型。到90年代，面向对象的程序设计逐渐成为软件开发的重要方法，而今天，它已经成为软件开发的首选方法和必备条件。空格为什么采用面向对象技术，面向对象技术的概念和特点是什么？在本章，仅从一个程序实例的角度，使大家对结构化程序设计和面向对象程序设计的区别有一个感性上的认识。

22例子：空格电梯是人们日常生活中经常使用和乘坐的设备，我们就不妨以电梯的控制程序为例，看看结构化程序设计与面向对象设计的本质区别。

电梯的控制规则在这里不作赘述。需要说明的是，我们主要是分析结构化设计和面向对象设计的区别，鉴于有些知识是后续才介绍的内容，这里仅进行软件顶层的设计，重要的是了解分析问题的方法和思路，而不是实现细节。233.3.1结构化程序设计方法结构化程序设计是面向过程的设计，我们研究的是系统的工作流程，具体的讲是数据和状态的变化过程。明确输入与输出及功能要求要求：针对楼层按钮和电梯内按钮的状态要求，控制电梯的正确运行。我们将所有数据分为外部输入和内部状态两类：24Diagram外部输入数据：楼层按钮：boo：UpButton[N]，DownButton[N]；电梯内部按钮：bool：button[N]，DoorOpen，DoorClose；数据内部数据：电梯当前楼层：int：CurrentFloor；电梯运行方向set：CurrentRunDirection={UP，DOWM}；

25系统硬件结构图图3-4系统硬件结构图26显然，软件分为底层信号获取模块、控制执行模块和上层控制策略处理模块。其软件结构图如图3-5所示。

图3-5软件结构图27空格显然，信号获取、执行驱动和系统初始化的模块都比较简单，不再说明，仅对电梯控制策略处理模块进行进一步说明。其中，仅需对电梯停顿规则和运行方向调整规则进行说明：电梯停顿规则：

1本楼层有与电梯运行同方向的停顿请求（按钮）；

2或电梯内有本楼层的停顿请求（按钮）；

3或已到顶层或底层（包括后续同方向无停顿请求）；方向调整规则：

1若电梯内有后续楼层的同向停顿要求（按钮）；

2或后续楼层有停顿请求；则保持方向不变；否则反向。28空格到这里，我们用结构化设计方法对电梯系统的分析已基本完毕。这里我们给出的是程序设计的基本框架，而不是具体实现。但是，我们可以看到，结构化程序设计时，设计人员必须面对所有数据和控制流程。何时获取数据，何时进行计算，如何驱动执行机构等必须都安排好顺序。事实上，往往整个程序执行工程都必须全部清晰地反映在设计者的头脑中，才能进行流程控制和理顺全部的数据与时序。下面让我们看看用面向对象的程序方法是如何做的。293.3.2面向对象程序设计方法空格现在我们再来看看面向对象设计的方法。要让程序设计者在头脑中准确记住所有的输入数据、输出数据和状态关系，往往是十分困难、甚至难以做到的事。面向对象设计与结构化程序设计方法的最根本区别，是我们不需要去考虑所有的数据、输出和状态等，而我们只关心有哪些对象构成，每个对象能做什么？我们再来考虑电梯控制程序，我们首先考虑在这个过程中都有哪些对象，从系统需求中我们知道有：大厦、电梯、楼层、按钮等，我们把这些对象细化到与程序有关的对象：大厦是没有直接意义的，电梯又由按钮、电梯门和电梯执行机构组成，当然，还有每层的楼层按钮，以及电梯控制器：决定电梯的上升、下降停止和开门与关门。30空格在面向对象设计时，每一个对象是独立的，它根据自己的状态和外部信息决定自己的动作。那么，我们只要将每一个对象的数据和功能设计完成，整个系统就设计完成了。而不用将全部的数据和控制顺序全部考虑在头脑中。我们设计电梯控制系统由楼层按钮类（FloorButton）、电梯按钮类（ElevatorButton）、电梯门类（ElevatorDoor）、电梯控制器类（ElevatorControler）、电梯执行器类（ElevatorActor）构成。31空格让我们以“楼层按钮类”为例，来看看类的内部构造，以便让我们对“类”有一个初步认识：楼层按钮类（FloorButton）：

classFloorButton{private：

boolUP，DOWN；//按钮“上”、“下”的状态

public：

pressUp（）；//按下“上”按钮

pressDown（）；//按下“下”按钮

cleanUp（）；//清楚“上”按钮

CleanDown（）；//清除“下”按钮

}32空格也许我们现在还看不懂类是怎样构造出来的，没有关系，在后面的章节中我们会学到有关的知识，这里只要认识就可以了。空格将前面所列出的类一一构造出来后，面向对象的分析也可基本考一段落。我们可以看到，面向对象的程序设计，更符合人们日常的思考习惯和工作方法，各个对象都有独立的状态和方法，使软件工程师将更多的精力放在应用问题的处理上，而不再是复杂的程序结构和控制顺序上。随着后续章节的说明，大家会对面向对象程序设计方法有越来越多的认识。333.4结构化程序的应用ATM机是人们日常生活经常使用的设备，我们给出它的需求，请大家尝试按结构化程序设计的方法设计该系统的数据结构、软件结构、模块划分和各个模块的流程图。ATM机功能需求：①系统功能语言选择（中文、英文、日文）用户合法性检验用户刷卡、6位数密码②网络通讯实现与银行数据库系统的联接③帐户基本管理功能查询余额查询当前帐户的剩余金额；存储当前帐户中存入现金；取现金从当前帐户余额中，提取不超过余额和本日提取金额的用户输入现金数；历史信息查询查询从“起始日期”到“结束日期”的本帐户所有存、取活动；④打印打印上述活动的信息⑤帐户高级功能挂失帐户对当前帐户进行挂失操作；转帐从本帐户支付用户输入金额到用户指定帐户中；34小结与作业空格本章对面向结构化程序设计的软件工程技术进行了介绍和说明。虽然面向对象的软件设计和软件工程技术已成为当今的主流技术，但在一定条件下，面向结构化程序的设计技术与方法还有着重要的意义。而且作为面向对象软件工程技术的基础，了解和学习传统的结构化软件工程技术与方法，也是后续学习的必要保证。作业与练习：（回答下列问题）1.结构化程序设计基本要求要点是什么？2.结构化分析与结构化设计的区别？3.结构化方法以及其手段有哪些？4.面向对象方法与结构化方法的相同和不同之处有哪些？5.结构化分析方法建立的系统模型包括什么，请具体说明？6.不论项目采用什么样的软件生存周期过程，其基本特征是什么？7.软件开发模型与软件开发学之间的关系是什么？35ThankYou!2025/2/2636第七章面向对象分析

2025/2/2637第七章

面向对象分析（OOA）

基本原理与概念

1基本方法与过程2OOA实践1:ATM系统3OOA实践2：电梯控制系统4小结52025/2/2638面向对象分析（OOA）

在本章中，我们将介绍面向对象分析（object-orientedanalysis，OOA）的各种技术和方法。它包括分析和定义用户的需求（用例模型）、系统中数据的定义（静态模型），以及控制流（动态模型）分析。2025/2/2639

7.1基本原理与概念

面向对象分析（OOA），就是抽取和整理用户需求，并建立问题域精确模型的过程。 面向对象分析的关键，是识别出问题域内的对象，并分析它们相互间的关系，最终建立起问题域的简洁、精确、可理解的正确模型。根据Coda&Yourdon的面向对象分析和设计技术，面向对象分析（Object-OrientedAnalysis,OOA）模型的5个层次分别如下：2025/2/26407.1基本原理与概念对象-类层（Class&ObjectLayer），表示待开发系统的基本构造块。

属性层（AttributeLayer），对象所存储（或容纳）的数据。服务层（ServiceLayer），对象所做的“工作”，加上对象实例间的通讯。结构层（StructureLayer），负责捕捉特定应用论域中的结构关系。如电梯作为一个整体而言，必须由电梯马达、超载传感器、楼层到达显示面板、随机指令面板、随机召唤面板等组成。主题层（SubjectLayer），可以将众多的对象归类到几个子模型或子系统，即各个主题。对于电梯控制系统，可分为电梯控制和电梯管理两个主题。2025/2/26417.1基本原理与概念 OOA的实现方法有多种，大多数分析结果可以被归结到如下方面：功能模型（用例模型）。通过用例描述，来表达系统的详细需求，为软件的进一步分析和设计打下基础。静态结构（对象模型）。对象模型描述了现实世界中的“类和对象”以及它们之间的关系，表示了目标系统的静态数据结构。交互次序（动态模型）。动态模型描述系统的动态结构和系统对象之间的交互。2025/2/26427.2基本方法与过程7.2.1OOA原则

OOA的主要原则有以下九点：

抽象：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征，就叫作抽象。抽象原则有两方面的意义：第一，需要分析研究其中与系统目标有关的事物及其本质性特征。第二，通过舍弃个体事物在细节上的差异，抽取其共同特征而得到一批事物的抽象概念。抽象原则包括过程抽象和数据抽象两个方面。

2025/2/26437.2基本方法与过程封装：就是把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。 继承：特殊类的对象拥有的其一般类的全部属性与服务，称作特殊类对一般类的继承。 分类：就是把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。分类原则实际上是抽象原则运用于对象描述时的一种表现形式。2025/2/26447.2基本方法与过程聚合：又称组装，其原则是：把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。 关联：是人类思考问题时经常运用的思想方法：通过一个事物联想到另外的事物。能使人发生联想的原因是事物之间确实存在着某些联系。 消息通信：这一原则要求对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。通过消息进行通信，是由于封装原则而引起的。在OOA中要求用消息连接表示出对象之间的动态联系。 粒度控制：一般来讲，人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又能洞察秋毫。因此需要控制自己的视野：考虑全局时，注意其大的组成部分，暂时不详察每一部分的具体的细节；考虑某部分的细节时，则暂时撇开其余的部分。这就是粒度控制原则。 行为分析：现实世界中事物的行为是复杂的。由大量的事物所构成的问题域中各种行为往往相互依赖、相互交织。2025/2/26457.2基本方法与过程7.2.2OOA建模基本过程1)功能模型的建立该阶段的目标是获得对问题论域的清晰、精确的定义，产生描述系统功能和问题论域的基本特征的综合文档。论域分析过程是抽取和整理用户需求并建立问题域精确模型的过程。主要任务是充分理解专业领域的业务问题和投资者及用户的需求，提出高层次的问题解决方案。应具体分析应用领域的业务范围、业务规则和业务处理过程，确定系统范围、功能、性能，完善细化用户需求，抽象出目标系统的本质属性，建立问题论域模型。在我们的分析过程中，则须建立详细的用例模型图。2025/2/26467.2基本方法与过程2)对象模型的建立

对象是由描述其属性的数据，及可以对这些数据施加的操作（即服务），封装在一起构成的独立单元。因此，为建立完整的对象模型，既要确定类中应该定义的属性，又要确定类中应该定义的服务。这些信息体现在类模型图中。在分析过程中，由软件分析师来确定所需要的类的集合和它们的属性，以及类与类之间的关系。对象服务的确定我们放在设计阶段。这一步骤完全等同于面向数据的技术。几乎解决任何一个问题，都需要从客观世界实体及实体间相互关系抽象出极有价值的对象模型；对于复杂问题（大型系统）的对象模型一般由Coad方法所述的五个层次组成：主题层（也称为范畴层）类&对象层结构层属性层服务层2025/2/26477.2基本方法与过程

通过划分主题，我们可以把一个大型、复杂的对象模型分解成几个不同的概念范畴。一个主题有一个名称和一个标识它的编号。在描绘对象模型的图中，把属于同一个主题的那些类—&—对象框在一个框中，并在框的四角标上这个主题的编号。在建立对象模型阶段，分析师借助用例脚本和用例图来获得关于该软件后续设计阶段中，所要创建的对象类的最原始信息。包括分析为创建一个用例图已经写出的用例脚本的描述性文字，其实，这也是E-R图（实体-关系图）的另一种形式。工作步骤如下：确定对象类和关联进一步划分出若干主题给类和关联增添属性利用适当的继承关系进一步合并和组织类确定类中的服务（等到建立了动态模型和功能模型之后）2025/2/26487.2基本方法与过程(1)

类和关联的确定。

名词抽象是类建模的第一步，在面向对象分析阶段，紧随用例建模之后。为了定义一系列后选类和对象，名词抽象是一种语言分析形式，被用来分析用例细节和其它已经提取出的系统行为的书面描述。名词抽象时，每一步的输入要么是不正式的产品描述（正如在Schach多级处理的描述），或者是在用例建模期间被创建的详细用例情节。在这个章节里，我们将详细说明这两个方法。下文中将介绍使用两种名词抽象抽象方法来实现设计的修改。 对象类的确定是在需求陈述的基础上进行的。需求陈述阐明软件的具体功能，即“做什么”，它描述用户的需求但一般不提出解决问题的方法。需求陈述可以由用例（usecase）分析的结果直接得出。陈述的内容包括：问题范围，功能需求，性能需求，应用环境及假设条件等。2025/2/26497.2基本方法与过程类和对象是在问题域中客观存在的。首先，我们要找出所有候选的类和对象；然后，从候选的类和对象中筛选掉不正确的或不必要的。一种指导我们分析的方法为：以用自然语言书写的需求陈述为依据，把陈述中的名词作为类的候选者；找出隐含类；形容词作为确定属性的线索；动词作为服务（操作）的候选者。通常，在需求陈述中不会一个不漏地写出问题域中所有有关的类和对象；根据领域知识或常识，可以进一步把隐含的类和对象提取出来。

2025/2/26507.2基本方法与过程初步选出候选类和对象之后，我们还必须对候选类进行筛选。筛选时主要依据下列标准，删除不正确或不必要的类和对象，包括：冗余：如果两个类表达了同样的信息，则应该保留在此问题域中最富于描述力的名称。无关：仅需要把与本问题密切相关的类和对象放进目标系统中。笼统：去掉笼统的或模糊的类。属性：有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类中去掉。当然，如果某个性质具有很强的独立性，则应把它作为类而不是作为属性。操作：一些既可作为名词，又可作为动词的词，应该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是作为类中定义的操作。但是，本身具有属性且需独立存在的操作，应该作为类。例如，谈到电话时通常把“拨号”当作动词，当构造电话模型时确实应该把它作为一个操作，而不是一个类。但是，在开发电话的自动记账系统时，“拨号”需要有自己的属性（如日期、时间、受话地点等），因此应该把它作为一个类。实现：去掉仅和实现有关的候选类。在设计和实现阶段，这些类可能是重要的，但在分析阶段过早地考虑它们反而会分散我们的注意力。2025/2/26517.2基本方法与过程确定了类和对象之后，我们来确定类和对象间的关联关系。两个或多个对象之间的相互依赖、相互作用的关系就是关联。分析确定关联，能促使对问题域的边缘情况进行分析，有助于发现那些尚未被发现的类和对象。大多数关联可以通过直接提取需求陈述中的动词词组而得出。进一步分析需求陈述，能发现一些在陈述中隐含的关联。分析员通过与用户及领域专家讨论问题域实体间的相互依赖、相互作用关系，根据领域知识可能再进一步补充一些关联。经初步分析得出的关联只能作为候选的关联，还需经过进一步筛选，以去掉不正确的或不必要的关联。要删除的关联包括：已删去的类之间的关联。如果在分析确定类和对象的过程中已经删掉了某个候选类，则与这个类有关的关联也应该删去，或用其他类重新表达这个关联。与问题无关或应在实现阶段考虑的关联。即处在本问题域之外的关联或与实现密切相关的关联。瞬时事件：关联描述问题域的静态结构，因此瞬时事件应该删除。三元关联：三个或三个以上对象之间的关联，大多可以分解为二元关联或用词组描述成限定的关联。如果三元关联中涉及的某个实体仅用于描述另两个实体的关系，而且这个实体本身不包含属性，则它是二元关联上的链属性。派生关联：可以用其他关联定义的关联。经过筛选后的关联还需要进行进一步的完善，这一步的工作主要包括：正名：仔细选择含义更明确的名字作为关联名。分解：为了能够适用于不同的关联，必要时应该分解以前确定的类。补充：及时补上遗漏的关联。标明阶数：初步判定各个关联的类型，并粗略地确定关联的阶数。2025/2/26527.2基本方法与过程(2)

划分主题主题是按照问题域来确定的，注意不是用功能分解方法来确定主题。不同主题内的对象间应相互依赖和交互最少。如在ATM系统中，一般可分为三个主题。(3)

确定属性属性是对象的性质，借助于属性我们能对类和对象的结构有更深入、更具体的认识。通常，在需求陈述中用名词词组表示属性，例如，“汽车的颜色”或“光标的位置”。另外，借助于领域知识和常识，才能分析得出需求陈述中未直接给出的属性。属性的确定既与问题域有关，也和目标系统的任务有关。以下我们给出几点确定属性的方法：仅考虑与具体应用直接相关的属性，不考虑那些超出所要解决的问题范围的属性；首先找出最重要的属性，以后再逐渐把其余属性增添进去；在分析阶段不考虑那些纯粹用于实现的属性。2025/2/26537.2基本方法与过程认真考察经初步分析得到的属性，从中删掉不正确的或不必要的属性。要删除的属性包括：属性对象：误把对象当作属性。连接属性：把链属性误作为属性限定：把限定误当成属性内部状态：误把内部状态当成了属性过于细化需要合并的属性不一致的属性(4)识别继承和组合一般说来，可以使用两种方式建立继承关系：自底向上：抽象出现有类的共同性质泛化出父类，这个过程实质上模拟了人类归纳思维过程。自顶向下：把现有类细化成更具体的子类，这模拟了人类的演绎思维过程。从应用域中常常能明显看出应该做的自顶向下的具体化工作。例如，带有形容词修饰的名词词组往往暗示了一些具体类。但是，在分析阶段应该避免过度细化。

2025/2/26547.2基本方法与过程组合也是一种特殊的关联关系，“事务”和“更新”之间是组合关系。通常，一个事务包含对账户的若干次更新，这里所说的更新，指的是对账户所做的一个动作（取款、存款或查询）。“更新”虽然代表一个动作，但是它有自己的属性（类型、金额等），应该独立存在，因此应该把它作为类。在关联的识别过程中，大部分组合关系已被识别，在这里再次列出，以进一步发现遗漏的组合关系。

3)动态模型的建立动态模型建模的目标，是要创建一个描述软件在运行过程中，所有可能进入的不同状态的状态装换图（STD）。就此而言，状态转换图，好比是用来说明在结构分析的建模过程中，建立的一个有限状态机（FSM）。一个状态转换图可以定义成如下的公式：当前状态+事件+断言

下一个状态即

currentstateandeventandpredicate

nextstate2025/2/26557.2基本方法与过程然而实际上，状态转换图通常以图形的方式表现出来，以便于更清晰地表示出状态转换之间的关系。在开发交互式系统时，动态模型起着很重要的作用，动态模型的建立通常有以下几步：编写典型交互行为的脚本。从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。2025/2/26567.2基本方法与过程(1)编写脚本脚本是指系统在某一执行期间内出现的一系列事件。编写脚本的过程，实质上就是分析用户对系统交互行为的要求的过程。编写脚本的目的是为了保证不遗漏重要的交互步骤，它有助于确保整个交互过程的正确性和清晰性。其内容范围既可以包括系统中发生的全部事件，也可以只包括由某些特定对象触发的事件。脚本描写的范围主要由编写脚本的具体目的决定。脚本用来描述事件序列，每当系统中的对象与用户（或其他外部设备）交换信息时，就发生一个事件。所交换的信息值就是该事件的参数（例如，“输入密码”事件的参数是所输入的密码）。也有许多事件是无参数的，这样的事件仅传递一个信息——该事件已经发生了。对于每个事件，都应该指明：触发该事件的动作对象（例如，系统、用户或其他外部事物）；接受事件的目标对象；事件的参数。编写过程中要考虑以下三种情况：正常情况。特殊情况，例如，输入或输出的数据为最大值（或最小值）。出错情况，例如，输入的值为非法值或响应失败。如果可能，系统应该允许用户“异常中止”或“取消”一个操作。应该提供诸如“帮助”和”状态查询”之类的在基本交互行为之上的“通用”交互行为。2025/2/26577.2基本方法与过程(2)事件提取仔细分析每个脚本，从中提取出所有外部事件。事件包括系统与用户（或外部设备）交互的所有信号、输入、输出、中断、动作等等。对象传递信息的动作也是事件。对控制流产生相同效果的事件组合在一起应作为一类事件，并采用唯一的名字。对控制流有不同影响的事件则应区分开来，最后，还应该区分出每类事件的发送对象和接收对象。完整、正确的脚本为建立动态模型奠定了必要的基础。但是，用自然语言书写的脚本往往不够简明，而且有时在阅读时会有二义性。为了有助于建立动态模型，通常在画状态图之前先画出事件跟踪图，即时序图。(3)绘制状态图状态图用于描绘事件与对象状态的关系。状态图的详细作用及绘制方法参见第五章。有以下几点需要注意：

2025/2/26587.2基本方法与过程将图中所有指向某条竖线的箭头线，作为状态图中的箭头线，边上标以事件名。两个事件之间的间隔就是一个状态。从时序图中当前考虑的竖线射出的箭头线，是这条竖线代表的对象到达某个状态时所做的行为。画出状态图之后，再把其他脚本的时序图合并到已画出的状态图中。为此需在事件跟踪图中找出以前考虑过的脚本的分支点（例如“验证账户”就是一个分支点，因为验证的结果可能是“账户有效”，也可能是“无效账户”），然后把其他脚本中的事件序列并入已有的状态图中，作为一条可选的路径。考虑完正常事件之后，再考虑边界情况和特殊情况，其中包括在不适当时候发生的事件（例如，系统正在处理某个事务时，用户要求取消该事务）。有时用户（或外部设备）不能做出快速响应，然而某些资源又必须及时收回，于是在一定间隔后就产生了“超时”事件。对用户出错情况往往需要花费很多精力处理，并且会使原来清晰、紧凑的程序结构变得复杂、繁琐，但是，出错处理是不能省略的。当状态图覆盖了所有脚本，包含了影响某类对象状态的全部事件时，该类的状态图就构造出来了。2025/2/26597.2基本方法与过程(4)审查动态模型各个类的状态图通过共享事件合并起来，构成了系统的动态模型。在完成了每个具有重要交互行为的类的状态图之后，我们来检查系统级的完整性和一致性。一般说来，每个事件都应该既有发送对象又有接受对象。对于没有前驱或没有后继的状态应该着重审查，如果这个状态既不是交互序列的起点也不是终点，则发现了一个错误。基本系统模型由若干个数据源点/终点、及一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。由数据源点输入的数据和输出到数据终点的数据，构成了系统与外部世界之间交互事件的参数。2025/2/26607.3OOA实践1:ATM系统本节以ATM系统为例来进一步详细展示面向对象的分析过程。1).功能描述ATM系统的需求陈述如下：某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统。ATM和中央计算机由总行投资购买。总行拥有多台ATM，分别设在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。银行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。通常，一个储户可能拥有多个账户。柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。2025/2/26617.3OOA实践1:ATM系统11.拥有银行账户的储户有权申请领取现金兑换卡。12.使用现金兑换卡可以通过ATM访问自己的账户。13.目前仅限于用现金兑换卡在ATM上提取现金（即取款），或查询有关自己账户的信息（例如，某个指定账户上的余额）。14.将来可能还要求使用ATM办理转账、存款等事务。15.所谓现金兑换卡就是一张特制的磁卡，上面有分行代码和卡号。16.分行代码唯一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户。17.通常，一张卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户。18.每张现金兑换卡仅属于一个储户所有，但是，同一张卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性。19.也就是说，系统应该能够处理并发的访问。20.当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。21.首先，ATM要求用户输入密码，接下来ATM把从这张卡上读到的信息以及用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。22.中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码。23.如果用户输入的密码是正确的，ATM就要求用户选择事务类型（取款、查询等）。24.当用户选择取款时，ATM请求用户输入取款额。25.最后，ATM从现金出口吐出现金，并且打印出账单交给用户。2025/2/26627.3OOA实践1:ATM系统

图7-1给出了系统的总体用例结构图。涵盖了需求陈述中描述的几乎全部交互关系。图7-2则以储户和ATM机之间的交互功能来给出详细的用例。2025/2/26637.3OOA实践1:ATM系统如图7-2所示，银行储户在ATM机上完成取款、存款及其他业务。在这里，参与者为“银行储户”和ATM机。从系统需求描述中，我们知道ATM机目前仅限于用现金兑换卡在ATM上提取现金（即取款），或查询有关自己账户的信息。将来可能还要求使用ATM办理转账、存款等事务。因此我们在用例图中仅有取款、存款及其余功能。其余功能即留作系统功能的扩展，包括存款，转账等。图7-2ATM系统用例图2025/2/26647.3OOA实践1:ATM系统在此以取款用例为例来给出用例的详细文本描述，如图7-3所示。其中系统默认随时有退卡功能，在此忽略。用例简介:取款用例使得储户可以从ATM系统提取现金。详细步骤描述:储户把现金兑换卡插入ATM；ATM要求储户输入密码，储户输入密码；如果储户输入的密码是正确的，ATM就要求用户选择事务类型（取款、查询等），否则，提示密码错；储户选择取款；ATM请求用户输入取款额，储户输入取款额；ATM从现金出口吐出现金，并且打印出账单交给储户。图7-3取款用例描述2025/2/26657.3OOA实践1:ATM系统2)类建模本节我们对ATM系统进行详细分析，建立类图模型。(1)主题划分

首先我们根据问题域的关系对ATM系统进行主题划分。整个银行系统包括了账户库、银行储户库及ATM系统三个主题，分别为图中1,2,3所示。许多单个的账户组成了账户库。许多银行储户组成了储户库。ATM系统包含了许多ATM机。2025/2/26667.3OOA实践1:ATM系统(2)

类和对象的确定对象类的确定是在需求陈述的基础上进行的。根据ATM系统需求陈述找到的候选类有：银行自动取款机(ATM)系统中央计算机分行计算机柜员终端网络总行市街道分行营业厅储蓄所软件成本柜员储户现金支票账户事务现金兑换卡余额磁卡分行代码卡号副本访问用户信息密码类型取款额账单。在ATM系统的需求陈述中没写出的候选类：通信链路事务日志。对不正确或不必要的类和对象进行删除，详细过程如下：删除冗余类。ATM系统的候选类中，”储户”与”用户”，”现金兑换卡”与”磁卡”及”副本”分别描述了相同的二类信息；因此，应该去掉”用户”、”磁卡”、”副本”等冗余的类，仅保留“储户”和“现金兑换卡”这两个类。银行自动取款机(ATM)系统中央计算机分行计算机柜员终端网络总行市街道分行营业厅储蓄所软件成本柜员储户现金支票账户事务现金兑换卡余额分行代码卡号访问信息密码类型取款额账单用户磁卡副本事务日志通信链路

2025/2/26677.3OOA实践1:ATM系统删除无关类。ATM系统并不处理分摊软件开发成本的问题，而且ATM和柜员终端放置的地点与本软件的关系也不大。因此，应该去掉候选类“成本”、“市”、“街道”、“营业厅”和“储蓄所”。银行自动取款机(ATM)系统中央计算机分行计算机柜员终端网络总行分行软件柜员储户现金支票账户事务现金兑换卡余额分行代码卡号访问信息密码类型取款额账单。成本市街道营业厅储蓄所事务日志通信链路删除笼统的类。“银行”实际指总行或分行，“访问”在这里实际指事务，“信息”的具体内容在需求陈述中随后就指明了。此外还有一些笼统含糊的名词。因此，在本例中应该去掉“银行”、“网络”、“系统”、“软件”、“信息”、“访问”等候选类。自动取款机(ATM)中央计算机分行计算机柜员终端总行分行柜员储户现金支票账户事务现金兑换卡余额分行代码卡号密码类型取款额账单。银行网络系统软件信息访问事务日志通信链路2025/2/26687.3OOA实践1:ATM系统删除属性。在ATM系统中，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对待。因此，将它们从候选类中去除。自动取款机(ATM)中央计算机分行计算机柜员终端总行分行柜员储户账户事务现金兑换卡现金支票取款额账单余额分行代码卡号密码类型事务日志通信链路删除操作。在ATM系统中，没有此类操作。删除实现。在ATM系统中，“事务日志”无非是对一系列事务的记录，它的确切表示方式是面向对象设计的议题；“通信链路”在逻辑上是一种联系，在系统实现时它是关联链的物理实现。总之，应该暂时去掉“事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们。自动取款机(ATM)中央计算机分行计算机柜员终端总行分行柜员储户账户事务现金兑换卡事务日志通信链路2025/2/26697.3OOA实践1:ATM系统经过以上筛选步骤最终确定系统所需的类：自动取款机(ATM)中央计算机分行计算机柜员终端总行分行柜员储户账户事务现金兑换卡(3)确定关联直接提取动词短语得出的关联：ATM,中央计算机,分行计算机及柜员终端组成网络总行拥有多台ATM。ATM设在主要街道上分行提供分行计算机和柜员终端柜员终端设在分行营业厅及储蓄所内分行分摊软件开发成本储户拥有账户柜员输入针对账户的事务柜员终端与分行计算机通信分行计算机处理针对账户的事务分行计算机维护账户系统处理并发的访问ATM与用户交互ATM与中央计算机交换关于事务的信息ATM读现金兑换卡中央计算机确定事务与分行的对应关系ATM吐出现金ATM打印账单2025/2/26707.3OOA实践1:ATM系统需求陈述中隐含的关联：总行由各个分行组成分行保管账户总行拥有中央计算机系统维护事务日志系统提供必要的安全性储户拥有现金兑换卡根据问题域知识得出的关联：现金兑换卡访问账户分行雇用柜员2025/2/26717.3OOA实践1:ATM系统对关联进行筛选，详细过程如下：已删去的类之间的关联。如果在分析确定类和对象的过程中已经删掉了某个候选类，则与这个类有关的关联也应该删去，或用其他类重新表达这个关联。以ATM系统为例，由于已经删去了系统、网络、市、街道、成本、软件、事务日志、现金、营业厅、储蓄所、账单等候选类，因此，与这些类有关的下列八个关联也应该删去。ATM、中央计算机、分行计算机及柜员终端组成网络。ATM设在主要街道上。柜员终端设在分行营业厅及储蓄所内。分行分摊软件开发成本。ATM吐出现金。ATM打印账单。系统维护事务日志。系统提供必要的安全性。与问题无关或应在实现阶段考虑的关联。即处在本问题域之外的关联或与实现密切相关的关联。例如，在ATM系统的例子中，“系统处理并发的访问”并没有标明对象之间的新关联，它只不过提醒我们在实现阶段需要使用实现并发访问的算法，以处理并发事务。2025/2/26727.3OOA实践1:ATM系统瞬时事件。关联描述问题域的静态结构，因此瞬时事件应该删除。以ATM系统为例，“ATM读现金兑换卡”描述了ATM与用户交互周期中的一个动作，它并不是ATM与现金兑换卡之间的固有关系，因此应该删去。类似地，还应该删去“ATM与用户交互”这个候选的关联。三元关联。三个或三个以上对象之间的关联，大多可以分解为二元关联或用词组描述成限定的关联。例如，“柜员输入针对账户的事务”可以分解成：“柜员输入事务”和“事务修改账户”；“分行计算机处理针对账户的事务”可以分解成：“分行保管账户”和“事务修改账户”；“ATM与中央计算机交换关于事务的信息”可以分解成：“ATM与中央计算机通信”和“ATM上输入事务”。如果三元关联中涉及的某个实体仅用于描述另两个实体的关系，而且这个实体本身不包含属性，则它是二元关联上的链属性。例如，“公司付给员工工资”可以改造成带有链属性“工资”的二元关联“公司雇用员工”。派生关联。可以用其他关联定义的关联。例如，“总行拥有多台ATM”实质上是“总行拥有中央计算机”和“ATM与中央计算机通信”这两个关联组合的结果。而“分行计算机维护账户”的实际含义是，“分行保管账户”和“事务修改账户”。2025/2/26737.3OOA实践1:ATM系统经过以上处理，最终得到ATM系统中的所有关联如下：总行由各个分行组成总行拥有中央计算机中央计算机与分行通信ATM与中央计算机通信分行拥有分行计算机分行拥有柜员终端柜员终端与分行计算机通信分行雇用柜员柜员输入柜员事务柜员事务输入柜员终端柜员事务修改账户分行保管账户储户拥有账户储户拥有现金兑换卡远程事务由现金兑换卡授权在ATM上输入远程事务远程事务修改账户现金兑换卡访问账户2025/2/26747.3OOA实践1:ATM系统(4)确定属性

从需求陈述中可以得到帐户具有帐户类型、帐户号、余额三个属性。柜员事务则包括时间，日期和金额三个属性。银行储户及ATM机两个类包含哪些属性，如下页图7-5都一目了然。

2025/2/26757.3OOA实践1:ATM系统2025/2/26767.3OOA实践1:ATM系统(5)识别继承和组合进一步考虑继承和组合的因素对类进行组织。使用两种方式建立继承关系：自底向上：在ATM系统中，“远程事务”和“柜员事务”是类似的（它们都“修改”帐户），可以泛化出父类“事务”；类似地，可以从“ATM”和“柜员终端”（它们都“输入”事务）泛化出父类“输入站”。自顶向下：“现金兑换卡”类实际上有两个相对独立的功能，即鉴别储户使用ATM的权限的卡：“卡权限”和ATM获得分行代码和卡号等数据的数据载体：“现金兑换卡”。“卡权限”类标志储户访问账户的权限，“现金兑换卡”类是含有分行代码和卡号的数据载体。多张“现金兑换卡”可能对应着相同的“卡权限”。因此应将类“现金兑换卡”分解为两个类“现金兑换卡”和“卡权限”。另外，“事务”和“更新”之间是组合关系。通常，一个事务包含对账户的若干次更新，这里所说的更新，指的是对账户所做的一个动作（取款、查询）。“更新”虽然代表一个动作，但是它有自己的属性（类型、金额等），应该独立存在，因此把它作为类。这样我们得到新的类图7-6。2025/2/26777.3OOA实践1:ATM系统图7-6迭代后的ATM机类图2025/2/26787.3OOA实践1:ATM系统2)动态建模

为建立动态模型，我们首先考虑ATM系统的使用过程。写出ATM系统的用例脚本。考虑其正常脚本，及异常脚本。这里异常指用户不合法操作。以下给出一个正常情况脚本和一个异常情况脚本。ATM系统的正常情况脚本：ATM请储户插卡；储户插入一张现金兑换卡。ATM接受该卡并读它上面的分行代码和卡号。ATM要求储户输入密码；储户输入自己的密码“1234”等数字。ATM请求总行验证卡号和密码；总行要求“39”号分行核对储户密码，然后通知ATM说这张卡有效ATM要求储户选择事务类型（取款、转账、查询等）；储户选择“取款”。ATM要求储户输入取款额；储户输入“880”。ATM确认取款额在预先规定的限额内，然后要求总行处理这个事务；总行把请求转给分行，该分行成功地处理完这项事务并返回该账户的新余额。ATM吐出现金并请储户拿走这些现金；储户拿走现金。ATM问储户是否继续这项事务；储户回答“不”。ATM打印账单，退出现金兑换卡，请储户拿走它们；储户取走账单和卡。ATM请储户插卡。2025/2/26797.3OOA实践1:ATM系统ATM系统的异常情况脚本：ATM请储户插卡；储户插入一张现金兑换卡。ATM接受这张卡并读它上面的分行代码和卡号。ATM要求密码；储户误输入“8888”。ATM请求总行验证输入的数字和密码；总行在向有关分行咨询之后拒绝这张卡。ATM显示“密码错”，并请储户重新输入密码；储户输入“1234”；ATM请总行验证后知道这次输入的密码正确。ATM请储户选择事务类型；储户选择“取款”。ATM询问取款额；储户改变主意不想取款了，他敲“取消”键。ATM退出现金兑换卡，并请储户拿走它；储户拿走他的卡。ATM请储户插卡。

2025/2/26807.3OOA实践1:ATM系统

根据ATM的用例脚本出发画出状态图。将各脚本描述的状态转换逐次添加到原图上，得到最后的状态图，如图7-7,7-8和图7-9。针对系统脚本，三个图分别从系统不同层次对类的交互行为进行了描述。状态图的详细作用及绘制方法参见第五章。2025/2/26817.3OOA实践1:ATM系统2025/2/26827.4OOA实践2：电梯控制系统

7.4OOA实践2：电梯控制系统1)功能描述电梯的抽象用例图如下：图7-10电梯控制系统用例图2025/2/26837.4OOA实践2：电梯控制系统电梯控制系统面向对象的分析，电梯系统我们在第三章提到过。在这里我们对电梯系统进行更详细的描述，需求陈述如下：(1)有楼高为N层的大厦，需要安装电梯；(2)

除底层和顶层仅有一个单向按钮，其它楼层均安装“上▲”、“下▼”两个按钮；(3)

电梯内有1~N个数字按钮和“开”、“关”按钮；每个数字按钮代表一个楼层。当按下一个数字按钮时，该数字按钮指示灯亮。当电梯到达相应楼层时，该搂层对应数字按钮指示灯灭。(4)

电梯在单向运行中，如“上升”：若在“上升需求”或“到达需求”中有高于目前楼层的需求存在或有更高的“下降需求”，方向不变，运行至上一楼层位置；(5)

否则运行反向，在若在“下降需求”或“到达需求”中有低于目前楼层的需求存在或有更低的“上升需求”，运行至下一楼层位置；若无任何需求，关门，停止运行，等待；(6)

到达需求楼层位置，若有到达需求或上升需求，或满足反向条件，开门，保持20秒钟，或响应“开”、“关”按钮动作，在关门2秒钟后，重复(3)；2025/2/26847.4OOA实践2：电梯控制系统2)类建模从系统需求中我们得到候选类：按钮，电梯，楼层，运行，大厦，指示灯，请求，门。其中，楼层、大厦是处于问题边界以外的名词，应该删除。运行是抽象名词，没有实际意义，因此删去。指示灯、请求都可以作为按钮的属性。最后我们得到三个类：电梯，按钮和门。对于按钮，根据需求中指定的两种类型，进行抽象继承，得到两个子类：电梯按钮和楼层按钮。由此得到电梯控制系统的基本类模型。

图7-11电梯控制系统的基本类模型

2025/2/26857.4OOA实践2：电梯控制系统

在实际的电梯中，按钮并不直接与电梯通信，按钮响应与电梯之间的对应关系必须由某种类型的电梯控制器来负责。因此，我们增加电梯控制器类。电梯控制器处理请求并控制按钮指示灯的亮与灭。另外，打开和关闭电梯门的唯一办法是向“电梯门”对象发送一条消息，如果在错误的时间关闭或打开电梯门是很危险的。为了更好的保证电梯运行的安全，将电梯门从电梯分离出来，分别对它们进行控制。经过以上步骤，得到类图:2025/2/26867.4OOA实践2：电梯控制系统3)动态建模电梯控制系统中，用户的任何输入都是合法的。因此对其进行动态建模，只需考虑电梯的调度原则。而其状态图也恰恰只描述电梯的所有可能事件，及其交互过程。如图7-13所示，电梯控制系统，即电梯事件循环状态，不停的监视由按钮对象发送来的消息，根据电梯运动现状，选择电梯移动方向。例如，当电梯移动一楼层时，处于“决定是否停止”状态，此时则需要对当前请求队列进行检查，若无停留在该楼层的请求，则继续移动，否则，要“停在楼层”，开门并启动定时器。2025/2/26877.4OOA实践2：电梯控制系统图7-13电梯系统类图2025/2/26887.5小结

7.5小结

面向对象的分析OOA（Object-OrientedAnalysis）是面向对象方法从编程领域向分析领域延伸的产物，充分体现了面向对象的概念与原则。面向对象的分析方法，强调从问题域中的实际事物及与系统责任有关的概念出发，来构造系统模型、与问题域具有一致的概念和术语，同时尽可能使用符合人类的思维方式来认识和描述问题域，有利于对问题及系统责任的理解以及人员之间的交流。再加上面向对象本身的封装、继承和多态等特征，OOA对需求变化有较强的适应性，并且很好的支持了软件复用。在本章中，我们介绍了OOA的分析原则及详细分析过程，并以ATM系统以及电梯调度系统开发为例，详细说明了OOA分析中三种模型即用例模型、静态模型和动态模型的建模过程。

SoftwareEngineering软件工程精品课程第九章实现与测试

9.1重用性（reuse） 人们在开发一件新的产品时,往往会直接使用大量的成熟部件,这些被重新使用的软件模块和程序，称为组件（component）。而在新的软件开发中选用原有组件的方法，就是软件重用。 软件重用有两种类型，第一种是意外（accidental）重用，另一种是预备（deliberate）重用。 随着组件技术的不断发展，软件重用成为软件开发的主要指标之一。第九章实现与测试9.1.2对象与重用 面向对象的程序设计，将数据结构及其之上的操作封装起来，对外具有统一的接口定义和数据传递关系。这样一种模式，为软件重用技术的应用带来了极大的便利。9.1.3

重用在软件的各个阶段 应用架构的重用

1.软件设计阶段的重用 设计模式的重用 软件架构的重用

第九章实现与测试

2.软件实现阶段的重用选择合适的组件、继承和集成现有的软件模块，已经是软件实现阶段的重要任务。3.软件维护阶段的重用软件重用对软件维护带来的好处，软件的维护可以象机械设备的维修一样进行部件（组件）的更换。当然我们知道软件部件是不会磨损的，需要更换的软件组件要么是有错误，要么是需要升级。

第九章实现与测试第四代语言第三代语言第二代语言

第一代语言面向问题描述的更自然的语言高级语言Fortran、BASIC、C汇编语言机器语言，即01代码9.2选择编程语言9.2.1编程语言的类型第九章实现与测试9.2.2快速原型语言

快速原型语言，是要在短时间内以直观的方式展现用户的需求。 快速原型语言的要求，一是快，二是直观，图形化的显示。

建立原型的目的，是为了方便与用户的沟通，而不是软件的设计，仅需要描述软件的外部特性而不是内部实现！

第九章实现与测试9.2.3最终实现语言 当我们实现一个软件产品的模块编程（coding）时，应该选择什么样的实现语言呢？选择语言时，却应该遵循一些基本的准则：选择客户具有经验和支持工具的语言选择适合应用特点的语言选择信息内聚性最大的语言选择具有最佳成本-效率比的语言选择风险最小的语言第九章实现与测试9.3好的编程风格与原则

编程风格的基本要求：

使用一致的、有意义的变量命名注释语句的必要性避免模糊、复杂的算法使用常量学会代码的版面设计嵌套的

if语句第九章实现与测试9.4单元测试

关于软件测试的工作，应该从软件一开始的需求阶段就包含进来，并且一直贯穿软件生命周期的全过程。

软件测试的目标为：

1.检查软件代码是否达到软件设计的功能与性能要求

2.尽可能发现代码中存在的错误。

第九章实现与测试

针对软件测试的两个目标，从测试方法的角度，可以分为两种测试的方法。

1.以软件设计为标准，检查软件代码是否满足了软件设计的要求----黑盒测试。

2.以软件代码为对象，检查已完成的代码中是否存在错误----白盒测试。

第九章实现与测试9.4.1黑盒测试

黑盒测试，是在不了解软件代码的条件下，检测软件是否达到的设计的要求。因为不了解程序的内部结构，测试数据就要从输入数据和输出数据上分析了。 对于黑盒测试而言，是检测软件是否达到设计的要求，即软件的功能要求。因此测试用例的另一个生成标准，就是覆盖软件模块的所有功能。

第九章实现与测试9.4.2白盒测试

白盒测试是基于代码的测试，也称为基于软件结构的测试。白盒测试更注重于代码自身的质量，而不是其要实现的功能。 白盒测试从软件代码出发，测试用例的选择都是基于代码的语句、结构和路径的构成，测试的目的，就是尽可能覆盖代码的所有运行，从而发现其中的错误。 语句覆盖（statementcoverage） 分支覆盖（branchcoverage） 路径覆盖（pathcoverage）

第九章实现与测试9.4.3其他审查1）代码走查（CodeWalkthroughs） 在软件描述和编码阶段，对于软件设计师和程序员完成的文档和代码，如果能够有其他富有经验的设计师和程序员重读检查，往往会发现许多存在的错误。而当进行重读检查的人员不止一人时，这种对文档和代码的重新检查，往往能够发现文档和代码的所有错误和问题。第九章实现与测试2）代码视察（CodeInspections） 代码视察是一种更规范的重读方式，人员组成与代码走查类似。一般由3~6人组成，包括当前阶段（实现与测试阶段）的代表和下一阶段（集成测试）的代表、一个成员扮演团队的协调者来领导和管理团队、还有一个成员是记录者，负责记录代码视察中发现的错误。

3）正确性证明（CorrectnessProofs）

正确性证明，是用形式化、数学的方法证明一段程序代码满足了输入、输出的要求。这是唯一能够证明程序正确的方法。第九章实现与测试4）复杂性描述（ComplexityMetrics）

尽管复杂性描述更象一个白盒测试方法，它依赖于被测试的程序代码，但它并不对程序进行测试，而只是表明程序的复杂性和哪个程序更需要被测试。

5）错误统计与可靠性分析（FaultStatisticsandReliabilityAnalysis）

错误统计提供了一个有用的体系来决定是否继续测试一个模块，还是重新编写。在程序测试中，不论是白盒、黑盒还是走查，所有的错误被按照不同错误级别记录下来，为软件质量的评价提供了依据。第九章实现与测试6）静室技术（TheCleanroomTechnique）

静室技术是多种软件开发技术的集成，包括了正确性证明、代码审查、错误统计与可靠性分析等一系列技术方法。静室技术的核心思想是：通过在第一次正确地书写代码增量并在测试前验证它们的正确性，从而避免成本很高的错误消除过程。

第九章实现与测试9.4.4测试方法的评价与选择

上面介绍了黑盒测试、白盒测试、程序走查等一系列软件测试方法，究竟那种软件测试方法最有效呢？ 实验结果，并不能证明有哪一种测试方法具有明显的优势。黑盒测试、白盒测试、程序走查作为三种典型的软件测试方法，各具有自己的优点和不足。当然，其中程序走查方法的费用要高于黑盒测试和白盒测试。第九章实现与测试9.5集成测试

软件产品总是由许多不同功能的模块组成的，当完成模块编码和单元测试工作后，就需要进行软件的集成测试工作。

考虑如图所示的模块结构组成的软件。

第九章实现与测试9.5.1自顶向下测试（Top-Down）

自顶向下的集成测试，优点是能够及早发现软件的需求错误、逻辑故障、结构错误等软件的重要错误。 一类称为逻辑模块（Logicmodules），就是一般比较靠近根部的模块，这类模块往往是关于程序逻辑、结构、控制的模块。 另一类称为操作模块（operationalmodules），一般是调用的最底层模块，这类模块往往是执行一些具体的操作，如输入、输出或硬件的驱动等。 自顶向下集成测试的缺点，正是因为从逻辑模块开始，而导致对操作模块的测试不足。

第九章实现与测试9.5.2自底向上测试（Bottom-Up）

自底向上的测试方法，对操作模块的测试是充分的，因为在测试操作模块时，可能尚不清楚本软件对操作模块的具体要求，所以会对操作模块的全部功能都进行完全的测试。保证了对操作模块测试的充分性。

自底向上的测试方法，因为将逻辑模块的测试放在了后期，所以软件的需求错误、结构错误都会较晚发现，甚至出现对操作模块的完全测试，因为需求的错误，而变成完全无用的模块。第九章实现与测试9.5.3三明治测试 仍然考虑图9-9的软件模块，我们把模块a，b，c，d，g，I当作逻辑模块；把模块e，f，h，i，k，l，m作为操作模块。那么，我们可以对逻辑模块采用自顶向下的测试方法，而对操作模块，采用自底向上的测试方法。并且可以同时开始两个小组的测试工作。这样，我们既可以在早期就发现软件需求、结构和逻辑上的错误，又可以保证对操作模块测试的充分性。第九章实现与测试方法优点不足整体测试—错误定位难主要设计错误发现较晚自顶向下错误定位主要设计错误发现早重用模块测试测试不足自底向上错误定位重用模块测试充分主要设计错误发现晚三明治错误定位主要设计错误发现早重用模块测试充分—集成测试方法总结第九章实现与测