面向对象的系统分析与设计
课程实验报告
项目名称: 图书管理系统的设计与实现
学
班
学
姓
院:
信息科学与技术学院
软件工程 1703
级:
号:
名:
完成时间:
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 便可以证明借书是否成功以及
后台系统是否发生故障。
除了图书管理员之外,同样继承于工作人员的系统管理员类也与其他类有着很多联系,比如
说系统管理员同样与图书类有着维护与被维护这样的关系,但与图书管理员不同的是,系统
管理员只负责通过从后台系统中的添加、修改或者删除来管理图书,而不是像图书管理员一
样去管理实体的图书。另外,系统管理员可以管理后台系统,控制后台系统中所存储的信息
以及当后台系统在发生一些故障时,系统管理员能够提供及时的维修。
数据表设计
图书表
读者表
读者类型表
正借阅表
已还表