图书馆管理系统.docx
- 文档编号:11341343
- 上传时间:2023-02-28
- 格式:DOCX
- 页数:34
- 大小:433.33KB
图书馆管理系统.docx
《图书馆管理系统.docx》由会员分享,可在线阅读,更多相关《图书馆管理系统.docx(34页珍藏版)》请在冰豆网上搜索。
图书馆管理系统
课程设计报告
学生姓名:
学号:
学院:
班级:
题目:
图书馆管理系统
指导教师:
王欣职称:
教授
2011年7月15日
1.选题背景
随着社会的进步和计算机技术的发展,特别是微型计算机的大范围普及,现在应用在大中型企业的信息管理系统中,几乎都包括了工资管理模块。
有些环境中是有大型ERP软件中的一个模块引进的,有些作为企业的财务系统的一部分。
计算机处理的数据量不断增加。
文件管理系统采用的一次最多存取一个记录的访问方式,以及在不同文件之间缺乏相互联系的结构,越来越不能适应管理大量数据的需要,于是数据库管理系统便应运而生。
有了数据库我们便能方便快捷的对数据进行读取、存取,并维护数据库的数据。
面向对象的软件工程,同传统的面向过程的软件工程相比,在需求的获取、系统分析、设计和实现方面都有着很大的区别。
UML是OOA和OOD的常用工具。
使用UML来构建软件的面向对象的软件工程的过程,就是一个对系统进行不断精化的建模的过程。
这些模型包括用例模型、分析模型、设计模型等。
信息社会的高科技,商品经济的高效益,使对计算机的应用得到普及。
计算机虽然与人类的关系越来越密切,但还有人由于计算机操作的不便而使用手工进行管理。
为了适应现代社会高度强烈的时间观念,宾馆管理系统软件为管理人员带来了极大的方便。
通过操作手册,使用者可以了解本软件的基本工作原理。
操作人员只需输入一些简单的汉子,数字,即可达到自己的目标。
应用软件系统,就其本质来说,是使用计算机对现实世界进行的数字化模拟。
应用软件的制造过程,按照UML的方法,就是建立这一些模型的过程。
关于这个图书馆系统,基本的需求比较简单,就是允许借阅者可以在图书馆借阅和归还图书,另外,也可以通过网络或者图书馆的终端来查询和预订图书。
当然,图书馆管理员也可以对图书和借阅者进行管理。
为了简化系统,我们没有把图书馆中的人员作细分。
2.图书馆管理系统需求分析
2.1图书馆管理系统的需求陈述
在图书管理系统中,管理员要为每个读者建立借阅账户,并给读者发放不同类别的借阅卡(借阅卡可提供卡号、读者姓名),账户内存储读者的个人信息和借阅记录信息。
持有借阅卡的读者可以通过管理员(作为读者的代理人与系统交互)借阅、归还图书,不同类别的读者可借阅图书的范围、数量和期限不同,可通过互联网或图书馆内查询终端查询图书信息和个人借阅情况,以及续借图书(系统审核符合续借条件)。
借阅图书时,先输入读者的借阅卡号,系统验证借阅卡的有效性和读者是否可继续借阅图书,无效则提示其原因,有效则显示读者的基本信息(包括照片),供管理员人工核对。
然后输入要借阅的书号,系统查阅图书信息数据库,显示图书的基本信息,供管理员人工核对。
最后提交借阅请求,若被系统接受则存储借阅纪录,并修改可借阅图书的数量。
归还图书时,输入读者借阅卡号和图书号(或丢失标记号),系统验证是否有此借阅纪录以及是否超期借阅,无则提示,有则显示读者和图书的基本信息供管理员人工审核。
图书管理员定期或不定期对图书信息进行入库、修改、删除等图书信息管理以及注销(不外借),书目的维护,都需要及时。
这样的修改,以便于后期系统管理员对图书馆图书数据库进行操作。
2.2需求分析
2.2.1功能需求
对图书管理系统的域描述如下:
在图书管理系统中,要为每一个借阅者建立一个账户,并发放借阅卡(此卡可以提供借阅卡号、借阅者名)给借阅者,其中账户中存储借阅者的个人信息、借阅信息。
持有借阅卡的的借阅者可以借阅书籍、返还书籍、查询书籍信息,所有这些操作都是通过图书管理员进行的,也就是说,借阅者不直接与系统交互,而是让图书管理员充当借阅者的代理与系统交互。
借阅书刊时,需要输入所借阅的书刊名、书刊的ISBN/ISSN号,然后输入借阅者的借阅卡号(学生学号、教师职工号)和借阅者名,完成后提交所填表格,系统验证借阅者是否有效(在系统中是否存在账户),若有效,借阅请求被接受,系统查询数据库系统,看借阅者要求借阅的书看是否存在,若存在,则借阅者可以借出书刊,并在系统中建立存储借阅记录。
借阅者还书后,删除关于所还书刊的借阅记录。
另外,为了简化系统,暂时不考虑书籍的丢失和预定情况。
对上述图书管理系统的域描述进行分析,可以获得如下的功能性需求:
1.借阅者持有借阅卡(借阅卡包含借阅者名和借阅卡号);
2.图书管理员代理借阅者借书;
3.图书管理员代理借阅者还书;
4.图书管理员可以创建新的借阅者账户;
5.图书管理员可以修改借阅者的账户信息;
6.图书管理员可以删除已存在的借阅者账户;
7.图书管理员可以添加新书籍种类;
8.图书管理员可以修改书籍种类信息;
9.图书管理员可以删除系统中的书籍种类;
10.图书管理员可以在系统中添加书目信息;
11.图书管理员可以编辑书目信息;
12.图书管理员可以删除书目信息。
注:
“书籍种类”和“书目信息”是两个不同的概念“书籍种类”代表了书籍的种类,它不仅包括书刊名,还包括ISBN/ISSN号等信息,他出现在书籍目录中;“书目信息”则指书籍的信息,即图书信息。
此外,第一部分提到的用户含借阅者和管理员,但侧重指借阅者。
系统功能结构图如图2.1所示。
2.1系统功能结构图
2.2.2性能需求
本系统主要实现对图书馆信息的管理,主要功能为管理有关读者,书籍,借阅的信息等。
本系统结构分为读者信息管理模块,书籍信息管理模块,借阅信息管理模块。
读者信息管理部分有两方面的功能,可以浏览读者的信息,可以对读者信息进行分类。
书籍信息管理可以浏览书籍的信息,可以对书籍信息分类。
借阅信息管理可以显示当前数据库中书籍借阅情况,可以对借阅信息进行维护。
本系统使用UML建模技术,对图书管理系统进行分析与设计,使开发的系统方面用户的使用和维护,根据图书管理工作性质和环境决定了本系统在性能方面要达到以下要求。
1.系统可扩充性要求
要保证所整合的图书管理系统的可扩充性,对不同级别的用户要求的层次和模块,可灵活地进行定制。
使得将来易于与当前系统实现互连互通,为用户提供全方位,高质量和高效率服务。
2.界面友好性要求
系统提供统一的操作界面和方式。
要求操作界面美观大方、布局合理、功能完善,对于初级用户容易上手。
3.服务个性化要求
系统针对不同级别的用户提供方便的界面形式,以满足用户需求。
如图书管理员登录系统之后,可以看到系统所有的内容。
用户登录后,可以看到最关心的信息,对于有些不必要的细节,系统不会显示。
4.可管理性要求
系统涉及面较广,系统应提供对管理内容的分级分类管理和维护、审批服务事项、维护工作流定制与监控、用户信息维护、系统配置和管理、故障诊断等功能。
2.3系统需求建模
2.3.1确定参与者
在对现行住院管理系统的分析过程中,在我们获取了执行者之后,我们就对每个执行者提出以下问题以获取用例。
1.执行者要求系统提供哪些功能(执行者需要做什么)。
2.执行者需要读、产生、删除、修改或存储的信息有哪些类型。
3.必须提醒执行者的系统事件有哪些,或者执行者必须提醒系统的事件有哪些,怎样把这些事件表示成用例中的功能。
4.为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现。
除了以上考虑到的问题之外,我们还考虑了一些不针对具体执行者问题(即针对整个系统的问题),以使自己的分析结果更加准确。
1.系统需要何种输入输出,输入从何处来,输出到何处。
2.当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题。
通过对系统需求的分析,可以确定系统中有两个参与者,即借阅者和管理员。
1.借阅者
描述:
借阅者可以借阅、归还书籍。
示例:
持有借阅卡的任何人或组织。
2.管理员
描述:
管理员维护系统,他可以增加、修改、删除借阅者的信息;可以增加、修改、删除书目信息,即维护书目目录。
示例:
系统管理员、图书管理员
2.3.2确定用例
根据调研,我们认为,由于目前还没有一个图书馆管理系统的行业标准,而实施图书馆管理系统,又是发展趋势,因此,各高校图书馆只能根据自己的情况选择适合自己的图书馆管理模式,就目前来说没有哪一所搞笑的图书馆管理系统是适合其它所有高校图书馆的,也就是说我们必须结合本高校的情况设计适合自己的图书馆管理系统。
在系统的设计和开发中,以下问题是应该注意的:
新系统应该尽可能地解决现有系统存在的问题。
例如:
减少手工操作和重复劳动,提高计算机管理程度,尽可能的杜绝漏费现象,方便查询、统计,方便数据的管理和备份等等。
系统应具备较好的可维护性,较长的生存期,避免较短的时间内被推倒重来的情况发生。
根据开发者和客户的需求分析后,可以把系统功能分为三个大的用例模块:
1.查询模块
包括:
借阅者查询和管理员查询。
2.用户管理模块
包括:
增加及删除用户信息以及修改用户信息。
3.书籍管理模块
包括:
增加及删除书目信息以及修改书目信息。
2.3.3系统用例建模
针对图书馆管理系统的流程分析,我们采用的是面向对象的分析方法(OOA)。
使用用例图来描述参与者与外部用户所能观察到的系统功能的模型图,在此模型中列出了系统中的用例和参与者,并显示哪个参与者参与了哪个用例的执行。
在识别出参与者和用例后,要想建立用例图,还需要识别出它们之间的关系。
借阅书刊、预定书刊、取消预定这些动作是由借阅者执行的,但是对于软件系统来说,这些操作是由图书管理员与系统进行交互完成的,也即用例借书、还书、预定书刊、取消预定实际上是与图书管理员交互的,在参与者“借阅者”和参与者“图书管理员”之间存在着依赖关系,即“借阅者”借助“图书管理员”完成这些工作。
用例“维护借阅者信息”、“维护书刊信息”也是与参与者“图书管理员”交互,为了系统的安全性,系统还需要提供进行身份验证的功能,以确保只有具有权限的“图书管理员”才可以使用系统的功能,所以“图书管理员”必须与用例“登录”交互,即“图书管理员”在使用系统前,要使用用户名和密码进行登录,系统验证用户的密码正确后,用户才可以执行进一步的操作。
用ROSE软件制作出的用例图,如图2.2所示。
图2.2系统的用例图
2.3.4用例描述
在上面,已经识别出了系统的两位参与者,经过对需求的进一步分析,可以确定系统中有如下用例存在。
1.借书请求
概述:
该用例说明用户如何在图书馆借阅书籍,通过登录服务器预约,续借等功能。
前置条件:
该用户未出现借书超期。
后置条件:
系统记录用户借阅记录,并且对系统中的书目信息进行修改。
实现过程:
(1).图书管理员得到借阅者的图书证;
(2).系统扫描图书证的借阅者信息,并且将其姓名,班级,学号,借书号,借阅日期,归还日期进行记录;
在上面的实现过程中,借阅者的借阅信息和图书馆的图书信息已经进行了记录,在还书或者进行书目查询时,只需直接调用即可。
2.还书请求
概述:
该用例说明在借阅者归还图书时,系统管理员对读者信息,图书馆书目信息的操作。
前置条件:
借阅者的借阅信息中未出现逾期现象,或者为出现欠费记录。
后置条件:
图书入库,系统自动的修改书目信息。
实现过程(事件流):
(1).图书归还,图书管理员得到借阅图书,对其条形码进行扫描。
(2).修改借阅者的借阅记录,更改图书馆书目信息,包括读者姓名,班级,学号,借书号,借阅日期,归还日期进行记录。
(3).出现逾期或者图书丢失时,收取一定数额的罚金。
3.书籍管理
概述:
该用例说明如何对图书进行管理,包括图书的编目,图书的破损维修。
前置条件:
图书已经入库。
后置条件:
分配到各个典藏馆,进行正常的流通。
实现过程(事件流):
(1).查看图书的借阅状态
(2).分配图书应该进入哪个典藏馆
(5).系统可根据图书的典藏位置,对图书进行记录,包括图书号、图书名称、图书作者、出版日期等。
4.用户管理
概述:
系统管理员对于借阅者信息进行输入,系统对其记录,在之后的借书、还书过程中直接对用户的信息进行操作。
前置条件:
系统中已近有了借阅者信息。
后置条件:
对借阅者的信息进行查询、修改。
实现过程:
(1).借阅者在图书馆对其个人信息进行录入。
(2).借书、还书时系统都能够对借阅者的信息进行操作。
5.查询
概述:
系统管理员对于借阅者信息进行输入,系统对其记录,在之后的借书、还书过程中直接对用户的信息进行操作。
前置条件:
系统中已近有了借阅者信息。
后置条件:
对借阅者的信息进行查询、修改。
实现过程:
读者,系统管理员,图书管理员通过数据库的操作对系统中的信息进行查询操作。
6.维护借阅者信息
前置条件:
在这个用例开始前,图书管理员必须登录到系统中。
后置条件:
如果这个用例成功,系统添加、修改或删除借阅者信息。
否则,系统的状态没有变化。
实现过程:
如果借阅者已存在,借阅者被识别,提供借阅者信息,如果所选活动是删除借阅者。
从系统中删除借阅者的信息,以及借阅者的预订记录,如果所选活动室修改借阅者,修改相应的信息,更新系统中借阅者的信息,如果借阅者不存在,所选活动是添加借阅者,输入借阅者信息;
7.维护书刊信息
前置条件:
在这个用例开始前,图书管理员必须登录到系统中。
后置条件:
如果这个用例成功,系统添加、修改或删除书刊种类信息。
否则,系统的状态没有变化。
实现过程:
如果书刊已存在,书刊被识别,提供书刊信息,如果所选活动是删除书刊信息,从系统中删除书刊信息,以及借阅者的预订记录,如果所选活动是修改书刊信息,修改相应的信息,新系统中书刊信息,如果书刊不存在,所选活动是添加书刊信息,输入书刊信息,系统存储书刊信息。
8.续借
前置条件:
无。
后置条件:
如果这个用例成功,参与者可以启动系统并使用系统所提供的功能;反之,系统的状态不变。
实现过程:
(1)当用户希望登录到系统中时,用例启动,系统提示用户输入用户名和密码;用户输入用户名和密码;
(2)系统验证输入的用户名和密码,若正确,则用户登录到系统中;如果用户输入不正确的用户名和密码:
系统显示错误信息;用户可以选择返回到起始点,重新输入正确的用户名和密码;或取消登录,用例结束。
3.图书馆管理系统系统分析
3.1系统用例建模
在进行用例建模之前,我们首先了解到用例模型描述的是外部执行者(Actor)所理解的系统功能。
它主要用于需求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。
它的重要作用对于我们住院管理系统的分析和设计主要体现在以下几个方面:
首先,它描述了待开发系统的功能需求;
其次,它将系统看作黑盒,从外部执行者的角度来理解系统;
再次,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和UML的各个模型。
从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。
在UML中,用例被定义成系统执行的一系列动作,动作执行的结果能被指定执行者察觉到。
几乎在任何情况下都会使用用例。
用例用来获取需求,规划和控制项目。
用例的获取是需求分析阶段的主要任务之一,而且是首先要做的工作。
大部分用例将在项目的需求分析阶段产生,并且随着工作的深入会发现更多的用例,这些都应及时增添到已有的用例集中。
经过对系统需求陈述的分析,可以看出系统的主要参与者有3类:
读者(借阅者)、图书管理员、系统管理员
1.借阅者参与的用例图
(1)功能描述:
书籍查询:
借阅者用过网络查询自己想找的书籍信息,该数据的查询主要是查看借阅者的借阅信息,图书的借阅状态;
书籍预定:
借阅这要借阅的书籍处于借出状态是,借阅者可以预约该书籍,当借阅者要借阅的书籍归还时,读者便可以对该书籍进行借阅。
如果读者想要取消预约操作,也可以在图书馆的客户终端上进行取消的操作;
查询借阅信息:
借阅者查询自己所借书籍的信息,借阅者可以根据自己的借阅信息方便的进行操作,以免出现逾期现象;
续借书籍:
借阅者在无人预订该书的情况下,可以续借该书。
在系统的客户终端上即可以进行这些操作,但是必须保证客户的信息无误,这部分的操作对系统数据库处理冗余要求很高;
检查书籍:
检查书籍是否被预定,这步的操作主要是为图书借阅和图书续借这两个步骤,进行相应的基础设置;
登录:
用户可以用自己的帐号和密码登录系统,并且在其中进行系统授权的操作,例如图书信息查询,预约操作,续借信息等;
(2)用例图:
图3.1借阅者参与的用例图
2.图书馆管理员处理借书、还书等的用例图
(1)功能描述:
登录:
图书管理员登录系统,对其中的图书信息,借阅者信息,进行添加、修改、删除、更新等操作;
还书处理:
读者将图书归还到图书馆管理员处,管理员对归还的书籍进行处理,将书籍的系统信息进行更行,并将图书归还到图书架相应的地位,并且对图书的借阅状态进行修改,以便预约的读者可以方便的借到图书;
罚款:
还书时,管理员对图书进行扫描,并且检查图书。
核对借阅者的借阅信息,对逾期、破损的图书收取罚金;
检验:
查看用户信息,检查读者的图书是否超期,如果没有超期。
图书管理员将图书归还指图书架,并且对借阅者信息进行相应的修改。
如果超期则对超期的图书进行相应的罚款;
删除:
当图书的节约状态处于未借出状态时,读者将图书借出,管理员删除书籍预定信息。
(2)用例图:
图3.2图书馆管理员处理借书、还书等的用例图
3.系统管理进行系统维护的用例图
(1)功能描述:
查询借阅信息:
系统管理员可以查询借阅者的基本信息和借阅信息,确定是否读者可以借的想要的图书,是否对其归还的图书进行罚款,是否读者有预约操作,是否图书处于借出或者未借出状态等操作;
查询书籍信息:
系统管理员可以查询书库里的书籍信息;
增加书目:
系统管理员可以向书库中增加书目;
删除或更新书目:
书库中的图书发生变化的时候,系统管理员可以从书库中删除或者更新书目;
增加书籍:
图书馆会定期的更新图书,期间典藏馆分得相应的图书时,系统管理员可以从书库中增加书籍,这样,系统中的图书信息就会发生变化,读者可借阅的图书数目也会增加;
添加借阅者账户:
对于新加的借阅者,包括老师,学生,系统管理员可以向系统中添加借阅者账户,包括读者的编号、姓名、专业等具体信息;
(2)用例图
图3.3系统管理进行系统维护的用例图
3.2静态结构模型
进一步分析系统需求,发现类以及类之间的联系,确定它们的静态结构和动态行为,是面向对象分析的基本任务。
系统的静态结构模型主要用类图来描述的:
3.2.1类的识别
我们对需求陈述进行初步处理之后,经过非正式分析得出图书馆管理系统的初始类为:
图书管理系统、管理员、读者、借阅账户、借阅卡、账户、个人信息、借阅记录、互联网、图书馆、查询终端、续借图书、借阅卡号、基本信息、人工核对、图书信息数据库、图书号、图书信息管理。
对候选类进行严格的考察筛选,去掉不正确的或不必要的,仅保留确实应该记录其信息或需要其提供服务的那些对象。
删除不正确的或不必要的类与对象,根据冗余标准,读者、借阅卡号、借阅账户、个人信息、借阅记录都描述相同的类,图书号与图书信息,应保留在此问题域中最富于描述力的名称,因此,应该去掉读者卡号、个人信息等冗余的类,仅保留读者信息、管理员、图书管理系统这三个类。
综上所述,在住院管理系统中,经过初步筛选,剩下下列类与对象:
图书管理系统、管理员、读者、个人信息、借阅账户、图书信息数据库、查询终端。
通过对系统进行需求分析后,就可以识别出在该系统中存在的对象。
从前述的系统需求描述中可以找到以下对象类:
借阅者、书籍、管理员(图书管理员、系统管理员)。
3.2.2类的关联分析
在上文中我们将待开发的图书馆管理系统的对象和类识别了出来,随后,我们通过提取动词词组初步得出它们之间的关联,通过分析前文中的需求陈述,我们找出了陈述中隐含的关联,经过分析之后,初步确定出下列关联:
·系统建立读者信息
·图书管理员对图书进行典藏分配
·系统管理员对图书的信息进行记录
·当借阅者借阅图书时,系统管理员对图书进行扫描,系统自动对图书的信息进行记录
·图书处于未借出状态时,读者可以借阅图书,读者也可登陆图书馆管理终端,对图书进行预约
·读者归还图书时,图书管理员读图书进行扫描,系统提取读者信息,并对其借阅信息进行修改
·系统管理读数据书目,书籍目录进行修改,更新等操作
由于以上关联只是初步分析得出,并不合理,需要进一步的筛选初步得出的关联,去掉不正确的或不必要的关联,进一步完善,才能得到正确而合理的关联。
经过筛选之后,得到的关联如下:
·读者通过图书管理员对图书进行借阅,系统修改读者借阅信息、修改图书的借阅状态
·读者借阅的图书如果处于借出状态,则登陆图书馆客户终端,对图书进行预订,系统对其操作进行记录
·读者归还图书,系统更新借阅信息,修改图书的借阅状态
·系统管理员对图书目录,用户信息可以进行修改、删除、更新
3.2.3类的属性描述
属性是对象的性质,通过对象类和结构有更深入,更具体的认识。
一般来说确定属性的过程包括分析和选择两个步骤。
属性的确定既与问题有关,也和目标系统的任务有关。
应该仅考虑与具体应用直接相关的属性,不要考虑那些超出所要解决的问题范围的属性。
在分析过程中应该首先找出最重要的属性,以后在逐渐把其余属性添加进去。
此次分析过程中,我们在分析阶段没有考虑那些纯粹用于实现的属性。
只是在最后认真考察了经初步分析而确定下来的那些属性,从中删掉了那些不正确的或不必要的属性。
部分对象类的属性描述如下:
借阅者:
学生——学号、姓名、学院、班级、图书证编号
教师——职工号、姓名、单位
书籍——书号、书名、作者、类型、价格
管理员——用户名、密码
3.2.4类图的构建
抽象出系统中的类后,确定并细化这些类的属性及操作,建立每个类的图形,通过这些图形对每一个类的属性和操作进行说明,如图3.4所示。
图3.4系统类图
借阅者包含学生和教师。
学生的属性有学号、姓名和单位,教师的属性有职工号、姓名和单位。
借阅者可以借书、还书和查询。
书籍包含很多种类,这里大致分为理工和文史类。
书籍的属性有书号、书名、作者、类型和价格。
书籍是整个系统的主要部分,借阅者可以借阅及归还图书(学生可以借1-5本,教师可以借1-10本,这里用1...n表示借阅书籍数),管理员则管理书籍、维护书籍信息。
管理员(可以有多个管理员,这里用m表示管理员个数)的属性主要是登录系统的用户名及密码。
管理员的作用是书籍管理和用户管理,即增加、删除和修改信息。
3.3系统动态模型
系统的动态行为模型可以有交互作用图(时序图和通讯图)、状态图、活动图来描述。
本设计选用时序图描述用例的主要场景,用状态图描述对象的动态行为。
3.3.1系统执行顺序分析
为了实现一个合适的系统,第一步应对现行图书馆管理系统情况进行调研分析,掌握现有的工作模式和工作流程。
经过对现行系统的调查和分析,图书馆当前的业务主要涉及两大块,一块是借阅业务,另一块是图书馆维护业务。
本文研究的是图书馆管理系统,根据调查,描述系统用例的主要场景的时序图如图3.5所示。
图3.5借书时序图
管理员每天工作时先登录系统,再进行挂机等待借阅者操作。
借阅者借书时,先出示借阅卡。
管理员扫描借阅卡,验证借阅者身份,系统读取相应信息并显示借阅者信息。
此后,管理员扫描借阅者要借阅的书籍,增加书目信息。
系统对应显示书目信息后,借阅书籍成功,书籍借出。
借阅者续借时,步骤一直,故省略续借时的情况。
图3.6还书时序图
逾期处理是还书时的扩展动作,因此在这里一起考虑。
还书时扫描图书,若显示正常,则管理
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 图书馆 管理 系统
![提示](https://static.bdocx.com/images/bang_tan.gif)