图书馆信息系统UML 实例

《图书馆信息系统UML 实例》由会员分享，可在线阅读，更多相关《图书馆信息系统UML 实例（18页珍藏版）》请在金锄头文库上搜索。

1、图书馆信息系统UML 实例1需求（Requirements） 典型地，由系统最终用户的代表写出文 本形式的需求规范文档。对于该图书馆应用 程序来说，需求规范文档应该类似于这样： 1. 这是一个图书馆支持系统； 2. 图书馆将图书和杂志借给借书者。借书者 已经预先注册，图书和杂志也预先注册； 3. 图书馆负责新书的购买。每一本图书都购 进多本书。当旧书超期或破旧不堪时，从图 书馆中去掉。 4. 图书管理员是图书馆的员工。他们的工作 就是和读者打交道并在软件系统的支持下工 作。 5. 借阅人可以预定当前没有的图书和杂志。 这样，当他所预定的图书11和杂志归还回来 或购进时，就通知预定人。当预定了某

2、书的 借书者借阅了该书后，预定就取消。或者通 过显式的取消过程强行取消预定。 6. 图书馆能够容易地建立、修改和删除标题、 借书者、借阅信息和预定信息。7. 系统能够运行在所有流行的技术环境中， 包括Unix, Windows 和OS/2，并应有一个现 代的图形用户界面(GUI)。 8. 系统容易扩展新功能。 系统的第一版不必考虑预定的图书到达后通 知预定人的功能，也不必检查借书过期的情 况。2分析（Analysis） 系统分析的目的是捕获和描述所有的系 统需求，并且建立一个模型来定义系统中主 要的问题域类。通过系统分析达到开发者和 需求者的理解和沟通。因此，分析一般都是 分析员和用户协作的产

3、物。 在这个阶段，程序开发者不应该考虑代码或 程序的问题；它只是理解需求和实现系统的 第一步。21 需求分析（Requirements Analysis） 分析的第一步是确定系统能够做什么？ 谁来使用这个系统？这些分别叫角色 （actors）和用例（use cases）。用例描述 了系统提供什么样的功能。通过阅读和分析 文档，以及和潜在的用户讨论系统来分析用 例。 图书馆的角色定为图书管理员和借书人。 图书管理员是软件系统的用户；而借书者则 是来借阅或预定图书杂志的客户。偶尔，图 书管理员或图书馆的其他工作人员也可能是 一个借书者。借书者不直接和系统交互，借书人的功能由图书管理员代为执行。 图

4、书馆系统中的用例有：1. 借书 2. 还书 3. 预定 4. 取消预定 5. 增加标题 6. 修改或删除标题 7. 增加书目 8. 删除书目 9. 增加借书者 10. 修改或删除借书者 上面所列的用例中没有维护，维护是一个使 用其它用例的更一般的用例。同时，还应注 意到上述用例中出现的两个概念：标题(Title) 和书目(Item) 。因为在一个图书馆中，一个 流行的标题可能有好几本，因此系统必须将 标题(可能是书名或书的作者)同其它的书目 (代表一个指定标题的物理副本)区分开来。 从图书馆借的是书目。在图书馆拥有一本书 的副本(书目)之前加一个标题到系统中是可 能的，这样做的目的是让借书者可

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

6、，谁将去使用它。它们 分别就是用例和角色。所有的用例必须始于 角色，而且有些用例也结束于角色。角色是 位于你所工作的系统外部的人或其他系统。 一台打印机或一个数据库都可能是一个角色。 本系统有两个角色：借阅者和图书管理员。 通过与用户或客户的讨论，可以将每一个用 例用文字进行说明。借书者预定删除预定借出书目图书管理员返还书目图书管理员增加标题删除或更新标题增加书目删除书目增加借书者系统维护删除或更改借书者22 问题域分析（Domain Analysis） 系统分析也详细地列出了域（系统中的关键 类）。为了导出一个域分析，可以阅读规范 文档（specifications）和用例，查找哪一些概 念

7、应该被系统处理。或者组织一个集体讨论， 在用户及领域专家共同的参与下指出系统中 必须处理的关键概念，以及它们之间的关系。其中有些类有UML 状态图，用来显示这些 类的对象可能具有的不同状态，以及触发他 们的状态发生改变的事件。该例子中有状态 图的类是item 和title 类。LoanedNot loanedItem returnedItem loanedNot reservedReservedTitle reservation / Number of reservations +Reservation removed Number of reservations = 1 / Number o

8、f reservations -Title reservation / Number of reservations +Reservation removed Number of reservations 1 / Number of reservations -3设计（Design） 设计阶段对分析模型进行扩展并将模型进一 步细化，并考虑技术细节和限制条件。设计 的目的是制定一个可行的解决方案，以便能 很容易地转变成为编程代码。 设计可以分成两个阶段： 体系结构设计阶段（ Architecture Design）。这是一个从较高层次的进行的设 计，用来定义包（子系统），描述包之间的 依赖性及通

9、信机制。很自然，目的是要设计 一个清晰简单的体系结构，有很少的依赖性， 而且尽可能避免双向依赖。 详细设计阶段（ Detailed Design）。在 此阶段，所有的类都详尽地进行描述，给编 写代码的程序员一个清晰的规范说明。UML 中的动态模型用来说明类的对象如何在特定 的情况下做出相应的表现。 31 体系结构设计 一个良好的体系结构设计是一个可扩展 的和可改变的系统的基础。包可能关注特定 的功能领域或关注特定的技术领域。把应用 程序逻辑（域类）和技术逻辑分开是至关重要的，这样不管哪一部分的改变都不会影响 其他的部分。 本案例的包或叫子系统如下： User-Interface Package

10、 包。该包中的类 基于Java AWT 包，java AWT 是一个用来书 写用户界面应用程序的Java 的标准库。该包 和Business-objects Package 包协作。 Business-objects Package 包包含那些实际存 储数据的类。UI 包调用Business 对象的操作， 对他们进行取出或插入数据操作。 用户接口包显示了所有的在用户接口中 的类，以及它们与其它类（即，在业务对象 类）之间的关系和协作。用户接口描述了四 个类图：1、基本类图：该图显示了 StartClass，该类 包含了整个应用软件的主操作，并且只有它 才可以激活主窗口（MainWindow）

11、。主窗口 包含了一个菜单，该菜单被用来访问在应用 系统中所有的其它窗口。 2、功能类：它显示了所有的用在 MenuBar “Functions”中的窗口类。这些窗口包含了 对于租借和返还书目以及预定书目和取消预定的主要功能。 3、信息类：它显示了所有的用在 MenuBar “Information”中的窗口类。这些类都是为 了查看有关标题和租借者信息以及浏览所有 的标题和所有的租借者的信息。 4、维护类：它显示了所有的用在 MenuBar “Maintenance”中的窗口类。这些类都是为 了系统维护的，如增加、删除和更新标题、 书目和租借者信息。 UI 包同样也包含了对所有在分析中多定 义的

12、用例顺序图，它显示了这些用例在设计 阶段的实现。用例现在被细化成在设计类图 中的实际操作，因此，这些顺序图可以阅读， 用来理解实际代码。有些顺序图同样也被转 换成协作图。Business-object Package。该包包括域类， 这些域类（如 borrowerinformation，title，item，loan 等） 来自于分析模型。设计阶段完整地定义了这 些类的操作，并增加了一些其他细节来支持 持续存储。Business-object 包与Database Package 进行协作。所有的Business-object 类必须继承Database Package 中的persisten

13、t 类。 Database Package。Database Package 向 Business-object 包中的类提供服务，以便他 们能够持续地存储。 在当前版本中，persistent 类将把它的子 类的对象存储到文件系统的文件中。 Utility Package。Utility Package 包含了一 些服务，用来被系统中其他包调用。当前， ObjId 类是该包中的唯一的类。用来被整个 系统包括User-Interface，Business-Object 和 Database package 使用。 这些包的设计如图所示.图：图书馆应用程序体系结构设计总览。本类 图显示了应用程序

14、包以及它们之间的依赖性。Database 包提供了persistence 类。 Utility 包提供了Object ID 类。Business- Object 包包含了域类（详细情况参见类图） 最后，UI 包（在本例中它是基于标准Jaa AWT 库）调用business 对象中的操作来实现 对他们的数据存取操作。 3 32 2 详细设计详细设计 细节设计描述了新的技术性的类， 如User- Interface 和Database 包中的类，并且丰富 了分析阶段所形成的Business-Object 类。 类图、状态图和动态图用的还是分析阶段所 形成的图，但对他们定义的更加详细，具有 了更高的

15、技术水平。在分析阶段对用例进行 的文字性描述在此用来证明用例在设计阶段 也能被处理。顺序图就是用来说明用例如何 在系统中被实现的。 Database Package。应用程序必须有持 续存储的对象。因此，必须增加数据层来提 供这样的服务。为简单起见，我们将对象以文件的形式保存在磁盘上。存储的细节被应 用程序隐藏起来，只需调用诸如store（）， update（），delete（）和find（）这样的 公共操作即可。这些都是persistent 类的一 部分，所有需要持续对象的类必须继承它。 对类进行持续处理的一个重要因子就是 ObjId 类。它的对象用来引用系统中的任何 持续对象（不管这个对象

16、是在磁盘上还是已 经被读进了应用程序之中）。ObjId 是 Object Identity 的简写，它是一个广为应 用的技术，用来有效地处理应用程序中的对 象引用。通过使用object identifiers，一 个对象ID 能被传递到普通的 persistent.getobject（）操作中，进而该 对象将被从持续的存储体中取出或存储。通 常情况下，这些都是通过每个持续类的一个 getobject 操作完成的。当然，持续类同时 也作一些检查或格式转换的操作。一个对象 标识符也能作为一个参数很容易地在两个操 作之间传递（例如，一个查找特定对象的查 询窗口可以将它的查询结果通过object id 传递给另一个窗口）。ObjId 是一个系统中所有的包（User Interface , Business Object 和 Database）都能使用的通用类，所以在设计 阶段它被放置在Utility 包中，而不是放在 Database 包中。 当前对persistent 类的实现还能改进。 为