第07章 面向对象的分析与设计

第七章面向对象的分析与设计

本章内容

第一节原理和工具

第二节面向对象的分析与设计的过程

第三节识别系统的目标和边界

第四节用例和用例图

第五节对象与类图

第六节交互图

《第一节原理与工具

-00方法的发展

■00方法的基本概念

-00方法的建模语言UML

面向对象方法的优势

■对问题空间的理解更直接，更符合人们认识

客观事物的思维规律

■系统分析、系统设计和系统实现使用同一模

型，不存在过渡困难

■开发出来的信息系统从本质上具有更强的生

命力

■维护成本降低

.一、面向对象发展

■60年代后期：Simula67,基本思想

面向对象

年代后期：实用化

■70SmalltalkSO,理序设计语言

■1982贝尔实验室：C++

■1985微软：MS-Windows

■1995Sun：Java

£90年代：面向对象与设计方法学上“方法大战”

：-B・H.Sellers等提出喷泉模型

■G.Booch提出面向对象开发方法等

■P,Coad和E,Yourdon提出00A和00D

；■Jacobson提出OOSE

■1997年：UML被OMG接纳为标准

4现状

-现状

■00成为最重要的软件开发方法

■00在GUI、模拟系统、游戏开发、应用框架、软

件构件化领域大显身手

■UML、MDA与RUP、敏捷开发

■构件技术（CORBA、COM、EJB、.Net、SOAP）

■类库与设计模式

.二、面向对象方法的基本概念

■对象

-类

-封装

■集成

-消息

■关系

■多态

,（工）对象（Object）

-《现代汉语词典》（商务印书馆，1996）的解

释是：对象是行动或思考时作为目标的人或

事物。广义地讲，对象可以是任何人或事物。

■对象是一些属性及专用服务的封装体，它是

问题域中一些事物的抽象。

■这些属性的值刻画了一个对象的状态；

■这些操作是对象的行为，通过它们改变对象的状

态（即属性值）

举例

属性counter

:

胤、度

value

总重量init()

燃料股分dec()

燃量inc()

料i

-

搭表物

一个计数器对象:

属性值

•

操作•清空

•

操傕

•加

1

点火减

轨道运行1

返回

对象举例

医疗保险账户

属性：操作：

姓名：张三查询余额

年度：2005拨入资金

医保号付费用

累计账户拨入金额：1800.00年度结转

累计账户支付金额：230.50

最高统筹限额：50000.00

累计统筹支付金额：680.00

《对象的属性

-属性是类的特征或特性

・属性的值是某一特定对象的属性值

.在类中属性名必须是唯一的

・每一个类的实例都有为这个类定义的所有

属性的值

《对象的操作

■对象的行为是由为此对象定义的一系列操作

决定的

-操作访问或修改对象的属性值

■一个类可能同时存在多个实例，也可能在某

一时刻没有实例

■一个类的所有实例都可以使用在这个类中定

义的操作

y(2)类(Class)

■对象类(Objectclass)简称类，是指有相同属性

和服务的一组对象的集合。

■类的概念体现了人类常用的一种思维方式一一抽象，

类就是对一组对象的抽象表示，同样包含属性和服

务两个部分。

■实例(Instance)：一个具体的对象就是该对象所

在类的一个实例

-类是抽象虚无的，实例是具体实在的(如个人帐户与我的

个人帐户)

■在程序运行过程中根据类定义来创建实例，每个实例互不

干扰，各自有自己独立的存储空间，保存自己特有的属性。

(如同数据类型和变量的关系)

3类举例

/个人帐户,张三的个人账户

类名'Name对象名张三

Income1800.00

Payment230.50

属性,

属性’Limitation50000.00

UsedLimitation680.00

GetBalance()GetBalance()

Save()Save()

，Pay()

Pay()

操作

操作'CarryForward()CarryForward()

*区分对象和类

-同类对象具有相同的属性和服务，是指它们

的定义形式相同，即具有相同的属性项和行

为方式，而不是说每个对象的属性值都相同。

■类是静态的，类的存在、语义和关系在程序执行

前就已经定义好了。

■对象是动态的，对象在程序执行时可以被创建和

删除。计算机中一个对象通常就是指一个实例

■有的场合不作区分

抽象类和接口

■抽象类(abstractclass)用来表征我们在对

问题领域进行分析、设计中得出的抽象概念。

■如“形状”就是一个抽象概念，圆是具体概念。

■接口(interface)是抽象类的变体。接口是

一些方法的集合，但所有方法都是抽象的，只

有声明而没有程序体。其它类需要实现某个接

口时才对这个接口的所有方法进行定义。

■比如很多物体都有“开”和“关”的操作，但对于

不同的对象类是抽象的行为，具体实现由不同的物

体来定义，如电灯的开、关和门的开、关。

定义一个几何计算的接口

interfaceMath

<

publicvoidarea();

}

classrectangleimplementsMathclasscircleimplementsMath

<<

privatedoubleheight,width;privatedoubleradius;

publicvoidareapublicvoidarea

<<

}}

}}

（3）封装（Encapsulation）

-封装即信息隐藏，它保证软件部件具有较好

的模块性。

■设计软件总体结构时，应尽量封装为独立的

模块，每个模块对外提供接口，而尽可能少

地显露其内部处理逻辑。（黑箱）

■对象是更高一个级别的封装体，它把数据和

服务封装于一个内在的整体。对象向外提供

某种界面（接口），可能包括一组数据（属

性）和一组操作（服务），而把内部的实现

细节（如函数体）隐蔽起来。

）良好封装的好处

■封装使对象对外仅提供接口，即可见的一些

属性和操作，而具体实现是不可见的。

■开发人员一旦设计好对象的界面（接口）后，不

需要等待该对象全部完成就可以进行后续开发，

实现并行工作

■只要对象接口不变，对象内部逻辑的修改不会影

响其它部件，便于复用，也减少了因修改引起的

“水波效应”；

■严密的接口保护，使对象的属性或服务不会随意

地被使用，对象的状况易于控制，可靠性随之增

强。

1|(4)泛化(Generazation)

■泛化是指将一组相关对象进行归纳，抽取它们共同

拥有的一般性的属性与服务进行封装，从而构造出

对象从一般到特殊的分类层次。特殊类拥有一般类

的语义性质，并具有自己特有的属性和操作。

■继承是泛化的具体实现手段。

-一般类/特殊类、父类/子类、超类/子类、基类/派生类等

都是相同的概念。可以简化系统的描述和实现，较好地实

现软件重用，提高效率。

-子类(特殊类)可以继承父类(一般类)的属性和操作,

也可以重新定义特殊行为。

■继承可分为单继承和多继承，单继承是指子类只从一个父

类继承，多继承是指子类从多个父类继承。

继承举例

继承下去

Student

多继承(Multi-Inheritance)

多继承可以设计成对多个接口的实现

⑸消息（Message）

■消息是指向对象发出的服务请求（对象间的交互

信息）O

■一个对象向另一个对象发消息请求某项服务，接收

消息的对象响应该消息，激发所要求的服务操作，

并把操作结果返回给请求服务的对象。

■一个消息应当包含以下信息：消息名、接收消息对

象的标识、服务类型、输入信息、回答消息。

■采用消息（而不是函数调用）这个术语的好处:

■1、更接近人们日常思维所采用的术语，符合对象

的独立自治原则；

■2、在分布式环境中，对象可以在不同的网络结点

上相互提供服务，消息具有更强的适应性。

(6)关系(Relationship)

-类之间的联系方式：

■(1)分类结构：继承/泛化(generalization)。类之间

的关系是指对象分类的层次关系，继承关系对于类中的所有

对象都成立，而不特指某个具体对象。

■(2)实现(realization):即描述和实现。一个接口可

以提供某些操作的描述，另一些类需要具体来完成这些操作,

即对接口进行实现。

■对象关系则是存在于具体对象实例之间的联系：

■(3)关联(association):组装结构和实例连接。表达

对象与对象的静态联系，是一种长期关系，比如整体和部分

关系。

■(4)消息连接：也称依赖(dependency):表达对象与对

象的动态联系(运行时)，是一种短期关系。

（7）多态（Polymorphism）

-多态性又叫多形性，指相同的操作（或函数,

或过程）可作用于多种类型的对象并获得不

同的结果。

■在OOP中多态的实现有两种方法：

■由覆盖（overtide）实现动态多态，子类对父类

的方法进行重写，称为运行时多态，展示的是父

类及其多个不同子类的多态性。

■由重载（overload）实现的静态多态，即利用重

载技术在一个类中定义多个名称相同、参数类型

不同的方法，称为编译时多态，是一个类中操作

多态性的表现。

多态举例

*

1

昌PRINT(GRAPHobJect1

HI歪,，.”I..

PRINT(JMAGEobject

多态的好处

-多态性一般需要建立在继承机制之上。

1.当给不同子类型的对象发送相同的消息时，消

息的发送者可以不用关心具体的对象类型，而

由对象自身做出不同的响应处理。

2.需要扩充一种新类型时，只需要从父类中再派

生出一个子类，覆盖父类的某些服务，而不需

要改动其它外部程序。

3.多态性极大地提高了重用性和灵活性，对象的

使用和理解也得以简化。

）三、统一建模语言

>OOA&OOD

>UML

面向对象分析与设计

-结构化分析与设计注重对过程进行建模，面向对象的分析

与设计则强调对事物和它们的交互建模。

■00A主要任务是分析问题空间的主要目标和功能，寻找存

在的对象，找出这些对象的特征和责任（即属性和服务），

以及对象间的关系，并由此产生一个完整表达系统需求的

规格说明——“做什么”的描述。

■00D主要任务是将分析得到的需求做进一步的明确和调整,

运用面向对象技术和前人总结的经验模式优化对象结构，

设计用户界面类和内部控制类，设计数据库结构等，它强

调的是对分析结果的完善和改良，产生一个指导面向对象

编程的详细规格说明——“怎么做”的描述。

■UML是00方法的标准建模语言

*UML的目标

■统一建模语言UnifiedModeling

Language-UML,是一个通用的可视化

建模语言

-充分运用面向对象的概念来构造系统模型（不仅仅是针

对软件）；

■建立起从概念模型直至运行体之间明显的对应关系；

.着眼于那些有重大影响的问题；

-创建一种对人和机器都适用的建模语言；

-提供扩展和专用机制，为新概念或特定应用提供支持。

UNIFIED

MODELING

LANGUAGE

，UML的历史

""R2004

UNIFIED

MODEUNG!

Fall1998LANGUAGE〜

OMGAcceptance,Nov1997

public

FinalsubmissiontoOMG,Nov'97

feedbackUML1.1

FirstsubmissiontoOMG,Jan97

UMLpartnersUML1.0

/

OthermethodsBoochmethodOMTOOSE

1989-1994期间，00方法从不足10种增加到50多种

&UML的创始人

■UML是由世界著名的面向对象技术专家G.

Booch>J.Rumbaugh和I.Jacobson发

起，在Booch方法、OMT方法和OOSE方法

的基础上，广泛征求意见，集众家之长，几

经修改而完成的。

■Threeamigos

BoochRumbaughJacobson

uoiieoiuniuuioo;ndi]6noji]±

uoj同网su/%/a/i//a(7^Uiqeieos

ABo/odo}uieisAsQOUBLUJOped

6uueaui6ue山ejsAssjoiej6d)uiiua;sAs

■M9IA}U9LUAO|d9aM3IAssaoojd/空

M9iAaseo-asn

、Ameuoi;ounj

fuaiudDeueurajeMffosajnionjis

sjeuiiuejOoJdjasn-pu3sjeuBisaa/^sAieuv

虚

MOiAuo!)e}uaiue|diu|M9IA|BOI6OIg

由13

在

国跄1+Wiwn《

yUML的4+1视图

■用例视图UseCaseView

■最终用户

■这些视图由用例视图所统一＞它描述项目干系

人(stakeholder)的需求；所有其他视图都

是从用例视图派生而来，该视图把系统的基本

需求捕获为用例并提供构造其他视图的基础

■逻辑视图LogicalView

■分析师和设计师

■系统功能和词汇；描述问题域的词汇，作为类

和对象的集合。重点是展示对象和类是如何组

晟4系统、实现所需系统行为的

3UML的4+3■视图

■进程视图ProcessView

■系统集成商

■系统性能、可伸缩性和吞吐量；建模在我们系统中的可执行

线程和进程柞为活动类。其实，它是逻辑视图面向进程的变

体，包含居点相同的制品

■实现视图ImplementationView

-程序员

■系统组装和配置管理；对组成基于系统的物理代码的文件和

构件进行蕖模。它同才羊展示出构件之间的依赖，展示一组构

件的配置管理以定义系统的版本

■实施视图DeploymentView

■系统工程师

■系统的拓扑结构、分布、移交和安装；建模把构件物理地部

奢到一组跖理招、可讣算节点上，如计算机和外设上。

&UML中的图

对整个系统而言：

■功能由用例图描述。

■静态结构由类图和对象图描述。

.动态行为由状态图、顺序图、协作图和活

动图描述。

.物理架构则是由构件图和部署图描述。

（工）用例图UseCaseDiagram

-用例图定义了系统的功能需求，它完全是从

系统的外部观看系统功能，并不描述系统内

部对功能的具体实现。是从外部执行者的角

度来描述系统提供的功能。

(2)类图ClassDiagram

■类图描述系统的静态结构，表示系统中的类

以及类与类之间的关系。

卜（3）对象图ObjectDiagram

对象图描述了一组对象以及它们之间的关系,

表示类的对象实例。对象图是对类图一种实

例化。是系统某个时期可能存在的具体对象

实例。

1号会员：会员0012号租赁：租赁记录

编号=1租赁号=0012

入会日期=2002/09/01租赁日期=2002/09/10

姓名=李立预付款=100

《飘》001：项百一

0012号内容1：租赁明细项

序号=001

名称=飘租赁天数=3

每日租金=5归还日期=

状态=租出

（4）状态图StateChartDiagram

-状态图表示一个状态机，强调对象行为的事

件顺序。是对类的补充，展示此类对象可能

的状态和发生某些事件时其状态的转移情况。

（5）活动图ActivityDiagram

■活动图反映系统中从一个活动到另一个活动

[.⑹顺序图SequenceDiagram

■顺序图和协作图均表示一组对象之间的动态

协作关系，其中顺序图反映对象之间发送消

息的时间顺序

(7)协作图CollaborationDiagram

■协作图反映收发消息的对象的结构组织。顺

序图和协作图是同构的，即两者之间可以相

互转换。

⑻构件图ComponentDiagram

■构件图描述程序代码的组织结构。构件以及

它们之间的依赖关系，表示系统的静态实现

视囱O

UML2.0中的构件图

]|(9)实施图DeploymentDiagram

-实施图(部署图)反映了系统中软件和硬件

的物理架构，表示系统运行时的处理节点以

及节点中构件的配置。

UML2.0新增图

■包图正式化

■协作图(CollaborationDiagram)改名为

通信图(CommunicationDiagram)

■交互概览图(InteractionOverview

Diagram)

■复合结构图(CompositeStructure

Diagram)

■定时图/计时图(TimingDiagram)

y(10)UML建模工具

■RationalRose98、2000—2003

(UML1.3)

■RationalSoftwareArchitect(UML2.0)

■MicrosoftVisio

■PowerDesigner

■Together

■其它软件产品……

上第二节面向对象的分析与设计

■1.识别信息系统目标和系统边界。

-2,识别用例，建立用例图。

■3.识别对象、类及其关系，建立类图。

-4,设计用例的详细实现逻辑，建立顺序图和

协作图。

-5,精化并调整。

*第三节识别系统的目标和边界

■根据企业目标制定信息系统的目

标

■根据企业流程和业务内容，识别

所包含的信息处理，确定信息系

统范围

&一、识别信息系统的目标

-信息系统目标要尽可能地明确和简洁；

■采用积极正面的方式表达，因此用的词如

“帮助”、“提高”、“维持”、“支持”

和“推动”等；

-每个描述都支持整个企业行为；

■避免使用技术术语。目标的表述常常不用计

算机或其他技术常语，因为它只是尝试着定

义“一个信息系统将要做什么”，而不是

“这个信息系统如何去做”。

《信息系统目标举例

■某便利店信息系统的目标是：帮助收银员提高结

账的工作效率，保存好每笔销售记录，更有效地

支持商店的操作。

■某材料仓库（任何仓库应用）信息系统的目标是：

帮助人员更有效地实现进货和出货，从而提高仓

库的收益……确保库存商品数量的正确性，并提

高库存率。

■某订货中心信息系统的目标是：提高接收货单、

货单运送和付款的效率和正确率。

■某自动导航系统（任何其它实时控制系统）信息系

统的目标是：维持飞机的高度、方向和飞行途中

的状态。

*二、明确信息系统的边界

-通过识别系统参与者来确立系统边界。

■系统参与者（Actor）:直接使用信息系统，

与系统之间进行信息交换的人或事物。

■谁负责提供、使用或删除信息？

-谁将使用此功能？

■谁对某个特定功能感兴趣？

■在组织中的什么地方使用系统？

■谁负责支持和维护系统？

■参与者可以是个人、外部硬件、第三方系统

参与者举例

■参与者为旅行社

机票预订系统

■参与者为旅客

机票预订系统

/三、门诊系统案例说明

■挂号

■窗口挂号、预约挂号，普通号/专家号/教授号

■建档

■就诊

■医生书写诊断和处方

■存档

■交费

■根据处方收费

■收费处维护各项收费标准

J第四节用例与用例图

-基于用例的需求分析：

■确定系统应具备哪些功能，这些功能是否完整

表达了系统的需求；

■为系统功能提供清晰规范的描述，这是开发人

员之间以及开发人员与用户之间交流的基础，

也为系统测试和验收提供依据；

■以用例驱动，为具体实现的类及其方法提供跟

踪检测和设计启发。

、一、什么是用例

-用例是参与者与系统之间为达到某个目的而

进行的一次典型的交互过程。

■用例创始人雅各布森IvarJacobson认为：

■用例（usecase）是对于一组动作序列的描述,

系统执行这些动作会对特定的参与者（actor）

产生可观测的、有价值的结果。

.用例结构

■基本用例是包含常规会发生的最基本功能的

用例，它是具有普遍性的，对于任何执行该

功能的参与者来讲都是适合的。进行用例描

述时，往往会有冗余的情况出现，比如多个

用例会共享一些子功能。

■扩展和包含关系就是用例模型中消除冗余的

一种手段。

■但忌讳使用结构化的功能分解将用例分解成

一些子用例、子子用例。

y(1)基本用例

■一个最初的未经过分解、包含常规会发生的

最基本的功能的用例，称为基本用例。

■它是具有普遍性的，对于任何执行该功能的

参与者来讲都是适合的。

d(2)包含用例

■经过封装后可以在各种不同的基本用例中

复用的行为称为包含用例。基本用例可以

控制包含用例，并要使用包含用例所得到

的结果。

■包含用例是基本用例存在的必要条件

■一个基本用例可以有多个包含用例，一个

包含用例可以包含在若干基本用例中。

$(3)扩展用例

■表达某些可选或只在特定条件下才执行的

系统行为的用例，称为扩展用例。

■扩展用例是可选的，它是否执行取决于在

执行基本用例时所发生的事件

还书时可以直接

登记赔偿，也可

以不登记

k_7

〈〈exlend〉〉

归还图书登记赔偿

图书管理员

I,(4)泛化用例

■■用一个新的、通常也是抽象的用例来描述多

个用例的共有部分(父用例)，子用例继承父

用例的所有结构、行为和关系，并含有自己

特殊的部分。

■父用例通常是抽象的，如果两个子用例都对

同一父用例进行特殊化，则两个子用例是相

互独立而且完整的，这一点与包含关系扩展

*二、如何识别用例

-识别参与者

-识别用例

■审查用例

.(工)识别参与者(Actor)

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

工.使用系统的个人

■谁负责提供、使用或删除信息？

■谁替使用某项功能？

2.系统所连接的外部硬件。

■例如，控制建筑物中温度的通风系统不断地从传

感器获取温度信息，传感器就是一个参与者。

3.与该系统进行通信的其他信息系统。

■例如为自动柜员机系统建模时，中央银行系统就

是它的一个参与者。银行卡系统是销售系统中的

一个蓼与著

.区分参与者和DFD的外部实体

-只有在执行系统功能时与信息系统进行实时

交互的人员才能被当作参与者

■外部实体是指数据的来源和去向，提供数据

的人员不一定会执行系统功能

■新生入学手工填写个人信息，然后由教务人员统

一臀数据登记到学籍系统中，教务人员是参与者。

■如果学生直接通过Web方式提交个人信息，则认

为学生是参与者。

为区分直接参与者和间接参与者

-直接参与者是从系统中直接获得可度量价值

的用户。

■间接参与者的需求驱动了用例所表示的行为

或功能，在用例中起辅助支持作用

■用例分析的重点是要找到直接参与者。

■比如，门诊的窗口挂号中挂号员是直接参与者，

患者是间接参与者。

■在图书馆的借/还书用例中，首先要考虑谁直接

使用这一功能，谁频繁地和系统进行交互？图书

管理人员是直接操作者，他们的需求和变化对于

用例的影响最大。

《参与者的表示

■在UML中，参与者使用小人符号:

"；r、一RSA中的

M：符号）

1尸送件务K

〜，学隹

11节写周记

教帅3

容写周志意见

《参与者的泛化

-在某些情况下，参与者的角色可以有共性，

或者说一般性，一种角色可以拥有另一种角

色的全部行为。

■比如在超市系统中，值班经理完全可以充当收银

员这一角色，此外，值班经理还可以有退货、更

改事务等权利。

值班经理.，

,(2)识别用例(UseCase)

-用例就是功能性需求。

-每个用例至少和一个参与者相关，用例名称

要体现参与者希望系统提供的一项具体功能。

»用例的UML图形表示

(

Rose中的符号C

购买冏品

»区分用例和用例完成的步骤

-不能混淆用例和用例所包含的步骤。

■比如“借出图书”功能要经过验证读者信息、检

查超出可借数量、保存借书记录、修改图书状态

等步骤

■在系统中这些步骤通常不作为单独的功能提

供给参与者使用，它们只是一个用例所包含

的事件流，或者是用例的子功能。

■与结构化分析中提到的事件概念相同。

）区分业务用例和系统用例

-当针对整个业务领域建模时，使用的是业务用

例

■比如医生“检查患者”

■信息系统作为整个业务系统的一部分，只负责

管理业务的部分信息处理的功能，使用系统用

例：

■如上述业务用例应表示为系统用例，即医生“登记

检查结果”

4(3)用例的检查

■L每个基本用例应至少涉及一个参与者。

■2.如果两个用例总是以同样的顺序被激活，而且是

不可分割的操作序列，那么需要将它们合并为一个

用例。

■3.如果两个用例有非常相似的行为或事件流，可以

将它们合并为一个用例，或者适当采用包含用例或

扩展用例。

■5.用例的名称应具有惟一性、直观性和可理解性。

■6■一个用例中如果包含完全不同分支的事件流，可

以考虑分解成两个或更多个单独的用例。

■7.用例功能在信息系统中能体现。

.三、构建用例建模

基于用例的需求获取过程：

■1.获取原始需求

■2.开发一个可以理解的需求

-识别参与者

-识别用例

■构建用例图

■3详细、完整地描述需求

-书写用例规格说明

■4重构用例模型

-识别用例间的关系

-对用例进行组织和分包

口.(工)用例图

名称描述符号

用于描述与系统功能有关的外部实体，可以是人或其他系统

参与者大

(Actor)

表示用例图中的用例，每个用例代表系统的一项外部功能需求

用例匚

(Usecase)

关联连接参与者与用例(可以指定方向)

(Association)

>

包含关系从基本用例到包含用例的关系，由用例A指向用例B,指用例A«include>：>

(Include)定义的行为包含了用例B定义的行为

扩展关系从扩展用例到基本用例的关系，由用例A指向用例B,指用例A«Extend»>

(Extend)定义的行为在扩展条件满足时插入到用例B定义的行为中

泛化关系指一种从子用例到父用例的关系，由用例A指向用例B,指用例

------------O

(Generalize)A继承用例B的行为和含义，并且增加或覆盖了用例B的行为

系统边界界定系统功能范围，描述该系统的用例置于其中，参与者置于—

(Boundary)其外

用于对基本兀素的补充描述

注释(Notes)

$(2)用例的说明

-用例图是对系统中的用例的高度概括和直观

的表示，但没有细节。

■一个用例就象一个故事，使用文字叙述对用

例进行详细描述。

■一个编写良好的用例应该具有很好的可读性,

没有可读性的用例则一点儿用也没有。

■用例的描述可以有多种格式，从随意的语言

描述到定义严格的用例模板，可根据实际情

况选择。

用例规格说明Specification

用例名称

直接参与者/间接参与者

简要描述

前置条件

后置条件

主事件流（主要成功场景/基本路径）

备选事件流（扩展路径/替代流程/异常事件流）

特殊要求/非功能性需求

发生频率

用例事件流(FlowofActivities)

■用例描述的是一个系统做什么，可以通过

用足够清晰的、外部人员很容易理解的文

字描述一个事件流，来说明一个用例的行

为。

-事件流的描述包括：

■用例何时开始和结束

■用例何时与参与者交互(对话过程)

■参与者与系统之间有什么对象或信息被交换

■该行为的主事件流和备选事件流

,用例的前置条件和后置条件

■前置条件(pre-condition)：表述在系统允许

用例开始以前，系统应确保为真的条件。这可为

后续的编程人员提供帮助，从而确定在用例的实

现代码中哪些条件无须再次检验。

■如果前置条件不满足，用例无法被启动，比如“网上

挂号”用例的前置条件是用户已正确登录到系统中。

■后置条件(guarantee)：或称为成功保证。表

述在用例结束时，系统将要保证的限定条件，一

般都是在成功完成用例后成立。

■一旦用例被成功地执行，可能会导致系统内部某些状

态的改变，比如成功地“挂号”会使挂号限额改变等C

■某些用例可能没有前置条件或后置条件，比如挂

号员“查询”用例。

“取款”用例的完整描述

主参叮者：银行卡用户

目标：用户使用银行卡从ATM机获取现金

范围：银行ATM系统

前置条件：用户将信用卡插入ATM

后置事件：交易日志被保存

主事件流：

1.用户插入银行卡到ATM机

2.ATM系统识别卡的ID和账号，并用主银行系统验证其有效性

3.用户输入密码，ATM系统验证其有效性

4.用户选择取款，并输入提取金额，该数额必须在50〜2000之间,

50的倍数

5.ATM系统通知账户所在的主银行系统，传递账号和取款金额，

并接受返回的确认信息和账户余额

6.ATM系统发放现金、卡，并打印收据

7.ATM将事务记入日志

4对“取款”用例的完整描述（续）

备选事件流：

2a：该卡不能在此ATM机上使用

2al.提示错误并退卡

3a：密码不正确

3al.提示密码错误，返回3

3b：用户没有及时输入密码

■■■

4a：金额不是50的倍数，或不在指定范围

5a：主机死机或网络瘫痪

•••

5b：账户余额不足

发生频率：一天1000次

为四、门诊系统的用例模型

收款

员

.第五节对象与类图

建立逻辑模型的步骤

-识别对象

-识别对象属性

-识别对象服务

-确定对象分类层次

■确定对象关联关系

-构建类图

■永久对象的持久化

*一、识别对象

-有两种方法用来识别领域中的对象（概念），

从而确定概念类

1.从用例描述中获取候选概念

■摘取用例的详细文档中的名词（术语或名词短

语），然后进行分析

2.通过不同类别发现候选概念

（1）Wirfs-Brock名词短语策略

L阅读理解需求文档（或用例说明）；

2.反复阅读，筛选出名词或名词短语，建立

初始对象清单（候选对象）；

3.将候选对象分成三类，即显而易见的对象、

明显无意义的对象和不确定类别的对象；

4.舍弃明显无意义的名词或短语；

5.小组讨论不确定类别的对象，直到将它们

都合并或调整到其它两类。

名词策略举例

名词类别对象列表

显而易见的对象顾客、信用卡、收据、现金

明显无意义的对象“取消”按钮

不确定类别的对象密码、业务类型、取款业务类型、

机器、存款余额

q.（2）不同类别的概念

■人员：系统需要保存或管理其信息的人员（如录象商店

的会员、图书馆的读者），或在系统中中扮演一定角色

的人员（如录象商店的职员、论文评阅教师）。

■组织：在系统中发挥一定作用的组织机构（如录象商店

的连锁店，医疗保险系统中的医院，学校中的系）。

■物品：需要由系统管理的各种物品（如录象商店的商品、

图书），包括无形事物（如学校的一门课程、毕设题

目）。

-设备：在系统中被使用或由系统进行监控的设备、仪器

等，系统运行中的硬件设备（如打印机）除外。

■事件：需要由系统长期记忆的事件（如在自动柜员机上

的每次取款事件、每次借书事件）。

不同类别的概念（续）

■规格说明：系统中关于对象的规格信息的描述。

■如药品描述，每种药品有一个唯一的药品编号，同时

还包含一些描述信息，如名称、包装规格、价格、厂

家等，所有相同药品对象共用这些规格说明。这是一

种经过了抽象的概念，同样应该识别为概念类。

&(3)对象的检查

■对象的名称及说明是否清楚而且易于理解？对象的

名称必须有明确的符合问题空间的使用习惯，不能

有二义性，这样所有人员才能达成共识。

■对象是否参与至少一个用例的实现？如果一个对象

不参与任何用例的实现，说明该对象与系统没有责

任关系，应删除。如果该对象是从需求文档中获取

的，则不会出现这种情况。

-是否有表示同一种事物的对象？由于有的事物名称

不统一，可能会出现别名，如果有则将它们合并。

*(4)门诊系统的对象

所属类目对象举例

人员挂号员医生收款员患者

组织科室

物品挂号单病案发票普通号专家号教授号

设备

事件医生诊疗开处方交款

规范化描述药品描述检查项目描述挂号限额表挂号价

格表

八识别属性

■属性是描述对象静态特征的一个数据项。

■属性是对象自身能管理的特征

(1)识别属性的策略

见属性的策略：

-如何为对象做一般性的描述？比如人，一般的描述信息

有姓名、性别、出生日期、身高、体重等。

-在当前问题域，对象还具备那些特定描述项？比如人作

为门诊系统的患者，还需要考虑血型、药物过敏、家族

病史等。

-对象的责任是什么？在系统中对象还需要了解或提供哪

些信息？比如图书馆要实现催还功能，与该责任相关的

就需要为书籍或借书事项定义借书日期和期限。

-对象需要长期保存哪些信息？比如肥胖症患者病案中需

要保存以往的体重资料。

-对象可能处于什么状态？对象的状态不同，贝I可能执行

的操作也不同。比如出租物品就有在库、出租、维修三

个状态。

*(2)属性的检查

■属性名是否清楚？与对象命名一样，属性名称也必

须符合问题空间的使用习惯，不能含糊不清。

■该属性是否能在系统责任中发挥用途？如果一个属

性在系统中脱离主题，不参与任何操作，应标记删

除。但也可以考虑暂时保留，经过多轮分析设计后

仍然发现无用再舍弃。

■是否存在可导出的属性？比如年龄可以由出生日期

导出。除非导出算法很复杂或有特别的需要，否则

舍弃可导出的属性。

■该属性是否不是简单类型？简单类型是指布尔、日

期、数字、字符串、文本、时间等类型。

$(3)属性的说明

-每个属性需要说明如下内容：

■属性的名称和解释：有些属性只适用于该问题域,

是专业术语，晦涩难懂；有些常用词语在特定环

境下字面的含义有所修改，为了提高清晰度，需