图书馆信息系统UML 实例 .pdf

图书馆信息系统UML实例

1．需求（Requirements）

典型地，由系统最终用户的代表写出文本

形式的需求规范文档。对于该图书馆应用程序

来说，需求规范文档应该类似于这样：

1.这是一个图书馆支持系统；

2.图书馆将图书和杂志借给借书者。借书者

已经预先注册，图书和杂志也预先注册；

3.图书馆负责新书的购买。每一本图书都购

进多本书。当旧书超期或破旧不堪时，从图书

馆中去掉。

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

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

作。

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

这样，当他所预定的图书11和杂志归还回来或

购进时，就通知预定人。当预定了某书的借书

者借阅了该书后，预定就取消。或者通过显式

的取消过程强行取消预定。

6.图书馆能够容易地建立、修改和删除标题、

借书者、借阅信息和预定信息。

7.系统能够运行在所有流行的技术环境中，

包括Unix,Windows和OS/2，并应有一个现代

的图形用户界面(GUI)。

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

系统的第一版不必考虑预定的图书到达后通

知预定人的功能，也不必检查借书过期的情

况。

2．分析（Analysis）

系统分析的目的是捕获和描述所有的系

统需求，并且建立一个模型来定义系统中主要

的问题域类。通过系统分析达到开发者和需求

者的理解和沟通。因此，分析一般都是分析员

和用户协作的产物。

在这个阶段，程序开发者不应该考虑代码或程

序的问题；它只是理解需求和实现系统的第一

步。

2．1需求分析（RequirementsAnalysis）

分析的第一步是确定系统能够做什么？

谁来使用这个系统？这些分别叫角色（actors）

和用例（usecases）。用例描述了系统提供

什么样的功能。通过阅读和分析文档，以及和

潜在的用户讨论系统来分析用例。

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

图书管理员是软件系统的用户；而借书者则是

来借阅或预定图书杂志的客户。偶尔，图书管

理员或图书馆的其他工作人员也可能是一个

借书者。借书者不直接和系统交互，借书人的

功能由图书管理员代为执行。

图书馆系统中的用例有：

1.借书

2.还书

3.预定

4.取消预定

5.增加标题

6.修改或删除标题

7.增加书目

8.删除书目

9.增加借书者

10.修改或删除借书者

上面所列的用例中没有维护，维护是一个使用

其它用例的更一般的用例。同时，还应注意到

上述用例中出现的两个概念：标题(Title)和书

目(Item)。因为在一个图书馆中，一个流行的

标题可能有好几本，因此系统必须将标题(可

能是书名或书的作者)同其它的书目(代表一

个指定标题的物理副本)区分开来。从图书馆

借的是书目。在图书馆拥有一本书的副本(书

目)之前加一个标题到系统中是可能的，这样

做的目的是让借书者可以预订。

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

每一个用例都附带有文本文档，描述用例和客

户交互的细节。文本是通过与客户讨论得到

的。用例“借书”描述如下：

1．如果借阅者没有预定：

确定标题

确定该标题下有效的书目

确定借书者

图书馆将书借出

登记一个新的借阅

2．如果借阅者有预定：

确定借书人

确定标题

确定该标题下有效的书目

图书馆将相应的书目借出

登记一个新的借阅

取消预定

除了定义系统的功能需求之外，在分析过

程中用例用于检查是否有相应的域类已经被

定义，然后他们可以被用在设计阶段，确保解

决方案可以有效地处理系统功能。可以在顺序

图中可视化实现细节。

角色和用例。分析中的第一步就是指出系

统能被用来做什么，谁将去使用它。它们分别

就是用例和角色。所有的用例必须始于角色，

而且有些用例也结束于角色。角色是位于你所

工作的系统外部的人或其他系统。一台打印机

或一个数据库都可能是一个角色。本系统有两

个角色：借阅者和图书管理员。通过与用户或

客户的讨论，可以将每一个用例用文字进行说

明。

借书者