图书馆管理系统.docx
- 文档编号:3753965
- 上传时间:2022-11-25
- 格式:DOCX
- 页数:26
- 大小:180.28KB
图书馆管理系统.docx
《图书馆管理系统.docx》由会员分享,可在线阅读,更多相关《图书馆管理系统.docx(26页珍藏版)》请在冰豆网上搜索。
图书馆管理系统
课程设计报告
学生姓名:
学号:
学院:
班级:
题目:
图书馆管理系统
教授
王欣
指导教师:
职称:
2011年7月15日
目录
1.选题背景1
2.图书馆管理系统的需求分析2
2.1图书馆管理系统的需求陈述2
2.2需求分析2
2.2.1功能需求2
2.2.2性能需求3
2.3系统需求建模3
2.3.1确定参与者3
2.3.2确定用例3
2.3.3系统用例建模4
2.3.4用例描述5
3.图书馆管理系统系统分析8
3.1系统用例建模8
3.2静态结构模型10
3.2.1类的识别10
3.3.3类的属性描述11
3.2.4类图的构建11
3.3系统动态模型12
3.3.1系统执行顺序分析12
3.3.2系统的协作分析15
3.3.3系统状态分析16
3.3.4系统活动分析17
4.图书馆管理系统系统设计与实现20
4.1UML体系结构设计20
4.1.1硬件体系结构设计20
4.1.2软件体系结构设计20
4.2对象模型设计21
4.3系统实现22
4.3.1组件分析22
4.3.2配置分析23
5.课程设计心得体会25
参考文献26
1.选题背景
现代信息技术的迅速发展使图书馆的信息环境发生了巨大变化,随着网上资源越来越丰富和网上参考咨询工作、网上教育的开展,读者对信息的需求也使图书馆的用户教育在时代的潮流中显示出其重要性。
为此图书馆对学生们进行信息素养教育,培养学生们的文献信息获取、识别、接受和利用的能力,使其在今后信息化、网络化的学习和科研环境中游刃有余。
除此,参考咨询部定期以讲座的形式进行用户教育,面向全校师生,介绍馆内现有一些光盘和电子数据库的收录范围,各种数据库的特色及其检索使用方法,介绍网址的搜索方法和文件下载的方法,对网上检索工具进行评估。
读者利用图书馆资源水平不断提高,反过来对图书馆用户教育和参考咨询服务要求也更高,这样形成良性互动,进一步促进图书馆资源的深层开发利用和用户教育﹑服务水平的提高。
图书馆管理系统是一种基于集中统一规划的数据库数据管理新模式。
在对图书、读者的广利,其实是对图书、读者数据的管理。
2.图书馆管理系统的需求分析
2.1图书馆管理系统的需求陈述
某学校拟开发一个图书馆管理系统,该图书管理系统需求陈述如下:
在图书馆管理系统中,管理员要为每个读者建立一个账户,并给读者发放不同类型的借书证,借书证标明个人借书证号、学号、姓名、班级或个人职位及所属部门。
图书管理员每天上班要登陆图书官管理系统,并对当天的书籍预约情况进行查询,将预约的图书放在预约台。
查询预约台上是否有超出预约期的图书并做相应处理。
持有借书证的读者可以通过管理员(作为读者的代理人与系统交互)借阅归还图书,不同类型的读者可借阅图书的范围、数量和期限不同,可通过互联网或图书馆内查询终端登陆图书管理系统查询图书信息、个人借阅情况和读者信息还可以进行密码修改,以及续借预约图书(系统审核符合续借预约条件)。
如果读者丢失图书应持借书证找图书管理员做书籍丢失记录,在规定的时间内进行赔偿。
图书管理员做好书籍丢失处理。
如果读者丢失原有密码、证件或退办证件可以通过系统管理员来修改密码及信息。
系统管理员还可以对新增、修改或丢失图书进行系统录入。
2.2需求分析
2.2.1功能需求
系统的功能需求包括以下几个方面。
(1)借阅者可以通过网络查询书籍信息和预定书籍,并可以进行密码修改。
(2)借阅者能够借阅书籍和还书以及续借。
(3)图书管理员能够处理借阅者的借阅和还书请求。
(4)系统管理员可以对系统的数据进行维护,如增加、删除和更新数目,增加、删除和更新借阅者账户,增加和删除书籍。
(5)系统管理员对逾期或丢失的书籍进行处理。
满足上述需求的系统主要包括以下几个模块。
基本数据维护模块。
基本数据维护模块提供了使用者录入、修改并维护基本数据的途径。
例如对借阅者的、书籍的各项信息的更新与修改。
基本业务模块。
基本业务模块主要用于实现用户借书与还书的管理,例如借阅者可以登录系统预订书籍,图书管理员可以取消书籍的预订,当然还可以进行借书、还书等操作。
数据库管理模块。
在系统中,所有书籍的信息以及借阅者的账户信息都要统一管理,书籍的借阅情况、预订情况也要进行详细的记录,所以要用统一的数据库平台进行管理。
信息查询模块。
信息查询模块主要用于查询书籍的信息和借阅者的信息。
2.2.2性能需求
本系统使用UML建模技术,对图书管理系统进行分析与设计,使开发的系统方面用户的使用和维护,根据图书管理工作性质和环境决定了本系统在性能方面要达到以下要求。
1.系统可扩充性要求
要保证所整合的图书管理系统的可扩充性,对不同级别的用户要求的层次和模块,可灵活地进行定制。
使得将来易于与当前系统实现互连互通,为用户提供全方位,高质量和高效率服务。
2.界面友好性要求
系统提供统一的操作界面和方式。
要求操作界面美观大方、布局合理、功能完善,对于初级用户容易上手。
3.服务个性化要求
系统针对不同级别的用户提供方便的界面形式,以满足用户需求。
如图书管理员登录系统之后,可以看到系统所有的内容。
用户登录后,可以看到最关心的信息,对于有些不必要的细节,系统不会显示。
4.可管理性要求
系统涉及面较广,系统应提供对管理内容的分级分类管理和维护、审批服务事项、维护工作流定制与监控、用户信息维护、系统配置和管理、故障诊断等功能。
2.3系统需求建模
2.3.1确定参与者
参与者是指与系统交互的人或其他系统,它代表外部实体。
使用用例并且与系统交互的任何人或物都是参与者。
通过对系统需求的分析,可以确定系统中有以下几个参与者:
借阅者、图书管理员、系统管理员。
借阅者:
可以借阅、预定书籍,可以查询书籍信息等。
图书管理员:
处理借阅者借书还书业务,可以提供预订和取消预订功能等。
系统管理员:
增删更新书籍信息、借阅者信息,进行系统维护等。
2.3.2确定用例
一个用例是可以被参与者感受的、系统的一个完整的功能。
用例通过关联与参与者连接,关联指出一个用例与哪些参与者交互,这种交互是双向的。
通过以上的分析得到该系统的用例如下:
1.图书借阅者
概述:
该用例说明用户如何在图书馆借阅书籍,通过登录服务器预约,续借等功能。
前置条件:
该用户未出现借书超期。
后置条件:
系统记录用户借阅记录,并且对系统中的书目信息进行修改。
实现过程:
(1).图书管理员得到借阅者的图书证;
(2).系统扫描图书证的借阅者信息,并且将其姓名,班级,学号,借书号,借阅日期,归还日期进行记录;
在上面的实现过程中,借阅者的借阅信息和图书馆的图书信息已经进行了记录,在还书或者进行书目查询时,只需直接调用即可。
2.查询
概述:
该用例可以进行借阅者信息以及书籍信息的查询。
前置条件:
图书馆数据库中已存入相关信息。
后置条件:
图书入库,系统自动的修改书目信息。
实现过程(事件流):
(1).借阅者可以通过输入自己的帐号和密码进行书籍信息的查询,以及自己借书是否逾期等信息。
(2).如果逾期,则缴纳罚金,也可以退还该书
(3).图书管理员处理该书业务,系统管理员则进行书目信息和借阅者信息的更新。
3.信息维护
概述:
该用例说明如何对书籍和借阅者的信息进行删曾改等操作处理。
前置条件:
数据库信息健全。
后置条件:
数据信息不断进行更新。
实现过程(事件流):
(1).系统管理员输入书籍基本信息。
(2).系统可根据图书的基本信息,对图书信息进行记录更新,包括图书号、图书名称、图书作者、出版日期等。
2.3.3系统用例建模
根据以上分析结果得到以下用例模型
1.图书馆管理系统顶层用例图
图2-1图书馆管理系统顶层用例图
2.图书馆管理系统的一级用例图
图2-2图书馆管理系统的一级用例图
2.3.4用例描述
1.书籍借阅
书籍借阅用例描述如表2-1
表2-1书籍借阅用例描述
用例名称:
书籍借阅
用例标识号:
1
参与者:
借阅者
简要说明:
借阅者可以借阅和预定书籍。
前置条件:
该用户未出现借书超期。
基本事件流:
(1).图书管理员得到借阅者的图书证;
(2).系统扫描图书证的借阅者信息,并且将其姓名,班级,学号,借书号,借阅日期,归还日期进行记录;
其他事件流A1:
在按“提交”按钮之前,借阅者随时可以按“返回”按钮,返回到浏览页面
异常事件流:
1.提示错误信息,借阅者确认;
2.返回到申请管理页面。
后置条件:
系统记录用户借阅记录,并且对系统中的书目信息进行修改。
注释:
无
2.查询
查询用例描述如表2-2
表2-2查询用例描述
用例名称:
查询
用例标识号:
2
参与者:
图书管理者
简要说明:
图书管理者可以查询借阅者书籍信息和逾期情况
前置条件:
图书馆数据库中已存入相关信息。
基本事件流:
(1).借阅者可以通过输入自己的帐号和密码进行书籍信息的查询,以及自己借书是否逾期等信息。
(2).如果逾期,则缴纳罚金,也可以退还该书
(3).图书管理员处理该书业务,系统管理员则进行书目信息和借阅者信息的更新。
其他事件流A1:
突发性终止,或者借阅者点击返回,返回到主页
异常事件流:
1.提示错误信息用户确认
2.返回主页
后置条件:
图书入库,系统自动的修改书目信息。
注释:
无
3.信息维护
信息维护用例描述如表2-3
表2-3信息维护用例描述
用例名称:
信息维护
用例标识号:
3
参与者:
系统管理者
简要说明:
系统管理员要及时更新维护书籍和借阅者信息
前置条件:
数据库信息健全。
基本事件流:
(1).系统管理员输入书籍基本信息。
(2).系统可根据图书的基本信息,对图书信息进行记录更新,包括图书号、图书名称、图书作者、出版日期等。
其他事件流A1:
无
异常事件流:
1.提示错误信息系统管理员确认
2.返回主页
后置条件:
数据信息不断进行更新。
注释:
无
3.图书馆管理系统系统分析
3.1系统用例建模
(1)借阅者请求服务二级用例图
图3-1借阅者请求服务二级用例图
(2)图书管理员处理借书和还书业务二级用例图
图3-2图书管理员处理借书和还书业务二级用例图
(3)系统管理员维护系统二级用例图
图3-3系统管理员维护系统二级用例图
(4)信息查询用例图
图3-4信息查询用例图
3.2静态结构模型
3.2.1类的识别
我们对需求陈述进行初步处理之后,经过非正式分析得出图书馆管理系统的初始类为:
图书管理系统、系统管理员、图书管理员读者、借阅账户、借阅卡、账户、个人信息、借阅记录、互联网、图书馆、查询终端、续借图书、借阅卡号、基本信息、人工核对、图书信息数据库、图书号、图书信息管理。
对候选类进行严格的考察筛选,去掉不正确的或不必要的,仅保留确实应该记录其信息或需要其提供服务的那些对象。
删除不正确的或不必要的类与对象,根据冗余标准,读者、借阅卡号、借阅账户、个人信息、借阅记录都描述相同的类,图书号与图书信息,应保留在此问题域中最富于描述力的名称,因此,应该去掉读者卡号、个人信息等冗余的类,仅保留读者信息、管理员、图书管理系统这三个类。
综上所述,在住院管理系统中,经过初步筛选,剩下下列类与对象:
图书管理系统、管理员、读者、个人信息、借阅账户、图书信息数据库、查询终端。
通过对系统进行需求分析后,就可以识别出在该系统中存在的对象。
从前述的系统需求描述中可以找到以下对象类:
借阅者、书籍、管理员(图书管理员、系统管理员)。
3.2.2类的关联分析
在上文中我们将待开发的图书馆管理系统的对象和类识别了出来,随后,我们通过提取动词词组初步得出它们之间的关联,通过分析前文中的需求陈述,我们找出了陈述中隐含的关联,经过分析之后,初步确定出下列关联:
·系统建立借阅者信息
·图书管理员对图书进行典藏分配
·系统管理员对图书的信息进行记录
·当借阅者借阅图书时,图书管理员对图书进行扫描,系统自动对图书的信息进行记录
·图书处于未借出状态时,读者可以借阅图书,读者也可登陆图书馆管理终端,对图书进行预约
·读者归还图书时,图书管理员读图书进行扫描,系统提取读者信息,并对其借阅信息进行修改
·系统管理读数据书目,书籍目录进行修改,更新等操作
由于以上关联只是初步分析得出,并不合理,需要进一步的筛选初步得出的关联,去掉不正确的或不必要的关联,进一步完善,才能得到正确而合理的关联。
经过筛选之后,得到的关联如下:
·读者通过图书管理员对图书进行借阅,系统修改读者借阅信息、修改图书的借阅状态
·读者借阅的图书如果处于借出状态,则登陆图书馆客户终端,对图书进行预订,系统对其操作进行记录
·读者归还图书,系统更新借阅信息,修改图书的借阅状态
·系统管理员对图书目录,用户信息可以进行修改、删除、更新
3.3.3类的属性描述
属性是对象的性质,通过对象类和结构有更深入,更具体的认识。
一般来说确定属性的过程包括分析和选择两个步骤。
属性的确定既与问题有关,也和目标系统的任务有关。
应该仅考虑与具体应用直接相关的属性,不要考虑那些超出所要解决的问题范围的属性。
在分析过程中应该首先找出最重要的属性,以后在逐渐把其余属性添加进去。
此次分析过程中,我们在分析阶段没有考虑那些纯粹用于实现的属性。
只是在最后认真考察了经初步分析而确定下来的那些属性,从中删掉了那些不正确的或不必要的属性。
部分对象类的属性描述如下:
(1)借阅者类,它的属性很多,包括借阅者的账户、姓名、地址、班级、所借书籍的书目等。
其中主要操作有借书和还书和预订等。
(2)管理员类,他有编号和姓名属性,操作主要是书籍的增删改和读者的增删改等等。
(3)书目信息类,包括书籍的名字、作者等属性。
(4)书籍类,属性包括书籍号。
操作包括预订、按书目查找等。
(5)借阅信息类,包括所借阅书籍的借阅的时间等。
(6)预订信息类,每个预订信息包括预订日期、预订书籍的用户等属性。
(7)书籍永久的存储类,在数据库中的存储数据,其他对与书籍有关的活动都要经过其存储类。
3.2.4类图的构建
图3-5系统类图
3.3系统动态模型
3.3.1系统执行顺序分析
系统的顺序图
顺序图是显示对象之间交互的图,这些对象是按时间顺序排列的。
该图书馆管理系统主要含有以下几个重要的顺序图,其他对象的顺序图和这些也类似。
(1)借书顺序图
借书时,读者先将书拿予管理员,管理员对书籍和读者进行检验,若书籍和读者都符合借书条件,则借书成功。
(2)还书顺序图
还书时,读者先将书交给管理员,由管理员扫描书籍,若书籍没有过期等违规现象,则对书目和读者借阅信息进行更新,同时还书成功。
(3)罚款顺序图
管理员对书籍进行扫描,若发现书籍已经超过了图书馆规定的还书期限,则按每天一定金额进行罚款,过期天数和罚款金额由系统自动计算。
用户交完罚金后,则对读者借阅信息进行更新。
(4)管理员登陆顺序图
图3--6借书顺序图
图3-7还书顺序图
图3-8罚款顺序图
图3-9管理员登录顺序图
3.3.2系统的协作分析
系统合作图
1.借书合作图
图3-10借书合作图
2.还书合作图
图3-11还书合作图
3.罚款合作图
图3-12罚款合作图
3.3.3系统状态分析
系统状态图
图书馆的书籍状态图如图3-13所示。
【状态图说明】
书籍在未变成图书馆在库书籍时,为新加书籍状态。
书籍处于在库状态时既可以预订也可以外借,外借后变为借出状态。
处于预订状态时也可以外借,超出预订时间期限则从预订状态直接转为可用状态。
借阅者在规定的预订时间内也可以考虑取消预订,取消预订后书籍的状态转为可用。
外借书籍归还后变为可用状态。
图3-13图书馆的书籍状态图
3.3.4系统活动分析
系统的活动图
活动图描述的是某流程中的任务的执行,活动图描述活动是如何协同工作的,当一个操作必须完成一系列事情,而又无法确定以什么样的顺序来完成这些事情时,活动图可以更清晰地描述这些事情。
。
在本图书馆管理系统中,我们主要描述了图书馆系统的借书、还书和预订的活动图。
(1)借书活动图
【借书活动图说明】
管理员首先要扫描读者的借书证,检验证件是否符合图书馆借书条件,若该读者的借书数量还未达到最大规定数量,并且其所借书籍均未属于过期范围,则符合借书条件。
则再扫描书籍条形码,检查书籍是否是不可借书籍或者已经被预订,若被预订,则取消预订,方可借书。
在这些条件都符合时则更新书籍信息和读者的借阅信息,记录好借书的时间。
图3-14图书馆管理系统的借书活动图
(2)还书活动图
【还书活动图说明】
图书管理员对书籍进行扫描,若书籍已经过期,则要求读者还请欠款才能还书,读者缴应交罚款后,更新书目信息和读者信息。
图3-15图书馆管理系统的还书活动图
(3)预订图书活动图
【预订书籍活动图说明】
读者先进入系统查询自己所需要的书籍,显示书籍信息,检验书籍是否属于可预订书籍,若符合条件则检查书籍是否已经被预订或已经被外借,若都未成立,则读者登录系统,并对该书籍进行预订。
图3-16图书馆管理系统预订书籍活动图
4.图书馆管理系统系统设计与实现
4.1UML体系结构设计
4.1.1硬件体系结构设计
(1)该系统使用的硬件设备有:
利用一台高性能计算机作为网络数据库服务器,两台计算机作为终端机。
数据库服务器与终端机采用internet方式连接。
数据库服务器,终端与工作站采用Internet方式连接。
(2)连接:
数据库服务器与终端机采用Internet方式连接,数据库服务器,终端与工作站采用Internet方式连接。
该系统的硬件体系结构如下,
图4-1硬件配置图
4.1.2软件体系结构设计
信息系统的软件结构是由信息系统软件的各子系统按照确定的关系构成的结构框架,一般呈现多层次结构模式。
子系统是对软件进行分解的一种中间形式,也是组织和描述软件的一种方法。
软件结构设计就是把软件分解成多个子系统,并确定各子系统及其接口之间的相互关系。
在系统分析部分已经识别出系统的类,以及类的属性,根据这两部分对系统进一步的分析,用软件的组成原理,分析出系统的包,包既是系统中表现软件体系结构的一类图。
在系统分析中的定义并描述了各个类后,我们可以根据实际情况引入包来管理类,本图书馆管理系统可以划分为四个包:
用户管理:
对系统用户进行管理,为用户提供信息服务接口,便于对系统进行操作。
借阅管理包括借书处理,还书处理和罚款处理等;
借阅管理:
主要是读者借阅图书,系统对读者信息,数据库书目的添加、删除、更新等操作;
读者管理及图书管理:
包括对读者、图书等信息进行维护,主要有读者信息的增删,对图书更新资料进行维护。
系统服务:
包括系统登录检查,安全维护等。
系统的软件子系统如图4-2所示。
数据库层
应用层
服务层
用户层
图4-2系统的软件子系统
4.2对象模型设计
面向对象分析的首要任务就是建立对象模型。
对问题的陈述,文字形式的或图形形式的需求陈述是建立对象模型的主要信息来源,另外涉及的相关应用领域的专业知识也很重要。
建立对象模型是一个渐进的过程,在初期的模型一般都不完善,我们在做的时候,由于已经在前面进行了类的识别,类的关联分析,因此在此部分做时,我们参考前面的设计所进行的,因此在进行模型设计时,避免了一些不必要的错误的出现,但是在建立的过程中,我们也深刻的认识到了建立模型不是一次完成的事情,经过几次修改才形成了比较完整的对象模型图。
图4-3系统类图
4.3系统实现
4.3.1组件分析
构件图描述构件及其之间的相互依赖,构件是逻辑体系结构(类、对象、它们间的关系和协作)中定义的概念和功能在物理体系结构中的视线,它通常是开发环境中的实现性文件。
构件图主要用于建立系统的静态实现视图模型,通过构件之间的依赖(虚箭线)关系描述系统软件的组织结构,展示系统中的不同物理构件及其之间的联系。
在UML中对一个系统的构件和构件图建模就是在物理结构上建模。
每一个构件图只是系统静态视图的某一个图形表示,描述系统的某一个侧面。
也就是说,任何一个构件图都不必面面俱到,试图全面地描述系统的整个面貌,系统中所有的构件图合起来才能描述系统的完整静态视图。
图4-4系统构件图
4.3.2配置分析
配置图(DeploymentDiagram)描述了运行软件的系统中硬件和软件的物理结构。
配置图中通常包含两种元素:
节点(Node)和关联关系(Association)
节点是在运行时代表计算机资源的物理元素。
在UML中,节点用一个立方体来表示。
节点在很多方面与配置相同,二者都有名称和关系,都可以有实例,都可以被嵌套,都可以参与交互。
但是节点与配置之间也存在着差别:
配置是参与系统执行的事物,而节点是执行配置的事物。
配置表示逻辑元素的物理包装,而节点表示配置的物理配置。
配置用关联关系(Association)表示各节点之间通信路径。
关联关系一般不使用名称,而是使用构造型。
图4-5系统部署图
5.课程设计心得体会
在这两个星期的UML课程设计中我发现了自身的很多问题。
平时老师上课所教授的很多知识点自己都没有掌握,很多知识点甚至一点不懂。
我们小组选择的是一个图书管理系统的设计,难度是很大的,在我们分工之后各自负责自己的模块各自完成自己的任务,在设计过程中我们会遇到很多大大小小的问题,比如我在画状态图的时候就不知道该怎么下手该怎么分析。
于是我会选择请教同学或者上网查找资料,大家一起讨论。
设计的过程中我再次感受到团队的力量,在此感谢我的合作伙伴们,他们给我讲解了很多,我从他们那里学到了很多知识,这可能是这次课程设计我最大的收获。
通过这次课程设计,我认识到学校给我们课题的主要目的。
一是要我们懂得什么是团队。
团队的力量是强大的,再困难的问题大家在一起讨论最终肯定会有完美的答案!
二是巩固和正确运用我们平时所学的知识。
平时上课没有注意到的问题在这次设计中完全暴露出来,一些薄弱知识点也都一一加以巩固。
书本上的知识只是理论知识通过课程设计我们可以吧理论知识与实际生活相连接,把理论的东西灵活的运用到实际生活当中。
在设计的同时达到一箭双雕的作用。
参考文献
1.张海潘著.软件工程导论(第五版).北京:
清华大学出版社,2008
2.谭云杰等编著.《大象--ThinkinginUML》.中国水利水电出版社,2009
3.邵维忠,杨芙清著.面向对象的系统分析.北京:
清华大学出版社,1998
4.张友生等编著.《软件体系结构》.北京:
清华大学出版社,2006
5.吴洁明,袁山龙编著.软件工程应用实践教程.北京:
清华大学出版社,2003
6.UML系统分析设计王强,贾素玲,许珂,韩小汀高等教育出版社2005-4
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 图书馆 管理 系统
![提示](https://static.bdocx.com/images/bang_tan.gif)