图书馆信息系统UML-实例.doc

图书馆信息系统UML 实例

———————————————————————————————— 作者：
———————————————————————————————— 日期：

20

个人收集整理 勿做商业用途
图书馆信息系统UML 实例

1．需求（Requirements）
典型地，由系统最终用户的代表写出文本形式的需求规范文档。对于该图书馆应用程序来说，需求规范文档应该类似于这样：
1。 这是一个图书馆支持系统；
2. 图书馆将图书和杂志借给借书者。借书者已经预先注册,图书和杂志也预先注册；
3. 图书馆负责新书的购买。每一本图书都购进多本书。当旧书超期或破旧不堪时，从图书馆中去掉。
4. 图书管理员是图书馆的员工。他们的工作就是和读者打交道并在软件系统的支持下工作。
5。 借阅人可以预定当前没有的图书和杂志。这样，当他所预定的图书11和杂志归还回来或购进时，就通知预定人。当预定了某书的借书者借阅了该书后，预定就取消。或者通过显式的取消过程强行取消预定。
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．如果借阅者有预定：
确定借书人
确定标题
确定该标题下有效的书目
图书馆将相应的书目借出
登记一个新的借阅
取消预定
除了定义系统的功能需求之外，在分析过程中用例用于检查是否有相应的域类已经被定义，然后他们可以被用在设计阶段，确保解决方案可以有效地处理系统功能。可以在顺序图中可视化实现细节。
角色和用例。分析中的第一步就是指出系统能被用来做什么，谁将去使用它。它们分别就是用例和角色.所有的用例必须始于角色，而且有些用例也结束于角色。角色是位于你所工作的系统外部的人或其他系统.一台打印机或一个数据库都可能是一个角色。本系统有两个角色:借阅者和图书管理员。通过与用户或客户的讨论，可以将每一个用例用文字进行说明。

2．2 问题域分析（Domain Analysis）
系统分析也详细地列出了域(系统中的关键类)。为了导出一个域分析,可以阅读规范文档(specifications）和用例，查找哪一些概念应该被系统处理。或者组织一个集体讨论，在用户及领域专家共同的参与下指出系统中必须处理的关键概念，以及它们之间的关系。

其中有些类有UML 状态图,用来显示这些类的对象可能具有的不同状态，以及触发他们的状态发生改变的事件。该例子中有状态图的类是item 和title 类。

3．设计（Design)
设计阶段对分析模型进行扩展并将模型进一步细化,并考虑技术细节和限制条件。设计的目的是制定一个可行的解决方案,以便能很容易地转变成为编程代码.
设计可以分成两个阶段：
体系结构设计阶段（ Architecture Design）。这是一个从较高层次的进行的设计，用来定义包（子系统），描述包之间的依赖性及通信机制。很自然，目的是要设计一个清晰简单的体系结构，有很少的依赖性，而且尽可能避免双向依赖.
详细设计阶段（ Detailed Design）.在此阶段，所有的类都详尽地进行描述，给编写代码的程序员一个清晰的规范说明.UML 中的动态模型用来说明类的对象如何在特定的情况下做出相应的表现.
3．1 体系结构设计
一个良好的体系结构设计是一个可扩展的和可改变的系统的基础。包可能关注特定的功能领域或关注特定的技术领域.把应用程序逻辑（域类）和技术逻辑分开是至关重要的，这样不管哪一部分的改变都不会影响其他的部分。
本案例的包或叫子系统如下：
User—Interface Package 包。该包中的类基于Java AWT 包,java AWT 是一个用来书写用户界面应用程序的Java 的标准库。该包和Business—objects Package 包协作.Business-objects Package 包包含那些实际存储数据的类。UI 包调用Business 对象的操作，对他们进行取出或插入数据操作。
用户接口包显示了所有的在用户接口中的类,以及它们与其它类（即,在业务对象类）之间的关系和协作。用户接口描述了四个类图:

1、基本类图：该图显示了StartClass，该类包含了整个应用软件的主操作，并且只有它才可以激活主窗口(MainWindow)。主窗口包含了一个菜单,该菜单被用来访问在应用系统中所有的其它窗口。
2、功能类:它显示了所有的用在MenuBar “Functions”中的窗口类。这些窗口包含了对于租借和返还书目以及预定书目和取消预定的主要功能.
3、信息类:它显示了所有的用在MenuBar “Information"中的窗口类。这些类都是为了查看有关标题和租借者信息以及浏览所有的标题和所有的租借者的信息.
4、维护类：它显示了所有的用在MenuBar “Maintenance”中的窗口类。这些类都是为了系统维护的,如增加、删除和更新标题、书目和租借者信息。
UI包同样也包含了对所有在分析中多定义的用例顺序图，它显示了这些用例在设计阶段的实现。用例现在被细化成在设计类图中的实际操作,因此，这些顺序图可以阅读,用来理解实际代码。有些顺序图同样也被转换成协作图。

Business—object Package。该包包括域类,这些域类（如borrowerinformation,title,item,loan 等）来自于分析模型。设计阶段完整地定义了这些类的操作，并增加了一些其他细节来支持持续存储。Business—object 包与Database Package 进行协作。所有的Business—object 类必须继承Database Package 中的persistent 类。
Database Package。Database Package 向Business—object 包中的类提供服务，以便他们能够持续地存储。
在当前版本中,persistent 类将把它的子类的对象存储到文件系统的文件中.
Utility Package。Utility Package 包含了一些服务，用来被系统中其他包调用。当前，ObjId 类是该包中的唯一的类。用来被整个系统包括User-Interface，Business—Object 和Database package 使用。
这些包的设计如图所示。

图:图书馆应用程序体系结构设计总览.本类

图显示了应用程序包以及它们之间的依赖性.
Database 包提供了persistence 类。Utility 包提供了Object ID 类。Business-Object 包包含了域类（详细情况参见类图）最后，UI 包（在本例中它是基于标准Jaa AWT 库）调用business 对象中的操作来实现对他们的数据存取操作。
3．2 详细设计
细节设计描述了新的技术性的类, 如User—Interface 和Database 包中的类，并且丰富了分析阶段所形成的Business—Object 类.类图、状态图和动态图用的还是分析阶段所形成的图，但对他们定义的更加详细，具有了更高的技术水平。在分析阶段对用例进行的文字性描述在此用来证明用例在设计阶段也能被处理。顺序图就是用来说明用例如何在系统中被实现的。
Database Package。应用程序必须有持续存储的对象。因此，必须增加数据层来提供这样的服务.为简单起见，我们将对象以文件的形式保存在磁盘上。存储的细节被应用程序隐藏起来，只需调用诸如store(）， update（），delete（）和find（）这样的公共操作即可。这些都是persistent 类的一部分，所有需要持续对象的类必须继承它.
对类进行持续处理的一个重要因子就是ObjId 类。它的对象用来引用系统中的任何持续对象（不管这个对象是在磁盘上还是已经被读进了应用程序之中)。ObjId 是Object Identity 的简写，它是一个广为应用的技术，用来有效地处理应用程序中的对象引用.通过使用object identifiers,一个对象ID 能被传递到普通的persistent。getobject（）操作中，进而该对象将被从持续的存储体中取出或存储。通常情况下，这些都是通过每个持续类的一个getobject 操作完成的.当然,持续类同时也作一些检查或格式转换的操作.一个对象标识符也能作为一个参数很容易地在两个操作之间传递（例如，一个查找特定对象的查询窗口可以将它的查询结果通过object id 传递给另一个窗口）。
ObjId 是一个系统中所有的包（User Interface , Business Object 和Database）都能使用的通用类,所以在设计阶段它被放置在Utility 包中,而不是放在Database 包中.
当前对persistent 类的实现还能改进。为此，定义persistent 类的接口，方便持续存储的改变。一些备选的方案可能是：将对象存储在一个关系数据库中或存储在面向对象的数据库中，或使用Java 1.1 所支持的持续对象来存储他们。
Business—Object Package。设计阶段的Business-Object 包基于相应的分析阶段的放置域类的包.类和类之间的关系以及他们的行为继续保留,只是被描述的更为详细，包括他们的关系和行为如何被实现。
分析模型中的一些操作中被翻译成设计模型的操作，另一些改了名字。这是很正常的事，因为分析阶段得到的是每一个类的草图,而设计阶段是对系统的详细描述。因此，设计模型的操作必须有设计良好的特征值和返回值(由于空间限制,图 没有显示，但他们在在线模型中都有）.注意以下所列的设计和分析阶段的变化：
1. 系统的当前版本不要求检查书目是否按时归还，也不要求处理预定的次序.因此没有在loan 和reservation 类中设置日期属性。
2. 除了最长借阅期外，对杂志和书标题的处理方式是一样的.因此分析阶段的子类magazine title和book title 被认为在设计阶段是不必要的，而是在title 类中增加type 属性来指出该标题引用的是一本书还是一本杂志。在面向对象的设计中不存在设计不能简化分析的说法。
如果认为有必要的话，在将来的版本中这些简化都可以很容易地被取消.
分析阶段的状态图也在设计阶段细化了.状态图显示了如何表示状态及如何在系统中处理状态。设计阶段的title 类的状态图如图6 所示。其他的对象可以通过调用如图所示的操作addreservation（）和removereservation（)来改变title 对象的状态。
User—Interface Package.User—Interface Package 位于其他包的“上面”。在系统中它为用户提供输出信息和服务。正如上面曾经提到的,该包是基于标准Java AWT（abstract windows toolkit)类的.
设计模型中的动态模型放置在GUI 包中,因为所有和用户的交互都从用户界面开始.在此声明，顺序图用来显示动态模型。用例在设计模型中的实现通过顺序图被详细地显示出来，包括类中的实际操作。
顺序图由一系列的交互构成。在实现阶段（编码），考虑到具体情况，可能会有更多的交互。图显示了add title 用例的顺序图.实际的操作和特征值从在线模型代码中可以看到。