#图书馆信息系统面向对象分析实例

图书馆信息系统面向对象分析实例。

总体问题的陈述：本项目的目的是创建一个用于对图书馆的图书进行管理的图书管理系统。

该项目的用户：该项目的用户是一个某大学的图书馆，它负责对其顾客提供图书借阅服务。

该项目的目标：总体上来说，项目的目标是提高图书管理的自动化水平，为图书业务过程提供更快捷的、更好的和更准确的服务。

具体来讲，系统的目标包括：为借书者提供快速借书的服务；进行快速准确的图书和借书者的信息维护；图书管理和查询的自动化。

该系统的功能：系统功能是系统应该做的事情，例如系统提供的预定功能。

应该识别出这些功能并把它们列入到逻辑相关联的功能组中。

注意：要验证某一个描述是否真是一个系统的功能，如下的判断语句应该成立：
系统应该做某一个描述
例如，系统应该做图书的预定。

然而，系统的属性是系统的非功能性的特性，这些非功能性特性和系统功能经常被混淆。

例如，“易于使用”就是一个非功能性的特性。

它是不符合我们上述的验证语句：“系统应该做易于使用”。

系统属性不应该是功能规格说明书中的一部分，而应该是一个单独的系统属性规格说明文档。

对于系统的功能，我们应该对其分类，以便区分开各类功能的优先次序和识别出哪些是理所当然应该具备的系统功能。

功能的分类包括：
明显的：应该履行的功能，并且用户应该知道这个功能是否已经被履行。

隐藏的：应该履行的功能，但功能的履行对用户不可见。

很多使用底层技术的服务确实符合这种情况，例如，将数据保存到一个持久化存储机构中。

隐藏的功能经常在采集需求的过程中被遗漏。

修饰性的：可选的，增加这些功能不会对成本和其它系统造成重要影响。

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

系统属性具有一组可能的属性细节，这些属性细节往往是属性的一些离散的、表达模糊的符号值，例如：
响应时间=（生理上能够接受的时间段）
界面形式=（图形化的，基于表的，彩色比较平淡的）
在我们的案例中，要求借书查找时间小于1秒。

我们结合上面的图书馆管理系统的案例，来给出图书管理系统的问题域模型。

我们首先看问题域中的图书、借阅、书目和借书者这四个类。

系统将通过计算机来处理图书、副本、借书者和借阅。

借书者要求借书，给出要借图书的名称，出示借书证。

系统查找所借的图书是否存在，若存在，同时还要查看该图书是否还有副本，如果有，再查询该借书者提供的借书证是否合法的注册用户，如果是，则办理借阅手续（登记借阅信息）。

图书是存放在图书馆中的一个书的名称，副本是一个图书的具体实例。

一个图书可能有多
个副本，一个副本一定会对应一个图书。

为简化起见，我们假定一次借阅（登记）只能借一本图书，同时会对应着一个借书证信息。

一个借书者可以进行多次借阅。

首先找出业务对象：图书、副本、借书证。

系统需要处理的现实世界中的对象和概念：借阅、预定。

将要发生或已经发生的事件：已经预定。

下面给出其UML 表示的问题域的类图。

副本
借阅
10..1
参考
借书证1
0..n 具有预定
图书
0..n 1拥有
0..n
0..n 参考
图-2-1 图书管理系统中的问题域主要概念类图
问题域类图中的关系说明如下：
1、一个图书名称可以有多个同样图书的副本。

2、每一个副本一定要对应一个图书名称。

3、一次借阅必须记录一个图书的副本和一个借书证信息。

4、一个副本可以被借阅，也可以不被借阅。

5、一个借书证可以借多本书，也可以不借一本书。

6、一个借书证可以进行多个图书名称的预定，也可以不进行预定。

7、一次预定必须记录一个图书名称信息和一个借书证信息。

8、一个图书名称可以被多次预定，也可以不被预定。

术语表也是一个重要的内容，下面我们给出图书管理系统的术语表：
图书：图书是图书馆内最重要的对象，它是系统处理主要对象，图书是本书的信息描述，它包含了图书的名称，图书的作者以及图书的ISBN 统一出版编号等内容。

副本：副本是图书的一个实例，一个图书信息可以有多个副本，也可以没有副本。

副本是借书时的真正对象。

只有一个图书有可以供借阅的副本时，借书者才可以对其借阅。

借书证：业务中的借书证记录了借书者的信息，从计算机使用软件开发的角度来看，如果组织对象，应该叫“借书者信息”更确切。

借阅：借阅是图书管理中的一个最重要的业务活动，它需要进行一系列的操作才能完成一个借阅业务，包括查找图书、查找副本、核对借书证（借书者信息）等步骤。

预定：预定是图书管理中的一个业务活动，它也需要一系列的操作才能完成。

书籍：书籍是图书的一种形式。

杂志：杂志也是图书的一种形式。

图书管理员：图书馆的工作人员，直接为借书者提供服务的人，也是系统的直接使用者。

借书者：到图书馆借书的人，属于图书馆的用户（服务对象）。

借书者信息：一个记录了借书者完整信息的卡片，包括借书者的姓名、居住地址，所在城市和电话号码等内容。

有关的术语可能还有很多，这里就不再一一列出。

对于图书管理系统的业务模型，我们可以采用逐步描述的方式来建立：
一、确定业务系统的参和者
系统的参和者：借书者
业务系统：图书馆
二、确定业务系统的参和者的目标
对于借书者的目标我们可以描述如下：
1 借书use csae 1
2 还书use case 3
3 预定use case 3
4 取消预定use case 4
三、绘制图书馆业务系统的Use case 模型图
四、在以上四个use case中挑选一个作为首先实现的目标。

选择：use case 1，借书作为我们首先分析和实现的目标。

五、了解业务系统的参和者的期望，导出系统责任。

写出use case 描述的事件流。

Business use case 描述：借书
借书者到图书馆里选择了喜欢的图书之后，要求图书馆办理借书手续，图书馆登记所借图书的借阅资料，查找所借的图书是否存在以及所借图书是否还有副本，请借书者提供借书证。

借书者请图书馆登记借书证上的借书者信息，图书馆登记完成后，将借书者所要借的图书交给借书者，借书者拿着图书离开图书馆。

六、绘制业务系统的顺序图（Sequence diagram）
根据事件流的描述，绘出业务系统的顺序图，见图2-2。

通过该图我们可以看到，图书馆这个业务系统需要向借书者提供以下的服务：
1、受借书请求。

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

作为图书馆内部的业务实体有：图书借阅登记、图书预定登记、图书信息卡、图书副本、借书人信息等。

每登记一次图书借阅，需要登记图书名称、借书者名称以及图书副本号等信息。

每登记一次图书预定，需要登记图书名称和借书者信息。

具体的系统内部结构图见图2-3。

图2-3 图书馆业务系统内部业务对象模型元素
八、写出详细的事件处理流描述
事件流描述：借书
借书者到图书馆里选择了喜欢的图书之后，要求图书管理员办理借书手续，图书管理员使用图书管理系统登记所借图书的借阅资料。

首先，图书管理员向图书借阅登记输入图书名称，图书借阅登记请图书信息卡查找所借的图书是否存在，如果该图书存在，则图书信息卡请图书副本检查该图书是否还有副本，如果有，进行下面的工作；图书管理员请借书者提供借书者信息。

借书者请图书管理员登记借书者信息，图书管理员向图书借阅登记输入借书者信息，图书借阅登记请借书者信息核对该信息是否有效；如果有效，图书借阅登记将登记相应的借书者信息、图书信息卡和图书副本。

处理完成后，提示图书管理员登记完毕，图书管理员将借书者所要借的图书交给借书者，借书者拿着图书离开图书馆。

九、绘制业务系统详细顺序图（Sequence diagram）
根据上面的借书事件流描述，我们可以给出借书业务的顺序图，如图2-4。

通过顺序图我们可以看到每一个对象的责任：
借书者：通过请求借书，启动借书流程；向图书管理员提供图书名称和借书者信息；拿走图书。

图书管理员：接受借书请求，启动系统的借书流程；接受借书者提供的图书名称、借书者信息；向图书借阅登记对象提供图书名称和借书人名称；提示借书人拿走图书。

图书借阅登记：接受并执行借书登记；接受并执行查找图书；接受并执行核对借书人信息。

图书信息卡：负责查找图书。

图书副本：负责查找核实空闲的副本。

借书人信息：负责查找核实借书人，确认其为合法的借书人。

应当注意的是，借书事件流的描述并非只有以上的一种描述方式，它将随着业务处理方式的不同而改变。

比如，我们也可以这样描述：
借书者到图书馆里选择了喜欢的图书之后，将选定的图书名称和借书者信息交给图书管理员，要求图书管理员办理借书手续，图书管理员使用图书管理系统登记所借图书的借阅资料。

首先，图书管理员向图书借阅登记输入图书名称和借书者信息，请图书借阅登记处理借书登记业务，图书借阅登记请图书信息卡查找所借的图书是否存在，如果该图书存在，则请图书副本
检查该图书是否还有副本，如果有，进行下面的工作；图书借阅登记请借书者信息核对该信息是否有效，如果有效，图书借阅登记将登记相应的借书者信息、图书信息卡和图书副本。

处理完成后，提示图书管理员登记完毕，图书管理员将借书者所要借的图书交给借书者，借书者拿着图书离开图书馆。

这样的操作过程必然产生不同的顺序图。

它明显地减少了图书管理员和借书者之间的交互次数。

这种方式所产生的顺序图见图2-5。

: 借书人 : 图书管理员 : 图书借阅登记 : 图书信息卡 : 图书副本 : 借书人信息1: 请求借书服务
3: 请给出所借图书名称
4: 请接受图书名称5: 查找图书信息
6: 查找图书信息7: 查找副本信息
8: 请给出借书人信息
9: 请接受借书人信息13: 请拿走图书
10: 请核对借书人信息
11: 请核对借书人信息
12: 登记借书信息
2: 请求借书登记
图2-4 业务系统打开后的顺序图
在建立业务模型时，术语表也是一个重要的内容，它是在前面已经建立的问题域模型的基础上进行增补而形成的。

下面我们给出图书管理系统业务模型的术语表：
图书信息卡：图书信息卡是图书馆内最重要的对象，它是系统处理主要对象，图书信息卡是某一本图书的信息描述，它包含了图书的名称，图书的作者以及图书的ISBN统一出版编号等内容。

图书副本：图书副本是图书的一个实例，一个图书信息卡可以有多个图书副本，也可以没有图书副本。

图书副本是借书时的真正对象。

只有一个图书信息卡有可以供借阅的图书副本时，借书者才可以对其借阅。

借书者信息：业务中的借书者信息记录了借书者的重要信息，包括借书者的姓名、住址、居住城市、居住省、身份证号码、邮政编码、电话号码等内容。

图书借阅登记：图书借阅登记是图书管理中的一个最重要的业务活动，它需要进行一系列的操作才能完成一个图书借阅登记业务，包括查找图书、查找副本、核对借书证（借书者信息）等步骤。

预定：预定是图书管理中的一个业务活动，它也需要一系列的操作才能完成。

书籍：书籍是图书的一种形式。

杂志：杂志也是图书的一种形式。

图书管理员：图书馆的工作人员，直接为借书者提供服务的人，也是系统的直接使用者。

借书者：到图书馆借书的人，属于图书馆的用户（服务对象）。

: 借书人 : 图书管理员 : 图书借阅登记 : 图书信息卡 : 图书副本 : 借书人信息1: 请求借书服务（图书名称，借书者信息）
7: 请拿走图书
2: 请求借书登记（图书名称，借书者信息）
3: 请查找图书（图书名称）
4: 请查找图书副本（）
5: 请核对借书者信息（借书者信息）
6: 记录借阅信息（图书信息卡，图书副本，借书者信息）
图2-5 另一种借书业务处理事件流产生的顺序图
十、形成业务模型的对象模型
在前面的第七步，我们找出了一些比较重要的对象模型元素，结合前面的问题域模型的类图进行修改和补充，我们可以得到业务系统的对象模型。

见图2-6。

书籍
杂志图书副本图书信息卡
0..n 借书人信息
图书借阅登记
0..1
图书管理员图书预定登记0..n
0..n
0..n 拥有拥有参考
拥有副本参考
图2-6 图书馆业务系统对象模型
业务系统对象模型类图中的关系说明如下：
1、一个图书信息卡可以有多个同名图书副本。

2、每一个图书副本一定要对应一个图书信息卡。

3、一次图书借阅登记必须记录一个图书副本和一个借书人信息。

4、一个图书副本可以被借阅，也可以不被借阅。

5、一个借书人信息可以进行多次图书借阅登记，也可以没有图书借阅登记。

6、一个借书人信息可以进行多次图书预定登记，也可以没有图书预定登记。

7、一次图书预定登记必须记录一个图书信息卡和一个借书人信息。

8、一个图书信息卡可以被多次预定，也可以不被预定。

9、书籍和杂志是图书信息卡的特殊类。

它们之间具有一般特殊结构。

A、系统参和者描述
图书管理员
图书管理员是和计算机系统实际交互的活动者。

图书管理员通过增加和删除标题、书目和借书者来维护系统，同时也执行像借书、还书、预定书目给、给出有关存储在系统中的数据的信息等执行系统关键性的功能。

这些功能是为借书者服务的。

借书者
借书者可以借阅和预定书和杂志。

借书者可以是一个人或另一个图书管理员。

借书者
预定
删除预定
借出书目图书管理员
返还书目
图书管理员
增加标题
删除或更新标题
增加书目
删除书目
增加借书者
系统维护
删除或更改借书者
<<use>>
<<use>>
<<use>>
<<use>>
<<use>>
<<use>>图书管理用例图
B、用例模型的综合描述
图书管理系统为客户提供一个管理图书的软件系统，直接和系统交互的是图书管理员，因此，图书管理员是使用系统的参和者。

借书者是通过图书管理员和系统交互的，他的交互对象是图书管理员，因此借书者是业务系统的参和者。

图书管理员通过使用预定、借出书目、删除预定和返还书目这些用例来提供对借书者的服务，还通过使用系统维护用例来完成增加标题、删除或更新标题、增加书目、删除书目、增加借书者、删除或更新借书者等系统维护的工作。

我们以图书管理的借书用例来说明详细描述一个用例。

图书管理的借书用例的事件流描述。

前提条件：借书者已经将自己的姓名、所借的图书标题、图书的作者等信息给了图书管理员。

图书管理员在获取这些信息之后，开始进行图书借阅业务处理。

事件流：
基本路径：
图书管理员通过输入所借阅的图书标题（书名、作者或出版号），使用系统的查阅来确定所借图书是一个有效标题。

图书管理员通过查询系统查询确定该标题下具有有效的、可供借阅的书目。

图书管理员通过输入借书者的信息，使用系统的查询功能来确定借书者是一个已经注册的合法借书者。

图书管理员通过输入借阅图书的标题信息和借书者信息来确定该图书和该借书者所存在的
预定信息。

图书管理员将书借给借书者。

然后，输入所借的图书标题、书目登记号、借书者的信息来形成一个新的借阅，并将以上信息存储。

如果存在预定，图书管理员通过输入借阅图书的标题信息和借书者信息来删除该图书和该借书者所存在的预定信息。

否则执行以下步骤。

该用例实例结束。

备选路径：
如果在上述图书查询中没有借书者要求的图书，有两种处理方式：其一，取消图书借阅；其二，通过系统维护增加一个图书标题，并为该借书者进行一个图书预定。

如果在上述借书者查询中没有发现该借书者信息，同样有两种处理方式：其一，取消图书借阅；其二，通过系统维护增加一个借书者信息（新用户），然后再执行借书的用例。

后置条件：当借书完毕、或没有要借的图书并且借书者不希望预定、或该借书者没有注册并拒绝注册为新用户时，该用例实例结束。

1．需求（Requirements）
典型地，由系统最终用户的代表写出文本形式的需求规范文档。

对于该图书馆使用程序来说，需求规范文档应该类似于这样：
1. 这是一个图书馆支持系统；
2. 图书馆将图书和杂志借给借书者。

借书者已经预先注册，图书和杂志也预先注册；
3. 图书馆负责新书的购买。

每一本图书都购进多本书。

当旧书超期或破旧不堪时，从图书馆中去掉。

4. 图书管理员是图书馆的员工。

他们的工作就是和读者打交道并在软件系统的支持下工作。

5. 借阅人可以预定当前没有的图书和杂志。

这样，当他所预定的图书和杂志归还回来或购进时，就通知预定人。

当预定了某书的借书者借阅了该书后，预定就取消。

或者通过显式的取消过程强行取消预定。

6. 图书馆能够容易地建立、修改和删除标题、借书者、借阅信息和预定信息。

7. 系统能够运行在所有流行的技术环境中，包括Unix, Windows 和OS/2，并应有一个现代的图形用户界面(GUI)。

8. 系统容易扩展新功能。

系统的第一版不必考虑预定的图书到达后通知预定人的功能，也不必检查借书过期的情况。

2．分析（Analysis）
系统分析的目的是捕获和描述所有的系统需求，并且建立一个模型来定义系统中主要的问题域类。

通过系统分析达到开发者和需求者的理解和沟通。

因此，分析一般都是分析员和用户协作的产物。

在这个阶段，程序开发者不应该考虑代码或程序的问题；它只是理解需求和实现系统的第一步。

2．1 需求分析（Requirements Analysis）
分析的第一步是确定系统能够做什么？谁来使用这个系统？这些分别叫角色（actors）和用
例（use cases）。

用例描述了系统提供什么样的功能。

通过阅读和分析文档，以及和潜在的用户讨论系统来分析用例。

图书馆的角色定为图书管理员和借书人。

图书管理员是软件系统的用户；而借书者则是来借阅或预定图书杂志的客户。

偶尔，图书管理员或图书馆的其他工作人员也可能是一个借书者。

借书者不直接和系统交互，借书人的功能由图书管理员代为执行。

图书馆系统中的用例有：
1. 借书
2. 还书
3. 预定
4. 取消预定
5. 增加标题
6. 修改或删除标题
7. 增加书目
8. 删除书目
9. 增加借书者
10. 修改或删除借书者
上面所列的用例中没有维护，维护是一个使用其它用例的更一般的用例。

同时，还应注意到上述用例中出现的两个概念：标题(Title) 和书目(Item) 。

因为在一个图书馆中，一个流行的标题可能有好几本，因此系统必须将标题(可能是书名或书的作者)同其它的书目(代表一个指定标题的物理副本)区分开来。

从图书馆借的是书目。

在图书馆拥有一本书的副本(书目)之前加一个标题到系统中是可能的，这样做的目的是让借书者可以预订。

图书馆系统分析的结果写在UML 用例图中。

每一个用例都附带有文本文档，描述用例和客户交互的细节。

文本是通过和客户讨论得到的。

用例“借书”描述如下：
1．如果借阅者没有预定：
确定标题
确定该标题下有效的书目
确定借书者
图书馆将书借出
登记一个新的借阅
2．如果借阅者有预定：
确定借书人
确定标题
确定该标题下有效的书目
图书馆将相应的书目借出
登记一个新的借阅
取消预定
除了定义系统的功能需求之外，在分析过程中用例用于检查是否有相应的域类已经被定义，然后他们可以被用在设计阶段，确保解决方案可以有效地处理系统功能。

可以在顺序图中可视化实现细节。

角色和用例。

分析中的第一步就是指出系统能被用来做什么，谁将去使用它。

它们分别就是用例和角色。

所有的用例必须始于角色，而且有些用例也结束于角色。

角色是位于你所工作的系统外部的人或其他系统。

一台打印机或一个数据库都可能是一个角色。

本系统有两个角色：借阅者和图书管理员。

通过和用户或客户的讨论，可以将每一个用例用文字进行说明。