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案例--银行系统
（1）系统提示输入用户的相关信息 和转账金额。
（2）银行职员将相关信息输入后提 交，系统判断账户是否存在且有效，账 户中的金额是否大于转账金额。
（3）如果账户有效并存在同时金额 足够，建立交易记录，同时修改账户金 额，保存交易记录。
（4）判断转入账户是否属于同一银 行。如是同一银行，系统先确认转入账 户是否存在并有效。如有效更新账户相 关信息，建立转账记录，保存转账记录。 （5）如果转入和转出账户不是同一银
（1）系统提示输入用户的相关 信息和取款金额。
（2）银行职员将相关信息输入 后提交，系统判断账户是否存在且 有效，账户中的余额是否大于取款 金额。
（3）如果账户有效并存在同时 金额足够，建立交易记录，同时修 改账户金额，保存交易记录。
UML统一建模语言
三、创建系统动态模型 13、客户转账活动图
客户转账活动图创建二个泳道，分 别是银行职员对象和系统对象，具体的 活动过程描述如下：
UML统一建模语言
二、创建系统用例模型
银行职员用例能够通过 该系统进行如下活动：
（1）登录银行系统。银 行职员在登录系统时，必须 通过系统的身份验证才能进 入银行系统主界面进行下一 步的操作。
（2）对客户的账户进行 管理，包括为客户创建新的 账户、修改账户信息和删除 账户。
UML统一建模语言
二、创建系统用例模型
UML统一建模语言
三、创建系统动态模型
4、客户本行转账序列图和交互图
客户进行本行转账的工作流程如下： （1）客户向银行职员提出本行转账的 要求。 （2）银行职员在系统主界面请求转账 操作，系统创建转账界面。 （3）银行职员添加转账款信息后，提 交至账户类（转出）。 （4）账户类确认是否存在该账户，并 确认账户中的金额是否足够支付转账款项， 如可足够支付则计算新的账户余额，更新 数据库中该账户的信息，发送消息给转账 类，创建转账交易记录，保存转账交易记 录。 （5）转账界面将转账信息传递给账户 （转入），查询该账户是否存在。如存在 计算账户余额，然后更新数据库的数据。 发送消息给转账类，创建转账交易记录， 保存转账交易记录。
（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完整例子
- 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与其对应 而言只能有一个 与其对应