图书馆借还书管理系统分析与设计(共31页).doc
-
资源ID:14031115
资源大小:419.50KB
全文页数:31页
- 资源格式: DOC
下载积分:20金币
快捷下载
会员登录下载
微信登录下载
三方登录下载:
微信扫一扫登录
友情提示
2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
|
图书馆借还书管理系统分析与设计(共31页).doc
精选优质文档-倾情为你奉上课 程 设 计 报 告学生姓名: 学 院:班 级:题 目:图书馆借还书管理系统分析与设计指导教师: 职称: 2011年 7 月15日目 录专心-专注-专业1.选题背景当今时代是飞速发展的信息时代。在各行各业中离不开信息处理,这正是计算机被广泛应用于信息管理系统的环境。计算机的最大好处在于利用它能够进行信息管理。使用计算机进行信息控制,不仅提高了工作效率,而且大大的提高了其安全性。 尤其对于复杂的信息管理,计算机能够充分发挥它的优越性。计算机进行信息管理与信息管理系统的开发密切相关,系统的开发是系统管理的前提。本系统就是为了管理好图书馆信息而设计的。图书馆作为一种信息资源的集散地,图书和用户借阅资料繁多,包含很多的信息数据的管理。根据调查得知,他们以前对信息管理的主要方式是基于文本、表格等纸介质的手工处理,对于图书借阅情况(如借书天数、超过限定借书时间的天数)的统计和核实等往往采用对借书卡的人工检查进行,对借阅者的借阅权限、以及借阅天数等用人工计算、手抄进行。数据信息处理工作量大,容易出错;由于数据繁多,容易丢失,且不易查找。总的来说,缺乏系统,规范的信息管理手段。尽管有的图书馆有计算机,但是尚未用于信息管理,没有发挥它的效力,资源闲置比较突出,这就是管理信息系统的开发的基本环境。 数据处理手工操作,工作量大,出错率高,出错后不易更改。图书馆采取手工方式对图书借阅情况进行人工管理,由于信息比较多,图书借阅信息的管理工作混乱而又复杂;一般借阅情况是记录在借书证上,图书的数目和内容记录在文件中,图书馆的工作人员和管理员也只是当时对它比较清楚,时间一长,如再要进行查询,就得在众多的资料中翻阅、查找了,造成查询费时、费力。 基于这此问题,我认为有必要建立一个图书管理系统,使图书管理工作规范化,系统化,程序化,避免图书管理的随意性,提高信息处理的速度和准确性,能够及时、准确、有效的查询和修改图书情况。随着科学技术的高速发展,我们已步入数字化、网络化的时代。图书馆是学校的文献信息中心,是为全校教学和科学研究服务的学术性机构,是学校信息化的重要基地。图书馆的工作是学校教学和科学研究工作的重要组成部分,是全校师生学习和研究的重要场所。为了更好地适应这种网络数字化信息的环境,一种成功的跟踪最新技术,充分利用软硬件资源,扎根于准、新、全数字资源的"图书馆管理信息系统"已孕育而生。 另外,由于图书馆陈旧的管理手段给读者和图书馆管理员带来的很多操作上的不方便,同时为了提高工作效率、服务质量和管理水平,并使图书馆管理人员从繁琐的工作中解脱出来,从而使我们下定决心开发该系统。面向对象的软件工程,同传统的面向过程的软件工程相比,在需求的获取、系统分析、设计和实现方面都有着很大的区别。UML是OOA和OOD的常用工具。使用UML来构建软件的面向对象的软件工程的过程,就是一个对系统进行不断精化的建模的过程。应用软件系统,就其本质来说,是使用计算机对现实世界进行的数字化模拟。应用软件的制造过程,按照UML的方法,就是建立这一些模型的过程。关于这个图书馆借还书系统,基本的需求比较简单,就是允许借阅者可以在图书馆借阅和归还图书,另外,也可以通过网络或者图书馆的终端来查询和预订图书。当然,图书馆管理员也可以对图书和借阅者进行管理。2. 图书馆借还书管理系统需求分析2.1图书馆借还书管理系统需求陈述作为图书馆借还书管理系统,需要完成图书借阅、图书归还、图书预定及取消预订等功能,系统开发的总目标是:系统开发的总目标是实现内部图书借阅管理的系统化、规范化和自动化。能够对图书进行注册登记,也就是将图书的基本信息(如:书的编号、书名、作者、入库时间、出版时间等)预先存入数据库中,供以后检索。下面陈述对图书馆管理系统的需求。在图书管理系统中,要为每一个借阅者建立一个账户,并给借阅者发放借阅证(借阅者可以提供借阅证号、借阅者名),账户中存储借阅者的个人信息、借阅信息及预订信息等。持有借阅证的借阅者可以借阅图书、返还图书、查询图书信息、预定图书或取消预定图书,但其中借阅图书、返还图书是通过图书管理员代理进行的,也就是借阅者不直接与系统交互,而是图书管理员充当借阅者的代理与系统交互,在借阅图书时,需要扫描借阅者的借书证及所要借阅的图书条形码,系统验证借阅者是否有效(在系统中存在该账户或满足借书要求),若有效,借阅请求被接受,系统查询数据库系统,看借阅者所借阅的图书是否存在,若存在,则借阅者可借出图书,建立并在系统中存储借阅记录。借阅者还书后,删除关于所还书刊的借阅记录。如果借阅者所借的图书已被借出,借阅者还可预订该图书;系统还提供相关的安全性认证。2.2图书馆借还书管理系统需求分析2.2.1系统功能需求分析对上述图书馆借还书管理系统的问题描述进行分析,可以获得如下功能性需求:(1)借阅者可以通过网络查询书籍信息和预定书籍。(2)借阅者能够节约书籍和还书。(3) 图书管理员能够处理借阅者的借阅和还书请求。(4)系统管理员可以对系统的数据进行维护,如增加、删除和更新数目,增加、删除和更新借阅者账户,增加和删除书籍。满足上述需求的系统主要包括一下几个模块。(1)基本数据维护模块。基本数据维护模块提供了使用者录入、修改并维护基本数据的途径。例如对借阅者的、书籍的各项信息的更新与修改。(2)基本业务模块。基本业务模块主要用于实现用户借书与还书的管理,例如借阅者可以登录系统预订书籍,图书管理员可以取消书籍的预订,当然还可以进行借书、还书等操作。(3)数据库管理模块。在系统中,所有书籍的信息以及借阅者的账户信息都要统一管理,书籍的借阅情况、预订情况也要进行详细的记录,所以要用统一的数据库平台进行管理。(4)信息查询模块。信息查询模块主要用于查询书籍的信息和借阅者的信息。2.2.2性能需求本系统使用UML建模技术,对图书管理系统进行分析与设计,使开发的系统方便用户的使用和维护,根据图书管理工作性质和环境决定了本系统在性能方面要达到以下要求。1.在性能方面,要求系统的查询和更新时间不超过1秒。2.系统最小寿命:系统应该在无重大改动的条件下正常运行5年以上。3.设备要求:计算机稳定性良好,整套系统经济实惠。4.在使用上:要求系统易理解,易学习,易操作。5.在安全上:要求系统安全可靠,容错,易恢复。6.在数据集上:要求用统一的数据库实现数据的完整性和实时性。7.在可为维护性上:要求系统可修改,可测试,可扩充,可移植。2.3系统需求建模根据对系统需求建模的分析可知几乎在任何情况下都需要使用用例,通过用例可以获取用户需求,规划和控制图书馆借还书管理系统项目。获取用例是需求分析阶段的主要工作之一,而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生而且随着开发工作的深入还会发现更多用例,这些新发现的用例都应及时补充进已有的用例集中。用例集中的每个用例都是对系统的一个潜在的需求。一个用例模型由若干幅用例图组成。创建用例模型的工作包括:定义系统、寻找参与者和用例、描述用例、定义用例之间的关系、确定模型,其中寻找参与者和用例是关键。2.3.1确定参与者通过对系统需求的分析,可以确定系统中有两个参与者:借阅者、图书管理员。参与者的描述如下。1.借阅者 描述:借阅者可以借阅、预定、归还图书,还可以取消预定。 示例:持有借阅证的人或组织。2.图书管理员 描述:图书管理员描述系统,可以创建、修改、删除借阅者的信息,可以添加、编辑、删除图书信息,即维护目录。 示例:图书管理员。3.系统维护人员 描述:系统维护人员可以进行对系统的一系列维护活动。 示例:系统维护人员。2.3.2确定用例前面已经识别出了参与者,通过对需求的进一步分析,可以确定系统中有如下用例存在。从用例图中我们可以看出管理员和读者之间对本系统所具有的用例。管理员所包含的用例有:(1) 登录系统:管理员可以通过登录该系统进行各项功能的操作(2) 书籍管理:包括对书籍的增删改等。(3) 书籍借阅管理:包括借书、还书、预订、书籍逾期处理和书籍丢失处理等等。(4) 读者管理:包含对读者的增删改等操作。读者所包含的用例有:(1) 登录系统(2) 借书:进行借书业务。(3) 还书:读者具有的还书业务。(4) 查询:包含对个人信息和书籍信息的查询业务(5) 预订:读者对书籍的预订业务。(6) 逾期处理:就是书籍过期后的缴纳罚金等。(7) 书籍丢失处理:对书籍丢失后的不同措施进行处理。2.3.3系统用例建模在识别出参与者和用例后,要想建立用例图,还需要识别出它们之间的关系。借阅图书、预定图书、取消预定这些动作是由借阅者执行的,但是对于软件系统来说,这些操作是由图书管理员与系统进行交互完成的,也即用例借书、还书、预定图书、取消预定实际上是与图书管理员交互的,在参与者“借阅者”和参与者“图书管理员”之间存在着依赖关系,即“借阅者”借助“图书管理员”完成这些工作。用例“维护借阅者信息”、“维护图书信息”也是与参与者“图书管理员”交互,为了系统的安全性,系统还需要提供进行身份验证的功能,以确保只有具有权限的“图书管理员”才可以使用系统的功能,所以“图书管理员”必须与用例“登录”交互,即“图书管理员”在使用系统前,要使用用户名和密码进行登录,系统验证用户的密码正确后,用户才可以执行进一步的操作。其中图书馆借还书管理信息系统用例图如图2.1所示:2.3.4 用例描述 用例可以用事件流来描述,用例的事件流是对完成用例行为所需的事件的描述。事件流描述了系统应该做什么,而不是描述系统应该怎么做,也就是说,事件流描述是用域语言描述的,而不是用实现语言描述的。图书馆借还书管理系统的用例的事件流描述如下:1.名称:借阅图书1.1.前置条件:在这个用例开始前,图书管理员必须登录到系统中。1.2后置条件:如果这个用例成功,在系统中建立并存储借阅记录,如果必要还要删除预订记录。否则,系统的状态没有变化。1.3扩充点:没有。图2.1图书馆借还书管理系统用例图1.4事件流1.4.1基流当借阅者从图书馆借阅图书时,用例启动。如果图书管理员选择:“借书”,则直接借阅图书。如果所借图书是经过预订的,则执行预订借阅图书。1.4.2分支流直接借阅图书(1) 提供书刊种类、借阅者信息。(2) 检索书刊种类。(3) 确定所借书刊是否都以借出。(4) 检索借阅者。(5) 图书馆将图书借给借阅者。(6) 创建借阅记录。(7) 存储借阅记录。通过预订借阅图书(1) 提供图书种类、借阅者信息。(2) 检索图书种类。(3) 检索借阅者。(4) 确定该类图书是否可以获得。(5) 将图书发给借阅者。(6) 创建借阅记录。(7) 存储借阅记录。(8) 删除借阅记录。2返还图书2.1. 前置条件在这个用例开始之前,图书管理员必须登录到系统中。2.2后置条件如果这个用例成功,系统删除借阅记录。否则,系统的状态没有变化。2.3扩充点:没有。2.4.事件流2.4.1.基流当借阅者返还所借的图书时,用例启动。(1) 提供所返还图书信息。(2) 检索图书(3) 检索图书的借阅信息。(4) 删除借阅信息3.预定图书3.1.前置条件在这个用例开始前,图书管理员必须登录到系统中。3.2.后置条件如果这个用例成功,系统建立预定记录。否则,系统的状态没有变化。3.3.扩充点:没有。3.4.事件流3.4.1基流当图书管理员为借阅者预订图书时,用例启动。(1) 提供图书种类、借阅者信息。(2) 检索图书种类。(3) 检索借阅者。(4) 系统接收预订。(5) 将预定记录存储在系统中。4.取消预定4.1.前置条件在这个用例之前,图书管理员必须登录到系统中。4.2.后置条件如果这个用例成功,系统删除预定记录。否则,系统没有变化。4.3.扩充点:没有。4.4.事件流4.4.1.基流(1)提供所预定的图书种类、借阅者信息。(2)检索所预定图书种类。(3)检索借阅者。(4)从系统中删除预定信息。5.维护图书信息5.1.前置条件在这个用例使用之前,图书管理员必须登录到系统中。5.2.后置条件如果这个用例成功,系统添加、修改或图书种类。否则,系统没有变化。5.3.扩充点:没有。5.4.事件流5.4.1.基流(1)添加图书信息。(2)删除图书信息。(3)修改图书信息。6.登录6.1.前置条件没有。6.2.后置条件如果用例成功,参与者可以启动系统并使用所提供的功能。反之,系统的状态不变。6.3.扩充点:没有。6.4.事件流6.4.1.基流当用户希望登录到系统中,用例启动。(1) 系统提示用户输入用户名和密码。(2) 用户输入用户名和密码。(3) 系统验证输入的用户名和密码,若正确,则用户登录到系统中。3.图书馆借还书管理系统分析3.1系统用例建模用例图中的每个用例都是对系统的一个潜在的需求。图书管理系统的用例建模是有以下几幅用例图组成的,包括借阅者请求服务的用例图,图书馆管理员处理借书、还书等的用例图,系统管理员进行系统维护的用例图一、借阅者请求服务的用例(1)查询信息(2)书籍预约(3)借书(4)还书(5)图书续借(6)登录系统图 3.1 借阅者请求服务的用例图二、图书馆管理员处理借书、还书等的用例图(1)处理借书(2)处理还书(3)取消预约(4)检查读者数量图 3.2 图书馆管理员处理借书、还书等的用例图三、系统管理员进行系统维护的用例图(1)增加图书(2)删除图书(3)添加标号(4)删除或更新标号(5)添加读者(6)删除或更新读者(7)查询读者信息(8)查询图书信息图3.3 系统管理员进行系统维护的用例图3.2静态结构模型3.2.1类的识别系统需求已经定义过了,现在可以根据系统需求识别出系统中存在的类。系统类的识别可以通过寻找系统域描述和需求描述中的名词来进行。1.找出候选类从前述的系统需求描述中可以找到的名词有:借阅者、用户、读者、图书、借阅记录、预定记录、永久数据、用户个人信息、借书证、借书证号、图书编号、图书名、出版社、地址、电话、作者、入库时间、出版时间等,这些都是类图中的候选类。2.筛选正确类仅通过一个简单、机械的过程不可能正确的完成分析工作。接下来要从中去掉不正确的、不必要的,仅保留确实应该记录的类。按照如下标准进行筛选a.冗余如果两个类表达了同样的信息,则应该保留在此问题中最富于描述力的名称。此系统中“借阅者”、“用户”、“读者”描述相同的信息,因此应该用“借阅者”。b.属性在需求陈述中有些名词实际上描述的是其他对象的属性,应该把这些名词从候选类中去掉,当然,如果某个性质具有很强的独立性,则应把它作为类,而不是作为属性。此系统中“借书证号”、“图书编号”、“图书名”、“出版社”、“地址”、“电话”、“作者”、“入库时间”、“出版时间”等,实际上都应该作为属性对待。综上所述,经过初步的筛选剩下的类有: 借阅者、图书、借阅记录、预定记录、数据库中的存储、借阅证。3.2.2类的关联分析在初步分析确定了问题域中的类之后,接下来就分析确定类与对象之间的关联关系,两个或多个对象之间的相互依赖、相互作用的关系就是关联。分析确定关联能促使分析员考虑问题域的边缘情况,有助于发现那些尚未被发现的类。对于图书馆管理系统,我们从以下几个方面确定其关联。在需求陈述中使用的描述性动词或动词词组,通常表示关联关系,经过对本图书馆分析,初步确定下列关联。通过对图书管理系统需求陈述的分析,我们得到了各个类之间的关联。1直接提取动词短语得出的关联(1)图书入库管理和修改图书信息。(2)对读者借书、还书和罚金处理(3)建立、修改和删除标题、借书者、借阅信息和预定信息。(4)根据图书信息,进行查询(5)预约和续借2需求陈述中隐含的关联(1)系统维护员对图书管理系统进行一定的系统维护(2)图书管理员与读者和借阅窗口进行交互 (3)预定的图书归还回来时,通知预定人(4)读者拥有自己的图书证号 3根据问题域知识得出的关联 (1 使用图书证号登录系统 (2)图书馆雇佣图书管理员和系统维护员经过初步分析得出的关联只能作为候选的关联,对此,我们进行了进一步的筛选,以确定不正确的的关联。以下是标准的关联。(1)图书入库管理和修改图书信息。(2)对读者借书、还书和罚金处理(3)建立、修改和删除标题、借书者、借阅信息和预定信息。(4)根据图书信息,进行查询(5)预约和续借(6)系统维护员对图书管理系统进行一定的系统维护(7)图书管理员与读者和借阅窗口进行交互3.2.3类的属性描述根据系统的需求分析确定的主要类有:借阅者、图书、借阅记录、预订记录、图书管理员、登录对话框。属性是对象的性质,借助于属性人们能够对类和对象的结构有更深入、更具体的认识,下面具体介绍一下上述各类的属性。1.类名:借阅者属性:姓名、地址、电话、班级、学号、邮箱、借阅记录、还书记录、罚款记录、预订记录2.类名:图书 属性:图书名、图书号、出版社、作者、出版时间、入库时间、分类3.类名:借阅记录 属性:图书名、借阅者、借书日期和应还日期、图书类型4.类名:预订记录属性:图书名、借阅者、预订日期和应还日期、图书类型5.类名:图书管理员 属性:姓名和编号6.类名:登录对话框 属性:用户名和密码系统的实体类的类图如图3.4所示。3.3系统动态模型在开发图书馆管理信息系统时,动态模型起着重要的作用,动态行为模型由顺序图、协作图、状态图、活动图描述。3.3.1系统执行顺序分析顺序图是显示对象之间交互的图,这些对象是按时间顺序排列的。该图书馆借还书管理系统主要含有以下几个重要的顺序图,其他对象的顺序图和这些也类似。图3.4 图书馆借还书管理系统读者借阅的类图1.借书顺序借书的过程是:图书管理员登录借书界面,并验证读者信息,在借书界面显示读者信息,读者提出借书要求,显示读者信息看读者是否符合借书要求,若符合,则显示可借,并取得图书信息,检查图书是否预订,如若没有预订,返回没有被预订,书籍外借,显示借书成功。如若上述有一条不符则不能成功借书。根据基本流程,创建借阅者借书的顺序图如图3.6所示。2.还书顺序还书的过程是:读者将图书交给图书管理员,图书管理员登录系统,显示还书界面,扫描书籍条形码并取得书籍条目信息,进行确认验证,并返回确认结果,对书籍条目进行更新和对借阅者信息进行修改,返回还书成功。根据基本流程,创建借阅者还书的顺序图如图3.7所示。3.删除借阅者顺序删除借阅者的过程是:图书管理员选择菜单下“删除借阅者”,查询对话框弹出,图书管理员输入借阅者账号,系统查询数据库,显示借阅者信息(若借阅者信息不存在,显示提示信息,结束删除动作),按下删除按钮,系统确定是否存在与该借阅者相关的借阅记录,若有,给出提示信息,结束删除动作;若没有,查询是否存在与该借阅者相关的预订记录,若有,删除预订记录。从系统中删除借阅者。根据基本流程,创建删除借阅者的顺序图如图3.8所示。图3.5借书顺序图图3.6还书顺序图图3.7删除借阅者顺序图4. 逾期处理是还书时的扩展动作,因此在这里一起考虑。还书时扫描图书,若显示正常,则管理员只需修改删除相应书目信息,在系统显示书目信息后还书成功。若显示图书逾期,则管理员需按照处罚条例给以一定的罚款处理。等借阅者交纳罚金后,修改删除相应书目信息,在系统显示书目信息后还书成功。根据基本流程,创建逾期处理的顺序图如图2.9所示。3.3.2系统的协作分析顺序图和协作图在语义上是等价的,所以顺序图和协作图可以彼此转化,而不会损失信息,但这并不意味着两种图都显式的可视化了同样的信息。例如,协作图描述了对象怎样互相连接,但相应的顺序图没有显式的描述这个信息。在顺序图中,可以描述返回消息,但相应的协作图没有描述这个信息。下面以借书协作图为例进行分析;图3.5所示的顺序图与图3.9所示的协作图是等价的,根据借书顺序图与借书协作图之间的关系,我们能够轻易画出其它一些操作的协作图,下面就依照借书顺序图与协作图之间的关系进行分析。 图3.8 逾期处理顺序图图3.9借书协作图3.3.3系统状态分析1登录系统后显示系统界面,借阅者可以进入查询界面直接进行信息查询。管理员输入用户名和密码后进入管理员界面,此后管理员可以进行查询、书籍管理和用户管理三个功能操作。当借阅者借书时,管理员验证借阅者信息后系统显示借阅者信息,而后添加书目信息,借阅者借书成功。还书时管理员扫描图书,若未逾期则显示正常和相应的更新书目信息后还书成功;若逾期则做出罚款处理后修改书目信息,待系统显示更新的书目信息后还书成功。描述系统用例的状态图如下3.10所示: 图3.10 图书馆借还书管理系统的状态图2.图书状态分析图书在未变成图书馆在库图书时,为新加图书状态。图书处于在库状态时既可以预订也可以外借,外借后变为借出状态。处于预订状态时也可以外借,超出预订时间期限则从预订状态直接转为可用状态。借阅者在规定的预订时间内也可以考虑取消预订,取消预订后书籍的状态转为可用。外借书籍归还后变为可用状态。图书馆的书籍状态图如图3.11所示。3.借阅者状态分析借阅者在没有账户的时候,由图书管理员创建账户,创建账户后,处于可用的状态,当借阅者可以借阅图书的时候,处于能够借书状态;当借阅者借书超过规定额度时,处于不能借书状态,只有将图书归还后,才能处于能够借书状态;当借阅者被删除时,处于删除状态不能使用。借阅者状态图如图3.12所示。图3.11 图书馆的图书状态图图3.12 借阅者状态图3.3.4活动分析活动图能够描述出系统中那些地方提供了什么功能,以及这些功能之间如何协同来共同满足前面的用例。活动图描述的是某流程中的任务的执行,活动图描述活动是如何协同工作的,当一个操作必须完成一系列事情,而又无法确定以什么样的顺序来完成这些事情时,活动图可以更清晰地描述这些事情。活动图可以有效地描述用例,在为用例建立工作控制流模型时,活动图可以显示用例内部和用例之间的交互路径。在本图书馆管理系统中,我们主要描述了图书馆系统的借书、还书和预订的活动图。1.借书活动管理员首先要扫描读者的借书证,检验证件是否符合图书馆借书条件,若该读者的借书数量还未达到最大规定数量,并且其所借书籍均未属于过期范围,则符合借书条件。则再扫描书籍条形码,检查书籍是否是不可借书籍或者已经被预订,若被预订,则取消预订,方可借书。在这些条件都符合时则更新书籍信息和读者的借阅信息,记录好借书的时间。图书馆借书活动图,如图3.13所示。2.还书活动图书管理员对书籍进行扫描,若书籍已经过期,则要求读者还请欠款才能还书,读者缴清应交罚款后,更新书目信息和读者信息。图书馆还书活动图,如图3.14所示。3.预订图书活动读者先进入系统查询自己所需要的书籍,显示书籍信息,检验书籍是否属于可预订书籍,若符合条件则检查书籍是否在书库,如果书籍在书库则检查是否被预订或已经外借,若都未成立,则读者登录系统,并对该书籍进行预订。图书馆预订图书活动图,如图3.15所示。图3.14 图书馆还书活动图图3.13 图书馆借书活动图图3.15 图书馆预订图书活动图4.图书馆借还书管理系统系统设计与实现4.1 UML体系结构设计UML(Unified Modeling Language的缩写)统一建模语言,是用来对密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。统一建模语言 (UML)是非专利的第三代建模和规约语言。 UML是在开发阶段,说明,可视化,构建和书写一个面向对象软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践,这些最佳实践在对大规模,复杂系统进行建模方面,特别是在软件架构层次已经被验证有效。UML被OMG采纳作为业界的标准。UML最适于数据建模,业务建模,对象建模,组件建模。本图书管理系统采用统一建模语言UML对该系统体系结构建模。4.1.1硬件体系结构设计本系统中,图书馆可通过局域网服务器对信息及借阅情况进行管理,还可通过互联网服务器对读者的查询和续借进行管理,但是读者只能通过互联网进行相关图书的查询和预定,借阅管理、读者查询和续借都要汇总到数据服务器中进行相关存储。借阅管理子系统局域网服务器数据服务器互联网图4.1 “图书管理系统”硬件设计查询续借子系统互联网服务器局域网局域网图书馆PC终端读者PC终端局域网4.1.2软件体系结构设计信息系统的软件结构是由信息系统软件的各子系统按照确定的关系构成的结构框架,一般呈现多层次结构模式。子系统是对软件进行分解的一种中间形式,也是组织和描述软件的一种方法。软件结构设计就是把软件分解成多个子系统,并确定各子系统及其接口之间的相互关系。系统软件结构设计如图4.2所示。读者管理员操作员用户界面读者信息预订管理数据库借书记 录读者信息预订信息借书管理借书记录还书管理处理记录续借管理续借信息用户层用户界面层局域网应用层图4.2 系统软件结构设计图4.2对象模型设计进入了设计阶段,要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型着手实现软件的需求,并将设计的结果反映在“设计规格说明书”文档中。需求可以通过对象以及它们的抽象类型组织起来。这种设计也可以围绕抽象的数据类型来建立系统的模块(组件)。基于对象的设计必须具备两个重要特征。(1)对象必须保持数据表示的完整性,数据表示对于其他对象是隐藏的。与管道/过滤器系统不同的是,一个对象必须能识别其他对象以便于它们之间的通信,而过滤器是完全独立。(2)设计不是编码,即使在详细设计阶段,设计模型的抽象级别也比源代码要高。详细设计是设计实现的算法和具体的数据结构。软件的质量属性需要在设计时考虑如何实现,在设计过程中要不断评价软件质量,不要等全部设计结束之后再考虑。在前文所述中,对系统所有关联对象经过初步分析后得出了图书馆管理系统的初始类如下:借阅者、书刊、借阅记录、预订记录、登录对话框、借阅对话框、查询对话框、还书对话框、预订对话框、永久数据、图书管理员。经过对其的进一步分析,和为了更好的实现其功能,我们决定在本系统实体类图中增加图书管理员类,因此在实体类图中用到了: 借阅者、书刊、借阅记录、预定记录、数据库中的存储、借阅证、图书管理员。并对其每个类的操作进行了进一步的分析和总结。在本系统的对象设计中,由以上分析得到了实体对象图,如图4.3所示。图4.3 系统实体对象图4.3 系统实现4.3.1 组件分析系统中遵从一组接口且提供其实现的物理的、可替换的部分。对系统的物理方面建模时,它是一个重要的构造块。若组件的定义良好,该组件不直接依赖于组件所支持的接口,在这种情况下,系统中的一个组件可以被支持正确接口的其他组件所代替。组件图符是一个矩形框。该系统的组件图如图4.4所示。图4.4 系统组件图4.3.2 配置分析配置图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件,即系统运行时刻的结构。可以显示计算机结点的拓扑结构和通信路径,结点上执行的软构件,软构件包含的逻辑单元等,特别对于分布式系统,配置图可以清楚的描述系统中硬件设备的配置,通信以及在各硬件设备上各种软构件和对象的配置。配置图是描述任何基于计算机的应用系统的物理配置或逻辑配置的有力工具,图书馆借还书管理子系统的配置图如图4.5所示。数据库服务器应用服务器客户端图书库图书馆借还书管理系统用户界面TCP/IPTCP/IP图4.5 系统配置图5.课程设计心得体会两周的课程设计结束了,在这次的课程设计中不仅检验了我所学习的知识,也培养了我如何去把握一件事情,如何去做一件事情,又如何完成一件事情。在设计过程中,学会了许多知识。课程设计是我们专业课程知识综合应用的实践训练,是我们迈向社会,从事职业工作前一个必不少的过程”千里之行始于足下”,通过这次课程设计,我深深体会到这句千古名言的真正含义我今天认真的进行课程设计,学会脚踏实地迈开这一步,就是为明天能稳健地在社会大潮中奔跑打下坚实的基础在此感谢我们的王欣老师.,老师循循善诱的教导和不拘一格的思路给予我无尽的启迪;这次课程设计的每个细节,都离不开老师您的细心指导。而您开朗的个性和宽容的态度,帮助我能够很顺利的完成了这次课程设计。同时感谢对我帮助过的同学们,谢谢你们对我的帮助和支持,让我感受到同学的友谊。 由于本人的设计能力有限,在设计过程中难免出现错误,恳请老师们多多指教,我十分乐意接受你们的批评与指正,本人将万分感谢。参考文献1 张海藩.软件工程导论(第五版).北京:清华大学出版社,20082 冀振燕.uml系统分析设计与应用案例.北京:人民邮电出版社,20033 刘天时等.软件案例分析.北京:清华大学出版社,20084王少锋.面向对象技术uml教程.北京:清华大学出版社,20045王欣 管理信息系统 中国水利水电出版社 2004(2007年重印)6石峰 宋红.面向对象方法 高等教育出版社 2008