文档介绍：图书馆信息系统UML 实例
(Requirements)
典型地,由系统最终用户的代表写出文本形式的需求规范文档。对于该图书馆应用程序来说,需求规范文档应该类似于这样:
1. 这是一个图书馆支持系统;
2. 图书馆将图书和杂志借给借书者。借书者已经预先注册,图书和杂志也预先注册;
3. 图书馆负责新书的购买。每一本图书都购进多本书。当旧书超期或破旧不堪时,从图书馆中去掉。
4. 图书管理员是图书馆的员工。他们的工作就是和读者打交道并在软件系统的支持下工作。
5. 借阅人可以预定当前没有的图书和杂志。这样,当他所预定的图书和杂志归还回来或购进时,就通知预定人。当预定了某书的借书者借阅了该书后,预定就取消。或者通过显式的取消过程强行取消预定。
6. 图书馆能够容易地建立、修改和删除标题、借书者、借阅信息和预定信息。
7. 系统能够运行在所有流行的技术环境中,包括Unix, Windows 和OS/2,并应有一个现代的图形用户界面(GUI)。
8. 系统容易扩展新功能。
系统的第一版不必考虑预定的图书到达后通知预定人的功能,也不必检查借书过期的情况。
(Analysis)
系统分析的目的是捕获和描述所有的系统需求,并且建立一个模型来定义系统中主要的问题域类。通过系统分析达到开发者和需求者的理解和沟通。因此,分析一般都是分析员和用户协作的产物。
在这个阶段,程序开发者不应该考虑代码或程序的问题;它只是理解需求和实现系统的第一步。
需求分析(Requirements Analysis)
分析的第一步是确定系统能够做什么?谁来使用这个系统?这些分别叫角色(actors)和用例(use cases)。用例描述了系统提供什么样的功能。通过阅读和分析文档,以及和潜在的用户讨论系统来分析用例。
图书馆的角色定为图书管理员和借书人。图书管理员是软件系统的用户;而借书者则是来借阅或预定图书杂志的客户。偶尔,图书管理员或图书馆的其他工作人员也可能是一个借书者。借书者不直接和系统交互,借书人的功能由图书管理员代为执行。
图书馆系统中的用例有:
1. 借书
2. 还书
3. 预定
4. 取消预定
5. 增加标题
6. 修改或删除标题
7. 增加书目
8. 删除书目
9. 增加借书者
10. 修改或删除借书者
上面所列的用例中没有维护,维护是一个使用其它用例的更一般的用例。同时,还应注意到上述用例中出现的两个概念:标题(Title) 和书目(Item) 。因为在一个图书馆中,一个流行的标题可能有好几本,因此系统必须将标题(可能是书名或书的作者)同其它的书目(代表一个指定标题的物理副本)区分开来。从图书馆借的是书目。在图书馆拥有一本书的副本(书目)之前加一个标题到系统中是可能的,这样做的目的是让借书者可以预订。
图书馆系统分析的结果写在UML 用例图中。每一个用例都附带有文本文档,描述用例和客户交互的细节。文本是通过与客户讨论得到的。用例“借书”描述如下:
:
确定标题
确定该标题下有效的书目
确定借书者
图书馆将书借出
登记一个新的借阅
:
确定借书人
确定标题
确定该标题下有效的书目
图书馆将相应的书目借出
登记一个新的借阅
取消预定
除了定义系统的功能需求之外,在分析过程中用例用于检查是否有相应的域类已经被定义,然后他们可以被用在设计阶段,确保解决方案可以有效地处理系统功能。可以在顺序图中可视化实现细节。
角色和用例。分析中的第一步就是指出系统能被用来做什么,谁将去使用它。它们分别就是用例和角色。所有的用例必须始于角色,而且有些用例也结束于角色。角色是位于你所工作的系统外部的人或其他系统。一台打印机或一个数据库都可能是一个角色。本系统有两个角色:借阅者和图书管理员。通过与用户或客户的讨论,可以将每一个用例用文字进行说明。
问题域分析(Domain Analysis)
系统分析也详细地列出了域(系统中的关键类)。为了导出一个域分析,可以阅读规范文档(specifications)和用例,查找哪一些概念应该被系统处理。或者组织一个集体讨论,在用户及领域专家共同的参与下指出系统中必须处理的关键概念,以及它们之间的关系。
其中有些类有UML 状态图,用来显示这些类的对象可能具有的不同状态,以及触发他们的状态发生改变的事件。该例子中有状态图的类是item 和title 类。
(Design)
设计阶段对分析模型进行扩展并将模型进一步细化,并考虑技术细节和限制条件。设计的目的是制定一个可行的解决方案,以便能很容易地转变成为编程代码。
设计可以分成两个阶段:
体系