UML完整例子
UML系统需求分析建模实例(包括业务建模)
系统用例几乎总是以黑盒形式编 写的。它们描述了软件系统之外 的参与者如何与将被设计的系统 进行交互。系统用例详细阐明了 系统需求。系统用例模型的目的 是从涉众的角度说明需求，而不 是设计如何满足需求。
业务用例图中，可以让业务参与者【业 在系统用例图中，让参与者与用 务执行者】和业务角色【业务工人】与 例进行交互。 业务用例进行交互。
做专业的企业，做专业的事情，让自 己专业 起来。2 020年1 2月上 午12时3 5分20. 12.200: 35Dece mber 2, 2020
时间是人类发展的空间。2020年12月2 日星期 三12时 35分4 秒00:35: 042 December 2020
科学，你是国力的灵魂；同时又是社 会发展 的标志 。上午1 2时35 分4秒上 午12时 35分00 :35:042 0.12.2
原始需求愿景
1. 为员工提供账务的自动化办理，提高办 事效率，方便员工。
2. 方便财务部门管理好账务信息。
涉众分析
涉众
解释
期望
员工
公司的正式录用雇员 通过网上办理账务业务申 请，计算机控制流程
部门经理 部门负责人，负责审 方便审核操作，通过计算 核员工提交的申请 机代替原来的手工审核方 式。
公司主任 公司负责人，负责 2 方便审核操作，通过计算
次审核员工提交的申 机代替原来的手工审核方
请
式，界面友好易用。
财务主任 公司财务部门负责人，通过计算机转账的方式替 负责发放报账款项 代原来的人为付款方式。
业务用例获取（1）
定义：
" 业务用例从一个外部的，增加值的角度来描 述一个业务过程。为了给这个业务的涉众创造 价值，业务用例是超越组织边界的业务过程， 很可能包括合作伙伴和供应商。“
UML实例UML案例(完整建模)(汽车租赁系统)
建立UML模型框架
▪ 选择J2EE模式
系统的用例图
▪ 创建用例图之前首先需要确定参与者。 ▪ 系统中的参与者主要有两类： ① 客户 ② 公司职员
系统的用例图
▪ 1. 客户参与的用例图 ▪ 2. 公司职员参与的用例图
客户参与的用例图
公司职员参与的用例图
系统的时序图
▪ 1. 管理人员开展工作的时序图 ▪ 2. 客户预订车辆的时序图 ▪ 3. 客户取车的时序图 ▪ 4. 客户还车的时序图
theCommonWorker : CommonWorker
theSkillWorker : SkillWorker
theCar : Car
theServiceRecord : ServiceRecord
theCustomerRecord : CustomerRecord
theRenBiblioteka Record : WorkRecord
4: InServiced( )
3: check( )
8: new CustomerRecord
theCustomerRecord : CustomerRecord
客户取车的协作图
1: show_notice( )
4: take_car( ) : custormer
theRequestOrder : RequestOrder
returnback
check_carstatus( )
fillRecord( )
notify_payment( ) pay()
return
update_carstatus( )
end( ) updateRecord( )
系统的协作图
▪ 1. 客户预订的协作图 ▪ 2. 客户取车的协作图 ▪ 3. 客户还车的协作图
UML案例--银行系统
（2）银行职员将相关信息输入后提 交，系统判断账户是否存在且有效，账 户中的金额是否大于转账金额。
（3）如果账户有效并存在同时金额 足够，建立交易记录，同时修改账户金 额，保存交易记录。
（4）判断转入账户是否属于同一银 行。如是同一银行，系统先确认转入账 户是否存在并有效。如有效更新账户相 关信息，建立转账记录，保存转账记录。 （5）如果转入和转出账户不是同一银
（1）系统提示输入用户的相关 信息和取款金额。
（2）银行职员将相关信息输入 后提交，系统判断账户是否存在且 有效，账户中的余额是否大于取款 金额。
（3）如果账户有效并存在同时 金额足够，建立交易记录，同时修 改账户金额，保存交易记录。
UML统一建模语言
三、创建系统动态模型 13、客户转账活动图
客户转账活动图创建二个泳道，分 别是银行职员对象和系统对象，具体的 活动过程描述如下：
UML统一建模语言
二、创建系统用例模型
银行职员用例能够通过 该系统进行如下活动：
（1）登录银行系统。银 行职员在登录系统时，必须 通过系统的身份验证才能进 入银行系统主界面进行下一 步的操作。
（2）对客户的账户进行 管理，包括为客户创建新的 账户、修改账户信息和删除 账户。
UML统一建模语言
二、创建系统用例模型
UML统一建模语言
三、创建系统动态模型
4、客户本行转账序列图和交互图
客户进行本行转账的工作流程如下： （1）客户向银行职员提出本行转账的 要求。 （2）银行职员在系统主界面请求转账 操作，系统创建转账界面。 （3）银行职员添加转账款信息后，提 交至账户类（转出）。 （4）账户类确认是否存在该账户，并 确认账户中的金额是否足够支付转账款项， 如可足够支付则计算新的账户余额，更新 数据库中该账户的信息，发送消息给转账 类，创建转账交易记录，保存转账交易记 录。 （5）转账界面将转账信息传递给账户 （转入），查询该账户是否存在。如存在 计算账户余额，然后更新数据库的数据。 发送消息给转账类，创建转账交易记录， 保存转账交易记录。
UML实例UML案例(完整建模)(图书馆信息系统)
1: add item( ) : Administrator
: Maintenance Window
3: update( )
2: find(String)
: Item
: Title
2. 系统管理员删除书籍的协作图
1: remove item( ) : Administrator
: Maintenance Window
2: find(String)
3: Return true 4: reserve( )
系统的协作图
▪ 1. 系统管理员添加书籍的协作图 ▪ 2. 系统管理员删除书籍的协作图 ▪ 3. 图书管理员处理借书的协作图 ▪ 4. 图书管理员处理还书的协作图 ▪ 5. 借阅者预留书籍的协作图
1. 系统管理员添加书籍的协作图
5. 图书管理员处理书籍归还的时序图
: Borrower
: Librarian
: Return Window
1: give the book
2: return item( )
3: check( )
: Item
4: ok 5: update( )
6: update( )
: Loan
6. 借阅者查询书籍信息的时序图
或其他正式规定的文档所需要的条件或权 能。 ③ 反映以上（1）或（2）中描述的条件或权 能的文档说明。
软件需求的层次
▪ 软件需求包括三个层次： ▪ 业务需求：反映了组织机构或客户对系统
高层次的目标要求。 ▪ 用户需求：描述了用户使用产品所能完成
的任务。 ▪ 功能需求：说明了软件的功能，用户使用
这些功能以完成任务。
基本数据维护模块
▪ 基本数据维护模块包括的主要功能模块： ①添加借阅者帐户 ②修改更新借阅者帐户信息 ③添加书目 ④修改和更新书目信息 ⑤添加书籍 ⑥删除书籍
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系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
uml建模实例100例
uml建模实例100例UML（统一建模语言）是一种用于软件开发的标准建模语言，它可以帮助开发人员更好地理解、设计和实现软件系统。
下面是100个UML建模实例。
1. 用例图：描述系统功能和外部用户的行为。
2. 活动图：描述系统中的过程和活动，通常用来描述系统的业务流程。
3. 类图：描述系统中的类、属性和方法、关系等。
4. 对象图：描述系统中的对象及其关系。
5. 状态图：描述系统中的对象或类的状态和状态转换。
6. 序列图：描述系统中的对象或类之间的交互过程。
7. 协作图：描述系统中的对象或类之间的协作过程。
8. 构件图：描述系统的组成部分和它们之间的关系。
9. 部署图：描述系统的物理部署结构和组件之间的关系。
10. 通信图：描述系统中的对象之间的消息传递。
11. 包图：描述系统中的包和它们之间的关系。
12. 组合结构图：描述系统中的组成部分和它们之间的组合关系。
13. 时序图：描述系统中的对象或类之间的时间关系。
14. 交互概述图：描述系统中的对象或类之间的协作过程。
15. 系统顺序图：描述系统中的对象或类之间的时间关系。
16. 概念图：描述系统中的概念和它们之间的关系。
17. 数据流图：描述系统中的数据流和处理过程。
18. 流程图：描述系统中的过程和流程。
19. 参与者图：描述系统中的参与者和它们之间的关系。
20. 视图图：描述系统中的视图和它们之间的关系。
21. 规则图：描述系统中的规则和它们之间的关系。
22. 用例图扩展点：描述用例图中的扩展点和它们之间的关系。
23. 活动图扩展点：描述活动图中的扩展点和它们之间的关系。
24. 类图扩展点：描述类图中的扩展点和它们之间的关系。
25. 对象图扩展点：描述对象图中的扩展点和它们之间的关系。
26. 状态图扩展点：描述状态图中的扩展点和它们之间的关系。
27. 序列图扩展点：描述序列图中的扩展点和它们之间的关系。
28. 协作图扩展点：描述协作图中的扩展点和它们之间的关系。
UML完整例子
• “计算机类”、“非计算机类”是该系统中图书
的两大分类，因此应该对其建模，并改名为“计 算机类书籍”和“非计算机类书籍”，以减少歧
义；、
火龙果 整理
筛选备选类
• “外借情况”则是用来表示一次借阅行为， 应该成为一个候选类，多个外借情况将组 成“外借情况列表”，而外借情况中一个 很重要的角色是“朋友”—借阅主体。 • 虽然到本系统中并不需要建立“朋友”的 资料库，但考虑到可能会需要列出某个朋 友的借阅情况，因此还是将其列为候选类。 为了能够更好地表述，将“外借情况”改 名为“借阅记录”，而将“外借情况列表” 改名为“借阅记录列表”；
火龙果 整理
需求描述
• 在使用该系统录入新书籍时系统会自动按 规则生成书号，可以修改信息，但一经创 建就不允许删除。 • 该系统还应该能够对书籍的外借情况进行 记录，可对外借情况列表打印。 • 另外，还希望能够对书籍的购买金额、册 数按特定时间周期进行统计
火龙果 整理
火龙果 整理
4.绘制交互图
• 首先根据自己的喜好和实际的表现需要来 • 不过由于它们在语义上是等价的，因此可
以绘制出一种，再通过建模工具来自动转 换成另一种图 。 选择顺序图或通信图。
火龙果 整理
（1）准备工作
• 分析模型中的交互图彻重于分析类的职责分配
•
一本书只有一册，因此只能够被借一次，因此对于一本 Book而言只能有一个RecordId与其对应
火龙果 整理
限 定 • 分 析
火龙果 整理
3.绘制用例图
• 用例图的绘制流程
（1）记录需求—特性表
编号 说明
火龙果 整理
火龙果 整理
UML完整例子
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机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
(完整word版)UML综合案例
ＵＭＬ在ＡＴＭ自动取款机中的应用(一)Uml 基础知识Uml 概述UML （Unified Modeling Language)是软件界第一个统一的建模语言，该方法结合了Booch ， OMT ，和OOSE 方法的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术.它是一种标准的表示,已成为国际软件界广泛承认的标准。
是一种基于面向对象的可视化的通用（General ）建模语言。
为不同领域的用户提供了统一的交流标准 — UML 图。
UML 应用领域很广泛,可用于软件开发建模的各个阶段，商业建模（Business Modeling ）, 也可用于其它类型的系统。
UML 是一种定义良好,易于表达，功能强大且普遍实用的建模语言，不是一种方法，它独立于过程。
利用它建模时，可遵循任何类型的建模过程。
建模过程：UML 的主要构成向对象分析与设计的一种UML 是一种标准化的图形建模语言,它是面向对象分析与设计的一种标准表示.由：● 视图（views ）, ● 图(Diagrams ）,● 模型元素（Model elements ） ● 通用机制（general mechanism ）等几个部分构成。
视图(views）一个系统应从不同的角度进行描述，从一个角度观察到的系统称为一个视图（view）。
视图由多个图（Diagrams）构成，它不是一个图表(Graph）,而是在某一个抽象层上，对系统的抽象表示。
如果要为系统建立一个完整的模型图，需定义一定数量的视图,每个视图表示系统的一个特殊的方面。
另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。
图(Diagrams）UML语言定义了五种类型9种不同的图，把它们有机结合起来就可以描述系统的所有视图。
用例图(Use case diagram）从用户角度描述系统功能，并指出各功能的操作者。
静态图（Static diagram)，表示系统的静态结构.包括类图、对象图、包图。
详细的图书馆管理系统UML图终极版
The library management system UML diagrams1．需求（Requirements）经典地，由系统最终顾客旳代表写出文本形式旳需求规范文档。
对于该图书馆应用程序来说，需求规范文档应当类似于这样：1.这是一种图书馆支持系统；2.图书馆将图书和杂志借给借书者。
借书者已经预先注册，图书和杂志也预先注册；3.图书馆负责新书旳购置。
每一本图书都购进多本书。
当旧书超期或破旧不堪时，从图书馆中去掉。
4.图书管理员是图书馆旳员工。
他们旳工作就是和读者打交道并在软件系统旳支持下工作。
5.借阅人可以预定目前没有旳图书和杂志。
这样，当他所预定旳图书和杂志偿还回来或购进时，就告知预定人。
当预定了某书旳借书者借阅了该书后，预定就取消。
或者通过显式旳取消过程强行取消预定。
6.图书馆可以轻易地建立、修改和删除标题、借书者、借阅信息和预定信息。
7.系统可以运行在所有流行旳技术环境中，包括Unix, Windows和OS/2，并应有一种现代旳图形顾客界面 (GUI)。
8.系统轻易扩展新功能。
系统旳第一版不必考虑预定旳图书抵达后告知预定人旳功能，也不必检查借书过期旳状况。
Typically, the end user's representative by system of regulating write text document demand. For the library application, it should be similar to the standard document demand so:1. This is a library support system;2. The library will lend books and magazines JieShuZhe. JieShuZhe has register in advance, books and magazines will register in advance;3. New book purchase for library. The book is more than buying every book. When old books extended or worn out, removing from the library.4. The librarian is the library staff. Their job is to deal with the reader in software support system work.5. Borrowing people can be scheduled have no current of books and magazines. So, when his book of books and magazines returned back or purchase, confirmation. When booked MouShu JieShuZhe borrowing of the reservation is cancelled after. Or by explicit cancel process forcibly cancellation of reservation.6. The library can easily establish, modify and delete title, JieShuZhe, borrowing information and booking information.7. System can run on all popular technology environment, including Unix, Windows and OS / 2, and should have a modern graphical user interface (GUI).8. The system is easy to expand new functions.The first edition of need not consider booking system of books after confirmation of arrive, don't check function of books expired.2．分析（Analysis）系统分析旳目旳是捕捉和描述所有旳系统需求，并且建立一种模型来定义系统中重要旳域类。
UML包图的应用案例
UML包图的应用案例UML（Unified Modeling Language）是一种软件工程领域常用的建模语言，它提供了一套标准的符号和图形表示法，用于描述和设计软件系统的结构和行为。
其中，UML包图是一种用于展示系统的层次结构和组织关系的图形表示方法。
在本文中，我们将探讨UML包图的应用案例，并分析其在软件开发过程中的价值。
一、电子商务系统假设我们要开发一个电子商务系统，该系统包含商品管理、订单管理、用户管理等模块。
我们可以使用UML包图来表示系统的整体结构和模块之间的关系。
首先，我们可以创建一个顶层包，命名为“电子商务系统”，用来表示整个系统。
然后，在该包下创建三个子包，分别是“商品管理”、“订单管理”和“用户管理”。
每个子包再进一步细分为更小的包，表示不同的功能模块。
例如，“商品管理”子包可以包含“商品信息管理”、“库存管理”等子包。
通过使用UML包图，我们可以清晰地展示系统的层次结构，帮助开发人员更好地理解和组织代码。
此外，UML包图还可以用于与团队成员和客户进行沟通，让他们更容易理解系统的组成部分和模块之间的关系。
二、学生管理系统另一个应用UML包图的案例是学生管理系统。
假设我们要设计一个学生管理系统，包括学生信息管理、课程管理、成绩管理等模块。
我们可以使用UML包图来表示系统的模块结构和组织关系。
首先，创建一个顶层包，命名为“学生管理系统”，表示整个系统。
然后，在该包下创建三个子包，分别是“学生信息管理”、“课程管理”和“成绩管理”。
每个子包再细分为更小的包，表示不同的功能模块。
例如，“学生信息管理”子包可以包含“学生基本信息管理”、“学生选课管理”等子包。
通过使用UML包图，我们可以清晰地展示学生管理系统的模块结构，帮助开发人员更好地组织和管理代码。
此外，UML包图还可以用于与教师和学生进行沟通，让他们更容易理解系统的组成部分和模块之间的关系。
三、医院管理系统另一个应用UML包图的案例是医院管理系统。
UML类图说明
UML类图说明1：⽰例这是⼀个使⽤UML表⽰的类图的结构，通过箭头，菱形，实线以及虚线来代表⼀些类之间的关系，后⾯将按照上⾯的例⼦⼀⼀介绍说明。
上图中，abstract 车是⼀个抽象类。
⼩汽车和⾃⾏车是继承了车的抽象类，实现了抽象类的⼀些抽象⽅法，他们之间是实现关系。
SUV继承⼩汽车，SUV和⼩汽车之间是泛化关系！轮胎，发动机和⼩汽车之间是组合关系。
学⽣和班级之间是聚会关系。
学⽣和⾝份证之间是关联关系。
学⽣和⾃⾏车之间是依赖关系。
2：具体分析2.1：泛化关系上⾯UML图中，SUV和⼩汽车之间是⼀种泛化关系，SUV is a ⼩汽车，泛化关系⽤⼀种带有空⼼的箭头来表⽰。
在代码中表现的⽅式就是继承⾮抽象类的⽅式。
2.2：实现关系上⾯UML图中，⼩汽车，⾃⾏车与抽象类车，之间是⼀种实现关系。
重要的是要继承抽象类，或者实现接⼝这种关系是实现关系，在UML类图中使⽤虚线带箭头。
在代码中表现的⽅式就是继承抽象类。
2.3：聚合关系上⾯UML图中，学⽣和班级之间是⼀种聚合关系，表⽰班级有学⽣聚合⽽来，采⽤实线空⼼菱形箭头表⽰。
与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在；例如，班级撤销了，学⽣不会消失，他们依然存在。
2.4：组合关系上⾯UML图中，轮胎，发动机和⼩汽车之间是⼀种组合关系，采⽤实线实⼼菱形箭头表⽰。
与聚合关系不同的是，整体和部分是强依赖的，即使整体不存在了，组合部分也不存在；例如，⼩汽车没有，⾃然轮胎和发动起，也不会存在了。
2.5：关联关系上⾯UML图中，学⽣和⾝份证是⼀种关联关系。
关联关系是⽤⼀条直线表⽰的；它描述不同类的对象之间的结构关系；它是⼀种静态关系，通常与运⾏状态⽆关，⼀般由常识等因素决定的；它⼀般⽤来定义对象之间静态的、天然的结构；所以，关联关系是⼀种“强关联”的关系；⽐如，乘车⼈和车票之间就是⼀种关联关系；学⽣和学校就是⼀种关联关系；2.6：依赖关系上⾯UML图中，学⽣和⾃⾏车之间是⼀种依赖关系。
UML建模案例——即时通信系统
案例：即时通信系统1、问题描述设计一个即时通信系统，实现多个用户进行网上聊天的功能，各个聊天客户端通过注册、登录才可以和好友进行通信。
系统既包括客户端部分、也包括服务器端部分。
在客户端能够实现消息的查看，添加和删除网上的好友，与选定的好友进行通信，查询自己与好友的聊天记录等功能。
服务器端负责好友的在线维护，同时服务器还应该具有保存用户资料和用户聊天记录的功能。
此外，当用户不在线时，收到的好友消息能够被保存，使用户在下次登录时可以查看。
2、建立用例模型（1）确定参与者当考虑构造一个系统时，首先要确定系统的边界，即主体。
系统边界定义了由谁（参与者）使用系统，系统能够为参与者提供什么功能（用例）。
根据定义，参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。
为了确定参与者，需要考虑谁或什么使用系统，它们在与系统的交互中扮演什么角色，然后归纳它们。
一般地，寻找参与者可以从一下问题入手：●系统开发完成后，有哪些人会使用这个系统？●系统需要从哪些人或其他系统获取数据？●系统会为哪些人或其他系统提供数据？●系统会与哪些其他系统相关联？●系统是由谁维护和管理的？●谁启动或关闭系统？这些问题有助于抽象出系统的参与者。
分析：●对于即时通信系统，参与聊天的客户（Client）显然是系统的参与者。
●为了完成在线客户的管理和客户信息的验证等功能，需要有一个服务器（Server）。
●为了实现客户信息和通信记录的存储等功能，需要有一个数据库（DataBase）。
（2）确定用例确定参与者后，就可以根据参与者来确定系统的用例，用例是参与者想要系统做的事情。
需找用例可以从以下问题入手（针对每一个参与者）：●参与者希望系统提供什么功能？●参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？●参与者是否会将外部的某些事件通知给该系统？●系统是否会将部的某些事件通知给该参与者？分析：●参与者Client使用的用例有：Register（注册账号）、Log in（登录系统）、Log out（退出系统）、Send Message(发送消息)、Add Friends（添加好友）、Delete Friends（删除好友）、Query Record（查询聊天记录）等。
苏州科技学院UML建模技术案例
Credit System
(from Actor)
Flight Coordinator
(from Actor)
62
Airline
案例1：航空售票系统
Purchase Ticket Check credit Change Reservation
Credit System
(from Actor)
58
识别思路：
• • • • • • • • • 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务
操作员，管理员 操作员，管理员 操作员，管理员
领料员,退料员,操作员,管理员,供应商
谁负责维护、管理并保持系统正常运行案 管理员 系统需要应付那些硬件设备 生产系统, 供应商系统 系统需要和那些外部系统交互 操作员,管理员,领料员,退料员 谁对系统运行产生的结果感兴趣 时间、气温等内部外部条件 时间
(from Actor)
Flight Coordinator
(from Actor)
57
Airline
案例2：库存管理系统
某汽车制造厂需要一套库存管理系统， 该系统实现的业务：生产工人根据生 产计划领取物料，库存操作员根据生 产系统的派单准备，交付给领料工人， 余料即时归还库房。库房管理人员定 期盘点库存，通知供应商供货，对长 期积存的货物，申请退货。
75
76
练习： 建模航班状态图 创建一个状态图来描述航班如何从提出申请、制定航班计划、 售票、起飞、飞行、到着陆的状态过程。 练习步骤； 1）标识出要建模的实体。 2）标识出实体的状态。
77
航班计划 批准航班计划 航班申请
entry/ 发 布 航 班 信 息 do/ 检 查 当 前 日 期
UML实践参考例子
UML使用案例----网上选课系统网上选课系统主要包括如下功能：管理员通过管理界面进入，建立本学期要开的各种课程、将课程信息保存在数据库里并可以对课程进行改动和删除。
学生通过客户机浏览器根据学号和密码进入选课界面，在这里学生可以进行三种操作：查询已选课程、选课以及付费。
同样，通过业务层，这些操作结果存入数据库中。
本系统拟使用Java语言通过三层模型实现：数据核心层，业务逻辑层和接入层。
其中，数据核心层包括对于数据库的操作；业务逻辑层作为中间层对用户输入进行逻辑处理、再映射到相应的数据层操作；而接口层包括用户界面，包括系统登入界面、管理界面、用户选课界面等。
本系统涉及的用户包括管理员（Registrar）和学生（Student），他们是用例图中的活动。
数据库管理系统是另外一个活动者。
注：因为付费方式的多样化，所以在此将不讨论涉及到付费有关的设计。
1．1用例图1．1．1事件流①添加课程事件流：1.管理员选择进入管理界面，用例开始。
2.系统提示输入管理员密码。
3.管理员输入密码。
4.系统验证密码。
A1：密码错误5．进入管理界面，系统显示目前所建立的全部课程信息。
6．管理员选择添加课程。
7．系统提示输入新课程信息。
8．管理员输入信息。
9．系统验证是否和已有课程冲突。
A2：有冲突10．系统添加新课程，提示课程添加成功。
11．系统重新进入管理主界面，显示所有课程。
12．用例结束。
其他事件流：A1：密码错误1．系统提示再次输入。
2．用户确认。
3．三次错误，拒绝再次访问。
4．否则进入添加课程事件流第5步。
A2：有冲突1．系统提示冲突，显示冲突课程信息。
2．用户重新输入。
3．继续验证直到无冲突。
4．进入添加课程事件流第10步。
注：删除课程事件流和修改课程事件流与此类似，在此不再详述。
②选课事件流：1.学生进入选课登入界面，用例开始.2.系统提示输入学号和密码.3.学生输入学号密码.4.系统验证：A1;验证失败。
5、进入选课主界面。
UML类图符号各种关系说明以及举例
UML类图符号各种关系说明以及举例UML中描述对象和类之间相互关系的⽅式包括：依赖（Dependency），关联（Association），聚合（Aggregation），组合（Composition），泛化（Generalization），实现（Realization）等。
依赖（Dependency）：元素A的变化会影响元素B，但反之不成⽴，那么B和A的关系是依赖关系，B依赖A；类属关系和实现关系在语义上讲也是依赖关系，但由于其有更特殊的⽤途，所以被单独描述。
uml中⽤带箭头的虚线表⽰Dependency关系，箭头指向被依赖元素。
泛化（Generalization）：通常所说的继承（特殊个体 is kind of ⼀般个体）关系，不必多解释了。
uml中⽤带空⼼箭头的实线线表⽰Generalization关系，箭头指向⼀般个体。
实现（Realize）：元素A定义⼀个约定，元素B实现这个约定，则B和A的关系是Realize，B realize A。
这个关系最常⽤于接⼝。
uml 中⽤空⼼箭头和虚线表⽰Realize关系，箭头指向定义约定的元素。
关联（Association）：元素间的结构化关系，是⼀种弱关系，被关联的元素间通常可以被独⽴的考虑。
uml中⽤实线表⽰Association 关系，箭头指向被依赖元素。
聚合（Aggregation）：关联关系的⼀种特例，表⽰部分和整体（整体 has a 部分）的关系。
uml中⽤带空⼼菱形头的实线表⽰Aggregation关系，菱形头指向整体。
组合（Composition）：组合是聚合关系的变种，表⽰元素间更强的组合关系。
如果是组合关系，如果整体被破坏则个体⼀定会被破坏，⽽聚合的个体则可能是被多个整体所共享的，不⼀定会随着某个整体的破坏⽽被破坏。
uml中⽤带实⼼菱形头的实线表⽰Composition关系，菱形头指向整体。
1.1.1 依赖（Dependency）:虚线箭头表⽰1、依赖关系也是类与类之间的联结2、依赖总是单向的。
UML案例_超市进销存系统
打开业务界 面
输入商品( 可重复)
计算总价
付款
打印清单
保存购买记 录
“销售”场景的时序
: 销售UI
: 商品
: 售货员 1: 输入订购商品( ) 2: 读取商品信息( ) 3: 计算总价( )
4: 接受付款( )
5: 打印清单( )
<<extend>>
报损
<<include>>
入库
检查商品
查询
3、订货
❖需求描述：
➢ 订货员用新商品供应商信息 更新供应商数据库的信息
➢ 订货员统计库存商品是否低 于库存下限，然后制作订货 单
❖提到的业务：
➢ 1.更新供应商数据库 ➢ 2.订货
条件：某商品的库存低于 下限
制作订货单是一个步骤 应该会有选择供应商这个
1、销售
❖可能特殊的步骤，与重复的步骤一样，可用包 含关系列出：
<<include>>
售货员
销售
保存购买记录
<<include>>
付款
顾客
1、销售
❖本场景中可能存在的实体类有：
➢ 商品：应该会有ID、名称、单价等属 性
➢ 总价：应该是清单和购买记录的一项 数据。
➢ 清单：给顾客看的纸 ➢ 购买记录：与清单的内容应该是一致
➢ 5.打印清单并交给顾客
➢ 6.保存购买记录？
打开业务界 面
输入商品( 可重复)
计算总价
付款
打印清单
保存较特殊的步骤：
➢1.付款
系统会支持什么样的支付方式未知 如果只收现金，则系统中只需要售货员确认已收款 如果支持刷卡，系统需要有支付接口 详细情况
uml图例讲解
9
A
UML图例讲解
(10)当手机开机时，它处于空闲状态，当用户使用电话呼叫某 人时，收集进入拨号状态。如果呼叫成功，即电话接通，手机 就处于通话状态；如果呼叫不成功，如对方线路有问题或关机， 则拒绝接听。这时手机停止呼叫，重新进入空闲状态，手机进 入空闲状态下被呼叫，手机进入响铃状态(ringing)；如果用户 接听电话(pick)，手机处于通话状态；如果用户未做出任何反 应，可能他没有听见铃声，手机一直处于响铃状态，如果用户 拒绝来电，手机回到空闲状态。
教务管理人员：
①登录系统；
②教师、学生名单管理；
③学期教学计划管理；
④成绩管理；
⑤课程分配，每次课程分配时都必须打印任课通知书。
学生：
①登录系统；
②选课。
教师：
①登录系统；
②成绩管理，并且可以选择是否生成成绩单。
请根据以上信息画出该系统的用例图。
1
A
UML图例讲解
(2)某银行储蓄系统需求说明如下。
“上课登记”用例的主要事件流如下： 学生从系统菜单中选择“上课登记”； 系统显示指纹识别界面； 学生将手指放置于界面上； 系统捕获并识别学生的指纹，向学生返回识别的身份信息； 学生选择“确认”按钮； 系统生成一个关于该登记学生及当前日期、时间的新记录，并将该记录 保存到数据库中。 请根据以上描述绘制“上课登记”用例的顺序图。
2
A
UML图例讲解
(3)一个公司可以雇佣多个人，某个人在同一时刻只能为一家 公司服务。每个公司只有一个总经理，总经理下有多个部门经 理管理公司的雇员，公司的雇员只归一个经理管理。请为上面 描述的关系建立类模型，注意捕捉类之间的关联并标明类之间 的多重性。
uml组合关系的例子
uml组合关系的例子嘿，朋友！咱们今天来聊聊 UML 组合关系。
你知道吗？这组合关系就好比是一个团队里的核心成员。
比如说，一辆汽车和它的发动机，发动机那可是汽车的关键部分，没了发动机，这汽车就跑不起来啦！这汽车和发动机之间的关系，就是典型的组合关系。
再想想，咱们的身体和心脏。
心脏对于身体来说，多重要啊！一旦心脏出了问题，整个身体都得遭殃。
身体和心脏之间，不也是一种紧密的组合关系嘛。
还有哦，像一台电脑和它的主板。
主板是电脑运行的基础，没有好的主板，电脑的性能就没法保障。
这电脑和主板的关系，跟咱们说的UML 组合关系是不是很像？比如说一个公司，各个部门之间可能有各种各样的联系，但研发部门和核心技术团队的关系，那就是一种组合关系。
核心技术团队就像是公司的心脏，决定着公司的发展方向和竞争力。
又好比一个乐队，乐器和乐手之间的关系可能比较多样，但主唱和乐队的关系往往就是组合关系。
主唱的表现直接影响着整个乐队的演出效果。
你看，在一个家庭里，父母和孩子也可以看作是一种组合关系。
孩子的成长离不开父母的关爱和教育，父母的生活也因为孩子而有了更多的责任和期待。
再比如说，一个花园和里面精心栽培的珍稀花卉。
珍稀花卉让花园变得独特而美丽，花园为花卉提供了生长的环境。
UML 中的组合关系，强调的是整体和部分之间一种“同生共死”的紧密联系。
部分不能脱离整体而单独存在，就像鱼离不开水一样。
想想看，如果汽车没有了发动机，还能叫汽车吗？如果身体没了心脏，那还能正常运转吗？所以啊，理解 UML 组合关系，就是要明白这种紧密、不可分割的关系，就像生活中那些相互依存、缺一不可的存在一样。
总之，UML 组合关系在软件开发和设计中非常重要，能帮助我们更清晰地理解和构建复杂的系统结构。
只要我们多观察生活中的例子，就能更好地掌握它！。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
(3) 得到候选类
书籍 计算机类书籍 非计算机 类书籍 借阅记录 借阅记录列表 书籍列表
在使用"名词动词法"寻找类的时候,很多团 在使用"名词动词法"寻找类的时候, 队会在此耗费大量的时间,特别是对于中大型项目, 队会在此耗费大量的时间,特别是对于中大型项目, 这样很容易迷失方向. 这样很容易迷失方向.其实在此主要的目的是对问 题领域建立概要的了解, 题领域建立概要的了解,无需太过咬文嚼字
特性
用例
FEAT07.按书名,作者,类别,出版社等关键字组合查查 UC03.查查书籍 按书名,作者,类别, 按书名 查查书籍 书籍 信息 FEAT08.列出所有书籍信息 列出所有书籍信息 FEAT14.所有查查,列表,统计功能应可以单独对计算机 所有查查, 所有查查 列表, 类或非计算机类进行 FEAT09.登录登登情况 登录登登情况 FEAT10.登登状态能够自动反应在书籍信息中 登登状态能够自动反应在书籍信息中 UC04.登登登登 登登登登 信息
(4)用例图
新增书籍信息
<<extend>> 查查书籍信息 <<include>>
修改书籍信息
查查登登信息 图书管理员 登登登登信息
统计统统和统数
(5)细化用例描述—搭框架 )细化用例描述—
(2)筛选备选类
筛选备选类
"基本信息"则是书名,作者,类别等描述书籍的 基本信息"则是书名,作者, 基本信息 基本信息统称, 关键字"则是代表其中之一, 基本信息统称,"关键字"则是代表其中之一, 因此无需对其建模; 因此无需对其建模; "功能","新书籍","信息","登录"都 功能" 新书籍" 信息" 登录" 是在描述需求时使用到的一些相关词语, 是在描述需求时使用到的一些相关词语,并不是 问题域的本质,因此先可以将其淘汰掉; 问题域的本质,因此先可以将其淘汰掉;
主要的成员方法是新增,修改,查询(按关键字 主要的成员方法是新增,修改,查询( 查询),统计(按特定时限统计册数与金额). ),统计 查询),统计(按特定时限统计册数与金额).
借阅记录类:借阅人(朋友),借阅时间. 借阅记录类:借阅人(朋友),借阅时间. ),借阅时间 借阅记录列表类:主要职责就是添加记录(借 借阅记录列表类:主要职责就是添加记录(
需求描述
在使用该系统录入新书籍时系统会自动按 规则生成书号,可以修改信息, 规则生成书号,可以修改信息,但一经创 建就不允许删除. 建就不允许删除. 该系统还应该能够对书籍的登登情况进行 登录,可对登登情况列表打印. 登录,可对登登情况列表打印. 另登,还希望能够对书籍的购买统统,统 另登,还希望能够对书籍的购买统统, 数按特定时间周期进行统计
识别参与者
需求研讨会和联合应用开发会议的登录: 需求研讨会和联合应用开发会议的登录: 这些会议的参与者通常是很重要的, 这些会议的参与者通常是很重要的,因为 他们在组织中所代表的角色就是可能与系 统发生交互的参与者. 统发生交互的参与者. 当前过程和系统的培训指南及用户手统: 当前过程和系统的培训指南及用户手统: 这些东西中经常会有潜在参与者. 这些东西中经常会有潜在参与者.
"计算机类","非计算机类"是该系统中图书 计算机类" 非计算机类"
的两大分类,因此应该对其建模,并改名为" 的两大分类,因此应该对其建模,并改名为"计 算机类书籍" 非计算机类书籍" 算机类书籍"和"非计算机类书籍",以减少歧 义;,
筛选备选类
"登登情况"则是用来表示一次登阅行为, 登登情况"则是用来表示一次登阅行为, 登登情况 应该成为一个候选类, 应该成为一个候选类,多个登登情况将组 登登情况列表" 成"登登情况列表",而登登情况中一个 很重要的角色是"朋友" 登阅主体 登阅主体. 很重要的角色是"朋友"—登阅主体. 虽然到本系统中并不需要建立"朋友"的 虽然到本系统中并不需要建立"朋友" 资料库, 资料库,但考虑到可能会需要列出某个朋 友的登阅情况,因此还是将其列为候选类. 友的登阅情况,因此还是将其列为候选类. 为了能够更好地表述, 登登情况" 为了能够更好地表述,将"登登情况"改 名为"登阅登录" 而将"登登情况列表" 名为"登阅登录",而将"登登情况列表" 改名为"登阅登录列表" 改名为"登阅登录列表";
(2)识别参与者
已有的上下文关系图(表示系统范围)及 已有的上下文关系图(表示系统范围) 其他相关模型: 其他相关模型:它们描述了系统与登部系 统的边界, 统的边界,从这些图中可以寻找出与系统 有交互关系的登部实体. 有交互关系的登部实体. 项目相关人员分析:对项目的相关人员进 项目相关人员分析: 行分析, 行分析,就能够决定出哪些人将会与系统 进行交互. 进行交互. 书面的规格说明和其它项目文档(如会谈 书面的规格说明和其它项目文档( 备忘录等) 备忘录等)
(4)关联分析,建模,多重性分析,再建模
(5) 职责分析
书籍类:从需求描述中,可找到书名,类别,作 书籍类:从需求描述中,可找到书名 类别, 书名,
者,出版社;同时从统计的需要中,可得知"定 出版社;同时从统计的需要中,可得知" 也是一个关键的成员变量. 价"也是一个关键的成员变量.
书籍列表类:书籍列表就是全部的藏书列表,其 书籍列表类:书籍列表就是全部的藏书列表,
类,非计算机类分别建档,实现按书名,作 非计算机类分别建档,实现按书名, 分别建档 书名 类别,出版社等关键字的组合查查功能. 的组合查查功能 者,类别,出版社等关键字的组合查查功能.
发现类
在使用该系统录入新书籍时系统会自动按规 在使用该系统录入新书籍 系统会自动按 新书籍时 会自动按规
则生成书号,可以修改信息,但一经创建就 生成书号,可以修改信息, 书号 信息 不允许删除. 不允许删除.
UML完整例子 UML完整例子
书籍管理系统分析与设计
1.需求描述 1.需求描述
小王是一个爱书之人,家里各类书籍已过 小王是一个爱书之人, 千统,而平时又时常有朋友登登, 千统,而平时又时常有朋友登登,因此需 要一个个人图书管理系统. 要一个个人图书管理系统. 该系统应该能够将书籍的基本信息按计算 机类,非计算机类分别建档,实现按书名, 机类,非计算机类分别建档,实现按书名, 作者,类别, 作者,类别,出版社等关键字的组合查查 功能. 功能.
筛选备选类
"购买统统","统数"都是统计的结果, 购买统统" 购买统统 统数"都是统计的结果, 都是一个数字,因此不用将其建模, 都是一个数字,因此不用将其建模,而 特定时限"则是统计的范围, "特定时限"则是统计的范围,也无需将 其建模;不过从这里的分析中, 其建模;不过从这里的分析中,我们可以 发现, 发现,在该需求描述中隐藏着一个关键 书籍列表, 类—书籍列表,也就是执行统计的主体. 书籍列表 也就是执行统计的主体.
限 定 分 析
3.绘制用例图 3.绘制用例图
用例图的绘制流程
(1)登录需求—特性表 )登录需求—
编号 FEAT01 FEAT02 FEAT03 FEAT04 FEAT05 FEAT06 FEAT07 FEAT08 FEAT09 FEAT10 FEAT11 FEAT12 FEAT13 FEAT14 新增书籍信息 修改已有的书籍信息 书籍信息按计算机类, 书籍信息按计算机类,非计算机类分别建档 录入新书时能够自动按规则生成书号 计算机类与非计算机类书籍采用不同的书号规则 录入新书时如果重名将自动提示 按书名,作者,类别, 按书名,作者,类别,出版社等关键字组合查查书籍 列出所有书籍信息 登录登登情况 登登状态能够自动反应在书籍信息中 按人, 按人,按书查查登登情况 列出所有的登登情况 按特定时间段统计购买统统, 按特定时间段统计购买统统,统数 所有查查,列表,统计功能应可以单独对计算机类或非计算机类进行 所有查查,列表, 说明
2.类图的设计 - (1)发现类 2.类图的设计
小王是一个爱书之人,家里各类书籍已过千 小王是一个爱书之 是一个爱书之人 家里各类书籍已过千 各类书籍
统,而平时又时常有朋友登登,因此需要一 而平时又时常有朋友登登, 朋友登登 个人图书管理系统. 个个人图书管理系统.
该系统应该能够将书籍的基本信息按计算机 该系统应该能够将书籍的基本信息 基本信息按
),删除记录 归还) 删除记录( 出),删除记录(归还)以及打印借阅记录
类图
(6) 限定与修改
导航性分析: 之间, 导航性分析:Book与BookList之间,BorrowRecord和 与 之间 和 BorrowList之间是组合关系均无需添加方向描述,而 之间是组合关系均无需添加方向描述, 之间是组合关系均无需添加方向描述 Book与BorrowRecord之间则是双方关联,也无需添加 之间则是双方关联, 与 之间则是双方关联 约束: 约束: Book对象创建后就不能够被删除只能被修改,因此在 对象创建后就不能够被删除只能被修改, 对象创建后就不能够被删除只能被修改 Book类边上加上用自由文本写的约束 ; 类边上加上用自由文本写的约束 一本书要么属于计算机类,要么属于非计算机类, 一本书要么属于计算机类,要么属于非计算机类,因此 约束限定符: 在ItBook和OtherBook间加了 "{Xor}"约束限定符: 和 间加了 约束限定符 一本书只有一册,因此只能够被借一次, 一本书只有一册,因此只能够被借一次,因此对于一本 Book而言只能有一个 而言只能有一个RecordId与其对应 而言只能有一个 与其对应