图书馆信息系2e统2分析.doc

图书馆信息系2e统2分析

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

18

个人收集整理 勿做商业用途
图书馆信息系统面向对象分析实例
。
总体问题的陈述：本项目的目的是创建一个用于对图书馆的图书进行管理的图书管理系统。
该项目的用户：该1项目的用户是一个某大学的图书馆，它负责对其顾客提供图书借阅服务。
该项目的目标：总体上来说，项目的目标是提高图书管理的自动化水平，为图书业务过程提供更快捷的、更好的和更33准确的服务。具体来讲,系统的目标包括：为借书者提供快速借书的服务；进行快速准确的图书和借书者的信息维护;图书管理和查询的自动化。
该系统的功能:系统功能是系统应该做的事情,例如系统提供的预定功能。应该识别出这些功能并把它们列入到逻辑相关联的功能慰问组中。
注意：要验证某一个描述是否真是一个系统的功能,如下的判断语句应该成立：
系统应该做某一个描述
例如，系统应该做图书的预定。
然而，系统的属性是系统的非功能性的特性,这些非功能性特性和系统功能经常被混淆。例如，“易于使用”就是一个非功能性的特性。它是不符合我们上述的验证语句:“系统应该做易于使用”。系统属性不应该是功能规格说明书中的一部分，而应该是一个单独的系统属性规格说明文档.
对于系统的功能，我们应该对其分类，以便区分开各类功能的优先次序和识别出哪些是理所当然应该具备的系统功能。功能的分类包括:
明显的:应该履行的功能，并且用户应该知道这个功能是否已经被履行。
隐藏的：应该履行的功能,但功能的履行对用户不可见.很多使用底层技术的服务确实符合这种情况，例如,将数据保存到一个持久化存储机构中。隐藏的功能经常在采集需求的过程中被遗漏.
修饰性的:可选的，增加这些功能不会对成本和其它系统造成重要影响。
为此，我们给出该系统的借书基本功能如下:
F1.1记录借出的图书-—--借阅事件 明显的
F1。2 查找书库中是否存在这种图书 明显的
F1.3 从借书卡中读取借书者信息，并校验该信息 明显的
F1.4 查找书库中这本书是否还有副本 隐藏的
F1.5 当一次借阅完成后,削减该书的副本存书数量 隐藏的
F1。6 管理员要使用系统,必须输入ID号和密码才行 明显的
F1。7 查询显示借书信息 明显的
F1.8 提供一个持久化存储机制 隐藏的
F1.9 提供过程间的和系统间的通信机制 隐藏的
系统属性:系统属性是系统的特性，它们并不是系统的功能，例如:易用、容错、响应时间、界面形式、平台等。系统属性具有一组可能的属性细节，这些属性细节往往是属性的一些离散的、表达模糊的符号值,例如：
响应时间=（生理上能够接受的时间段)
界面形式=(图形化的，基于表的，彩色比较平淡的）
在我们的案例中，要求借书查找时间小于1秒。

我们结合上面的图书馆管理系统的案例，来给出图书管理系统的问题域模型。我们首先看问题域中的图书、借阅、书目和借书者这四个类。
系统将通过计算机来处理图书、副本、借书者和借阅。借书者要求借书,给出要借图书的名称，出示借书证。系统查找所借的图书是否存在，若存在，同时还要查看该图书是否还有副本，如果有，再查询该借书者提供的借书证是否合法的注册用户，如果是，则办理借阅手续（登记借阅信息）。
图书是存放在图书馆中的一个书的名称，副本是一个图书的具体实例.一个图书可能有多个副本,一个副本一定会对应一个图书。为简化起见，我们假定一次借阅（登记）只能借一本图书,同时会对应着一个借书证信息。一个借书者可以进行多次借阅。
首先找出业务对象：图书、副本、借书证。
系统需要处理的现实世界中的对象和概念：借阅、预定.
将要发生或已经发生的事件：已经预定。
下面给出其UML表示的问题域的类图。

图—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、将图书送出,提示借书者拿走图书

图2-2 业务系统级的顺序图
七、打开业务系统，找出业务系统内部的业务对象模型元素
根据前面的需求说明，我们知道图书馆内部情况如下：
作为图书馆工作人员的图书管理员,他们负责为借书者服务，并操作各种业务实体来完成图书馆的各种业务流程.
作为图书馆内部的业务实体有：图书借阅登记、图书预定登记、图书信息卡、图书副本、借书人信息等.
每登记一次图书借阅,需要登记图书名称、借书者名称以及图书副本号等信息。
每登记一次图书预定，需要登记图书名称和借书者信息.具体的系统内部结构图见图2-3.

图2—3 图书馆业务系统内部业务对象模型元素
八、写出详细的事件处理流描述
事件流描述：借书
借书者到图书馆里选择了喜欢的图书之后，要求图书管理员办理借书手续，图书管理员使用图书管理系统登记所借图书的借阅资料.首先，图书管理员向图书借阅登记输入图书名称，图书借阅登记请图书信息卡查找所借的图书是否存在，如果该图书存在,则图书信息卡请图书副本检查该图书是否还有副本，如果有,进行下面的工作；图书管理员请借书者提供借书者信息。借书者请图书管理员登记借书者信息,图书管理员向图书借阅登记输入借书者信息，图书借阅登记请借书者信息核对该信息是否有效；如果有效，图书借阅登记将登记相应的借书者信息、图书信息卡和图书副本。处理完成后，提示图书管理员登记完毕，图书管理员将借书者所要借的图书交给借书者，借书者拿着图书离开图书馆.
九、绘制业务系统详细顺序图（Sequence diagram）
根据上面的借书事件流描述，我们可以给出借书业务的顺序图，如图2—4.
通过顺序图我们可以看到每一个对象的责任：
借书者：通过请求借书，启动借书流程；向图书管理员提供图书名称和借书者信息；拿走图书。
图书管理员：接受借书请求,启动系统的借书流程；接受借书者提供的图书名称、借书者信息；向图书借阅登记对象提供图书名称和借书人名称;提示借书人拿走图书.
图书借阅登记:接受并执行借书登记;接受并执行查找图书；接受并执行核对借书人信息。
图书信息卡：负责查找图书。
图书副本:负责查找核实空闲的副本.
借书人信息：负责查找核实借书人，确认其为合法的借书人。
应当注意的是，借书事件流的描述并非只有以上的一种描述方式，它将随着业务处理方式的不同而改变。比如，我们也可以这样描述：
借书者到图书馆里选择了喜欢的图书之后,将选定的图书名称和借书者信息交给图书管理员,要求图书管理员办理借书手续，图书管理员使用图书管理系统登记所借图书的借阅资料。首先，图书管理员向图书借阅登记输入图书名称和借书者信息，请图书借阅登记处理借书登记业务，图书借阅登记请图书信息卡查找所借的图书是否存在,如果该图书存在,则请图书副本检查该图书是否还有副本,如果有，进行下面的工作；图书借阅登记请借书者信息核对该信息是否有效，如果有效，图书借阅登记将登记相应的借书者信息、图书信息卡和图书副本.处理完成后，提示图书管理员登记完毕,图书管理员将借书者所要借的图书交给借书者，借书者拿着图书离开图书馆.
这样的操作过程必然产生不同的顺序图.它明显地减少了图书管理员与借书者之间的交互次数。这种方式所产生的顺序图见图2—5。

图2—4 业务系统打开后的顺序图
在建立业务模型时，术语表也是一个重要的内容，它是在前面已经建立的问题域模型的基础上进行增补而形成的。下面我们给出图书管理系统业务模型的术语表：
图书信息卡：图书信息卡是图书馆内最重要的对象，它是系统处理主要对象，图书信息卡是某一本图书的信息描述,它包含了图书的名称，图书的作者以及图书的ISBN统一出版编号等内容.
图书副本：图书副本是图书的一个实例,一个图书信息卡可以有多个图书副本，也可以没有图书副本。图书副本是借书时的真正对象.只有一个图书信息卡有可以供借阅的图书副本时,借书者才可以对其借阅。
借书者信息：业务中的借书者信息记录了借书者的重要信息，包括借书者的姓名、住址、居住城市、居住省、身份证号码、邮政编码、电话号码等内容。
图书 借阅登记:图书 借阅登记是图书管理中的一个最重要的业务活动,它需要进行一系列的操作才能完成一个图书 借阅登记业务，包括查找图书、查找副本、核对借书证(借书者信息)等步骤。
预定：预定是图书管理中的一个业务活动，它也需要一系列的操作才能完成。
书籍：书籍是图书的一种形式.
杂志:杂志也是图书的一种形式。
图书管理员：图书馆的工作人员,直接为借书者提供服务的人，也是系统的直接使用者。
借书者：到图书馆借书的人，属于图书馆的用户（服务对象）。

图2-5 另一种借书业务处理事件流产生的顺序图
十、形成业务模型的对象模型
在前面的第七步，我们找出了一些比较重要的对象模型元素，结合前面的问题域模型的类图进行修改和补充,我们可以得到业务系统的对象模型。见图2—6。

图2—6 图书馆业务系统对象模型
业务系统对象模型类图中的关系说明如下：
1、一个图书信息卡可以有多个同名图书副本。
2、每一个图书副本一定要对应一个图书信息卡.
3、一次图书借阅登记必须记录一个图书副本和一个借书人信息。
4、一个图书副本可以被借阅，也可以不被借阅。
5、一个借书人信息可以进行多次图书借阅登记，也可以没有图书借阅登记.
6、一个借书人信息可以进行多次图书预定登记，也可以没有图书预定登记。
7、一次图书预定登记必须记录一个图书信息卡和一个借书人信息.
8、一个图书信息卡可以被多次预定，也可以不被预定.
9、书籍和杂志是图书信息卡的特殊类。它们之间具有一般特殊结构。
A、系统参与者描述
图书管理员
图书管理员是与计算机系统实际交互的活动者.图书管理员通过增加和删除标题、书目和借书者来维护系统，同时也执行像借书、还书、预定书目给、给出有关存储在系统中的数据的信息等执行系统关键性的功能。这些功能是为借书者服务的.
借书者
借书者可以借阅和预定书和杂志。借书者可以是一个人或另一个图书管理员。

图书管理用例图

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．如果借阅者有预定：
确定借书人
确定标题
确定该标题下有效的书目
图书馆将相应的书目借出
登记一个新的借阅
取消预定
除了定义系统的功能需求之外,在分析过程中用例用于检查是否有相应的域类已经被定义,然后他们可以被用在设计阶段，确保解决方案可以有效地处理系统功能。可以在顺序图中可视化实现细节。
角色和用例.分析中的第一步就是指出系统能被用来做什么，谁将去使用它.它们分别就是用例和角色。所有的用例必须始于角色，而且有些用例也结束于角色.角色是位于你所工作的系统外部的人或其他系统.一台打印机或一个数据库都可能是一个角色。本系统有两个角色：借阅者和图书管理员。通过与用户或客户的讨论，可以将每一个用例用文字进行说明。

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 用例的顺序图。实际的操作和特征值从在线模型代码中可以看到。