UML建模参考样例3
UML完整例子
(3) 得到候选类
书籍 计算机类书籍 非计算机 类书籍 借阅记录 借阅记录列表 书籍列表
在使用"名词动词法"寻找类的时候,很多团 在使用"名词动词法"寻找类的时候, 队会在此耗费大量的时间,特别是对于中大型项目, 队会在此耗费大量的时间,特别是对于中大型项目, 这样很容易迷失方向. 这样很容易迷失方向.其实在此主要的目的是对问 题领域建立概要的了解, 题领域建立概要的了解,无需太过咬文嚼字
特性
用例
FEAT07.按书名,作者,类别,出版社等关键字组合查查 UC03.查查书籍 按书名,作者,类别, 按书名 查查书籍 书籍 信息 FEAT08.列出所有书籍信息 列出所有书籍信息 FEAT14.所有查查,列表,统计功能应可以单独对计算机 所有查查, 所有查查 列表, 类或非计算机类进行 FEAT09.登录登登情况 登录登登情况 FEAT10.登登状态能够自动反应在书籍信息中 登登状态能够自动反应在书籍信息中 UC04.登登登登 登登登登 信息
(4)用例图
新增书籍信息
<<extend>> 查查书籍信息 <<include>>
修改书籍信息
查查登登信息 图书管理员 登登登登信息
统计统统和统数
(5)细化用例描述—搭框架 )细化用例描述—
(2)筛选备选类
筛选备选类
"基本信息"则是书名,作者,类别等描述书籍的 基本信息"则是书名,作者, 基本信息 基本信息统称, 关键字"则是代表其中之一, 基本信息统称,"关键字"则是代表其中之一, 因此无需对其建模; 因此无需对其建模; "功能","新书籍","信息","登录"都 功能" 新书籍" 信息" 登录" 是在描述需求时使用到的一些相关词语, 是在描述需求时使用到的一些相关词语,并不是 问题域的本质,因此先可以将其淘汰掉; 问题域的本质,因此先可以将其淘汰掉;
UML示例图
UML示例图UML示例图在Visio里，包和类的关系是包含关系，将类拖入包的文件夹之后，关系就建立了，二元关联符号可以设置为：聚合、合成。
接口：空心圆+直线（唐老鸭类实现了‘讲人话’）；依赖：虚线+箭头（动物和空气的关系）；关联：实线+箭头（企鹅需要知道气候才迁移）；聚合：空心四边形+实线+箭头（雁群和大雁的关系）；合成：实心四边形+实线+箭头（鸟和翅膀的关系）；泛化：空心三角形+实线（动物和鸟的继承关系）；实现：空心三角形+虚线（实现大雁飞翔的接口）；UML类图解释UML类图：1. 首先看“动物”矩形框，它代表一个类。
该类图分为三层，第一层显示类的名称，如果是抽象类就要用斜体显示。
第二层是类的特性，通常就是字段和属性。
第三层是类的操作，通常是方法和行为。
注意前面的符号，‘+’表示public, ‘—’ 表示private, ‘#’表示protected.2. “飞翔”矩形框表示一个接口图，它与类图的区别主要是顶端有《interface》显示，第一行是接口名称，第二行是接口方法。
接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。
interface IFly interface Ilanguage{ {void Fly(); void Speak();} }3. 动物，鸟，鸭，唐老鸭他们之间都是继承的关系，继承关系用空心三角形+实现来表示。
4.“大雁”实现了“飞翔”接口。
实现接口用空心三角形+虚线来表示。
（注：下面的图中应为空心三角形）class Bird:Animal class WideGoose:IFly{ {//继承动物类 //实现飞翔接口} }5. 企鹅与气候有很大的关系，企鹅需要“知道”气候的变化，需要“了解”气候规律。
当一个类“知道”另一个类时，可以用关联(association)关系。
关联关系用实线箭头来表示。
class Penguin :Bird{private Climate climate;//在企鹅Penguin中，引用到气候Climate对象}6. “大雁”和“雁群”这两个类。
uml建模实例
合作关系（关联），甲会对乙做点 什么：如月老和小伙、姑娘，小伙 A
和玫瑰，小伙和姑娘的关系
D
第14页，共23页。
我的一个朋友结婚了-F
F.这些东东是怎么成事的？
每个事物都会尽量利用伙伴的能力
B
整体事物的能力依靠部分事物的能 力
C
抽象事物的属性和能力就是具体事
物的属性和能力；具体事物除了有 抽象事物的属性和能力外，还可以
第17页，共23页。
搞清过程的活动图
牵线
相识
一见钟情
拍拖
不成 谈婚论嫁
蜜月
结婚
举行婚礼
订婚
第18页，共23页。
拍拖过程活动图
非初级阶段 初级阶段
谈婚论嫁 热恋阶段
送收花
甜言蜜语
手拉手
亲亲嘴
换戒指
......
通过 不通过
进入下一轮 通过
不通过
告吹
第19页，共23页。
通过
结婚
不通过
复述情节的顺序图
D
第13页，共23页。
我的一个朋友结婚了-E
E.这些东东之间有什么关系？
事物之间的关系非常多，面向对象的观点 一般分为主要的三类：
整体-部分关系（组成和聚合），甲
是乙的一个组成部分：如恋人和小伙， 恋人和姑娘的关系
B
C
抽象-具体关系（泛化），甲是乙的
一个特例：如人和小伙，人和月老， E
F
人和姑娘的关系
婚礼( 结婚证 )
不愉快( 伤感 )
不愉快( 伤感 )
和好( 愉快 ) 和好( 愉快 )
亲恋
爱恋
交换戒指(戒指)
第23页，共23页。
月老牵线搭桥，介绍小伙和姑娘认识 姑娘和小伙一见钟情，成为一对恋人 一对恋人开始拍拖 小伙追求献花，表达对姑娘的爱意 姑娘收到999火红玫瑰，激动得头晕目眩 小伙真心求婚，姑娘以身相许 一对恋人终于走入婚姻殿堂
UML用例图模板
UML用例图模板定期存款存款业务员ULM用例图1、UC1用例名称：查看客户资料⏹参与者(Actor)[参与者]⏹简要说明(Brief Description)[简要介绍该用例的作用和目的]⏹事件流(Flow of Event) [事件流应该表示出所有的场景]★基本流1)基本流12)基本流1[把所有的基本流列出来]★备件流1)基本流12)基本流2⏹用例场景(Use-Case Scenario)[ 场景主要是由基本流和备选流组合而成]★成功场景1)成功场景12)成功场景2★失败场景1)失败场景12)失败场景2⏹特殊要求(Special Requirement)[描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）]⏹前置条件(Pre-Condition)[执行用例之前系统必须所处的状态]⏹后置条件(Post-Condition)[用例执行完毕后系统可能处于的一组状态]2、UC2用例名称：活期存款⏹参与者(Actor)[参与者]⏹简要说明(Brief Description)[简要介绍该用例的作用和目的]⏹事件流(Flow of Event) [事件流应该表示出所有的场景]★基本流3)基本流14)基本流1 [把所有的基本流列出来]★备件流3)基本流14)基本流2⏹用例场景(Use-Case Scenario)[ 场景主要是由基本流和备选流组合而成]★成功场景3)成功场景14)成功场景2★失败场景3)失败场景14)失败场景2⏹特殊要求(Special Requirement)[描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）]⏹前置条件(Pre-Condition)[执行用例之前系统必须所处的状态]⏹后置条件(Post-Condition)[用例执行完毕后系统可能处于的一组状态]。
UML范例
UML期末大作业题目：班级：姓名：学号：目录一、订餐系统中的用例图 (1)1、主管的用例图： (2)2、客户的用例图： (3)3、送餐人员的用例图： (4)4、厨师的用例图： (4)5、系统管理员用例图： (4)二、订餐系统的时序图 (5)1、用户充值时序图： (5)2、客户订餐时序图： (6)3、主管查询时序图： (6)4、菜单更新时序图： (7)三、订餐系统中的类图 (8)1、类图的生成： (8)2、系统中的其它类。
(8)四、订餐系统中的活动图 (10)1、客户的活动图： (10)2、送餐人员的活动图： (11)3、厨师的活动图： (11)4、主管的活动图： (12)五、订餐系统的构件图 (13)1、业务对象构件图： (13)2、用户界面构件图： (14)六、订餐系统的部署图 (15)一、订餐系统中的用例图用例图(Use Case Diagram)在需求分析阶段有很重要的作用，它描述人们希望如何使用一个系统，作为参与者的外部用户所能观察到的系统功能的模型图。
开发的全过程都是围绕需求阶段的用例图进行的。
我们所要开发的订餐系统内容十分丰富，用户包括授权的主管、客户、厨师及送餐人员、未授权的用户以及外部数据库系统，其角色层次图如图4-14所示:未授权用户进人订餐系统后可以浏览系统内的公共资源，如餐馆的基本情况、菜单、新闻等，还可以通过注册系统申请成为授权用户。
授权用户通过订餐系统的身份认证后享有系统规定的资源，主管可以查看一天的销售情况、菜单、顾客的建议、顾客提交的订单、库存；顾客可以查看菜单、向餐馆提出建议、以及订餐等；厨师可以查看顾客提交的订单、顾客提出的建议、菜单、库存等；送餐人员可以查看顾客提交的订单获得地址、菜单等。
外部数据库则主要用于和系统进行数据交换。
经过以上分析得到订餐系统用例模型图如下：作为教学评估系统的参与者有：（1）主管：主管可以登录系统查看一天的销售情况、顾客的建议、顾客提交的订单、以及查看库存、修改菜单等；（2）顾客：查看菜单、向餐馆提出建议、以及订餐等。
UML业务建模实例分析四例
UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。
我们在日常生活中也经常和ATM打交道。
本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
图5.1 自动取款机（ATM）系统用例图银行储户在ATM机上完成取款、存款及其他业务。
图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。
帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。
六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。
getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。
getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。
getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
UML实例UML案例(完整建模)(图书馆信息系统)
1: add item( ) : Administrator
: Maintenance Window
3: update( )
2: find(String)
: Item
: Title
2. 系统管理员删除书籍的协作图
1: remove item( ) : Administrator
: Maintenance Window
: Item
2. 系统管理员添加借阅者帐户的时序图
: Administrator
: Maintenance Window
1: create borrower( )
: Borrower
2: create(String, String)
3. 系统管理员删除书目的时序图
4. 图书管理员处理书籍借阅的时序图
书籍。 ② 借阅者能够借阅书籍和还书。 ③ 图书管理员能够处理借阅者的借阅和还书
请求。 ④ 系统管理员可以对系统的数据进行维护，
如增加、删除和更新书目，增加、删除和 更新借阅者帐户，增加和删除书籍。
系统功能需求
▪ 系统主要包括以下几个模块： ① 基本数据维护模块 ② 基本业务模块 ③ 数据库管理模块 ④ 信息查询模块
ReturnItem Fram e.j ava Fi ndBorrowerDi al og.j ava
T i tl eInfoWi ndow.j ava
LendItemFrame.java FindTitleDialog.java
BorrowerInfoWindow.java
UpdateT i tl eFram e.j ava
: Borrower
: Reservation Window
UML系统建模与分析设计 案例图
公司经理银行税务局客户企业员工财务管理进销存管理行政事务管理生产调度管理生产设备管理人力资源管理<<依赖>><<依赖>><<依赖>><<依赖>>见第三章 企业综合信息管理系统最高层用例图销售管理库存管理采购管理<<依赖>><<依赖>>财务管理子系统公司经理生产调度管理子系统企业员工客户见第三章 的2层用例图—进销存管理子系统销售计划规定销售合同管理售后服务管理《依赖》《依赖》财务管理子系统公司经理生产调度管理子系统企业员工客户见第三章 第3层—销售管理子系统修改合同增加销售合同付款单处理履约合同检查打印催款单销售合同查询<<依赖>><<依赖>><<依赖>>公司经理财务管理子系统生产调度管理子系统合同管理员仓库管理员客户见第三章 销售合同管理子系统采购管理销售管理身份验证库存管理<<包含>><<包含>><<包含>>系统管理员见第三章 用例之间的包含关系签订销售合同核对合同核对货物清单制作并发放出库单核对付款单发货合同履约[未付款][缺货][有货][已付款]见第三章 销售合同履约过程活动图：出库单：合同：付款单签订销售合同核对合同核对货物清单核对付款单发货合同履约：出库单：付款单[未付款][缺货][有货][已付款]：合同见第三章 活动图中的对象及对象流执行销售合同制作出库单核对付款单安排发货合同履约发货[已付款=合同总款并且 已发货=合同总发货量][没付款][有货][已付款][无货]见第三章 活动图中的条件线程签订销售合同执行销售合同*合同履约见第三章 描述销售合同从签订到履约的活动态并发活动图核对付款单核对合同排除未付款合同付款累加合同客户未履约合同客户履约[已付款][未付款][付款累加<合同总金额][付款累加=合同总金额]见第三章 “核对付款单”子活动图核对付款单核对合同检查合同订单项排除未付款合同更新库存制作并发放缺货单制作并发放出库单制作并发放生产单[已付款][对每一订单项]*[未付款][有货][缺货]见第三章 检查合同、核对付款单并发放出库单的活动图《Interface 》建立销售合同《Interface 》销售合同查询《Interface 》付款通知单《Interface 》到款通知单《Interface 》催款单合同管理器《Interface 》建立采购合同合同统计表销售合同容器销售合同《Interface 》合同统计表采购合同容器采购合同《Interface 》采购合同查询《Interface 》付款通知单《Interface 》到货通知单《Interface 》催货单管理管理存储存储销售员库房财务客户业务员财务库房客户1111111111**见第四章 合同管理子系统的对象类图合同-合同编号:string -甲方:string-乙方:string-商品名称:string -规格:string 《构造新对象》+合同():购进合同-首付款时间:string -首付款额:double -首到货时间:date -首到货量:double -付款时间2:date-付款额2:double 销售合同-首到款时间:date -首到款额:double -首发货时间:date -首发货量:double -到款时间2:date -至款额2:double见第四章合同的继承关系用户接口出错处理企业综合信息管理系统数据库见第四章与企业综合信息管理系统相关的包财务管理系统《subsystem》进销存管理系统《subsystem》人力资源管理系统《subsystem》生产调度管理系统《subsystem》《资金往来》《使用》《使用》《使用》《使用》见第四章企业综合信息管理系统包含的子系统合同管理系统《subsystem》合同管理器采购合同管理器销售合同容器合同销售合同采购合同合计统计仓库管理系统《subsystem》出入库单管理器出入库单容器入库单容器出库单入库单库存管理器库存单进销存管理子系统保所包含的类。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1系统软件重构分析
首先该系统主要用于药店、药品检查评定工程，该系统主要分为用户管理，系统设置，检查准备，检查执行，检查统计与帮助等模块。
登录时有三种身份可供选择，即管理员，检查员和统计员。
其中，管理员可以对用户管理，系统设置，检查准备，检查执行等整个系统进行管理，而检查员和统计员仅仅可以对检查准备，检查执行，检查统计与帮助等模块有权限，而对用户管理和系统设置没有访问的权限。
对于系统设置模块，管理员进入系统，点击系统设置，即可进行受检单位设置，法规设置与维护，条例设置维护，检查标准维护等操作。
对于用户管理模块，管理员可以新增，编辑和浏览用户信息和身份设置等。
而其他用户仅可以对自己的信息进行维护和注销等操作。
其他模块，管理员，检查员，统计员三种身份的人都可以进行操作。
在检查准备模块中，用户可以设定检查计划，修订检查计划以及下载或上传检查计划。
在检查执行过程中，用户可以进行选取检查任务，选取复检查任务以及打印检查报告和上传检查记录等操作。
同时，用户还可以进行受检单位设置，检查统计以及任务检查等操作。
2系统模块时序图
Manage law 模块：
Create law
（1）打开法规维护界面
（2）输入要查询的法规内容信息
（3）参考信息在浏览标签页中显示出来
（4）创建新法规
（5）显示新输入的法规内容信息
（6）输入新增法规的详细信息
（7）验证本页的数据是否符合规范
（8）连通数据库服务器，创建一条新记录
（9）保存数据库新增记录
（10）系统退出
5-1managelawSD.createnewlawSD.mdl
Modify law
（1）打开法规维护界面
（2）输入用户查询的法规信息内容
（3）信息在页面中显示出来
（4）修改和删除法规内容
（5）显示修改后的法规信息内容
（6）连通数据库查找要得到的信息
（7）将在数据库中得到的信息显示出来
（8）校验输入的数据是否符合规范
（9）保存数据库中修改的记录
（10）退出系统
5-2managelawSD.modifylawinfoSD.mdl Query law
（1）用户打开法规维护界面
（2）输入用户想要查询的法规信息
（3）在页面中显示信息
（4）查询法规内容
（5）将查询的结果在页面中显示出来
（6）连通数据库查找法规内容
（7）将数据库中的法规内容反馈并显示在在页面上
（8）系统退出
5-3managelawSD.querylawinfoSD.mdl Manage key word 模块
Add new key word
（1）用户打开条件搜索关键字维护
（2）输入用户要查询的关键字信息
（3）显示参考信息
（4）增加新的关键字
（5）在界面中显示新增的关键字内容
（6）输入新关键字的详细内容
（7）校验输入的数据是否符合规范
（8）连通数据库服务器，创建一条新的关键字
（9）保存数据库中的新增关键字
（10）系统退出
7-1ManagekeywordSD.addnewkeywordSD.mdl
Modify key word
（1）用户打开条件搜索关键字界面
（2）输入用户查询的关键字内容
（3）将关键字信息显示出来
（4）修改或者删除关键字信息
（5）将编辑后的关键字内容信息显示出来
（6）验证输入的信息是否符合规范
（7）在数据库服务器中保存修改的信息
（8）系统退出
7-2ManagekeywordSD.modifykeywordSD.mdl
Manage check task 管理检查任务：
（1）用户打开选取检查任务界面
（2）输入用户查询的法规信息内容
（3）将查询到的信息显示出来
（4）修改检查任务
（5）将修改后的信息在页面中显示出来
（6）连接数据库查找要显示的信息
（7）将在数据库中找的信息进行反馈并且显示出来（8）验证本页输入的信息是否符合规范
（9）保存数据库中的信息
（10）退出系统
9managechecktaskSD.vsd 3系统模块活动图
Manage law
（1）用户输入信息后，系统首先对用户提交的信息进行验证符合即进入不符合则返回登陆界面
（2）显示法规维护窗口程序等待下一步执行命令
(3) 查询信息，输入法规文件号等进行查询，系统列出该法规的详细信息
(4) 法规编辑，浏览等待编辑的法规。
对其进行修改和删除操作后，系统确认并保存（5）选择新建法规，输入各项法规信息系统进行判断（如果信息不全，责提示继续输入）输入信息正确后系统确认保存
（6）系统退出
）
15managelawAD
Manage key word
（1）用户输入信息，系统进行验证。
信息正确则进入不符合返回登陆界面
（2）进入条例搜索关键字主界面，系统等待执行命令
（3）选择新增关键字，系统要求先输入信息，并对关键字进行验证，如果相同或者不符合规范则返回继续输入，通过就进入下一步系统进行保存和确认并返回到显示页面。
（4）选择修改关键字，先选中要修改的关键字，并输入要修改后的信息或者选择删除造作和系统确认和保存。
系统返回显示页面
（5）系统退出
17managekeyword.mdl
Manage check task
（1）用户输入信息，系统进行验证通过进入修改检查任务显示界面，不符合返回登陆界面（2）显示选取检查任务界面，选定一个检查任务
（3）输入检查任务判断有无
（4）保存退出
19ManagechecktaskAD
4系统模块状态图
Enterprise checked state chart 受检单位信息管理
（1）首先，输入信息，判定信息验证是否成功，成功则进入，信息错误重新输入登陆信息（2）进入条例检查界面，若满足此条件：GSP standard[(serius defect<=0&&general defect<=10%)]，检查对象通过检查。
（3）若满足此条件：GSP standard[(serius defect<=2&&general defect>=10%)||(serious defect=0&&general defect<=30%)||serious defect>2]，检查对象则未通过，需重新检查直至满足此条件：GSP standard[(serious defect=0&&10%<general defect<=30%)||(serious defect<=2&&10%<general defect<=10%)]，则通过检查。
（3）各条例每个三月复检一次，复检合格，则通过检查
（4）系统退出
23enterprisecheckedstatechart(GSP)
Stautestatehart
（1）进入系统
（2）在条例本身是关键条例的的状态下条例是关键的，在条例本身是非关键条件下条例是非关键的。
（3）在受检单位符合该条例的条件下条例是合格的，在受检单位不符合该条例的条件下条例是不合格的
（4）系统退出
25stautestatechart.mdl
5整体系统部署图
分析：运行系统首先需要安装Microsoft SQL Server2000，.net2.0，服务器为database server,客户端为drug check office drug factory drug merchant drug retail drug store 设备之间可以用网线进行
27developmentdiagram
6系统软件重够建模总结：
通过课程设计相关实践活动，我对统一建模语言的功能有了更深一步的理解并且能够简单运用UML的模型图来表示被建模系统的某一方面的某一部分，将多个不同的模型图有机组合在一起来描述系统模型的某方面的特征。
之前对uml一些概念总有点模糊的，可是当你自己亲自动手去做了，并且认真的去思考这些问题，发现之前不理解的现在也弄懂了很多。
之前存在很多迷惑的地方，现在也有所减少。
也许可能课堂不太认真听，导致了对一些的不理解。
通过这次课程设计是我真正懂得一点：即使你不会也要大胆的去尝试，只有自己去做然后去改才可能有收获。