ImageVerifierCode 换一换
格式:DOCX , 页数:16 ,大小:460.25KB ,
资源ID:17248629      下载积分:12 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/17248629.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(图书馆信息系统面向对象分析实例Word格式文档下载.docx)为本站会员(b****6)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

图书馆信息系统面向对象分析实例Word格式文档下载.docx

1、修饰性的:可选的,增加这些功能不会对成本和其它系统造成重要影响。为此,我们给出该系统的借书基本功能如下:F1.1记录借出的图书-借阅事件 明显的F1.2 查找书库中是否存在这种图书 明显的F1.3 从借书卡中读取借书者信息,并校验该信息 明显的F1.4 查找书库中这本书是否还有副本 隐藏的F1.5 当一次借阅完成后,削减该书的副本存书数量 隐藏的F1.6 管理员要使用系统,必须输入ID号和密码才行 明显的F1.7 查询显示借书信息 明显的F1.8 提供一个持久化存储机制 隐藏的F1.9 提供过程间的和系统间的通信机制 隐藏的系统属性:系统属性是系统的特性,它们并不是系统的功能,例如:易用、容错

2、、响应时间、界面形式、平台等。系统属性具有一组可能的属性细节,这些属性细节往往是属性的一些离散的、表达模糊的符号值,例如:响应时间=(生理上能够接受的时间段)界面形式=(图形化的,基于表的,彩色比较平淡的)在我们的案例中,要求借书查找时间小于1秒。我们结合上面的图书馆管理系统的案例,来给出图书管理系统的问题域模型。我们首先看问题域中的图书、借阅、书目和借书者这四个类。系统将通过计算机来处理图书、副本、借书者和借阅。借书者要求借书,给出要借图书的名称,出示借书证。系统查找所借的图书是否存在,若存在,同时还要查看该图书是否还有副本,如果有,再查询该借书者提供的借书证是否合法的注册用户,如果是,则办

3、理借阅手续(登记借阅信息)。图书是存放在图书馆中的一个书的名称,副本是一个图书的具体实例。一个图书可能有多个副本,一个副本一定会对应一个图书。为简化起见,我们假定一次借阅(登记)只能借一本图书,同时会对应着一个借书证信息。一个借书者可以进行多次借阅。首先找出业务对象:图书、副本、借书证。系统需要处理的现实世界中的对象和概念:借阅、预定。将要发生或已经发生的事件:已经预定。下面给出其UML表示的问题域的类图。图-2-1 图书管理系统中的问题域主要概念类图问题域类图中的关系说明如下:1、一个图书名称可以有多个同样图书的副本。2、每一个副本一定要对应一个图书名称。3、一次借阅必须记录一个图书的副本和

4、一个借书证信息。4、一个副本可以被借阅,也可以不被借阅。5、一个借书证可以借多本书,也可以不借一本书。6、一个借书证可以进行多个图书名称的预定,也可以不进行预定。7、一次预定必须记录一个图书名称信息和一个借书证信息。8、一个图书名称可以被多次预定,也可以不被预定。术语表也是一个重要的内容,下面我们给出图书管理系统的术语表:图书:图书是图书馆内最重要的对象,它是系统处理主要对象,图书是本书的信息描述,它包含了图书的名称,图书的作者以及图书的ISBN统一出版编号等内容。副本:副本是图书的一个实例,一个图书信息可以有多个副本,也可以没有副本。副本是借书时的真正对象。只有一个图书有可以供借阅的副本时,

5、借书者才可以对其借阅。借书证:业务中的借书证记录了借书者的信息,从计算机应用软件开发的角度来看,如果组织对象,应该叫“借书者信息”更确切。 借阅:借阅是图书管理中的一个最重要的业务活动,它需要进行一系列的操作才能完成一个借阅业务,包括查找图书、查找副本、核对借书证(借书者信息)等步骤。预定:预定是图书管理中的一个业务活动,它也需要一系列的操作才能完成。书籍:书籍是图书的一种形式。杂志:杂志也是图书的一种形式。图书管理员:图书馆的工作人员,直接为借书者提供服务的人,也是系统的直接使用者。借书者:到图书馆借书的人,属于图书馆的用户(服务对象)。借书者信息:一个记录了借书者完整信息的卡片,包括借书者

6、的姓名、居住地址,所在城市和电话号码等内容。有关的术语可能还有很多,这里就不再一一列出。对于图书管理系统的业务模型,我们可以采用逐步描述的方式来建立:一、确定业务系统的参与者系统的参与者: 借书者业务系统:图书馆二、确定业务系统的参与者的目标对于借书者的目标我们可以描述如下:1 借书 use csae 12 还书 use case 33 预定 use case 34 取消预定 use case 4三、绘制图书馆业务系统的Use case 模型图四、在以上四个use case中挑选一个作为首先实现的目标。选择:use case 1, 借书作为我们首先分析和实现的目标。五、了解业务系统的参与者的期

7、望,导出系统责任。写出use case 描述的事件流。Business use case 描述:借书借书者到图书馆里选择了喜欢的图书之后,要求图书馆办理借书手续,图书馆登记所借图书的借阅资料,查找所借的图书是否存在以及所借图书是否还有副本,请借书者提供借书证。借书者请图书馆登记借书证上的借书者信息,图书馆登记完成后,将借书者所要借的图书交给借书者,借书者拿着图书离开图书馆。六、绘制业务系统的顺序图(Sequence diagram)根据事件流的描述,绘出业务系统的顺序图,见图2-2。通过该图我们可以看到,图书馆这个业务系统需要向借书者提供以下的服务:1、受借书请求。2、提示借书者提供所要借的图

8、书名称3、接受借书者提供的图书名称4、查找书名5、查找副本6、提示借书者给出借书者信息7、接受借书者给出的借书者信息8、核对借书者信息并记录借阅信息9、将图书送出,提示借书者拿走图书图2-2 业务系统级的顺序图七、打开业务系统,找出业务系统内部的业务对象模型元素根据前面的需求说明,我们知道图书馆内部情况如下:作为图书馆工作人员的图书管理员,他们负责为借书者服务,并操作各种业务实体来完成图书馆的各种业务流程。作为图书馆内部的业务实体有:图书借阅登记、图书预定登记、图书信息卡、图书副本、借书人信息等。每登记一次图书借阅,需要登记图书名称、借书者名称以及图书副本号等信息。每登记一次图书预定,需要登记

9、图书名称和借书者信息。具体的系统内部结构图见图2-3。图2-3 图书馆业务系统内部业务对象模型元素八、写出详细的事件处理流描述事件流描述:借书者到图书馆里选择了喜欢的图书之后,要求图书管理员办理借书手续,图书管理员使用图书管理系统登记所借图书的借阅资料。首先,图书管理员向图书借阅登记输入图书名称,图书借阅登记请图书信息卡查找所借的图书是否存在,如果该图书存在,则图书信息卡请图书副本检查该图书是否还有副本,如果有,进行下面的工作;图书管理员请借书者提供借书者信息。借书者请图书管理员登记借书者信息,图书管理员向图书借阅登记输入借书者信息,图书借阅登记请借书者信息核对该信息是否有效;如果有效,图书借

10、阅登记将登记相应的借书者信息、图书信息卡和图书副本。处理完成后,提示图书管理员登记完毕,图书管理员将借书者所要借的图书交给借书者,借书者拿着图书离开图书馆。九、绘制业务系统详细顺序图(Sequence diagram)根据上面的借书事件流描述,我们可以给出借书业务的顺序图,如图2-4。通过顺序图我们可以看到每一个对象的责任:通过请求借书,启动借书流程;向图书管理员提供图书名称和借书者信息;拿走图书。接受借书请求,启动系统的借书流程;接受借书者提供的图书名称、借书者信息;向图书借阅登记对象提供图书名称和借书人名称;提示借书人拿走图书。图书借阅登记:接受并执行借书登记;接受并执行查找图书;接受并执

11、行核对借书人信息。图书信息卡:负责查找图书。图书副本:负责查找核实空闲的副本。借书人信息:负责查找核实借书人,确认其为合法的借书人。应当注意的是,借书事件流的描述并非只有以上的一种描述方式,它将随着业务处理方式的不同而改变。比如,我们也可以这样描述:借书者到图书馆里选择了喜欢的图书之后,将选定的图书名称和借书者信息交给图书管理员,要求图书管理员办理借书手续,图书管理员使用图书管理系统登记所借图书的借阅资料。首先,图书管理员向图书借阅登记输入图书名称和借书者信息,请图书借阅登记处理借书登记业务,图书借阅登记请图书信息卡查找所借的图书是否存在,如果该图书存在,则请图书副本检查该图书是否还有副本,如

12、果有,进行下面的工作;图书借阅登记请借书者信息核对该信息是否有效,如果有效,图书借阅登记将登记相应的借书者信息、图书信息卡和图书副本。这样的操作过程必然产生不同的顺序图。它明显地减少了图书管理员与借书者之间的交互次数。这种方式所产生的顺序图见图2-5。图2-4 业务系统打开后的顺序图在建立业务模型时,术语表也是一个重要的内容,它是在前面已经建立的问题域模型的基础上进行增补而形成的。下面我们给出图书管理系统业务模型的术语表:图书信息卡是图书馆内最重要的对象,它是系统处理主要对象,图书信息卡是某一本图书的信息描述,它包含了图书的名称,图书的作者以及图书的ISBN统一出版编号等内容。图书副本是图书的

13、一个实例,一个图书信息卡可以有多个图书副本,也可以没有图书副本。图书副本是借书时的真正对象。只有一个图书信息卡有可以供借阅的图书副本时,借书者才可以对其借阅。业务中的借书者信息记录了借书者的重要信息,包括借书者的姓名、住址、居住城市、居住省、身份证号码、邮政编码、电话号码等内容。图书 借阅登记:图书 借阅登记是图书管理中的一个最重要的业务活动,它需要进行一系列的操作才能完成一个图书 借阅登记业务,包括查找图书、查找副本、核对借书证(借书者信息)等步骤。图2-5 另一种借书业务处理事件流产生的顺序图十、形成业务模型的对象模型在前面的第七步,我们找出了一些比较重要的对象模型元素,结合前面的问题域模

14、型的类图进行修改和补充,我们可以得到业务系统的对象模型。见图2-6。图2-6 图书馆业务系统对象模型业务系统对象模型类图中的关系说明如下:1、一个图书信息卡可以有多个同名图书副本。2、每一个图书副本一定要对应一个图书信息卡。3、一次图书借阅登记必须记录一个图书副本和一个借书人信息。4、一个图书副本可以被借阅,也可以不被借阅。5、一个借书人信息可以进行多次图书借阅登记,也可以没有图书借阅登记。6、一个借书人信息可以进行多次图书预定登记,也可以没有图书预定登记。7、一次图书预定登记必须记录一个图书信息卡和一个借书人信息。8、一个图书信息卡可以被多次预定,也可以不被预定。9、书籍和杂志是图书信息卡的

15、特殊类。它们之间具有一般特殊结构。A、系统参与者描述图书管理员图书管理员是与计算机系统实际交互的活动者。图书管理员通过增加和删除标题、书目和借书者来维护系统,同时也执行像借书、还书、预定书目给、给出有关存储在系统中的数据的信息等执行系统关键性的功能。这些功能是为借书者服务的。借书者借书者可以借阅和预定书和杂志。借书者可以是一个人或另一个图书管理员。图书管理用例图B、用例模型的综合描述图书管理系统为客户提供一个管理图书的软件系统,直接与系统交互的是图书管理员,因此,图书管理员是应用系统的参与者。借书者是通过图书管理员与系统交互的,他的交互对象是图书管理员,因此借书者是业务系统的参与者。图书管理员

16、通过使用预定、借出书目、删除预定和返还书目这些用例来提供对借书者的服务,还通过使用系统维护用例来完成增加标题、删除或更新标题、增加书目、删除书目、增加借书者、删除或更新借书者等系统维护的工作。我们以图书管理的借书用例来说明详细描述一个用例。图书管理的借书用例的事件流描述。前提条件:借书者已经将自己的姓名、所借的图书标题、图书的作者等信息给了图书管理员。图书管理员在获取这些信息之后,开始进行图书借阅业务处理。事件流:基本路径: 图书管理员通过输入所借阅的图书标题(书名、作者或出版号),使用系统的查阅来确定所借图书是一个有效标题。 图书管理员通过查询系统查询确定该标题下具有有效的、可供借阅的书目。

17、 图书管理员通过输入借书者的信息,使用系统的查询功能来确定借书者是一个已经注册的合法借书者。 图书管理员通过输入借阅图书的标题信息和借书者信息来确定该图书和该借书者所存在的预定信息。 图书管理员将书借给借书者。然后,输入所借的图书标题、书目登记号、借书者的信息来形成一个新的借阅,并将以上信息存储。 如果存在预定,图书管理员通过输入借阅图书的标题信息和借书者信息来删除该图书和该借书者所存在的预定信息。否则执行以下步骤。 该用例实例结束。备选路径:如果在上述图书查询中没有借书者要求的图书,有两种处理方式:其一,取消图书借阅;其二,通过系统维护增加一个图书标题,并为该借书者进行一个图书预定。如果在上

18、述借书者查询中没有发现该借书者信息,同样有两种处理方式:其二,通过系统维护增加一个借书者信息(新用户),然后再执行借书的用例。后置条件:当借书完毕、或没有要借的图书并且借书者不希望预定、或该借书者没有注册并拒绝注册为新用户时,该用例实例结束。1需求(Requirements)典型地,由系统最终用户的代表写出文本形式的需求规范文档。对于该图书馆应用程序来说,需求规范文档应该类似于这样:1. 这是一个图书馆支持系统;2. 图书馆将图书和杂志借给借书者。借书者已经预先注册,图书和杂志也预先注册;3. 图书馆负责新书的购买。每一本图书都购进多本书。当旧书超期或破旧不堪时,从图书馆中去掉。4. 图书管理

19、员是图书馆的员工。他们的工作就是和读者打交道并在软件系统的支持下工作。5. 借阅人可以预定当前没有的图书和杂志。这样,当他所预定的图书和杂志归还回来或购进时,就通知预定人。当预定了某书的借书者借阅了该书后,预定就取消。或者通过显式的取消过程强行取消预定。6. 图书馆能够容易地建立、修改和删除标题、借书者、借阅信息和预定信息。7. 系统能够运行在所有流行的技术环境中,包括Unix, Windows 和OS/2,并应有一个现代的图形用户界面(GUI)。8. 系统容易扩展新功能。系统的第一版不必考虑预定的图书到达后通知预定人的功能,也不必检查借书过期的情况。2分析(Analysis)系统分析的目的是

20、捕获和描述所有的系统需求,并且建立一个模型来定义系统中主要的问题域类。通过系统分析达到开发者和需求者的理解和沟通。因此,分析一般都是分析员和用户协作的产物。在这个阶段,程序开发者不应该考虑代码或程序的问题;它只是理解需求和实现系统的第一步。21 需求分析(Requirements Analysis)分析的第一步是确定系统能够做什么?谁来使用这个系统?这些分别叫用例(use cases)和角色(actors)。用例描述了系统提供什么样的功能。通过阅读和分析文档,以及和潜在的用户讨论系统来分析用例。图书馆的角色定为图书管理员和借书人。图书管理员是软件系统的用户;而借书者则是来借阅或预定图书杂志的客

21、户。偶尔,图书管理员或图书馆的其他工作人员也可能是一个借书者。借书者不直接和系统交互,借书人的功能由图书管理员代为执行。图书馆系统中的用例有:1. 借书2. 还书3. 预定4. 取消预定5. 增加标题6. 修改或删除标题7. 增加书目8. 删除书目9. 增加借书者10. 修改或删除借书者上面所列的用例中没有维护,维护是一个使用其它用例的更一般的用例。同时,还应注意到上述用例中出现的两个概念:标题(Title) 和书目(Item) 。因为在一个图书馆中,一个流行的标题可能有好几本,因此系统必须将标题(可能是书名或书的作者)同其它的书目(代表一个指定标题的物理副本)区分开来。从图书馆借的是书目。在

22、图书馆拥有一本书的副本(书目)之前加一个标题到系统中是可能的,这样做的目的是让借书者可以预订。图书馆系统分析的结果写在UML 用例图中。每一个用例都附带有文本文档,描述用例和客户交互的细节。文本是通过与客户讨论得到的。用例“借书”描述如下:1如果借阅者没有预定: 确定标题 确定该标题下有效的书目 确定借书者 图书馆将书借出 登记一个新的借阅2如果借阅者有预定: 确定借书人 图书馆将相应的书目借出 取消预定除了定义系统的功能需求之外,在分析过程中用例用于检查是否有相应的域类已经被定义,然后他们可以被用在设计阶段,确保解决方案可以有效地处理系统功能。可以在顺序图中可视化实现细节。角色和用例。分析中

23、的第一步就是指出系统能被用来做什么,谁将去使用它。它们分别就是用例和角色。所有的用例必须始于角色,而且有些用例也结束于角色。角色是位于你所工作的系统外部的人或其他系统。一台打印机或一个数据库都可能是一个角色。本系统有两个角色:借阅者和图书管理员。通过与用户或客户的讨论,可以将每一个用例用文字进行说明。22 问题域分析(Domain Analysis)系统分析也详细地列出了域(系统中的关键类)。为了导出一个域分析,可以阅读规范文档(specifications)和用例,查找哪一些概念应该被系统处理。或者组织一个集体讨论,在用户及领域专家共同的参与下指出系统中必须处理的关键概念,以及它们之间的关系。其中有些类有UML 状态图,用来显示这些类的对象可能具有的不同状态,以及触发他们的状态发生改变的事件。该例子中有状态图的类是item 和title 类。

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1