面向对象课后习题及课件

面向对象不仅是一些具体的软件开发技术与策略，而且是一整套关于如何看待软件系统

与现实世界的关系，以什么观点来研究问题并进行求解，以及如何进行系统构造的软件方法

学。面向对象技术在计算机学科产生了巨大的影响，在产业界有着广泛应用。它已经渗透到

计算机科学技术的几乎每一个分支领域，如编程语言、系统分析与设计、数据库、人机界面、

,知识工程、操作系统、计算机体系结构等等。此外，新兴的基于构件开发、面向服务计算、

Agent和面向方面开发等技术也以面向对象技术作为基础。

当我们提到对象导向的时候，它不仅指一种程序设计方法。它更多意义上是一种程序开

发方式。在这一方面，我们必须了解更多关于对象导向系统分析和对象导向设计(Object

OrientedDesign,简称OOD)方面的知识。

对象导向程序设计Object-OrientedProgramming,缩写：OOP.指一种程序设计范型,

同时也是一种程序开发的方法论。它将对象作为程序的基本单元，将程序和数据封装其中，

以提高软件的重用性、灵活性和扩展性。

软件是客观世界中问题空间与解空间的具体描述，追求表达能力强、更符合人类思维模

式具有易构造性和易演化性的计算模型

软件工程应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度，实现满

足用户要求的软件产品的定义、开发、发布和维护的工程或以之为研究对象的学科。

计算机软件一般指计算机系统中的程序及文档，程序是以计算机语言表达的软件系统，

文档是以人类语言表达的软件系统，二者互相配合共同构成了完整的软件系统。软件是系统

逻辑的体现必须依附于一定的载体例如：纸张、软盘、硬盘、光盘等，人类抽象的经验、知

识正逐步由软件予以精确地体现。

软件发展现状

(1)已经存在大量正在运行的软件：金融、电信、航空航天等

(2)软件的应用范围不断扩大：商务、交通、家电等，“无处不在的软件”

(3)软件的规模与复杂性持续增加，越来越多的知识正在由软件进行显式表达

(4)出现了大量与软件相关的标准

(5)软件危机仍然存在(软件脱节)1968-2009

软件发展特点

(1)软件应用范围将继续扩大，成为信息社会的物理设施

(2)遗留软件将继续发挥作用

(3)软件的可靠性与安全性日趋重要

(4)网络化软件将是发展重点

(5)工业化生产是必由之路

软件开发的特点：

软件开发是典型的知识密集型活动、复杂度高、开发周期长、可靠性保证难。随着软件

应用范围的快速扩大以及软件运行平台从单机向网络的转变，软件的规模越来越大，复杂度

越来越高，软件开发的高、长、难愈益突出。

网络环境给应用系统带来的挑战：通信问题异构问题定位问题可靠性问题安全问

题管理问题维护问题等等

软件的本质特性：构造性演化性

其它特点：知识密集逻辑产物

软件是典型的知识产品，是客观世界中问题空间与解空间的具体描述。(1)软件是有

结构的。传统的软件开发是个体作坊式的主要解决功能问题，较少考虑结构问题，造成软件

复杂度高、维护难度大、可靠性差。软件构件技术集中体现了软件的构造性。随着软件规模

及复杂性的增加，W法+数据结构的描述方式逐渐变得不足。人们需要从整体上、从体系

结构高度把握软件构件+构件之间的关系，是软件体系结构的具体内容。

（2）客观世界不断发展，不断发生变化。软件系统不可能一成不变，新需求、新技术

不断出现，软件系统要不断升级、不断演化。

软件构件技术有力地支持软件的演化性，软件的演化涉及软件系统在功能、性能、易用

性等方面的改进,对于大型软件系统的维护（演化）工作，占据开发单位总开销的50-75%。

目前“打补丁”（patched）式的“演化”方式，限制了软件的演化能力。基于构件技术开发

软件。采用构件的集成组装方式生成软件易描述、易配置、易演化，提高了软件的演化能力。

网络环境下软件技术有什么样的特点？

传统开发方法中存在的问题

在二十世纪六十年代

•软件系统都是较小且相对简单的•所用的编程语言也都是十分简单的语言•时兴个人英

雄注意，即崇尚程序员的个人技能•代码是面条式的，特别是代码中含有GOTO语句。

随着软件复杂性的增长，代码是很难维护的。高层次语言的引入有助于解决一些与复杂

性有关的问题，但这些语言并不是充分的。那时，无开发方法而言。

结构化分析设计方法：

二十世纪七十年代，发明了结构化分析设计方法：功能分解，使用功能作为构造块。

功能分解法（functiondecomposition）：功能分解=功能+子功能+功能接口。以系

统需要提供的功能为中心来组织系统。首先定义各种功能，然后把功能分解为子功能，同时

定义功能之间的接口。对较大的子功能进一步分解，直到可给出明确的定义。根据功能/子

功能的需要设计数据结构。

工作过程：一层层地进行功能分解。

得到的系统模型：由模块及其接口构成。

优点：

•当时的计算机应用还不是很普及，只是特定的用户按自己的需要，对软件系统做出了

功能性的要求，有据可寻。•在相当大的程度上，解决了以前存在的问题。特别是与模块化

编程结合使用，效率更高。•删除GOTO语句，使得软件能得到有效的维护。•适用于功能稳

定的应用领域，如某些科学计算。•直接地反映用户的需求，所以工作很容易开始。

缺点：

•开头容易，结束难。•结构化分析和设计仅处理功能，对处理数据基本上没什么帮助。

•对于众多的领域而言，其功能是易变的，如企业管理和商业管理。对需求变化的适应能力

很差••不能直接地映射问题域，很难检验分析结果的正确性。•局部的错误和局部的修改很

容易产生全局性的影响。•对于大型、复杂的软件，由于其中内在的高偶合、低内聚，特别

是当时团体开发的开发管理方法的不足，70年代出现了软件危机：对系统的维护。•使用结

构化的方法、4GL、CASE工具、原型技术和代码生成器来解决这些问题但不成功。

数据流法又称结构化分析：

数据流法=数据流+数据处理（加工）+数据存储+端点+处理说明+数据字典

基本策略是跟踪数据流，即研究问题域中数据如何流动以及在各个环节上进行何种处

理，从而发现数据流和加工。问题域被映射为数据流图（DFD）,并用处理说明和数据字典

进行详细说明。

优点：有严格的法则，较强调研究问题域。•大系统数据流和加工的数量太多，引起分

析文档的膨胀。•仍然是间接映射；•系统复杂时，难以检验分析的正确性。•对需求变化的

适应能力较弱。•设计与表示法不一致，其转换规则也不严格。

从历史上看，人们使用函数、模块和抽象数据类型，直到现在使用对象，作为系统的构

造块。

2

函数与过程：允许程序员在一处组织重复的任务•提供了将实现的信息隐藏的能力：只

需知道接口，不需要知道实现的确切细节，就可使用函数或过程。•提供的这种机制不严格。

模块：模块是一种对产生和管理名称空间有用的抽象机制•模块为程序员提供将名字空

间的可见性和名称的机制划分为公有和私有两部分的能力（名称空间是•种管理程序元素，

如函数、属性和类名）。•公有的部分对外来说都是可访问的，而只能在模块内访问私有部

分。

•变量（数据）、函数、过程和类型都可以被定义为模块的任何一部分。

使用模块的要求：模块的设计者必须为预期的用户提供正确使用该模块所需要的信息，

并且不附加其他的信息。模块的设计者必须为实现者提供完成（编码）该模块所必需的信息,

并且不附加其他的信息。

优点：它将称为模块的系统的一部分从系统的所有的其他部分中隔离出来。•解决了信

息隐臧问题•增加了软件的可维护性，因为封装使得代码可被修改或扩展，并且在修改错误

的时候不会有引起不必要或非故意的副面效应的风险。

缺点：•不能实例化，实例化是使得数据区有多个拷贝的能力。

抽象数据类型：

•抽象数据类型是一种程序员定义的数据类型，可以按与编程语言预定义的数据类型相

似的方式操作它。•抽象数据类型对应一组（或许几乎是无限集合）合法数据值和在其之上

操作的一组函数。•程序员可以通过将合法值赋予变量的方式，产生这种抽象数据类型的实

例。•保护（隐藏）与类型相关的实例数据，并且将对数据的访问限制在程序员定义的函数

内。•产生程序员定义的类型的（无限）实例如Ada和CLU在关系上不完善，对00发展产生

重要影响。

基于数据的方法：

实体-关系图：用实体的数据集合作为构造块，以数据结构为中心。•结构化的方法实际

匕帮助开发者处理数据，但数据建模方法却不能帮助开发者管理功能。

实体关系法：跟踪数据流，从而发现数据流和加工。•强调对信息实体建模，而不是对

象建模。•对象只有属性，而无服务。•父类与子类之间也只有属性继承。•没采用消息通讯。

信息建模法（informationmodeling）

信息建模=实体（对象）+属性+关系+父类型/子类型+关联对象

由实体-关系法（E-R方法）发展而来。

与数据库设计有很深的渊源。核心概念是实体和关系。实体描述问题域的事物，含有属

性；关系描述事物之间在数据方面的联系，也可以带有属性。发展之后的方法也把实体称作

对象，并使用了类型和子类型的概念，作为实体（对象）的抽象描述。

有限状态机方法

•它基于现实的行为视图，状态是这类系统的构造块，并且所操作的数据是独立于状态

的。•基于系统状态的处理。•这一方法学没有体现数据管理。

基于规则的系统

•计算机是执行一套规则的推理机（if—then语句）。♦基于人工智能系统•基于规则的

系统并没有帮助我们处理数据，也不支持过程概念•如prolog,list语言

上述方法都仅基于一个角度看待系统，对系统的其它视图建模方面的能力都很弱。但对

00产生都做出了一定的贡献.

UML是一种面向对象的建模语言，在软件产业界获得了很大的支持。

从程序设计方法的角度看，面向对象是一种新的程序设计范型（paradigm）,其基本思想

是使用对象、类、继承、封装、聚合、关联、消息、多态性等基本概念来进行程序设计。

3

面向对象方法是一种运用对象、类、继承、封装、聚合、关联、消息、多态性等概念来

构造系统的软件开发方法。

面向对象的基本思想

（1）从现实世界中客观存在的事物出发来建立软件系统，强调直接以问题域（现实世

界）中的事物为中心来思考问题、认识问题，并根据这些事物的本质特征，把它们抽象地表

示为系统中的对象，作为系统的基本构成单位。这可以使系统直接映射问题域，保持问题域

中事物及其相互关系的本来面貌（2）充分运用人类日常的思维方法强调运用人类在日常的

逻辑思维中经常采用的思想方法与原则，例如抽象、分类、继承、聚合、封装、关联等等。

这使得软件开发者能更有效地思考问题，并以其他人也能看得懂的方式把自己的认识表达出

来。

（3）具有相同属性和服务的对象属于一个类，这样的对象是类的一个实例。

（4）类可有层次结构，即类可有子类，其中子类继承父类的属性和服务，而且根据需

要，子类还可以有自己的属性和服务。

（5）类具有封闭性，把内部的属性和服务隐藏起来，只有公共的服务对外是可见的。

例如，家庭财产的管理就具有封装性。对象之间只可通过消息来请求其它对象的服务，或提

供自己

的服务。

面向对象方法的抽象性

00方法可采用自顶向下的方式进行抽象。既先定义类的名称、责任和接口。其他的内

容以后再考虑。例题：自动售货机。名称：自动售货机；责任：收钱、发货：接口：收钱口、

选择按钮、发货口。机器的内部实现细节以后再考虑。

抽象的益处之'：有限的接口方便用户使用，而且很少发生变化。之二：复用：接口稳

定，修改只在类的内部进行。

面向对象的软件工程方法：问题域一-00A--00D--OOP--00T--计算机。

面向对象程序设计的本质：把数据和处理数据的过程作为一个整体，即对象。

程序*对象，关系〉对象=（算法）+（数据结构）

面向对象中的基本概念：

对象:

对象是现实世界中某个实际存在的事物，它可以是有形的（比如一辆汽车），也可以是

无形的（比如一项计划）。对象是构成世界的一个独立单位。它具有自己的静态特征和动态

特征。

对象是系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位。一个对象

由一组属性和对这组属性进行操作的一组服务构成。

对象由“对象标识--属性--服务”。属性是用来描述对象状态特征的一个数据项。服

务是用来描述对象动态特征的一个操作序列。对象标识就是对象的名字，有“外部标识”和

“内部标识”之分。

类是具有相同属性和服务的一组对象的集合,它为属于该类的全部对象提供了统一的抽

象描述，其内部包括属性和服务两个主要部分。类的作用是用来创建对象，对象是类的一个

实例。

抽象与分类：忽略事物的非本质特征，只注意那些与当前目标有关的本质特征，从而找

出事物的共性，叫做抽象；把具有共同性质的事物划分为一类，得出一个抽象的概念，叫做

分类。

4

不同程度的抽象可得到不同层次的分类，较多地忽略事物之间的差别得到较一般的类。

较多地注意事物之间的差别得到较特殊的类。

如果类A具有类B的属性和服务，而且具有自己特有的某些属性或服务，则A叫做B的特殊

类，B叫做A的一般类。

另一定义：如果类A的全部对象都是类B的对象，而且类B中存在不属于类A的对象，则A

是B的特殊类，B是A的般类。

继承：特殊类拥有其一般类的属性与服务，称作特殊类对一般类的继承。

一般类与特殊类之间的关系叫泛化关系（继承关系），简称泛化。继承简化了人们对事

物的认识和描述，非常有益于软件复用，是00技术提高软件开发效率的重要原因之一。

子类自动共享父类的attributes和methods,而不必重复定义。

消息：

对象通过它对外提供的服务在系统中发挥作用。当系统中的其他对象或其他系统成分

（在不要求完全对象化的语言中，允许有不属于任何对象的成分，例如C++程序中的main函

数）请求这个对象，执行某个服务时，该对象就响应这个请求，完成该服务。在00方法中，

把向对象发出的服务请求称为消息。目前在大部分面向对象的编程语言中，消息其实就是函

数（或过程）调用。但是，函数调用只是实现消息的方式之一，上述理解只适合于顺序系统。

一个（较复杂的）对象由其他若干（较简单的）对象作为其构成部分，称较复杂的对象

为聚集，称较简单的对象为成分，称这种关系为聚合。聚合刻画了现实事物之间的构成关系。

如：

类之间的静态联系称作关联。在实例化后，由类产生对象，由关联产生连接对象的链。

链是关联的实例。关联的表示符号也称作实例连接。

永久对象：可以在程序运行后继续保存的对象

主动对象：至少有一个服务不需要接收消息就能主动执行的对象。描述具有主动行为的

事物，描述并发执行的任务。

面向对象中的基本原则：

（1）抽象

过程抽象:任何一个完成确定功能的操作序列，其使用者都可把它看作一个单一的实体,

尽管实际上它可能是由一系列更低级的操作完成的。

数据抽象:根据施加于数据之上的操作来定义数据类型，并限定数据的值只能由这些操

作来修改和观察。

（2）封装:

封装:把对象的属性和服务结合成一个独立的系统单位，并尽可能隐蔽对象的内部细节。

只是向外部提供接口。由封装机制保证：数据不能被对象的使用者直接访问。只允许通过山

对象提供的方法或代码访问数据。

封装的重要意义：

使对象能够集中而完整地描述并对应•个具体事物。体现了事物的相对独立性，使对象

5

外部不能随意存取对象的内部数据，避免了外部错误对它的“交插感染”。对象的内部的修

改对外部的影响很小，减少了修改引起的“波动效应”。公开静态的、不变的服务，而把动

态的、易变的服务隐藏起来。

封装带来的问题：编程的麻烦执行效率的损失解决办法：不强调严格封装，实行可

见性控制。

（3）信息隐蔽

包含属性（数据）的对象定义其什么服务（函数）可被其他对象访问。实际上，其他的

对象

对被请求的对象怎样提供服务（方法/代码）没有感知.•对象的服务定义其他的对象怎

样获得对其方法的访问。每一个对象将愿意提供给所有对象的公共服务公开化。它也提供仅

局限于特定对象的其它的服务（受保护的和私有的）。

（4）委托

借助消息传递，工作可从一个对象（客户）传递到另一个对象（代理），因为从客户的

观点，代理具有客户所需要的服务。工作连续地传递，直到到达了既有数据又有方法（代码）

能完成这项工作的对象。

（5）消息通信

即要求对象之间只能通过消息进行通讯，而不允许在对象之外直接地存取对象内部的属

性。

•消息传递机制与函数调用机制的区别

第一，在消息传递机制中，每个消息被发送给指定的接收者（对象）。在命令式编程

范型中，函数调用机制没有指定的接收者。这一区别支持封装。

第二，消息的解释（用来完成服务请求的方法或操作/代码集）依赖接收者，并且因接

收者的不同而异。这一区别对于支持信息隐藏和多态（重载）是必要的。

第三，在面向对象的范型中，通常在运行时才能知道给定消息的特定的接收者。这样，

在消息（服务请求/函数调用）和用来完成对行为的请求的方法（代码片段）之间存在后期

连接。命令式编程范型中的函数调用与代码片段之间存在的是早期连接（编译或连接时）。

（6）分类

•把具有相同属性和服务的对象划分为•类，用类作为这些对象的抽象描述。

•分类帮助我们组织我们所生活的复杂世界。我们可以对在一个特殊分类中的对象做一

些假设。如果一个对象是分类（类）的一个实例，它将符合该分类的总体模式。

类/对象

所有的对象都是类的实例。实例能够在运行时被产生（初始化）或销毁（删除）。

•对象怎样提供服务由该对象为其实例的类所决定。这样，同一个类的所有对象在响应

特定的服务请求（功能调用）时使用相同的方法。

（7）泛化

•无多态性的泛化•类可以由层次继承结构所组织。在该结构中，子类将从位于层次结

构高层的父类中继承属性、关系和方法。抽象的父类是指仅用来产生子类的超类。这样，抽

象类就没有直接的实例。

有多态的泛化.可以使用层次继承结构组织类，子类可以继承位于层次结构的高层的父

类的属性、关系和方法。然而，子类可以产生它自己的方法来代替其任何超类的方法。

多态是指同一个命名可具有不同的语义。00方法中，常指在一般类中定义的属性或服务

被特殊类继承之后，可以具有不同的数据类型或表现出不同的行为。

对于子类，可用不同的方法替代实现父类的服务的方法。用途：把具有共同基类的对

象组成一组，并对它们进行一致的处理。例如，多边形下的三角形、长方形、正多边形。

6

(8)关系

向客户提供服务的对象之间的协作通常由关联关系捕获，在技术上把其称为链。

还有在课程的后面的部分，我们将讨论的聚合关系和依赖等关系。

(9)行为

行为分析是我们用来考察一个对象(类)是怎样提供它的服务(也就是方法)的过程。

从分析的视点，有两种类型的行为：

-静态的

-动态的

在静态行为中，方法内的操作(代码)不被任何外部或内部的事件(动作)所影响。

在行为中发生这些变化的原因可能是由于对象存在很多不同的状态。随后，对象根据它

的状态做出反映。使用命令式编程技术不能很好地处理这种类型的行为。使用另外的一种称

为有限状态机的机制会更好地捕获这样的方法。

例子：航班定票系统中的定票过程对象“机票”的状态：预定、等待、确认、取消、

使用、归档。

(10)粒度控制

引入包(package)或主题(subject)的概念，使模型具有大小不同的粒度层次，以利于

控制复杂性。

UML(统一建模语言)：UnifiedModelingLanguage

面向对象分析(00A)是对现实世界对象实体和概念建立用户可理解的、准确和简明的问

题模型的过程。

面向对象设计(00D)是按对象的协作集合组织解决方案的阶段，每个对象实体代表类的

一个实例，类的所有成员通过继承关系组织在一起。

面向对象编程(OOP)是使用一种支持面向对象方法的语言实现面向对象设计的过程。上

面两个阶段共同提供了面向对象编程的框架。典型的支持OOP的语言是C++和Java及C#。

在00A中，构建与现实世界原型相对应的问题模型。此外，非编程人员也应能够理解系

统的定义。换句话说，面向对象的分析着重强调从现实世界原型角度表述问题。

00D方法要求在设计中要映射现实世界中指定问题域中的对象和实体，例如：顾客、汽

车和销售人员等。这就需要设计要尽可能地接近现实世界，即以最自然的方式表述实体。所

以面向对象技术的优点即为能够构建与现实世界相对应的问题模型，并保持他们的结构、关

系和行为模式。

系统建模有助于实现如下目的：模型有助于按系统本身或者按需要对系统进行可视化、

模型有助于确定系统的结构和行为、模型为开发者构建系统提供模板、模型记录开发者所

做的决策，以备将来使用。

模型的演变经历了以下阶段：•GradyBooch的Booch建模方法，JamesRumbaugh的对

象建技术一OMT,IvarJacobson的OOSE方法•Hewlett-Packard的Fusion方法•Coad和

Yordon的00Aand00D«

人们越来越发现非常有必要建立构建对象模型的通用和标准方法。要求用一套标准的符

号和示图清晰地表达设计决策。为了这个目标，JamesRumbaugh,GradyBooch和Ivar

Jacobson做了开创性的努力，并提供了一整套示图、符号表示法。

统一建模语言UML(UnifiedModelingLanguage)：UML是一种建模语言,它主要组成

是一些用面向对象方法表达系统设计的图形符号。它是一种用于对软件密集性系统进行可视

化、具体化、结构化和文档化的建模语言。

UML用来建立用户、分析人员、设计者和软件开发人员之间的轻松对话.

7

软件开发生命期（SDLC）:是指由分析人员、设计人员和使用者为了开发并实现一个信

息系统所进行的系列操作。这些操作在儿个不同的阶段中执行。

分析人员：研究客户/用户的需求，并定义问题域。

设计者：依据数据库结构、界面、表单和报表设计系统。确定所开发系统的软硬件配置。

使用者：正在开发的系统的使用者.

SDLC的阶段：•初步调查（可行性研究）•需求分析，系统设计・软件构建（编码）•系

统测试•系统实现・系统维护

UML与SDLC各阶段的对应关系

初步调查：UML通过使用案例描述用户的需求。每个使用案例使用文本详细描述用户的

具体需求。UML通过使用案例示图描述系统内部的相互关系和动态交互。

分析：在此阶段中，要对问题域进行抽象，理解其内部的运行机制。类表达了现实世界

的对象，并描述他们的存在和相互关系。分析过程中只考虑问题域中的类。

设计：在设计阶段，对分析阶段的成果提出技术上的解决方案。对类进行细化，以提供

技术框架，例如，用户界面、面向对象数据库的永久对象、和本系统或其他系统的接口。本

阶段最后生成一个系统构建的详细说明文档•

构建（编码）：本阶段中把设计模型转换为真正的代码。程序员使用在设计阶段生成的

不同的UML示图理解和开发代码

测试：UML有许多不同的示图支持软件测试。单元测试使用类示图和类规范。集成测试

使用集成示图和协作示图，系统测试通过使用案例图验证系统是否能执行用户要求的操作

用例之间的关系：泛化、扩展、包含。

用例泛化关系：将特定用例抽象为更•般的用例，子用例继承父用例的属性、操作以及

行为顺序，可以增加自己的属性和操作•子用例与父用例有相同的业务目的。

如：

用例的扩展：一种依赖关系，客户用例依赖于基用例・客户用例向基用例（扩展点）插

入额外的动作序列来增加增量行为。比如查看清单是购物的扩展，透支是取款的扩展等。

在开发过程中常发现要开发的新用例所需的部分功能已有其它的用例提供•这种情况

下将的用例定义为已存在的用例和附加功能之和•这样的用例可看作是旧的用例的扩展。

两个用例之间的扩展关系，代表基用例可以隐式地包含另一个用例作为其行为的一部

分，包含的位置间接地由另一个用例（扩展用例）确定。基用例可以独立于扩展用例单独存

在。

当一个用例有多个子流程时，可以用扩展关系对其进行扩展，使得此基用例的不同子流

程能在不同的情形下以扩展用例的形式被激活

UML把包含关系和扩展关系表示为依赖关系的构造型，而在某些工具（如visio）中，它

们被表现为泛化关系的构造型。

在任何一种图形表示中，箭头所指的模型元素分别代表被包含的用例或被扩展用例（基

用例），而包含关系和扩展关系的构造型标记分别是〈〈include〉〉和〈〈extend〉〉

包含（使用）关系：

8

当许多用例有一个共同的操作，可只建一个用例模型并为其他的用例使用，这样的关系

叫做包含关系。“取款”用例使用“口令验证”和“打印回执”用例。

用例的包含：在客户用例的控制下，对提供者用例在客户用例的交互顺序中的行为顺序

的包含。如

include意思是包含、用到，可理解为与"使用”相同.“使用关系”形状中的箭头指向

被使用的UseCase。

位于两个用例之间的包含关系意味着基用例显式地在其指定位置将另一个用例包含进

来，使其成为自己的行为的一部分。包含关系可用于提取共用的用例。在具有包含关系的两

个用例中，被包含的那个用例不能单独存在，它只能以实例的形式存在于包含它的用例之中。

组合(Package)关系：

当许多用例具有类似的功能或者以同样的方式相互联系，就将他们归在一起。•UML的

程序包表示了用例的组合。

如何通过Actor捕获UserCase?

用例图：主要用于对系统、子系统或类的行为进行建模。

益处：

•通过表示在语境中参与者如何与系统交互，使得系统、子系统和类对于用户和开发者

易于探讨和理解。•易于对需求规范化•有利于进行00A•有助于发现主动对象•对系统测试来

说，产生测试用例。

系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。

系统：是由“用户”使用的软件，以及所有与其相关的硬件•指被开发的计算机软硬件

系统，不是指现实世界的系统。

系统成分：在00A和00D中定义，在编程时加以实现的系统元素——对象

系统边界

•定义：系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。

•系统是指被开发的计算机软硬系统，而不是泛指问题域的全部事物所构成的现实系统。

问题域中的某些事物(如使用系统的人员)将被看成是位于系统边界之外，作为参与者处理。

9

•如果在其中使用一个原来已经存在的系统（即这样的系统此时不需要再开发），这样

的系统就应该放在正开发的系统之外，把它看作是一个外系统。如果个大系统在任务分解

时，被划分成几个子系统，则每个子系统的开发者都可以把其他子系统看作是外系统，系统

边界以内只包括自己所负责的子系统。

现实世界中的事物与系统的关系包括如下几种情况：

■某些事物位于系统边界内，作为系统成分。如超市中的商品，抽象为系统内的“商品”

对象。

■某些事物位于系统边界外，作为参与者。

■某些事物可能既有一个对象作为其抽象描述，而本身（作为现实世界中的事物）又是

在系统边界以外与系统进行交互的参与者。如超市中的收款员，他本身是现实中的人，作为

参与者；在系统边界内，又有一个相应的“收款员”对象来模拟其行为或管理其信息，作为

系统成分。

■某些事物即使属于问题域，也与系统责任没有什么关系。如超市中的保安员，在现实

中与超市有关系，但与所开发的系统超市商品管理系统无关系。这样的事物既不位于系统边

界内，也不作为系统的参与者。

认识清楚上述事物之间的关系，也就划分出了系统边界。

参与者是在系统之外的与系统进行交互的任何事物。

概念与表示法

•定义:一个参与者定义了用例的使用者在与这些用例交互时所扮演的一组高内聚的角

色。

•参与者可以发出对系统服务的请求：参与者能够初始系统部分的动作

•按系统的要求提供服务：响应系统的请求

•通过参与者和系统之间服务请求的复杂对话与系统交互

•所有参与者的请求/响应的完全集构成了可以觉察到的系统的问题域边界。

系统从来不会对没有被设计的问题域部分作出响应，也就是说它不处理没有被设计的

请求［输入］。

•一个参与者的一个实例代表以一种特定的方式与系统进行的单独的交互。

尽管在模型中使用参与者，但参与者实际上并不是系统的一部分。它们存在于系统之

外。

一些参与者可能具有共同的对系统调用的请求。一种做法是显式地将这样同的每一个

请求与每一个参与者相关联。（不推荐）

如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另i个参与者中，它

们再从中继承，把这种关系称为参与者之间的泛化关系。

定义：从参与者A到参与者B之间的泛化关系是指，A的实例能与和B实例进行通讯的用例

实例进行通信。

总结：如何发现参与者？

人员——系统的直接使用者直接为系统服务的人员

设备——与系统直接相联的设备为系统提供信息在系统控制卜.运行不与系统相联

的设

外系统——上级系统子系统其它系统

外部事件

用例

用例是对一个参与者使用系统的一项功能的描述。

10

1、使用用例的原因

用例是对用户需求(主要是功能需求)的规范化的描述。用户需求是分析工作的起点，

但分析员能够得到的反映用户需求的材料常常是不够规范或不够准确的。通过全面、认真地

定义用例，可把用户对系统的功能需求比较准确地在用例中表达出来，并且在形式上是较为

规范的。

为领域专家、最终用户和开发者提供一种相互交流的手段。

为开发者提供一种认识和理解系统的方法。系统、子系统或类可能会很复杂，充满了

操作和其它部分。通过用例，可以帮助这些元素的使用者根据他们将如何使用这些元素而直

接地认识它们。如果没有这些用例，用户将不得不亲自搞清楚怎样使用这些元素。用例使一

个元素的作者可以就元素应该如何被使用，表达意图。

用用例是开发期间随着演化而测试每个元素的基础。通过不断地测试每个元素和它的

用例，可以不间断地校验它的实施。这些用例不仅为单元测试提供了依据，而且每当向一个

元素中加入新的用例时，还可以迫使我们重新考虑这个计划的实施，以确保这个元素易于修

改。否则，必须恰当地调整体系结构。

Usecase说明:

(1)一个用例描述参与者对一项或几项系统功能的使用情况。而且只有当外部的参与

者与该系统或类目进行交互时，该功能才发挥作用。

(2)是对一组动作序列的描述。

(3)描述参与者和系统在交互过程中双方所做的事。

(4)描述彼此为对方直接地做什么事，不描述怎么做

(5)描述应力求准确、清晰，允许概括，但不要把双方的行为混在一起。

(6)系统执行该动作序列来为参与者产生一个可观察的结果值。

(7)这些行为实际上是系统级的功能，用来可视化、详述、构造和文档化在需求获取

和分析过程中所希望的系统行为。内部细节不要在其中描述。

用例与参与者之间的关系：

定义：关联是参与者在用例中的参与(也就是参与者实例与用例实例之间的相互通信)。

任何一方都可发送和接收消息。

这是参与者和用例之间的唯一关系。交互是双向的，参与者能够产生对系统的请求，或

系统要求参与者采取某些动作。

把参与者和用例之间的关联表示成参与者和用例之间的一条实线。

一个用例可能要与系统的一个或几个参与者交互。

)捕获用例的策略

捕获系统功能时，要注意考虑问题的抽象层次，因为所处的抽象层次不同，考虑问题的

出发点也不同。对系统的功能描述的抽象层次分为三类：

高层用例(high-level)和低层用例

高层用例描述对有价值的功能所提供的要素做了总的、简要的描述，并不考虑这些有价

值的功能是怎样获得的。低层用例描述提供了表示活动、任务或变化的确切顺序的业务细节。

主要用例(primaryusecase)和次要用例(secondaryusercase)

主要用例捕获系统的基本业务功能，即向用户提供系统存在的理由的功能。次要用例处

理不常见的和例外的情况。

基本用例(essentialusecase)和真实用例(realusecase)

基本用例是独立于实现的(硬件的和软件的)业务解，而真实用例是依赖设计的。基本

和真实的区别是黑盒和透明盒模型之间的区别。

2)利用参与者捕获用例

11

对所有的参与者（把自己作为参与者），提问下列问题：

■每个参与者的主要任务是什么？

■为了达到某种目的，它们参加什么活动？该参与者是否将读、写或修改系统的任何信

息？参与者是否该把系统外部的变化通知系统？参与者是否希望系统把预料之外的变化通

知自己？

■在交互过程中，它们是怎样使用系统的服务来完成它们的任务以达到目的？

■它们参加了什么在本质上是不同的过程？

■是什么事件引起了与系统进行交互的序列？

能完成特定功能的每一项活动明确地是一个用例。这些参与者参与的活动，通常会导致

其它用例。

3）从系统功能角度捕获用例

用于本步骤的一些简单的指导如下：

1）一个用例描述一项功能，这项功能不能过大。例如，把一个企业信息管理系统粗略

第分为生产管理、供销管理、财务管理和人事管理等几大方面的功能，就显得粒度太大了，

应该再进行细化。

2）全面地认识和定义每一个用例，要点是以穷举的方式考虑每一个参与者与系统的交

互情况，看看每个参与者要求系统提供什么功能，以及参与者的每一项输入信息将要求系统

作出什么反映，进行什么处理；另外，要以穷举的方式，检查用户对系统的功能需求，是否

能在各个用例中体现出来。

用例文档模板

用例名

描述：对该用例的一句或两句的描述。

参与者：识别参与用例的参与者。

包含：识别该用例所包含的用例。

扩展：识别该用例可以扩展的用例。

泛化：若该用例是子用例，则要说明它的父用例。

前置条件：启动此用例所必须具备的条件。

细节：识别该用例的细节（可选）。

后置条件：识别在该用例结束时确保成立的条件。

例外：识别在该用例的执行的过程中可能引起的例外*。

限制：识别在应用中可能出现的任何限制*。

注释：提供可能对该用例是重要的任何附加信息。

用例示例：

表示形式：名称（参与者，功能）行为描述控制语句括号或标号

收款员收款

输入开始本次收款的命令；作好收款准备，应收款总数置为0,输出提示信息；

for顾客选购的每种商品do

输入商品编号；

if此种商品多于一件then输入商品数量endif；

检索商品名称及单价；货架商品数减去售出数；

if货架商品数低于下限then

通知供货员请求上货endif；

计算本种商品总价并打印编号、名称、数量、单价、总价；总价累加到应收款总数；

endfor；

12

打印应收款总数；

输入顾客交来的款数：

计算应找回的款数，

打印以上两个数目，

应收款数计入帐册。

用例图展示了用例之间以及同用例与参与者之间是怎样相互联系的。用例图用于对系

统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实

现这些元素。

定义用例图呈现了一些参与者和一些用例，以及它们之间的关系。

在图形上，用例图是一幅由一组参与者、一组用例以及这些元素之间的关系组成的图。

这些关系是参与者和用例之间的关联、参与者之间的泛化，以及用例之间的泛化、扩展和包

含。

可以选择把一些用例用一个矩形围起来，用来表示系统、子系统或“类”的边界。

用例图可以包含注解和约束。

在分析软件系统的功能设置时,应该把重点放在描述软件系统的外部边界上即重点考虑

用户对软件系统的功能设置的合理性、方便性和运行效率的要求，而不应该在需求分析阶段

就过多地考虑软件系统的结构和内部实现机制。这是在对软件系统进行需求分析时，应该遵

循的一个重要原则。

例2：为“设备”对象设立一个属性，名为“状态”属性值：关闭、待命、运行、故障

等。

在这里，“状态”是一个专门设置的属性，它的值反映了实际事物的状态。

状态转换图(STD)

A入*S»)

律也＜未交)

MVC通过以下三种方式消除与用户接口和

面向对象的设计有关的绝大部分困难：

控制器通过一个状态机跟踪和处理面向操作的用户事件、MVC将用户接口与面向对象

的模型分开MVC允许应用的用户接口进行大的变化而不影响模型

尽管MVCMVC设计模式很早就提出，但在WebWeb项目的开发中引入MVCMVC却是步履维艰。

主要原因：在早期的Web项目的开发中，程序语言和HTML的分离一直难以实现脚本语言

的功能相对较弱，缺乏支持MVC设计模式的一些必要的技术基础

在使用Java开发WebApplication中符合

MVC设计模式的开发方式：

Jsp+Serv1et+JavaBean(EJB)

Jsp+JavaBean(Controller)+JavaBean(EJB)(Model)

TDK(Turbine,Velocity...)

Xsp(Cocoon)

Jsp+Struts+JavaBean(EJB)

13

创建WebWeb应用程序的方法

将JSP用于显示，将JavaBeans用于逻辑

在一个Model-View-Controller（MVC）结构（也称为Model-2）中将servlets、JSP

和JavaBeans一起运用

struts是MVC的一种实现，它将Servlet和JSP标记（属于J2EE规范）用作实现的一部

分。Struts继承了MVC的各项特性，并根据J2EE的特点，做了相应的变化与扩展

Struts的体系结构实现了Model-View-Controller设计模式的概念，它将这些概念映射

到web应用程序的组件和概念中

基于MVC的系统中的Model部分可以细分为两个概念：系统的内部状态能够改变状

态的行为

View:JSP页面和表示组件：

基于Struts的应用程序中的View部分通常使用JSP技术来构建

JSP环境包括了其用途由JSP规范来描述的•套标准的行为标记，一个用来定义你自己

标记的标准机制，这些自定义的标记组织在“定制标记库”中。

Struts包括了一个广阔的便于创建用户界面，并且充分国际化的定制标记库，与作为系

统

Model部分一•部分的ActionFormbeans美妙地相互配合

Controller:ActionServlet和ActionMapping

应用程序的Controller部分集中于从客户端接收请求，决定执行什么商业逻辑功能,

然后将产生下一步用户界面的责任委派给一个适当的View组件。在Struts中，controller

的基本组件是一个ActionServlet类的servlet

Struts也支持使用包含有运行框架所必需的标准属性之外的附加属性的

ActionMapping类的能力

Struts的创建：

创建Model组件：

通常说来，Model组件的开发者集中于创建支持所有功能需求的JavaBeans类。通常可

以分成下面讨论的几种类型：ActionFormBeans系统状态Beans商业逻辑Beans

创建View组件：创建应用程序中的View组件的任务，主要使用JSP技术建立，主要内

容包括：国际化消息表单和FormBean的交互其它的表示技术（特定于应用程序的定制

标记、有包含文件的页面组件、图片处理组件）

创建Controller组件

Struts包括,•个实现映射一个请求URI到一个行为类的主要功能的servlet。因此你的与

Controller有关的主要责任是：为每一个可能接收的逻辑请求写一个Action类，写一个

定义类名和与每个可能的映射相关的其它信息的ActionMapping类,写行为映射配置文件（用

XML）用来配置controllerservlet,为应用程序更新web应用程序展开描述符文件（用XML）

用来包括必需的Struts组件，给应用程序添加适当的Struts组件。

Struts优缺点

优点：

Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，使开发者能更深入的

了解其内部实现机制Taglib。Taglib是Struts的标记库，灵活动用，能大大提高开发效率页

面导航，使系统脉络更加清晰

缺点：

Taglib是Struts的一大优势，但对于初学者而言，却需要一个持续学习的过程，甚至还

会打乱你网页编写的习惯，Struts将MVC的Controller一分为三，在获得结构更加清晰的同

14

时，也增加了系统的复杂度

Struts逐步越来越多运用于商业软件。虽然它现在还有不少缺点，但它是一种非常优秀

的J2EEMVC实现方式

什么是设计模式？简述2种设计模式

设计模式描述了一个通用的设计结构，该结构能被用来构造可复用的面向对象设计，确

定了所包含的类、实例以及它们的角色、协作方式。

使用设计模式的好处：1)确定系统对象2)决定对象粒度3)指定对象接口4)描述对象

实现5)运用复用机制6)平滑结构映射7)支持需求变化

原则：1)针对接口编程，而不是针对实现编程2)优先使用对象组合，而不是类继承

设计模式类别-创建型(Creational)-结构型(Structural)-行为型(Behavioral)

创建型(CreationalCreational)模式：以建立对象来解决问题：-ClassACA=ne\v

ClassAO;工厂模式单件模式

工厂模式

存在一个创建对象的工厂调用者从中取得特别的对象由工厂决定如何符合调用需

求客户不知道对象如何生成

单件模式

整个系统中对象是唯一的也可以有固定数目个-如：对象池、portal中的配置对象

当前httpcontextappdomain

结构型(StructuralStructural)模式

与对象之间的结构有关涉及两个或两个以上对象间活动没有限制-小结构组织大

结构，组织解决方案

组合模式(composite)：通常以大对象方式出现由众多小对象组成

BehavioralBehavioral模式行为型

Iterator模式封装多个元素使用户正确使用遍历内部内容

Proxy模式：客户端---proxy---sever

大数据调用大计算远程计算机访问限制访问权限

文档设计模式的具体实例：36—47页20100526_设计模式概论

动态模型的必要性：

动态模型——对真正工作的系统建模并且展示其可能的执行状态

动态模型处理系统中对象生命周期中的各个不同阶段

需要动态模型因为它表达了系统在时间上的变化

所有系统都有静态结构和动态行为！对象模型中的类图和对象图用来描述系统的静态结

构。动态模型用于表达系统的行为(动态)！

系统中动态实体之间的通讯可以使用UML中

的四种图来描述:顺序图(sequencediagram)协作图(collaborationdiagram)活动

图(activediagram)状态图(statechartdiagram)

UML包括9种示图(diagram)

静态结构：类图(classdiagram)对象图(objectdiagram)组件图(Componentdiagram)

部署图(deploymentdiagram)

动态结构：使用案例图(usecasediagram)顺序图(sequencediagram)协作图

(collaborationdiagram)表示动态行为活动图(activediagram)状态图(statechart

diagram)

交互图包括(顺序图、协作图)

通过类图，可以描述问题域的词汇；

15

组件图与部署图是用来对面向对象系统的物理方面建模的两种图。组件图显示一组组件

之间的组织及其依赖关系。部署图显示运行时进行处理的节点和在节点上活动的组件的配

置。

通过使用案例图，可以描述系统的期望行为。

通过使用顺序图，协作图、状态图和活动图可以说明所定义的问题域词汇中的事物是如

何共同协作来完成这一行为的。

动态模型的内容

顺序图(sequencediagram)-本图描述了对象实体之间的交互-主要的重点在于从

时间的角度描述这些交互作用

协作图(collaborationdiagram)-本图和序列图一样描述了对象实体