数据库系统UML建模案例演示
- 格式:ppt
- 大小:670.50 KB
- 文档页数:30
信息系统集成技术及应用题目:UML系统分析设计、建模与实现学号:100430112022姓名:杨家建专业:计算机技术指导教师:舒远仲UM L系统分析设计与建模以简单的学生选课系统进行详细的系统分析与建模。
(一)系统用例图1•首先根据需求分析可知:管理员维护课程信息,对其进行添加、修改、删除等。
学生可以在线查询课程信息,并进行选课,也可以在规定时间内更改选修 的课程。
我们发现系统中的参与者有:管理员和学生,然后从参与者的角度就可 以发现系统的用例,并绘制出系统的用例图,如图 1所示:图1学生选课系统用例图2.对部分用例进行描述:“添加课程”用例1) 用例名:添加课程2) 执行者:管理员3) 目的:管理员通过系统界面进入,添加所要开设的课程,确认无误后将其信息保 存到数据库中,以供学生选择。
4)过程描述:5) 管理员选择进入管理界面,用例开设修改课程停开课程A —管理员vvinclude>><<include>>添加课程vvinclude>><<extend>>删除课程查询课程信息6)系统提示输入管理密码7)管理员输入密码8)系统验证密码9)A1:密码错误10)进入管理界面,系统显示目前所建立的全部课程信息11)管理员选择添加课程12)系统提示输入新课程信息13)管理员输入信息14)系统验证是否和已有的课程冲突15)A2 :有冲突16)10 )系统添加新课程,提示课程添加成功17)11 )系统重新进入管理界面,显示所有课程18 )12 )用例结束19 )异常事件流处理:20 )A1 :密码错误:1)系统提示再次输入。
2)用户确认后进入第5)步。
21 )A2 :有冲突:1)系统提示冲突,显示冲突的课程信息。
2)用户重新输入,验证无误后进入第10 )步。
选课”用例1)用例名:选课2)执行者:学生3)目的:学生进入选课系统界面,浏览的课程,最后选择一门自己喜欢的课程并提交。
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率,决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作,包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工:具有查看和修改个人信息的权限。
- 人事部门:负责对员工信息进行管理、薪资管理和请假管理。
- 管理员:拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图,包括主要的参与者和他们的交互。
(图1:用例图)3. 用例描述- 查看个人信息:员工可以查看自己的个人信息,包括个人资料、联系方式和工作历史。
- 修改个人信息:员工可以修改自己的个人信息,如联系方式和地址等。
- 管理员登陆:管理员可以使用管理员账号登陆系统。
- 管理员工信息:管理员可以查看和修改员工信息,包括添加员工、删除员工和修改员工信息等。
- 薪资管理:人事部门可以查看和修改员工薪资信息。
- 请假管理:人事部门可以管理员工的请假信息,包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
(图2:状态图)5. 类图类图展示了系统中的类以及它们之间的关联。
(图3:类图)三、系统分析1. 需求分析对于查看个人信息的用例,系统应该提供一个界面给员工输入自己的员工号,然后显示员工的个人信息。
对于修改个人信息的用例,系统应该提供一个界面给员工输入员工号和想修改的信息,然后保存修改后的信息。
对于管理员登陆的用例,系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例,系统应该提供一个界面给管理员查看和修改员工信息,包括添加、删除和修改员工信息。
对于薪资管理的用例,系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例,系统应该提供一个界面给人事部门管理员工的请假信息,包括请假申请和批准。
2. 非功能性需求- 界面友好:系统应该提供直观、易用的界面来满足用户的需求。
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建模 - ATM取款机软件建模(UML)作业班级:计算机0806班学号:20213007 姓名:姜俊方UML个人作业一、ATM机需求分析图ATM自动取款读卡机模块键盘输入模块认证模块显示模块打印报表报表吐钱机模块 IC监视器模块二、用例图用于描述一组用例、参与者及它们之间的连接关系。
用例图仅仅从角色使用系统的角度描述系统中的信息,也是站在系统外部查看系统功能,而并不描述该功能在系统内部是如何实现的。
用例图是被称为参与者的外部用户所能观察到的系统功能的模型图。
用例可应用于整个系统,也可应用于系统的一部分,包括子系统、单个的类甚至接口。
通常,用例不仅代表这些元素所期望的行为,而且还可把这些元素用作开发过程中测试用例的基础。
椭圆:用例,是用户与计算机之间的一次典型交互作用。
人形:参与者(外部执行者)是指用户在系统中所扮演的角色。
ATM系统的用例图存钱银行工作人员添加信息取钱客户修改密码维护硬件设备转账查询余额付款银行工作人员ATM提款系统用例图存款查余额用户付款信用取款验证用户更改密码三、类图用于描述一组类、接口、协作及它们间的静态关系。
在面向对象系统的建模中,类图最为常用,它用来阐明系统的静态结构。
类是对一组具有相同属性、操作、关系和语义的对象的描述,其中对类的属性和操作进行描述时的一个最重要的细节是它的可见性。
一个典型的系统模型中通常有若干个类图。
一个类图不一定要包含系统中所有的类,一个类可加到几个类图中。
在类图中类用矩形框来表示,它的属性和操作分别列在分格中。
类之间可以多种方式链接(如关联、泛化、依赖和实现等)。
关系用类框之间的连线来表示,不同的关系用连线上和连线端头处的修饰符来区别。
类图账户ATM屏幕ATM键盘ATM读卡器吐钱机数据库ATM系统类图四、顺序图(序列图)顺序图表示对象之间传送消息的时间顺序。
顺序图用来描述对象之间消息发送的先后次序,阐明对象之间的交互过程以及在系统执行过程中的某一具体时刻将会发生什么事件。
案例:酒店预订系统一、需求分析酒店订餐管理系统是中小型酒店餐饮企业用来对客人的订餐活动进行管理的信息管理系统(MIS)。
该信息系统不仅能够为客人提供方便的订餐功能,同时也能够达到提高酒店餐饮企业管理效率的目的。
订餐系统的功能性需求包括以下内容:(1)酒店的接待员使用电话为客人提供订餐服务,根据客人的订餐要求,在指定的时间和桌位安排好客人的就餐事宜;按客人的要求执行修改订单的操作;在客人临时取消预订时删除订餐信息;在客人订餐时间到达前,及时提供电话提醒服务。
(2)酒店领班在订餐客人到店用餐时和用餐离店后分别在系统做好记录并保存;能够为客人注册成为会员;可以查询、修改和删除会员信息;可以为客人提供换桌服务。
二、创建系统用例模型接待员用例能够通过该系统进行如下活动:(1)记录订餐信息。
接待员将客人的订餐要求输入到系统中予以保存。
(2)订餐定时提醒。
接待员在客人的预定的订餐时间之前给客人一个提醒,同时再次加以确认。
(3)取消订餐记录。
客人因临时原因取消订餐,接待员将系统中原来的订餐信息予以取消。
领班用例能够通过该系统进行如下活动:(1)记录订餐客人到店。
领班在有预订的客人前来酒店就餐时,在系统中记录预订客人已到店的信息并保存。
(2)记录订餐客人离店。
领班在预订的客人用餐离店后,在系统中记录预订客人用餐完毕的信息并保存,表示整个订餐过程结束。
(3)注册新会员。
领班在用餐客人同意加入成为本酒店会员时,有为客人注册成为新会员的权力。
(4)修改会员信息。
领班有权对酒店会员信息进行修改。
(5)删除会员信息。
当客人不再要保留会员资格时,领班将该会员的信息从系统中删除。
(6)换桌服务。
当客人对就餐位置不满意时,领班可为客人提供更换餐位的服务并在系统中做好记录。
三、创建系统静态模型根据系统需求,创建静态系统类图。
我们可以识别系统中存在的主要实体类:接待员类(Receptionist)、领班类(Captain)、客人类(Customer)和会员类(Member)。