目  录

第1章  初识UML. 1

1.1 初识UML用例图... 1

1.2 初识UML类图... 3

第2章  Rational Rose工具... 6

2.1 安装与配置Rational Rose. 6

2.2 使用Rational Rose建模... 15

第3章  用例模型... 20

3.1 参与者... 20

3.2 用例... 28

3.3用例模型中的关系... 37

第4章  静态模型... 49

4.1 类图中的事物... 49

4.2 类图中的关系... 66

第5章  时序图... 80

第6章  协作图... 95

第7章  状态图... 108

第8章  活动图... 122

第9章  物理模型... 139

9.1 组件图（Component Diagram）... 139

9.2 部署图（Deployment Diagram）... 160

第10章  双向工程... 167

10.1 正向工程... 167

10.2 逆向工程... 177

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

11.1 BBS论坛系统... 182

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

附录  Rational Rose 2003菜单... 220

第1章  初识UML

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

1.1 初识UML用例图

1.1.1 相关知识点

1. 什么是用例图

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

2. 如何绘制用例图

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

在具体应用时，可辅以建模工具（如Microsoft Office Visio、Sybase PowerDesigner、IBM Rational Rose等）将其描绘出来。

1.1.2 知识点的能力目标

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

1.1.3 实现能力目标的具体要求

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

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

1.1.4 需要完成的实验

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

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

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

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

1.1.5 测试能力目标

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

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

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

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

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

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

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

1.1.6 知识扩展

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

1.2 初识UML类图

1.2.1 相关知识点

1. 什么是类图

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

2. 如何绘制类图

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

1.2.2 知识点的能力目标

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

1.2.3 实现能力目标的具体要求

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

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

1.2.4 需要完成的实验

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

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

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

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

1.2.5 测试能力目标

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

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

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

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

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

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

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

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

1.2.6 知识扩展

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

第2章  Rational Rose工具

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

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

2.1 安装与配置Rational Rose

2.1.1 相关知识点

1. Rational Rose的安装

安装Rational Rose首先需要获得软件安装包，可以从官方网站http://www.ibm.com下载试用版本，然后根据安装向导提示逐步安装。

2. Rational Rose的启动

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

3. Rational Rose的配置

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

2.1.2 知识点的能力目标

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

2.1.3 实现能力目标的具体要求

1. 安装Rational Rose 2003。

2. 启动Rational Rose 2003。

3. 配置Rational Rose 2003。

2.1.4 需要完成的实验

1. 安装Rational Rose 2003

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

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

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

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

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

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

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

（8）单击【Next】按钮，打开“版权声明”对话框，如图2.9所示。在此选择“I Accept the terms in the license
agreement”接受版权许可协议。

（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. 启动Rational Rose 2003

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

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

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

3. 配置Rational Rose 2003

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

2.1.5 测试能力目标

1. Rational Rose 2003的自定义安装

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

2. Rational Rose 2003的配置

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

2.1.6 知识扩展

1. Rational Rose 2003软件的卸载

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

2. 其他UML建模工具安装

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

2.2 使用Rational Rose建模

2.2.1 相关知识点

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

2.2.2 知识点的能力目标

能够使用Rational
Rose建模。

2.2.3 实现能力目标的具体要求

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

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

3. 发布该模型。

2.2.4 需要完成的实验

1. 创建模型

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

2. 保存模型

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

3. 发布模型

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

2.2.5 测试能力目标

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

2. 通过Rational Rose的【Tools】->【Web Publisher】菜单可以进行模型的_________操作。

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

2.2.6 知识扩展

1. 导出模型

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

2. 导入模型

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

3. Rational Rose的主菜单

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

表2.1 Rational Rose主菜单说明

4. Rational Rose的工具栏

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

表2.2 Rational Rose工具栏

按钮	英文含义	中文含义
	Create New Model or File	新建模型或文件
	Open Existing Model or File	打开已有的模型或文件
	Save Model, File or Script	保存模型，文件或脚本
	Cut	剪切
	Copy Diagram	复制图形
	Paste	粘贴
	Print	打印
	Context Sensitive Help	动态帮助
	View Documentation	浏览文档
	Browse Class Diagram	浏览类图
	Browse Interaction Diagram	浏览交互图
	Browse Component Diagram	浏览组件图
	Browse State Machine Diagram	浏览状态图
	Browse Deployment Diagram	浏览部署图
	Browse Parent	浏览父图
	Browse Previous Diagram	浏览上一图形
	Zoom In	放大
	Zoom Out	缩小
	Fit in Window	设置显示比例，使图形放进窗口
	Undo Fit in Window	撤销【Fit in Windows】设置

第3章  用例模型

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

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

3.1 参与者

3.1.1 相关知识点

1. 系统边界（System Boundary）

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

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

2. 参与者（Actor）

参与者指的是存在于系统之外，透过系统边界与系统进行有意义交互的任何事物。参与者可以是一个人，一个其他的系统或一部机器，甚至可以是时间，如图3.2所示。举例来说，比如在“自动售货系统”中，系统有售货、供货、提取销售款等功能，其中启动售货功能的是人，那么人就是参与者；又如“图书管理系统”可能需要和其他应用系统发生联系，比方说可能通过“学生管理系统”验证读者是否为在校学生，那么这里的“学生管理系统”就是一个参与者，只不过该参与者不是具体的一个人，而是另外的一个系统；与一个系统进行交互的人或其他的系统可以是参与者，与系统进行通信的硬件设备也可以是参与者，例如在“自动售货系统”中，顾客购买货品时，最终是货品分配器将货品传送至出货口以便用户提取，此时货品分配器作为硬件设备也就成为了该系统的参与者之一；再如“图书管理系统”中如果读者到期没有归还图书，则读者进入系统时会有“未还书提示”功能，此处时间也就成为参与者，也就是说当经过一定时间后系统中的“未还书提示”事件就会发生。

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

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

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

3. 识别参与者

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

从交互识别：

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

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

（3）谁从系统获得信息?

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

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

从维护、管理识别：

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

从设备或外部条件识别：

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

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

（9）时间、气温等条件是否对系统产生影响？

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

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

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

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

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

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

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

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

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

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

（9）忽略时间、气温等条件对系统产生的影响。

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

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

3.1.2 知识点的能力目标

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

3.1.3 实现能力目标的具体要求

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

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

3.1.4 需要完成的实验

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

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

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

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

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

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

（1）创建和保存工程

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

（2）创建用例图

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

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

（3）新建参与者

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

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

3.1.5 测试能力目标

1. 什么是系统边界？

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

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

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

A. 人员         B. 外部系统         C. 硬件设备         D. 时间

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

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

3.1.6 知识扩展

1. 自定义绘图工具栏

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

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

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

如果系统用例图中有多个参与者，按照前面介绍的方法绘制相关图示就需要做很多重复劳动，显得相当麻烦。其实可以选择更快捷的方法来完成多个参与者的绘制，首先选择绘图工具栏中【】 “锁定选择”按钮 ，然后选择“参与者”按钮，此时鼠标会变成十字形状，接着在编辑区中任意位置多次单击鼠标，即可绘制出多个参与者图示，再次单击“锁定选择按钮”即可取消锁定，如图3.13所示。此方法同样适用于其他图示。

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

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

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

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

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

3.2 用例

3.2.1 相关知识点

1. 用例（Use
Case）

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

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

用例具有以下特征：

（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

补充说明：

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

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

例如，在“图书管理系统”的Borrow Book（借书）这个用例中，包含着如下几个相关的场景。

Scenario-1：顺利地借到书

Scenario-2：该种书刊不存在

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

Scenario-4：没有该读者信息

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

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

用例编号：001

用例名称：Borrow Book

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

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

前置条件（Preconditions）：图书馆正常开放时间

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

基本事件流（Flow of Events）：

1. 读者进入图书馆

2. 读者查找图书

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

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

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

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

备选流：

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

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

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

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

3a. 物理书刊均已借出

3a1. 系统提示无馆藏

补充说明：

无

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

3.2.2 知识点的能力目标

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

3.2.3 实现能力目标的具体要求

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

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

3.2.4 需要完成的实验

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

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

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

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

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

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

综合对“图书管理系统”中参与者和相关系统功能的分析，得到该系统的全部用例如表3.1所示。

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

（1）打开工程和用例图

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

（2）创建用例

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

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

编号	参与者	用例名称	用例说明
1	Administrator （系统管理员）	Add User	增加系统用户
2		Delete User	删除系统用户
3		Update User	修改系统用户
4		Query User	查询系统用户
5	Librarian （图书管理员）	Set BookType	进行图书类型设置
6		Set BorrowType	进行借阅种类设置
7		Set BookInfo	进行图书信息设置
8		Set ReaderCard	为读者办证
9		Query BookInfo	根据需要进行图书信息查询
10		Query ReaderInfo	进行读者信息查询
11		Borrow Book	处理读者的借书请求
12		Return Book	处理读者的还书请求
13		Renew Book	处理读者的续借图书请求
14		Fine	收取读者的超期罚款
15		Reserve Book	处理读者的图书预定请求
16		Cancel Reservation	处理读者的取消预订请求
17		Lose Book	处理图书挂失
18		Lose ReaderCard	处理读者证挂失
19	Reader （读者）	Login	登录系统
20		Reserve Book	申请预订图书
21		Cancel Reservation	取消图书预订
22		Query BookInfo	根据需要进行图书信息查询
		Query ReaderInfo	进行读者信息查询
23		Renew Book	申请续借图书

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

按以上方法，可以创建“图书管理系统”中的主要用例，与系统管理员相关的用例如图3.18所示，与图书管理员相关的用例如图3.19所示，与读者相关的用例如图3.20所示。

3.2.5 测试能力目标

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

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

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

A. Clerk, Manager

B. Clerk, Manager, Customer

C. Clerk, Manager, Bank network

D. Clerk, Manager, Bank network, Customer

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

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

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

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

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

5. 根据表3.2列举的信息，借助Rational Rose工具绘制“手机系统”的参与者和相关用例。

表3.2 “手机系统”相关信息

6. 识别“Email客户端”（如：outlook express）软件系统中的参与者和用例，需求描述如下：A在北京发送邮件给上海的B，系统提醒B “您有新邮件”，B接收邮件。借助Rational Rose工具，设计并绘制出相关参与者和用例图示。

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

3.2.6 知识扩展

1. 谁来写用例阐述文档

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

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

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

2. 用例的粒度

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

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

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

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

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

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

3. 识别用例的注意事项

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

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

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

例如，在“零件销售管理系统”中，与客户相关的检索零件功能具体操作步骤是：首先客户设置检索条件，然后选择合适的零件，接着再进行后续操作。通过分析可知，其中有意义的目标就是检索零件，而并非是设置检索条件和选择合适零件。所以正确的用例应如图3.23所示，而非图3.24所示。在具体分析时，也应避免此种情况发生。

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

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

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

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

用户角度	开发人员角度
呼叫某人	传输/接收
接听电话	电源/基站
发送短消息	输入输出（显示器，键盘）
记录电话号码	电话簿管理
……	……

3.3用例模型中的关系

3.3.1 相关知识点

1. 泛化（Generalization）关系

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

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

2. 关联（Association）关系

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

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

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

3. 包含（Inclusion）关系

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

在UML中包含关系使用虚线箭头表示，其上添加<<include>>字样，箭头指向被包含用例。例如，在“学生成绩管理系统”中，学生登录系统之后方可查询个人的成绩信息，教师也需登录系统后方可输入学生成绩、查询学生成绩，那么该系统用例模型中登录用例和查询成绩、输入成绩用例之间就可以表示为包含关系，如图3.29所示。

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

4. 扩展关系（Extension）

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

扩展的目的在于：

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

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

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

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

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

3.3.2 知识点的能力目标

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

3.3.3 实现能力目标的具体要求

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

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

3.3.4 需要完成的实验

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

三个参与者Administrator（系统管理员），Librarian（图书管理员），Reader（读者）和与其相关的用例之间存在关联关系。

此外，Reader（读者）相关的Reserve Book（预订图书）用例、Cancel Reservation（取消预订）用例、Query BookInfo（查询图书）用例、Query ReaderInfo（查询读者）用例、Renew Book（续借图书）用例包含一个公共的用例，就是Login（注册）用例，它们与Login（注册）用例存在包含关系。

Librarian（图书管理员）相关的Return Book（还书）用例和Fine（罚款）用例之间存在扩展关系。

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

（1）打开工程和用例图

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

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

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

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

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

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

3.3.5 测试能力目标

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

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

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

2. 用例用来描述系统在对事件做出响应时所采取的行为。用例之间是具有相关性的。在一个“订单输入子系统”中，创建新订单和更新订单都需要核查用户账号是否正确。那么，用例“创建新订单”、“更新订单”与用例“检查客户账号”之间是（    ）关系。

A. 包含                                     B. 扩展

C. 分类（Classification）           D. 泛化

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

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

4. 在“成绩管理系统”中，“查询成绩”和“网上查询成绩”用例之间为（　　　　）关系；“输入成绩”和“登录系统”用例之间为（　　　　）关系；“修改成绩”和“输入成绩”用例之间为（　　　　）关系。

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

5. 某电话公司决定开发一个管理所有客户信息的交互式的网络系统，系统功能需求描述如下。

（1）浏览客户信息：任何使用Internet的网络用户都可以浏览电话公司所有的客户信息（包括姓名、住址、电话号码等）。

（2）登录：电话公司授予每个客户一个账号。拥有授权账号的客户，可以使用系统提供的页面设置个人密码，并使用该账号和密码向系统注册。

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

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

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

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

用户可以通过不同的方式（包括电话、前台、网上）提出预订车辆申请；基层工作人员可以处理客户预定、客户取车、客户还车等业务，并保存客户相应历史记录；技术人员可以填写检修服务记录、保存检修结果。

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

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

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

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

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

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

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

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

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

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

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

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

3.3.6 知识扩展

1. 用例图的层次

由于人类处理复杂事物的能力有限，所以在系统需求相对较多的情况下，就需要采用分层处理的方法。层次中的“顶层”用例是重中之重，因为它决定了一个系统的内在实质。同时，作为系统的实施者，要经常性地关注顶层用例图，这样才能够保证在系统实施过程中牢牢把握系统目标。在接下来的次高层，用例的数量也应当进行适当地控制，但就整体而言用例图的总层次不宜超过三层。

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

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

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

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

2 用例图工具栏

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

表3.4 用例图工具栏按钮

3. 绘图中的错误提示

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

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

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

第4章  静态模型

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

4.1 类图中的事物

4.1.1 相关知识点

1. 类（Class）

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

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

（1）名称（Name）

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

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

（2）属性（Attribute）

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

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

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

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

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

表4.1 Rational Rose的属性可见性

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

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

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

其中属性字符串用来指定属性的其他相关信息。通常情况下，属性字符串列出该属性所有可能的取值。

（3）操作（Operation）

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

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

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

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

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

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

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

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

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

（1）实体类（Entity Class）

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

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

（2）边界类（Boundary Class）

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

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

（3）控制类（Control Class）

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

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

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

2. 接口（Interface）

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

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

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

3.
包（Package）

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

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

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

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

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

4. 协作（Collaboration）

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

4.1.2 知识点的能力目标

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

4.1.3 实现能力目标的具体要求

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

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

4.1.4 需要完成的实验

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 “图书管理系统”中的类

另外，系统的用户接口，如Login（登录）、Main（主界面）、SystemManage（系统管理）、ReaderManage（读者管理）、BookManage（图书管理）、BorrowManage（借阅管理）、FineManage（罚款管理）等窗体，也可作为该系统的边界类出现。

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

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

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

（1）打开工程创建类图

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

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

（2）创建包

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

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

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

（3）创建类

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

（4）编辑类

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

添加属性的方法之一是通过菜单直接添加。即右键单击要添加属性的类（如“Book”类）打开快捷菜单，选择【New
Attribute】菜单项，如图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所示的快捷菜单中选择【New
Operation】菜单项；或者在图4.24 所示的“类设置”对话框中选择【Operations】选项卡而非【Attributes】选项卡，即可完成类操作的添加。类操作的详细设置可以在如图4.26所示的对话框中双击指定的操作如querybyAuthor，打开“类操作设置”对话框，如图4.27所示，在此可以进行操作名称、返回值、可见性等设置；继续单击该对话框的【Detail】选项卡，可以进行参数列表设置，如图4.28所示，在“Arguments”空白区域任意位置右键单击，在弹出的快捷菜单中选择【Insert】菜单项，此处设置querybyAuthor操作有一个参数名为authorName，参数类型为String字符串。

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

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

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

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

4.1.5 测试能力目标

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

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

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

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

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

A. 边界类                     B. 实体类

C. 控制类                     D. 主类

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

A. Type                       B. Stereotype

C. Initial                      D. Export Control

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

A. abstract                     B. control

C. boundary                    D. subclass

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

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

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

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

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

功能需求：

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

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

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

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

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

4.1.6 知识扩展

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

类的概念层、说明层和实现层的划分最先是由 Steve Cook和John
Daniels引入的。

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

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

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

4.2 类图中的关系

4.2.1 相关知识点

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

1. 泛化（Generalization）关系

在第3章用例模型中已经提到过泛化关系，通过前面的介绍可知，泛化表示一般元素和特殊元素之间的关系。在类图中，一般元素被称为超类或父类，特殊元素被称为子类。子类可以继承父类的属性和操作，并根据需要增加自己新的属性和操作。更简单地说，泛化关系描述了类之间的“is a kind of”（是……的一种）关系。在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）关系

关联是类（更确切地说，是类的实例即对象）之间的关系，表示有意义的和值得关注的连接。换言之，在类图中如果两个对象之间存在需要保持一段时间的关系，那么它们之间就可以表示为关联关系。举例来说，学生（Student）在学校（School）里学习课程（Classes），那么在学生（Student）、学校（School）和课程（Classes）之间就存在着某种连接。设计类图时，也就可以在“Student”、“School”和“Classes”之间建立关联关系。

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

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

（1）关联名称

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

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

（2）关联角色

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

（3）关联的导航性

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

（4）关联的多重性

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

表4.3 关联的多重性指标

 

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

5. 聚集（Aggregation）关系

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

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

6. 组合（Composition）关系

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

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

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

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

4.2.2 知识点的能力目标

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

4.2.3 实现能力目标的具体要求

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

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

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

4.2.4 需要完成的实验

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

显而易见，GUI
Package和Business Package之间存在依赖关系，前者依赖后者而存在。

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

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

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

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

表4.5 GUI Package包中各边界类的关系

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

（1）打开类图

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

（2）建立包之间的关系

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

（3）建立类之间的关系

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

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

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

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

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

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

4.2.5 测试能力目标

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

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

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

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

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

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

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

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

A.

B.

C.

D.

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

class
RegularReceiptVisitor

{

public void
printRoomCharges( XXX& aVar)

{

aVar.getDescription();

aVar.getQualtity();

aVar.getPrice();

}

……

}

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

A. ReceiptVisitor                  B. PromotionalReceiptVisitor

C. Describable                     D.
Entertainment

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

A.   B.

C.          D.

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

A. B.

C. D.

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

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

public class Student{

private String name;

public void setName(String name){

this.name=name;

}

public String getName(){

return this.name;

}

}

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

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

（2）研究生可以利用课余时间担任助教。

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

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

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

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

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

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

4.2.6 知识扩展

1. 类图工具栏

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

表4.6 类图工具栏

按钮	按钮名称	说明
	Selection Tool	选择工具
	Text Box	文本框
	Note	注释
	Anchor Note to Item	将图中的元素与注释连接
	Class	类
	Interface	接口
	Unidirectional Association	单向关联关系
	Association Class	关联类
	Package	包
	Dependency or instantiates	依赖关系或实例化（包含和扩展关系）
	Generalization	泛化关系
	Realize	实现关系
	Association	关联关系

2. 对象图与类图

类图表示类及类间的关系，对象图则表示在某一时间段这些类的具体实例及这些实例间的关系。由于对象是类的实例，所以对象图可以看作是类图的实例（对象图中的概念也与类图中的概念基本一致），用于帮助人们理解比较复杂的类图。对象有生存期，所以对象图只能在系统的某一时间段存在。

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

第5章  时序图

除了静态模型外，UML还有非常重要的动态模型。本章主要介绍动态模型中的时序图。时序图（Sequence Diagram）也称顺序图，描述了随时间变化，对象间传递消息的先后顺序。在具体应用中，时序图通常用来展示用例行为中各个对象的交互顺序。例如“图书管理系统”中的“借阅图书”用例，如果我们想刻画该用例是如何完成借阅功能的，就要分析该用例所涉及到的对象间是通过怎样的消息进行交互的，这些消息又是通过怎样的顺序进行传递的，那么就需要为“借阅图书”这一用例建立相应的时序图。时序图可供用户、分析人员、设计人员、编码人员、测试人员使用，以帮助他们深入理解系统的功能和结构。本章在全书知识体系中的位置如图5.1所示。

在UML中，时序图被描绘成一个二维关系图。其中，横轴代表各个参与交互的对象，纵轴代表时间，垂直向下延伸。一般来讲，时序图包括如下四种构成元素：对象（Object）、生命线（Lifeline）、消息（Message）、激活期（Activation）。

5.1 相关知识点

5.1.1 对象（Object）

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

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

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

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

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

5.1.2 生命线（Lifeline）

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

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

5.1.3 消息（Message）

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

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

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

5.1.4 激活期（Activation）

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

5.2 知识点的能力目标

能够识别“图书管理系统”中既定场景的对象、消息等要素，并且使用Rational Rose工具绘制出相关的时序图。

5.3 实现能力目标的具体要求

1. 识别“图书管理系统”中“用户登录”场景的对象、消息等要素，并使用Rational Rose工具绘制出其登录场景的时序图。

2. 识别“图书管理系统”中“图书信息录入”场景的对象、消息等要素，并使用Rational Rose工具绘制出其登录场景的时序图。

3. 识别“图书管理系统”中管理员“查询热门图书”场景的对象、消息等要素，并使用Rational Rose工具绘制出其登录场景的时序图。

4. 识别“图书管理系统”中“借书”场景的对象、消息等要素，并使用Rational Rose工具绘制出其登录场景的时序图。

5. 识别“图书管理系统”中“查询罚金”场景的对象、消息等要素，并使用Rational Rose工具绘制出其登录场景的时序图。

5.4 需要完成的实验

1. 建立“用户登录”的时序图，并使用Rational
Rose工具实现。

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

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

（2）新建时序图

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

（3） 创建对象

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

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

（4）识别对象间的消息

在时序图工具栏中选择消息按钮【】即“Object Message”，然后在绘图区域中两个对象生命线之间拖拽鼠标左键，便可以在指定的对象间添加相应的消息，被添加消息后对象的激活期会自动出现。对象间的消息默认情况下只有一个消息编号，如果要输入消息的具体内容或设置消息的类型，可以双击该消息打开“消息属性”对话框，或者右键单击该消息打开“消息属性”对话框。在“消息属性”对话框中选择【General】选项卡可以输入消息的名字和相关说明信息，如图5.13所示；在“消息属性”对话框中选择【Detail】选项卡可以设置消息的类型等，如图5.14所示。

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

本例时序图中， 对象间涉及到的消息有两个：其一为 Librarian对象发送给Reader对象的getReaderInfo消息，用于获取用户信息如用户名和密码等；其二为Lirarian对象发送给自身的 login消息，用于显示是否成功登录到“图书管理系统”，如图5.16所示。

至此，“用户登录”场景的时序图已基本完成。

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

实际操作步骤与建立“用户登录”时序图相似，使用Rational Rose工具实现的 “InputBook”时序图如图5.17所示。

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

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

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

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

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

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

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

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

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

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

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

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

3. 识别“图书管理系统”中管理员“查询热门图书”场景的对象、消息等要素，并使用Rational Rose工具绘制出其登录场景的时序图。

实际操作步骤与建立“用户登录”时序图相似，使用Rational Rose工具实现的 “SearchHotBook”时序图如图5.18所示。

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

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

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

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

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

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

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

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

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

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

4. 识别“图书管理系统”中“借书”场景的对象、消息等要素，并使用Rational Rose工具绘制出其登录场景的时序图。

实际操作步骤与建立“用户登录”时序图相似，使用Rational Rose工具实现的 “BorrowBook”时序图如图5.19所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 识别“图书管理系统”中“查询罚金”场景的对象、消息等要素，并使用Rational Rose工具绘制出其登录场景的时序图。

实际操作步骤与建立“用户登录”时序图相似，使用Rational Rose工具实现的 “SearchPayment”时序图如图5.20所示。

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

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

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

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

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

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

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

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

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

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

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

5.5 测试能力目标

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

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

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

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

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

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

7 参考“图书管理系统”的“查询热门图书”时序图，创建“查询读者信息”时序图，并使用Rational Rose工具实现。

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

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

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

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

5.6 知识扩展

1. 监护条件

为了详细说明对象间的消息传递，可以在时序图中使用监护条件（或称约束条件），加以辅助说明，如图5.23“购买饮料零钱找不开”场景时序图所示，其中括号内部标注信息即为监护条件。例如消息3的监护条件是[cash>price]即顾客现金大于饮料售价，此条件满足时Recorder（记录仪）对象才传递找零信息给Distributor（分配器）对象；又如消息5的监护条件是[no Change]即没有零钱，此条件满足时Recorder（记录仪）对象才会传递相关提示信息给Panel（面板）对象。

在大部分情况下，时序图中发送消息的时间是可以忽略的。如果有某些特殊情况需要表示消息间的时间差，也可以在图中使用监护条件，用于指示时间间隔。

2. 时序图工具栏

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

表5.2 时序图工具栏按钮

第6章  协作图

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

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

6.1 相关知识点

6.1.1 对象（Object）

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

6.1.2 链（Link）

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

6.1.3 消息（Message）

协作图中的消息与时序图中的消息相似，但是为了能够在协作图中显示交互过程中消息的时间顺序，通常也为交互的消息添加顺序号。顺序号是一个数字前缀，由数字1开始依次递增，每个消息有一个唯一的顺序号，可以通过点表示法代表消息的嵌套关系。例如在图6.2消息2中，消息2.1是嵌套在消息2中的第一个消息，它在2.2之前，以此类推。由于在消息中使用了嵌套表示，与时序图相比，协作图可以显示更为复杂的内容。

6.2 知识点的能力目标

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

6.3 实现能力目标的具体要求

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

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

3. 将“图书管理系统”中“用户登录”场景的时序图转化成协作图，并使用Rational Rose工具绘制出该协作图。

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

5. 将“图书管理系统”中“查询热门图书”场景的时序图转化成协作图，并使用Rational Rose工具绘制出该协作图。

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

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

6.4 需要完成的实验

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

（1）打开模型

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

（2）新建协作图

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

图6.3 新建协作图

（3）创建对象

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

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

图6.4 创建对象

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

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

图6.5 “链属性”对话框

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

方法之一是：在协作图工具栏中选择消息按钮【】即“Object Message”，此时将鼠标停放在该编辑区任意位置，鼠标会变成十字形状，在需要添加消息的链上再次单击鼠标即可在该链上添加消息。对象间的消息默认情况下只有一个消息编号，如果要输入消息的具体内容或设置消息的类型，可以双击该消息打开“消息属性”对话框，或者右键单击该消息打开 “消息属性”对话框。在“消息属性”对话框中选择【General】选项卡可以输入消息的名字和相关说明信息，具体参见第5章中图5.13所示；在“消息属性”对话框中选择【Detail】选项卡可以设置消息的类型，具体参见第5章图5.14所示。

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

图6.6 添加消息

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

图6.7 “Reader Reserve”协作图

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

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

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

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

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

（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“Reader Confirm”协作图

3. 建立“用户登录”协作图，并使用Rational
Rose工具实现。

使用Rational
Rose工具，建立“用户登录”协作图的方法有两种。

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

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

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

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

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

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

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

图6.11“User Login”协作图

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

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

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

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

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

（2）login消息：用于显示是否成功登录到“图书管理系统”。

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

实际操作步骤与建立“用户登录”协作图相似，使用Rational Rose工具实现的 “InputBook”协作图如图6.12所示。

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

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

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

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

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

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

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

图6.12 “InputBook”协作图

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

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

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

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

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

5. 建立“查询热门图书”协作图，并使用Rational
Rose工具实现。

实际操作步骤与建立“用户登录”协作图相似，使用Rational Rose工具实现的 “SearchHotBook”协作图如图6.13所示。

图6.13“SearchHotBook”协作图

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

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

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

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

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

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

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

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

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

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

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

实际操作步骤与建立“用户登录”协作图相似，使用Rational Rose工具实现的 “BorrowBook”协作图如图6.14所示。

图6.14 “BorrowBook”协作图

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

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

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

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

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

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

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

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

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

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

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

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

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

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

实际操作步骤与建立“用户登录”协作图相似，使用Rational Rose工具实现的 “SearchPayment”协作图如图6.15所示。

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

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

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

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

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

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

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

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

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

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

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

图6.15“SearchPayment”协作图

6.5 测试能力目标

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

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

B. 在Rational Rose工具中，协作图可在时序图的基础上按“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 维护课程信息协作图

6.6 知识扩展

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

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

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

区别体现为：时序图强调消息的时间顺序，协作图强调参加交互的对象的组织。通常情况下，二者可以相互转换。

2. 交互图与类图的关系

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

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

3. 协作图工具栏

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

表6.1 协作图工具栏按钮

第7章  状态图

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

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

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

7.1 相关知识点

7.1.1起点（Start）和终点（End）

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

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

图7.2 状态图的起点和终点

7.1.2状态（State）

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

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

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

（1）状态名称（State Name）

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

（2）入口/出口动作（Entry/Exit Action）

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

（3）动作（Action）

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

（4）子状态（Substate）

一个状态允许嵌套，以包含子状态，子状态继承其父状态的所有转换（Transition）。这使得即便在复杂的应用中，也可以绘制出结构清晰的状态图。以电话机对象的状态为例，

其简洁的描绘方式如图7.5所示。接线员挂机（on hook）之后再次拿起话筒之前电话机处于空闲（Idle）状态，当摘机（off hook）事件发生时，电话从空闲（Idle）状态转换为活动（Active）状态。而对于活动（Active）状态来说相对比较复杂，所以可以采用其子状态加以详细描绘，如图7.6所示，其中PlayingDialTone状态、 Dialing状态、Connecting状态、Talking状态都是Active状态的子状态。当发生某个到活动（Active）状态的转换时，播放拨号音（PlayingDialTone）状态被创建，并自动转换到该状态。无论电话机对象处于活动（Active）状态的哪一个子状态，当挂机（on hook）事件发生时，都发生向空闲（Idle）状态的转换。

图7.4 状态的组成部分

图7.5 电话机对象状态图1

图7.6 电话机对象状态图2

7.1.3事件（Event）

事件是指一件值得注意的事情的发生，事件能够引起某些动作执行。例如，电话接线员拿起话筒，此处“拿起话筒”就是事件，而事件引起的动作就是“开始通话”。又如，当按下CD机上的Play按钮时，CD机开始播放音乐，此处“按下Play按钮”就是事件，而事件引发的动作就是“开始播放”。

事件产生的原因包括：调用、满足条件的状态的出现、到达时间点或经历某一时间段、发送信号等等。事件的图形表示方式，可参见图7.5和图7.8中的标注。

7.1.4转换（Transition）

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

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

图7.7 转换

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

图7.8 转换中的互斥条件

7.2 知识点的能力目标

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

7.3 实现能力目标的具体要求

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

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

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

7.4 需要完成的实验

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

（1）打开模型

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

（2）新建状态图

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

图7.9 新建状态图

（3）添加状态及转换

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

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

图7.10 “状态属性”对话框

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

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

图7.11 设置状态包含的动作

图7.12 “动作属性”对话框

图7.13 “状态转换”对话框

图7.14 设置监护条件

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

（4）调整图形

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

图7.15 调整线性

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

图7.16 “ReaderCard State”状态图

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

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

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

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

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

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

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

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

图7.17 “Book State”状态图

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

（1）图书对象首先进入初始状态，购入新书（buy new book）后，该图书转换到入库（Enter To Store）状态；

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

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

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

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

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

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

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

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

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

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

图7.18 “System State”状态图

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

（1）系统首先进入初始状态，用户输入登录（input login information）信息后，系统进入登录（Login）状态；

（2）系统进入登录状态后，根据用户的操作产生相应的事件，系统可以进入读书管理（Book Management）状态、读者管理（Reader Management）状态、借阅管理（Borrow Management）状态、罚金管理（Fine Management）状态、关闭（Closing）状态；

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

7.5 测试能力目标

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

A. 时序图（Sequence Diagram） 
  B. 状态图（Statechart Diagram）

C . 类图（Class Diagram）         D. 协作图（Collaboration Diagram）

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

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

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

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

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

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

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

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

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

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

图7.19 MortgageApplication的状态图

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

图7.20 线程的状态图

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

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

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

图7.21 手机状态图

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

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

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

（3）反之，如果电梯的当前楼层比想要的楼层低时（[currentFloor<desiredFloor] 监护条件成立），电梯进入上升（Moving Up）状态；

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

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

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

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

7.6 知识扩展

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

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

图7.22 关于起点的错误提示

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

图7.23 视图区域树型列表

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

图7.24 关于转换的错误提示

2. 状态图工具栏

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

表7.1 状态图绘图工具栏

第8章  活动图

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

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

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

8.1 相关知识点

8.1.1起点（Start）和终点（End）

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

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

8.1.2活动（Activity）

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

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

动作状态有如下特点：

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

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

（3）动作状态是瞬时的，所占用的处理时间极短，有时甚至可以忽略。

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

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

活动状态有如下特点：

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

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

图8.4 活动的扩展

8.1.3转换（Transition）

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

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

8.1.4泳道（Swimlane）

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

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

图8.5 转换和泳道

8.1.5分支（Branch）

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

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

图8.6 分支

8.1.6分叉与汇合（Fork and Join）

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

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

8.1.7对象流（Object Flow）

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

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

图8.7 分支与汇合

图8.8 对象流

8.2 知识点的能力目标

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

8.3 实现能力目标的具体要求

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

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

3. 建立登录系统用例的活动图，并使用Rational
Rose工具实现。

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

8.4 需要完成的实验

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

（1）打开“Library”模型

（2）新建活动图

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

图8.8 新建活动图

（3）添加活动

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

图8.9 关于起点的错误提示

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

图8.10 “活动属性”对话框

图8.11 设置活动包含的动作

图8.12 “动作属性”对话框

依照如上方法，分别创建出图书管理员对象活动：Query（查询）、Process Return（处理还书）、Process Borrow（处理借阅）、Set（设置）、Get Fine（收取罚金）、Return Book（收回图书）、Give Book（借出图书）、Quit（退出）。

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

（4）添加分叉与汇合

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

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

图8.13 “同步属性”对话框

（5）添加分支

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

（6）添加转换

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

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

图8.14 设置监护条件

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

图8.15 “Librarian Activity”活动图

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

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

图8.16 “Reader Activity”活动图

3. 建立登录系统用例的活动图，并使用Rational
Rose工具实现。

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

图8.17 “Login Activity”活动图

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

图8.18 关于泳道的快捷菜单

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

实际操作步骤与建立登录系统用例活动图相似，使用Rational Rose工具实现的 “Borrow Book Activity”活动图，如图8.19所示。

图8.19 “Borrow Book Activity”活动图

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

图8.20 “对象属性”对话框

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

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

8.5 测试能力目标

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

A. 类图（Class Diagram）            B. 状态图（State Diagram）

C. 活动图（Activity Diagram）        D. 对象图（Object Diagram）

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

A. 分叉与汇合（Fork and Join）         B. 泳道（Swimlane）

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

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

图8.22 “搜索工作”活动图

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

（2）清找出系统在该流程中相关的活动内容___________________________________。

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

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

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

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

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

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

（2）如果电梯在当前楼层，则电梯门打开（open
the door）；否则，电梯移到当前楼层（lift
move to the current floor），然后电梯门打开；

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

（4）用户按下想去的楼层按钮（press
desired floor button）；

（5）电梯移到那个楼层（go to the floor）；

（6）电梯门打开（the door open），用户离开（leave）；

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

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

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

（2）新建一个文件；

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

（4）键入文档的内容；

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

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

（7）保存该文件；

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

（9）退出Office软件包。

8.6 知识扩展

1. 活动图工具栏

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

表8.1 活动图工具栏按钮

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

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

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

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

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

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

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

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

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

活动图描述的是对象活动的顺序关系以及所遵循的规则，它着重表现的是系统的行为，并非是系统的处理过程；而流程图则着重描述处理过程，它的主要控制结构是顺序、选择（分支）和循环，各个处理过程之间有严格的顺序和时间关系。

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

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

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

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

图8.24 错误提示1

图8.25 错误提示2

第9章  物理模型

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

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

9.1 组件图（Component Diagram）

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

9.1.1 相关知识点

1. 组件（Component）

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

通常存在三种类型的组件：配置组件（Deployment Component）、工作产品组件（Work Product Component）、执行组件（Execution Component）。

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

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

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

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

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

图9.2 组件

2. 接口（Interface）

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

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

图9.3 接口

3. 关系（Relationship）

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

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

图9.4 组件之间的依赖关系

9.1.2 知识点的能力目标

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

9.1.3 实现能力目标的具体要求

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

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

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

9.1.4 需要完成的实验

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

通过分析，确定“图书管理系统”中的组件有：Main Program（主程序），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 “图书管理系统”中组件间的关系

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

（1）打开“Library”模型

（2）新建组件图

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

图9.5 新建组件图

（3）添加组件

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

图9.6 “组件属性”对话框

（4）添加关系

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

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

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

在具体的组件图中，还可以指定实现组件功能的文件，也就是建立组件和功能文件之间的关系，具体方法描述如下。在“组件属性”对话框中选择【Files】选项卡，然后在中间空白区域任意位置右键单击，会弹出如图9.9所示的快捷菜单，在弹出的快捷菜单中选择【Insert File】菜单项，可以添加实现该组件功能的文件。若指定的文件存在，如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 创建文件提示框

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

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

图9.12 图书管理系统组件图

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

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

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

（1）创建数据库

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

图9.13 创建数据库

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

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

（2）创建表空间

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

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

图9.16 创建表空间

（3）创建计划

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

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

图9.17 创建计划

图9.18 “计划属性”对话框

（4）创建数据模型图

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

展开视图区域树型列表中的【Logical View】结点，选择Schemas包下的“S_0”计划，右键单击该计划，在弹出的快捷菜单中选择【Data Modeler】->【New】->【Data
Model Diagram】便可创建数据模型图，如图9.19所示。新创建的数据模型图默认名称为“NewDiagram”，在此根据实际情况将名称修改为“Libraray DataModel”。双击“Libraray
DataModel”数据模型图，打开如图9.20所示的编辑窗口。在数据模型图编辑窗口中可以添加表及表之间的关系等相关内容。

图9.19 创建数据模型图

图9.20 数据模型图编辑窗口

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

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

图9.21 “表属性”对话框

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

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

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

图9.22 添加表的列

图9.23 “列属性”对话框

图9.24 “关系属性”对话框

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

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

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

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

图9.26 生成对象模型

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

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

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

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

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

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

展开视图区域树型列表中的【Logical View】结点，选择Schemas包下的“S_0”计划，右键单击该计划，在弹出的快捷菜单中选择【Data Modeler】->【Forward Engineer...】，如图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”脚本文件具体内容如下：

CREATE TABLE Book (

bookID
SMALLINT NOT NULL,

bookName
VARCHAR ( 30 ) NOT NULL,

pubID
SMALLINT NOT NULL,

author
SMALLINT NOT NULL,

price
SMALLINT NOT NULL,

quantity
SMALLINT NOT NULL,

CONSTRAINT
PK_Book2 PRIMARY KEY (bookID)

);

CREATE TABLE Fine (

fineID
SMALLINT NOT NULL,

borrowID
SMALLINT NOT NULL,

CONSTRAINT
TC_Fine16 UNIQUE (borrowID),

CONSTRAINT
PK_Fine4 PRIMARY KEY (fineID)

);

CREATE TABLE Borrow (

borrowID
SMALLINT NOT NULL,

borrowTypeName
VARCHAR ( 3 ) NOT NULL,

CONSTRAINT
PK_Borrow1 PRIMARY KEY (borrowID)

);

CREATE TABLE Reader (

ID
VARCHAR ( 10 ) NOT NULL,

bookID
SMALLINT NOT NULL,

borrowID
SMALLINT,

CONSTRAINT
PK_Reader0 PRIMARY KEY (ID)

);

CREATE TABLE BookType (

bookTypeID
SMALLINT NOT NULL,

bookTypeName
VARCHAR ( 10 ) NOT NULL,

bookID
SMALLINT NOT NULL,

CONSTRAINT
PK_BookType3 PRIMARY KEY (bookTypeID)

);

ALTER TABLE BookType ADD
CONSTRAINT FK_BookType3 FOREIGN KEY (bookID) REFERENCES Book (bookID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE Fine ADD CONSTRAINT
FK_Fine7 FOREIGN KEY (borrowID) REFERENCES Borrow (borrowID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE Reader ADD CONSTRAINT
FK_Reader5 FOREIGN KEY (bookID) REFERENCES Book (bookID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE Reader ADD CONSTRAINT
FK_Reader6 FOREIGN KEY (borrowID) REFERENCES Borrow (borrowID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

9.1.5 测试能力目标

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

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

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

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

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

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

9.1.6 知识扩展

1. 组件图工具栏

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

表9.2 组件图工具栏按钮

2. 组件和类之间的区别

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

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

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

3. 数据模型图工具栏

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

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

9.2 部署图（Deployment Diagram）

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

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

9.2.1 相关知识点

1. 节点（Node）

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

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

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

在UML中，处理器和设备都被表示为一个附有名称的三维立方体，但代表处理器的三维立方体中有两个侧面带有阴影，如图9.36所示。

2. 连接（Connection）

连接代表一种交流机制，常用于对节点间的物理通信路径或软件通信协议进行建模。

在UML中，连接被表示为一条实线，如图9.37所示。

图9.36 处理器和设备

图9.37 连接

9.2.2 知识点的能力目标

能够抽象出“图书管理系统”中节点及连接，并且使用Rational Rose工具绘制部署图。

9.2.3 实现能力目标的具体要求

1. 抽象出“图书管理系统”中的节点及连接。

2. 使用Rational Rose工具绘制部署图。

9.2.4 需要完成的实验

1. 抽象出“图书管理系统”中的节点及连接。

通过分析，确定“图书管理系统”中的节点有：ApplicationServer（应用服务器）、Printer（打印机）、AdministratorPC（系统管理员PC机）、LibrarianPC（图书管理员PC机）、LibraryPC（图书馆内的自助PC机）、ReaderPC（读者PC机）、DatabaseSever（数据库服务器）。

显而易见，ApplicationServer（应用服务器）节点与其他各节点之间都存在连接。

2. 使用Rational Rose工具绘制部署图。

（1）打开“Library”模型

（2）打开部署图

部署图并不需要创建，因为模型里面已经建立好了部署图，如图9.38所示，在视图区域树型列表中双击【Deployment
View】打开部署图即可，被打开的部署名称为“Deployment Diagram”。

（3）添加节点

在部署图工具栏中选择按钮【】即“Processor”，然后在编辑区中单击鼠标左键，便可将处理器添加到部署图中。添加的处理器默认名称为“NewProcessor”，可在图9.39所示的“处理器属性”对话框中对其进行修改，同时还可以进行其他详细设置。在此处将处理器名称设置为“ApplicationServer”，节点类型设置为“Processor”。

图9.38 打开部署图

图9.39 “处理器属性”对话框

由于处理器具有一定的处理能力，所以在绘图时可以为其指明处理性能、处理进程、处理计划等内容。具体操作方法是：在“处理器属性”对话框中选择【Detail】选项卡，然后在其“Characteristic”栏中书写性能指标；继而在其“Processes:”栏中的空白区域右键单击，在弹出的快捷菜单中选择【Insert】菜单项添加进程，如图9.40所示。

默认情况下，为处理器添加的进程不显示，若要显示则需右键单击该处理器，在弹出的快捷菜单中选择【Show Processes】菜单项，如图9.41所示。

类似地，在部署图工具栏中选择按钮【】即“Device”，便可以将设备节点添加到部署图中。

图9.40 为处理器添加处理内容

图9.41 显示处理器的处理内容

（4）添加连接

参照前面的分析，ApplicationServer节点和AdministratorPC节点之间存在连接，为刻画这种关系，需要在编辑区工具栏中单击连接符号【】即“Connection”，采用按住鼠标左键拖拽的方式，将ApplicationServer节点和AdministratorPC节点连接起来。

若要为连接指定更详细的内容，如连接名称和连接类型等，则可以在如图9.42所示的“连接属性”对话框中进行设置。

图9.42 “连接属性”对话框

此处将连接类型设置为“10/100/1000M Ethernet”（10/100/1000M自适应以太网），设置完的效果如图9.43所示。

图9.43 显示连接类型

按照同样的方法，可以建立ApplicationServer节点与Printer（打印机）、ApplicationServer节点与LibrarianPC（图书管理员PC机）、ApplicationServer节点与LibraryPC（图书馆内的自助PC机）、ApplicationServer节点与ReaderPC（读者PC机）、ApplicationServer节点与DatabaseSever（数据库服务器）各节点间的连接。

综合以上操作，最终完成“图书管理系统”部署图，如图9.44所示。

图9.44 “图书管理系统”部署图

9.2.5 测试能力目标

1. 在UML部署图中，具有计算能力的节点、能够执行软组件的节点，通常被称为_____________。

2. 以下各项不属于设备节点的是（     ）。

A. 扫描仪（Scanner）                      B. 计算机（Computer）

C. 打印机（Printer）                       D. 调制解调器（Modem）

3. 如图9.45所示为家用计算机系统部署图，请根据图示说明该系统中的处理器节点、设备节点、连接。

图9.45 家用计算机系统部署图

9.2.6 知识扩展

1. 处理计划（Scheduling）中各选项的含义

如前所述，在为处理器指定处理性能、处理进程的同时，还可以指定处理计划。现将处理计划各选项（即在图9.40所示的对话框中“Scheduling”栏各选项）的含义说明如下，详见表9.4所示。

表9.4 处理计划中选项的含义

2. 部署图工具栏

部署图工具栏上的按钮名称及功能，详见表9.5。

表9.5 部署图工具栏按钮

3. 绘制部署图时的错误提示

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

图9.46 关于连接的错误提示

第10章  双向工程

双向工程包括正向工程和逆向工程。正向工程指的是从UML模型生成具体语言代码的过程；而逆向工程则与此相反，指的是从具体语言代码生成UML模型的过程。无论是从代码到模型，还是从模型到代码，都是一项复杂的工作。Rational Rose建模工具将二者有机地整合在了一起，提供了模型框架与代码框架进行双向交换的机制。本章在全书知识体系中的位置如图10.1所示。

10.1 正向工程

10.1.1 相关知识点

正向工程能够从UML模型（主要是静态模型中的类图）直接生成代码框架，这为程序员节省了大量用于编写类、定义属性和方法等琐碎代码的时间。正向工程的指导思想就在于框架，一个成熟的框架可以让开发人员思路更清晰。

以Java作为模型语言为例，正向工程就是从Rational Rose模型中的一个或多个类图生成Java源代码的过程。Rational Rose的正向工程是以组件为中心的，也就是说Java源代码的生成是基于组件的而不是基于类的，所以在创建一个类后需要将它分配给一个组件（具体内容参见第9章物理模型中组件图的相关介绍）。如果模型的缺省语言是Java，Rational Rose会自动为这个类创建一个组件。

对一个Java模型元素进行正向工程时，模型的特征会映射为对应的Java语言的特征。比如Rational Rose类图中的一个类会通过组件生成一个.java文件；Rational
Rose中的包会生成Java中的一个包。

10.1.2 知识点的能力目标

利用Rational
Rose工具的正向工程，以“图书管理系统”为例，将其类模型中的Admin类、Librarian类等，生成Java源代码。

10.1.3 实现能力目标的具体要求

1. 设置模型的缺省语言为Java。

2. 设置类路径和代码生成属性。

3. 对“图书管理系统”模型进行语法检查。

4. 将“图书管理系统”类图生成Java源代码。

5. 浏览代码。

10.1.4 需要完成的实验

1. 设置模型的缺省语言为Java。

在主菜单栏中选择【Tools】->【Options...】菜单，然后在弹出的窗口中选择【Notation】选项卡，在该选项卡的“Default”栏下拉列表中选择“Java”作为模型的缺省语言，确定即可，如图10.2所示。

图10.2 设置缺省语言

2. 设置类路径和代码生成属性。

在主菜单栏中选择【Tools】->【Java/J2EE】->【Project
Specification】菜单，然后在弹出的“工程属性”对话框中选择【Classpath】选项卡可以为模型指定一个Java类路径，如图10.3所示。

图10.3 设置Classpath

继续在“工程属性”对话框中选择【Code Generation】选项卡，可以对正向工程的代码生成属性进行相关设置，如图10.4所示。其中各选项的含义详见表10.1。

3. 对“图书管理系统”模型进行语法检查。

在生成代码之前，可以采用手动方式对模型组件进行语法检查。在生成代码时，Rational Rose会自动进行语法检查。此步骤为可选步骤，具体方法描述如下。

图10.4 设置Code Generation

表10.1 代码生成属性中各选项的含义

（1）打开包含用于生成代码的模型图。

启动Rational Rose后，首先打开“Library”模型，然后在左侧视图区域树型列表中展开【Logical View】逻辑视图，进一步打开该视图下的“Library Class”类图。在该类图中存在两个包，即Business Package和GUI Package，双击每个包打开其中的类模型图即可。

（2）检查模型

在主菜单中选择【Tools】->【Check Model】，从日志窗口中观察错误提示。如果有错误，信息将显示在日志窗口中，如图10.5所示。

图10.5 检查模型

（3）检查访问问题

如果要发现访问（如寻找不同包中两个类之间是否存在关系）问题，可以在主菜单中选择【Report】->【Show
Access Violations】来进行检查，访问窗口将提示是否存在问题，如图10.6所示。

（4）检查语法

在主菜单中选择【Tools】->【Java/J2EE】->【Syntax
Check】，可以进行语法检查，如图10.7所示。

图10.6 检查访问问题

图10.7 检查语法

对于模型语法检查中存在的问题，可以进行更正，以保证语法正确。

4. 将“图书管理系统”类图生成Java源代码。

在打开的类图中，选定要生成Java源代码的类（如Admin类及其子类Librarian），然后在主菜单中选择【Tools】->【Java/J2EE】->【Generate
Code】，如图10.8所示。

图10.8 生成代码

接下来在弹出的“指定类路径入口”对话框中指定保存Java源代码的路径以及包名等内容，最后确定即可。如图10.9所示，此处指定保存源代码路径为“D:\Rose&Java”，包名为“BusinessPackage”。

图10.9 指定类路径入口

5. 浏览代码。

代码生成以后，可以在保存路径中找到对应的Java源文件，如图10.10所示为生成的Admin.java文件和Librarian.java文件。

图10.10
定位Java源文件

与此同时，可以浏览Admin.java文件的详细代码：

//Source file:
D:\\Rose&Java\\BusinessPackage\\Admin.java

package BusinessPackage;

public class Admin

{

/**

* @roseuid
4D523D380242

*/

public Admin()

{

}

}

另外，还可以通过浏览Librarian.java文件的详细代码，确定Rational Rose是否在生成的代码中保持了模型中原有的继承关系，子类Librarian源代码如下：

//Source file:
D:\\Rose&Java\\BusinessPackage\\Librarian.java

package BusinessPackage;

public class Librarian extends
Admin

{

private int libID;

private int
libName;

private int
libPassword;

/**

* @roseuid
4D523D3801D4

*/

public Librarian()

{

}

/**

* @roseuid
4D33EE8D037A

*/

public void
manageBook()

{

}

/**

* @roseuid
4D33EE95034B

*/

public void
manageReader()

{

}

/**

* @roseuid
4D33EE9D036B

*/

public void
manageFine()

{

}

/**

* @roseuid
4D33EEF101D4

*/

public void
manageBorrow()

{

}

/**

* @roseuid
4D33EF250119

*/

public void
query()

{

}

}

通过浏览以上代码，可以明确Admin类和Librarian类完好地保持了模型中的继承关系。遵循以上的操作步骤，能够将“图书管理系统”类图中的所有类生成相应的Java源代码。开发人员便可以在此代码框架的基础上给出具体的方法实现，从而节省开发时间、提高开发效率。

10.1.5 测试能力目标

1. 从UML模型生成代码框架的过程称为___________工程。

2. 在Rational Rose选择【Tools】->【Java/J2EE】菜单实现正向工程时，选择下列哪一项，可以实现代码生成功能。

A. Edit Code                                     B.
Syntax Check

C. Project Specification                      D. Generate Code

3. 利用Rational Rose正向工程，将第4章4.2.5测试能力目标中10、11、12题的类图生成Java源代码。

10.1.6 知识扩展

利用Rational
Rose正向工程，将UML模型生成语言代码时，并不是所有语言都被支持。一般情况下，在【Tools】的子菜单中可以查看Rational Rose所支持的模型语言，如果在其子菜单中没有列举出全部的语言种类，还可以选择主菜单中【Add-Ins】->【Add-In Manage】，在弹出的“插件管理器”对话框中，设置显示或隐藏各种语言的生成菜单，如图10.11所示。

图10.11
语言选择界面

通过观察发现，插件管理器中并未列举出C#语言，如果要实施C#语言的正向工程，需要选择其他建模工具。

10.2 逆向工程

10.2.1 相关知识点

逆向工程能够从现有的语言代码生成UML模型（如类图、组件图、数据模型图等），这对达到设计模型和实现模型的同步大有益处；尤其是在为大型软件系统做二次开发时，开发人员可以利用逆向工程生成的模型，来更好地了解系统原来的组织结构，以方便团队内部讨论以及制定改进方案。

Rational Rose建模工具所支持的逆向工程拥有非常强大的功能，它不仅支持多种编程语言（如C++、VB、VC、Java、CORBA等）；而且还支持多种数据库（如SQL Server、Oracle、DB2、Sybase等）。

10.2.2 知识点的能力目标

利用Rational
Rose工具的逆向工程，以“图书管理系统”为例，将已有的Java源代码（即正向工程中得到的源代码）生成类模型。

10.2.3 实现能力目标的具体要求

1. 检查类路径。

2. 加载“图书管理系统”源代码。

3. 生成“图书管理系统”类图。

10.2.4 需要完成的实验

1. 检查类路径。

进行逆向工程时，必须要有JDK（Java Development Kit）类库的支持。Classpath类路径可以指向不同类型的类库文件，如.zip，.jar等。有关Classpath的配置，可以从“环境变量”中进行设置（具体参见Java相关教程）。

2. 加载“图书管理系统”源代码。

（1）选择Java逆向工程。

启动Rational
Rose后，在主菜单中选择【Tools】->【Java/J2EE】->【Reverse
Engineer】，如图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 生成的类

3. 生成“图书管理系统”类图。

采用按住鼠标左键拖拽的方式，将生成的类从左侧视图区域拖放到右侧绘图区域，便可以得到相应的类图，如图10.15所示为Admin类、Administrator类和Librarian.java类构成的类图。遵循同样的方法，能够得到“图书管理系统”的完整类图。

10.2.5 测试能力目标

1. 在软件的迭代开发周期中，通常采用___________达到设计模型与实现模型的同步。

2. 下列关于正向工程和逆向工程的描述，错误的是（     ）。

A. 正向工程是把模型转换为代码的过程。

B. 逆向工程是把代码转换为模型的过程。

C. 正向工程是把代码转换为模型的过程。

D. 逆向工程是把模型转换为代码的过程。

E. 正向工程和逆向工程都可以通过Rational
Rose工具来实现。

3. 应用Java语言编写一个简单的学籍管理系统，并借助Rational Rose工具实施逆向工程，将其中的Java源代码转换成UML模型。

图10.15 生成的类图

10.2.6 知识扩展

1. 逆向工程中类属性的表现形式

利用Rational
Rose实施逆向工程时，类的属性可能表现为如图10.16左图的形式，即在“String”类型前附加了“Logical View::java::lang::”前缀，该前缀指明了视图名称和包名称，实际应用时可根据具体情况选择是否删除该前缀。删除后的表现形式更为简洁，如图10.16右图所示。

图10.16 属性的表现形式

2. 逆向工程中的错误提示

在进行逆向工程时，如果Rational Rose弹出如图10.17所示的错误提示框，则说明操作有误，该错误提示的含义为：在实施逆向工程时发生错误，详情见Rose日志窗口。单击【确定】按钮后，在日志窗口中可以查看错误详情提示，如图10.18所示。一般情况下，该问题可以通过检查类路径、包路径及Java源文件的正确性来解决。

图10.17 关于逆向工程的错误提示

图10.18 日志窗口中的错误详情提示

第11章  综合案例实训

前面已经介绍了关于建模基础和建模技术的相关内容，本章主要通过两个综合实例（“BBS论坛系统”和“基于Web的求职招聘系统”），加深读者对UML基础与Rose建模的理解和掌握。本章在全书知识体系中位置如图11.1所示。

11.1 BBS论坛系统

11.1.1 相关知识点

BBS（Bulletin
Board System，电子公告牌系统）俗称论坛系统，是互联网上一种交互性极强、网友喜闻乐见的信息服务形式。根据相应的权限，论坛用户可以进行浏览信息、发布信息、回复信息、管理信息等操作，从而加强不同用户间的文化交流和思想沟通。

经过调查分析，最终确定“BBS论坛系统”的基本模块有：用户管理、版块管理、帖子管理、友情链接管理、广告管理。

其中各基本模块的功能大体说明如下：

（1）用户管理主要包括用户注册、用户登录、用户资料修改等功能。

（2）版块管理主要包括增加版块、编辑版块、删除版块等功能。

（3）帖子管理主要包括发布帖子、回复帖子、浏览帖子、转移帖子、编辑帖子、删除帖子、帖子加精、帖子置顶等功能。

（4）友情链接管理主要包括增加链接、修改链接、删除链接等功能。

（5）广告管理主要包括放置广告、删除广告等功能。

另外，需要说明的是，以上各项功能中有些功能只需要普通用户权限就能够完成，而有些功能则需要版主或管理员权限才能完成。

结合前述需求分析，可以得出论坛系统的总体结构图，如图11.2所示。

图11.2 “BBS论坛系统”总体结构图

11.1.2 知识点的能力目标

根据11.1.1相关知识点介绍，借助Rational Rose工具，按照“用例建模”、“静态建模”、“动态建模”、“物理建模”、“双向工程”的顺序对“BBS论坛系统”进行UML建模。

11.1.3 实现能力目标的具体要求

1. 用例建模

（1）分析系统参与者。

（2）分析系统用例，并使用自然语言对主要用例进行文档阐述。

（3）分析系统用例模型中的关系。

（4）借助Rational
Rose工具绘制出“BBS论坛系统”用例图。

2. 静态建模

（1）识别系统中的类，并根据实际情况确定类的属性和操作。

（2）识别系统中各类之间的关系。

（3）借助Rational
Rose工具绘制出“BBS论坛系统”类图。

3. 动态建模

（1）识别系统中既定场景的对象、消息等要素，并借助Rational Rose工具绘制出相应的时序图。

（2）识别系统中既定场景的对象、消息等要素，并借助Rational Rose工具绘制出相应的协作图，或将现有的时序图转换成协作图。

（3）捕获系统中指定对象的状态，并借助Rational Rose工具绘制出相应的状态图。

（4）捕获系统中指定对象或指定用例的活动，并借助Rational Rose工具绘制出相应的活动图。

4. 物理建模

（1）分析系统中的组件及组件间的关系，并借助Rational Rose工具绘制出“BBS论坛系统”组件图。

（2）结合静态模型，借助Rational Rose工具绘制“BBS论坛系统”数据模型图。

（3）分析系统中的节点及节点间的连接，并借助Rational Rose工具绘制出“BBS论坛系统”部署图。

5. 双向工程

（1）利用Rational
Rose工具的正向工程，将“BBS论坛系统”的类模型生成相应的Java源代码。

（2）利用Rational
Rose工具的逆向工程，将“BBS论坛系统”已有的Java源代码（即正向工程中得到的源代码）生成类模型。

11.1.4 需要完成的实验

1. 用例建模

（1）分析系统参与者。

遵循识别参与者的方法，可以初步分析出“BBS论坛系统”中的主要参与者有：Anonymous User（匿名用户）、Member（注册用户）、Editor（版主）、Administrator（管理员），如图11.2所示。

图11.2 “BBS论坛系统”的参与者

Anonymous User（匿名用户）：通过使用系统进行帖子搜索、帖子浏览等。

Member（注册用户）：通过使用系统进行帖子搜索、帖子浏览、帖子发布、帖子回复、帖子编辑以及个人信息修改等。

Editor（版主）：除拥有普通用户的职责外，还可以通过使用系统进行版块管理、公告发布等。

Administrator（管理员）：除拥有普通用户的职责外，还可以通过使用系统进行用户管理、帖子管理、版块管理、公告管理等。

（2）分析系统用例，并使用自然语言对主要用例进行文档阐述。

针对分析出的系统主要参与者（匿名用户、注册用户、版主、管理员）的功能需求，可以初步确定“BBS论坛系统”中主要用例包括：Search Article（搜索帖子）、Browse Article（浏览帖子）、Register（注册）、Login（登录）、Issue Article（发布帖子）、Reply Article（回复帖子）、Modify Article（修改帖子）、Modify Info（修改资料），Displace Article（转移帖子）、Delete Article（删除帖子）、Place Peak（帖子置顶）、Extract Article（帖子加精）、Add Edition（增加版块）、Modify Edition（修改版块）、Delete Edition（删除版块）、Add Link（增加链接）、Modify Link（修改链接）、Delete Link（删除链接）、Add Advertise（增加广告）、Delete Advertise（删除广告）。

综合对“BBS论坛系统”中参与者和相关系统功能的分析，将该系统的全部用例说明如下，详见表11.1所示。

表11.1 “BBS论坛系统”用例说明

（3）分析系统用例模型中的关系。

显然，四个参与者即Anonymous User（匿名用户）、Member（注册用户）、Editor（版主）、Administrator（管理员）之间依次存在泛化关系。

另外，还可以确定Anonymous User（匿名用户）、Member（注册用户）、Editor（版主）、Administrator（管理员）和与其相关的用例之间存在关联关系。

Member（注册用户）相关的Issue Article（发布帖子）用例、Reply Article（回复帖子）用例、Modify Article（修改帖子）用例、Modify Info（修改资料）用例包含一个公共的用例，就是Login（登录）用例，它们与Login（登录）用例存在包含关系；同样Login（登录）用例与Register（注册）用例之间也存在包含关系。

（4）借助Rational
Rose工具绘制出“BBS论坛系统”用例图

根据以上分析，借助Rational Rose工具绘制系统参与者之间的关系，如图11.3所示；绘制Anonymous User（匿名用户）与其关联的用例之间的关系，如图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论坛系统”用例图

2. 静态建模

（1）识别系统中的类，并根据实际情况确定类的属性和操作。

基于MVC三层架构的思想，将系统中的类按照实体类、边界类、控制类来划分。

其中实体类有：User（用户）、Administrator（管理员）、Article（帖子）、Edition（版块）、Link（链接）、Advertise（广告）、UserData（用户信息）、ArticleData（帖子信息）、EditionData（版块信息）、LinkData（链接信息）、AdvertiseData（广告信息）、Conn（数据库连接），如图11.9所示。需要说明的是，识别类时将Anonymous User（匿名用户）、Member（注册用户）、Editor（版主）统一抽象为User（用户）类，并依据userGrade属性值标识其具体身份。

图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 系统中的控制类

（2）识别系统中各类之间的关系。

分析得出“BBS论坛系统”中各个类之间关系如表11.2所示。

表11.2 系统中各类之间的关系

（3）借助Rational
Rose工具绘制出“BBS论坛系统”类图。

由于该系统总体类图较复杂，所以将其划分为如下六个子图：Mange User（用户管理）子图，如图11.12所示；Manage
Article（帖子管理）子图，如图11.13所示；Manage Edition（版块管理）子图，如图11.14所示；Manage Link（友情链接管理）子图，如图11.15所示；Manage Advertise（广告管理）子图，如图11.16所示；Manage Module（模块管理）子图，如图11.17所示。

图11.12 
Manage User子图

3. 动态建模

（1）识别系统中既定场景的对象、消息等要素，并借助Rational Rose工具绘制出相应的时序图。

此处以“Login”（用户登录）场景和“Add Edition”（增加版块）为例进行分析和建模。

图11.13 Manage Article子图

图11.14 Manage Edition子图

“Login”（用户登录）的具体处理流程为：User（用户）通过user.jsp输入登录信息，然后其登录信息交由UserServlet处理，继而UserServlet将登录信息传递给User进行封装，接着再由UserData查询判断用户输入的登录信息是否与数据库中的信息一致，最后由UserServlet根据判断结果给出是否成功登录的提示信息。详见图11.18所示。

图11.15 Manage Link子图

图11.16 Manage Advertise子图

图11.17 Manage Module子图

图11.18 “Login”的处理流程

根据以上处理流程，得出“Login”（用户登录）场景时序图，如图11.19所示。

图11.19 “Login”时序图

“Add Edition”（增加版块）的具体处理流程为：Administrator（管理员）通过edition.jsp输入版块相关信息，然后交由EditionServlet处理，继而EditionServlet将版块信息传递给Edition进行封装，接着EditionServlet调用EditionData中相应的方法对数据库进行操作。详见图11.20所示。

图11.20 “Add Edition”的处理流程

根据以上处理流程，得出“Add Edition”（增加版块）场景时序图，如图11.21所示。

图11.21 “Add Edition”时序图

（2）识别系统中既定场景的对象、消息等要素，并借助Rational Rose工具绘制出相应的协作图，或将现有的时序图转换成协作图。

此处仍以“Login”（用户登录）场景和“Add Edition”（增加版块）为例，利用Rational Rose工具将其时序图直接转化成协作图。

最终生成的“Login”（用户登录）场景协作图，如图11.22所示，生成的“Add Edition”（增加版块）场景协作图，如图11.23所示，

（3）捕获系统中指定对象的状态，并借助Rational Rose工具绘制出相应的状态图。

此处以Member（注册用户）对象、Article（帖子）对象、Edition（版块）对象为例，绘制其状态图。

最终得到注册用户的状态图如图11.24所示，帖子的状态图如图11.25所示，版块的状态图如图11.26所示。

图11.22 “Login”协作图

图11.23 “Add Edition”协作图

图11.24 注册用户的状态图

图11.25 帖子的状态图

图11.26 版块的状态图

（4）捕获系统中指定对象或指定用例的活动，并借助Rational Rose工具绘制出相应的活动图。

以捕获“Search
Article”（搜索帖子）用例的活动为例，绘制“Search Article”活动图如图11.27所示。

图11.27 “Search Article”活动图

再以捕获“Delete
Edition”（删除版块）用例的活动为例，绘制“Delete Edition”活动图如图11.28所示。

图11.28 “Delete Edition”活动图

4. 物理建模

（1）分析系统中的组件及组件间的关系，并借助Rational Rose工具绘制出“BBS论坛系统”组件图。

通过分析，确定“BBS论坛系统”中的组件有：BBS System（BBS论坛系统Web应用程序）、Manager
User（用户管理）、Manage Article（帖子管理）、Manage Edition（版块管理）、Manage Link（友情链接管理）、Manage Advertise（广告管理）。

以上各组件中有部分组件存在依赖关系，详见表11.3所示。

表11.3 “BBS论坛系统”中组件间的关系

最终完成“BBS论坛系统”组件图，如图11.29所示。

图11.29 “BBS论坛系统”组件图

（2）结合静态模型，借助Rational Rose工具绘制“BBS论坛系统”数据模型图。

借助Rational
Rose工具绘制“BBS论坛系统”数据模型图，如图11.30所示。

图11.30 “BBS论坛系统”数据模型图

另外，还可以从以上数据模型中导出数据库或DDL（数据库定义语言）脚本，导出的“BBS_DB.ddl”脚本文件具体内容如下：

CREATE TABLE Link (

linkID
SMALLINT NOT NULL,

linkName
VARCHAR ( 20 ) NOT NULL,

linkURL
VARCHAR ( 80 ) NOT NULL,

CONSTRAINT
PK_Link5 PRIMARY KEY (linkID)

);

CREATE TABLE Administrator (

adminID
SMALLINT NOT NULL,

adminName
VARCHAR ( 20 ) NOT NULL,

adminPassword
VARCHAR ( 20 ) NOT NULL,

CONSTRAINT
PK_Administrator1 PRIMARY KEY (adminID)

);

CREATE TABLE Article (

articleID
SMALLINT NOT NULL,

articleName
VARCHAR ( 16 ) NOT NULL,

articleContent
VARCHAR ( 500 ) NOT NULL,

editionID
SMALLINT NOT NULL,

CONSTRAINT
PK_Article3 PRIMARY KEY (articleID)

);

CREATE TABLE Edition (

editionID
SMALLINT NOT NULL,

editionInfo
VARCHAR ( 500 ) NOT NULL,

editionName
VARCHAR ( 116 ) NOT NULL,

CONSTRAINT
PK_Edition4 PRIMARY KEY (editionID)

);

CREATE TABLE Advertise (

advertiseID
SMALLINT NOT NULL,

advertiseName
VARCHAR ( 20 ) NOT NULL,

advertiseWord
VARCHAR ( 100 ) NOT NULL,

CONSTRAINT
PK_Advertise6 PRIMARY KEY (advertiseID)

);

CREATE TABLE User (

userID
VARCHAR ( 20 ) NOT NULL,

userName
VARCHAR ( 20 ) NOT NULL,

userPassword
VARCHAR ( 20 ) NOT NULL,

userGrade
VARCHAR ( 1 ) NOT NULL,

CONSTRAINT
PK_User0 PRIMARY KEY (userID)

);

ALTER TABLE Article ADD
CONSTRAINT FK_Article6 FOREIGN KEY (editionID) REFERENCES Edition
(editionID)  ON DELETE NO ACTION ON
UPDATE NO ACTION;

（3）分析系统中的节点及节点间的连接，并借助Rational Rose工具绘制出“BBS论坛系统”部署图。

通过分析，确定“BBS论坛系统”中的节点有：ApplicationServer（应用服务器）、DatabaseSever（数据库服务器）及若干个Customer（客户机）。

显而易见，ApplicationServer（应用服务器）节点与其他各节点之间都存在连接。

借助Rational
Rose工具绘制“BBS论坛系统”部署图，如图11.31所示。

图11.31 “BBS论坛系统”部署图

5. 双向工程

（1）利用Rational
Rose工具的正向工程，将“BBS论坛系统”的类模型生成相应的Java源代码。

借助Rational
Rose的正向工程将类模型生成代码以后，可以在保存路径中找到对应的Java源文件，如图11.32所示。

浏览Administrator.java文件的详细代码：

//Source file: D:\\Rose&Java\\Administrator.java

public class Administrator extends User

{

private int adminID;

private int
adminName;

private int
adminPassword;

/**

* @roseuid 4D622F1902EE

*/

public
Administrator()

{

}

图11.32 生成Java源文件

/**

* @roseuid 4D5C9989036B

*/

public void
setAdminID()

{

}

/**

* @roseuid 4D5C98D6032C

*/

public void
getAdminID()

{

}

/**

* @roseuid 4D5C99B701B5

*/

public void
setAdminName()

{

}

/**

* @roseuid 4D5C98DF0203

*/

public void
getAdminName()

{

}

/**

* @roseuid 4D5C99BD02FD

*/

public void
setAdminPass()

{

}

/**

* @roseuid 4D5C99C90290

*/

public void
getAdminPass()

{

}

}

（2）利用Rational
Rose工具的逆向工程，将“BBS论坛系统”已有的Java源代码（即正向工程中得到的源代码）生成类模型。

读者可参照第10章双向工程的介绍自行练习，将“BBS论坛系统”已有的Java源代码生成类模型。

11.1.5 测试能力目标

选择一个熟悉的软件系统（如“学生管理系统”、“教务管理系统”等），借助Rational　Rose工具，按照“用例建模”、“静态建模”、“动态建模”、“物理建模”、“双向工程”的顺序对其进行UML建模。

11.1.6 知识扩展

1. 传统的瀑布开发模型

最早的软件开发模型是1970年提出的瀑布模型，而后随着软件工程学科的发展和软件开发实践的推进，又相继出现了原型模型、演化模型、增量模型、喷泉模型等。瀑布模型将软件生命周期划分为八个阶段：问题定义、可行性研究、需求分析、总体设计、详细设计、编码实现、测试运行、使用维护，如图11.33所示。其中各个阶段的工作按顺序开展，上一个阶段的工作成果是下一个阶段的工作前提。

不难看出，瀑布模型规定了一个标准流程，整个软件开发过程严格按照这个流程来实施，有效避免了盲目、混乱局面的出现。但是也必须看到，瀑布模型仍有其与生俱来的局限性。因为它要求在软件开发的初始阶段就捕获用户的全部需求，这显然是十分困难的，甚至是不切实际的。另外，在需求确定以后，如果用户临时提出变更需求，那么瀑布模型由于其不可回溯性也将不能灵活应对。

图11.33 瀑布模型

2. RUP的迭代开发模型

RUP（Rational Unified
Process，统一软件过程）是由Rational公司推出的软件开发模型框架，它吸收了多种开发模型的优点，具有良好的操作性和实用性。

RUP可以用二维坐标来描述，如图11.34所示。其中横轴以时间来组织，是过程展开的生命周期特征，体现开发过程的动态结构；用来描述它的术语主要包括周期、阶段、迭代和里程碑。纵轴以内容来组织，为自然的逻辑活动，体现开发过程的静态结构；用来描述它的术语主要包括活动、产物、工作者和工作流。

图11.34
RUP开发模型

从上图可以看出，RUP将软件生命周期划分为四个阶段：Inception（初始）阶段、Elaboration（细化）阶段、Construction（构造）阶段、Transition（交付）阶段。

（1）Inception（初始）阶段

初始阶段是项目的基础阶段，该阶段的主要参与人员是项目经理和系统设计师。初始阶段的目标是对系统进行可行性分析、创建基本需求、识别软件系统的关键任务。

（2）Elaboration（细化）阶段

细化阶段的目标是创建可执行的构件基准、精化风险评估、定义质量属性、捕获大部分的系统功能需求用例，为构造阶段创建详细的计划。细化阶段是开发过程中最重要的阶段。细化的焦点是需求、分析和设计工作流。

（3）Construction（构造）阶段

构造阶段的目标是完成所有的需求、分析和设计。细化阶段的成果将演化为最终系统，构造的主要问题是维护系统框架的完整性。构造的焦点是实现工作流。

（4）Transition（交付）阶段

交付阶段的目标是将完整的系统部署到用户所处的环境。交付的内容包括修复系统缺陷、为用户环境准备新软件、创建用户使用手册和系统文档、提供用户咨询。

RUP的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，即最终产品的子集，它增量式地发展（从一个迭代过程到另一个迭代过程），直到成为最终的软件系统。

与传统的瀑布模型相比，RUP的迭代模型降低了开发风险，因为开发人员重复某个迭代承担的只是本次迭代的开发风险。另外，与传统的瀑布模型相比，RUP的迭代模型加快了开发进程，因为开发人员清楚问题的焦点所在，这样使得工作更有效率。

11.2 基于Web的求职招聘系统

11.2.1 相关知识点

极速发展的时代，企业对于人才的需求突飞猛进。“基于Web的求职招聘系统”正是在这样的背景下应运而生的，它为求职者和招聘者提供了一个虚拟化、智能化的人才市场，其主要目的是为了拉近求职者和应聘者之间的距离，以便于求职者能够找到合适的工作，招聘者能够找到合适的人才。当用户进入该系统时，可以根据各自的需求和权限注册为求职者、招聘者以及管理员，然后行使系统为其提供的相应功能。

经过调查分析，最终确定“基于Web的求职招聘系统”的基本模块有：求职模块、招聘模块、管理模块。其中各基本模块的功能大体说明如下：

（1）求职模块主要包括更新求职者资料、搜索招聘信息、发布求职意向、投递简历、查看求职邮箱等功能。

（2）招聘模块主要包括更新招聘者资料、搜索应聘信息、发布招聘信息、查看招聘邮箱、浏览应聘简历、回复求职者等功能。

（3）管理模块主要包括更新管理员资料、管理求职者、管理招聘者、管理新闻等功能。

结合前述需求分析，可以得出论坛系统的总体结构图，如图11.35所示。

图11.35
“基于Web的求职招聘系统”总体结构图

11.2.2 知识点的能力目标

根据11.2.1相关知识点的介绍，借助Rational　Rose工具，按照“用例建模”、“静态建模”、“动态建模”、“物理建模”、“双向工程”的顺序，对“基于Web的求职招聘系统”进行UML建模。

11.2.3 实现能力目标的具体要求

1. 用例建模

（1）分析系统参与者。

（2）分析系统用例。

（3）分析系统用例模型中的关系。

（4）借助Rational
Rose工具绘制出“基于Web的求职招聘系统”用例图。

2. 静态建模

（1）识别系统中的类，并根据实际情况确定类的属性和操作。

（2）识别系统中各类之间的关系。

（3）借助Rational
Rose工具绘制出“基于Web的求职招聘系统”类图。

3. 动态建模

（1）识别系统中既定场景的对象、消息等要素，并借助Rational Rose工具绘制出相应的时序图。

（2）识别系统中既定场景的对象、消息等要素，并借助Rational Rose工具绘制出相应的协作图，或将现有的时序图转换成协作图。

（3）捕获系统中指定对象的状态，并借助Rational Rose工具绘制出相应的状态图。

（4）捕获系统中指定对象或指定用例的活动，并借助Rational Rose工具绘制出相应的活动图。

4. 物理建模

（1）分析系统中的组件及组件间的关系，并借助Rational Rose工具绘制出“基于Web的求职招聘系统”组件图。

（2）结合静态模型，借助Rational Rose工具绘制“基于Web的求职招聘系统”数据模型图。

（3）分析系统中的节点及节点间的连接，并借助Rational Rose工具绘制出“基于Web的求职招聘系统”部署图。

5. 双向工程

（1）利用Rational
Rose工具的正向工程，将“基于Web的求职招聘系统”的类模型生成相应的Java源代码。

（2）利用Rational
Rose工具的逆向工程，将“基于Web的求职招聘系统”已有的Java源代码（即正向工程中得到的源代码）生成类模型。

11.2.4 需要完成的实验

1. 用例建模

（1）分析系统参与者。

遵循识别参与者的方法，可以初步分析出“基于Web的求职招聘系统”中的主要参与者有：User（用户）、Seeker（求职者）、Inviter（招聘者）、Administrator（管理员），如图11.36所示。其中User（用户）是为了实际需要，抽象出来的参与者。

图11.36 “基于Web的求职招聘系统”的参与者

（2）分析系统用例。

针对分析出的系统主要参与者（用户、求职者、应聘者、管理员），可以初步确定“图书管理系统”中主要用例包括：Register（注册）、Login（登录）、Modify Info（更新资料）、Seek Job（搜索招聘信息）、Issue Application（发布求职意向）、Post Resume（投递简历）、Browse SeekMail（查看求职邮箱），Search SeekInfo（搜索应聘信息）、Issue Invitation（发布招聘信息）、Browse Resume（浏览应聘简历）、Browse InviteMail（查看招聘邮箱）、Reply Seeker（回复求职者）、Manage Seeker（管理求职者）、Manage Inviter（管理招聘者）、Manage News（管理新闻）。

下面给出Modify Info（更新资料）用例的阐述文档，其余用例阐述文档读者可以通过自行练习来完成。

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

用例编号：003

用例名称：Modify Info

涉及的参与者：User（用户）

用例概述：用户针对当前的实际情况，修改了个人资料

前置条件：用户已经成功登录到求职招聘系统

后置条件：用户资料更新成功，新的个人资料生效

基本事件流：

1. 用户登录到求职招聘系统

2. 用户发出更新资料请求

3. 系统接受请求，并提示用户输入新的资料

4. 用户输入新的个人资料并确认

5. 系统显示更新后的用户资料

备选流：

1a. 资料格式输入有误

1a1.系统提示用户输入信息有误，提供正确的格式范例

补充说明：

无

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

（3）分析系统用例模型中的关系。

显然，User（用户）、Seeker（求职者）、Inviter（招聘者）、Administrator（管理员）和与其相关的用例之间存在关联关系。User（用户）相关的用例Login（登录）与Register（注册）之间、Modify Info（更新资料）与Login（登录）之间存在包含关系。

另外，还可以确定参与者User（用户）和Seeker（求职者）、Inviter（招聘者）、Administrator（管理员）之间依次存在泛化关系。

（4）借助Rational
Rose工具绘制出“基于Web的求职招聘系统”用例图。

根据以上分析，借助Rational Rose工具绘制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的求职招聘系统”用例图

2. 静态建模

（1）识别系统中的类，并根据实际情况确定类的属性和操作。

此处只对系统中部分实体类进行分析，识别出的实体类有：User（用户）、Seeker（求职者）、Inviter（招聘者）、Administrator（管理员）、Application（求职信息）、Invitation（招聘信息）、Resume（简历）、News（新闻），如图11.43所示。

图11.43 系统中的实体类

（2）识别系统中各类之间的关系

分析得出“基于Web的求职招聘系统”中各实体类之间关系如表11.4所示。

表11.4 系统中各实体类之间的关系

（3）借助Rational
Rose工具绘制出“基于Web的求职招聘系统”类图

由于该系统总体类图较复杂，所以将其划分为如下三个子图：Manage（管理模块）子图，如图11.44所示；Seek（求职模块）子图，如图11.45所示；Invite（招聘模块）子图，如图11.46所示；。

图11.44 Manage子图

图11.45 Seek子图

图11.46 Invite子图

3. 动态建模

（1）识别系统中既定场景的对象、消息等要素，并借助Rational Rose工具绘制出相应的时序图。

此处以“Register”场景为例进行分析和建模，得到的时序图如图11.47所示。

图11.47 “Register”时序图

（2）识别系统中既定场景的对象、消息等要素，并借助Rational Rose工具绘制出相应的协作图，或将现有的时序图转换成协作图。

此处仍以“Register”场景为例，利用Rational Rose工具将其时序图直接转化成协作图。生成的“Register”场景协作图，如图11.48所示。

图11.48 “Register”协作图

（3）捕获系统中指定对象的状态，并借助Rational Rose工具绘制出相应的状态图

此处以Seeker（求职者）对象为例，绘制其状态图，如图11.49所示。

图11.49 Seeker的状态图

（4）捕获系统中指定对象或指定用例的活动，并借助Rational Rose工具绘制出相应的活动图

以捕获“Modify
Info”（更新信息）用例的活动为例，绘制“Modify Info”活动图如图11.50所示。

图11.50 “Modify Info”活动图

4. 物理建模

（1）分析系统中的组件及组件间的关系，并借助Rational Rose工具绘制出“基于Web的求职招聘系统”组件图

通过分析，确定“基于Web的求职招聘系统”中的组件有：Application System（求职招聘系统的Web应用程序）、Seek（求职）、Invite（招聘）、Manage（管理）。以上各组件中有部分组件存在依赖关系，详见表11.5所示。

表11.5 “基于Web的求职招聘系统”中组件间的关系

最终完成“BBS论坛系统”组件图，如图11.51所示。

图11.51 “基于Web的求职招聘系统”组件图

（2）结合静态模型，借助Rational Rose工具绘制“基于Web的求职招聘系统”数据模型图

借助Rational
Rose绘制“基于Web的求职招聘系统”部分数据模型图如图11.52所示。

图11.52 “基于Web的求职招聘系统”部分数据模型图

另外，还可以从以上数据模型中导出数据库或DDL（数据库定义语言）脚本，导出的“S&I.ddl”脚本文件具体内容如下：

CREATE TABLE Seeker (

seekerID
SMALLINT NOT NULL,

seekerName
VARCHAR ( 16 ) NOT NULL,

seekerSex
VARCHAR ( 2 ) NOT NULL,

seekerPassword
SMALLINT NOT NULL,

userID SMALLINT
NOT NULL,

CONSTRAINT
PK_Seeker0 PRIMARY KEY (seekerID)

);

CREATE TABLE Inviter (

inviterID
SMALLINT NOT NULL,

inviterName
VARCHAR ( 50 ) NOT NULL,

InviterPassword
SMALLINT NOT NULL,

userID SMALLINT
NOT NULL,

CONSTRAINT
PK_Inviter1 PRIMARY KEY (inviterID)

);

CREATE TABLE User (

userID SMALLINT
NOT NULL,

userName
VARCHAR ( 50 ) NOT NULL,

userPassword
SMALLINT NOT NULL,

CONSTRAINT
PK_User2 PRIMARY KEY (userID)

);

CREATE TABLE Administrator (

adminID
SMALLINT NOT NULL,

adminName
VARCHAR ( 16 ) NOT NULL,

adminPassword
SMALLINT NOT NULL,

userID SMALLINT
NOT NULL,

CONSTRAINT
PK_Administrator3 PRIMARY KEY (adminID)

);

ALTER TABLE Administrator ADD CONSTRAINT FK_Administrator2
FOREIGN KEY (userID) REFERENCES User (userID) 
ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE Seeker ADD CONSTRAINT FK_Seeker0 FOREIGN KEY
(userID) REFERENCES User (userID)  ON
DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE Inviter ADD CONSTRAINT FK_Inviter1 FOREIGN KEY
(userID) REFERENCES User (userID)  ON
DELETE NO ACTION ON UPDATE NO ACTION;

（3）分析系统中的节点及节点间的连接，并借助Rational Rose工具绘制出“基于Web的求职招聘系统”部署图。

通过分析，确定“基于Web的求职招聘系统”中的节点有：ApplicationServer（应用服务器）、DatabaseSever（数据库服务器）、SeekerPC、（求职者客户机）、InviterPC（招聘者PC客户机）、AdminPC（管理员PC机）。

显而易见，ApplicationServer（应用服务器）节点与其他各节点之间都存在连接。

借助Rational
Rose工具绘制“基于Web的求职招聘系统”部署图，如图11.53示。

图11.53“基于Web的求职招聘系统”部署图

5. 双向工程

（1）利用Rational
Rose工具的正向工程，将“基于Web的求职招聘系统”的类模型生成相应的Java源代码。

借助Rational
Rose的正向工程将类模型生成代码以后，可以在保存路径中找到对应的Java源文件。

以浏览Inviter.java文件为例，其详细代码如下：

//Source file: D:\\Rose&Java\\Inviter.java

public class Inviter extends User

{

private int
inviterID;

private int
inviterName;

private int
inviterPassword;

private int
inviterPhone;

private int
inviterEmail;

private int inviterRID;

public Resume
theResume;

public Application
theApplication;

public Invitation
theInvitation;

public News
theNews;

/**

* @roseuid
4D65D2990157

*/

public Inviter()

{

}

/**

* @roseuid
4D64BEC001E4

*/

public void
setInviterPhone()

{

}

/**

* @roseuid
4D64BEC70177

*/

public void
getInviterPhone()

{

}

/**

* @roseuid
4D64BECC0232

*/

public void
setInviterEmail()

{

}

/**

* @roseuid 4D64BED20280

*/

public void
getInviterEmail()

{

}

/**

* @roseuid
4D64BEDA007D

*/

public void
setInviterRID()

{

}

/**

* @roseuid
4D64BEE00196

*/

public void
getInviterRID()

{

}

}

（2）利用Rational
Rose工具的逆向工程，将“基于Web的求职招聘系统”已有的Java源代码（即正向工程中得到的源代码）生成类模型。

读者可参照第10章双向工程的介绍自行练习，将“BBS论坛系统”已有的Java源代码生成类模型。

11.2.5 测试能力目标

选择一个基于Web的软件系统（如“网上书店系统”、“网上花店系统”等），借助Rational　Rose工具，按照“用例建模”、“静态建模”、“动态建模”、“物理建模”、“双向工程”的顺序，对其进行UML建模。

11.2.6 知识扩展

1. RUP的核心工作流

从图11.34可以看出，RUP包括九个核心工作流：Business Modeling（业务建模）、Requirements（需求分析）、Analysis & Design（分析与设计）、Implementation（实现）、Test（测试）、Deployment（部署）、Configuration & Change
Mgmt（配置和变更管理）、Project Management（项目管理）、Environment（环境）。其详细内容读者可自行参考相关资料介绍。

2. RUP的核心技术特点

（1）用例驱动

通过前面的实例可以看出，需求分析阶段用户需求是借助用例来表达的，设计初期的类是根据用例来发现的，构造阶段开发管理和任务分配是按照用例来组织的，测试阶段的实例是根据用例来生成的。

（2）以构架为中心

架构为用户和研发人员提供系统的管理视图，架构是系统实现的基础，架构为项目管理提供基本指导，架构描述是软件系统的主要制品。

（3）迭代和增量的开发方式

迭代是同一过程中最小的开发时间单位，但它却包括了软件开发的所有工作流，因此可以看作是“袖珍瀑布模型”。增量是每次迭代所产生的、可增加系统功能的构造块。迭代是RUP的开发方式，增量是RUP的开发结果。