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建模案例_即时通信系统方案

.Register UC001高客户、数据库客户在即时通信系统中注册客户端应用程序主界面已经启动1、客户单击"注册"按钮;2、系统弹出一个注册交互对话框;3、客户输入注册信息;4、客户单击"提交"按钮,发送注册信息到数据库;5、数据库保存注册信息,并自动生成一个数字ID 返回;6、客户端弹出对话框显示注册的ID,提示注册成功7、用例终止。
在单击"提交"按钮前,客户可随时单击"取销"按钮,关闭注册窗口,返回客户端界面提示注册错误,请稍后再试,客户确认,然后返回客户端主界面客户获得一个ID,可用此ID 登录系统开始即时通信Log in UC002高客户、服务器客户登录即时通信系统客户端应用程序主界面已经启动,并且已经有了注册ID1、客户输入ID 和密码;2、客户单击"登录"按钮,发送登录请求到服务器;3、服务器执行"验证用户"用例,将登录请求中的信息发送给数据库;4、数据库将ID 和密码与数据库中的注册记录比对;5、如果用户信息合法,数据库发送合法信息、用户的详细注册资料和用户不在线期间收到的离线消息给服务器,否则进入可选事件流。
6、服务器将客户加入在线用户列表,返回登录成功消息和离线消息给客户,并将在线用户列表发送给所有的在线用户。
7、提示登录成功,更新好友列表的状态信息并显示离线消息8、用例终止将用户不合法消息发送给客户,提示重新登录提示登录失败,请稍后再试,客户确认,然后返回客户端主界面主界面显示用户好友及好友的在线状态Send Message UC003高客户、数据库客户给自己的好友〔在线和离线发送消息客户已成功登录即时通信系统1、客户选择一个好友;2、系统激活主界面消息编辑文本框;3、客户在文本框中输入、编辑消息,然后单击"发送" 按钮;4、如果好友不在线,发送消息给数据库,数据库保存该聊天记录;否则执行可选事件流5、数据库返回聊天记录已保存的通知。
UML实例UML案例(完整建模)(汽车租赁系统)课件

Manager manager;Boolean
◆Manager() wewwokinfo)
CommonWorker cammissionRate;int
calculate() checkRequest0
SkillWorker skills;String quaifcations:String
Allow() isHandled()
ok create new customer record
17
客户取车的时序图
theCustomer:Customer theRequestOrder: RequestOrder
show/hotice()
theCommonWorker: CommonWorker
1.* Customer ACarType:Sting licenseNo:String
Customer( grint0
BenuestOrde CarType RentDate Aiow
Aliow( Oder Scheck( WisHandled(
1
ServiceRecord
seMceHistory
3
系统功能需求
满足上述需求的系统主要包括以下模块: ① 基本数据维护模块 ② 基本业务模块 ③ 数据库管理模块 ④ 信息查询模块
4
基本数据维护模块
基本数据维护模块包括的主要功能模块: ① 添加车辆信息 ② 修改车辆信息 ③ 添加员工信息 ④ 修改员工数据
5
基本业务模块
基本业务模块包含的功能: ① 用户填写预定申请 ② 工作人员处理预定请求 ③ 技术人员填写服务记录 ④ 工作人员处理还车
22
客户还车的协作图
UML建模实验报告02

UML建模实验报告02UML建模实验报告021.实验目的本实验的目的是通过实际项目案例,了解和掌握使用UML建模工具进行软件系统建模的过程和方法。
2.实验过程本次实验我们选择了一个简单的在线购物系统作为项目案例。
首先,我们进行了需求分析,确定了系统的功能和特性。
然后,我们进行了领域建模,识别出了系统的核心概念和实体。
接下来,我们进行了用例建模,识别出了系统的用例,并绘制了用例图。
然后,我们进行了行为建模,设计了系统的顺序图和活动图。
最后,我们进行了结构建模,设计了系统的类图和对象图。
3.实验结果通过本次实验,我们成功完成了在线购物系统的建模过程,并获得了以下结果:1)需求分析:我们确定了系统的功能和特性,包括用户登录、浏览商品、添加到购物车、下订单等。
2)领域建模:我们识别了系统的核心概念和实体,包括用户、商品、购物车、订单等,并绘制了类图。
3)用例建模:我们识别了系统的用例,并绘制了用例图,包括登录、浏览商品、添加到购物车、下订单等。
4)行为建模:我们设计了系统的顺序图和活动图,包括用户登录、浏览商品、添加到购物车、下订单等的流程和交互。
5)结构建模:我们设计了系统的类图和对象图,识别了系统的类和对象,包括用户、商品、购物车、订单等。
4.实验总结通过本次实验,我们深入了解和体验了使用UML建模工具进行软件系统建模的过程和方法。
我们发现UML建模工具可以很好地帮助我们理清系统的功能和特性,识别出系统的核心概念和实体,设计系统的用例、顺序图、活动图、类图和对象图。
通过建模过程,我们可以更加清晰地理解系统的需求和设计,并与团队成员进行有效的沟通和协作。
同时,我们也发现UML建模工具的使用需要一定的学习和实践,尤其是对于一些高级建模概念和技术的掌握。
因此,我们认为在今后的实践中,需要进一步学习和应用UML建模工具,以提高我们的建模能力和技术水平。
5.实验改进建议根据本次实验的经验和总结,我们提出以下改进建议:1)在实验前进行必要的学习和准备,了解UML建模工具的基本概念和使用方法,以充分发挥工具的功能和效能。
UML建模案例之图书管理系统

<<Bus ines Object>> s Item itemid : Integer ti tle : ObjId loan : ObjId Item() getTi tleName( ) getId() s etLoan() getLoan() is Borrowed() write() read() 0..n
2、2 分析--需求分析
1、识别角色:系统角色是人或其它外部系统。他/它将在 系统开发和运行过程中和系统进行交互、对话。
Librarian
Borrower
maintain
Account??
2、识别用例 ♦用例描述了系统对外表现的特征和性能
–每个用例是由系统用户通过对话框进行的一系列相关活动
♦对每个系统用户进行分析,抽象他和系统之间可能的交互方
3: find Item ( )
4: find on title (Title)
5: identify borrower ( ) 6: find (String) 7: create (Borrower information, Item)
三、设计
设计阶段对分析模型进行扩展并将模型进一步细化,并考 虑技术细节和限制条件。设计的目的是指定一个可行的解 决方案,以便能很容易地转变成为编程代码。
<<Bus ines Object>> s Borrow erInformation las tname : String firs tname : String addres : String s city : String zip : String s tate : String loans : ObjId[] res ervations : ObjId[]
UML建模案例分析

确定候选类: 学生、学习计划、成绩单、教授、课程、班级
3. 标识类属性
确定候选类的描述属性的相关方法:
(1)在候选类筛选过程中,有些名词或名词短语已经确定为描述属性,如“学位”为学生的描述属性、 “听课位置”、听课时间、学期是班级类的描述属性;
相关用例:
系统登录 建立学习计划 查询授课班级信息
5 建立用例和演员之间的关系
• 利用演员和用例的交叉引用表,来描述用例和演员之间的关系:
启动演员
用例 • 系统登录 • 建立学习计划 • 审核学习计划 • 注册课程班级 • 取消注册课程 • 查询授课班级信息 • 查询学生信息 • 查询学生成绩单 • 公布课程成绩 • 维护后台基础数据
图
UML语言定义了五种类型,9种不同的图,把它们 有机的结合起来就可以描述系统的所有视图。
用例图(Use case diagram) 从用户角度描述系统功 能,并指出各功能的操作者。
静态图(Static diagram),表示系统的静态结构。包 括类图、对象图、包图。
行为图(Behavior diagram),描述系统的动态模型 和组成对象间的交互关系。包括状态图、活动图。
交互图(Interactive diagram), 描述对象间的交互关 系。包括顺序图、合作图。
实现图( Implementation diagram ) 用于描述系统的 物理实现。包括构件图、部件图。
SRS系统用例建模
1、了解系统需求,需要寻求以下问题答案
• (1)谁将使用待开发的系统? • (2)系统需要提供什么有价值的服务? • (3)当用户与系统交互时,他们期待什么效果?
学生最迟可以在学期的第一个星期末决定退出所选课程班级。
UML建模案例——酒店预订系统

UML统一建模语言
三、创建系统动态模型 10、预订类状态图
在订餐管理系统中,有明确状态转换旳类是预订类。预订类包括下列三 种状态:被预订旳状态、被取消旳状态、预订结束旳状态。它们之间旳转化 规则是:
(1)接待员接受客人旳订餐,将订餐信息输入系统,表达预订类进入了 被预订旳状态。
(2)当客人取消订餐旳要求被接受,接待员将系统中原来旳订餐信息取 消时,该预订类进入被取消旳状态。
订餐系统旳功能性需求包括以下内容: (1)酒店旳接待员使用电话为客人提供订餐服务,根据 客人旳订餐要求,在指定旳时间和桌位安排好客人旳就餐事 宜;按客人旳要求执行修改订单旳操作;在客人临时取消预 订时删除订餐信息;在客人订餐时间到达前,及时提供电话 提醒服务。 (2)酒店领班在订餐客人到店用餐时和用餐离店后分别 在系统做好记录并保存;能够为客人注册成为会员;可以查 询、修改和删除会员信息;可觉得客人提供换桌服务。
(1)接待员在操作界面输入要 取消旳订单号旳。
(2)系统判断该订单是否存在。 假如不存在向界面返回订单不存在 旳信息。
(3)假如该订单存在则更改订 单旳状态并更新数据库订单旳数据。 同步,向界面返回取消订餐成功旳 信息。
UML统一建模语言
三、创建系统动态模型 13、接待员定时提醒预订活动图
接待员定时提醒预订旳活动图 中,创建了二个泳道,系统对象泳 道和接待员对象泳道,活动过程描 述如下:
18、领班修改会员信息活动图
领班修改会员信息旳活动图, 先创建了个二个泳道,分别是领班 对象和系统对象。详细旳活动过程 如下:
(1)领班在界面中输入会员编 号。
(2)系统判断该会员是否存在。 假如不存在此会员,将此信息返回 给界面。
(3)假如有该会员存在,就修 改会员信息并保存。然后更新数据 库会员旳数据。
UML系统需求分析建模实例包括业务建模

UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率,决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作,包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工:具有查看和修改个人信息的权限。
- 人事部门:负责对员工信息进行管理、薪资管理和请假管理。
- 管理员:拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图,包括主要的参与者和他们的交互。
(图1:用例图)3. 用例描述- 查看个人信息:员工可以查看自己的个人信息,包括个人资料、联系方式和工作历史。
- 修改个人信息:员工可以修改自己的个人信息,如联系方式和地址等。
- 管理员登陆:管理员可以使用管理员账号登陆系统。
- 管理员工信息:管理员可以查看和修改员工信息,包括添加员工、删除员工和修改员工信息等。
- 薪资管理:人事部门可以查看和修改员工薪资信息。
- 请假管理:人事部门可以管理员工的请假信息,包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
(图2:状态图)5. 类图类图展示了系统中的类以及它们之间的关联。
(图3:类图)三、系统分析1. 需求分析对于查看个人信息的用例,系统应该提供一个界面给员工输入自己的员工号,然后显示员工的个人信息。
对于修改个人信息的用例,系统应该提供一个界面给员工输入员工号和想修改的信息,然后保存修改后的信息。
对于管理员登陆的用例,系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例,系统应该提供一个界面给管理员查看和修改员工信息,包括添加、删除和修改员工信息。
对于薪资管理的用例,系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例,系统应该提供一个界面给人事部门管理员工的请假信息,包括请假申请和批准。
2. 非功能性需求- 界面友好:系统应该提供直观、易用的界面来满足用户的需求。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
2.2 列出初始名词清单
• 大学 学生注册系统 系统 学生 所有学生 学位 学习计划 课程计划 导师 教授 成绩单 完成课程 成绩 课程 预修课程 所需要的课程 班级 等待的班级 选修的课程班级、所选课程班级 所注册的课程班级 听课位置 听课时间 学期 邮件 等待列表
(2)利用领域知识,确定候选类可能的描述属性; 如大学中每个学生都有学生编号,姓名,专业等信息,这些就可以作为描述属性添加到学生类中;
(3)查看相似信息在现有老信息系统或者人工系统中的表示形式,确定候选类应该具有的描述属性;
(4)另外在后续分析类与类之间关系时,也可能会考虑添加候选类的描述属性。
4 数据字典的生成
选择的动词短语:
(1)我们被要求为大学开发一个自动化的学生注册系统(SRS) (2)学生…注册…课程班级 (3)跟踪学生的学习进展 (4)学生被大学录取 (5)学生建立学习计划 (6)学生..选择一名导师 (7)检验…学习计划是否满足…学位要求
2.3 候选类确定
• 1)删除和本系统关联不大的名词或者指代本系统的名词
• 2)删除重复项、删除单数术语的复数形式。
• 3)将明显的同义词分组,在同义词中选择一个最为合适 的作为候选类名
• 4)有些候选名词是暗示对象之间角色的名词,要将角色 名称删除
• 5)删除反映其它类对象属性的名词
大学 学生注册系统 系统 学生 所有学生 学位 学习计划 课程计划 教授 导师 成绩单 完成课程 成绩 课程 预修课程 所需要的课程 班级 等待的班级 选修的课程班级 所选课程班级
UML的用例模型一直被推荐为识别和捕获 需求的首选工具!!
2. 构建用例模型的三个步骤
• (1)确定系统参与的演员; • (2)根据系统需要实现的具体功能,确定系统各种用例; • (3)确定演员和用例之间的交互关系。
3.确定用例的参与演员
演员指代在系统建成后与系统交互的任何人或任何物,演员驱 动用例。演员一般包含两类: (1) 用户(人)
分别为学生、学习计划、成绩单、教授、课程、班级; • (3)运用描述属性确定方法确定了6个候选类的描述属性
• (4)定义了包含候选类及其属性描述的SRS数据字典。
参考文献:
• [1] 许家珆. 软件工程——方法与实践(第二版).北京:电子工业出版社.
• [2] Jacquie Barker著.韩柯等译.Java 面向对象编程指南.电子工业出版社.
(2)其他计算机系统
3.1 SRS系统参与演员分析
用户(人)
学生 教授 管理人员 校友 准大学学生
其他计算机系统
教务系统 教室安排系统 收费系统
分析原则: 合理的界定系统范围,避免出现”需求膨胀”或者”范围萎缩”。
确定最终参与演员: 学生 教授 管理人员
4.1 SRS系统用例确定
用例是演员和系统的一次典型交互,一般被定义为系统执行的一系列动作或功能。
候选类
学生 学习计划 教授 课程
班级
成绩单
候选类描述
被大学录取的学习主体对象。
属性
学生编号、姓名、专业、学位…
学生为得到特定学位所要完成的必修课程清单。
计划编号、计划制定时间…
为班级授课或指导学生的教职工
老师编号、姓名、职称…
一个学期长的一系列授课、作业、考试等,与特定专题领域 课程编号、课程名称、课程学分.. 有关,与一定学时数、学分相关联,是获得学位的一个单位。
配置视图
UML常用视图
Implementation
View 表示系统的 实现特征,常用 构件图表示。
Process View 表示系统内部 的控制机制。常用类图描述 过程结构,用交互图描述过 程行为。
Deployment View 配置视 图描述系统的物理配置特 征。用配置图表示。
图(Diagrams)
在特定学期每星期特定日期的特定时间提供的特定课程(如 班级编号、学期、听课位置、听课时 课程”面向对象程序设计方法学”,班级:2015年秋季每周四 间、听课人数… 上午的讲授)
特定学生选修学习的所有课程的记录,包含具体参加的班级 总成绩、总学分… 信息、课程成绩、获得的学分。
总结:
• (1)搜索收集了需求文档中的名词和名词短语,列出初始名词或名词短语26项 • (2)运用候选类筛选原则,确定SRS系统的合适候选类共6个:
交
互 关
使用信息 (以读方式启动用例)
系
不可用 (不能启动用例)
6 建立用例图
SRS系统静态建模
——标识候选类及其属性
1、系统静态建模需要完成的任务
1.分析系统问题域,确定和标识系统需要定义的类; 2. 定义类对象的属性和操作; 3. 建立系统中类对象之间的结构关系。
2、标识适当的类
• 标识类的过程相当“模糊”,很大程度上依赖直觉、以前的建模 经验以及对要开发系统领域的了解程度。
基于UML的面向对象软件开发方法案例分析 UML是一种标准化的图形建模语言,它是面向对象分析与设 计的一种标准表示。
参考文—方法与实践(第二版).北京:电子工业出版社.
• [2] Jacquie Barker著.韩柯等译.Java 面向对象编程指南.电子工业出版社.
所注册的课程班级 听课位置 听课时间 学期 邮件 等待列表
确定候选类: 学生、学习计划、成绩单、教授、课程、班级
3. 标识类属性
确定候选类的描述属性的相关方法:
(1)在候选类筛选过程中,有些名词或名词短语已经确定为描述属性,如“学位”为学生的描述属性、 “听课位置”、听课时间、学期是班级类的描述属性;
假设:(a) 所要求的预修课程已经满足; (b)课程满足该学生学习计划要求之一; (c) 课程班级尚有空位,则学生可以参加听课。
如果上述三个条件满足,则系统将确认注册课程班级成功。
取消注册课程用例
学生在线查看课程计划,选择要选修的课程班级后,SRS系统同样检查上述三个条件: 如果(a)(b)条件可以满课程足,但是(c)不能满足,则该学生要放到一个先来先服务等待列表中。 如果学生以前所等待的班级可以提供(或者由于某个学生取消所注册的课程班级,或者课程的听课位置增加了),则该学生会被自动录 取到所等待的班级中,并向该学生发送一个邮件。 该学生如果不再对这个课程感兴趣,可以自行决定取消,否则学生要为该课程付费。
主要步骤:
(1)登录到SRS系统 (2)查看本学期开发的班级计划信息 (3)选择合适班级,提交注册需求,等待系统应答。 (4)系统检查保证所请求的课程对于他的整个学位目标是合适的。
(5) 系统检查该学生成绩单,确保该学生满足所请求课程的预修课程要求 (6)确认所注册班级是否还有空余位置。 (7)该班级加入到该学生当前选修课程表中 (8)系统给予注册成功与否的应答信息
2.2 动词短语分析法举例
我们被要求为大学开发一个自动化的学生注册系统(SRS)。这个系统可使学生在线注册每个 学期的课程班级,也可以用于跟踪学生的学习进展,直到其获得学位。
当学生被大学录取后,所有学生在SRS上建立学习计划,即确定满足特定学位程序所需要 的课程,并选择一名导师。SRS要检验所提出的学习计划是否满足该学生所希望获得学位的 要求。
• 初次建模,常使用“搜索收集”方法: 在项目的所有文档中搜索收集所有名词或名词短语,构成一个清 单,并按照一定原则不断筛选、消减这个清单,最终确定一组合 适的候选类,形成系统数据字典。
2.1 SRS系统主要用例需求描述
注册课程班级用例
我们被要求为大学开发一个自动化的学生注册系统(SRS)。这个系统可使学生在线注册每个学期的课程班级, 也可以用于跟踪学生的学习进展,直到其获得学位。
学生
提供信息 提供信息 不可用 提供信息 提供信息 使用信息 使用信息 使用信息 不可用 不可用
教授
提供信息 不可用 提供信息 不可用 不可用 使用信息 使用信息 使用信息 提供信息 不可用
管理人员
提供信息 不可用 不可用 不可用 不可用 使用信息 使用信息 使用信息 不可用 提供信息
提供信息 (以写方式启动用例)
假设:(a) 所要求的预修课程已经满足; (b)课程满足该学生学习计划要求之一; (c) 课程班级尚有空位,则学生可以参加听课。
如果上述三个条件满足,则系统将确认注册课程班级成功。
4.2 用例描述——用例模板描述
用例名:注册课程班级
执行者:学生
功能描述:
每个学期开始,学生登录到SRS系统后能按照学习计划的安排,查看本学期相关课程开设的相关班级,并进行注册, 方便后续课程学习的顺利进行。
图
UML语言定义了五种类型,9种不同的图,把它们 有机的结合起来就可以描述系统的所有视图。
用例图(Use case diagram) 从用户角度描述系统功 能,并指出各功能的操作者。
静态图(Static diagram),表示系统的静态结构。包 括类图、对象图、包图。
行为图(Behavior diagram),描述系统的动态模型 和组成对象间的交互关系。包括状态图、活动图。
相关用例:
系统登录 建立学习计划 查询授课班级信息
5 建立用例和演员之间的关系
• 利用演员和用例的交叉引用表,来描述用例和演员之间的关系:
启动演员
用例 • 系统登录 • 建立学习计划 • 审核学习计划 • 注册课程班级 • 取消注册课程 • 查询授课班级信息 • 查询学生信息 • 查询学生成绩单 • 公布课程成绩 • 维护后台基础数据
• 系统登录 • 建立学习计划 • 审核学习计划 • 注册课程班级 • 取消注册课程 • 查询授课班级信息 • 查询学生信息 • 查询学生成绩单 • 公布课程成绩 • 维护后台基础数据
4.2 用例描述——自然语言描述
注册课程班级用例