UML基础与Rose建模实训教程CrunchYou|个人图书管理系统CRC建模_在线图书馆

9.1组件图（ComponentDiagram）...139

9.2部署图（DeploymentDiagram）...160

第10章双向工程...167

10.1正向工程...167

10.2逆向工程...177

第11章综合案例实训...182

11.1BBS论坛系统...182

11.2基于Web的求职招聘系统...205

附录RationalRose2003菜单...220

UML（UnifiedModelingLanguage，统一建模语言）是描述、构造和文档化系统（尤其是面向对象软件）制品的可视化语言，是用于面向对象建模图形化表示法的事实标准和法律标准。UML用来描述模型内容的基本构造块有三种：事物（Things）、关系（Relationships）和图（Diagrams）。事物是实体抽象化的结果，关系是事物连接的方式，图是事物和关系的组合，在后续的各章节中会逐步介绍其详细内容，本章主要通过两个实验，来初步了解UML中的用例图和类图。本章在全书知识体系中的位置如图1.1所示。

1.什么是用例图

用例图用于展示系统的参与者（也称角色）、用例（也称用况）及其相互关系。其中参与者指的是系统用户，用例指的是系统功能。用例图仅从参与者使用系统的角度描述系统信息，即处在系统外部分析系统功能，并不涉及系统内部对该功能的具体操作。用例图在定义系统功能需求时最为有用。

2.如何绘制用例图

借助用例图来描述系统需求一般可分三个步骤：首先，确定系统角色即参与者；其次，确定系统功能即用例；最后，确定系统中涉及到的关系（包括参与者之间的关系、参与者和用例之间的关系、用例之间的关系）。

在具体应用时，可辅以建模工具（如MicrosoftOfficeVisio、SybasePowerDesigner、IBMRationalRose等）将其描绘出来。

能够初步识别UML用例图中的参与者、用例及其关系，能够根据用例图对系统需求进行简单描述。

1.识别“CD销售系统”用例图。

2.根据用例图，对“CD销售系统”的功能需求进行简单描述。

1.识别“CD销售系统”用例图

如图1.2所示为“CD销售系统”的用例图。其中参与者表示为小人图形，如BandManager（乐队经理）、DiscManager（唱片经理）、RankService（排行榜报告服务）；用例表示为椭圆图形，如BrowseCDSale（查看乐队CD的销售统计）、BrowseRank（查看排行榜报告）、SearchCDSale（查看特定CD的销售统计）、SearchNewRank（检索最新的排行榜报告）；其中关联关系表示为实型直线，如BandManager和BrowseCDSale之间、RankService和SearchNewRank之间的连线。

2.根据用例图，对“CD销售系统”的功能需求进行简单描述

在图1.2中可以很容易地看出“CD销售系统”所提供的功能。该系统允许乐队经理查看乐队CD的销售统计报告及排行榜报告；它也允许唱片经理查看特定CD的销售统计报告和这些CD在排行榜的报告。通过此图还可以看出，系统将通过一个名为“排行榜报告服务”的外部系统来提供排行榜报告。

1.以下对于UML的描述，错误的是（）。

A.UML是一种面向对象的设计工具

B.UML不是一种程序设计语言，而是一种建模语言

C.UML不是一种建模语言规格说明，而是一种表示的标准

D.UML不是过程，也不是方法，但允许任何过程和方法使用它

2.从系统外部用户角度着眼，用于描述系统功能集合的UML图是___________。

3.识别如图1.3所示的用例图，并对其功能需求进行简单描述。

使用用例图时应注意如下事项：将系统视为黑盒，从用户的角度看待系统，以确定系统必须实现的功能；参与者描述的是系统中涉及的用户，现实生活中不同的人可能拥有多个角色；所有的交互都发生在参与者和用例之间，再没有其他可能发生的交互。

1.什么是类图

类图用于展示系统中的类、接口及其相互关系，类和接口体现系统需要处理的事物，关系体现系统内部的结构。一个典型的系统通常包含多个类图，其中单个类图只表达了系统的某一方面。类图在系统静态建模时最为有用。

2.如何绘制类图

使用类图进行系统静态建模一般可分两个步骤：首先，确定系统中的类、接口等事物；其次，确定事物之间的逻辑关系。在具体应用时，可借助建模工具将其描绘出来。

能够初步识别UML类图中的类、接口等事物，能够初步识别事物之间关系。

1.识别“教学管理系统”类图中的类、接口等事物。

2.识别“教学管理系统”类图中事物之间的关系。

1.识别“教学管理系统”类图中的类、接口等事物

如图1.4所示为“教学管理系统”的部分类图。其中类表示为一个矩形，该矩形被分隔成上、中、下三部分。上部描述类的名字，如Person（人）、Stu（学生）、Teacher（教师）、Course（课程）；中部描述类的属性，此处略去；下部描述类的操作，此处略去。

2.识别“教学管理系统”类图中事物之间的关系

以上“教学管理系统”类图中涉及到了两种关系：泛化关系和关联关系。其中泛化关系表示为一条带有空心箭头的实线，其方向指向父类，如Person和Stu之间、Person和Teacher之间的连线，标明学生类和教师类是人类的子类。其中关联关系表示为实型直线，如Stu和Course之间、Teacher和Course之间的连线，标明学生学习课程、教师讲授课程。

1.在UML的关系中，用来描述父类与子类之间关系的是__________关系。

2.“交通工具”类与“汽车”类之间的关系属于（）。

A.关联关系B.聚集关系

C.依赖关系D.泛化关系

3.请用UML图示描述“狗”和“小黄狗”之间的关系。

4.根据如图1.5所示的类图，回答问题。

（1）在该图中，涉及到的类有___________________________----------______。

（2）在该图中，涉及到的关系有_______________________________。

UML建模过程通常被分为以下四个连续迭代的阶段：分析阶段、设计阶段、实现阶段和部署阶段。在系统开发的每个阶段都需建立相应的模型，建立这些模型的目的也不尽相同。分析阶段的模型用来捕获系统的需求，多以用例图体现；设计阶段的模型用来扩充分析阶段的系统需求，同时为实现段提供解决方案，多以类图体现；实现阶段的模型用于将设计阶段的系统方案转化成实际事物（如可执行文件等），多以组件图体现；部署阶段的模型用来展示系统的物理架构，多以部署图（也称配置图）体现。

“工欲善其事，必先利其器”。为了更好地利用UML进行软件系统建模，我们首先需要获得支持UML的建模工具。自从UML正式发布以后，出现了大量的UML建模工具，如在第1章中提及的MicrosoftOfficeVisio、SybasePowerDesigner、IBMRationalRose等，其中以RationalRose使用较为广泛。

RationalRose工具由Rational公司（现已被IBM公司收购）提供，它具有建模功能强大、操作界面友好、可视化的特点，能够支持UML用例建模、静态建模、动态建模、物理建模等。本章将初步介绍RationalRose的安装、配置及使用，本章在全书知识体系中的位置如图2.1所示。

1.RationalRose的安装

2.RationalRose的启动

成功安装后，可以通过开始菜单启动该软件；也可以找到RationalRose的安装路径，默认情况下为C:\ProgramFiles\Rational\Rose\，双击该目录下的Rose.exe文件启动该软件。

3.RationalRose的配置

RationalRose成功安装、正常启动后，为了有效的完成建模工作，可以根据实际需要对环境进行配置。

能够熟练安装RationalRose，能够正确启动RationalRose，能够进行RationalRose环境配置。

1.安装RationalRose2003。

2.启动RationalRose2003。

3.配置RationalRose2003。

1.安装RationalRose2003

（1）运行RationalRose2003的安装程序，如果安装程序为压缩文件，将会打开“指定文件保存路径”对话框，如图2.2所示。此处默认的保存路径为“C:\ProgramFiles\RoseEnterpriseEditionforWindows”，单击【Change】按钮可以更改文件保存路径，单击【Cancel】按钮可以取消本次安装。

（2）单击【Next】按钮，打开“解压文件”对话框，如图2.3所示。

（3）文件解压完毕后，打开“Rational产品安装向导”对话框，如图2.4所示。

（4）单击【下一步】按钮，打开“选择安装产品”对话框，如图2.5所示。在此选择“RationalRoseEnterpriseEdition”准备安装企业版。

（5）单击【下一步】按钮，打开“发布方法”对话框，如图2.6所示。在此选择默认的“DesktopinstallationfromCDimage”即可。

（6）单击【下一步】按钮，打开“RationalRose企业版安装向导”对话框，如图2.7所示。

（7）单击【Next】按钮，打开“产品警告”对话框，如图2.8所示。

（9）单击【Next】按钮，打开“目标文件夹”对话框，如图2.10所示。单击【Change】按钮可以更改程序安装路径。

（10）单击【Next】按钮，打开“自定义安装”对话框，如图2.11所示。在此处可以自行选择要安装的项目，单击【Space】按钮可查看磁盘空间，单击【Help】按钮可查看帮助信息。

（11）单击【Next】按钮，打开“准备安装”对话框，如图2.12所示。

（12）单击【Install】按钮，打开“安装Rose企业版”对话框，如图2.13所示。

（13）软件安装完毕，打开“安装完成”对话框，如图2.14所示。

（14）单击【Finish】按钮，打开“注册向导”对话框，在此用户可以对软件进行注册，如图2.15所示。

2.启动RationalRose2003

RationalRose2003安装成功后，依次单击【开始】->【程序】->【RationalSoftware】->【RationalRoseEnterpriseEdition】启动该程序，如图2.16所示；或找到RationalRose2003的安装路径，如C:\ProgramFiles\Rational\Rose\，双击Rose.exe文件启动该程序。

启动RationalRose2003后，首先出现启动界面，如图2.17所示。启动界面消失后，进入到RationalRose2003的主界面，并且会弹出“创建新模型”的对话框，此对话框用来设置本次启动的初始动作，分为New（新建模型）、Existing（打开现有模型）、Recent（最近打开模型）三个选项卡。第一个选项卡New，用来选择新建模型时采用的模板，如图2.18所示。第二个选项卡Existing，用来打开一个已经存在的模型，如图2.19所示；第三个选项卡Recent，用来打开一个最近使用过的模型文件，如图2.20所示。

在此暂时不需要任何模板，只需新建一个空白模型，即单击【Cancel】按钮，直接进入RationalRose2003的主界面，如图2.21所示。

3.配置RationalRose2003

实际应用中可以根据个人喜好和具体情况，对RationalRose进行相应的配置。主要通过菜单【Tools】->【Options】->【General】进行常规操作，如图2.22所示。在此对话框中单击【Font…】（根据不同对象选择不同的【Font…】）按钮，弹出如图2.23所示的对话框，可以设置字体；单击【LineColor…】按钮进行颜色选择，如图2.24所示。

1.RationalRose2003的自定义安装

在自己计算机上安装RationalRose2003，并将安装路径选择在非启动盘符下，如D:\。

2.RationalRose2003的配置

在RationalRose2003中进行除常规设置外的其他设置，如使用菜单【Tools】->【Options】->【Toolbars】对标准工具栏和编辑区工具栏进行配置。

1.RationalRose2003软件的卸载

在控制面板的添加删除程序中对其进行卸载，而不仅仅只删除安装后的文件目录。

2.其他UML建模工具安装

在自己计算机上下载、安装一款其他UML建模工具，并与RationalRose进行比较。

使用RationalRose工具进行UML建模，通常包括创建模型、保存模型、发布模型、导入/导出模型等几个步骤。

能够使用RationalRose建模。

1.创建一个UML模型，命名为myFirst.mdl。

2.将该模型保存在D:\UML目录下，如无此目录可自行建立。

3.发布该模型。

1.创建模型

在RationalRose主界面中，单击菜单【File】->【New】，或直接单击标准工具栏的【CreateNewModelofFile】按钮，打开如图2.18所示的对话框，选择创建模型所需的模板，单击【OK】按钮确认，或直接单击【Cancel】按钮取消。

2.保存模型

在RationalRose主界面中，单击菜单【File】->【Save】，或直接单击标准工具栏的【SaveModel，File，Script】按钮保存模型，其文件扩展名为.mdl。如果该模型还未指定名称，将会打开如图2.25所示的另存为对话框。

3.发布模型

使用RationalRose建立的模型可以直接发布到Web上，以方便他人共享。在RationalRose主界面中，单击菜单【Tools】->【WebPublisher】，打开如图2.26所示的对话框，该对话框中可以选择发布到Web页面上的内容和HTML文件保存的位置，然后单击【Publish】按钮发布模型。如果打开所保存的HTML文件，则可以看到发布的RationalRose模型，如图2.27所示。

1.使用RationalRose建立的模型文件其扩展名为：_______。

2.通过RationalRose的【Tools】->【WebPublisher】菜单可以进行模型的_________操作。

3.创建一个空白的模型，命名为simpleTest.mdl；在simpleTest.mdl模型中添加一个简单的类图，保存该模型；将其发布到D:\UML\simpleTest.html文件，选择发布的图形文件类型为JPEG；查看发布的模型。

1.导出模型

在RationalRose主界面中，单击菜单【File】->【ExportModel】，打开如图2.28所示的对话框，可进行模型的导出。

2.导入模型

在RationalRose主界面中，单击菜单【File】->【Import】，打开如图2.29所示的对话框，可进行模型的导入。

3.RationalRose的主菜单

RationalRose的主菜单如图2.30所示，主菜单中各菜单的含义说明详见表2.1所示，主菜单的各级子菜单含义及功能可参阅本书附录。

表2.1RationalRose主菜单说明

序号

菜单

含义

File

文件

Edit

编辑

View

视图

Format

格式

Browse

浏览

Report

报告

Query

查询

Tools

工具

Add-Ins

插件

Window

窗口

Help

帮助

4.RationalRose的工具栏

RationalRose的工具栏如图2.31所示，其中各按钮的含义详见表2.2所示。

表2.2RationalRose工具栏

按钮

英文含义

中文含义

CreateNewModelorFile

新建模型或文件

OpenExistingModelorFile

打开已有的模型或文件

SaveModel,FileorScript

保存模型，文件或脚本

Cut

剪切

CopyDiagram

复制图形

Paste

粘贴

打印

ContextSensitiveHelp

动态帮助

ViewDocumentation

浏览文档

BrowseClassDiagram

浏览类图

BrowseInteractionDiagram

浏览交互图

BrowseComponentDiagram

浏览组件图

BrowseStateMachineDiagram

浏览状态图

BrowseDeploymentDiagram

浏览部署图

BrowseParent

浏览父图

BrowsePreviousDiagram

浏览上一图形

ZoomIn

放大

ZoomOut

缩小

FitinWindow

设置显示比例，使图形放进窗口

UndoFitinWindow

撤销【FitinWindows】设置

在系统开发的分析阶段，用户对系统的使用方式直接决定了系统的设计方式与构建方式。所以从用户观点出发，对帮助分析人员理解用户需求，建立可用、有用的系统是十分关键的。从用户的观点出发对系统建立模型是用例模型要完成的任务，因此用例建模通常也称为需求建模。本章在全书知识体系中位置如图3.1所示。

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

1.系统边界（SystemBoundary）

系统边界指一个软件系统能够处理的整个问题空间的范围。一个软件系统不可能处理所有问题，开发人员必须得给系统定义问题空间的范围。哪些是这个软件可以处理的，哪些则是这个软件不能处理的，也就是项目管理中所说的项目范围。

在UML中，系统边界用方框表示，或者省略不做表示。

2.参与者（Actor）

从参与者在系统中的地位来看，可以将其分成两类，即主要参与者（PrimaryActor）和次要参与者（SecondaryActor）。主要参与者指的是执行系统主要功能的参与者，例如在“图书管理系统”中主要参与者是进行借阅管理的图书管理员；次要参与者指的是使用系统次要功能的参与者，次要功能一般指系统维护功能（如管理数据库、备份和通信等），例如在“图书管理系统”中，能够检索该系统中一些基本统计数据的系统管理员属于次要参与者。将参与者分类的主要目的是，保证把系统所有功能表示出来，而主要功能是系统最关心的部分。

从参与者对用例的作用来看，可以将其分为主动参与者和被动参与者。主动参与者可以初始化用例、启动用例；而被动参与者则不能，它需要使用用例结果或为用例执行提供数据，被动参与者仅仅参与一个或多个用例，在某个时刻与用例通信。

在UML中，参与者表示为一个小人的图形（StickMan符号），在小人图形的下方书写参与者的名字，如图3.3所示；也可以用类符号（类的具体内容详见第4章）来表示参与者，如图3.4所示。

3.识别参与者

怎样确定系统的参与者呢？开发人员可以从如下几个方面来考虑。

从交互识别：

（1）谁使用系统的主要功能？

（2）谁改变系统的数据？

（3）谁从系统获得信息

（4）谁需要系统的支持以完成日常工作任务？

（5）谁（或什么）对系统运行产生的结果感兴趣？

从维护、管理识别：

（6）谁负责维护、管理并保持系统正常运行？

从设备或外部条件识别：

（7）系统需要应付（处理）哪些硬件设备？

（8）系统需要和哪些外部系统交互？

例如，在“基于Web的零件销售系统”中，顾客可以通过Internet进行购买。要求顾客先预付一定金额存入内部账户中成为会员，然后才能购买零件。顾客可以根据自己所知道的零件的形状、大小、零件编号等指标，搜索出所需要的零件。结账使用内部账户支付。系统根据会员提供的送货地址和订购数量，从库存中搜索出离送货地址最近的供应商，通知供应商发货。另外，内部工作人员不定期地根据供应商方面的价格变动，对某些零件的销售价格进行更新。每个星期，各个供应商会把记录自己最新库存情况的Excel文件寄来，系统根据这些文件更新库存信息。因简化的需要，以下因素略去不考虑：折扣，延迟交货……

以该系统为例，针对前述问题进行回答便可以确定系统的参与者。

（1）潜在会员，会员使用系统的主要功能。

（2）会员，货管员，经理改变系统的数据。

（3）潜在会员，会员，经理，货管员从系统获得信息。

（4）经理，货管员需要系统的支持以完成日常工作任务。

（5）会员，经理对系统运行产生的结果感兴趣。

（6）系统管理员负责维护、管理并保持系统正常运行。

（7）系统无需应付（处理）特殊硬件设备。

（8）系统可能与供应商的系统交互。

综上回答，确定出“基于Web的零件销售系统”的参与者有：潜在会员、会员、经理、货管员、系统管理员、供应商系统。

需要注意的是，在识别参与者时，不能将参与者的名字表示成参与者的某个实例，比如“张三”是“基于Web的零件销售系统”中的会员，但“张三”作为参与者的实例不能作为参与者的名字；也不能将参与者表示成参与者所需完成的功能，比如“售货”就是所需完成的功能，同样不能作为参与者的名字。

能够识别“图书管理系统”中的参与者，并且在RationalRose中绘制图示。

1.识别“图书管理系统”中的参与者。

2.在RationalRose中绘制“图书管理系统”的参与者。

1.识别“图书管理系统”中的参与者

遵循前面叙述的识别参与者的方法，暂时可以分析出“图书管理系统”中的参与者有：Administrator（系统管理员），Librarian（图书管理员），Reader（读者）。

Administrator（系统管理员）：通过使用系统进行用户管理。

Librarian（图书管理员）：通过使用系统进行读者管理、图书管理、借阅管理等。

Reader（读者）：通过使用系统进行读者信息查询、预订图书、取消预订等。

2.在RationalRose中绘制“图书管理系统”的参与者

（1）创建和保存工程

启动RationalRose后，在菜单栏中选择【File】->【New】菜单项，可以创建一个模型，选择【File】->【Save】或【SaveAs】可以保存工程为“Library”，如图3.5所示。

（2）创建用例图

在RationalRose左侧视图区域树型列表中选择【UseCaseView】，点击鼠标右键在弹出的快捷菜单中选择【New】->【UseCaseDiagram】，新建一个用例图，如图3.6所示。

新建用例图默认名称为“NewDiagram”，可以更改其名称，更改方法是选择“NewDiagram”点击鼠标右键选择【Rename】，然后输入用例图的新名称即可，如图3.7所示，在此可将用例图名称改为“LibraryUseCase”。双击该用例图，在RationalRose窗口内右侧空白处出现相应的编辑区，在编辑区中可进行后续操作。

（3）新建参与者

在编辑区工具栏中单击“StickMan”符号，也就是“Actor”，如图3.8所示，然后将鼠标停放在编辑区任意位置，鼠标会变成十字形状，在需要的位置再次单击鼠标即可在编辑区中绘制出参与者的图示。新建的参与者默认名称为“NewClass”，可将其名称根据具体情况进行修改。简便的修改方法是直接在“NewClass”处键入参与者的新名称；稍复杂的修改方法是双击该参与者打开“参与者属性”对话框，或者右键单击该参与者，在弹出的快捷菜单中选择【OpenSpecification】也可以打开“参与者属性”对话框，如图3.9所示，在此进行参与者名称的修改，同时还可以进行其他方面更为详细的设置。

按照以上方法，可以绘制出“图书管理系统”中的全部参与者：Administrator（系统管理员），Librarian（图书管理员），Reader（读者），如图3.10所示。

1.什么是系统边界？

2.什么是参与者？如何用图示描述参与者？

3.识别参与者应遵循怎样的步骤？

4.在UML中，参与者可以是（）。

5.参考以上“图书管理系统”，捕获“短信平台系统”中的参与者，并使用RationalRose工具实现。需求描述如下：

用户如果预定了天气预报，系统每天定时给用户发送天气信息；如果当天气温高于34摄氏度，系统还要提醒用户注意防暑。在这段叙述中，谁是“短信平台系统”的参与者？

1.自定义绘图工具栏

绘图工具栏中给出了常用的绘图工具，如果用户有更丰富的需求，可根据实际情况自定义该工具栏。方法是右键单击绘图工具栏的任意位置，在弹出的快捷菜单中选择【Customize】，如图3.11所示。

然后在弹出的“自定义工具栏”对话框中“可用工具栏按钮”栏，选取需要添加的工具，单击“添加”按钮，确认无误后关闭该对话框即可，如图3.12所示。

2.绘制多个参与者的快捷方法

3.删除用例模型中的参与者

使用RationalRose绘制系统用例模型的参与者时，由于操作不当或需求发生变化可能需要删除已绘制出的参与者图示，删除方法有如下几种。

（1）在编辑区中选择待删除的参与者，然后选择菜单【Edit】->【DeletefromModel】即可删除指定参与者，如图3.14所示。另外，在编辑区中选择待删除的参与者后，直接按“Ctrl+D”组合键也可直接删除指定参与者。

（2）在左侧浏览器窗口的树型结构中选择待删除对象，单击鼠标右键，在弹出的快捷菜单中选择【Delete】，即可删除指定参与者，如图3.15所示。另外，在浏览器窗口的树型结构中选择待删除对象后，直接按“Delete”键也可直接删除指定参与者。

（3）在编辑区中选择待删除的参与者，单击鼠标右键，在弹出的快捷菜单中选择【Edit】->【Delete】，可以将指定参与者从编辑区中删除，但该参与者在用例模型中仍然存在，即在浏览器窗口树型结构中该参与者仍然显示，如图3.16所示。另外，在编辑区中选择待删除的参与者后，直接按“Delete”键也可达到相同效果。

1.用例（UseCase）

用例是系统执行的一系列动作，这些动作生成特定参与者可观测的、有价值的结果值。一个用例定义一组用例实例。

用例是参与者要求系统提供的服务，是参与者使用系统期望达到的目标.，是从用户角度描述的系统行为。通俗地说，用例侧重于目标，而不是内部处理。用例没有表示任何关于系统内部的东西，只是表示系统将达到什么样的目标及由哪些参与者操作、负责。

用例具有以下特征：

（1）每个用例都有相应的信息输入，而输入信息一般由参与者提供；

（2）每个用例都有相应的信息输出，而输出信息一般被参与者接收；

（3）每个用例都是对一项系统功能的完整表述，对应具体的用户目标。

在UML中，用例被表示为一个椭圆图形，该椭圆的底部或内部书写用例名称，如图3.17所示。

2.识别用例

怎样确定系统的用例呢？识别用例最好的方法是从参与者着手，考虑每个参与者是怎样使用系统的。应用这种策略可能还会找出一些新的参与者，这对完善整个系统用例模型大有益处。用例建模的过程就是反复迭代和逐步精化的过程。在此过程中，通过回答如下几个问题可以帮助识别用例。

（1）参与者要为系统提供哪些功能和信息？

（2）参与者需要系统提供哪些功能和信息？

（3）系统在哪些方面存在问题，在哪些方面亟待完善？

进而，确定用例的一般步骤为：

（1）确定哪些参与者为系统提供输入信息；

（2）确定哪些参与者需要从系统获取输出信息；

（3）确定输入信息与输出信息之间的映射关系，即用例。

例如，在“仓库管理系统”中，通过与系统用户沟通，分析人员可以识别出系统主要参与者有：操作员、管理员、供应商、商品领料人、商品退料人。针对以上参与者，识别出系统用例有：仓库进货、仓库退货、仓库领料、仓库退料、商品调拨、仓库盘点、库存查询、业务分析、仓库历史记录查询、供应商信息维护、仓库信息维护、用户管理等。

3.用例阐述文档

用例阐述文档是针对每个用例，描述该用例各个场景（Scenario）的文档。所谓场景是指参与者和系统之间的一系列特定的活动和交互。每个用例是一组场景的集合，而每个场景又是一组步骤序列的集合。具体应用时，可采用如下用例阐述的模板。

------------------------------------------------------------------------------------------------------------

用例编号：

用例名称：

涉及的参与者：

用例概述：

前置条件：

后置条件：

基本事件流：

1.……XXXXX

2.……XXXXX

备选流：

1a.……XXXXX

1a1.……XXXXX

1a2.……XXXXX

2a.……XXXXX

2a1.……XXXXX

2a2.……XXXXX

补充说明：

其中前置条件约束在用例开始前系统的状态，后置条件约束用例执行后系统的状态。

Scenario-1：顺利地借到书

Scenario-2：该种书刊不存在

Scenario-3：物理书刊都已借出

Scenario-4：没有该读者信息

为描述该用例的各个场景，可采用如下用例阐述文档加以说明。

用例编号：001

用例名称：BorrowBook

涉及的参与者：Librarian（图书管理员）

用例概述：读者凭读者证借阅图书

后置条件（Postconditions）：如果读者借阅成功，则该读者可借阅书刊数量减少，馆藏减少；如果读者借阅失败，该读者可借阅书刊数量不变。

基本事件流（FlowofEvents）：

1.读者进入图书馆

2.读者查找图书

3.读者将读者证提交给图书管理员，并提交借阅图书请求

4.图书管理员检查读者可借阅书刊数量和馆藏数量，如果满足条件则借出图书

5.图书借给读者，读者可借阅书刊数量减少，馆藏减少

6.系统显示读者当前的借阅信息

1a.没有该借阅者信息：

1a1.系统提示借阅者信息不存在

2a.查询图书信息不存在：

2a1系统提示该图书不存在

3a.物理书刊均已借出

3a1.系统提示无馆藏

无

能够识别“图书管理系统”中的用例，并在RationalRose中绘制图示。

1.识别“图书管理系统”的用例。

2.在RationalRose中绘制“图书管理系统”的用例。

1.识别“图书管理系统”的用例

针对3.1.4中分析出的系统主要参与者（系统管理员、图书管理员、读者），可以分析出“图书管理系统”中主要用例包括：ManageUser（用户管理）、ManageBook（图书管理）、ManageReader（读者管理）、Borrow-Lend（借阅管理）等，详细说明如下。

ManageUser（用户管理）：完成系统用户的增加、删除、修改、查询等功能。

ManageBook（图书管理）：完成基本信息设置（图书类型设置、借阅种类设置）和图书信息管理（图书信息设置、图书信息查询）功能。

ManageReader（读者管理）：完成读者办证、读者信息查询、读者证挂失功能。

Borrow-Lend（借阅管理）：完成借书、还书、续借、超期罚款、图书预订、取消预订、图书挂失等功能。

2.在RationalRose中绘制“图书管理系统”的用例

（1）打开工程和用例图

启动RationalRose后，在菜单栏中选择【File】->【Open】菜单项，可以打开已有工程“Library”，然后在左侧浏览器窗口中单击【UseCaseView】前面的【】符号，展开树型结构，此时已经创建过的“LibraryUseCase”用例图便可显示出来，双击“LibraryUseCase”打开该用例图的编辑区即可创建用例。

（2）创建用例

在编辑区工具栏中单击用例符号【】即“UseCase”，然后将鼠标停放在编辑区任意位置，鼠标会变成十字形状，在需要的位置再次单击鼠标即可在编辑区中绘制出用例的图示。新建的用例默认名称为“NewUseCase”，可将其名称根据具体情况进行修改。

表3.1“图书管理系统”中的用例

编号

参与者

用例名称

用例说明

Administrator

（系统管理员）

AddUser

增加系统用户

DeleteUser

删除系统用户

UpdateUser

修改系统用户

QueryUser

查询系统用户

Librarian

（图书管理员）

SetBookType

进行图书类型设置

SetBorrowType

进行借阅种类设置

SetBookInfo

进行图书信息设置

SetReaderCard

为读者办证

QueryBookInfo

根据需要进行图书信息查询

QueryReaderInfo

进行读者信息查询

BorrowBook

处理读者的借书请求

ReturnBook

处理读者的还书请求

RenewBook

处理读者的续借图书请求

Fine

收取读者的超期罚款

ReserveBook

处理读者的图书预定请求

CancelReservation

处理读者的取消预订请求

LoseBook

处理图书挂失

LoseReaderCard

处理读者证挂失

Reader

（读者）

申请预订图书

取消图书预订

申请续借图书

简便的修改方法是直接在“NewUseCase”处键入用例的新名称；稍复杂的修改方法是双击该用例打开“用例属性”对话框，或者右键单击该用例，在弹出的快捷菜单中选择【OpenSpecification】也可以打开“用例属性”对话框，在此进行用例名称的修改，同时还可以进行其他方面更为详细的设置。

1.什么是用例图？用例图的构成要素有哪些？

2.建立用例图应遵循怎样的步骤？

3.如图3.21所示为“超市系统”设计的用例图，该系统的参与者有：()。

A.Clerk,Manager

B.Clerk,Manager,Customer

C.Clerk,Manager,Banknetwork

D.Clerk,Manager,Banknetwork,Customer

4.下列关于使用用例的目的，不正确的说法是：()。

A.确定系统应该具备哪些功能

B.为系统的功能提供清晰一致的描述，方便开发人员传递系统的需求

C.为系统验证工作奠定基础

D.能够减少程序员的编码工作量，从而提高开发效率

用例

手机用户

呼叫某人

发送短消息

7.借助RationalRose工具，绘制“航班售票系统”的参与者和用例。参与者为旅客（Passenger），用例为订票（Order）和查看今日航班（SearchTodayFlight）。

1.谁来写用例阐述文档

最完美的情况：业务人员接受训练，写出优美的用例文档。

最现实的情况：业务人员提供素材，开发人员写用例文档。

最糟糕的情况：业务人员不管，完全由开发人员杜撰。

2.用例的粒度

简单地说，用例的粒度就是用例规模的大小；严格地说，用例的粒度表示一个用例可以描述一项完整的业务流程或一项完整的系统功能。怎样确定一个用例的粒度是否合适，是以这个用例是否完成了参与者的某个目的为依据的。

在一次技术研讨会上，有人问起IvarJacoboson博士，一个系统需要多少个用例？IvarJacoboson博士的回答是20个，当然他的意思是最好将用例模型的规模控制在几十个用例左右，这样比较容易来管理用例模型的复杂度。在用例个数大致确定的条件下，我们就很容易来确定用例粒度的大小。

对于较复杂的系统，我们需要控制用例模型这一级别的复杂度。所以可以将复杂度适当地移往每一个用例的内部，也就是让一个用例包含比较多的需求信息量，从而减少用例个数增大用例的粒度，降低用例模型的复杂度。

对于比较简单的系统，我们则可以将复杂度适当地曝露在模型这一级别，也就是我们可以将较复杂的用例分解成为多个简单的用例，从而增大用例的个数减小用例的粒度，加强用力模型的饱满度。

用例的粒度不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。我们应该根据每个系统的具体情况，来把握各个层次的复杂度，在尽可能保证整个用例模型易理解的前提下来决定用例的大小和数目。

例如，在“图书管理系统”读者借阅书刊的场景中，读者首先出示了读者证，图书管理员查询了该读者以前的借阅记录，确保没有到期未归还的书刊，然后又查询了读者欲借阅的书刊确保有馆藏，最后读者借阅成功。从这个例子中能分析出多少用例呢？注意，用例分析是以参与者为中心的，因此用例的粒度是以能完成参与者目的为依据。因此，实际上合适的用例是：借书。只有这一个用例即可，其它描述都只是完成这个目的过程。

3.识别用例的注意事项

（1）用例应该终止于系统边界，超出系统问题空间的功能不必放入该系统用例模型中。

例如，在“零件销售管理系统”中，出纳员作为其中的参与者可能为系统提供相应功能或者希望系统为其提供相应功能，但吃饭和睡觉这两项功能与销售管理本身并没有密切联系，也就是说图3.22中“Eat”和“Sleep”脱离了系统问题空间，超出了系统边界，所以这两项功能不应作为系统用例出现。在具体分析时，应避免此种情况发生。

（2）用例的结果值应该由系统生成，从而使得用例是有意义的目标。

（3）用例分析应从用户角度出发，使用业务语言描述；而非从开发人员角度出发，使用技术语言描述。

例如，在“航班售票系统”中，从用户角度描述的功能为“订票”和“查看今日航班”，而从开发人员角度描述的系统功能为“处理订票”和“显示今日航班”。

又如，在“手机系统”中，分别从用户角度和开发人员角度描述的系统功能如表3.3所示，在具体识别用例时应着重考虑用户角度。

表3.3用户角度与开发人员角度的不同描述

用户角度

开发人员角度

传输/接收

电源/基站

输入输出（显示器，键盘）

……

1.泛化（Generalization）关系

在面向对象程序设计中存在继承的概念，继承是指一种由已有类创建新类的机制。利用继承，可以先创建聚集共有属性和行为的一般类，根据该一般类再创建具有特殊属性和行为的新类，新类继承一般类的属性和行为，并根据需要增加自己新的属性和行为。由继承而得到的类称为子类，被继承的类称为父类。与此相似的是，用例模型中参与者和参与者之间、用例和用例之间也有可能存在这种一般和特殊的关系；与此不同的是，在分析领域而非设计、实现领域，我们通常用泛化来表示此种关系。也就是说，如果一个参与者是另一个参与者的特例，一个用例是另一个用例的特例，它们之间就可以表示为泛化关系。实际上，泛化是一种抽象化，继承则是一种具体化。

在UML用例模型中，泛化关系被表示为一条带有空心箭头的实线，其方向指向父参与者或父用例。如图3.25所示为参与者之间的泛化关系，如图3.26所示为用例之间的泛化关系。

2.关联（Association）关系

在用例模型中关联关系通常用来反应参与者和用例之间的相互作用，表示参与者使用用例的功能或参与者接受用例提供的数据。

在UML中，关联关系用实型直线表示，该实型直线可以有导航方向（即画出箭头），也可以忽略导航方向（即不画出箭头）。通常，参与者与用例之间的关联关系无需特别强调导航，但部分UML书籍中也定义了这种导航，其大致内容是：如果参与者要使用用例，则箭头从参与者指向用例；如果参与者要接受用例提供的数据或查询结果，则箭头从用例指向参与者。

如图3.27所示为定义了导航方向的关联关系，而图3.28所示为忽略导航方向的关联关系，两个图示都可以表示“自动提款机系统”中BankCustomer（银行客户）、Server（后台服务器）两个参与者和Query（查询）、GetCash（提款）、Transefer（转账）三个用例之间的关联关系。本章后续内容中没有过多考虑导航方向的问题。

3.包含（Inclusion）关系

虽然每个用例大都是独立的，但是一个用例也可以包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。如果一个用例包含另一个用例的行为，则称这两个用例之间存在包含关系，被包含的用例可以是事先定义好的，也可以是在各种环境下使用的公共行为。

值得注意的是，不要乱用包含关系，错把用例步骤（即用例阐述文档中的事件流）当作被包含的用例。如图3.30就是一个误用包含关系的实例，该例中错将会员注册的步骤（填写注册信息、生成会员ID和密码、保存注册信息）当作注册用例的包含用例来使用，实际问题中应尽量避免。

4.扩展关系（Extension）

用例模型中允许为已有用例创建新用例，新用例作为已有用例的增量扩展，以此强化已有用例的行为，等于在不改变已有用例的情况下，给系统添加新的行为。其中已有用例通常称为基本用例（BaseUseCase），新用例通常称为扩展用例（ExtensionUseCase）。基本用例与扩展用例之间的关系称作扩展关系。

扩展的目的在于：

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

（2）表明只有在特定条件下（通常是在异常情况下）才执行的行为，如触发警报等。也就是说，基本用例自身应该是完整的，即基本用例应该是可理解并且是有意义的，而不必引用任何扩展用例；扩展用例是否执行取决于在执行基本用例时所发生的事件。

如前所述，扩展用例的执行是有条件的，这个条件称作扩展点（ExtensionPoint），该扩展点可以用注释在用例中进行标注，也可以在用例描述中加以说明。通过在基本用例中引用扩展点，可以定义在基本用例的哪些位置插入扩展用例。

在UML中，扩展关系使用虚线箭头表示，其上添加<>字样，箭头指向基本用例。例如，在“图书管理系统”中，如果按期还书不会出现异常情况即不会有其他用例产生，而超期还书就会出现异常情况即产生用例——罚款，如图3.31所示。其中ReturnBook为基本用例，Fine为扩展用例，OverdueBook为扩展点。由于在此图中加入了扩展关系，所以Librarian和Fine之间的关联关系也可以省略。

有些时候，人们对扩展关系和包含关系会产生混淆，其实扩展关系和包含关系的主要区别在于：扩展关系中，基本用例不必知道扩展用例的任何细节，事实上基本用例没有扩展用例也是完整的，只有特定的条件发生了，扩展用例的行为才被执行；而在包含关系中，被包含用例却是必不可少的，如在图3.29中没有LoginSystem用例作为前提，InputScore用例和QueryScore用例的功能则根本不能完成。

能够识别“图书管理系统”用例模型中的关系，并在RationalRose中绘制图示。

1.识别“图书管理系统”用例模型中的关系。

2.在RationalRose中绘制“图书管理系统”用例模型中的关系。

1.识别“图书管理系统”用例模型中的关系

2.在RationalRose中绘制“图书管理系统”用例模型中的关系

按照3.2.4中的方法，打开“Library”工程和“LibraryUseCase”用例图。

（2）创建用例模型中的关系

在编辑区工具栏中单击关联关系符号【】即“Association”，然后将鼠标停放在编辑区任意位置，鼠标会变成箭头形状，箭头方向向上，此时采用按住鼠标左键拖拽的方式将参与者和用例连接起来便可。

继续在编辑区工具栏中单击依赖关系符号【】即“Dependencyorinstantiates”，采用按住鼠标左键拖拽的方式，分别将ReserveBook（预订图书）用例、CancelReservation（取消预订）用例、QueryBookInfo（查询图书）用例、QueryReaderInfo（查询读者）用例、RenewBook（续借图书）用例和Login（注册）用例连接起来，注意箭头应该指向被包含的用例Login（注册）。然后双击在图中出现的依赖关系，打开如图3.32所示的对话框，在该对话框中“Stereotype”对应的下拉列表里选择“include”，便可完成包含关系的绘制。

最后在编辑区工具栏中单击依赖关系符号【】即“Dependencyorinstantiates”，采用按住鼠标左键拖拽的方式，将ReturnBook（还书）用例和Fine（罚款）用例连接起来，注意箭头应指向基本用例ReturnBook（还书）。接下来双击两个用例之间的依赖关系，在图3.32所示的对话框中“Stereotype”对应的下拉列表里选择“extend”，便可完成扩展关系的绘制。

按照以上方法，绘制出“图书管理系统”用例模型中的关系，如图3.33所示，此图也就是本系统的用例图。

1.用例之间有不同的关系，下列哪个不是它们之间可能的关系（）。

A.泛化（Generalization）B.扩展（Extension）

C.包含（Inclusion）D.聚合（Aggregation）

A.包含B.扩展

C.分类（Classification）D.泛化

3.用例从用户角度描述系统的行为。用例之间可以存在一定的关系。假设在“图书管理系统”用例模型中，所有用户使用系统之前必须通过“身份验证”，“身份验证”可以有“密码验证”和“智能卡验证”两种方式，则“身份验证”与“密码验证”和“智能卡验证”之间是（）关系。

A.关联B.包含C.扩展D.泛化

（3）修改个人信息：客户向系统注册后，可以发送电子邮件或者使用系统提供的页面，对个人信息进行修改。

（4）删除客户信息：只有公司管理人员才能够删除不再接受公司服务的客户的信息。

在需求分析阶段，采用用例图描述系统功能需求，如下图3.34所示，请指出图中的A，B，C和D分别是哪个用例？

6.根据以下“汽车租赁系统”的需求描述，借助RationalRose工具绘制系统用例图。

7.在线售票订位系统中，客户（一般客户/企业客户）可以建立在线订位销售事件、事件确认、执行在线信用卡付费、个人或团体账户修改和管理；系统操作者可以建立在线销售定位事件、查询目前销售订位状况；系统设计维护者可以建立在线售票定位事件、查询目前销售定位情况、在线系统维护功能和系统环境设置。

根据以上描述，请分析出该系统的参与者和用例，并利用RationalRose工具绘制出需求用例模型。

8.根据下面的陈述，分析出系统参与者和用例，并利用RationalRose绘制用例图。

在医生的办公室里接待员、护士和医生使用病人记录和计划安排系统。当病人第一次来这里看病时，接待员使用该系统来输入病人信息，并且安排所有的预约。护士使用系统来跟踪病人每次看病的结果并输入护理病人的信息，如医疗和诊断。护士也可以访问这些信息以打印病人诊断结果或病人看病历史。医生主要用这个系统来查看病人的病史，偶尔也输入病人的医疗信息，但通常医生让护士输入这些信息。

9.通过回答下列提示问题，获取ATM自动取款系统中的参与者、用例、关系，并利用RationalRose工具绘制ATM系统的用例图。

（1）谁使用ATM系统的取款功能？

（2）谁使用ATM系统的支持以完成日常工作任务？

（3）谁对ATM系统的运行结果感兴趣？

（4）谁来维护、管理并保持ATM系统的正常运行？

（5）ATM系统需要和哪些系统进行交互？

（6）ATM系统需要处理哪些设备？

10.根据下面图3.35所示的结账系统用例图，描述出其中涉及到的参与者、用例以及相互关系。

1.用例图的层次

以“图书管理系统”为例，为了让层次更加清晰，可以先绘制顶层用例图，如图3.36所示。

然后在顶层用例图的基础上绘制子用例图，比如在图3.36中双击“Borrow-Lend”用例，或右键单击该用例并在弹出的快捷菜单中选择【OpenSpecification】，打开“用例属性”对话框，继而选择其中的【Diagrams】选项卡，右键单击中间的空白区域并在弹出的快捷菜单中选择【InsertUseCaseDiagram】，便可插入“Borrow-Lend”用例的子图，同时可将子用例图的默认名称“NewDiagram”修改为“Borrow-LendSubDiagram”，如图3.37所示。

双击“Borrow-LendSubDiagram”子用例图，进入用例图的绘制界面，参照前面用例图的绘制步骤，完成Administrator（图书管理员）“Borrow-LendSubDiagram”子用例图，如图3.38所示。

类似地，完成Librarian（图书管理员）“ManageReader”子用例图，如图3.39所示；完成Administrator（图书管理员）“ManageUser”子用例图，如图3.40所示；完成Reader（读者）“Borrow-Lend”子用例图，如图3.41所示。

2用例图工具栏

用例图工具栏上的按钮名称及功能，详见表3.4。

表3.4用例图工具栏按钮

按钮名称

说明

SelectionTool

选择工具

TextBox

文本框

Note

注释

AnchorNotetoItem

将图中的元素与注释连接

Package

包

Actor

UseCase

UnidirectionalAssociation

单向关联关系

Dependencyorinstantiates

依赖关系或实例化（包含和扩展关系）

Generalization

泛化关系

Association

关联关系

3.绘图中的错误提示

以绘制关联关系即使用【】为例，如果在操作过程中出现如图3.42所示的错误提示对话框，则说明操作有误。该错误提示的含义为：为非法关联，关联关系只能用来连接类（用例图中的参与者可以看作类）或用例。出现这个错误是因为，在绘制参与者和用例间的关联关系时，关系的起始端和终止端不是参与者和用例，或者是因为在绘制关系时起始点和终止点位置选择则不够准确。

以添加注释即使用【】为例，如果在操作过程中出现如图3.43所示的错误提示对话框，则同样说明操作有误。该错误提示的含义为：为非法注释，必须与注释连接。出现这个错误是因为，在添加注释时，连线的的起始端或终止端不是注释，或者是因为注释的起始点和终止点位置选择则不够准确。

以添加依赖关系即使用【】为例，如果在操作过程中出现如图3.44所示的错误提示对话框，则同样说明操作有误。该错误提示的含义为：非法的依赖关系，对象流或实例化。出现这个错误是因为，在绘制用例间的扩展关系或包含关系时，关系的起始端和终止端不是用例，或者是因为在绘制关系时起始点和终止点位置选择不够准确。

静态模型是UML的基础，它用于显示系统的静态结构，特别是系统中事物（例如类、对象、包等）的内部结构以及相互关系。类图、对象图和包图都属于静态模型。类图主要描述系统中类的内部结构（属性和操作）及类之间的关系。对象图是类图的实例，主要描述类图的多个对象实例及相互关系。包图用于显示系统的分层结构，主要描述包的构成及包之间的相互关系。静态模型中以类图的使用最为广泛，所以本章主要介绍类图，稍加说明对象图和包图的部分内容。本章在全书知识体系中的位置如图4.1所示。

1.类（Class）

类是面向对象系统中最为重要的概念。在UML中，类是描述事物结构特性和行为特性的模型元素。类是对众多UML元素的泛化，这些元素包括常规的类、接口、用例和参与者；反过来说，可以认为这些元素是类的特例。在类图中，最常用的两个元素是常规的类和接口。

类在UML中被表示为一个矩形，该矩形被分隔成上、中、下三部分，如图4.2所示和图4.3所示。其中上部描述类的名字，中部描述类的属性，下部描述类的操作（也称类的方法），具体说明如下。

（1）名称（Name）

类映射为真实世界中的对象或结构，类的名称就是根据它们所代表的真实世界中的对象和结构来定义的。类的名称是一个字符串，是每个类必有的构成元素，用于和其它类相互区分。类的名称应该来自系统的问题空间，并且尽可能的明确。一般情况下，类的名字是一个名词，如“图书”、“Animal”、“Dog”等。

类的名称可分为简单名称（SingleName）和路径名称（PathName）。单独的名称叫做简单名称，如图4.4所示。用类所在的包名作为前缀的类名叫做路径名称，如图4.5所示，其中Package为NewClass所在的包的名称，NewClass为类名。

（2）属性（Attribute）

属性用于描述同类对象的内部特征。同类对象的内部特征可能需要多个属性进行描述，构成属性集合。例如对“学生”来建模，每个学生都有学号、姓名、专业、籍贯、出生日期等，这些都可以作为学生类的属性。

在UML中类属性的一般语法格式为：

[可见性]属性名称[：属性的类型][=初始值][{属性字符串}]

需要注意的是，在描述属性时属性名是一定要有的，其他部分可根据需要进行选择。

其中可见性用于控制外部事物对类中属性的操作方式，常用的可见性有三种，即公有的（public）、受保护的（protected）、私有的（private）。通常使用加号（+）表示公有的（public），井号（#）表示受保护的（protected），减号（-）表示私有的（private）。而在RationalRose中，采用图形符号表示可见性，具体含义见表4.1所示。如果没有标识可见性修饰符，则表示该属性的可见性尚未定义。

表4.1RationalRose的属性可见性

可见范围

UML符号

Rose符号

公有的（public）

类内部和外部

受保护的（protected）

类内部

能被其子类使用

私有的（private）

不能被其子类使用

其中属性名称用于区别类中其他属性，通常情况下，属性名称由描述类特征的名词或名词短语组成。按照UML的约定，如果属性名称为单个英文单词，宜采用小写形式，如“name”；如果属性名称包含多个英文单词，这些单词要合并，并且除第一个单词外其余单词的首字母要大写，如“bookName”。

其中属性的类型用来说明该属性是什么数据类型，它可以是基本数据类型（如整型、单精度浮点型、布尔型等），也可以是其他数据类型（如类的类型）。

其中初始值是指属性最初获得的赋值。设置初始值有两个作用：一是保护系统的完整性，防止属性未被赋值而破坏系统完整性的情况出现；二是为用户操作提供方便，一旦指定了属性的初始值，当创建该类对象时，该对象的属性值便自动被赋予了设定的初始值，从而简化了用户操作。

（3）操作（Operation）

操作是对象与其外部进行信息交换的唯一途径，同类对象的外部特征可能需要多个事件进行描述，构成事件集合。操作定义的基本原则是：操作集合必须定义在属性集合之上，操作集合中各个操作至少用于属性集合中的一个属性；也就是说，操作的定义至少要涉及一个属性，否则就不是这个类的操作。

在UML中类操作的一般语法格式为：

[可见性]方法名[（参数表）][：返回类型][{属性字符串}]

其中可见性与类属性的可见性相似。

其中方法名是用来描述类行为的动词或动词短语。命名方法与类属性命名方法相似。

其中参数表是一些按顺序排列的属性，这些属性定义了方法的输入。参数表是可选的，即方法不一定必须有参数。如果要定义参数，则可以采用“名称：类型”的方式。存在多个参数时，可将各个参数用逗号隔开，参数也可以有默认值。

其中属性字符串可以为方法加入一些预定义元素之外的信息。

如图4.6所示Shape类的所有方法可见性均为公有的（public），其中move方法有两个参数argname和argname2，argname参数类型为Boolean布尔型，argname2参数类型为Date日期型，该方法返回值类型为int型。

在面向对象软件工程中，将类划分为以下三种类型。

（1）实体类（EntityClass）

实体类（EntityClass）表示系统问题空间内的实体。在软件系统中，实体具有永久性的特点，并且可以持久地存储在数据库中。这里的实体类与数据库中的表对应；类的实例对应于表中的一条记录；类的属性对应记录的字段。在UML建模时，通常使用实体类保存那些要永久存储的信息，如“教务管理系统”中的学生类、课程类等。

具体应用时，实体类通常被表示为如图4.7所示的形式。

（2）边界类（BoundaryClass）

边界类（BoundaryClass）用于处理系统内部与外部之间的通信，为系统的参与者或其他系统提供接口。边界类位于系统边界处，即系统内部与外部的交接处。边界类包括窗体、报表以及其他系统的接口。每个参与者和用例交互至少要有一个边界类。如“教务管理系统”中选课时使用的学生选课窗体等。

具体应用时，边界类通常被表示为如图4.8所示的形式。

（3）控制类（ControlClass）

控制类（ControlClass）用于控制系统中对象间的交互。它负责协调其他类之间的工作，实现对其他对象的控制。通常情况下，每个用例都相应的有一个控制类，控制用例中的事件流。如：“教务管理系统”中学生选课时的课程判断等。

具体应用时，控制类通常被表示为如图4.9所示的形式。

在以往传统的C/S（Customer/Server）客户机/服务器模式中，实体类、边界类、控制类没有严格的一一对应关系。在当前流行的设计模式如MVC（Model-View-Controller，模型—视图—控制器）模式中，MVC分别对应实体类、边界类、控制类。

2.接口（Interface）

根据以往所学我们知道，通过操作系统的接口可以实现良好的人机交互和信息交流。在UML中也可以定义接口，利用接口来说明类能够支持的行为。在面向对象建模时，接口起着非常重要的作用，因为模型元素之间的相互协作都是通过接口实现的。一个结构良好的软件系统，其接口的定义也必然非常规范。

接口通常被描述为一组抽象操作，也就是这些操作只有标识（返回值、方法名、参数表）说明它的行为，而真正实现部分放在使用该接口的类中。这样，应用该接口的各个类就可以对接口采用不同的实现方法。

在UML中，接口被表示为一个圆形，在圆形的下方书写接口名称和抽象操作；接口还有其扩展形式，扩展形式中接口被表示为一个构造型类，如图4.10所示为接口的一般表示形式，图4.11所示为接口的扩展表示形式。在RationalRose中可以通过右键单击该接口，在弹出的快捷菜单中选择【Options】->【StereotypeDisplay】中各子菜单项，来完成接口各种表示形式的转换，如图4.12所示。

3.包（Package）

包是对模型元素进行分组的机制，它把模型元素划分成若个个子集。包可以拥有UML中的其他元素，如类、接口、用例等等，包甚至还可以包含其他包。包和类一样也具有可见性，利用可见性控制外部包对包中内容的存取方式，包的可见性分为三种。

（1）公有的（public）：表示此包内的模型元素可以被任何引入此包的其他包中的模型元素访问。公有访问的表示形式为：在该包的模型元素名字前添加加号（+）修饰符。

（2）受保护的（protected）：表示此包内的模型元素能够被该包在继承关系上的后代包中的模型元素访问。受保护访问的表示形式为：在该包的模型元素名字前添加井号（#）修饰符。

（3）私有的（private）：表示此包内的模型元素可以被属于同一包的其他模型元素访问。私有访问的表示形式为：在该包的模型元素名字前添加减号（-）修饰符。

在UML中，包被表示为类似文件夹的形状，内部书写包的名称，如图4.13所示为NewPackage包中包含了NewPackage2包。

4.协作（Collaboration）

协作是一组类、接口和其他模型元素构成的群体，它们共同工作，提供比各组成部分功能总和更强的合作行为，如图4.14所示内容即为协作。

能够识别“图书管理系统”中的类，并且在RationalRose中绘制图示。

1.识别“图书管理系统”中的类。

2.在RationalRose中绘制“图书管理系统”中的各个类。

1.识别“图书管理系统”中的类

怎样确定软件系统中的类呢？开发人员可以从如下几方面考虑。

（1）寻找名词

阅读系统文档和用例（尤其是用例事件流），找出名词或名词短语，分析这些名词的含义，因为这些名词并不都是类，可能有些只是属性。所以需要经过筛选，去除冗余的、与系统无关的、非独立的类。

（2）类—职责—协作方法

类—职责—协作方法，也称CRC（Class-Responsibility-Collaboration）方法。这是模拟开发人员“处理卡片”的一个过程。开发人员在执行一个处理实例（即一个用例）的同时，将类名赋予的职责和合作者填入卡片，以此来确定类。

（3）根据MVC模式寻找

根据用例图找出边界类；在用例中找出控制类；如果此时数据库已经设计完毕，则可以根据数据库中的表获得实体类。

需要注意的是，有些类无法通过以上方法找到，可能还需要从后面的动态模型（如时序图和协作图）中通过分析对象来确定。

接下来就以“图书管理系统”为例来进行类的识别。在“图书管理系统”的用例模型中已经知道，系统需要为每个读者建立一个账户，并给读者发放读者证（读者证可以提供读者证号、读者姓名），账户中存储读者的个人信息、借阅信息以及预订信息等，持有读者证的读者可以借阅书刊、返还书刊、查询书刊信息、预订书刊并取消预订。

在借阅书刊时，需要输入所借阅的书刊名、书刊的ISBN号，然后输入读者的读者证号和读者姓名，完成后提交所填表格，系统验证读者是否有效。若读者有效，借阅请求被接受，系统查询读者所借阅的书刊是否存在，若存在，则读者可借出书刊，系统记录借阅记录；如果读者所借书刊已被借出，读者还可预订该书刊。读者如期还书后，系统清除借阅记录，否则需缴纳罚金。

同时，以上部分操作还需要系统管理员和图书管理员进行参与。

结合以上分析，遵循前面叙述的识别类的方法，暂时可以识别出“图书管理系统”中的类有：Admin，Administrator，Librarian，Reader，ReaderType，Book，BookType，Borrow，BorrowType，Store，Reserve，Fine。详见表4.2所示。

表4.2“图书管理系统”中的类

类名称

类说明

Admin

抽象出来的管理员

进行系统管理的管理员

进行读者管理、图书管理、借阅管理的图书管理员

读者基本信息

ReaderType

读者类别信息

Book

图书基本信息

BookType

图书类别信息

Borrow

读者借阅图书信息

BorrowType

读者借阅类型信息

Store

图书在图书馆中的存放位置信息

Reserve

读者预订图书信息

读者罚款信息

为方便管理，可以将上述各类归入两个包中：BusinessPackage（业务包）和GUIPackage（图形用户接口包）。BusinessPackage包含表4.2中列举出来的类，GUIPackage包含用户接口类。

当然，如果采用页面形式表示用户接口，也可以把页面看成边界类。

2.在RationalRose中绘制“图书管理系统”中的各个类

（1）打开工程创建类图

启动RationalRose，在菜单栏中选择【File】->【Open】菜单项，打开在第3章中建立过的“Library”工程，然后在左侧浏览器窗口中单击“LogicalView”，点击鼠标右键【New】->【ClassDiagram】，新建一个类图，如图4.15所示。

新建类图默认名称为“NewDiagram”，可以更改其名称，更改方法是选择“NewDiagram”点击鼠标右键选择【Rename】，然后输入类图的新名称即可，在此可将类图名称改为“LibraryClass”。双击该类图，在RationalRose窗口内右侧空白处出现相应的编辑区，在编辑区中可进行后续操作。

（2）创建包

因为前面已经分析过，为方便管理，可以将各个类归入BusinessPackage和GUIPackage两个包中。所以，接下来就需要在RationalRose中创建这两个包。

在编辑区工具栏中单击【】符号，也就是“Package”，如图4.16所示，然后将鼠标停放在编辑区任意位置，鼠标会变成十字形状，在需要的位置再次单击鼠标即可在编辑区中绘制出包的图示。新建包的默认名称为“NewPackage”，可将其名称根据具体情况进行修改。简便的修改方法是直接在“NewPackage”处键入包的新名称；稍复杂的修改方法是双击该包打开“包属性”对话框，或者右键单击该包，在弹出的快捷菜单中选择【OpenSpecification】也可以打开“包属性”对话框，如图4.17所示，在此进行包名称的修改，同时还可以进行其他方面更为详细的设置。

按照以上方法，可以绘制出“图书管理系统”中的包：BusinessPackage（业务包）和GUIPackage（图形用户接口包），如图4.18所示。

（3）创建类

包被创建完以后，可以继续创建包中的各个类。具体方法是：首先双击包（如BusinessPackage包），进入该包的编辑区；然后在编辑区工具栏中单击【】符号，也就是“Class”，如图4.19所示，将鼠标停放在该包编辑区任意位置，鼠标会变成十字形状，在需要的位置再次单击鼠标即可在包编辑区中绘制出类的图示。新建类的默认名称为“NewClass”，可将其名称根据具体情况进行修改。简便的修改方法是直接在“NewClass”处键入类的新名称“Book”；稍复杂的修改方法是双击该参与者打开“类设置”对话框，或者右键单击该类，在弹出的快捷菜单中选择【OpenSpecification】也可以打开“类设置”对话框，如图4.20所示，在此修改类名称为“Book”，同时还可以进行其他方面更为详细的设置。

（4）编辑类

类名被确定以后，还可以为类添加相应的属性和操作。添加属性的方法和添加操作的方法类似，大致都有两种。

添加属性的方法之一是通过菜单直接添加。即右键单击要添加属性的类（如“Book”类）打开快捷菜单，选择【NewAttribute】菜单项，如图4.21所示；然后键入新的属性名称“bookID”替换掉默认属性名称“name”，如图4.22所示。如果想同时设置属性的类型、初始值，可以直接采用“属性名：类型=初始值”的键入方式。如果想进一步设置属性的可见性，则可以直接用鼠标单击属性名前面的可见性符号，在弹出的可见性选择项中重新设定以替换默认选项“private”。如图4.23所示将Book类的“bookID”属性设置为整型int，初始值设置为“0”，可见性设置为“public”。

添加属性的方法之二是通过“类设置”对话框间接添加。即首先在图4.20所示对话框中选择【Attributes】选项卡，如图4.24所示；然后右键单击中间空白区域，在弹出的快捷菜单中选择【Insert】菜单项，最后键入新的属性名称“bookName”替换默认属性名称“name”。同时，在此还可以双击属性，打开“类属性设置”对话框，进行更为详细的其他设置，例如设置属性的类型、初始值、可见性等等，详见图4.25所示。

添加操作的方法与添加属性的方法基本相同，只需要在图4.21所示的快捷菜单中选择【NewOperation】菜单项；或者在图4.24所示的“类设置”对话框中选择【Operations】选项卡而非【Attributes】选项卡，即可完成类操作的添加。类操作的详细设置可以在如图4.26所示的对话框中双击指定的操作如querybyAuthor，打开“类操作设置”对话框，如图4.27所示，在此可以进行操作名称、返回值、可见性等设置；继续单击该对话框的【Detail】选项卡，可以进行参数列表设置，如图4.28所示，在“Arguments”空白区域任意位置右键单击，在弹出的快捷菜单中选择【Insert】菜单项，此处设置querybyAuthor操作有一个参数名为authorName，参数类型为String字符串。

遵循以上步骤，绘制出BusinessPackage包中的所有类，如图4.29和图4.30所示。

以上BusinessPackage包中的各个类默认情况下都属于实体类，可以参照绘制实体类的方法绘制系统的边界类和控制类。接下来就以GUIPackage包中的边界类为例，说明其操作步骤：首先在“LibraryClass”类图中，双击GUIPackage包，进入该包的编辑区，在编辑区中添加“Login”类；然后打开如图4.20所示的“类设置”对话框，在对话框中选择【Stereotype】下拉列表框内的“boundary”选项，即可将“Login”类设置为边界类。如图4.31所示。

依次添加Main，SystemManage，ReaderManage，BookManage，BorrowManage，FineManage等边界类，如图4.32所示。

至此，“图书管理系统”两个包中的类就全部分析、绘制完成，具体层次结构如图4.33目录树所示。

1.下图4.34中类的名称是______________，类中的属性有______________，类中的操作有______________。

2.如果一个类的属性不能被其子类使用，则该属性的可见性为（）。

A.公有的（public）B.受保护的（protected）

C.私有的（private）D.默认的（default）

3.UML中的类被划分为三类，下面那个不是其中之一（）。

A.边界类B.实体类

C.控制类D.主类

4.在“类设置”对话框中，可以通过（）设置类属性的可见性。

A.TypeB.Stereotype

C.InitialD.ExportControl

5.在“类设置”对话框中，可以通过（）构造型（Stereotype）设置类为边界类。

A.abstractB.control

C.boundaryD.subclass

6.简述静态模型中类和用例模型中参与者之间的区别与联系。

7.请根据以下描述，给出系统的UML类设计方案。

系统名称：农夫果园游戏系统

人物角色：农夫（Farmer）、市场调查员（Inquirer）、农场主（Boss）

系统实物：各种果树（Fruit）、果园（Garden）

功能需求：

（1）农夫可以根据市场行情种植各种水果；

（2）市场调查员可以了解市场行情；

（3）农场主可以向农夫、市场调查员发布命令；

（4）各种果树都具有种植（plant）、成长（grow）、收获（harvest）行为；

（5）果园是人物和实物进行交易的经营场所。

在软件开发的不同阶段，类可以具有不同的抽象层次。一般地，类的抽象可分为三个层次，即概念层（Conceptual），说明层（Specification）和实现层（Implementation），如图4.35所示。

类的概念层、说明层和实现层的划分最先是由SteveCook和JohnDaniels引入的。

概念层（Conceptual）描述应用领域中的概念，一般地，这些概念和类有很自然的联系，但两者并没有直接的映射关系。

说明层（Specification）描述软件的接口部分，而不是软件的实现部分。

实现层（Implementation）才真正考虑类的实现问题，揭示实现细节。

UML类图中常常包含多个类，这些类并不是孤立存在的，它们之间存在着一定的逻辑关系，这些逻辑关系可以分为四种：泛化（Generalization）、依赖（Dependency）、实现（Realize）、关联（Association），其中关联又可以细化为聚集（Aggregation）和组合（Composition）。

在第3章用例模型中已经提到过泛化关系，通过前面的介绍可知，泛化表示一般元素和特殊元素之间的关系。在类图中，一般元素被称为超类或父类，特殊元素被称为子类。子类可以继承父类的属性和操作，并根据需要增加自己新的属性和操作。更简单地说，泛化关系描述了类之间的“isakindof”（是……的一种）关系。在Java语言中，extends关键字表示了这种关系的精髓。具体应用中，抽象类（没有具体对象的类）通常用作父类，具体类（拥有具体对象的类）通常用作子类。这样的例子很多，如“交通工具”为抽象类可以用作父类，“汽车”和“轮船”为具体类可以用作“交通工具”的子类。又如“图形”类是抽象类可以用作父类，“矩形”类、“圆形”类和“多边形”类是具体类可以用作“图形”类的子类。

在UML类图中，泛化关系被表示为一条带有空心箭头的实型直线，其方向指向父类，如图4.36所示。

2.依赖（Dependency）关系

如果一个元素A的变化影响到另一个元素B，但反之却不成立，那么这两个元素B和A之间的关系是依赖关系，即元素B依赖元素A。比如，工人（Worker）要完成拧螺丝（screw）的工作，需要依赖螺丝刀（Screwdriver）的帮助，在这种情况下就可以理解为，工人和螺丝刀之间存在依赖关系。前面介绍的泛化关系和后面即将介绍的实现关系在语义上讲也是依赖关系，但由于其有更特殊的用途，所以被单独描述。

在UML中，依赖关系被表示为带箭头的虚线，箭头指向被依赖元素。具体建模时，依赖关系通常体现为某个类的方法使用另一个类的对象作为参数，如图4.37所示，依赖关系体现为Worker类的screw方法使用Screwdriver对象作为参数。

3.实现（Realize）关系

如果一个元素A定义了一个标准，而另一个元素B保证执行该标准，那么元素B和元素A之间的关系是实现关系，即元素B实现元素A。在Java语言中，直接使用implements关键字表示实现关系。

这个关系最常应用于类和接口之间，接口可以定义标准，通常是定义类需要完成的功能的标准，但接口并不关心功能的具体实现，具体实现交由相应的类去完成。比如，“收费”是一个接口，它定义了“收取费用”这个功能的标准，如果“客车”类和“火车”类要执行该标准完成各自“收取费用”的功能，就必须给出“收取费用”的具体实现方法。在这种情况下可以理解为，“客车”类和“收费”接口之间是实现关系，“火车”类和“收费”接口之间也是实现关系。

在UML中，实现关系被被表示为带有空心箭头的虚线，箭头指向定义标准的元素（如接口），详见图4.38所示。

4.关联（Association）关系

关联通常是双向的（当然也有单向的），即关联的双方彼此能够互相通信，彼此都能感知到另一方的存在。在UML中，关联关系被表示为一条实型直线。如果该实型直线实线带有箭头，则表明是单向关联，箭头方向表示关联方向，图4.39所示；如果该实型直线实线没有箭头，则表明是双向关联，如图4.40所示。

关联可以使用关联名称、关联角色、导航性和多重性等来进行修饰。

（1）关联名称

关联关系可以添加名称，用于描述该关系的性质。此关联名称应该是动词或动词短语，因为它代表源对象正在目标对象上执行的动作。在双向关联中，可以在关联的一个方向上为关联起一个名字，而在另一个方向上起另外一个名字（也可以不起），名字通常紧挨着实线书写。为避免产生混淆，在名字的前面或后面可以附加一个表示关联方向的实心黑三角，黑三角的尖角指明这个关联名称只能用于尖角所指的对象上。如图4.41所示，“Person”和“Company”之间存在关联关系，其关联名称为“worksfor”，该名称用于“Company”上。

值得说明的是，关联名称并非是必须的，只有在需要明确给关联提供角色名称时，或一个模型中存在很多关联且应该加以区分时，才需要给出关联名称。

（2）关联角色

当一个对象处于关联的一端时，也就意味着该对象在这个关系中扮演了一个特定的角色。具体来说，关联角色就是关联关系中一个对象针对于另一个对象所表现的职责。角色的名称应该是名词或名词短语，用来解释对象是如何参与关联的。在类图中，关联角色放置在相应的关联（实线）的末端。如图4.42所示，“Company”扮演的是“employer”雇主的角色，而“Person”扮演的是“employee”雇员的角色。关联角色是关联的一个组成部分，可根据需要选用。

（3）关联的导航性

导航性描述的是一个对象能否访问另一个对象。也就是说，关联的一端设置导航性表明本端的对象可以被另一端的对象访问。在图示上，导航方向用箭头方向标注，前面已经介绍过，只在一个方向上可以导航的关系称为单向关联，用一条带箭头的实线来表示；在两个方向上都可以导航的关系称为双向关联，用一条没有箭头的实线表示。具体建模时，关联关系的导航性一般是通过类的成员变量来体现的，如图4.43所示。

（4）关联的多重性

关联的多重性是一种约束，用来表示关联中的数量关系。在图示上，多重性被表示为用圆点分隔的区间，每个区间的一般格式为：minimum..maximum。其中minimum代表最小值，maximum代表最大值，取值均是非负整数。具体多重性指标如表4.3所示。

表4.3关联的多重性指标

多重性指标

恰为1

*等同于n

0或更多

0..1

0或1

0..*等同于0..n

1..*等同于1..n

1或更多

2..6

2~6

2,4..6

2,4~6

“Company”和“Person”之间的多重性关系如图4.44所示。通过图示可知，一个“Company”（公司）可以拥有1个或多个“Person”（人员），一个“Person”（人员）属于一个“Company”（公司）。

5.聚集（Aggregation）关系

聚集也称聚合，是一种特殊的较强的关联，表示类（确切地说，是类的实例即对象）之间是整体与部分的关系。

在UML中，聚集关系被表示带有空心菱形头的实线。如图4.45所示，“Car”（汽车）是代表整体事物的对象（也称聚集对象），“Wheel”（轮子）是代表部分事物的对象。

6.组合（Composition）关系

组合是一种特殊形式的聚集，组合关系中的整体与部分具有相同的生存期。

在UML中，组合关系被表示为带有实心菱形头的实现。如图4.46所示，“Company”（公司）是代表整体事物的对象（也称组合对象），“Department”（部门）是代表部分事物的对象。

UML类图中的聚集关系和组合关系主要区别在于：聚集关系表示整体与部分的关系比较弱，而组合比较强。聚集关系是“hasa”的关系，组合关系是“containsa”的关系。聚集关系中聚集对象与代表整体事物的对象并无生存期上的联系，一旦删除了代表整体对象的事物不一定就删除了聚集对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。例如图4.45汽车和轮子之间的聚集关系表明，如果汽车没有了，轮子还可以独立存在，还可以被安装到其他汽车上，它们之间的关系相对松散。而在图4.46公司和部门之间的组合关系表明，如果公司没有了，公司的部门自然也就消失了，它们具有相同的生存期，它们之间的关系相对聚集而言更加密切。

之前介绍的关联关系和聚集关系的主要区别是语义上的：关联的两个对象之间一般是平等的，例如你是我的朋友；聚集则一般不是平等的，例如一个球队包含多个球员。但它们在实现上都是相似的。

能够识别“图书管理系统”中各个类之间的关系，并在RationalRose中绘制图示。

1.识别“图书管理系统”中包之间的关系。

2.识别“图书管理系统”中各个类之间的关系。

3.在RationalRose中绘制“图书管理系统”的类图。

1.识别“图书管理系统”中包之间的关系

显而易见，GUIPackage和BusinessPackage之间存在依赖关系，前者依赖后者而存在。

2.识别“图书管理系统”中各个类之间的关系

结合前面的知识，可以分析出“图书管理系统”中BusinessPackage包中各个实体类的关系如表4.4所示。

表4.4BusinessPackage包中各个实体类的关系

类A

类B

类A和类B之间的关系

泛化

组合

普通关联

同样，可以分析出GUIPackage包中各个边界类的关系如表4.5所示。

表4.5GUIPackage包中各边界类的关系

Main

单向关联

SystemManage

ReaderManage

BookManage

BorrowManage

FineManage

3.在RationalRose中绘制“图书管理系统”的类图

（1）打开类图

启动RationalRose后，在菜单栏中选择【File】->【Open】菜单项，可以打开已有工程“Library”，然后在左侧浏览器窗口中单击【LogicalView】前面的【】符号，展开树型结构，此时已经创建过的“LibraryClass”类图便可显示出来，双击“LibraryClass”打开该类图的编辑区。

（2）建立包之间的关系

在编辑区工具栏中单击依赖关系符号【】即“Dependencyorinstantiates”，采用按住鼠标左键拖拽的方式，将GUIPackage和BusinessPackage连接起来。注意箭头应该指向BusinessPackage，如图4.47所示。

（3）建立类之间的关系

接下来可以双击BusinessPackage，为该包中的各个类建立关系。

参照表4.4的分析，Admin类和Administrator类之间存在泛化关系，为刻画这种关系，需要在编辑区工具栏中单击依赖关系符号【】即“Generalization”，采用按住鼠标左键拖拽的方式，将Admin类和Administrator类连接起来，注意箭头应该指向父类Admin。按照同样的方法，可以建立Admin类和Librarian类之间的泛化关系。

参照表4.4的分析，Book类和BookType类之间存在组合关系，为刻画这种关系，需要在编辑区工具栏中单击依赖关系符号【】即“Association”，然后将鼠标停放在编辑区任意位置，鼠标会变成箭头形状，箭头方向向上，此时采用按住鼠标左键拖拽的方式，首先将Book类和BookType类之间建立关联关系。然后，双击该关联关系（即实线），打开“关联设置”对话框，在该对话框的【General】选项卡中可以设置关联名称、关联角色等内容，如图4.48所示。在该对话框的【RoleADetail】和【RoleBDetail】选项卡中可以设置关联的导航型、多重性等内容，同时还可以将该关联关系细化为聚集关系或组合关系，如图4.49所示。

根据实际需要，进行完相应的设置后，Book类和BookType类之间就可以建立起如图4.50所示的组合关系。

遵循以上方法，很容易建立“图书管理系统”GUIPackage包中各边界类之间的关系，如图4.51所示。

类似地，可以再建立“图书管理系统”BusinessPackage包中各实体类之间的关系，如图4.52所示和图4.53所示。

1.在UML的静态建模中，可以借助___________表示在某一时刻这些类的具体实例和这些实例之间的连接关系。

2.如果一个类与另一个类之间的关系具有“整体与部分”的特点，描述的是“hasa”的关系，那么这两个类之间的关系是（）关系。

A.实现（Realize）B.聚集（Aggregation）

C.组合（Composition）D.泛化（Generalization）

3.“交通工具”类与“汽车”类之间的关系属于（）关系。

A.关联（Association）B.聚集（Aggregation）

4.每个HouseKeeper都有一个Manager负责，有的Manager可能负责多个HouseKeeper，有的Manger可能一个HouseKeeper都没有，下面哪幅图适合描述类HouseKeeper和类Manger的关系？（）

5.根据图4.54所示类之间的关系，回答问题。

classRegularReceiptVisitor

{

publicvoidprintRoomCharges(XXX&aVar)

aVar.getDescription();

aVar.getQualtity();

aVar.getPrice();

}

上面代码中的XXX处最适合填什么？（）

A.ReceiptVisitorB.PromotionalReceiptVisitor

C.DescribableD.Entertainment

6.已知三个类A、B和C，其中类A由类B的一个实例和类C的1个或多个实例构成。能够正确表示类A、B和C之间关系的UML类图是（）。

A.B.

C.D.

7.下面哪个类图的关系表示只有SportVehicle才能使用SportEngine()

8.请建立一个树型结构的类图，要求任意一个节点能够导航到父亲节点，也能导航到其孩子节点。

9.请为下面这段Java代码补充类图。

publicclassStudent{

privateStringname;

publicvoidsetName(Stringname){

this.name=name;

publicStringgetName(){

returnthis.name;

10.根据下面的陈述绘制类图。

（1）学生包括本科生、研究生两种。

（3）教师包括讲师和教授两种。

（4）一名助教可以为一位讲师或一位教授助课，一位讲师只能有一名助教，一位教授可以有5名助教。

11.按如下描述绘制出“飞船系统”的类图。

神州六号飞船是神州飞船系列的一种，它由轨道舱、返回舱、推进舱和逃逸救生塔等组成；航天员可以在返回舱内驾驶飞船，轨道舱则是航天员工作和休息的场所。在紧急情况下，可以利用逃逸救生塔逃生。在飞船两侧有多个太阳能电池翼，可以为飞船提供电能。

12.按如下描述绘制出“自治机器人系统”的类图。

这张图的焦点是聚集在那些让机器人在路上行走的机制所对应的类上。通过分析，可以发现一个虚类Motor和两个从它派生出来的类：SteeringMotor和MainMotor。这两个类都从父亲Motor继承了五个方法：move()、stop()、resetCounter()、status（）、distance()。这两个类又是另一个类Driver的一部分。类PathAgent和Driver有一个1对1的关系，类PathAgent和CollisionSensor有1对n的关系。

1.类图工具栏

类图工具栏上的按钮名称及功能，详见表4.6。

表4.6类图工具栏

Class

类

Interface

接口

AssociationClass

关联类

Realize

实现关系

2.对象图与类图

对象图主要用来加强对类图的理解，在实际建模中并不常用。使用RationalRose工具并不能绘制对象图，如需绘制对象图可以借助于其他建模工具。

在第4章静态模型的类图和对象图中，我们已经知道对象是类的实例，是系统中用来描述客观事物的实体，是构成系统的基本单位。在本章动态模型的时序图中，对象代表参与交互的角色，该角色可以是类的实例，也可以是系统参与者、人机界面、功能模块等。

在UML1.x中，时序图的对象符号被表示为矩形，该矩形包含对象名称，并且在该对象名称下方需加下划线。常见格式有下列三种，实际应用中如何选择应视具体情况而定。

第一种见图5.2所示，即对象名在前，类名在后，其间用冒号连接，表明前者是后者的对象，如“Tom”是“Student”类的一个对象。

第二种见图5.3所示，此种格式用于尚未给出对象名的情况，如只给出“Student”类而没有给出该类对象的具体名称。

第三种格式见图5.4所示，只给出对象名而省略类名，如只给出对象名“Tom”，却没有指出该对象具体属于哪个类。

生命线代表对象在一段时期内的存在。在UML1.x中，生命线表示为一条垂直的虚线，存在于对象底部中心位置，如图5.5所示。但是在UML2.0中，生命线改成了矩形加虚线的整体表示，而取消了原来关于对象的称呼。另外，由于在UML2.0的时序图中矩形已经不代表对象，所以先前矩形对象名称下方的下划线也被取消，如图5.6所示。

在某些情况下，需要明显地表示出对象被销毁。例如，当使用没有自动垃圾回收机制的C++作为开发语言时，或者需要特别指明对象不再被使用时（如关闭数据库连接等），都需要销毁对象。在UML生命线中提供了表示对象销毁的方式，如图5.7所示。

消息是对象间通信的表现形式，对象间的交互是通过消息的传递来完成的。消息可以激发操作、唤起信号、创建对象或撤销对象。在时序图和后续的协作图中均用到了这一概念，消息在具体应用中可以是确切的信号，也可以是某种调用机制。

在UML中，消息表示为箭头，箭头起始的一方是发送方，箭头指向的一方是接收方，如图5.8中所示。箭头的类型体现了消息的类型，详见表5.1。

消息类型

符号表示

含义说明

Simple

对象间的简单消息

Synchronous

对象间的同步消息

Balking

反身消息

Timeout

超时消息

Procedurecall

对象间的过程调用

Asynchronous

对象间的异步消息

Return

返回消息

注：同步消息，就是需要等待消息的处理完成，才可以接着执行下去。异步消息，就是发送以后不必等待完成。

激活期，也称活动期或控制期（FocusofControl），代表对象直接或间接执行某项操作的时期；换言之，在该时期内对象被占用以完成特定的任务，而在该时期以外对象则处于空闲状态。在UML中，激活期表示为对象生命线上的细长矩形，该矩形也被称为激活条。对象在激活条的顶部被激活，完成特定的任务后进入空闲状态，详见图5.8所示。

（1）新建模型或打开模型

RationalRose正常启动后，选择【File】->【New】菜单，新建一个模型命名为“Library”，如图5.9所示。如果在此之前已经建立了“Library”模型，那么就可以选择【File】->【Open】菜单，打开这个原有的模型。

（2）新建时序图

在视图区域树型列表中，右键单击【LogicalView】结点，然后在弹出的快捷菜单中选择【New】->【SequenceDiagram】，如图5.10所示。在此默认的时序图名称为“NewDiagram”，可以输入新的时序图名称为“UserLogin”。

（3）创建对象

在时序图工具栏中选择对象按钮【】即“Object”，然后在绘图区域中单击鼠标左键，便可以将指定的对象添加到时序图中，被添加的对象自动带有生命线。如果要修改对象的名称，可以双击对象打开“对象属性”对话框，或者右键单击该对象，在弹出的快捷菜单中选择【OpenSpecification】也可以打开“对象属性”对话框，如图5.11所示。以创建Librarian对象为例，在图5.11所示对话框的【Class】下拉列表中，如果选择“Librarian(UseCaseView)”，Librarian对象将显示为类似参与者的图示，如果选择“Lirarian(LogicalView:BusinessPackage)”，Librarian对象对象将显示为相似于类的图示。

本例时序图中涉及到两个对象，其一为Librarian创建的一个对象，其二为Reader类创建的一个对象，如图5.12所示。

（4）识别对象间的消息

如果要取消消息编号或取消激活期的显示，可以选择主菜单栏中的【Tools】->【Options】，在弹出的对话框中选择【Diagram】选项卡，通过复选框来完成相应的设置，如图5.15所示。

2.建立“图书信息录入”的时序图，并使用RationalRose工具实现。

该时序图中涉及到的对象说明如下：

（1）Librarian对象：Librarian类即图书管理员类创建的一个对象。

（2）BookType对象：BookType类即图书类型创建的对象。

（3）Book对象：Book类即图书类创建的对象。

该时序图中涉及到的消息说明如下：

（1）bookType消息：获取所有图书类型编号及类型名称。

（2）operationType消息：选择操作方式。

（3）getBookInfo消息：获取图书基本信息。

（4）returnBookInfo消息：返回获取到的图书基本信息。

（5）editPage消息：界面编辑。

（6）inputBookInfo：根据操作方式录入图书基本信息。

（7）returnInputMess：返回录入信息。

（2）BorrowManage对象：借阅管理对象。

（3）BookType对象：图书类型对象。

（4）Book对象：图书对象。

（1）getBorrowInfo消息：获取借阅信息。

（2）getBookType消息：获取图书类型信息。

（4）showResult消息：显示查询结果。

（2）Reader对象：读者对象。

（3）Book对象：图书对象。

（4）ReaderType对象：读者类型对象。

（5）BorrowManage对象：借阅管理对象。

（1）getReaderInfo消息：获取读者基本信息，如办证日期、借阅数量、挂失标志，用处理图书证过期、借阅数量已满等问题

（2）getReaderType消息：获取读者类型信息。

（3）getBookFlag消息：获取图书借阅标志，用于判断图书是否可借阅。

（4）InputBorrowInfo消息：输入借阅信息，如读者编号，图书编号，借还日期等。

（5）modifyBookFlag消息：修改图书借阅标志。

（6）addBorrowBook消息：增加读者已借阅图书数量。

（4）BorrowManage对象：借阅管理对象。

（1）inputOption消息：输入查询条件信息。

（2）getPaymentInfo消息：获取罚金信息。

（3）getReaderInfo消息：获取读者基本信息。

（4）getBookInfo消息：获取图书基本信息。

（5）showResult消息：显示出读者、图书及罚金信息。

1.什么是时序图？时序图的构成要素有哪些？

2.建立时序图应遵循怎样的步骤？

3阅读如图5.21所示“购买饮料”主要场景的时序图，试描述不同对象间消息的传递。

4阅读如图5.22所示“饮料已售完”场景的时序图，试描述不同对象间消息的传递。

5参考“图书管理系统”的“借书”时序图，创建“还书”时序图，并使用RationalRose工具实现。

6参考“图书管理系统”的“图书信息录入”时序图，创建“读者信息录入”时序图，并使用RationalRose工具实现。

8.根据如下文字描述，绘制出“ATM取款”最理想场景（无需考虑特殊情况）的时序图，并用RationalRose工具实现。

（1）开始用户“Jack”将银行卡插入到读卡器，读卡器读取卡号，打开“Jack”的账目对象，并初始化屏幕，屏幕提示输入PIN密码，“Jack”输入密码，然后系统验证密码与账户对象，发出相符的信息。

（2）ATM屏幕向“Jack”提供操作选项，“Jack”选择取款，然后屏幕提示“Jack”输入取款金额，他选择了2000元RMB，系统启动账目对象进行核实，之后从账户中取钱。

（3）系统启动账目对象进行核实的过程如下：首先，验证“Jack”的账目至少有2000元RMB；然后从中扣除2000元RMB，再让吐钞机提供2000元RMB现金；另外还需要让票据打印机提供取款凭据；最后让读卡器退卡。

1.监护条件

2.时序图工具栏

时序图工具栏上的按钮名称及功能，详见表5.2。

表5.2时序图工具栏按钮

Object

对象

ObjectMessage

对象间的消息

MessagetoSelf

ReturnMessage

DestructionMarker

销毁对象

协作图（CollaborationDiagram）和时序图一样，都是用于描述系统动态特性的交互图；只不过时序图侧重强调消息的先后顺序，而协作图侧重强调参与交互的各个对象是如何组织的。本章在全书知识体系中的位置如图6.1所示。

一般来讲，协作图包括如下三种构成元素：对象（Object）、链（Link）和消息（Message）。

对象代表协作图中参与交互的角色，和时序图中对象的概念基本相似。只不过在协作图中，无法表示出对象的创建与对象的撤销，正因为如此在协作图中对象的位置没有特殊限制。如图6.2所示，矩形框中的内容代表对象。

链是连接两个对象的路径，它指明了对象间的关联。在UML中，链被表示为一条实线。如图6.2所示，从Student类的一个对象到Teacher类的一个对象之间存在链（或路径），消息会沿着此链流转，如message1，message2和message3。

能够捕获“图书管理系统”中既定场景的对象、消息等要素，并且使用RationalRose工具绘制出协作图；能够将指定的时序图转化成协作图，并且使用RationalRose工具绘制出其图示。

1.识别“图书管理系统”中“读者预订”场景的对象、消息等要素，并使用RationalRose工具绘制出其读者预订的协作图。

2.识别“图书管理系统”中“读者确认预订”场景的对象、消息等要素，并使用RationalRose工具绘制出其读者确认预订的协作图。

4.将“图书管理系统”中“图书信息录入”场景的时序图转化成协作图，并使用RationalRose工具绘制出该协作图。

6.将“图书管理系统”中“借书”场景的时序图转化成协作图，并使用RationalRose工具绘制出该协作图。

7.将“图书管理系统”中“查询罚金”场景的时序图转化成协作图，并使用RationalRose工具绘制出该协作图。

1.建立“读者预订”协作图，并使用RationalRose工具实现。

（1）打开模型

RationalRose正常启动后，选择【File】->【Open】菜单，打开此前已有的“Library”模型。

（2）新建协作图

在视图区域树型列表中，右键单击【LogicalView】结点，然后在弹出的快捷菜单中选择【New】->【CollaborationDiagram】，如图6.3所示。在此默认的协作图名称为“NewDiagram”，可以输入新的协作图名称为“ReaderReserve”。双击该协作图，在RationalRose窗口内右侧空白处出现相应的编辑区，在编辑区中可进行后续操作。

图6.3新建协作图

在协作图工具栏中选择对象按钮【】即“Object”，然后在编辑区中单击鼠标左键，便可以将指定的对象添加到协作图中。如果要修改对象的名称，可以双击对象打开“对象属性”对话框，或者右键单击该对象，在弹出的快捷菜单中选择【OpenSpecification】也可以打开“对象属性”对话框，具体参见第5章中图5.11所示。

本例协作图中涉及到四个对象，其一为Reader类创建的对象，其二为Main类创建的对象，其三为Book类创建的对象，其四为Reserve类创建的对象，如图6.4所示。

图6.4创建对象

（4）在对象间添加链和消息

在协作图工具栏中选择链的按钮【】即“ObjectLink”，然后在编辑区中两个对象之间拖拽鼠标左键，便可以在指定的对象间添加链。如果需要对链进行详细设置，可以双击链，或者右键单击链，在弹出的快捷菜单中选择【OpenSpecification】，打开“链属性”对话框，如图6.5所示。

图6.5“链属性”对话框

对象间添加链以后，可以在链上添加相应的消息。以Reader对象发送给Main对象的readerID（读者证号）消息为例，将具体添加方法说明如下。

方法之二是：在图6.5所示的“链属性”对话框中，选择【Messages】选项卡，然后右键单击中间空白区域，在弹出的快捷菜单中选择【InsertTo:Main】菜单项，最后键入新的消息名称“readerID”替换默认属性名称“opname”。如图6.6所示。

图6.6添加消息

本例协作图中，对象间涉及到的消息有四个：其一为Reader对象发送给Main对象的readerID（读者证号）消息；其二为Main对象发送给Book对象的queryRequirement（查询条件）消息；其三为Book对象发送给Main对象的返回消息queryResult（查询结果），其四是Main对象发送给Reserve对象的reserveSuccess（预订成功）消息。如图6.7所示。

图6.7“ReaderReserve”协作图

至此，“读者预订”协作图已基本完成。

2.建立“读者确认预订”协作图，并使用RationalRose工具实现。

实际操作步骤与建立“读者预订”协作图相似，使用RationalRose工具实现的“ReaderConfirm”协作图如图6.8所示。

该协作图中涉及到的对象说明如下：

（2）Reserve对象：Reserve类即预订类创建的对象。

（3）Book对象：Book即图书类创建的对象。

（4）Reader对象：Reader类即读者类创建的对象。

（5）Borrow对象：Borrow类即借阅类创建的对象。

该协作图中涉及到的消息说明如下：

（1）readerInfo消息：读者信息。

（2）reserveInfo消息：预订信息。

（3）confirmRequirement消息：请求确认预订。

（4）successInfo消息：核对成功。

（5）borrowInfo消息：借阅信息。

（6）bookInfo：图书信息。

（7）bookRequirement：请求获取图书。

图6.8“ReaderConfirm”协作图

方法之一是按照建立“读者预订”协作图的步骤操作。

方法之二是采用时序图和协作图自动相互转换的方式。具体步骤如下：

（1）首先打开要转换的时序图，如“UserLogin”时序图。

（2）然后选择RationalRose主菜单中的【Browse】->【GoToCollaborationDiagram】菜单项，如图6.9所示，即可将当前时序图转换成协作图。在图6.9所示的菜单中，选择【PreviousDiagram】菜单项还可以查看转换前的UML图示。当然也可以在RationalRose中按“F5”快捷键，直接将“UserLogin”时序图转化成协作图。

类似地，也可以将协作图转换成时序图。具体步骤同上：首先打开要转换的协作图，如“UserLogin”协作图；然后选择RationalRose主菜单中的【Browse】->【GoToSequenceDiagram】菜单项，如图6.10所示，即可将当前协作图转换成时序图。同样，在图6.10所示的菜单中，选择【PreviousDiagram】菜单项也可以查看转换前的UML图示。

无论采用哪种方式，最终完成的协作图如图6.11所示。

图6.9转化成协作图图6.10转化成时序图

图6.11“UserLogin”协作图

（2）UserInfo对象：用户信息表对象。

（1）getUserInfo消息：用于获取用户信息如用户名和密码等。

4.建立“图书信息录入”协作图，并使用RationalRose工具实现。

图6.12“InputBook”协作图

图6.13“SearchHotBook”协作图

6.建立“借书”协作图，并使用RationalRose工具实现。

图6.14“BorrowBook”协作图

（3）Reader对象：读者对象。

（5）ReaderType对象：读者类型对象。

7.建立“查询罚金”协作图，并使用RationalRose工具实现。

图6.15“SearchPayment”协作图

1.关于协作图的叙述，不正确的是（）。

A.协作图作为一种交互图，强调参加交互的对象的组织

B.在RationalRose工具中，协作图可在时序图的基础上按“F5”键自动生成

C.协作图中有消息的顺序号

D.协作图是时序图的一种

2.下面哪种图最合适用来描述场景：（）。

A.包图B.交互图

C.类图D.用例图

3.什么是协作图，协作图由哪些部分组成？

4.将下图6.16所示的时序图转换成协作图。

5.根据下图6.17所示的协作图，描述参与交互的对象及对象间的消息。

6.根据某连锁企业对其分店管理的协作图，如下图6.18所示，描述其管理过程。

7.根据下图6.19所示的协作图，描述对象之间的消息传递，并将其转换为时序图。

8建立“教务管理系统”中“学位评审”的协作图，其中学生学位评审流程描述如下。

（1）教务人员将需评审的学生的学号输入学位初评模块。

（2）学位初评模块会查询相应学生的成绩和奖惩记录，来作为学位评定的依据。

（3）学位初评模块将初评结果打印。

（4）学位初评打印稿被提交给教务人员。

图6.16“发送消息”时序图

图6.17“ATM验证用户”协作图

图6.18分店管理协作图

图6.19维护课程信息协作图

1.时序图与协作图的比较

时序图与协作图都是交互图，二者既有联系又有区别。

联系体现为：顺序图和协作图都是用于描述系统动态特性的交互图；时序图和协作图从语义上讲是相同的，它们只是从不同的方面来描述一次交互。

2.交互图与类图的关系

前面已经介绍过，协作图和时序图，都是用于描述系统动态特性的交互图。值得注意的是，当绘制交互图时，也就是在动态建模的过程中可能会发现一些新的类及方法。因此，类图的定义能够从交互图中产生。

在具体实践中，动态建模和静态建模往往是并行的。例如，10分钟绘制静态模型，10分钟绘制动态模型，如此交替进行。

3.协作图工具栏

协作图工具栏上的按钮名称及功能，详见表6.1。

表6.1协作图工具栏按钮

ClassInstance

类实例

ObjectLink

对象间的链

LinkToSelf

链接自身的链

LinkMessage

消息

ReverseLinkMessage

DataToken

数据流

ReverseDataToken

返回数据流

状态图（StatechartDiagram）是描述系统动态行为的一种常用工具，它强调从状态到状态的控制流，规定了对象在其生命周期内响应事件所经历的状态序列以及对象针对这些事件的响应。换言之，状态图主要用于建立类的一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件（Event），以及因状态转移而伴随的动作（Action）。但值得说明的是，并不需要为系统中涉及的所有对象都创建状态图，只有当行为的改变和状态有关时才需要创建状态图。

与交互图适合于描述单个用例中多个对象的行为不同，状态图适合于描述跨越多个用例的单个对象的行为，而不适合于描述多个对象之间的行为协作，因此，在实际应用中常常将状态图与其它技术组合使用。状态图在检查、调试和描述类的动态行为时非常有用。本章在全书知识体系中的位置如图7.1所示。

一般来讲，协作图包括如下几种构成元素：起点（Start）和终点（End）、状态（State）、事件（Event）、转换（Transition）。

起点是状态图的初始状态，也是状态图的起始位置，表示一个工作流程的开始。起点只能作为转换（Transition）的源，而不能作为转换（Transition）的目标。起点在状态图中只允许有一个。在UML中，起点被表示为实心圆，如图7.2所示。

终点是状态图的最后状态，也是状态图的终止位置。与起点相反，终点只能作为转换（Transition）的目标，而不能作为转换（Transition）的源。终点在一个状态图中可以有一个或有多个，也可以没有。在UML中，终点被表示为环形，环形内圆为实心圆，如图7.2所示。

图7.2状态图的起点和终点

状态是指对象在其生命周期内某时刻所处的的情形，在此期间对象将满足某些条件、执行某些活动或等待某些事件。下面就以“图书管理系统”中的对象为例，说明其状态。

例如，《C语言程序设计教程》在图书馆中，那么此时该图书对象就处于在馆状态。又如，“张三”已经毕业，那么此时该读者对象就处于离校状态。再如，“李四”的读者证已经挂失且未曾补办，那么此时该读者证对象就处于无效状态。

一个状态可以包括以下几个组成部分：状态名称（StateName）、入口/出口动作（Entry/ExitAction）、动作（Action）、子状态（Substate）。在实际应用中，状态名称一般需要表示出来，而入口/出口动作（Entry/ExitAction）、动作（Action）、子状态（Substate）部分可以视具体情况而定。在UML中，状态被表示为圆角矩形框，如图7.3所示。

（1）状态名称（StateName）

状态名称用于识别不同的状态，通常被表示为一个字符串，放置于状态的顶部，如图7.4所示，状态名称为Faxing。

（2）入口/出口动作（Entry/ExitAction）

入口动作表示进入某个状态所执行的操作，入口动作的语法是：entry/执行的动作。出口动作表示退出某个状态所执行的操作，出口动作的语法是：exit/执行的动作。这里所说的动作可以是原子动作，也可以是一个动作序列。如图7.4中所示，进入Faxing状态所执行的操作，即该状态的入口动作表示为entry/keyinremotefaxnumber，退出Faxing状态所执行的操作，即该状态的出口动作表示为exit/completetransmission。

（3）动作（Action）

动作表示在某个状态下，需要执行的操作。这里所说的动作同样可以是原子动作，也可以是一个动作序列。如图7.4中所示，在Faxing状态下需要执行的操作，即该状态的动作表示为do/adddatestamp和do/timestamp。

（4）子状态（Substate）

图7.4状态的组成部分

转换用于描述两个状态之间的关系，表示对象将在第一个状态中执行一定的动作，并在某个特定事件发生时进入第二个状态。也就是说，转换往往由事件引发。

在UML中，转换被表示为箭头，箭头起始的一端为源状态，箭头指向的一端为目标状态，如图7.7所示。

图7.7转换

对于一个给定的状态，最终只能产生一个转换。因此从相同的状态出发、事件相同的几个转换之间的条件应该是互斥的。如图7.8所示，从源状态“A”出发，事件均为“event”的三个转换条件分别为[x<0]、[x=0]、[x>0]，这三个条件本身是互斥的，使得对于给定的状态“A”，最终只能产生一个转换。

图7.8转换中的互斥条件

能够捕获“图书管理系统”中指定对象的状态，并且使用RationalRose工具绘制出相应的状态图。

1.建立读者证对象的状态图，并使用RationalRose工具实现。

2.建立图书对象的状态图，并使用RationalRose工具实现。

3.建立整个系统的状态图，并使用RationalRose工具实现。

RationalRose启动后，选择【File】->【Open】菜单，打开已有的“Library”模型。

（2）新建状态图

在视图区域树型列表中，右键单击【LogicalView】结点，然后在弹出的快捷菜单中选择【New】->【StatechartDiagram】，如图7.9所示。在此默认的状态图名称为“NewDiagram”，可以输入新的状态图名称为“ReaderCardState”。双击该状态图，在RationalRose窗口内右侧空白处出现相应的编辑区，在编辑区中可进行后续操作。

图7.9新建状态图

（3）添加状态及转换

在状态图工具栏中选择起点按钮【】即“StartState”，然后在编辑区中单击鼠标左键，便可以将初始状态添加到状态图中。

继续在状态图工具栏中选择状态按钮【】即“State”，然后在编辑区中单击鼠标左键，便可以将状态添加到状态图中。新添加的状态默认名称为“NewState”，可将其名称根据具体情况进行修改。简便的修改方法是直接在“NewState”处键入状态的新名称；稍复杂的修改方法是双击该状态打开“状态属性”对话框，或者右键单击该状态，在弹出的快捷菜单中选择【OpenSpecification】也可以打开“状态属性”对话框，如图7.10所示，在此将状态命名为“Valid”。如果还需要为状态设置入口/出口动作、动作等内容，可以双击“状态属性”对话框中的【Actions】选项卡，然后在中间空白区域任意位置右键单击，会弹出如图7.11所示的快捷菜单。在弹出的快捷菜单中选择【Insert】菜单项，可以添加动作，新添加的动作默认类型为“Entry”，默认名称为空。如果想修改动作的类型和名称，可以在图7.11所示的快捷菜单中选择【Specification】菜单项，打开如图7.12所示的“动作属性”对话框，在该对话框中进行详细的设置。

图7.10“状态属性”对话框

依照如上方法，分别创建出读者证的三个状态：Valid（有效）、Losing（挂失）、Invalid（无效）。

在不同状态之间可以添加转换，完成从一种状态到另一种状态的过渡。具体方法是：在状态图工具栏中单击转换符号【】即“StateTransition”，然后将鼠标停放在编辑区任意位置，鼠标会变成箭头形状，箭头方向向上，此时采用按住鼠标左键拖拽的方式，首先将Valid状态和Losing状态之间添加转换。然后，双击该转换，打开“状态转换属性”对话框，在该对话框的【General】选项卡中可以设置转换名称、参数等内容，如图7.13所示。在“状态转换属性”对话框中单击【Detail】选项卡，可以打开如图7.14所示的界面，在该界面中可以设置监护条件等内容。

图7.11设置状态包含的动作

图7.12“动作属性”对话框

图7.13“状态转换”对话框

图7.14设置监护条件

如果状态图还有终止状态，则可以在状态图工具栏中选择终点按钮【】即“EndState”，继而在编辑区中单击鼠标左键，便可以将终止状态添加到状态图中。

（4）调整图形

按照美观实用的原则，调整状态图中各元素的大小和位置。其中对线性的调整可以参照图7.15所示的菜单进行操作，以保证线性的平滑。

图7.15调整线性

经过以上各步骤，最终得到“图书管理系统”中读者证状态图如图7.16所示。

图7.16“ReaderCardState”状态图

通过读者证对象的状态图可知：

（1）读者证对象首先进入初始状态，读者办理读者证（getcard）后，该读者证转换到有效（Valid）状态，入口动作是获得新证（getnewcard）；

（2）发生读者证丢失（losecard）事件后，该读者证从有效状态转换到挂失（losing）状态，此时动作为丢失读者证（lostcard）；

（3）发生补办读者证（retrievecard）事件后，该读者证从挂失状态转换到有效状态；

（4）读者证丢失但读者放弃读者证（giveupcard）事件发生后，该读者证从挂失状态转换到无效（Invalid）状态；

（5）发生读者毕业（readergraduate）事件后，该读者证从有效状态转换到无效状态，出口动作是归还读者证（returncard）。

实际操作步骤与建立读者证对象状态图相似，使用RationalRose工具实现的“BookState”状态图如图7.17所示。

图7.17“BookState”状态图

通过图书对象状态图可知：

（1）图书对象首先进入初始状态，购入新书（buynewbook）后，该图书转换到入库（EnterToStore）状态；

（2）发生登记图书（bookin）事件后，该图书会由入库状态转换到在馆（InStore）状态；

（3）图书处于在库状态时，如果发生读者预订（readerreserve）事件，那么该图书将从在馆状态转换到预订（Reserved）状态；

（4）图书处于在馆状态时，如果发生读者借阅（readerborrow）事件，那么该图书将从在馆状态转换到在借（Borrowed）状态；

（5）图书处于预订状态时，如果发生取消预订（cancelreservation）事件，那么该图书将从预订状态转换回在馆状态；

（6）图书处于预订状态时，如果发生了确认预订（confirmreservation）事件，那么该图书将从预订状态转换到在借状态；

（7）图书处于在借状态时，如果发生了归还图书（returnbook）事件，那么该图书将从在借状态转回到在馆状态；

（8）图书处于在借状态时，如果发生了丢失图书（losebook）事件，那么该图书将从在借状态转换到注销（Logout）状态；

（9）图书处于在馆状态时，如果发生了图书下架（removebook）事件后，那么该图书将从在馆状态转换到下架（OffBookshelf）状态。

实际操作步骤与建立读者证对象状态图相似，使用RationalRose工具实现的“SystemState”状态图如图7.18所示。

图7.18“SystemState”状态图

通过整个系统的状态图可知：

（3）系统进入读书管理（BookManagement）状态、读者管理（ReaderManagement）状态、借阅管理（BorrowManagement）状态、罚金管理（FineManagement）状态之一后，发生退出（quit）事件时，系统将进入关闭（Closing）状态。

1.要描述控制机制，比如描述一个系统中的控制对象，（）最合适。

A.时序图（SequenceDiagram）B.状态图（StatechartDiagram）

C.类图（ClassDiagram）D.协作图（CollaborationDiagram）

2.下面关于状态图的说法错误的是（）。

A.状态图适合用来描述跨多个用例的对象的行为

B.状态图只适用于那些有多个状态的对象，而不是系统中绝大多数或所有的对象

C.状态图适合用来描述多个对象的交互

D.状态图可以用于图形用户界面或控制对象

3.如图7.19所示为一个MortgageApplication的状态图。假设要加入一个新的需求：除了“Closed”状态，其他任何状态都能迁移到“Cancelled”状态。以下（）方法最好。

A.只从其中一个状态迁移到“Cancelled”状态

B.在图中增加“Cancelled”父状态

C.增加一个“Active”父状态来处理到“Cancelled”状态的迁移

D.从“Submitted”和“Qualified”到新的“Cancelled”状态都增加一个迁移

图7.19MortgageApplication的状态图

4.根据图7.20所示的状态图，回答问题。

图7.20线程的状态图

（1）该图中有几种状态，分别为_____________________________。

（2）请描述线程的基本运行过程_____________________________。

5.根据图7.21所示的手机状态图，描述手机的工作过程。

图7.21手机状态图

6.根据如下描述，绘制电梯状态图。

（1）电梯开始处于空闲（Idle）状态，当有人按下按钮要求使用电梯时（isrequired事件发生），电梯进入运行（Run）状态；

（2）如果电梯的当前楼层比想要的楼层高时（[currentFloor>desiredFloor]监护条件成立），电梯进入下降（MovingDown）状态；

（3）反之，如果电梯的当前楼层比想要的楼层低时（[currentFloor

（4）如果电梯的当前楼层与想要的楼层相同时（[else]监护条件成立），电梯门打开（DoorOpen）；

（5）在电梯上升或下降期间，每经过一个楼层就判断[currentFloor=desiredFloor]监护条件是否成立，若不成立，继续移动，若成立，就进入停止（Stop）状态，15秒后，电梯门自动打开（DoorOpen），2分钟后，电梯门自动关上（DoorClose），如果有更多的电梯使用请求，进入运行（Run）状态，反之，则进入空闲（Idle）状态。

7.绘制办公系统中打印机（printer）的状态图

8.绘制网上书店系统中订单（order）的状态图

1.绘制状态图时的错误提示

以绘制起点即使用【】为例，如果在操作过程中出现如图7.22所示的错误提示对话框，则说明操作有误。该错误提示的含义为：在上下文中已经定义了一个初始状态。出现这个错误是因为，起点在状态图中只允许有一个。

图7.22关于起点的错误提示

如果在同一个模型中绘制多个状态图，同时为了保证图形的完整性又想在每个状态图中都显示起点，该如何操作呢？具体步骤如下：首先，需要添加一个起点，该起点被添加后可以在RationalRose视图区域树型列表中显示出来，如图7.23所示；然后采用按住鼠标左键拖拽的方式，将起点从树型列表拖拽到编辑区即可。

图7.23视图区域树型列表

再以绘制转换即使用【】为例，如果在操作过程中出现如图7.24所示的错误提示对话框，则同样说明操作有误。图7.24中错误提示的含义为：状态转换必须用于状态之间的连接，否则非法。出现这个错误是因为，转换的起始端和终止端不是状态，或者是因为在绘制转换时起始点和终止点位置不够准确。

图7.24关于转换的错误提示

2.状态图工具栏

将状态图工具栏上的按钮名称及功能说明如下，详见表7.1。

表7.1状态图绘图工具栏

State

状态

StartState

起点

EndState

终点

StateTransition

状态转换

TransitiontoSelf

转换到自身状态

活动图（ActivityDiagram）是描述系统动态行为的常用工具之一，它强调从活动到活动的控制流。活动图与程序设计中的流程图非常相似，可以显示出一个过程的各个步骤。但与流程图不同的是，活动图在表示并发过程时显得尤为有用，而流程图则一般常用于表示串行过程。

活动图的应用非常广泛，可以用于对系统的工作流(Workflow)建模，即对系统的业务过程建模，比如进行用例分析等；也可以用于对具体的操作建模，比如进行计算过程的细节描述等。本章在全书知识体系中的位置如图8.1所示。

一般来讲，协作图包括如下几种构成元素：起点（Start）和终点（End），活动（Activity），转换（Transition），泳道（Swimlane），分支（Branch），分叉与汇合（ForkandJoin），对象流（ObjectFlow）。

起点是活动图的初始状态，也是活动图的起始位置，表示一个工作流的开始。起点只能作为转换（Transition）的源，而不能作为转换（Transition）的目标。起点在活动图中只允许有一个。活动图中起点的表示方法与状态图中起点的表示方法相同。

终点是活动图的最后状态，也是活动图的终止位置。与起点相反，终点只能作为转换（Transition）的目标，而不能作为转换（Transition）的源。终点在一个活动图中可以有一个或有多个，也可以没有。活动图中终点的表示方法与状态图中终点的表示方法相同。

活动表示一个工作流或一个过程中任务的执行，包括动作状态和活动状态。

动作状态是指执行原子的、不可中断的动作，并在此动作完成后通过转换转向另一个状态。在UML中，动作状态使用带圆端的矩形表示，动作状态的名称写在该矩形内部，如图8.2所示。

动作状态有如下特点：

（1）动作状态是原子的，无法分解；

（2）动作状态是不可中断的，一旦开始运行就一直运行到结束；

活动状态用于表示非原子的运行，可被进一步分解。

在UML中，活动状态的表示方法与动作状态相似，只是活动状态可以添加入口动作、出口动作、动作状态等，如图8.3所示。

活动状态有如下特点：

（1）活动状态可以分解成其他子活动或动作状态，由于它是一组不可中断的动作或操作的组合，所以可以被中断；

（2）活动状态的内部活动可以用另一个活动图来表示，如图8.4所示就是将“DeliverOrder”活动状态用另一个子活动图来表示。其中的“DeliverRush”和“DeliverRegular”可以认为是“DeliverOrder”的子活动。

图8.4活动的扩展

活动图中的转换用于描述两个活动之间的关系，表示一个活动执行完相应的操作后会自动转换到另一个活动。与状态图中不同的是，这种转换一般不需要特定事件的触发。

活动图中转换的表示方法与状态图中转换的表示方法相同，见图8.5中所示。

顾名思义，泳道原本是用来分隔游泳池的，以保证不同选手可以在指定区域中进行比赛，而彼此互不干扰。活动图中泳道的含义与此类似，每个泳道代表一个责任区，它将活动分为若干个组，并为每一组指定负责人或所属组织。借助泳道，可以在活动图中清晰描述负责活动的对象，明确表示出哪些活动是由哪些对象展开的。在加入泳道的活动图中，每个活动只能属于一个泳道。从语义上理解，泳道可以被认为是一个模型包。

在UML中，泳道被表示为纵向矩形，属于同一个泳道的活动均放在该矩形中。每个泳道必须有唯一的名字（实际上就是对象名）以区别于其他泳道，泳道的名字放在纵向矩形的顶部。泳道没有顺序号，不同泳道的活动可以是顺序执行的也可以是并发执行的。如图8.5所示的活动图中有两个泳道，分别是Student和System，其中“CompleteApplication”活动属于Student泳道，“CheckCourseAvailability”活动和“CheckApplicaionQualification”活动属于Systems泳道。

图8.5转换和泳道

分支也称判定，是软件系统流程中十分常见的一种结构。在活动图中，分支描述了对象在不同的判定结果下所执行的不同动作。通常，分支包括一个进入转换和两个（或多个）输出转换，即有一个入口和两个（或多个）出口。每个出口都应带有监护条件，当且仅当该监护条件成立时，相应的出口路径才有效。在所有的出口中，其监护条件必须互斥，而且应该尽量覆盖所有的可能性，这样才可以保证有且仅有一条输出转换能够被触发。

在UML中，分支被表示为菱形框。如图8.6所示，ReleaseWorkOrder（分配工作指令）活动执行完以后遇到分支，该分支有两个出口路径：其中一条输出转换到AssignTasks（执行任务）活动，监护条件是[materialsready]（材料准备齐全）；另一条输出转换到Reschedule（重新规划）活动，监护条件是[materialsnotready]（材料没有准备齐全）。

图8.6分支

在活动图建模的过程中，可能会遇到这样的情况：存在两个或多个并发执行的控制流。为了描述这种并发执行，在活动图中可以使用分叉和汇合。分叉用于将路径分解成多个并发执行的分支控制流，每个分叉包括一个进入转换和多个输出转换；汇合则用于将不同的分支汇集在一起，当所有分支控制流都达到汇集点后，控制流才能继续往下进行，每个汇合包括多个进入转换和一个输出转换。从概念上说，分叉的每一个控制流都是并发的，但实际应用中，这些控制流可以是真正的并发，也可以是时序交替的。

在UML中，分叉和汇合都被表示为比较粗的实线，该实线也称为同步条，分水平和垂直两种，如图8.7所示。

在活动图中可以出现对象作为活动的输入或输出，并用对象流表达对象与活动之间的依赖关系。

同前几章介绍的一样，在活动图中对象也用矩形符号表示，矩形内部是对象的名称或对象所属类的名称，在名称的下方还可以设置对象的状态。对象和活动之间的依赖关系即对象流使用带箭头的虚线表示，如图8.8所示。

图8.7分支与汇合

图8.8对象流

能够捕获“图书管理系统”中指定对象或指定用例的活动，并且使用RationalRose工具绘制出相应的活动图。

1.建立图书管理员对象的活动图，并使用RationalRose工具实现。

2.建立读者对象的活动图，并使用RationalRose工具实现。

4.建立借阅图书用例的活动图，并使用RationalRose工具实现。

（1）打开“Library”模型

（2）新建活动图

在视图区域树型列表中，右键单击【LogicalView】结点，然后在弹出的快捷菜单中选择【New】->【ActivityDiagram】，如图8.9所示。在此默认的活动图名称为“NewDiagram”，可以输入新的活动图名称为“LibrarianActivity”。双击该活动图，在RationalRose窗口内右侧空白处出现相应的编辑区，在编辑区中可进行后续操作。

图8.8新建活动图

（3）添加活动

在活动图工具栏中选择起点按钮【】即“StartState”，然后在编辑区中单击鼠标左键，便可以将初始活动添加到活动图中。如果在操作过程中出现如图8.9所示的错误提示对话框，则说明操作有误。该错误提示的含义为：在上下文中已经定义了一个初始状态。此时可以采用按住鼠标左键拖拽的方式，将已经存在的起点从左侧视图区域树型列表中拖拽到编辑区。

图8.9关于起点的错误提示

继续在活动图工具栏中选择起点按钮【】即“Activity”，然后在编辑区中单击鼠标左键，便可以将活动添加到活动图中。新添加的活动默认名称为“NewActivity”，可将其名称根据具体情况进行修改。简便的修改方法是直接在“NewActivity”处键入活动的新名称；稍复杂的修改方法是双击该活动打开“活动属性”对话框，或者右键单击该活动，在弹出的快捷菜单中选择【OpenSpecification】也可以打开“活动属性”对话框，如图8.10所示，在此将活动命名为“ProcessReturn”。如果还需要为活动设置入口/出口动作、动作等内容，可以双击“活动属性”对话框中的【Actions】选项卡，然后在中间空白区域任意位置右键单击，会弹出如图8.11所示的快捷菜单。在弹出的快捷菜单中选择【Insert】菜单项，可以添加动作，新添加的动作默认类型为“Entry”，默认名称为空。如果想修改动作的类型和名称，可以在图8.11所示的快捷菜单中选择【Specification】菜单项，打开如图8.12所示的“动作属性”对话框，在该对话框中进行详细的设置。

图8.10“活动属性”对话框

图8.11设置活动包含的动作

图8.12“动作属性”对话框

依照如上方法，分别创建出图书管理员对象活动：Query（查询）、ProcessReturn（处理还书）、ProcessBorrow（处理借阅）、Set（设置）、GetFine（收取罚金）、ReturnBook（收回图书）、GiveBook（借出图书）、Quit（退出）。

如果活动图还有终止活动，则可以在活动图工具栏中选择终点按钮【】即“EndState”，继而在编辑区中单击鼠标左键，便可以将终止活动添加到活动图中。

（4）添加分叉与汇合

由于Query（查询）、ProcessReturn（处理还书）、ProcessBorrow（处理借阅）、Set（设置）活动可以认为是并发执行的，所以还需要为这些活动添加分叉与汇合，具体操作方法描述如下。

在活动图工具栏中选择水平同步按钮【】即“HorizontalSynchronization”，然后在编辑区中单击鼠标左键，便可以将分叉与汇合添加到活动图中。如果想对分叉与汇合进行详细设置，还可以打开如图8.13所示的“同步属性”对话框，在此进行设置。

图8.13“同步属性”对话框

（5）添加分支

图书管理员在处理还书时，可能会出现这样的情况：如果读者超期还书，那么图书管理员要收取一定的罚金；如果读者按期还书，那么图书管理员直接收回图书即可。也就是说，对于“ProcessReturn”活动而言，可能出现分支。分支的一条路径会转换到“GetFine”活动，条件是“outofdate”；分支的另一条路径会转换到“ReturnBook”活动，条件是“no”。描述这种分支结构的操作方法很简单，只需在活动图工具栏中选择分支按钮【】即“Decision”，然后在编辑区中单击鼠标左键，便可以将分支添加到活动图中。关于分支的条件描述，则要借助添加转换来完成。

（6）添加转换

在活动之间、分叉与活动之间、活动与汇合之间、活动与分支之间都可以添加转换，来完成相应的过渡。以处理还书出现的具体情况为例，将操作方法描述如下。

在活动图工具栏中单击转换符号【】即“StateTransition”，然后采用按住鼠标左键拖拽的方式，首先将“ProcessReturn”活动和分支之间添加转换。然后，将分支与“GetFine”活动之间也添加转换，双击该转换，打开“状态转换属性”对话框，在该对话框中单击【Detail】选项卡，可以打开如图8.14所示的界面，在该界面中可以设置监护条件等内容。按照同样的方法，也可以在分支与“ReturnBook”活动之间添加相应的转换。

图8.14设置监护条件

经过以上各步骤，最终得到图书管理员对象活动图，如图8.15所示。

图8.15“LibrarianActivity”活动图

实际操作步骤与建立图书管理员对象活动图相似，使用RationalRose工具实现的“ReaderActivity”活动图，如图8.16所示。

图8.16“ReaderActivity”活动图

实际操作步骤与建立图书管理员对象活动图相似，使用RationalRose工具实现的“LoginActivity”活动图，如图8.17所示。

图8.17“LoginActivity”活动图

需要说明的是，该图中添加了泳道。具体方法是：在活动图工具栏中选择泳道符号【】即“Swimlane”，此时鼠标会变成十字形状，然后在编辑区相应位置单击即可。新添加的泳道默认名称为“NewSwimlane”，可以根据实际需要将名称修改，如修改为“Reader”。右键单击该泳道可以打开如图8.18所示的快捷菜单，在该快捷菜单中可以选择相应的菜单项以满足更多的操作需求，比如剪切、复制、删除泳道等。

图8.18关于泳道的快捷菜单

图8.19“BorrowBookActivity”活动图

以上各图中没有涉及对象流的内容，如果在活动图中需要添加对象流，可以首先在活动图工具栏中选择对象符号【】即“Object”，然后在编辑区中单击鼠标便可。新添加的对象默认名称为空，可以打开如图8.20所示的“对象属性”对话框进行名称修改，在此还可以为对象设置所属类以及状态等。在图8.20的【State】下拉类表中选择“New”可以打开如图8.21所示的“对象状态属性”对话框，在该对话框中可以定义对象的新状态。

图8.20“对象属性”对话框

图8.21“对象状态属性”对话框

添加完对象以后，可以使用对象流将对象与指定的活动相连接，使该对象作为活动的输入或输出。在活动图工具栏中选择对象流符号【】即“ObjectFlow”，然后采用按住鼠标左键拖拽的方式将对象与活动连接起来即可。

1.在UML中，用例可以进一步使用（）来详细描述。

A.类图（ClassDiagram）B.状态图（StateDiagram）

C.活动图（ActivityDiagram）D.对象图（ObjectDiagram）

2.在活动图中，（）可以把活动划分成若干个组，并将划分的组指定给相应的对象，进而能够明确地表示出哪些活动是哪些对象负责的。

A.分叉与汇合（ForkandJoin）B.泳道（Swimlane）

C.活动（Activity）D.对象流（ObjectFlow）

3.如图8.22所示为“网上求职招聘系统”中“搜索工作”用例的活动图，请根据图示回答以下问题。

图8.22“搜索工作”活动图

（1）在上图中，有几种不同的角色___________________________。

4.如图8.23所示为“汽车租赁系统”的整体活动图，请根据该图完成以下要求。

（1）结合系统活动图描述汽车租赁过程的各个步骤。

（2）使用RationalRose工具绘制该图。

图8.23“汽车租赁系统”活动图

4.根据如下描述，绘制出“乘坐电梯”的活动图。

（1）用户（user）想乘电梯，按下电梯外的按钮（pressbutton）；

（2）如果电梯在当前楼层，则电梯门打开（openthedoor）；否则，电梯移到当前楼层（liftmovetothecurrentfloor），然后电梯门打开；

（3）电梯门打开后，用户进入（enter），电梯门关闭（closethedoor）；

（4）用户按下想去的楼层按钮（pressdesiredfloorbutton）；

（5）电梯移到那个楼层（gotothefloor）；

（6）电梯门打开（thedooropen），用户离开（leave）；

（7）电梯门关闭（close）。

5.根据如下描述，绘制出“创建文档”的活动图。

（1）打开Word字处理软件包；

（2）新建一个文件；

（3）命名该文档并为该文档指定一个存放目录；

（4）键入文档的内容；

（5）如果文档中需要图形，则打开图形软件包，创建图形，将图粘贴到文档中；

（6）如果文档中需要电子表格，再打开电子表格软件包，建立电子表格，将电子表格粘贴到文档中；

（7）保存该文件；

（8）打印一份该文档的硬拷贝；

（9）退出Office软件包。

1.活动图工具栏

活动图工具栏上的按钮名称及功能，详见表8.1。

表8.1活动图工具栏按钮

Activity

活动

HorizontalSynchronization

水平同步条

VerticalSynchronization

垂直同步条

Decision

分支

Swimlane

泳道

ObjuectFlow

对象流

2.活动图与状态图的区别

（1）活动图和状态图描述的侧重点不同

活动图可以被认为是状态图的一个变种，但与状态图不同的是，活动图的主要目的是描述对象的活动以及执行完活动的结果。也就是说，活动图强调从活动到活动的控制流，当一个活动中的动作被执行完时，直接转换到下一个活动；而状态图强调的是对象的状态及状态之间的转换。

（2）活动图和状态图使用的场合不同

对于以下情况，如分析用例、理解涉及多个用例的工作流、处理多线程应用，适合使用活动图。

对于下面的情况，如显示一个对象在其生命周期内的行为，适合使用状态图。

换言之，活动图适合于描述多个对象和多个用例活动的总次序，状态图适合于描述跨越多个用例的单个对象的行为。

另外需要重申的是，如果要显示多个对象之间的交互情况，可以使用时序图或协作图。

3.活动图与流程图的区别

活动图能够表示并发活动的情形，而流程图不能。

活动图是面向对象的，流程图是面向过程的。

4.绘图活动图时的错误提示

以绘制活动即使用【】为例，如果在操作过程中出现如图8.24和图8.25所示的错误提示对话框，则说明操作有误。图8.24中错误提示的含义为：“Login”名称不合法，因为在上下文中已经存在了“Login”活动。图8.25中错误提示的含义为：将活动名称修改为“Quit”时产生冲突，因为已经存在了“Quit”。之所以产生上述错误，是因为给活动命名和修改名称时，出现了与已有名称冲突的情况，只需另换一个名称便可解决。如果非要使用这个名称，那么可以采用按住鼠标左键拖拽的方式，把在模型中已经存在（显示在左侧视图区域树型列表中）的活动拖拽到编辑区即可。

图8.24错误提示1

图8.25错误提示2

在软件系统的建模过程中，可以借助用例模型描述系统期望达到的功能，可以借助静态模型来描述系统中存在的事物及关系，可以借助动态模型描述事物的行为活动及相互协作。在这些工作都完成以后，开发人员需要把以上的逻辑结构转化为物理结构（如设计执行文件、库和文档等），也就是建立物理模型。在进行物理建模时，需要用到组件图（ComponentDiagram）和部署图（DeploymentDiagram）两种工具，组件图和部署图也统称为实现图。

RationalRose工具除支持前述的用例建模、静态建模、动态建模、物理建模之外，还支持持久层数据库建模即建立数据模型。它允许将UML静态模型用作逻辑模型，将数据模型用作物理模型，并帮助用户保持二者之间的同步。所以本章在实验环节中相应地加入了数据建模的内容。本章在全书知识体系的位置如图9.1所示。

组件图也称构件图，用于显示一组软件组件及它们之间的关系。也就是说，借助组件图可以显示组件的结构，可以显示编译、链接或执行时组件之间的依赖关系。通常，组件图包含三种构成元素：组件（Component）、接口（Interface）和关系（Relationship）。

1.组件（Component）

组件也称构件，是系统中可替换的物理部件，是定义了良好接口的物理实现模块。换言之，组件是遵从一组接口且提供其实现的、物理的、可替换的部分。如程序源代码、子系统、动态链接库、ActiveX控件、JSP页面等都可以被认为是组件。这些组件一般都包含很多类且实现许多接口。对于组件可以做一个形象的类比，那就是家庭娱乐系统，在该系统中人们可以轻易更新DVD播放机或扬声器，因为它们是系统中模块化的、可替换的部分，并且可以通过标准接口相互连接。

通常存在三种类型的组件：配置组件（DeploymentComponent）、工作产品组件（WorkProductComponent）、执行组件（ExecutionComponent）。

（1）配置组件：也称二进制组件，这些组件构成了一个可执行的系统，如DLL文件、EXE文件、COM+对象、CORBA对象、EJB、动态Web页、数据库表等。

（2）工作产品组件：也称源组件，这些组件属于开发过程产物，这些组件不直接参与可执行系统，而是开发中的工作产品，如源代码文件（.java，.cpp），数据文件等。

（3）执行组件：这类组件是作为一个正在执行的系统的结果而被创建的，例如由DLL实例化形成的.NET对象。

以人们玩电脑游戏的整个过程为例，可以简单理解上述三种类型的组件。当单击游戏图标开始游戏时，该图标所对应的EXE文件就是配置组件；在游戏结束时会打开存储用户信息的数据文件，用于保持当前的最好成绩，这些都是工作产品组件；游戏结束后，系统会把相应的成绩更新到用户数据文件，这时又可以算是执行组件。

在UML中，组件被表示为左侧带有两个突出小矩形的大矩形，大矩形内部书写组件名称，如图9.2所示。

图9.2组件

接口用于描述类或组件提供的服务。在组件图中，组件可以通过其他组件的接口使用其他组件中定义的操作。通过使用接口，可以避免系统中各个组件之间直接发生依赖关系，有利于组件的替换。与前面章节介绍过的一样，在UML中，接口被表示为一个圆；其扩展形式是被表示为一个构造型类。

组件的接口可以分为两类：导入接口（ImportInterface）和导出接口（ExportInterface）。导入接口供访问操作的组件使用，导出接口由提供操作的组件提供，如图9.3所示，NewInterface接口对于NewComponent1组件来说是导出接口，对于NewComponent2组件来说是导入接口。

图9.3接口

3.关系（Relationship）

在组件图中，组件和接口之间可以存在两种关系：依赖（Dependency）关系和实现（Realization）关系。如果组件使用接口，那么组件和接口之间存在依赖关系即组件依赖接口；如果组件实现接口，那么组件和接口之间存在实现关系即组件实现接口。每个组件可能使用一些接口，并实现另一些接口。如上图9.3所示表明NewComponent1组件实现NenInterface接口，NewComponent2组件依赖NenInterface接口。

另外，组件和组件之间可以存在依赖关系。如图9.4所示表明NewComponent1组件依赖NewComponent2组件。

图9.4组件之间的依赖关系

能够抽象出“图书管理系统”中的组件、接口及关系，并且使用RationalRose工具绘制系统组件图。能够结合“图书管理系统”静态模型，借助RationalRose工具进行持久层数据库建模，即绘制系统数据模型图。

1.抽象出“图书管理系统”中的组件、接口及关系。

2.使用RationalRose工具绘制“图书管理系统”组件图。

3.结合第4章的静态模型，借助RationalRose绘制“图书管理系统”数据模型图。

通过分析，确定“图书管理系统”中的组件有：MainProgram（主程序），SystemManage，Login，ReaderManage，BookManage，BorrowManage，FineManage，User.java，Login.java，Reader.java，Book.java，Reaserve.java，Borrow.java，Fine.java，Conn.java（用于数据库连接的java源文件）。以上各组件中有部分组件存在依赖关系，详见表9.1所示。

表9.1“图书管理系统”中组件间的关系

组件A

组件B

组件A和组件B之间的关系

MainProgram

依赖关系

User.java

Reader.java

Book.java

Borrow.java

Reserve.java

Fine.java

Conn.java

（2）新建组件图

在视图区域树型列表中，右键单击【ComponentView】结点，然后在弹出的快捷菜单中选择【New】->【ComponentDiagram】，如图9.5所示。在此默认的组件图名称为“NewDiagram”，可以输入新的组件图名称为“LibraryComponent”。双击该组件图，在RationalRose窗口内右侧空白处出现相应的编辑区，在编辑区中可进行后续操作。

图9.5新建组件图

（3）添加组件

在组件图工具栏中选择按钮【】即“MainProgram”，然后在编辑区中单击鼠标左键，便可以将主程序添加到组件图中。类似地，在组件图工具栏中选择按钮【】即“Component”，可以将组件添加到组件图中。新添加的组件默认名称为“NewComponent”，可在如图9.6所示的“组件属性”对话框中对其进行修改，同时还可以进行其他详细设置。

图9.6“组件属性”对话框

（4）添加关系

对于在模型中已经存在的接口（或类），可以建立其与组件之间的关系，具体操作方法有两种。

方法之一是：在“组件属性”对话框中选择【Realizes】选项卡，右键单击要建立关系的接口（或类），在弹出的快捷菜单中选择【Assign】，便可以建立组件和接口（或类）之间的关系，如图9.7所示；如果要取消组件和接口（或类）之间的关系，则可以右键单击要取消关系的类或接口，在弹出的快捷菜单中选择【RemoveAssign】。

方法之二是：创建了相应的组件后，采用按住鼠标左键拖拽的方式，从左侧视图区域中将相应的接口（或类）拖放到组件上，建立组件和接口（或类）之间的关系，通过【Realizes】选项卡可以查看到建立了关系的接口（或类）前面标记了一个红色的勾，同时在左侧视图区域中的接口（或类）也显示了与组件的关联性，如图9.8所示。

在具体的组件图中，还可以指定实现组件功能的文件，也就是建立组件和功能文件之间的关系，具体方法描述如下。在“组件属性”对话框中选择【Files】选项卡，然后在中间空白区域任意位置右键单击，会弹出如图9.9所示的快捷菜单，在弹出的快捷菜单中选择【InsertFile】菜单项，可以添加实现该组件功能的文件。若指定的文件存在，如D:\ch9temp\Login.java，双击该文件名可以查看文件的详细内容，如图9.10所示为Login.java文件的源代码。若指定的文件不存在，如D:\ch9temp\Conn.java，双击该文件名会弹出如图9.11所示的对话框，该对话框提示的含义为：Rose不能定位D:\ch9temp\Conn.java文件，您是否想要自己创建指定的文件？单击【是】按钮即可自行创建文件。

图9.7设置组件和接口（或类）的关系

图9.8组件和接口（或类）的关联

图9.9设置组件和功能文件之间的关系

图9.10查看Login.java文件内容

图9.11创建文件提示框

如前所述，组件和组件之间可以存在依赖关系，例如“图书管理系统”中的MainProgram组件依赖SystemManage组件。为描述这种关系，可以在编辑区工具栏中单击依赖关系符号【】即“Dependency”，采用按住鼠标左键拖拽的方式，将MainProgram组件和SystemManage组件连接起来。注意箭头应该指向SystemManage组件。

综合以上操作，完成“图书管理系统”组件图，如图9.12所示。

图9.12图书管理系统组件图

3.结合第4章静态模型，借助RationalRose工具绘制“图书管理系统”数据模型图。

RationalRose支持持久层的数据库建模，即可以借助该工具建立“数据模型”。在RationalRose中，数据模型不仅存在于逻辑视图（LogicalView）中，而且也存在于组件视图（ComponentView）中。在逻辑视图中，开发人员可以创建一个计划（Schema），然后在计划中创建表（table）、域（domain）。在组件视图中，开发人员可以进行数据库建模，数据库在组件视图中扮演<>组件角色。

接下来就以“图书管理系统”为例，说明建立数据模型的操作步骤。

（1）创建数据库

正常启动RationalRose，在视图区域树型列表中，右键单击【ComponentView】结点，然后在弹出的快捷菜单中选择【DataModeler】->【New】->【Database】，如图9.13所示。

图9.13创建数据库

新建的数据库默认名称为“DB_0”，如图9.14所示；右键单击该数据库，在弹出的快捷菜单中选择【OpenSpecification...】菜单项，可以打开“数据库属性”对话框，如图9.15所示，在该对话框中，可以修改数据库名称（如修改为“LibraryDatabase”）、设置数据库查询语言名称、设置建立的数据库类型（如ANSISQL92，IBMDB2，SQLServer2000，Oracle等）。

图9.14新建数据库的默认名称

（2）创建表空间

表空间（Tablespaces）是存储表的逻辑单元。不同类型的数据库，表空间充当的角色有所不同。创建表空间的具体步骤如下：选定已经创建好的“LibraryDatabase”数据库，右键单击该数据库，在弹出的快捷菜单中选择【DataModeler】->【New】->【Tablespaces】即可，如图9.16所示。

图9.15“数据库属性”对话框

图9.16创建表空间

（3）创建计划

计划（Schema）是数据模型的容器，所有的表、触发器、约束等数据模型元素都包含在这个容器中。在【ComponentView】组件视图中创建数据库后，【LogicalView】逻辑视图中会自动生成两个包，即GlobalDataTypes（全局数据模型包）和Schemas（计划包）。创建计划的具体步骤如下：

展开视图区域树型列表中的【LogicalView】结点，选择其下的Schemas（计划包），右键单击该包，在弹出的快捷菜单中选择【DataModeler】->【New】->【Schema】即可创建一个计划，如图9.17所示。新创建的计划默认名称为“S_0”，若要对计划进行详细设置，可以打开如图9.18所示的“计划属性”对话框完成相应操作。

图9.17创建计划

图9.18“计划属性”对话框

（4）创建数据模型图

计划创建完以后，就可以在计划内创建数据模型图（DataModelDiagram）了，进而可以在数据模型图中添加表和其他一些数据模型元素，这类似于静态模型中的类图。创建数据模型图的具体步骤如下：

图9.19创建数据模型图

图9.20数据模型图编辑窗口

（5）添加表及表之间的关系

打开“LibrarayDataModel”数据模型图，在编辑区工具栏中单击【】按钮即“Table”，然后在编辑区任意位置单击鼠标左键即可创建表。双击该表，可以打开“表属性”对话框，如图9.21所示。

图9.21“表属性”对话框

单击“表属性”对话框中的【Columns】选项卡，在中间空白处任意位置单击鼠标右键，在弹出的快捷菜单中选择【Insert】，可以添加表的一个列，如图9.22所示。对于列属性的详细设置可以在如图9.23所示的“列属性”对话框中定义。同时，表的索引、约束、触发器等都可以在“表属性”对话框中进行设置。

添加完表以后，可以进一步添加表之间的关系。在编辑区工具栏中单击【】按钮即“Non_identifyingRelationship”，然后将鼠标停放在编辑区任意位置，鼠标会变成箭头形状，箭头方向向上，此时采用按住鼠标左键拖拽的方式，将两个表之间连接起来即可建立关系。双击该关系，打开如图9.24所示的“关系属性”对话框，在该对话框中可以进行关系的详细设置，比如设置对应关系等。

结合“图书管理系统”的静态模型，可以得到该系统的数据模型图，截取其中部分内容见图9.25所示。

图9.22添加表的列

图9.23“列属性”对话框

图9.24“关系属性”对话框

图9.25“图书管理系统”部分数据模型图

（6）数据模型和对象模型的转换

如前所述，借助RationalRose可以由一个数据模型自动生成一个对象模型，同时也可以由一个对象模型自动生成数据模型，以保证数据的一致性。由数据模型生成对象模型的具体步骤如下：

首先，展开视图区域树型列表中的【LogicalView】结点，选择Schemas包下的“S_0”计划，右键单击该计划，在弹出的快捷菜单中选择【DataModeler】->【TransformtoObjectModel】，如图9.26所示。

图9.26生成对象模型

然后，可以在打开的“数据模型生成对象模型”对话框中，详细设置目标对象的包名及前缀，如图9.27所示，单击【OK】按钮即可生成对象模型。

图9.27“数据模型生成对象模型”对话框

经过上述操作，自动生成的“图书管理系统”部分对象模型如图9.28所示。类似地，也可以由对象模型生成数据模型。

图9.28“图书管理系统”部分对象模型图

（7）由数据模型导出数据库

最后，可以从数据模型中导出数据库或DDL（数据库定义语言）脚本，具体步骤如下：

展开视图区域树型列表中的【LogicalView】结点，选择Schemas包下的“S_0”计划，右键单击该计划，在弹出的快捷菜单中选择【DataModeler】->【ForwardEngineer...】，如图9.29所示。

图9.29导出数据库

选择以上菜单后，会弹出如图9.30所示的“导出数据库向导”对话框。

图9.30“导出数据库向导”对话框

单击【Next】按钮，进入如图9.31所示的对话框，在该对话框中可以选择所需要的数据库模型元素。

图9.31选择数据库模型元素

继续单击【Next】按钮，进入如图9.32所示的对话框，在该对话框中可以单击【Browse】按钮，选择保存DDL脚本的位置，此处将保存位置选定为“F:\图书管理系统数据模型”。

图9.32选择保存和执行DDL

继续单击【Next】按钮，进入如图9.33所示的对话框，在该对话框中单击【Finish】按钮完成操作。

图9.33操作完成

经过上述步骤后，可以得到“图书管理系统”的DDL脚本文件，如图9.34所示。

图9.34“图书管理系统”DDL脚本文件

导出的“LibraryDB.ddl”脚本文件具体内容如下：

CREATETABLEBook(

bookIDSMALLINTNOTNULL,

bookNameVARCHAR(30)NOTNULL,

pubIDSMALLINTNOTNULL,

authorSMALLINTNOTNULL,

priceSMALLINTNOTNULL,

quantitySMALLINTNOTNULL,

CONSTRAINTPK_Book2PRIMARYKEY(bookID)

);

CREATETABLEFine(

fineIDSMALLINTNOTNULL,

borrowIDSMALLINTNOTNULL,

CONSTRAINTTC_Fine16UNIQUE(borrowID),

CONSTRAINTPK_Fine4PRIMARYKEY(fineID)

CREATETABLEBorrow(

borrowTypeNameVARCHAR(3)NOTNULL,

CONSTRAINTPK_Borrow1PRIMARYKEY(borrowID)

CREATETABLEReader(

IDVARCHAR(10)NOTNULL,

borrowIDSMALLINT,

CONSTRAINTPK_Reader0PRIMARYKEY(ID)

CREATETABLEBookType(

bookTypeIDSMALLINTNOTNULL,

bookTypeNameVARCHAR(10)NOTNULL,

CONSTRAINTPK_BookType3PRIMARYKEY(bookTypeID)

ALTERTABLEBookTypeADDCONSTRAINTFK_BookType3FOREIGNKEY(bookID)REFERENCESBook(bookID)ONDELETENOACTIONONUPDATENOACTION;

ALTERTABLEFineADDCONSTRAINTFK_Fine7FOREIGNKEY(borrowID)REFERENCESBorrow(borrowID)ONDELETENOACTIONONUPDATENOACTION;

ALTERTABLEReaderADDCONSTRAINTFK_Reader5FOREIGNKEY(bookID)REFERENCESBook(bookID)ONDELETENOACTIONONUPDATENOACTION;

ALTERTABLEReaderADDCONSTRAINTFK_Reader6FOREIGNKEY(borrowID)REFERENCESBorrow(borrowID)ONDELETENOACTIONONUPDATENOACTION;

1.____________和___________是用于对面向对象系统进行物理方面建模的两种图形。

2.下列不属于组件类型的是（）。

A.调用时的组件B.编译时的源组件

C.链接时的二进制组件D.运行时的可执行组件

3.如图9.35所示为“商品导览系统”组件图，根据图示说明其中的组件、接口及关系。

图9.35“商品导览系统”组件图

1.组件图工具栏

组件图工具栏上的按钮名称及功能，详见表9.2。

表9.2组件图工具栏按钮

Component

组件

Dependency

SubprogramSpecification

子程序规范

SubprogramBody

子程序体

主程序

PackageSpecification

包规范

PackageBody

包体

TaskSpecification

任务规范

TaskBody

任务体

Database

数据库

2.组件和类之间的区别

类是逻辑抽象，组件是物理抽象。

组件是对其他逻辑元素，如类、协作(Collaboration)的物理实现。即组件是软件系统的一个物理单元。

类可以有属性和操作；而组件通常只有操作，而且这些操作只能通过组件的接口才能使用。

3.数据模型图工具栏

数据模型图工具栏上的按钮名称及功能，详见表9.3。

表9.3数据模型图工具栏按钮

Table

表

Non_identifyingRelationship

关系

IdentifyingRelationship

单向关系

Dependancy

部署图是为面向对象系统进行物理方面建模的两个工具之一，也称配置图或实施图，主要用于描述系统硬件的物理拓扑结构以及在此结构上执行的软组件。也就是说，借助部署图可以显示出计算节点的拓扑结构、通信路径、节点上运行的软组件等内容。

需要注意的是，一个系统模型只能有一个部署图。通常情况下，这个部署图由体系结构设计师、网络工程师、系统工程师来进行描述。

1.节点（Node）

节点是存在于运行时并拥有某些计算资源的物理元素，一般至少拥有一些内存，而且通常具有处理能力。节点包括两种类型：处理器（Processor）和设备（Device）。

处理器是具有处理能力的节点，即它可以执行组件，如服务器（Server）、客户机（Customer）等。

设备是无计算能力的外部设备，如调制解调器（Modem）、打印机（Printer）、扫描仪（Scanner）等。

在UML中，处理器和设备都被表示为一个附有名称的三维立方体，但代表处理器的三维立方体中有两个侧面带有阴影，如图9.36所示。

2.连接（Connection）

连接代表一种交流机制，常用于对节点间的物理通信路径或软件通信协议进行建模。

在UML中，连接被表示为一条实线，如图9.37所示。

图9.36处理器和设备

图9.37连接

能够抽象出“图书管理系统”中节点及连接，并且使用RationalRose工具绘制部署图。

1.抽象出“图书管理系统”中的节点及连接。

2.使用RationalRose工具绘制部署图。

通过分析，确定“图书管理系统”中的节点有：ApplicationServer（应用服务器）、Printer（打印机）、AdministratorPC（系统管理员PC机）、LibrarianPC（图书管理员PC机）、LibraryPC（图书馆内的自助PC机）、ReaderPC（读者PC机）、DatabaseSever（数据库服务器）。

显而易见，ApplicationServer（应用服务器）节点与其他各节点之间都存在连接。

（2）打开部署图

部署图并不需要创建，因为模型里面已经建立好了部署图，如图9.38所示，在视图区域树型列表中双击【DeploymentView】打开部署图即可，被打开的部署名称为“DeploymentDiagram”。

（3）添加节点

在部署图工具栏中选择按钮【】即“Processor”，然后在编辑区中单击鼠标左键，便可将处理器添加到部署图中。添加的处理器默认名称为“NewProcessor”，可在图9.39所示的“处理器属性”对话框中对其进行修改，同时还可以进行其他详细设置。在此处将处理器名称设置为“ApplicationServer”，节点类型设置为“Processor”。

图9.38打开部署图

图9.39“处理器属性”对话框

由于处理器具有一定的处理能力，所以在绘图时可以为其指明处理性能、处理进程、处理计划等内容。具体操作方法是：在“处理器属性”对话框中选择【Detail】选项卡，然后在其“Characteristic”栏中书写性能指标；继而在其“Processes:”栏中的空白区域右键单击，在弹出的快捷菜单中选择【Insert】菜单项添加进程，如图9.40所示。

默认情况下，为处理器添加的进程不显示，若要显示则需右键单击该处理器，在弹出的快捷菜单中选择【ShowProcesses】菜单项，如图9.41所示。

类似地，在部署图工具栏中选择按钮【】即“Device”，便可以将设备节点添加到部署图中。

图9.40为处理器添加处理内容

图9.41显示处理器的处理内容

（4）添加连接

参照前面的分析，ApplicationServer节点和AdministratorPC节点之间存在连接，为刻画这种关系，需要在编辑区工具栏中单击连接符号【】即“Connection”，采用按住鼠标左键拖拽的方式，将ApplicationServer节点和AdministratorPC节点连接起来。

若要为连接指定更详细的内容，如连接名称和连接类型等，则可以在如图9.42所示的“连接属性”对话框中进行设置。

图9.42“连接属性”对话框

此处将连接类型设置为“10/100/1000MEthernet”（10/100/1000M自适应以太网），设置完的效果如图9.43所示。

图9.43显示连接类型

按照同样的方法，可以建立ApplicationServer节点与Printer（打印机）、ApplicationServer节点与LibrarianPC（图书管理员PC机）、ApplicationServer节点与LibraryPC（图书馆内的自助PC机）、ApplicationServer节点与ReaderPC（读者PC机）、ApplicationServer节点与DatabaseSever（数据库服务器）各节点间的连接。

综合以上操作，最终完成“图书管理系统”部署图，如图9.44所示。

图9.44“图书管理系统”部署图

1.在UML部署图中，具有计算能力的节点、能够执行软组件的节点，通常被称为_____________。

2.以下各项不属于设备节点的是（）。

A.扫描仪（Scanner）B.计算机（Computer）

C.打印机（Printer）D.调制解调器（Modem）

3.如图9.45所示为家用计算机系统部署图，请根据图示说明该系统中的处理器节点、设备节点、连接。

图9.45家用计算机系统部署图

1.处理计划（Scheduling）中各选项的含义

如前所述，在为处理器指定处理性能、处理进程的同时，还可以指定处理计划。现将处理计划各选项（即在图9.40所示的对话框中“Scheduling”栏各选项）的含义说明如下，详见表9.4所示。

表9.4处理计划中选项的含义

选项

Preemptive

高优先级的进程可以抢占低优先级的进程

NonPreemptive

进程没有优先级，按顺序执行进程

Cyclic

Executive

通过算法控制进程的执行

Manual

进程的执行由用户手工控制

2.部署图工具栏

部署图工具栏上的按钮名称及功能，详见表9.5。

表9.5部署图工具栏按钮

Processor

处理器

Connection

连接

Device

设备

3.绘制部署图时的错误提示

以绘制连接即使用【】为例，如果在操作过程中出现如图9.46所示的错误提示对话框，则说明操作有误。该错误提示的含义为：非法的连接关系，连接只能用于节点之间。出现这个错误是因为连接的起始端和终止端不是节点，或者是因为在绘制连接时起始点和终止点位置不够准确。

图9.46关于连接的错误提示

双向工程包括正向工程和逆向工程。正向工程指的是从UML模型生成具体语言代码的过程；而逆向工程则与此相反，指的是从具体语言代码生成UML模型的过程。无论是从代码到模型，还是从模型到代码，都是一项复杂的工作。RationalRose建模工具将二者有机地整合在了一起，提供了模型框架与代码框架进行双向交换的机制。本章在全书知识体系中的位置如图10.1所示。

对一个Java模型元素进行正向工程时，模型的特征会映射为对应的Java语言的特征。比如RationalRose类图中的一个类会通过组件生成一个.java文件；RationalRose中的包会生成Java中的一个包。

利用RationalRose工具的正向工程，以“图书管理系统”为例，将其类模型中的Admin类、Librarian类等，生成Java源代码。

1.设置模型的缺省语言为Java。

2.设置类路径和代码生成属性。

3.对“图书管理系统”模型进行语法检查。

4.将“图书管理系统”类图生成Java源代码。

5.浏览代码。

在主菜单栏中选择【Tools】->【Options...】菜单，然后在弹出的窗口中选择【Notation】选项卡，在该选项卡的“Default”栏下拉列表中选择“Java”作为模型的缺省语言，确定即可，如图10.2所示。

图10.2设置缺省语言

在主菜单栏中选择【Tools】->【Java/J2EE】->【ProjectSpecification】菜单，然后在弹出的“工程属性”对话框中选择【Classpath】选项卡可以为模型指定一个Java类路径，如图10.3所示。

图10.3设置Classpath

在生成代码之前，可以采用手动方式对模型组件进行语法检查。在生成代码时，RationalRose会自动进行语法检查。此步骤为可选步骤，具体方法描述如下。

图10.4设置CodeGeneration

表10.1代码生成属性中各选项的含义

IDE

DefaultDataTypes

设置缺省数据类型

Prefixes

设置实例和类变量是否使用缺省前缀

GenerateRoseID

设置是否添加唯一的RoseID标识符

GenerateDefaultReturnLine

StoponError

设置是否遇到错误时停止生成代码

CreateMissingDirectories

指定是否生成没有定义的目录

AutomaticSynchronizationMode

自动保持代码与模型同步

ShowProgressIndicator

指定在遇到复杂同步时显示进度栏

SourceCodeControl

指定对哪些文件进行源代码控制

InputCheckin/Checkoutcomment

指定用户是否需要对检入/检出代码的活动进行说明

SelectSourceRootPathforSourceControl

选择代码的存放路径

（1）打开包含用于生成代码的模型图。

启动RationalRose后，首先打开“Library”模型，然后在左侧视图区域树型列表中展开【LogicalView】逻辑视图，进一步打开该视图下的“LibraryClass”类图。在该类图中存在两个包，即BusinessPackage和GUIPackage，双击每个包打开其中的类模型图即可。

（2）检查模型

在主菜单中选择【Tools】->【CheckModel】，从日志窗口中观察错误提示。如果有错误，信息将显示在日志窗口中，如图10.5所示。

图10.5检查模型

（3）检查访问问题

如果要发现访问（如寻找不同包中两个类之间是否存在关系）问题，可以在主菜单中选择【Report】->【ShowAccessViolations】来进行检查，访问窗口将提示是否存在问题，如图10.6所示。

（4）检查语法

在主菜单中选择【Tools】->【Java/J2EE】->【SyntaxCheck】，可以进行语法检查，如图10.7所示。

图10.6检查访问问题

图10.7检查语法

对于模型语法检查中存在的问题，可以进行更正，以保证语法正确。

在打开的类图中，选定要生成Java源代码的类（如Admin类及其子类Librarian），然后在主菜单中选择【Tools】->【Java/J2EE】->【GenerateCode】，如图10.8所示。

图10.8生成代码

接下来在弹出的“指定类路径入口”对话框中指定保存Java源代码的路径以及包名等内容，最后确定即可。如图10.9所示，此处指定保存源代码路径为“D:\Rose&Java”，包名为“BusinessPackage”。

图10.9指定类路径入口

代码生成以后，可以在保存路径中找到对应的Java源文件，如图10.10所示为生成的Admin.java文件和Librarian.java文件。

图10.10定位Java源文件

与此同时，可以浏览Admin.java文件的详细代码：

//Sourcefile:D:\\Rose&Java\\BusinessPackage\\Admin.java

packageBusinessPackage;

publicclassAdmin

/**

*@roseuid4D523D380242

publicAdmin()

另外，还可以通过浏览Librarian.java文件的详细代码，确定RationalRose是否在生成的代码中保持了模型中原有的继承关系，子类Librarian源代码如下：

//Sourcefile:D:\\Rose&Java\\BusinessPackage\\Librarian.java

publicclassLibrarianextendsAdmin

privateintlibID;

privateintlibName;

privateintlibPassword;

*@roseuid4D523D3801D4

publicLibrarian()

*@roseuid4D33EE8D037A

publicvoidmanageBook()

*@roseuid4D33EE95034B

publicvoidmanageReader()

*@roseuid4D33EE9D036B

publicvoidmanageFine()

*@roseuid4D33EEF101D4

publicvoidmanageBorrow()

*@roseuid4D33EF250119

publicvoidquery()

1.从UML模型生成代码框架的过程称为___________工程。

2.在RationalRose选择【Tools】->【Java/J2EE】菜单实现正向工程时，选择下列哪一项，可以实现代码生成功能。

A.EditCodeB.SyntaxCheck

C.ProjectSpecificationD.GenerateCode

3.利用RationalRose正向工程，将第4章4.2.5测试能力目标中10、11、12题的类图生成Java源代码。

利用RationalRose正向工程，将UML模型生成语言代码时，并不是所有语言都被支持。一般情况下，在【Tools】的子菜单中可以查看RationalRose所支持的模型语言，如果在其子菜单中没有列举出全部的语言种类，还可以选择主菜单中【Add-Ins】->【Add-InManage】，在弹出的“插件管理器”对话框中，设置显示或隐藏各种语言的生成菜单，如图10.11所示。

图10.11语言选择界面

通过观察发现，插件管理器中并未列举出C#语言，如果要实施C#语言的正向工程，需要选择其他建模工具。

逆向工程能够从现有的语言代码生成UML模型（如类图、组件图、数据模型图等），这对达到设计模型和实现模型的同步大有益处；尤其是在为大型软件系统做二次开发时，开发人员可以利用逆向工程生成的模型，来更好地了解系统原来的组织结构，以方便团队内部讨论以及制定改进方案。

RationalRose建模工具所支持的逆向工程拥有非常强大的功能，它不仅支持多种编程语言（如C++、VB、VC、Java、CORBA等）；而且还支持多种数据库（如SQLServer、Oracle、DB2、Sybase等）。

利用RationalRose工具的逆向工程，以“图书管理系统”为例，将已有的Java源代码（即正向工程中得到的源代码）生成类模型。

1.检查类路径。

2.加载“图书管理系统”源代码。

3.生成“图书管理系统”类图。

（1）选择Java逆向工程。

启动RationalRose后，在主菜单中选择【Tools】->【Java/J2EE】->【ReverseEngineer】，如图10.12所示，继而可以打开“Java逆向工程”对话框，如图10.13所示。

图10.12选择Java逆向工程

图10.13“Java逆向工程”对话框

（2）加载指定的Java源代码

在“Java逆向工程”对话框中，选择Java源代码所存放的路径及待加载的文件。此处首先选择“D:\Rose&Java\BusinessPackage”中的Admin.java，Administrator.java，Librarian.java三个文件，然后单击【Reverse】按钮，执行从代码到模型的逆向转换，如图10.14所示。

图10.14生成的类

采用按住鼠标左键拖拽的方式，将生成的类从左侧视图区域拖放到右侧绘图区域，便可以得到相应的类图，如图10.15所示为Admin类、Administrator类和Librarian.java类构成的类图。遵循同样的方法，能够得到“图书管理系统”的完整类图。

1.在软件的迭代开发周期中，通常采用___________达到设计模型与实现模型的同步。

2.下列关于正向工程和逆向工程的描述，错误的是（）。

A.正向工程是把模型转换为代码的过程。

B.逆向工程是把代码转换为模型的过程。

C.正向工程是把代码转换为模型的过程。

D.逆向工程是把模型转换为代码的过程。

E.正向工程和逆向工程都可以通过RationalRose工具来实现。

3.应用Java语言编写一个简单的学籍管理系统，并借助RationalRose工具实施逆向工程，将其中的Java源代码转换成UML模型。

图10.15生成的类图

1.逆向工程中类属性的表现形式

利用RationalRose实施逆向工程时，类的属性可能表现为如图10.16左图的形式，即在“String”类型前附加了“LogicalView::java::lang::”前缀，该前缀指明了视图名称和包名称，实际应用时可根据具体情况选择是否删除该前缀。删除后的表现形式更为简洁，如图10.16右图所示。

图10.16属性的表现形式

2.逆向工程中的错误提示

在进行逆向工程时，如果RationalRose弹出如图10.17所示的错误提示框，则说明操作有误，该错误提示的含义为：在实施逆向工程时发生错误，详情见Rose日志窗口。单击【确定】按钮后，在日志窗口中可以查看错误详情提示，如图10.18所示。一般情况下，该问题可以通过检查类路径、包路径及Java源文件的正确性来解决。

图10.17关于逆向工程的错误提示

图10.18日志窗口中的错误详情提示

BBS（BulletinBoardSystem，电子公告牌系统）俗称论坛系统，是互联网上一种交互性极强、网友喜闻乐见的信息服务形式。根据相应的权限，论坛用户可以进行浏览信息、发布信息、回复信息、管理信息等操作，从而加强不同用户间的文化交流和思想沟通。

其中各基本模块的功能大体说明如下：

（2）版块管理主要包括增加版块、编辑版块、删除版块等功能。

（3）帖子管理主要包括发布帖子、回复帖子、浏览帖子、转移帖子、编辑帖子、删除帖子、帖子加精、帖子置顶等功能。

另外，需要说明的是，以上各项功能中有些功能只需要普通用户权限就能够完成，而有些功能则需要版主或管理员权限才能完成。

结合前述需求分析，可以得出论坛系统的总体结构图，如图11.2所示。

图11.2“BBS论坛系统”总体结构图

1.用例建模

（1）分析系统参与者。

（2）分析系统用例，并使用自然语言对主要用例进行文档阐述。

（3）分析系统用例模型中的关系。

（4）借助RationalRose工具绘制出“BBS论坛系统”用例图。

2.静态建模

（1）识别系统中的类，并根据实际情况确定类的属性和操作。

（2）识别系统中各类之间的关系。

（3）借助RationalRose工具绘制出“BBS论坛系统”类图。

3.动态建模

（1）识别系统中既定场景的对象、消息等要素，并借助RationalRose工具绘制出相应的时序图。

（2）识别系统中既定场景的对象、消息等要素，并借助RationalRose工具绘制出相应的协作图，或将现有的时序图转换成协作图。

（3）捕获系统中指定对象的状态，并借助RationalRose工具绘制出相应的状态图。

（4）捕获系统中指定对象或指定用例的活动，并借助RationalRose工具绘制出相应的活动图。

4.物理建模

（1）分析系统中的组件及组件间的关系，并借助RationalRose工具绘制出“BBS论坛系统”组件图。

（2）结合静态模型，借助RationalRose工具绘制“BBS论坛系统”数据模型图。

（3）分析系统中的节点及节点间的连接，并借助RationalRose工具绘制出“BBS论坛系统”部署图。

5.双向工程

（1）利用RationalRose工具的正向工程，将“BBS论坛系统”的类模型生成相应的Java源代码。

（2）利用RationalRose工具的逆向工程，将“BBS论坛系统”已有的Java源代码（即正向工程中得到的源代码）生成类模型。

遵循识别参与者的方法，可以初步分析出“BBS论坛系统”中的主要参与者有：AnonymousUser（匿名用户）、Member（注册用户）、Editor（版主）、Administrator（管理员），如图11.2所示。

图11.2“BBS论坛系统”的参与者

AnonymousUser（匿名用户）：通过使用系统进行帖子搜索、帖子浏览等。

Member（注册用户）：通过使用系统进行帖子搜索、帖子浏览、帖子发布、帖子回复、帖子编辑以及个人信息修改等。

Editor（版主）：除拥有普通用户的职责外，还可以通过使用系统进行版块管理、公告发布等。

Administrator（管理员）：除拥有普通用户的职责外，还可以通过使用系统进行用户管理、帖子管理、版块管理、公告管理等。

表11.1“BBS论坛系统”用例说明

功能描述

输入内容

输出内容

SearchArticle

根据需要搜索帖子

搜索条件

符合搜索条件的帖子

BrowseArticle

浏览任意版块帖子

选择任意话题帖子

该话题帖子及其回复

检测注册信息

用户名等注册信息

注册结果（是否成功）

合法用户通过验证进入系统

用户名、密码

IssueArticle

根据需要发布帖子

用户的言论

ReplyArticle

回复已存在的话题帖子

用户的回复

ModifyArticle

修改曾经发过的帖子

修改的内容

修改后的内容

ModifyInfo

根据当前状况修改个人信息

修改的信息

修改信息（是否成功）

DisplaceArticle

根据实际情况移动帖子位置

“移动”命令

移动结果（是否成功）

DeleteArticle

删除违规帖子

“删除”命令

删除结果（是否成功）

PlacePeak

将重要话题帖子放置于最上方

“置顶”命令

添加置顶图标的帖子

ExtractArticle

将重要话题帖子列为精华帖子

“加精”命令

添加加精图标的帖子

AddEdition

添加版块、设置版主

版块列表

ModifyEdition

修改版块信息

版块的修改信息

修改结果（是否成功）

DeleteEdition

删除版块

AddLink

友情网站的信息

友情网站的链接

ModifyLink

DeleteLink

AddAdvertise

DeleteAdvertise

显然，四个参与者即AnonymousUser（匿名用户）、Member（注册用户）、Editor（版主）、Administrator（管理员）之间依次存在泛化关系。

（4）借助RationalRose工具绘制出“BBS论坛系统”用例图

根据以上分析，借助RationalRose工具绘制系统参与者之间的关系，如图11.3所示；绘制AnonymousUser（匿名用户）与其关联的用例之间的关系，如图11.4所示；绘制Member（注册用户）与其关联的用例之间的关系，如图11.5所示；绘制Editor（版主）与其关联的用例之间的关系，如图11.6所示；绘制Administrator（管理员）与其关联的用例之间的关系，如图11.7所示；最后，得到“BBS论坛系统”总体用例图，如图11.8所示。

图11.3系统参与者之间的关系

图11.4匿名用户与其关联的用例

图11.5注册用户与其关联的用例

图11.6版主与其关联的用例

图11.7管理员与其关联的用例

图11.8“BBS论坛系统”用例图

基于MVC三层架构的思想，将系统中的类按照实体类、边界类、控制类来划分。

图11.9系统中的实体类

其中边界类有：index.jsp，user.jsp，article.jsp，edition.jsp，link.jsp，advertise.jsp，如图11.10所示。

图11.10系统中的边界类

其中控制类有：UserServelet，ArticleServlet，EditionServlet，LinkServlet，AdvertiseServlet，如图11.11所示。

图11.11系统中的控制类

分析得出“BBS论坛系统”中各个类之间关系如表11.2所示。

表11.2系统中各类之间的关系

User

user.jsp

UserServlet

UserData

Conn

article.jsp

ArticleServlet

ArticleData

Article

Edition

edition.jsp

EditionServlet

EditionData

link.jsp

LinkServelet

LinkData

Link

advertise.jsp

AdvertiseServlet

AdvertiseData

Advertise

index.jsp

图11.12ManageUser子图

图11.13ManageArticle子图

图11.14ManageEdition子图

图11.15ManageLink子图

图11.16ManageAdvertise子图

图11.17ManageModule子图

图11.18“Login”的处理流程

图11.19“Login”时序图

图11.20“AddEdition”的处理流程

根据以上处理流程，得出“AddEdition”（增加版块）场景时序图，如图11.21所示。

图11.21“AddEdition”时序图

此处以Member（注册用户）对象、Article（帖子）对象、Edition（版块）对象为例，绘制其状态图。

最终得到注册用户的状态图如图11.24所示，帖子的状态图如图11.25所示，版块的状态图如图11.26所示。

图11.22“Login”协作图

图11.23“AddEdition”协作图

图11.24注册用户的状态图

图11.25帖子的状态图

图11.26版块的状态图

以捕获“SearchArticle”（搜索帖子）用例的活动为例，绘制“SearchArticle”活动图如图11.27所示。

图11.27“SearchArticle”活动图

再以捕获“DeleteEdition”（删除版块）用例的活动为例，绘制“DeleteEdition”活动图如图11.28所示。

图11.28“DeleteEdition”活动图

以上各组件中有部分组件存在依赖关系，详见表11.3所示。

表11.3“BBS论坛系统”中组件间的关系

BBSSystem

ManagerUser

ManageArticle

ManageEdition

ManageLink

ManageAdvertise

最终完成“BBS论坛系统”组件图，如图11.29所示。

图11.29“BBS论坛系统”组件图

借助RationalRose工具绘制“BBS论坛系统”数据模型图，如图11.30所示。

图11.30“BBS论坛系统”数据模型图

另外，还可以从以上数据模型中导出数据库或DDL（数据库定义语言）脚本，导出的“BBS_DB.ddl”脚本文件具体内容如下：

CREATETABLELink(

linkIDSMALLINTNOTNULL,

linkNameVARCHAR(20)NOTNULL,

linkURLVARCHAR(80)NOTNULL,

CONSTRAINTPK_Link5PRIMARYKEY(linkID)

CREATETABLEAdministrator(

adminIDSMALLINTNOTNULL,

adminNameVARCHAR(20)NOTNULL,

adminPasswordVARCHAR(20)NOTNULL,

CONSTRAINTPK_Administrator1PRIMARYKEY(adminID)

CREATETABLEArticle(

articleIDSMALLINTNOTNULL,

articleNameVARCHAR(16)NOTNULL,

articleContentVARCHAR(500)NOTNULL,

editionIDSMALLINTNOTNULL,

CONSTRAINTPK_Article3PRIMARYKEY(articleID)

CREATETABLEEdition(

editionInfoVARCHAR(500)NOTNULL,

editionNameVARCHAR(116)NOTNULL,

CONSTRAINTPK_Edition4PRIMARYKEY(editionID)

CREATETABLEAdvertise(

advertiseIDSMALLINTNOTNULL,

advertiseNameVARCHAR(20)NOTNULL,

advertiseWordVARCHAR(100)NOTNULL,

CONSTRAINTPK_Advertise6PRIMARYKEY(advertiseID)

CREATETABLEUser(

userIDVARCHAR(20)NOTNULL,

userNameVARCHAR(20)NOTNULL,

userPasswordVARCHAR(20)NOTNULL,

userGradeVARCHAR(1)NOTNULL,

CONSTRAINTPK_User0PRIMARYKEY(userID)

ALTERTABLEArticleADDCONSTRAINTFK_Article6FOREIGNKEY(editionID)REFERENCESEdition(editionID)ONDELETENOACTIONONUPDATENOACTION;

通过分析，确定“BBS论坛系统”中的节点有：ApplicationServer（应用服务器）、DatabaseSever（数据库服务器）及若干个Customer（客户机）。

借助RationalRose工具绘制“BBS论坛系统”部署图，如图11.31所示。

图11.31“BBS论坛系统”部署图

借助RationalRose的正向工程将类模型生成代码以后，可以在保存路径中找到对应的Java源文件，如图11.32所示。

浏览Administrator.java文件的详细代码：

//Sourcefile:D:\\Rose&Java\\Administrator.java

publicclassAdministratorextendsUser

privateintadminID;

privateintadminName;

privateintadminPassword;

*@roseuid4D622F1902EE

publicAdministrator()

图11.32生成Java源文件

*@roseuid4D5C9989036B

publicvoidsetAdminID()

*@roseuid4D5C98D6032C

publicvoidgetAdminID()

*@roseuid4D5C99B701B5

publicvoidsetAdminName()

*@roseuid4D5C98DF0203

publicvoidgetAdminName()

*@roseuid4D5C99BD02FD

publicvoidsetAdminPass()

*@roseuid4D5C99C90290

publicvoidgetAdminPass()

读者可参照第10章双向工程的介绍自行练习，将“BBS论坛系统”已有的Java源代码生成类模型。

选择一个熟悉的软件系统（如“学生管理系统”、“教务管理系统”等），借助RationalRose工具，按照“用例建模”、“静态建模”、“动态建模”、“物理建模”、“双向工程”的顺序对其进行UML建模。

1.传统的瀑布开发模型

最早的软件开发模型是1970年提出的瀑布模型，而后随着软件工程学科的发展和软件开发实践的推进，又相继出现了原型模型、演化模型、增量模型、喷泉模型等。瀑布模型将软件生命周期划分为八个阶段：问题定义、可行性研究、需求分析、总体设计、详细设计、编码实现、测试运行、使用维护，如图11.33所示。其中各个阶段的工作按顺序开展，上一个阶段的工作成果是下一个阶段的工作前提。

不难看出，瀑布模型规定了一个标准流程，整个软件开发过程严格按照这个流程来实施，有效避免了盲目、混乱局面的出现。但是也必须看到，瀑布模型仍有其与生俱来的局限性。因为它要求在软件开发的初始阶段就捕获用户的全部需求，这显然是十分困难的，甚至是不切实际的。另外，在需求确定以后，如果用户临时提出变更需求，那么瀑布模型由于其不可回溯性也将不能灵活应对。

图11.33瀑布模型

2.RUP的迭代开发模型

RUP（RationalUnifiedProcess，统一软件过程）是由Rational公司推出的软件开发模型框架，它吸收了多种开发模型的优点，具有良好的操作性和实用性。

图11.34RUP开发模型

从上图可以看出，RUP将软件生命周期划分为四个阶段：Inception（初始）阶段、Elaboration（细化）阶段、Construction（构造）阶段、Transition（交付）阶段。

（1）Inception（初始）阶段

初始阶段是项目的基础阶段，该阶段的主要参与人员是项目经理和系统设计师。初始阶段的目标是对系统进行可行性分析、创建基本需求、识别软件系统的关键任务。

（2）Elaboration（细化）阶段

细化阶段的目标是创建可执行的构件基准、精化风险评估、定义质量属性、捕获大部分的系统功能需求用例，为构造阶段创建详细的计划。细化阶段是开发过程中最重要的阶段。细化的焦点是需求、分析和设计工作流。

（3）Construction（构造）阶段

构造阶段的目标是完成所有的需求、分析和设计。细化阶段的成果将演化为最终系统，构造的主要问题是维护系统框架的完整性。构造的焦点是实现工作流。

（4）Transition（交付）阶段

交付阶段的目标是将完整的系统部署到用户所处的环境。交付的内容包括修复系统缺陷、为用户环境准备新软件、创建用户使用手册和系统文档、提供用户咨询。

RUP的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，即最终产品的子集，它增量式地发展（从一个迭代过程到另一个迭代过程），直到成为最终的软件系统。

与传统的瀑布模型相比，RUP的迭代模型降低了开发风险，因为开发人员重复某个迭代承担的只是本次迭代的开发风险。另外，与传统的瀑布模型相比，RUP的迭代模型加快了开发进程，因为开发人员清楚问题的焦点所在，这样使得工作更有效率。

极速发展的时代，企业对于人才的需求突飞猛进。“基于Web的求职招聘系统”正是在这样的背景下应运而生的，它为求职者和招聘者提供了一个虚拟化、智能化的人才市场，其主要目的是为了拉近求职者和应聘者之间的距离，以便于求职者能够找到合适的工作，招聘者能够找到合适的人才。当用户进入该系统时，可以根据各自的需求和权限注册为求职者、招聘者以及管理员，然后行使系统为其提供的相应功能。

经过调查分析，最终确定“基于Web的求职招聘系统”的基本模块有：求职模块、招聘模块、管理模块。其中各基本模块的功能大体说明如下：

（3）管理模块主要包括更新管理员资料、管理求职者、管理招聘者、管理新闻等功能。

结合前述需求分析，可以得出论坛系统的总体结构图，如图11.35所示。

图11.35“基于Web的求职招聘系统”总体结构图

（2）分析系统用例。

（4）借助RationalRose工具绘制出“基于Web的求职招聘系统”用例图。

（3）借助RationalRose工具绘制出“基于Web的求职招聘系统”类图。

（1）分析系统中的组件及组件间的关系，并借助RationalRose工具绘制出“基于Web的求职招聘系统”组件图。

（2）结合静态模型，借助RationalRose工具绘制“基于Web的求职招聘系统”数据模型图。

（3）分析系统中的节点及节点间的连接，并借助RationalRose工具绘制出“基于Web的求职招聘系统”部署图。

（1）利用RationalRose工具的正向工程，将“基于Web的求职招聘系统”的类模型生成相应的Java源代码。

（2）利用RationalRose工具的逆向工程，将“基于Web的求职招聘系统”已有的Java源代码（即正向工程中得到的源代码）生成类模型。

遵循识别参与者的方法，可以初步分析出“基于Web的求职招聘系统”中的主要参与者有：User（用户）、Seeker（求职者）、Inviter（招聘者）、Administrator（管理员），如图11.36所示。其中User（用户）是为了实际需要，抽象出来的参与者。

图11.36“基于Web的求职招聘系统”的参与者

下面给出ModifyInfo（更新资料）用例的阐述文档，其余用例阐述文档读者可以通过自行练习来完成。

---------------------------------------------------------------------------------------------------------------------

用例编号：003

用例名称：ModifyInfo

涉及的参与者：User（用户）

用例概述：用户针对当前的实际情况，修改了个人资料

后置条件：用户资料更新成功，新的个人资料生效

2.用户发出更新资料请求

3.系统接受请求，并提示用户输入新的资料

4.用户输入新的个人资料并确认

5.系统显示更新后的用户资料

1a.资料格式输入有误

1a1.系统提示用户输入信息有误，提供正确的格式范例

另外，还可以确定参与者User（用户）和Seeker（求职者）、Inviter（招聘者）、Administrator（管理员）之间依次存在泛化关系。

根据以上分析，借助RationalRose工具绘制User（用户）与其关联的用例之间的关系，如图11.37所示；绘制Seeker（求职者）与其关联的用例之间的关系，如图11.38所示；绘制Inviter（招聘者）与其关联的用例之间的关系，如图11.39所示；绘制Administrator（管理员）与其关联的用例之间的关系，如图11.40所示；绘制系统参与者之间的关系，如图11.41所示；最后，得到“基于Web的求职招聘系统”总体用例图，如图11.42所示。

图11.37用户与其关联的用例

图11.38求职者与其关联的用例

图11.39招聘者与其关联的用例

图11.40管理员与其关联的用例

图11.41系统参与者之间的关系

图11.42“基于Web的求职招聘系统”用例图

此处只对系统中部分实体类进行分析，识别出的实体类有：User（用户）、Seeker（求职者）、Inviter（招聘者）、Administrator（管理员）、Application（求职信息）、Invitation（招聘信息）、Resume（简历）、News（新闻），如图11.43所示。

图11.43系统中的实体类

（2）识别系统中各类之间的关系

分析得出“基于Web的求职招聘系统”中各实体类之间关系如表11.4所示。

表11.4系统中各实体类之间的关系

Seeker

Inviter

News

Resume

Invitation

Application

（3）借助RationalRose工具绘制出“基于Web的求职招聘系统”类图

由于该系统总体类图较复杂，所以将其划分为如下三个子图：Manage（管理模块）子图，如图11.44所示；Seek（求职模块）子图，如图11.45所示；Invite（招聘模块）子图，如图11.46所示；。

图11.44Manage子图

图11.45Seek子图

图11.46Invite子图

此处以“Register”场景为例进行分析和建模，得到的时序图如图11.47所示。

图11.47“Register”时序图

此处仍以“Register”场景为例，利用RationalRose工具将其时序图直接转化成协作图。生成的“Register”场景协作图，如图11.48所示。

图11.48“Register”协作图

（3）捕获系统中指定对象的状态，并借助RationalRose工具绘制出相应的状态图

此处以Seeker（求职者）对象为例，绘制其状态图，如图11.49所示。

图11.49Seeker的状态图

（4）捕获系统中指定对象或指定用例的活动，并借助RationalRose工具绘制出相应的活动图

以捕获“ModifyInfo”（更新信息）用例的活动为例，绘制“ModifyInfo”活动图如图11.50所示。

图11.50“ModifyInfo”活动图

（1）分析系统中的组件及组件间的关系，并借助RationalRose工具绘制出“基于Web的求职招聘系统”组件图

通过分析，确定“基于Web的求职招聘系统”中的组件有：ApplicationSystem（求职招聘系统的Web应用程序）、Seek（求职）、Invite（招聘）、Manage（管理）。以上各组件中有部分组件存在依赖关系，详见表11.5所示。

表11.5“基于Web的求职招聘系统”中组件间的关系

ApplicationSystem

Seek

Invite

Manage

最终完成“BBS论坛系统”组件图，如图11.51所示。

图11.51“基于Web的求职招聘系统”组件图

（2）结合静态模型，借助RationalRose工具绘制“基于Web的求职招聘系统”数据模型图

借助RationalRose绘制“基于Web的求职招聘系统”部分数据模型图如图11.52所示。

图11.52“基于Web的求职招聘系统”部分数据模型图

另外，还可以从以上数据模型中导出数据库或DDL（数据库定义语言）脚本，导出的“S&I.ddl”脚本文件具体内容如下：

CREATETABLESeeker(

seekerIDSMALLINTNOTNULL,

seekerNameVARCHAR(16)NOTNULL,

seekerSexVARCHAR(2)NOTNULL,

seekerPasswordSMALLINTNOTNULL,

userIDSMALLINTNOTNULL,

CONSTRAINTPK_Seeker0PRIMARYKEY(seekerID)

CREATETABLEInviter(

inviterIDSMALLINTNOTNULL,

inviterNameVARCHAR(50)NOTNULL,

InviterPasswordSMALLINTNOTNULL,

CONSTRAINTPK_Inviter1PRIMARYKEY(inviterID)

userNameVARCHAR(50)NOTNULL,

userPasswordSMALLINTNOTNULL,

CONSTRAINTPK_User2PRIMARYKEY(userID)

adminNameVARCHAR(16)NOTNULL,

adminPasswordSMALLINTNOTNULL,

CONSTRAINTPK_Administrator3PRIMARYKEY(adminID)

ALTERTABLEAdministratorADDCONSTRAINTFK_Administrator2FOREIGNKEY(userID)REFERENCESUser(userID)ONDELETENOACTIONONUPDATENOACTION;

ALTERTABLESeekerADDCONSTRAINTFK_Seeker0FOREIGNKEY(userID)REFERENCESUser(userID)ONDELETENOACTIONONUPDATENOACTION;

ALTERTABLEInviterADDCONSTRAINTFK_Inviter1FOREIGNKEY(userID)REFERENCESUser(userID)ONDELETENOACTIONONUPDATENOACTION;

通过分析，确定“基于Web的求职招聘系统”中的节点有：ApplicationServer（应用服务器）、DatabaseSever（数据库服务器）、SeekerPC、（求职者客户机）、InviterPC（招聘者PC客户机）、AdminPC（管理员PC机）。

借助RationalRose工具绘制“基于Web的求职招聘系统”部署图，如图11.53示。

图11.53“基于Web的求职招聘系统”部署图

借助RationalRose的正向工程将类模型生成代码以后，可以在保存路径中找到对应的Java源文件。

以浏览Inviter.java文件为例，其详细代码如下：

//Sourcefile:D:\\Rose&Java\\Inviter.java

publicclassInviterextendsUser

privateintinviterID;

privateintinviterName;

privateintinviterPassword;

privateintinviterPhone;

privateintinviterEmail;

privateintinviterRID;

publicResumetheResume;

publicApplicationtheApplication;

publicInvitationtheInvitation;

publicNewstheNews;

*@roseuid4D65D2990157

publicInviter()

*@roseuid4D64BEC001E4

publicvoidsetInviterPhone()

*@roseuid4D64BEC70177

publicvoidgetInviterPhone()

*@roseuid4D64BECC0232

publicvoidsetInviterEmail()

*@roseuid4D64BED20280

publicvoidgetInviterEmail()

*@roseuid4D64BEDA007D

publicvoidsetInviterRID()

*@roseuid4D64BEE00196

publicvoidgetInviterRID()

选择一个基于Web的软件系统（如“网上书店系统”、“网上花店系统”等），借助RationalRose工具，按照“用例建模”、“静态建模”、“动态建模”、“物理建模”、“双向工程”的顺序，对其进行UML建模。

1.RUP的核心工作流

2.RUP的核心技术特点

（1）用例驱动

通过前面的实例可以看出，需求分析阶段用户需求是借助用例来表达的，设计初期的类是根据用例来发现的，构造阶段开发管理和任务分配是按照用例来组织的，测试阶段的实例是根据用例来生成的。

（2）以构架为中心

架构为用户和研发人员提供系统的管理视图，架构是系统实现的基础，架构为项目管理提供基本指导，架构描述是软件系统的主要制品。

（3）迭代和增量的开发方式

由于RationalRose2003是英文菜单，所以为方便读者使用，对照每一项菜单，将其中文含义说明如下，供读者自行查阅。

（1）【File】菜单的下级菜单如表附1所示。

表附1【File】的下级菜单

二级菜单

三级菜单

快捷键

New

Ctrl+N

创建新的模型文件

Open

Ctrl+O

打开模型文件

Save

Ctrl+S

保存模型文件

SaveAs

将当前的模型保存到其他的模型文件中

SaveLogAs

保存日志文件

AutoSaveLog

自动保存日志

ClearLog

清空日志记录区

LoadModelWorkspace

加载模型工作区

SaveModelWorkspace

保存模型工作区

SaveModelWorkspaceAs

将当前模型工作区保存为其他模型工作区

Units

Load…

加载

保存

SaveAs…

另存为

Unload

卸载

Control

控制

Uncontrol

放弃控制

WriteProtected

写保护

存在四级菜单（见表附2）

Import

导入模型

ExportActivation

导出模型

Update

更新模型

Ctrl+P

打印模型中的图和说明书

PageSetup

打印时的页面设置

EditPathMap

设置虚拟映射

Exit

退出

需要说明的是，二级菜单选项【Units】下的三级菜单（【CM】除外）因模型元素的不同而不同。

（2）【CM】的下级菜单详见表附2所示。

表附2【CM】的下级菜单

四级菜单

AddtoVersionControl

将模型元素加入版本控制

RemoveFromVersionControl

将模型元素从版本中删除

StartVersionControlExplore

启动Rose里的版本控制系统

GetLatest

获取模型元素的最新版本

CheckOut

放弃当前版本

CheckIn

登记当前版本

UndoCheckOut

撤销上一级的【CheckOut】

FileProperties

显示加入版本控制的模型元素的信息

FileHistory

显示加入版本控制的模型元素的历史信息

VersionControlOption

版本控制选项

AboutRationalRoseVersionControlIntegration

显示Rose版本控制的版本信息

不同种类的模型图，其【Edit】菜单的下级菜单有所不同，但有一些选项是共有的，详见表附3所示，不同的选项详见表附4所示。

表附3共有的【Edit】的下级菜单

UndoMove

Ctrl+Z

撤销前一次的操作

RedoMove

Ctrl+Y

重复前一次的操作

Ctrl+X

Copy

Ctrl+C

复制

Ctrl+V

Delete

DEL

删除

SelectAll

Ctrl+A

全选

DeletefromModel

Ctrl+D

删除模型中的元素

Find

Ctrl+F

查找

Reassign

重新指定模型元素

表附4不同种类模型图的【Edit】下级菜单

模型图

UseCaseDiagram

ClassDiagram

Reloacate

更新部署模型元素

Compartemnet

编辑模块

ChangeInfo

更改类

ParameterizedClass

更改参数化的类

InstantiatedClass

更改示例化的类

ClassUtility

更改类的效用

ParameterizedClassUtility

更改参数化的类的效用

InstantiatedClassUtility

更改示例化的类的效用

UsesDependency

更改依赖关系

更改泛化关系

Instantiates

更改实例

更改关联关系

更改实现关系

ComponentDiagram

Relocate

重新部署模型元素

Compartment

Subprogramspecification

更改子系统规范

Subprogrambody

更改子系统体

Genericsubprogram

更改通用子系统

Mainprogram

更改主程序

Packagespecification

更改包规范

Packagebody

更改包体

Taskspecification

更改工作规范

Taskbody

更改工作体

DeploymentDiagram

SequenceDiagram

AttachScript

添加脚本

DetachScript

删除脚本

CollaborationDiagram

StatechartDiagram

将活动变为状态

Activate

将状态变为活动

ActivateDiagram

【View】菜单的下级菜单如表附5所示。

表附5【View】下级菜单

Toolbars

Standard

显示或隐藏标准工具栏

显示或隐藏编辑区工具栏

Configure

定制工具栏

StatusBar

显示或隐藏状态栏

Documentation

显示或隐藏文档区

Browser

显示或隐藏浏览区

Log

显示或隐藏日志区

Editor

显示或隐藏内部编辑器

TimeStamp

ZoomtoSelection

Ctrl+M

居中显示

Ctrl+I

Ctrl+U

Ctrl+W

设置显示比例使图形放进窗口

撤销【FitinWindow】

PageBreaks

显示或隐藏页的操作

Refresh

刷新

AsBooch

Ctrl+Alt+B

用Booch符号表示模型

AsOMT

Ctrl+Alt+O

用OMT符号表示模型

AsUnified

Ctrl+Alt+U

用UML符号表示模型

【Format】菜单的下级菜单如表附6所示。

表附6【Format】下级菜单

备注

FontSize

设置为8号字

设置为10号字

设置为12号字

设置为14号字

设置为16号字

设置为18号字

Font

设置字体

LineColor

设置线段颜色

FillColor

设置图标颜色

UseFillColor

使用设置的图标颜色

AutomaticResize

自动调节图标大小

StereotypeDisplay

None

选择空的构造型

Label

选择带标签的模板

Decoration

选择带注释的模板

Icon

选择带图标的模板

StereotypeLabel

显示构造型标签

ShowVisibility

显示可见性

ShowCompartmentStereotype

显示构造型属性或操作

ShowOperationsignature

显示操作的署名

（即参数和返回值）

ShowAllAttributes

显示所有的属性

ShowAllOperations

显示所有的操作

ShowAllColumns

显示所有列

用例图和类图中没有

ShowAllTriggers

显示所有触发器

SuppressAttributes

禁止显示所有属性

SupressOperations

禁止显示所有操作

SupressColumns

禁止显示所有列

SupressTriggers

禁止显示所有触发器

LineStyle

Rectilinear

选择垂线样式

协作图中没有

Oblique

选择斜线样式

Toggle

选择折线样式

LayoutDiagram

重新排列所有图形

组件图和协作图中没有

AutosizeAll

组件图和部署图中没有

LayoutSelectedShapes

重新排列选中的图形

时序图和协作图中没有

表附6中备注栏没有特别说明的，表示该菜单选项在所有的模型图中都存在。

不同种类的模型图，其【Browse】菜单的下级菜单有所不同，但有一些选项是共有的，详见表附7所示，不同的选项详见表附8所示。

表附7共有的【Browse】的下级菜单

浏览用例图

浏览配置图

InteractionDiagram

StateMachineDiagram

Ctrl+T

Expand

Ctrl+E

浏览选中的逻辑包或组件包的主图

Parent

Specification

Ctrl+B

浏览模型元素的规范

TopLevel

浏览上层图

PreviousDiagram

浏览前一个图

表附8不同种类模型图的【Browse】下级菜单

ReferencedItem

Ctrl+R

CreateMessageTraceDiagram

创建消息追踪图

CreateCollaborationDiagram

根据时序图创建协作图

CreateSequenceDiagram

根据协作图创建时序图

【Report】菜单的下级菜单如表附9所示。

表附9【Report】下级菜单

ShowUsage

显示所选项目在哪里被使用

全部图中都有

ShowParticipantsinUC

获得用例中所有参与者列表

ShowInstances

获得所有包含所选类的协作图列表

用例图和类图中有

ShowAccessViolations

获得类图中包之间所有拒绝访问的列表

ShowUnresolvedObjects

获得所有所选项目中未解决的对象列表

时序图和协作图中有

ShowUnresolvedMessage

获得所选项目中未解决的消息列表

在时序图、协作图和配置图中没有【Query】菜单，在其他的模型图中【Query】的下级也是不同的，如表附10所示。

表附10【Query】下级菜单

UseCaseDiagram,

AddClass

添加类

AddUseCase

添加用例

ExpandSelectedElements

扩展所选的元素

HideSelectedElements

隐藏所选的元素

FilterRelationships

过滤关系

AddElements

添加元素

隐藏所选的关系

FilterTransitions

过滤转换

AddComponents

添加组件

AddInterfaces

添加接口

【Tools】菜单的下级菜单如表附11所示。

表附11【Tools】下级菜单

Create

不同模型图的三级菜单不同

在此附表中不再逐一赘述

CheckModel

搜寻模型中未解决的引用，

并在日志区中输出结果

ModelProperties

编辑模型道具

显示模型道具

Replace

加载模型道具集合

Export

导出模型道具集合

Add

添加新的模型道具

更新模型道具集合

Options

定制Rose选项

OpenScript

打开现有的脚本

NewScript

创建新的脚本

ANSIC++

OpenANSIC++Specification

编辑ANSIC++规范

BrowseHeader

浏览ANSIC++标题

BrowserBody

浏览ANSIC++主题

ReverseEngineer

由ANSIC++代码生成模型

GenerateCode

生成ANSIC++代码

ClassCustomization

定制生成ANSIC++中的类

Preferences

定制ANSIC++中的参数

ConvertFromClassicC++

从经典的C++转变为ANSIC++

Ada83

CodeGeneration

生成Ada83代码

BrowseSpec

浏览Ada83说明书

BrowseBody

浏览Ada83主体

Ada95

生成Ada95代码

浏览Ada95说明书

浏览Ada95主体

CORBA

ProjectSpecification

编辑CORBA工程规范

SyntaxCheck

CORBA语言检测

BrowseCORBASource

ReverseEngineerCORBA

由CORBA代码生成模型

生成CORBA代码

J2EEDeploy

Deploy

配置J2EE

Java/J2EE

编辑Java/J2EE工程规范

Java/J2EE语法检测

EditCode

编辑Java/J2EE代码

生成Java/J2EE代码

由Java/J2EE代码生成模型

登记当前的Java/J2EE代码

放弃当前的Java/J2EE代码

撤销【CheckOut】

UseSourceCodeControlExplorer

使用源代码控制探测器

NewEJB

创建新的EJB

NewServlet

创建新的Servlet

GenerateEJG-JARFile

生成EJB-JAR文件

GenerateWARFile

生成WAR文件

Oracle8

DataTypeCreationWizard

创建数据模型

OrderingWizard

属性和队列顺序向导

EditForeignKeys

编辑外键

AnalyzeSchema

分析图表

SchemaGeneration

生成图表

SyntaxChecker

语法检测

Reports

生成数据模型报告

ImportOracle8DataTypes

导入数据类型

QualityArchitect

Console

打开质量结构控制台

UnitTest

GenerateUnitTest

生成单元测试

SelectUnitTestTemplate

选择单元测试模板

Create/EditDatapool

创建或编辑数据池

Stubs

GenerateStub

生成存根

Creat/EditLook-upTable

创建或编辑查询表

ScenarioTest

GenerateScenarioTest

生成情景测试

SelectScenarioTemplate

选择情景测试

OnlineManual

打开在线手册

ModelIntegrator

打开模型集成器

WebPublisher

发布模型

TOPLink

进行TOPLink转换

COM

Properties

定制COM选项

ImportTypeLibrary

导入COM组件类型库

VisualC++

ModelAssistant

打开建模助手

ComponentAssignmentTool

打开组件分配工具

UpdateCode

打开代码更新工具

UpdateModelfromCode

打开模型更新工具

ClassWizard

创建新的类

UndoLastCodeUpdata

撤销【CodeUpdate】

NewATLObject

新的ATL对象

ImplementInterface

实现接口

ModuleDependencyProperties

模块依赖关系选项

HowDoI

如何实现接口对应的类

QuickImportATL3.0

导入ATL3.0类型库

QuickImportMFC6.0

导入MFC6.0类型库

ModelConverter

VisualC++模型转换器

FrequentlyAskedQuestions

VisualC++帮助

VisualC++选项设置

VersionControl

将模型元素从版本控制中删除

StartVersionControlExplorer

启动Rose中的版本控制系统

登记为当前版本

撤【CheckOut】

VersionControlOptions

显示RationalRose版本控制的版本信息

VisualBasic

打开VisualBasic建模助手

打开VisualBasic组件分配工具

打开VisualBasic代码更新工具

打开VisualBasic模型更新工具

创建新的VisualBasic类

AddReference

将COM组件的类型库导入模型

BrowseSourceCode

浏览VisualBasic源码

设置VisualBasic选项

WebModeler

UserPreference

设置网络建模器中的用户参数

ReverseEngineeraNewWebApplication

由网络应用生成模型

XML_DTD

编辑XML_DTD工程规范

XML_DTD语法检测

BrowseXML_DTDSource

ReverseEngineerXML_DTD

由XML_DTD代码生成模型

生成XML_DTD代码

创建新类

【Add-Ins】菜单下只有一个【Add-InManager】选项，其用途是设置附加选项的状态，即设置为活动或无效。

THE END

UML基础与Rose建模实训教程CrunchYou

研究报告可下载基于分治的文本语义建模研究档案课题知识库

学生管理系统的用例图类图活动图状态图

UML基础与Rose建模实训教程CrunchYou

uml面向对象的系统分析与设计实验指导书

数据安全论文汇总十篇