UML建模设计样例
- 格式:doc
- 大小:455.00 KB
- 文档页数:14
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率,决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作,包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工:具有查看和修改个人信息的权限。
- 人事部门:负责对员工信息进行管理、薪资管理和请假管理。
- 管理员:拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图,包括主要的参与者和他们的交互。
(图1:用例图)3. 用例描述- 查看个人信息:员工可以查看自己的个人信息,包括个人资料、联系方式和工作历史。
- 修改个人信息:员工可以修改自己的个人信息,如联系方式和地址等。
- 管理员登陆:管理员可以使用管理员账号登陆系统。
- 管理员工信息:管理员可以查看和修改员工信息,包括添加员工、删除员工和修改员工信息等。
- 薪资管理:人事部门可以查看和修改员工薪资信息。
- 请假管理:人事部门可以管理员工的请假信息,包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
(图2:状态图)5. 类图类图展示了系统中的类以及它们之间的关联。
(图3:类图)三、系统分析1. 需求分析对于查看个人信息的用例,系统应该提供一个界面给员工输入自己的员工号,然后显示员工的个人信息。
对于修改个人信息的用例,系统应该提供一个界面给员工输入员工号和想修改的信息,然后保存修改后的信息。
对于管理员登陆的用例,系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例,系统应该提供一个界面给管理员查看和修改员工信息,包括添加、删除和修改员工信息。
对于薪资管理的用例,系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例,系统应该提供一个界面给人事部门管理员工的请假信息,包括请假申请和批准。
2. 非功能性需求- 界面友好:系统应该提供直观、易用的界面来满足用户的需求。
案例:酒店预订系统一、需求分析酒店订餐管理系统是中小型酒店餐饮企业用来对客人的订餐活动进行管理的信息管理系统(MIS)。
该信息系统不仅能够为客人提供方便的订餐功能,同时也能够达到提高酒店餐饮企业管理效率的目的。
订餐系统的功能性需求包括以下内容:(1)酒店的接待员使用电话为客人提供订餐服务,根据客人的订餐要求,在指定的时间和桌位安排好客人的就餐事宜;按客人的要求执行修改订单的操作;在客人临时取消预订时删除订餐信息;在客人订餐时间到达前,及时提供电话提醒服务。
(2)酒店领班在订餐客人到店用餐时和用餐离店后分别在系统做好记录并保存;能够为客人注册成为会员;可以查询、修改和删除会员信息;可以为客人提供换桌服务。
二、创建系统用例模型接待员用例能够通过该系统进行如下活动:(1)记录订餐信息。
接待员将客人的订餐要求输入到系统中予以保存。
(2)订餐定时提醒。
接待员在客人的预定的订餐时间之前给客人一个提醒,同时再次加以确认。
(3)取消订餐记录。
客人因临时原因取消订餐,接待员将系统中原来的订餐信息予以取消。
领班用例能够通过该系统进行如下活动:(1)记录订餐客人到店。
领班在有预订的客人前来酒店就餐时,在系统中记录预订客人已到店的信息并保存。
(2)记录订餐客人离店。
领班在预订的客人用餐离店后,在系统中记录预订客人用餐完毕的信息并保存,表示整个订餐过程结束。
(3)注册新会员。
领班在用餐客人同意加入成为本酒店会员时,有为客人注册成为新会员的权力。
(4)修改会员信息。
领班有权对酒店会员信息进行修改。
(5)删除会员信息。
当客人不再要保留会员资格时,领班将该会员的信息从系统中删除。
(6)换桌服务。
当客人对就餐位置不满意时,领班可为客人提供更换餐位的服务并在系统中做好记录。
三、创建系统静态模型根据系统需求,创建静态系统类图。
我们可以识别系统中存在的主要实体类:接待员类(Receptionist)、领班类(Captain)、客人类(Customer)和会员类(Member)。
实验报告规实 验 报 告姓 名 学 号 班 级 成 绩实验名称 超市进销存管理系统的UML建模 实验日期一.实验容基于OO设计与分析方法,用统模语言UML完成一个超市进销存管理系统要求:软件系统模型包括8种建模图,其中至少包含三个主要用例的用例脚本描述、顺序图、活动图和两个有较复杂行为的类的实例状态图。
二.需求分析文档描述超市进销存管理系统要求能对超市的进、销、存行为进行管理,并且能根据不同权限的系统用户的需求进行报表的生成和查询,为超市管理者的决策提供协助。
当库存和在架商品数量低于临界值时,能发出警报,提醒库存管理人员。
当销售人员售出商品时,记录的在架商品的数量能相应的减少出售数量。
能进行人员的日常管理。
三.设计方法、思路和主要技术设计方法、思路:根据系统需要实现的功能,我将系统划分成五个子系统,分别是销售部、进货部、库存部、会计部、经理室。
分别用于实现商品的销售,商品的进货,商品的库存,金钱和报表,人事和决策的管理。
主要技术:UML四.软件系统建模(包括完整建模图) (一)系统用例图(1)企业级用例图(2)系统级用例图(3)销售部用例图(4)进货部用例图用例生成定单”的描述用例名称 生成定单标识符 SP0001用例描述 当进货员收到经理发出的定货单,联系供货商,谈好价格,报经理审核后,生成定单,用例结束。
参预者进货员 经理 供货商优先级 1状态 未审核前置条件 定货员收到经理发出的定货单后置条件 定货基本操作流程 进货员根据定货表选择多家供货商联系,谈好价格,将多家供货商的价格报经理审核,由经理选择供货商,然后进货员生成定单。
可选操作流程 进货员根据定货表先选择一家供货商联系,谈好价格,将价格报经理审核,审核通过,生成定单,不通过再联系下一家供货商。
被泛化的用例 无被包含的用例 无被扩展的用例 无(5)库存部用例图用例货物上架”描述用例名称 货物上架标识符 SP0003用例描述 当在架商品数量低于最小临界值,库存员收到警报,将库存货物摆上货架,用例结束。
1系统软件重构分析关于系统重构,我认为应该从以下几个方面进行考虑:首先,考虑能否优化数据库。
可能因为系统使用的时间过长,导致数据库的性能开始下降,搜索反映时间增加等等一系列的问题,此时的后台数据库应该考虑是不是要重新做下修改,比如创建新的索引,存储过程,作业,触发器等等,最坏的情况应该是考虑重新建库。
其次,软件在编写的时候,用的编程语言可能较现在已经很落后,无论是软件的性能还是安全性等方面已经出现了不可忽视的问题。
很显然,当时编程用的语言已经严重影响了软件的正常工作,成为了软件工作的瓶颈。
在不影响软件正常功能的情况下,考虑用其他的语言重新编写软件应该是值得考虑的。
最后,随着社会的变化,软件当时具备的功能可能已不能满足现今的需要,在原有功能的基础上扩展软件的功能应该也是软件重构应该考虑的一个方面。
2系统模块时序图2.1 managestatute(管理法规)模块时序图2.1.1createnewstatuteSD(增加新法规)时序图2.1.1 createnewstatuteSD(增加新法规时序图)步骤:1管理员打开管理法规界面4点击创建新法规5显示在法规界面上,用于输入新法规信息6设置新法规信息7处理新输入法规信息8将新法规写入到新增法规表里9保存新增的法规成功10用户退出2.1.2 modifystatuteSD(修改法规)时序图2.1.2modifystatuteSD(增加法规时序图)步骤:1管理员打开管理法规界面4 用户选择执行删除或修改操作5显示法规界面,用于用户选择执行删除或修改的记录6到法规表里选出法规记录7返回该记录到法规界面8用户选择相应的法规进行修改或删除处理9将执行的操作写入数据库并保存10用户退出2.1.3 querystatuteSD(查询法规)时序图2.1.3 querystatuteSD(查询法规时序图)步骤:1管理员打开管理法规界面4用户选择查询操作5显示法规界面6到数据库中的法规表中选择法规记录7返回该记录到法规界面让用户进行查看8用户退出2.2 manageinspectionplan模块(管理检查计划)时序图2.2.1 createnewplanSD(创建新的检查计划)时序图2.2.1 createnewplanSD(创建新检查计划时序图)步骤:1管理员或检查员打开管理检查计划界面4用户点击创建新的检查计划5显示检查计划界面,用于用户输入检查计划的信息6设置检查计划信息7验证输入的信息是否符合要求8点击新增按钮9将新增的计划写入数据库,保存检查计划10用户退出2.2.2 modifyplanSD(修改检查计划)时序图2.2.2 modifyplanSD(修改检查计划时序图)步骤:1用户登陆打开管理检查计划界面4进入管理检查计划界面修改或删除检查计划5显示检查任务界面,用于显示法规信息6到数据库中检查计划表中选择出检查计划记录7返回记录信息到检查计划界面8用户对记录进行修改9保存对检查计划的操作,并写入数据库10用户退出2.2.3 queryplanSD(查询检查计划)时序图2.2.3 queryplanSD(查询检查计划时序图)步骤:1管理员打开管理检查计划界面4用户选择查询操作5显示法规界面,该界面用于显示检查计划的记录6到数据库中的检查计划表中选择检查计划记录7返回该记录到检查计划界面让用户进行查看8用户退出8用户退出2.3 managecheckrecord模块(管理检查记录)时序图2.3.1 querycheckrecordSD(查询检查记录)时序图2.3.1 querycheckrecordSD(查询检查记录时序图)步骤:1管理员打开管理检查记录界面4用户选择查询操作5显示检查记录界面6用户在检查记录界面上输入检查条件按确定7到数据库中的检查记录表中选择记录8返回该记录到检查记录界面让用户进行查看9用户退出3系统模块活动图3.1 managelawAD(管理法规)活动图3.1.1 managecreatenewstatuteAD(创建新的法规)活动图3.1.1 managecreatenewstatuteAD(创建新的法规活动图)说明:用户首先输入用户名和密码登录系统,若验证失败,重新登录。
uml建模案例UML(Unified Modeling Language)是一种软件工程的建模语言,用于描述、分析和设计软件系统。
它提供了一套图形化的表示法,用于可视化和概括软件系统的各个方面,包括结构、行为和交互等。
以下是一个简单的 UML 建模案例,以一个图书馆管理系统为例:首先,我们需要定义系统的主要角色。
在这个案例中,主要角色有图书馆管理员、读者和图书。
接下来,我们可以开始构建类图,用于描述系统中的类及其之间的关系。
我们可以创建以下类:1. 图书类(Book):包含图书的相关信息,如书名、作者、出版社等。
2. 读者类(Reader):包含读者的相关信息,如姓名、年龄、地址等。
3. 图书馆管理员类(Librarian):包含管理员的相关信息,如姓名、工号等。
该类可以包含一些操作,例如借书、还书等。
4. 图书管理系统类(LibraryManagementSystem):负责管理图书、读者和管理员。
该类可以包含一些操作,如添加图书、删除图书、注册读者、借书、还书等。
接下来,我们可以定义类之间的关系。
在这个案例中,可以定义如下关系:1. 图书与读者之间的关系:读者可以借阅图书,每位读者可以借阅多本图书,而每本图书只能被一个读者借阅。
2. 图书与图书馆管理员之间的关系:管理员可以管理图书,例如添加图书、删除图书等操作。
3. 读者与图书馆管理员之间的关系:管理员可以注册读者,读者可以向管理员借书、还书。
最后,我们可以根据需求进一步细化类的行为和交互。
例如,根据借书和还书的需求,可以设计用例图,描述用户与系统之间的交互流程。
在用例图中,我们可以定义以下用例:1. 注册读者:读者通过系统界面提供个人信息进行注册。
2. 添加图书:管理员通过系统界面提供图书信息进行添加。
3. 借书:读者通过系统界面搜索图书并进行借书操作。
4. 还书:读者通过系统界面搜索已借阅的图书并进行还书操作。
以上仅为一个简单的UML 建模案例,实际情况可能更为复杂,涉及更多的类和关系。
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业务建模实例分析在我国十年前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建模案例——我的一位朋友结婚了案例:我的一位朋友结婚了1、引入案例这是人们日常生活中一件很普通的事情,但这只是事情的结果,这其中隐藏着很多活动和过程。
这就需要经过有效地分析和设计过程来描述,可以从不同的角度进行探讨。
A. 这里面有什么东西?要分析问题,首先就是要找到问题中所包含的事物。
在本案例中,可能存在月老、小伙、姑娘、恋人、玫瑰花等各种人、物或者事件。
B. 每个东西看上去是什么样的?找到这些事物后,下一步就要分析每个事物的特征,以认识和理解事物本质。
在本案例中,每个事物可能的特征有:月老一一看上去有些年纪了、挺热心;小伙一一看上去很强壮、很诚实;姑娘——看上去很漂亮,还很温柔;恋人一一看上去很黏糊,最终结婚了;玫瑰花——火红火红的,难怪姑娘动情了。
C. 每个东西能做什么?认识了这些事物后,下面就要分析这些事物的能力,以完成特定的事情。
在本案例中,每个事物的能力有:月老一一牵线搭桥,介绍两人认识;小伙一一追求献花,表达爱意;姑娘一一仰慕倾情,以身相许;恋人一一拍拖,结婚;玫瑰花一一令姑娘心动,传情示爱。
D. 这些东西都呆在什么地方?分析完这些事物本身的特征和能力之后,下面就要安排这些事物出场,为此首先需要定义每个事物所处的位置。
在本案例中,比如:月老可能在婚介所或交友网站;小伙可能在软件园工作;姑娘可能在医院工作;恋人可能出现在电影院;玫瑰花可以在花店,也可以在小伙或姑娘手中。
E. 这些东西之间有什么关系?安排好所有事物后,为了能够有效地完成事情,还需要分析它们彼此之间的关系,以便彼此合作。
在本案例中,可能的关系如表1-1所示。
F. 这些东西是怎么完成整个事情的?最后就是我们的重头戏,要利用前面的那些事物以及事物之间的关系,完成整件事情。
完成这个案例的过程如下所示:(1)月老牵线搭桥,介绍小伙和姑娘认识。
(2)姑娘和小伙一见钟情,成为一对恋人。
(3)一对恋人开始拍拖。
(4)小伙用献花表达对姑娘的爱意。
目录1.系统软件重构分析 (2)2.系统模块时序图 (2)2.1 managestatute模块 (2)2.1.1 managestatuteSD.createstatute (2)2.1.2 managestatuteSD.modifystatute (3)2.1.3 managestatuteSD.querystatute (4)2.2 manageinspectionplan模块 (5)2.2.1 manageinspection.creat (6)2.2.2 manageinspection.modify (6)2.2.3 manageinspection.query (7)2.3 managecheckrecord模块 (8)2.3.1 managecheckrecord (9)3.系统模块活动图 (10)3.1 managestatute模块 (10)3.2 manageinspectionplan模块 (11)3.3 managecheckrecord模块 (11)4. 系统模块状态图 (12)4.1 enterprisecheckedstatechart(GMP) (12)4.2 statutestatechart (13)5. 整体系统部署图 (14)5.1 deployment diagram (14)6.系统软件重构建模总结 (20)1.系统软件重构分析本系统用于药店、药品检查评定工程,采用的C/S即客户端/服务器端的架构方式,系统软件后台数据管理易学好用,可维护性强,对系统性能要求较低。
本系统有三类用户,即管理员、检查员和统计员。
系统要实现用户管理模块、系统管理模块、检查准备模块、检查执行模块和检查统计模块等功能。
管理员通过对用户信息进行增、删、查、改操作进行用户信息管理。
对受检单位进行设置,对法规、法规条例和监管单位等信息进行增加、删除、修改等操作。
浏览GMP认证检查评定标准和GSP认证检查评定标准,按照这些标准对受检单位进行检查.安排检查任务、修订之前已保存的检查任务,选取检查任务和复检任务进行执行。
公司经理银行税务局客户企业员工财务管理进销存管理行政事务管理生产调度管理生产设备管理人力资源管理<<依赖>><<依赖>><<依赖>><<依赖>>见第三章 企业综合信息管理系统最高层用例图销售管理库存管理采购管理<<依赖>><<依赖>>财务管理子系统公司经理生产调度管理子系统企业员工客户见第三章 的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、系统功能需求分析(1) 读者管理:读者信息的制定、输入、修改、查询,包括种类、性别、借书数量、借书期限、备注等。
(2) 书籍管理:书籍基本信息制定、输入、修改、查询,包括书籍编号、类别、关键词、备注。
(3) 借阅管理:包括借书,还书,预订书籍,续借,查询书籍,过期处理和书籍丢失后的处理。
(4)系统管理:包括用户权限管理,数据管理和自动借还书机的管理满足以上需求的系统主要包含有一下几个子系统(1)基本业务功能子系统:该系统中主要包含了借书还书和预订等功能。
(2)基本数据录入功能子系统:该子系统主要包含有书籍信息和读者信息录入功能。
(3)信息查询子系统:包含了多功能的查询书籍信息和读者信息。
(4)数据库管理功能子系统:主要包含了借阅信息管理功能,书籍信息管理功能和预订信息管理功能。
(5)帮助功能子系统。
下图为该图书馆管理系统的主要功能模块图:页脚图1:图书馆管理系统功能模块图3、功能描述(1)借书。
处理借书业务。
(2)还书。
处理还书业务。
(3)书籍预订。
借阅者可以通过网络进行书籍预订。
(4)书籍信息录入。
处理书籍个类信息录入业务。
(5)借阅者信息录入。
对读者信息进行录入。
(6)书籍信息查询。
负责书籍信息的查询。
(7)读者信息查询。
负责数据信息的查询。
(8)借阅信息管理。
书籍借阅信息包括所借书的书名、ISBN以及借书的时间等。
(9)书籍信息管理。
书籍信息包括书籍的名字、ISBN、作者、入库时间以及书籍在相应书目下的编号等。
(10)预订信息管理。
负责管理书籍预订信息。
4、图书馆管理系统的数据流图。
如下:图2:图书馆管理系统的DFD图1、UML简介UML是一种功能强大的、面向对象的可视化系统分析的建模语言,它采用一整套成熟的建模技术,广泛地适用于各个应用领域。
它的各个模型可以帮助开发人员更好地理解业务流程,建立更可靠、更完善的系统模型。
从而使用户和开发人员对问题的描述达到相同的理解,以减少语义差异,保障分析的正确性.2、该图书馆管理系统的用例分析该图书馆管理系统的用例图如下:页脚图3:图书馆管理系统的用例图从用例图中我们可以看出管理员和读者之间对本系统所具有的用例。
管理员所包含的用例有:(1)登录系统:管理员可以通过登录该系统进行各项功能的操作(2)书籍管理:包括对书籍的增删改等。
(3)书籍借阅管理:包括借书、还书、预订、书籍逾期处理和书籍丢失处理等等。
(4)读者管理:包含对读者的增删改等操作。
(5)自动借书机的管理。
12读者所包含的用例有:(1)登录系统(2)借书:进行借书业务。
(3)还书:读者具有的还书业务。
(4)查询:包含对个人信息和书籍信息的查询业务(5)预订:读者对书籍的预订业务。
(6)逾期处理:就是书籍过期后的缴纳罚金等。
(7)书籍丢失处理:对书籍丢失后的不同措施进行处理。
(8)自动借书机的使用等。
3、系统的顺序图顺序图是显示对象之间交互的图,这些对象是按时间顺序排列的。
该图书馆管理系统主要含有以下几个重要的顺序图,其他对象的顺序图和这些也类似。
(1)借书顺序图(2)还书顺序图(3)罚款顺序图1、借书顺序图图4:图书馆管理系统借书顺序图【顺序图说明】(1)login():登录系统。
(2)checkstu_card():对读者信息进行验证,检查是否符合本图书馆借书条件。
(3)showinformation():显示该读者的基本信息函数。
(4)borrow():读者借书函数。
(5)getreaders():取得读者信息函数。
看该读者是否符合借书条件,若符合,则页脚返回可借信息。
(6)gettitle():取得书目信息。
(7)getreservation():检验书籍是否被预订函数。
(8)getnoreservation():书籍没被预订或取消预订函数。
(9)create(borrower,item):创建书籍外借函数。
借书时,读者先将书拿予管理员,管理员对书籍和读者进行检验,若书籍和读者都符合借书条件,则借书成功。
2、还书顺序图图5:图书馆管理系统还书顺序图【顺序图说明】(1)login():登录系统。
(2)getitem():取得书籍条目信息。
(3)update():对图书馆书籍条目和借阅者信息进行更新条目。
还书时,读者先将书交给管理员,由管理员扫描书籍,若书籍没有过期等违规现象,则对书目和读者借阅信息进行更新,同时还书成功。
3、罚款顺序图12页脚图6:图书馆管理系统的罚款顺序图【顺序图说明】管理员对书籍进行扫描,若发现书籍已经超过了图书馆规定的还书期限,则按每天一定金额进行罚款,过期天数和罚款金额由系统自动计算。
用户交完罚金后,则对读者借阅信息进行更新。
4、系统的状态图图书馆的书籍状态图如图7所示。
【状态图说明】书籍在未变成图书馆在库书籍时,为新加书籍状态。
书籍处于在库状态时既可以预订也可以外借,外借后变为借出状态。
处于预订状态时也可以外借,超出预订时间期限则从预订状态直接转为可用状态。
借阅者在规定的预订时间也可以考虑取消预订,取消预订后书籍的状态转为可用。
外借书籍归还后变为可用状态。
图7:图书馆的书籍状态图5、系统的活动图活动图描述的是某流程中的任务的执行,活动图描述活动是如何协同工作的,当一个操作必须完成一系列事情,而又无法确定以什么样的顺序来完成这些事情时,活动图可以更清晰地描述这些事情。
在本图书馆管理系统中,我们主要描述了图书馆系统的借书、还书和预订的活动图。
1.借书活动图【借书活动图说明】管理员首先要扫描读者的借书证,检验证件是否符合图书馆借书条件,若该读者的借书数量还未达到最大规定数量,并且其所借书籍均未属于过期围,则符合借书条件。
则再扫描书籍条形码,检查书籍是否是不可借书籍或者已经被预订,若被预订,则取消预订,方可借书。
在这些条件都符合时则更新书籍信息和读者的借阅信息,记录好借书的时间。
12图8:图书馆管理系统的借书活动图2、还书活动图【还书活动图说明】图书管理员对书籍进行扫描,若书籍已经过期,则要求读者还请欠款才能还书,读者缴应交罚款后,更新书目信息和读者信息。
页脚图9:图书馆管理系统的还书活动图3、预订图书活动图【预订书籍活动图说明】读者先进入系统查询自己所需要的书籍,显示书籍信息,检验书籍是否属于可预订书籍,若符合条件则检查书籍是否已经被预订或已经被外借,若都未成立,则读者登录系统,并对该书籍进行预订。
12图10:图书馆管理系统预订书籍活动图6、图书馆管理系统的类图【类图说明】(1)reader类是借阅者的类,它的属性很多,包括借阅者的账户ID(reader_id)、(reader_Name)、地址(Address)、班级(class)、所借书籍的书目(borrowed)等。
其中主要操作有借书(addborrowed)和还书(deleteborrowed)和预订(reservation)等。
(2)admin类是管理员类,他有编号和属性,操作主要是书籍的增删改和读者的增删改等等。
(3) Title 类是记录书目信息的类,包括书籍的名字(name)、作者(author)、book_id 等属性。
(4) Item 类是具体某本书的类,属性包括书籍号(id)。
操作包括预订(reserve)、按书目查找(find_on_title)等。
(5) borrow类是某本书的借阅信息类,包括所借阅书籍的ISBN、借阅的时间(date)等。
(6) Reservation类是预订信息类,每个预订信息包括预订日期(date)、所预订书籍的ISBN、预订书籍的用户ID(UserID)等属性。
(7) persistent store类是书籍永久的存储类,在数据库中的存储数据,其他对与书籍有关的活动都要经过其存储类。
图11:图书馆管理系统的类图及关系图书馆管理系统数据库建模考虑到系统的推广性,本系统采用SQL SERVER2000作为数据库。
并且采用PowerDesigner进行数据建模,从而自动生成sql脚本。
1、数据库概念设计1、数据库表设计(1) 管理员表admin:管理员编号(admin_id),管理员(admin_name),密码(admin_password),登录次数(logins),最后一次登录时间(lastlogin)和权限(right)。
(2) 读者表reader:读者编号(reader_id),读者(reader_name),性别(sex),年龄(age),班级(class),最大借书量(maxborrowed)借书总量(amount)和权限(right)。
(3)书籍表books:书籍编号(book_id),书名(title),作者(author),(book concert),价格(price),出版时间(time),在库总量(amount),剩余量(remain)。
(4)借阅信息表(borrow_information):书籍编号(book_id),读者编号(reader_id),借书时间(borrow_time),到期时间(end_time),归还时间(return_time).(5)预订信息表:读者编号(reader_id),书籍编号(book_id),预订时间(reservation_time),取消预订时间(reservationcanceltime).(6) 书籍类型表booktype:书籍类型编号(type_id),书籍类型名称(type_name).(7) 用户权限表right:权限(right)。
2、图书管理系统个实体之间的E-R图图12:图书馆管理系统各实体之间的ER图3、基于powerdesigner的CDM数据库模型(1)数据库概念数据模型CDM对象如下图,该图显示了各实体的属性及各实体之间的关系。
图13:图书馆管理系统CDM建模。