图书管理系统课设报告（含用例图、通信图、顺序图、状态图、活动图）
这份报告帮助了很多人完成学业，你值得拥有
下载链接: https://download.csdn.net/download/secretstarlyp/12504045
面向对象的系统分析与设计
课程实验报告
1.研究背景及意义
学校图书馆希望设计一个图书管理系统，管理读者的登记、图书的购入、借出、归还以及注销等。管理人员还可以查询某位读者、某本图书的当前借阅情况、历史借阅记录，并可按照读者角度、图书角度、借阅角度分别进行统计，给出统计报表，以全面掌握图书的流通情况。
目前图书馆为手工管理，读者办理借阅等手续麻烦，而且管理员工作量打，开发这个系统最主要是方便管理，读者可以咋计算机上查询，预订图书，不须到图书馆直接去查找，这样节省了很多时间，管理员也可以再计算机上操作图书管理及读者管理，方便快速。目前的图书馆也可以进行信息查询预订图书，但因为是手工管理，速度慢，不方便，新的系统可以快捷的实现这些功能。为图书馆和读者都带来方便。
基于WEB的图书管理系统是对图书馆的网上管理，提高工作的效率。目标系统在至少应提供一下功能：系统管理员能够实现对系统管理：包括图书，借阅信息等的插入、修改、注销等功能，其中涉及基于以上操作的管理员操作，借阅者操作两个方面。目标系统可以查询某位读者、某本图书的当前借阅情况、历史借阅记录，并可按照读者角度、图书角度、借阅角度分别进行至少应该提供以下功能;证件的确认，借阅者可以查询自己的借阅信息，资料，预订图书等，管理员可以统计，给出统计报表，以全面掌握图书的流通情况。
2.系统的需求分析
2.1技术可行性
学校只需要建立一个局域网，并引入适当量的硬件设备就可以实现图书管理系统的应用，目标系统准备使用Java技术实现，目前这种技术已经普遍，因此在技术手段上实现本系统成为可能，高校也有计算机师资力量，对一定的软件师生有能力在一定时间内掌握。综上所述，目前实现目标系统的条件已经较为成熟。
2.2经济可行性
目标系统开发所需要求比较低，且系统不是十分复杂，开发的周期较短，人员经济支出有限。当系统开发完实际运行后，将会改变学校原有的图书手工管理，给许多读者带来方便，并且系统的开发将提高读者的时间利用率。
2.3系统的具体功能性需求
2.3.1用户分类和特征：
管理员：图书管理系统的管理者，管理读者的登记、图书的购入、借出、归还以及注销。查询某位读者、某本图书的当前借阅情况、历史借阅记录，并可按照读者角度、图书角度、借阅角度分别进行统计，给出统计报表全面掌握图书的流通情况。
读者：借阅图书馆图书的人。查询，借阅，归还图书。
2.3.2功能需求
- 读者注册：没有账号的读者可以注册用户，核实读者为本校教师或学生后予以注册。
- 读者登记：为读者编制读者卡片，包括读者的具体信息（读者编号，姓名，学院，专业，年级等），写入读者目录文件中。
- 购入新书：为该书编制图书卡片，包括分类目录号、流水号（唯一）书名、作者、内容摘要、价格和购书日期等信息，写入图书目录文件中。
- 图书注销：在某些情况下，需要对图书馆的图书进行清理工作，对无价值的和过时的图书要注销。
- 读者借书：先检查该读者是否有效的读者，若无效则拒绝借书，否则检查该读者所借图书是否超过最大限制数（五本）以及有未归还的过期图书，否则拒绝借书。查找该图书是否有多册，如果有则可以借出，登记图书分类号、读者号和借阅日期等。
- 读者还书：根据书号，从借书文件中读出有关记录，标明还书日期，如果图书过期，则处以罚款，并打印罚款单。
- 查询打印：根据需要可分为查询某位读者、某种图书和全局图书三种方式进行，同时可以打印读者和图书情况统计表。
- 系统维护：管理员可以对系统的数据进行维护，如增加、删除和更新书目，增加、删除和更新借阅者帐户，增加和删除书籍。
2.3.3非功能性需求：
（1）性能需求
- 系统在10秒内响应所有的请求；
- 系统应该每周七天、每天24小时都可以使用，并且在每天中午13：00——13：30进行书目的借阅情况及库存情况更新；
- 对一个没有经验的用户而言，经过两个小时的培训就可以使用系统的所有功能。
（2）输入输出需求
输入需求：
- 查询时输入读者姓名，证件号码，密码，书目名称或书目代码；
- 读者输入姓名类型为char；
- 读者输入的证件号码类型为char，号码范围为1000000000——4999999999；
- 读者输入的密码类型为char;
- 读者输入书目名称的类型为char;
- 读者输入书目代码的类型为char,范围为xxA0000——xxZ9999；
输出需求：
- 查看借阅信息正常输出显示借阅者姓名，学号，学院，借阅历史，剩余借阅量，预约状态，欠费状态，书目过期时间，即将过期书目显示续借状态；
- 查询正常输出显示书目名称，作者，发表日期，库存量，可借数目，库存地址；
- 预约正常输出显示书目名称，作者，发表日期及预约成功；
- 借阅正常输出显示当前借阅者信息及书目名称，作者，过期时间，剩余借阅量；
- 借阅量满情况下借阅时，显示不能再借书；
- 欠费状态显示欠费情况，提示交费，不能借书；
- 读者输入信息不正确时，显示输入错误！请重新输入。
（3）故障处理需求
- 死机情况下软件要能自动保存当前信息。
- 处理：重启机器，并查看核实信息。
- 输入信息类型不正确时，显示请重新输入有效信息。
- 不能正确显示读者信息或借阅信息时，管理员要核查读者信息，并对系统信息进行及时改正。
3.用例分析
用例图
在本系统中一共包含了三个参与者：
（1）其中读者的主要用例包括查询读者账户（即查询自己的个人信息以及查询自己的账户和借阅情况）、借书、还书和查询图书信息。
（2）图书管理员的主要用例是查看读者的账户，包括读者的个人信息以及读者的账户和借阅情况。在对书籍的信息进行管理的时候能够查看并添加添加图书的各种信息，修改图书的信息，以及删除图书的信息。在对借书记录和还书记录进行管理时图书管理员可以判断读者的借书情况是否超期，根据超期的情况决定是否需要罚款。
（3）系统管理员有五个用例，管理借阅者信息，包括添加新生信息和删除毕业生信息。在对图书的信息进行管理的时候，也能够添加新书的信息和删除已损坏图书的信息。同时，系统管理员也可以查询现有所有图书的信息，来决定是否需要引进新书。系统管理员也可以管理借书记录和还书记录，主要是当图书管理员遇到问题时，系统管理员也可以实现借还书的功能，另外，图书管理员和系统管理员都继承于图书馆内部人员这个父类。
4.数据库分析与设计
类图
本系统一共设计了七个类： 。
读者类：属性包含（1）读者证号 （2）密码 （3）最大借书数量
方法包括（1）借书 （2）还书 （3）查看用户账户 （4）查看借书数量 （5）登录系统
（5）查询图书信息 （6）交罚款
图书管理员类：属性包含（1）管理员帐号 （2）密码
方法包括（1）查询图书信息（2）修改图书信息
书架类：属性包含（1）书架号 （2）类型（3）位置（4）存放数量
方法只有 存放图书
图书类：属性包含（1）书号（2）书名（3）数量（4）价格（5）出版社
（6）馆藏册数（7）在馆册数
系统管理员类：属性包含 值班时间
方法包括（1）查看用户个人信息（2）修改用户个人信息
后台系统类：属性包含（1）级别（2）配置
方法包括（1）存储用户个人信息（2）存储图书信息（3）存储借阅信息
Item类：属性包含 id
方法包括（1）创建（2）销毁（3）更新（4）显示图书信息（5）显示借阅次数
其中，图书管理员类和系统管理员类是工作人员类的子类，图书管理员在继承了其父类的属性和操作以外还自己添加了管理员帐号和密码这两个属性，添加了查询图书信息和修改图书信息这两个操作。系统管理员在继承了父类的基础以外还添加了值班时间这个属性，以及查看用户个人信息和修改用户个人信息这两个操作。
另外，读者类和工作人员类是Person类的子类，读者在继承了其父类的属性和操作以外还自己添加了读者证号、密码和最大借书数量这几个属性，添加了借书、还书、查看用户账户、查看借书数量、登录系统、查询图书信息和交罚款这些操作。工作人员在继承了其父类的属性和操作以外还自己添加了工资和管理范围这两个属性，添加了登录账户、查询用户借阅信息、管理借书记录、管理还书记录、查看用户账户这些操作。
Person类是读者类和工作人员类的父类，它包含了所有人都有的三个属性：姓名、性别和年龄。读者类和工作人员类继承于Person类，这就简化了这两个子类的属性。
类之间的关系先从图书管理员讲起，图书管理员能够为读者提供服务，因此，二者之间应该是服务与被服务的关系。另外，图书管理员能够管理书架和图书，而且书架与图书之间是存放与被存放的关系，所有的图书都被存放于图书馆的书架中。最后，图书管理员还能够查看Item，Item类有点类似于超市中在购物后产生的小票，当读者在完成整个借阅的操作之后，后台系统会自动生成一个Item，因此，在类图中Item与后台系统之间是一种聚合的关系，而读者也可以查看Item，因为当读者在完成借阅之后，Item便可以证明借书是否成功以及后台系统是否发生故障。
除了图书管理员之外，同样继承于工作人员的系统管理员类也与其他类有着很多联系，比如说系统管理员同样与图书类有着维护与被维护这样的关系，但与图书管理员不同的是，系统管理员只负责通过从后台系统中的添加、修改或者删除来管理图书，而不是像图书管理员一样去管理实体的图书。另外，系统管理员可以管理后台系统，控制后台系统中所存储的信息以及当后台系统在发生一些故障时，系统管理员能够提供及时的维修。
数据表设计
图书表
读者表
读者类型表
正借阅表
已还表
书架表
工作人员表
5.系统主要交互流程设计
借书过程的顺序图：
上图表示了读者在进行借阅操作时的一系列变化，读者在进行借书操作之前，首先需要输入自己的信息包括帐号和密码，显示器将这些信息发送给数据库，在数据库中将读者的帐号和密码进行比对，进行身份验证，并将验证的结果返回给读者。如果身份验证成功则用户登录成功，反之读者登录失败。
然后，读者可以向图书管理员发送借阅请求，图书管理员在收到消息后可以向后台系统输入借阅信息，后台系统查看对应图书的馆藏册数，并根据馆藏信息，返回该图书是否可借阅。若可借阅，则图书管理员可在此时修改后台系统的借阅信息，将需要借阅图书的读者信息添加到后台数据库的借阅表中，并且后台系统自动计算当前对应的借阅时间。
此时，后台系统调用其Item功能，当图书管理员修改完借阅表之后，后台系统生成一张纸质书单，即类似于超市购物时的小票，图书管理员得到小票确认无误后将纸质小票返回给借阅者，借阅者可以得到实体的图书，整个借阅过程结束。
还书过程的时序图：
读者在进行借书操作时，可以向图书管理员发送借阅请求，图书管理员在收到消息后可以向后台系统输入借阅信息，并查看对应图书的馆藏信息，并根据馆藏信息，产生一个分支判断。若馆藏册数为0，则不可借阅，返回错误信息并拒绝读者的借阅，之后结束整个借书操作。若馆藏册数不为0，则可借阅，后台系统返回可借阅信息。
图书管理员在后台系统返回可借阅信息之后修改后台系统的借阅信息，将需要借阅图书的读者信息添加到后台数据库的借阅表中，并且后台系统自动计算当前对应的借阅时间，与此同时，后台系统调用其Item功能，当图书管理员修改完借阅信息之后，后台系统生成一张纸质书单。
完成这两个操作之后，借阅者可以得到实体的图书，整个借阅过程结束。
通信图
通信图也叫协作图，可与时序图相互转化。它是动态设计视图，强调参加交互的各个对象的组织，通信图只对相互之间有交互的对象和这些对象那个之间的关系建模，忽略了其它对象和关联。
协作图的组成部分
对象：用长方形框表示对象。
连接：使用实线标记两个对象之间的连接。
消息：由标记在连接上方的带有标记的箭头表示。
活动图：
状态图：
读者在进行借书与还书操作之前首先需要通过注册来验证身份，学校中的图书馆借阅者以学生为主，学生在登记学生信息之后一直处于未注册的状态。通过图书馆管理员对其进行注册操作，读者的状态才由未注册转向已注册。另外，读者在已注册的状态下也可以修改个人信息，此时借阅者的状态不变。
注册完之后的读者在身份验证成功之后就可以进入到系统，进行图书信息和自己个人信息的查询。已注册的读者此时处于可借阅的状态，若读者借书数量小于等于10本时，在办理借阅手续之后就可以对图书馆中的图书进行借阅。在取完实体书之后，借阅者便进入一个未还书的状态。
若借阅者处于未还书状态超过2个月，则借阅者进入欠款状态，若借阅者处于未还书状态不超过2个月，则借阅者依旧处于未欠款状态。当借阅者在欠款状态时，需要进行还款，还款之后返回到未欠款状态。通过还书，借阅者进入已还书的状态。
此时可选择继续借阅或者是直接结束，若是通过继续借阅返回，则需要进行判断，当读者借书数量小于等于10本时，才可以继续借阅，若是读者借书数量大于10本，则直接结束，无法再借。
读者从未登记到还书成功时的状态图：
图书管理书籍状态图
图书管理借阅者状态
6.系统实现
基于 vue.js 、element-ui 搭建一个前后端分离的的图书管理系统。具体有以下特点：
- 完备组织架构体系，基于 RBAC 模型实现用户权限配置
- 基于导航守卫，动态生成路由、用户菜单、面包屑导航等
- axios 异步请求统一封装，统一处理操作结果通知
- element-ui 组件使用覆盖率达到 70% 以上
1.登录界面
2.系统首页
3.图书界面
4.图书编辑界面
5.图书章节界面
6.作者管理界面
7.新增作者界面
8.编辑作者界面
9.字典配置界面
10.用户管理界面
11.新增用户界面
12.菜单权限界面
13.个人中心界面
14.角色管理界面
7.总结
本系统是使用java技术实现的，对于自身而言很是困难，所以在这个过程中基本处于一边学习一边设计的情况，通过观看各种javaweb视频来进行学习并设计。尽管如此还是有许多不足，除了程序本身还是有很多不足，自身的基础知识也不是很牢固。 程序自身还有很多繁琐并且重复的地方，由于编写前期受到视频的影响将前端代码写到的后端，采用了输出流的方式，使得程序异常繁琐，导致添加功能时期的进度十分缓慢，对自己造成了很大的困难，走了很多弯路。经过这段时间的努力，对javaweb编程与mysql数据库有了更深的理解，对自己以后的学习工作道路大有裨益。
通过开发这个设备管理系统学到了很多java全栈知识，例如ssm框架、git分支、数据库、前端等等知识点，使我进步了许多，对后端开发有了一个全新的认识，主要是把基础设施代码和业务代码尽可能的分开，各自不要干扰，而且能把BEAN都统一到spring container里面去，这样，bean的生老病死都由spring来管理，开发者就只需要关心业务怎么实现就好了，别一会实现功能，中间还要来段事务处理，后面还要加个数据库错误处理啥的。总而言之一句话，spring解决的问题就是尽可能的业务代码归业务代码，基础设施代码（日志、事务，异常，对外接口......）归基础设施代码，搞定解耦的问题，希望在以后的学习生涯中可以了解更高效的技术，从浅入深，环环相扣，每一步都会对照着官方文档结合自己的见解进行讲解，同时也会编码实现，理论与实践相结合。