logo资料库

WEB大作业图书管理系统.doc

第1页 / 共44页
第2页 / 共44页
第3页 / 共44页
第4页 / 共44页
第5页 / 共44页
第6页 / 共44页
第7页 / 共44页
第8页 / 共44页
资料共44页,剩余部分请下载后查看
第9章图书馆管理系统
9.1 收集与分析应用需求
9.1.1.收集需求
9.1.2.分析需求
9.2系统建模
9.2.1.图书馆管理系统的用例分析
9.2.2. 图书馆管理系统的领域分析
9.2.3.图书馆管理系统的系统设计
9.3设计数据库
9.3.1.概念设计
9.3.2.关系数据库的逻辑设计
9.3.3. 数据库的实现
9.4.设计用户界面
9.4.1.图书查询界面
9.4.2.借阅管理界面。
9.4.3.图书归还界面
9.4.4.图书管理界面
9.4.5.借阅证管理
9.4.6.读者规则管理界面
9.4.7.读者信息查询界面
9.5.代码实现
9.6.小结
第 9 章 图书馆管理系统 随着近年来教育事业的蓬勃发展,各大高校的基础建设不断加强。作为高校基础项目建 设标志性内容的图书馆,也随之不断扩大和加强。与此同时,为了使图书馆的功能得到充分 的发挥,迫切需要优秀的管理软件来维护图书馆的日常管理和运营。本章所要介绍的开发案 例,就是一套 JSP+MYSQL 实现的图书馆管理系统。 9.1 收集与分析应用需求 9.1.1. 收集需求 收集需求的目的在于明确客户的应用需求,确定系统开发的任务,消除设计开发人员和 客户之间的理解分歧,确保最终开发出来的产品能够满足客户的实际需要。 下面是一个图书馆管理系统开发过程中收集到的客户需求的文档记录的关键部分: 1. 图书馆管理系统有三类使用用户:图书借阅者、图书馆工作人员、图书馆管理人员。 2. 图书借阅者使用本系统能够进行以下操作:查阅借阅信息、查阅个人信息、修改个 人信息、查阅/查询馆藏书目信息。 3. 图书馆工作人员使用本系统进行以下操作:对图书借阅者进行借还书操作以及统计 相关的信息,维护和管理图书馆书目的有关信息 4. 图书馆管理员使用本系统进行以下操作:维护图书馆借阅者、工作人员、馆藏书目 的信息,维护系统状态,维护各类报表 5. 不同的用户应该具有相应的权限控制,重要的数据信息需要加密并备份 6. 重要的操作需要写入日志记录 7. 当系统出现故障时,应该有相应的应急措施或系统恢复功能 8. 系统需要有良好的可扩展性,方便以后的维护和升级工作 9. 系统需要有对外的接口,方便与外界的交流和信息互换工作
9.1.2. 分析需求 从以上收集到的需求来看,图书管理系统需要满足来自三方面的需求,这三个方面分别 是图书借阅者、图书馆工作人员和图书馆管理人员。图书借阅者的需求是查询图书馆所存的 图书、个人借阅情况及个人信息的修改;图书馆工作人员对图书借阅者的借阅及还书要求进 行操作,同时形成借书或还书报表给借阅者查看确认;图书馆管理人员的功能最为复杂,包 括对工作人员、图书借阅者、图书进行管理和维护,及系统状态的查看、维护并生成催还图 书报表。 图书借阅者可直接查看图书馆图书情况,如果图书借阅者根据本人借书证号和密码登录 系统,还可以进行本人借书情况的查询和维护部分个人信息。一般情况下,图书借阅者只应 该查询和维护本人的借书情况和个人信息,若查询和维护其他借阅者的借书情况和个人信 息,就要知道其他图书借阅者的借书证号和密码。这些是很难得到的,特别是密码,所以不 但满足了图书借阅者的要求,还保护了图书借阅者的个人隐私。 图书馆工作人员有修改图书借阅者借书和还书记录的权限,所以需对工作人员登陆本模 块进行更多的考虑。在此模块中,图书馆工作人员可以为图书借阅者加入借书记录或是还书 记录,并打印生成相应的报表给用户查看和确认。 图书馆管理人员功能的信息量大,数据安全性和保密性要求最高。本功能实现对图书信 息、借阅者信息、总体借阅情况信息的管理和统计、工作人员和管理人员信息查看及维护。 图书馆管理员可以浏览、查询、添加、删除、修改、统计图书的基本信息;浏览、查询、统 计、添加、删除和修改图书借阅者的基本信息,浏览、查询、统计图书馆的借阅信息,但不 能添加、删除和修改借阅信息,这部分功能应该由图书馆工作人员执行,但是,删除某条图 书借阅者基本信息记录时,应实现对该图书借阅者借阅记录的级联删除。并且还应具有生成 催还图书报表,并打印输出的功能。在本系统中由于没有打印机设备供试验,所以预先把报 表打印改成报表预览。 下面就是通过分析后得到的系统需要实现的功能:  设计不同用户的操作权限和登陆方法  对所有用户开放的图书查询  借阅者维护借阅者个人部分信息  借阅者查看个人借阅情况信息  维护借阅者个人密码  根据借阅情况对数据库进行操作并生成报表  根据还书情况对数据库进行操作并生成报表  查询及统计各种信息  维护图书信息  维护工作人员和管理员信息  维护借阅者信息  对借阅过期的图书生成报表
9.2 系统建模 9.2.1. 图书馆管理系统的用例分析 在前面的需求分析过程中,我们已经明确了系统的三类角色(Actor)及其相关的用例:  图书借阅者:查询图书馆所存的图书、个人借阅情况及个人信息的修改。  图书馆工作人员:对图书借阅者的借阅及还书要求进行操作,同时形成借书或还书 报表给借阅者查看确认,对超过应还书日期的读者进行超期罚款  图书馆管理员:对工作人员、图书借阅者、图书进行管理和维护,及系统状态的查 看、维护并生成催还图书报表。 在这里需要说明的是:图书馆管理员不能直接修改图书借阅者的借阅信息,只有当管理 员删除了某条读者信息的时候才应当级联地删除该借阅者的借阅信息,并生成催还图书报 表。 根据前面的需求分析,我们得到了图书馆管理系统的用例(UseCase)图。首先我们看到 的是整个系统的用例图,如图 9-1 所示: 图书馆工作人员 处理借阅请求 书目管理 <> 查询书目 <> <> <> 借阅请求 <> 人员管理 登陆/退出 图书馆管理员 <> 图书借阅者 发布新闻 浏览新闻 游客 图 9-1 系统的总体用例图
在这个总体用例图中,我们增加了一个“游客”的角色,这是基于对系统权限控制的考 虑。在这个系统中,馆藏书目的信息和系统发布的相关新闻是对所有人开发的,这些信息不 受任何权限的限制,因此,在用户没有登陆到系统之前,这些信息也应当是可见的。增加“游 客”类的角色,使得用户一进入系统就能获取得到公共信息,避免了登陆的麻烦,提高了系 统的可用性。 我们也看到,总体用例图十分复杂,某些角色的用例还比较模糊,需要进一步细化。因 此,我们下面分别给出了图书借阅者,图书馆工作人员以及图书馆管理员的用例图。 首先我们看到的是图书借阅者的用例图,如图 9-2 所示: 查询书目 修改个人信息 <> 图书借阅者 <> 登陆/退出 <> 借阅请求 <> <> 查询借阅信息 借书请求 还书请求 图 9-2 图书借阅者的用例图 从读者的用例图中我们可以看到:读者发起的“借阅请求”包括“借书请求”,“还书请 求”和“查询借阅信息”三个部分的内容,<>关系表明了“借阅请求”对后面三 部分内容的包含关系。在上图中,还有一种<>关系,分别出现在“登陆/退出”用 例和“借阅请求”以及“修改个人信息”之间,这个关系表明后面两个用例的启动需要“登 陆/退出”用例的支持。换句话说,只有当借阅者登陆到了系统之后,才能进行“借阅请求” 操作和“修改个人信息”操作,否则无法完成这些操作。
查询书目 统计报表 修改个人信息 <> <> 图书馆工作人员 <> 登陆/退出 <> <> 处理借阅请求 确认还书 <> <> 超期罚款 确认借书 确认续借 图 9-3 图书馆工作人员的用例图 图书馆工作人员的用例图如图 10-3 所示。正如前面所介绍的那样,图书馆工作人员的 用例图当中也存在<>和<>关系。这些关系的含义与前面读者用例图中 的介绍相一致。需要注意的是,在单独的用例图当中没有反映出图书馆工作人员和借阅者之 间的用例的依赖关系,这是由于局部用例图的局限性所造成的。因此,要全面的把握系统的 结构,还是应当从整体用例图入手,然后逐步深入和细化。这种方式正好体现了软件工程中 “自顶向下,逐步细化”的思想。 注意到图书馆工作人员的“修改个人信息”用例,它应该包括两部分的内容:首先,工 作人员应该可以修改自己的相关信息,就如读者可以修改自己的信息一样;其次,图书馆工 作人员也可以修改读者的部分信息,如读者的借阅权限。这个功能在建立临时用户权限的时 候非常有用。如果借阅者的借阅权限固定不变,那么每当借阅者的借阅权限需要发生变化的 时候,他原来的账号需要销毁,并重新建立新的账号,这给应用带来了很多不变,也浪费了 系统的资源。如果将此类问题全部提交给图书馆管理员,那么将增加管理员的负担,不利于 图书馆内部资源的均匀分配。
统计报表 查询书目 <> 删除用户 增加用户 <> <> 人员管理 <> 查询用户资料 <> <> 修改用户信息 <> 登陆/退出 图书馆管理员 <> <> 发布新闻 <> 书目管理 <> 增加书目 <> 修改书目信息 删除书目 查询书目信息 图 9-4 图书馆管理员的用例图 图书馆管理员的用例图最复杂,因为他在系统中担负的任务最多,所涉及的内容最核心。 从系统稳定和安全的角度考虑,这部分用例应当具有较高保密能力,同时这部分用例所进行 的操作都必须写入日志文件,以确保能够从管理员的误操作中恢复过来。 下面是对本系统中涉及到的主要用例的一些简单介绍: 1. 登陆/退出系统:本用例描述了用户如何登陆和退出本系统,登陆时要注意的事项, 本系统所有用户都启用本用例。 2. 查询书刊信息:本用例描述了用户可以在各种允许的条件下,选择关键字段对本馆 的书刊的详细资料进行查询。本用例主要是面向读者的,但图书馆管理员和工作人 员也可以启用本用例。 3. 查询用户信息:本用例描述图书管理员如何进行用户信息的查询,管理员只要输入 用户的 ID 就可以对用户的所有资料进行查询。本用例的主要角色是图书馆管理员。 4. 超期罚款:本用例主要是描述当读者有书刊超期没有归还时,图书管理员是如何对 超期读者进行罚款处理的。本用例中的主要角色是图书馆工作人员。 5. 管理书刊:本用例是描述图书管理员如何对图书馆里的书刊进行管理,如:新书入 库,旧书出库,书刊资料的修改等,本用例的主要角色是图书馆管理员。 6. 管理用户:本用例包含多个用例主要是描述对借书用户(读者)的管理,主要角色 是图书管理员。 7. 借阅请求:本用例描述了图书管理系统最重要的功能,读者如何从图书馆中借阅书
刊,主要角色是读者。本用例的成功完成需要依赖工作人员的“确认借书”用例 8. 还书请求:本用例了描述用户如何把借阅的书刊归还到图书馆,读者归还书刊必须 经过图书操作员代理还书,因此主要角色是读者和图书馆工作人员。 9. 确认借书:本用例描述图书馆工作人员如何确认借阅者的借书请求,即读者的借书 记录记载到载体当中。本用例的主要角色是图书馆工作人员。 10. 确认还书:本用例描述读者归还的书刊如何经图书馆工作人员归还到书库当中,本 用例的主要角色是图书馆工作人员。 11. 增加用户:本用例描述图书管理员为持有借书证的读者在本系统中增加一个记录, 主要角色是图书管理员和读者。 12. 删除用户:本用例描述图书管理员如何从系统中删除用户的记录,主要角色是图书 管理员和读者。 13. 续借书刊:本用例描述用户在当书刊将要到期如何对书刊进行续借,主要角色是读 者和图书馆工作人员。 14. 修改个人信息:本用例描述用户如何对自己的资料进行修改,本用例的主要角色是 读者,图书馆工作人员也可以修改自己的信息以及部分读者信息。 15. 修改用户信息:本用例描述图书馆管理员如何对系统用户的资料进行修改,用例的 主要角色是图书馆管理员。 16. 发布新闻:本用例描述图书馆管理员如何在系统上发布新闻,用例的主要角色是图 书馆管理员。 17. 浏览新闻:本用例描述系统的使用者如何在系统上浏览新闻,它对所有进入系统的 人员(可能不是系统的用户)开放。 9.2.2. 图书馆管理系统的领域分析 在用例分析的基础之上,我们将进行领域分析。领域分析的目的在于确定系统中概念与 概念之间的关系。 由于本系统涉及的概念非常广,为了更加清楚的表示这些关系,我们将这些概念划分为 三个层次:界面层,控制层和数据实体层。这三个层次所对应的领域关系图如下: 新闻页面 书目管理页面 查询页面 登陆页面 用户页面 罚款页面 还书页面 借书页面 用户管理页面 个人信息修 改页面 图 9-5 图书馆管理系统界面层领域关系图
管理 管理书目 修改用户资料 管理读者信息 增加图书 修改图书信息 删除图书 增加读者 修改读者信息 删除读者 登陆 图书借阅 查询 发布新闻信息 借书 还书 续借 查询图书信息 查询读者信息 <> <><> 罚款 图 9-6 图书馆管理系统控制层领域关系图 +0:1 +0:1 书目信息 日志记录 +0:1 读者信息 +0:n +1:1 +0:n 借阅信息 工作人员操 作日志 +0:1 +0:1 +0:1 +0:1 +0:1 +0:1 管理员操作 日志 +0:1 +0:1 工作人员信息 +1:1 借书记录 还书记录 +1:1 +1:1 续借记录 +1:1 罚款记录 图 9-7 图书馆管理系统数据层领域关系图 领域关系图比较清晰地描述了系统中各个概念之间的静态关系,如果需要描述系统中的 动态关系,就必须用到 UML 的时序图、协作图或者活动图。时序图的基础是用例,在时序 图中,将说明域类是如何操作和协作系统中的用例的。下面就以时序图来描述系统中的动态 关系。 9.2.3. 图书馆管理系统的系统设计 为了更加详细地介绍本系统中各个用例的工作过程,接下来我们给出本系统中关键用例
分享到:
收藏