10 基于UML的
仓储管理系统的
分析设计
概述
仓储系统业务用例建模
仓储系统需求用例建模
业务领域分析与设计
系统实现测试与配置
10.基于UML的仓储管理系统的分析设计
概述
系统开发背景与开发思想
(1)问题背景
某公司面对过程的仓储管理系统已不能满足企业新业务、
新环境以及客户对信息查询的要求，迫切需要开发一套新系统
实现第三方物流和电子商务的接轨。
(2)系统开发的主要思想
首先对公司的业务与用户的需求进行分析，然后对系统
的功能进行详细的设计，并在分析与设计的同时用UML建模语
言对其建模，采用工具ROSE绘制描述各种模型的图形。
Rational Rose是美国Rational软件公司研制的图形化
的OO CASE工具，是目前最为流行的先进的可视化软件开发
工具之一。它具有可视化建模功能，能帮助系统开发人员和用
户获得规范的OOAD结论，进行结论交流，以及对这些结论的
一致性检查；支持RUP过程。
系统基本功能需求
系统的功能是系统能够完成的操作和任务，本系统的功能
有：
（1）系统能完成入库操作过程中的表与码单的录入；
（2）系统能完成入库过程中货物的审核，记费；
（3）系统能进行有效的库存管理，例如盘点，移库等；
（4）系统能对出库过程中的表与帐单进行管理；
（5）系统能对出库后的平帐，记录储存等进行管理；
（6）系统用户能有效的进行权限，日志的管理；
（7）系统用户可以查询报表，客户，货物等基本信息；
（8）系统能记录下系统的使用日志；
（9）任何人员要使用本系统必须拥有相应的权限。
概述
系统开发过程
结合仓储系统的特点和RUP分析过程，基于UML和RUP
的仓储系统的开发过程：
概述
通用模型元素、用例建模和活动图
(1)通用模型元素
模型元素是UML构造系统的各种元素，是UML构建模型
的基本单位。模型元素代表面向对象中的类，对象，关系和消
息等概念，是构成图的最基本的常用的概念。分为以下两类：
基元素：是已由UML定义的模型元素。如：类、结点、
构件、注释、关联、依赖和泛化等。
构造型元素：在基元素的基础上构造的新的模型元素，
是由基元素增加了新的定义而构成的，如扩展基元素的语义
（不能扩展语法结构）,也允许用户自定义。构造型用括在双尖
括号《》中的字符串表示。
目前UML提供了40多个预定义的构造型元素。如使用
《Use》、扩展《 Extend 》。
仓储系统业务用例建模
①模型元素
可以在图中使用的概念统称为模型元素。模型元素在图中
用其相应的视图元素（符号）表示，下图给出了常用的元素符
号：类、对象、结点、包和组件等。
属性
用例
包
结点
状态
组件
类
操作
对象
属性
操作
接口
注释
仓储系统业务用例建模
关联：连接（connect）模型元素及链接(link)实例。
依赖：表示一个元素以某种方式依赖于另一种元素。
泛化：表示一般与特殊的关系，即“一般”元素是“特殊”
关系的泛化。
聚合：表示整体与部分的关系。
除了上述的模型元素外，模型元素还包括消息，动作和版类
（stereotype）等。
关联
聚合
组合组合
依赖
细化细化
泛化（继承）
模型元素与模型元素之间的连接关系也是模型元素，常见
的关系有关联（association）、泛化（generalization）、
依赖(dependency)和聚合(aggregation)，其中聚合是关联
的一种特殊形式。这些关系的图示符号如下图所示。
仓储系统业务用例建模
(2) 关联和链
关联（association）是两个或多个类之间的一个关系。链
（link)是关联的具体体现。
关联的表示：如下图所示，关联有二元关联(binary)、
三元关联(ternary)、多元关联(higher order)。
（（aa）） 二元关联二元关联
人员 公司
雇用雇用
二元关联的例子
（人员）
张涛
（公司）
通大
雇用雇用
链的例子
（（bb）三元关联）三元关联
项目 语言◆◆
人
三元关联的例子
(项目)
CAD系统
(语言)
C ++◆◆
(人)
李波
链的例子
仓储系统业务用例建模
关联的重数
重数(multiplicity)表示多少个对象与对方对
象相连接(如左图)，常用的重数符号有：
“0..1” 表示零或1
“0..*”或“*” 表示零或多个
“1..*” 表示1或多个
“1,3,7” 表示1或3或7（枚举型）
重数的默认值为1。
Person
Hobby
11
**
带有多重性关联图
有序关联与导航（导引）
在关联的多端标注{ordered}指明这些对
象是有序的(左图）。
关联可以用箭头，表示该关联使用的方
向(单向或双向)，称为导引或导航
(navigation)。
(a)指定链接之间
有明确的顺序
0..*
1..*
{ordered}
保险合同
个人
Polygon
Point
11
4..*
{ordered}
(b)单向关联
仓储系统业务用例建模
(3)约束
UML中提供了一种简便、统一和一致的约束（constraint），
是各种模型元素的一种语义条件或限制。一条约束只能应用于
同一类的元素。
约束的表示：如果约束应用于一种具有相应视图元素的模型
元素，它可以出现在它所约束元素视图元素的旁边。通常一个
约束由一对花括号括起来（{constraint}），花括号中为约束
内容（如下图所示）。
如果一条约束涉及同一种类的多
个元素，则要用虚线把所有受约束的
元素框起来，并把该约束显示在旁边
（如：或约束）。
0..*
1..*
{ordered}
保险合同
个人
Polygon
Point
11
4..*
{ordered}
仓储系统业务用例建模
对泛化的约束的两种表示方法
约束可分为对泛化的约束和关联的约束。
①对泛化的约束：应用于泛化的约束，显示在大括号里，若有
多个约束，用逗号隔开。如果没有共享，则用一条虚线通过所
有继承线，并在虚线的旁边显示约束， 如下图所示。
{constraint 1,constraint 2}
Class A
Class B Class C Class D
{constraint 1,constraint 2}
Class A
Class CClass B Class D
常用的对泛化的约束有：
complete: 说明泛化中所有子元素都已在模型中说明，不允
许再增加其它子元素。
disjoint: 父类对象不能有多于一个型的子对象。
仓储系统业务用例建模
incomplete: 说明不是泛化中所有子元素都已说明，允许再
增加其它子元素。
overlapping: 给定父类对象可有多于一个型的子对象，表示
重载。
②关联的约束：对消息，链接角色和对象的约束；自定义约束。
常用的关联的约束有：
implicit:该关联只是概念性的，在对模型进行精化时不再用。
ordered:具有多重性的关联一端的对象是有序的。
changeable:关联对象之间的链(Link)是可变的（添加、修
改、删除）。
addonly:可在任意时刻增加新的链接。
frozen:冻结已创建的对象，不能再添加、删除和修改它的链
接。
仓储系统业务用例建模
xor: “或约束”，某时刻只有一个当前的关联实例。
(4)依赖
依赖关系描述的是两个模型元素（类，组合，用例等）之间
的语义上的连接关系，其中一个模型元素是独立的，另一个
模型元素是非独立的（或依赖的）。如下图表示类A依赖于类
B的一个友元依赖关系。
帐号
人
单位
{xor}{xor}
对象类的xor关联
类A 类 B《友元》
仓储系统业务用例建模
依赖的形式可能是多样的，针对不同的依赖的形式，依赖关系
有不同的变体(varieties)：
抽象(abstraction)：从一个对象中提取一些特性，并用类方
法表示。
绑定(binding)：为模板参数指定值，以定义一个新的模板元
素。
组合(combination)：对不同类或包进行性质相似融合。
许可(permission)：允许另一个对象对本对象的访问。
使用(usage)：声明使用一个模型元素需要用到已存在的另一
个模型元素，这样才能正确实现使用者的功能(包括调用、实例
化、参数、发送)。
跟踪(trace)：声明不同模型中元素的之间的存在一些连接。
访问或连接(access)：允许一个包访问另一个包的内容。
仓储系统业务用例建模
调用(call)：声明一个类调用其他类的操作的方法。
导出(derive)：声明一个实例可从另一个实例导出。
友元(friend)：允许一个元素访问另一个元素，不管被访问的
元素是否具有可见性。
引入(import)：允许一个包访问另一个包的内容，并为被访问
组成部分增加别名。
实例(instantiation)：关于一个类的方法创建了另一个类的实
例声明。
参数(parameter)：一个操作和它参数之间的关系。
实现(realize)：说明和其实之间的关系。
精化(refine)：声明具有两个不同语义层次上的元素之间的映
射。
发送(send)：信号发送者和信号接收者之间的关系。
仓储系统业务用例建模
(5)细化
有两个元素A和B，若B元素是A元素的详细描述，则称B,A元
素之间的关系为B元素细化A元素。细化与类的抽象层次有密
切的关系，在构造模型时要经过逐步细化,逐步求精的过程。
如左图所示，类B是类A细化的结果。
AA BB
(6)注释
注释用于对UML语言的元素或实体进行说明，解释和描述。
通常用自然语言进行注释。
这是一个类
人员
仓储系统业务用例建模
2. 用例建模(Use case model)
用例建模技术，用于描述系统的功能需求。在宏观上给出
模型的总体轮廓。通过对典型用例的分析，使开发者能够有
效地了解用户的需求。
贸易经理
风险分析
设置边界
进行交易
交易估价
更新帐目
《使用》
《使用》
《扩展》
营销人员
超越边界
评价
记帐系统
销售人员
图
仓储系统业务用例建模
用例模型描述的是外部执行者(Actor)所理解的系统功能。
它描述了待开发系统的功能需求。用例模型驱动了需求分析
之后各阶段的开发工作，不仅在开发过程中保证了系统所有
功能的实现，而且被用于验证和检测所开发的系统，从而影
响到开发工作的各个阶段和 UML 的各个模型。用例模型由若
干个用例图构成，用例图中主要描述执行者和用例之间的关
系。在UML中，构成用例图的主要元素是用例和执行者及其
它们之间的联系。
创建用例模型的工作包括：
定义系统、确定执行者和用例、描述用例、定义用例间的关
系、确认模型。
仓储系统业务用例建模
(1)执行者(Actor)
执行者是指用户在系统中所扮演的角色。执行者在用例图中
是用类似人的图形来表示, 但执行者可以是人，也可以是一
个外界系统。注意：用例总是由执行者启动的。
如何确定执行者：
谁使用系统的主要功能(主执行者)?
谁需要从系统获得对日常工作的支持和
服务？
需要谁维护管理系统的日常运行（副执
行者）？
系统需要控制哪些硬件设备？
系统需要与其它哪些系统交互？
谁需要使用系统产生的结果（值）？
供货
买饮料
取货款
客户
供货人
收银员
自动售货系统
仓储系统业务用例建模
(2)用例(use case)
从本质上讲,一个用例是用户与计算机之间的一次典型交互作
用。在UML中,用例被定义成系统执行的一系列动作（功能）。
用例有以下特点:
用例捕获某些用户可见的需求,实现一个具体的用户目标。
用例由执行者激活,并将结果值反馈给执行者。
用例必须具有功能上的完整描述。
如何确定用例：
与系统实现有关的主要问题是什么？
系统需要哪些输入/输出？这些输入/输出从何而来？到哪里
去？
执行者需要系统提供哪些功能？
执行者是否需要对系统中的信息进行读、创建、修改、删
除或存储？
仓储系统业务用例建模
用例图的元素
(3)用例图
用例图描述了系统的功能需求，它是从执行者的角度来理解系
统，由“执行者”、“用例”和“用例之间的关系”3类模型
元素构成。下图中还有另外两种类型的连接,即《 Use 》和《
Extend 》关系，是两种不同形式的泛化关系。
《Use》表示一个用例使用另一个用例。
《Extend》通过向被扩展的用例添加动作来扩展用例。
用例2
用例A
用例
执行者
用例1
用例3
用例B
《Use》
《 Use 》
《 Extend 》
(a) (b) (c)
仓储系统业务用例建模
制作用例图的步骤：
①分析确定系统的执行者(角色)：项目管理员、
资源管理员、系统管理员、备份数据系统。
②确定用例：项目管理，资源管理和系统管
理。
③对用例进行分解，画出下层的Use case图。
对上层的用例进行分解,并将执行者分配到各
层次的Use case图中，还应画出相应的执行
者描述模板及用例描述模板。
角色：
角色职责：
角色职责识别：
角色描述模板
例题： 建立项目与资源管理系统的Use case图
系统的主要功能是：项目管理，资源管理和系统管理。
项目管理包括项目的增加、删除、更新。资源管理包括对资
源和技能的添加、删除和更新。系统管理包括系统的启动和
关闭，数据的存储和备份等功能。
仓储系统业务用例建模
例:项目与资源管理系统（PRMS）
添加技能
删除技能
更新技能
资源管理员
添加资源
删除资源
更新资源
查找技能
《Use
》
查找资源
《Use
》
《Use
》
《Use
》
把技能指
定给资源
从资源中
清除技能
《Extend
》
《Extend
》
资源管理Use Case图
Use Case图可以自顶而下不断精
化，抽象出不同层次的Use Case
图。
系统管理员
项目管理员
资源管理员
资源管理
项目管理
系统管理
备份系统备份系统
PRMS高层Use Case图
仓储系统业务用例建模
项目
管理员
添加项目
删除项目
更新项目
添加活动
删除活动
更新活动
查找项目
《Use
》
添加任务
《Use
》
把技能指
定给资源
从资源中
清除技能
《Extend
》
《Extend
》
删除任务
更新任务
《Extend
》
《Extend
》
《Extend
》
《Extend
》
《Extend
》
《Extend
》
项目管理项目管理Use CaseUse Case图图
系统管理员
系统管理系统管理Use CaseUse Case图图
添加技能
存储数据
启动系统
关闭系统
查找技能
《Use
》
《Use
》
《Use
》
备份资
源数据
备份项
目数据
《 Extend
》
《 Extend
》
《Use
》
备份数据
备份系统
仓储系统业务用例建模
3. 活动图
活动图(Activity Diagram)的应用非常广泛，它既可用来描述
操作(类的方法)的行为，也可以描述用例和对象内部的工作过
程，并可用于表示并行过程。活动图是由状态图变化而来的，
它们各自用于不同的目的。活动图描述了系统中各种活动的执
行的顺序。刻化一个方法中所要进行的各项活动的执行流程。
活动图中一个活动结束后将立即进入下一个活动(在状态图中状
态的变迁可能需要事件的触发)。
(1)活动图的模型元素
构成活动图的模型元素有：活动、转移、对象、信号、泳道
等。
仓储系统业务用例建模
活动：是构成活动图的核心元素，是具有内部动作的状态，
由隐含的事件触发活动的转移。活动的解释依赖于作图的目的
和抽象层次，在概念层描述中，活动表示要完成的一些任务；
在说明层和实现层中，活动表示类中的方法。活动用圆角框表
示，标注活动名。
活动名
[条件1]
[条件2]
活动还有其它的图符：初态、终态、判断、同步。
初态
终态
[条件1]
[条件2]
判断 同步线
仓储系统业务用例建模
转移：转移描述活动之间的关系，描述由于隐含事件引起的
活动变迁，即转移可以连接各活动及特殊活动（初态、终态、
判断、同步线）。转移用带箭头的直线表示，可标注执行该转
移的条件，无标注表示顺序执行。
泳道：泳道进一步描述完成活动的对象，并聚合一组活动。
活动图是另一种描述交互的方式，描述采取何种动作，做什么
（对象状态改变），何时发生（动作序列），以及在何处发生
（泳道）。泳道也是一种分组机制。
仓储系统业务用例建模
顾 客 售 货 库 房
●●
请求服务请求服务
支付
取货
提货开订单
供货
仓储系统业务用例建模
控制图符：活动图中可发送和接收信号，发送符号对应于
与转移联系在一起的发送短句。接收符号也同转移联系在一
起。
发送信号 接收信号
对象流：活动图中可以出现对象，对象作为活动的输入／输
出，用虚箭头表示。
测量
测量值
显示
控制图符
对象流
开机器
开动
调制咖啡
信号灯灭
倒咖啡
咖啡壶
控制图符例
仓储系统业务用例建模
(2)活动图举例
活动图中只有一个起点一个终点，表示方式和状态图一样，
泳道被用来组合活动，通常根据活动的功能来组合。具体说泳
道有如下目的：直接显示动作在哪一个对象中执行，或显示的
是一项组织工作的哪部分。泳道用纵向矩形来表示，如下图
DisplayerDisplayer SamplerSampler
(channel,frequency(channel,frequency
))
更新显示更新显示
初始化初始化
测量测量
仓储系统业务用例建模
活动图中可发送和接收信号，发送符号对应于与转移联系在
一起的发送短句。接收符号也同转移联系在一起。转移又分两
种：发送信号的转移和接收信号的转移。发送和接收信号可以
和消息的的发送对象和接收对象联系在一起，如下图。
aPrinter:PrinteraPrinter:Printer
Print(file)Print(file) Print(file)Print(file)
打印打印
创建创建PSPS文件文件
在屏幕上的在屏幕上的
报文框中显示报文框中显示
““打印打印””
删除报文框删除报文框
.
PrintAllPrintAll
Customers()Customers()
仓储系统业务用例建模
活动图举例
(1)
(2)
仓储系统业务用例建模
仓储系统业务流程分析
1、入库流程分析
业务需求用例建模阶段
1、业务角色的查找及建立
2、业务用例查找与分析
仓储系统业务用例建模
3、业务用例图
建立系统的业务用例图如下图所示。
仓储系统业务用例建模
4、业务活动图
（1）入库过程的业务活动图如下图所示。
仓储系统业务用例建模
系统基本功能描述
根据仓储系统业务过程分析知系统的基本功能有入库管理，出
库管理与库存管理三大模块，系统功能图如下图所示。
仓储系统
入库业务 库存业务 出库业务
入库管理需求用例分析
1、确定系统角色
2、确定系统顶层用例
表10-1 系统的顶层用例
参与者 用例说明
入库管理人员 入库管理，其中包括到站登记日报管理，入库单管理，码
单管理，审核记帐等
库存管理人员 库存的基本业务管理，包括盘点管理，过户管理，移库管
理
仓区的基本信息管理，包括仓区参数设置，库存分配，预
警管理
出库管理人员 出库管理，有出库单管理，出库信息管理，出库审核管理，
以及平帐等
系统管理人员 系统管理，报表管理，查询管理，基本资料管理等
仓储系统系统需求用例建模
仓储系统系统需求用例建模
顶层用例图
3、入库管理功能性分析
入库管理的分层用例图如下图所示。
仓储系统系统需求用例建模
4、到站日报录入管理用例描述
（1）用例：到站日报管理
（2）参与者：入库管理人员，站台管理员
（3）目的：记录货物的到站情况和到站货物的基本信息
（4）综述：货物到达后，站台管理员组织卸货，大致清点品
种、件数，编写《物资到站日报》，入库管理人员根据到站日
报进行到站日报的录入修改等操作。
仓储系统系统需求用例建模
表到站日报管理用例活动
参与者的动作 系统响应
1）用例始于入库管理人员根据站台管理
员提供的信息进行到站日报的管理
2）入库管理人员选择登陆到本系统，并
输入管理帐号与密码
3）系统确认帐号与密码，并提示登陆成功
进入系统
4）入库管理人员根据系统的提示选择到
站日报管理
5）进入到站管理界面
6）入库管理人员选择：
A.登记到站日报
B.修改到站日报
C.删除到站日报
7）记录这次完成的操作
8）用例在所有操作完成后结束
入库日报管理包括登记到站日报，修改到站日报，删除到站日报。
仓储系统系统需求用例建模
表3 登记到站日报
参与者的动作
系统响应
1）入库管理人员选择登记到站
日报
2）系统显示出登记日报的界面
3）入库管理人员根据站台管理
人员提供的信息输入要登记日
报的基本信息
4）入库管理人员选择登记完成 5）系统接收日报的基本信息并放
入数据库中
6）系统提示登记到站日报完成
仓储系统系统需求用例建模
表4修改到站日报
参与者的动作 系统响应
1）入库管理人员选择要修改的到
站日报
2）系统显示出到站日报的信息
3）入库管理人员确认要修改，并
选择修改项
4）系统进入日报修改界面
5）入库管理人员修改完成 6）系统接收日报的修改信息并再次
给出提示信息
7）入库管理人员确认 8）系统提示修改到站日报完成
仓储系统系统需求用例建模
表5 删除到站日报
参与者的动作 系统响应
1）入库管理人员选择要删除
的到站日报
2）系统显示出要删除的到站日报
的信息
3）入库管理人员确认要删除，
并选择删除项
4）系统接收日报的删除命令并给
出提示信息
5）入库管理人员确认 6）系统提示删除到站日报完成
仓储系统系统需求用例建模
系统扩展功能需求用例分析
1、系统管理：
（1）权限管理：给操作员分配相应的权限。
（2）日志管理：保存每个操作员所进行的所有操作，并提供
相关信息的查询。
（3）数据备份：将所有数据表信息定期保存在磁盘中，确保
数据的安全性与可靠性。
（4）数据恢复：将备份文件恢复到数据库中。
2、报表管理：
（1）业务统计
（2）库存统计
（3）货物统计
（4）货位统计
仓储系统系统需求用例建模
（5）盘点统计
3、查询管理：
（1）在库查询
（2）进货查询
（3）出货查询
（4）盘点查询
（5）货况查询
（6）基本资料查询
4、基本资料管理：
（1）客户管理
（2）货物管理
（3）业务员管理
仓储系统系统需求用例建模
（4）其它基本资料管理
5、仓区管理：
（1）仓区参数设置
（2）库位分配示意图
（3）库存预警
（4）计算机辅助分配
6、其他业务管理：
录入与编辑其它业务管理信息，具体包括：机电物质信息、化
工产品信息、攀金公司的物资信息、加工厂的物资信息、配送
信息等。
7、客户远程查询系统：
客户可根据不同的查询条件对自己的货物信息进行在库查询、
进货查询、出货查询、货况查询。
仓储系统系统需求用例建模
8、权限管理：
系统管理员能根据需要灵活地对操作角色的操作权限进行赋予
与修改，以此有效灵活地对用户的操作权限进行控制，角色管
理包括：
（1）角色填加
（2）角色删除
（3）角色权限修改
（4）角色密码修改
仓储系统系统需求用例建模
系统整体功能描述
系统整体功能如下图所示。
其
他
业
务
管
理
入
库
管
理
出
库
管
理
库
存
管
理
系
统
管
理
查
询
管
理
基
本
资
料
管
理
仓
区
管
理
报
表
管
理
仓储系统功能
仓储系统系统需求用例建模
动态建模、状态图和顺序图
1.动态建模
动态模型主要描述系统的动态行为和控制结构。动态行为包括
系统中对象生存期内可能的状态以及事件发生时状态的转移，
对象之间动态合作关系，显示对象之间的交互过程以及交互
顺序，同时描述了为满足用例要求所进行的活动以及活动间
的约束关系。在动态模型中,对象间的交互是通过对象间消息
的传递来完成的。对象通过相互间的通信(消息传递)进行合作
,并在其生命周期中根据通信的结果不断改变自身的状态。
动态模型主要描述系统的动态行为和控制结构。包括4类图：
状态图、活动图、顺序图（序列图）、合作图（协作图）。
状态图(statechart diagram)：状态图用来描述对象，子系
统，系统的生命周期。
顺序图(sequence diagram) ：是一种交互图，主要描述对
象
业务领域分析与设计
之间的动态合作关系以及合作过程中的行为次序，常用来描
述一个用例的行为。
合作图(collaboration diagram) ：用于描述相互合作的对
象间的交互关系，它描述的交互关系是对象间的消息连接关
系。
UML消息的图形表示是用带有箭头的线段。
简单消息(simple)：表示控制流，描述控制如何从一个对
象传递到另一个对象，但不描述通信的细节。
同步消息(synchronous)：是一种嵌套的控制流，用操作
调用实现。操作的执行者要到消息相应操作执行完并回送一
个
简单消息(simple)
异步消息(asynchronous)
同步消息(synchronous)
返回消息(simple)
业务领域分析与设计
简单消息后，再继续执行。
异步消息(asynchronous)：是一种异步的控制流，消息的
发送者在消息发送后就继续执行，不等待消息的处理。
2.状态图(State Diagram)
状态图用来描述一个特定对象的所有可能的状态及其引起状
态转移的事件。一个状态图包括一系列的状态以及状态之间
的转移。
状态：所有对象都具有状态,状态是对象执行了一系列活动
的结果。当某个事件发生后,对象的状态将发生变化。状态图
中定义的状态有:
初态——状态图的起始点,一个状态图只能有一个初态。
终态——是状态图的终点。而终态则可以有多个。
中间状态——可包括三个区域:名字域、状态变量与活动域。
复合状态——可以进一步细化的状态称作复合状态。
业务领域分析与设计
中间态
初态
终态
状态名
状态变量
活动
响应事件的内部动作或活动的列表，
定义为：
事件名 (参数表[条件])/动作表达式
状态变量: 是状态图所显示的类的属性。
活动:列出了在该状态时要执行的事件和动作。有3个标准事件：
entry事件用于指明进入该状态时的特定动作。
exit事件用于指明退出该状态时的特定动作。
do事件用于指明在该状态中时执行的动作。
例:
无参数
迁移
login 状态
login
login time=curent time
entry/type “login”
do/get use name
do/get password
help/display help
exit/login()
状态迁移：一个对象的状态的变迁称为状态迁移。通常是由
事件触发的,此时应标出触发转移的事件表达式。如果转移上
未标明事件,则表示在源状态的内部活动执行完毕后自动触发
转移。
在第一层
上行
向上移动
到达 上行
空闲
到达
向下移动
下行
超时
向第一层移动
到达
电梯状态图
业务领域分析与设计
细化的状态表示
状态名
状态变量
活动
细化电梯状态图
On
first floor
Go up
(floor) Moving up
do/moving
to floor
Go up
(floor))
Idle
timer=0
do/increase
timer
arrivedMoving down
do/moving
to floor
Go down (floor)
timer= timer-out
Moving to
first floor
arrived
arrived
或关系的子状态
嵌套状态图：状态图可能有嵌套的子状态图，且子状态图可
以是另一个状态图。子状态又可分为两种：“与”子状态和“
或”子状态，
与子状态及或子状态
前进 后退
低速 高速
运行
向前 向后
行使
业务领域分析与设计
事件：事件是激发状态迁移的条件或操作。
在UML中，有4类事件：
(1)某条件变为真；表示状态迁移的上的警戒条件。
(2)收到来自外部对象的信号 (signal) 表示为状态迁移上的事件
特征，也称为消息。
(3)收到来自外部对象的某个操作中的一个调用，表示为状态迁
移上的事件特征，也称为消息。
(4)状态迁移上的时间表达式。
业务领域分析与设计
状态图之间的消息发送：状态图之间可以发送消息，用虚箭
头表示。
消息发送状态图
on/stopoff on/play
off( )
on( ) play( )
stop( )
off( )/stop( )
CD player
Remote Control
off on
on( )
off( )
stop( )play( )
stop( )play( )
off( )on( )
业务领域分析与设计
2.顺序图(Sequence Diagram)
顺序图用来描述对象之间动态的交互行为,着重体现
对象间消息传递的时间顺序。顺序图存在两个轴:水
平轴表示一组对象,垂直轴表示时间。顺序图中的对
象用一个带有垂直虚线的矩形框表示, 并标有对象名
和类名。垂直虚线是对象的生命线,用于表示在某段
时间内对象是存在的。对象间的通信通过在对象的生
命线之间消息来表示，消息的箭头类型指明消息的类
型。
对象图
(1)消息
简单消息(simple)：表示消息类型不确定或与类型无关。
或者是一同步消息的返回消息。
同步消息(synchronous)：表示发送对象必须等待接收对
象完成消息处理后，才能继续执行。
业务领域分析与设计
异步消息(asynchronous)：表示发送对象在消息发送后，
不必等待消息处理后，可立即继续执行。
消息延迟：用倾斜箭头表示。
消息串：包括消息和控制信号，控制信息位于信息串的前
部。
同步消息(synchronous)：表示发送对象必须等待接收对
象完成消息处理后，才能继续执行。
控制信息{条件控制信息 如：［ｘ＞０］
重复控制信息 如：＊［Ｉ＝1..n］
当收到消息时,接收对象立即开始执行活动，即对象被激活了，
通过在对象生命线上显示一个细长矩形框来表示激活。
业务领域分析与设计
(2)顺序图的形式：有两种使用顺序图的方式：一般格式和实
例格式。实例格式详细描述一次可能的交互，没有任何条件和
分支或循环，它仅仅显示选定情节（场景）的交互（如下图）；
而一般格式则描述所有的情节，包括了分支，条件和循环。
:Customer Win :Customer
1:Chang Customer
data）
2:Update
Customer(CustomerData)
3:
业务领域分析与设计
:Computer :Printer Server :Printer :QueuePrint(file)
[Printer free]
Print(file)
[Printer busy]
Store(file)
带分支的顺序图
:C1:c :D1:D :D2:DOp( )
Op2( )
Op3( ) Op4( )
有循环标记的顺序图
Send message
op2
until…
业务领域分析与设计
呼叫者 交换 接受者
拿起话筒
响拨号声
拨号码
路由选择
鸣响音
停音
响铃声
接电话
停铃声
A
B
C
D
E
{B-A<1S}
{C-B<10S}
通过网络选
择通话路径
{E-D<5S}
双方通话
打电话的顺序图
业务领域分析与设计
创建对象与对象的消亡
在顺序图中，还可以描述一个对象通过发送一条消息来创
建另一个对象。
当对象消亡(destroying)时，用符号 表示。
：Customer Windows
NewCustomer(Data)
：Customer
Customer(Data)
DeleteCustomer()
图 创建或删除对象
业务领域分析与设计
静态建模、类图、对象图和包图
1.静态建模
任何建模语言都以静态建模机制为基础,标准建模语言UML也
不例外。所谓静态建模是指对象之间通过属性互相联系，而
这些关系不随时间而转移。
类和对象的建模，是UML建模的基础。熟练掌握基本概念、区
分不同抽象层次以及在实践中灵活运用,是三条最值得注意的
建模基本原则。
UML的静态建模机制包括：用例图(Use case diagram)、类
图(Class diagram)、对象图(Object diagram )、包图
(Package diagram)、构件图(Component diagram)和配置图
(Deployment diagram)
2.对象类与对象
面向对象的开发方法的基本任务是建立对象模型，是软件系统
业务领域分析与设计
开发的基础。UML中的对象类图(Class Diagram)与对象图
(Object Diagram)表达了对象模型的静态结构，能够有效地
建立专业领域的计算机系统对象模型。
(1)类图与对象图
对象类简称类，是面向对象模型的最基本的模型元素，用类
图来描述。类图(Class diagram)由系统中使用的类以及它们
之间的关系组成，是描述系统的一种图式，分为长式和短式。
类及类型名均用英文大写字母开头，属性及操作名为小写字
母开头。常见类型有：Char,Boolean,Double,Float,
Integer, Object,Short,String等。类图是构建其它图的基础。
对象是对象类的实例(instance),用对象图来描述。对象图亦分
长式和短式。
业务领域分析与设计
小汽车小汽车
注册号：String
日期： Cardata
速度： Integer
方向： Direction
属性：类型
类名
操作
类名
对象名:类名
属性
操作
对象名对象名
类图与对象图
丁一：作家丁一：作家
姓名=丁一
年龄=30
丁一办公室中的
PC:
计算机名称=Dell 466
内存=64
丁一家里的PC:
计算机
名称=长城PII MMX
内存=64
对象图
业务领域分析与设计
属性(attribute)：属性用来描述类的特征，表示需要处理
的数据。属性定义：
visibility attribute-name : type = initial-value
{property-string}
可见性 属性名：类型=缺省值{约束特性}
其中：可见性(visibility)表示该属性对类外的元素是否可见。
分为：
public（+） 公有的，即模型中的任何类都可以访问该属性。
private（-） 私有的，表示不能被别的类访问。
protected（#） 受保护的，表示该属性只能被该类及其子
类访问。
如果可见性未申明，表示其可见性不确定。
业务领域分析与设计
操作
对数据的具体处理方法的描述则放在操作部分，操作说明了该
类能做些什么工作。操作通常称为函数，它是类的一个组成部
分，只能作用于该类的对象上。 操作定义：
visibility operating-name(parameter-list): return-type
{property-string}
可见性 操作名（参数表）：返回类型{约束特性}
其中：可见性同上。
参数表：参数名：类型，…
Parameter-name :type =default-value
返回类型：操作返回的结果类型。
业务领域分析与设计
(2)类的识别：是面向对象方法的一个难点，但又是建模的关
键。常用的方法有：
名词识别法
系统实体识别法
从用例中识别类
利用分解与抽象技术
关键是要定义类的“属性”及“操作”。
业务领域分析与设计
中类之间的关系
UML中类的关系有关联(association) 、聚集(aggregation)
、泛化(generalization) 、 依赖(depending)和细化
(refinement)。
(1)关联：关联是类之间的连结，
分为：
常规关联(如右图)
多元关联
有序关联
受限关联
或关联(如右图)
关联类(图)
公司 员工
0..* 顾 佣 0..*
工作于 管理 1..*
工人
老板
0..1
顾佣关联
或关联
用户 工作站
授权授权* *
授权
优先级
特权
开始一个时间片 关联类
保险公司 保险合同
人 公司
*
*
*
{or}
业务领域分析与设计
其它关联
递归关联(Recursive association)：即一个类到
自身的关联。
节点
连接
*
*
递归关联
人
治疗
病人
医生
带有职责的递归关联
业务领域分析与设计
(2)聚集(aggregation)：聚集是一种特殊的关联，它指出类间
的“整体—部分”关系。又分为：
共享聚集(shared aggregation)：其“部分”对象可以是任
意“整体”对象的一部分。当“整体”端的重数不是1时，称
聚集是共享的。
整体类 部分类
组合聚集(composition aggregation)：其“整体”(重数为
0、1)拥有它的“部分” 。部分仅属于同一对象，整体与部分
同时存在。
整体类 部分类 窗口 工具框
显示区
标题 窗口
标题
工具框
显示区
项目 人员
＊ ＊
业务领域分析与设计
(3)泛化：泛化指出类之间的“一般与特殊关系”，即继承关系。
父类与子类之间构成类的分层结构。
一般类 特殊 人员
教师
学生
抽象类：指没有实例的类，定义一些抽象的操作，即不提供
实现方法的操作，只提供操作的特征。并附以{abstract}。
交叠泛化：在继承树中，若存在某种具有公共父类的多重继
承，称为是交叠(overlapping)的。否则是不交的(disjoint)。
完全泛化 ：一般类特化出它所有的子类，称为完全泛化，
记为{complete}。
不完全泛化 ：即未特化出它所有的子类，称为是不完全泛
化 的，表示为{incomplete}.
业务领域分析与设计
{complete}
人
女人男人
性别
完全泛化
交通工具
drive()
汽车
drive()
轮船
drive()
drive()启动
轮子转动
drive()启动
螺旋浆
Person
驾驶
drive()是
抽象操作
泛化中的多态性
及带识别名称的泛化
{propulsion} {propulsion}
{overlapping
}
交通工具
重叠泛化
汽车 船
水陆两栖车
业务领域分析与设计
继承性的实例：
泛化关系
图 形{abstract}
颜 色
中心位置
笔的粗细
移 动（）
旋 转（）
显 示（）{abstract}
2 维
{abstract}定位
填充类型
缩放
填充
多边形
边数
顶点数
显示
园
直径
显示
旋转
线
端点
显示
0 维
{abstract}
点
显示
样条
控制点
显示
弧
半径
起始角
弧度角
显示
1 维{abstract}
定位
缩放
维数
OrderLine
Quantity:Integer
isSatisfied
1
*
1*
1*
Customer
name
address
CreditRating()
Order
dataReceived
isPrepaid
number:String
dispatch()
close() Personal Customer
creditCard
Corporate Customer
contactName
creditRating
creditLimit
remind()
billForMonth()
Employee
Product
0..1
+LineItem
泛化关系
(4)类图的抽象层次和细化(Refinement)关系
需要注意的是，虽然在软件开发的不同阶段都使用类图，
但这些类图表示了不同层次的抽象。
在需求分析阶段，类图是研究领域的概念；在设计阶段，
类图描述类与类之间的接口；而在实现阶段，类图描述软件
系统中类的实现。
按照Steve Cook和John Dianiels的观点，类图分为三
个层次：概念层、说明层、实现层。
需要说明的是，这个观点同样也适合于其他任何模型，
只是在类图中显得更为突出。描述了类图的抽象层次和细化
(Refinement)关系。
业务领域分析与设计
概念层(Conceptual)：概念层类图描述应用领域中的概念。
实现它们的类可以从这些概念中得出,但两者并没有直接的映
射关系。事实上,一个概念模型应独立于实现它的软件和程序
设计语言。
说明层(Specification)：说明层类图描述软件的接口部分,
而不是软件的实现部分。面向对象开发方法非常重视区别接
口与实现之间的差异,但在实际应用中却常常忽略这一差异。
这主要是因为OO语言中类的概念将接口与实现合在了一起。
大多数方法由于受到语言的影响,也仿效了这一做法。现在这
种情况正在发生变化。可以用一个类型(Type )描述一个接口,
这个接口可能因为实现环境、运行特性或者用户的不同而具
有多种实现。
业务领域分析与设计
实现层(Implementation) ：只有在实现层才真正有类的概
念,并且揭示软件的实现部分。这可能是大多数人最常用的类
图,但在很多时候,说明层的类图更易于开发者之间的相互理解
和交流。
理解以上层次对于画类图和读懂类图都是至关重要的。但是
由于各层次之间没有一个清晰的界限,所以大多数建模者在画
图时没能对其加以区分。画图时,要从一个清晰的层次观念出
发;而读图时,则要弄清它是根据哪种层次观念来绘制的。要
正确地理解类图,首先应正确地理解上述三种层次。虽然将类
图分成三个层次的观点并不是UML的组成部分,但是它们对于
建模或者评价模型非常有用。尽管迄今为止人们似乎更强调
实现层类图,但这三个层次都可应用于UML,而且实际上另外
两个层次的类图更有用。
业务领域分析与设计
(5)识别系统的类
通过名词识别法和系统实体识别法等方法可以识别出医院病
房监护系统的十二个类,以下用类图这种简单明了的方法分别
表示出类的名称，属性\操作。（见下图）
值班护士 医生 病人 病症监视 中央监护系统 报警信
号 标准病症信号库 病历库 病人病症信号 病情报告
病历 标准病症信号
医生
用户名
密码
查看病情报告（）
要求打印病情报告（）
查看病历（）
要求打印病历（）
病人
姓名
性别
年龄
病症
提供病症信号（）
用户名
密码
查看病情报告（）
打印病情报告（）
值班护士 病症监视
采集频率
病症信号
格式化信号数据（）
采集信号（）
信号组合（）
业务领域分析与设计
病人病症信号
脉搏
血压
体温
生成病症信号（）
病历
格式
病人基本情况
打印时间
生成病历（）
查看病历（）
打印病历（）
标准病症信号
脉搏
血压
体温
生成标准信号（）
标题
格式
生成病情报告（）
查看病情报告（）
打印病情报告（）
病情报告
报警信号
声音
灯光
文字
报警（）
数模转化（）
病历库
类型
大小
容量
生成病历（）
更新病历（）
查看病历（）
打印病历（）
类型
大小
容量
提供标准信号（）
标准病症信号库
输入
输出
分解信号（）
比较信号（）
报警（）
数据格式化（）
中央监护系统
业务领域分析与设计
在类图中标明类之间的关系：
*
*
*
*
* *
*
11
1
1
1
1
1 1 1
1
1
1
1
1
11
值班护士 医生 病人
病症监视
病人病症信号
病历
病历库病情报告
报警信号 中央监护系统
标准病症信号
标准病症信号库
1
1
1
报警
监视
业务领域分析与设计
4. 包图
一个最古老的软件方法问题是:怎样将大系统拆分成小系统。
UML中解决该问题的思路之一是将许多类集合成一个更高层
次的单位,形成一个高内聚、低耦合的类的集合。UML中这种
分组机制叫包(Package)。引入包是为了降低系统的复杂性。
包是一种组合机制，把各种各样的模型元素通过内在的语义
连在一起成为一个整体就叫包，构成包的模型元素称为包的
内容，包通常用于对模型的组织管理，因此有时又将包称为
子系统（subsystem）。包拥有自己的模型元素，包与包之
间不能共用一个相同的模型元素，包的实例没有任何语义
（含义）。仅在模型执行期间包才有意义。
业务领域分析与设计
包的内容可以是类的列表,也可以是另一个包图,还可以是一个
类图。包之间的关系有依赖和泛化（继承）。
依赖关系：两个包中的任意两个类存在依赖关系，则包之间
存在依赖关系。表示为：
泛化关系：使用继承中通用和特例的概念来说明通用包和专
用包之间的关系。例如,专用包必须符合通用包的界面,与类继
承关系类似。表示为：
包内容
包名
包名
包A
包B
数据库界面
Oracle界面 Sybase界面
（a）包的表示 (b)包的依赖关系 (c) 包的泛化关系
包图
业务领域分析与设计
和类一样包也有可见性，利用可见性控制外部包对包的内容
的存取方式，UML中定义了四种可见性：私有(private)，公
有(public)，保护(protected)和实现(implementation)。缺
省值为公有。
包也可以有接口，接口与包之间用实线相连，接口通常由包
的一个或多个类实现。
X
类P 类S
AA
BB DD
CC
II
包图举例
业务领域分析与设计
保险单
填写界面
系统内部
保险单 客户
数据库界面
（abstract)
Oracle 界面
Sybasec界面
包的继承
包的依赖
包
包图
业务领域分析与设计
财务子系统
数据库子系统
数据库操作 数据库接口
Oracle 接口 Sybasec接口
包图举例
业务领域分析与设计
订单获
取界面
AWT 邮件发
送界面
邮件发
送应用
订单获
取应用
订单 顾客
用户接口包
应用层包
问题域包
业务领域分析与设计
包图另一种划分方式
订单获
取界面
AWT 邮件发
送界面
邮件发
送应用
订单获
取应用
订单 顾客
用户接口
用户
问题域
业务领域分析与设计
举例：用包图描述医院监护系统的体系结构
用户
医生
值班护士
病人
病历管理
病历
用户界面
病情报告
局部监视
报警信号
病症监视器
中央监护系统
病人病症信号
标准病症信号
数据库
病历库
标准病症信号库
用户层
用户界面层
应用层
数据库层
系统顺序图和状态图
1、新建到站日报
2、修改到站日报
3、删除到站日报
业务领域分析与设计
定义基本对象与类
入库管理子系统的对象分析
实体对象 货物，物资到站日报，码单入库信息表，仓库，货物明细单，
入库单，货物异常报告，帐卡入库信息，入库收费单，客户信
息，库区，库位，码单基本信息表，职工信息表，用户权限表，
权限信息表，验收工具表，设备表，站台表，计量单位表，部
门表，物资明晰分类表，业务类别表。
边界对象 入库到站日报管理界面，入库码单管理界面，入库单管理界面，
入库审核界面
控制对象 入库审核
入库管理子系统的对象分析表
业务领域分析与设计
根据分析级的顺序图与系统的对象分析定义系统中涉及的类
包括：
（1）类 客户 KH
（2）类 货物 HW
（3）类 仓库 CK
（4）类 库区 KQ
（5）类 库位 KW
（6）类 物资到站日报 DZRB
（7）类 码单基本信息 MDJBXX
（8）类 码单入库信息：MDRKXX
（9）类 保管员入库验收信息（BGYYSXX）
（10）类 码单货物存放明细（MDHWCF）
（11）类 入库单 RKD
（12）类 货物异常报告 HWYCBG
（13）类 帐卡入库信息 ZKRKXX
业务领域分析与设计
（14）类 入库收费单 RKSFD
（15）类 用户权限 YHQX
（16）类 权限信息 QXXX
（17）类 入库审核 RKSH
（18）类 职工信息ZGXX
（19） 类 物资存储类 WZCCL
（20）类 业务类别 YWLB
（21）类 物资明晰分类 WZMXFL
（22）类 部门 BM
（23）类 计量单位 JLDW
（24）类 站点 ZD
（25）类 验收工具 YSGJ
（26）类 设备 SB
业务领域分析与设计
实现建模、构件图和配置图
1.实现建模
实现模型描述了系统实现时的一些特性，又称为物理体系结
构建模。包括源代码的静态结构和运行时刻的实现结构。实
现模型包括：构件图（组件图）和配置图。
构件图(Component diagram) 显示代码本身的逻辑结构，
它描述系统中存在的软构件以及它们之间的依赖关系。构件
图的元素有构件，依赖关系和界面。
配置图(Deployment diagram) 描述了系统中硬件和软件
的物理配置情况和系统体系结构。显示系统运行时刻的结构，
配置图中的简单结点是指实际的物理设备以及在该结点上运
行构件或对象。配置图还描述结点之间的连接以及通信类型。
系统实现测试与配置
2.构件图
(1)构件（component）
构件定义：系统中遵从一组接口且提供其实现的物理的、可
替换的部分。对系统的物理方面建模时，它是一个重要的构
造块。
构件的名称和类的名称的命名法则很是相似，有简单名和
路径名之分。构件的描述如下图所示。
若构件的定义良好，该构件不直接依赖于构件的所支持的
接口，在这种情况下，系统中的一个构件可以被支持正确接
口的其他构件所替代。构件图符是一个矩形框（如下图所示）
。
系统实现测试与配置
图形库
()
构件可以看作包与类对应的物理代码模块，逻辑上与包，
类对应，实际上是一个文件，可以有下列几种类型的构件：
1） 源代码构件；
2） 二进制构件；
3） 可执行构件
构件对外提供的可见操作和属性称为构件的界面。界面的图
符是一个小圆圈。用一条连线将构件与圆圈连起来。
构件之间的依赖关系是指结构之间在编译，连接或执行时的
依赖关系。用虚线箭头表示。
系统实现测试与配置
窗口控制
（）
通信控制
()
主控模块
()
窗口控制
()
通讯控制
()
主控模块
()
图形库
()
客户程序
()
构件图实例
构件
关
系
类
Main类
Main类
图形库
Square类
Square类
Circle类
可执行程序
组件的依赖关系又分为：开发期的依赖和调用依赖。
开发期的依赖(Development –time Dependency)：是指在
编译阶段和连接阶段，组件之间的依赖关系。
调用依赖(Call Dependency)：是指一个组件调用或使用另
外一个组件服务。
业 务
（源码）
项目管理
（源码）
项目管理
（对象）
项目管理
（执行码）
系统管理
（源码）
资源管理
（源码）
资源管理
（对象）
资源管理
（执行码）
系统管理
（对象）
系统管理
（执行码）
3.配置图
配置图用来描述系统硬件的物理拓扑结构以及在此结构上
执行的软件，即系统运行时刻的结构。
配置图可以显示计算机结点的拓扑结构和通信路径，结点
上执行的软构件，软构件包含的逻辑单元等，特别对于分布
式系统，配置图可以清楚的描述系统中硬件设备的配置，通
信以及在各硬件设备上各种软构件和对象的配置。因此，配
置图是描述任何基于计算机的应用系统的物理配置或逻辑配
置的有力工具，配置图的元素有结点和连接。
配置图中的结点代表某种计算机构件，通常是某种硬件。
同时结点还包括在其上运行的软构件，软构件代表可执行的
物理代码模块，如一个可执行程序。结点的图符是一个立方
体。
系统实现测试与配置
保险单
填写界面
保险系统
保险数据库
保险政策
保险用户
客户PC
《TCP/IP>
保险服务器
保险系统
配置
配置
保险系统的配置图
配置图各结点之间进行交互的通信路径称为连接，连接
表示系统中的结点存在着联系，用结点之间的的连线表示连接，
在连接的连线上要标注通信类型，如上图。
医院诊疗系统的配置图
医院诊疗系统的配置图(C/S)
:Object
Database
:Health Care
Domain
Database Unit Server
（数据库服务器）
a Windows PC（客户机）
:Object
Database
:Health Care
Domain
Heart Unit Server（心血管病服务器）
:Configure
Knowledge
:Configure users
Heart Unit Configuration
《Communication 》
TCP/IP
TCP/IP
:Heart Unit UI
:Heart Unit
Client Facade
:Heart Unit
Server
Application
作业4
1、简述统一软件开发过程RUP的开发过程和
核心工作流。
P309 1
2、出库流程分析
3、库存管理业务流程分析
