第二节详细设计 详细设计描述新的类--在用户界面和数据库包中的类，以及在本分析中描绘的商业对象类以外的人。本类的状态和动态图表使用的是与分析过程中一样的图表，但是它们被定义在更加详细和更高的技术层次，分析过程中的使用案例描述用于验证在设计阶段处理的使用案例，使用序列图表阐明在系统中，每个使用案例是如何在技术上实现的。
数据库包应用程序必须有持久储存对象，所以必须添加一个数据库层来提供这个服务，为了简单起见，我们把对象作为文件储存在磁盘上，关于存储器的细节就不需要被应用程序所知了，它调用通用操作，比如store()、update()、delete()和find()等等，这些都是一个调用Persistent的类的一部分，所有的类都需要继承Persistent（持久对象）。
持久性处理中的一个重要的因素就是ObjId类，它的对象用于引用任何系统中的持久对象(无论对象是在磁盘上还是已经被读入应用程序中了)。ObjId是Object Identity的简写，是一种熟知的技术，用于处理应用程序中的对象引用。通过使用对象标识，一个对象标识号就能被传递到Persistent.getObject ( )操作，然后该对象将从持久存储器中取回。通常，这要通过每个持久类中的getObject操作来完成，它还要执行必要的类型检查和转换。对象标识号还可以很容易地作为操作的参数被传递(例如，一个寻找具体对象的搜索窗口可以通过对象标识号传递它的结果到另外一个窗口)。
ObjId标识系统（用户界面、商业对象和数据库）中所有的包使用的一个常规类，因此它在设计阶段就被放进实用程序包中而不是数据库包中。Persistent类的当前实现还可以不够完善，它的最终目标是可以很容易的改变持久存储器的实现，目前的替代的办法是把对象出存在关系数据库或面向对象数据库中，也可以使用Java中的持久对象支持储存它们。
商业对象包在设计阶段中的商业对象包基于分析过程中相应的包——讨论域类。类以及它们的相互关系和行为没有变，但是类被描述的更加详细，包括了它们的相互关系和行为如何实现。
一些操作已经被翻译成好几个设计模型中的操作，一些还被改了名称，这都是很正常的，因为分析只是每个类的能力的描绘，而设计则是系统详细的描述，因此设计模型中的所有的操作都必须有定义好的特征和返回值，注意，下面给出了设计与分析的不同。
 图5解释商业对象设计。这张图表充实了商业对象程序包的各种不同的类的设计。接口更加精确，选择了属性的数据类型。 |
系统的当前版本不必检查一本书是否及时归还，也不必处理预借书籍的订单，因此Loan和Reservation类的日期属性就没有实现。
杂志和书的处理过程是完全相同的，除了借期的不同，而且它还不用处理。在分析中，Magazine和Book Title子类已经被认为不必要的并且在Title类中只有一个类型属性指定该书名是否指出一本书或杂志。在以后的应用程序版本中，如果认为有必要的话，这两个简化都可以删除。
分析过程中的状态图表在设计阶段又被细化了，显示在工作系统中状态如何被表示以及被处理。Title类的设计状态图表如图6。其他对象可以通过调用addReservation ( )和removeReservation ( )操作来改变Title的状态，就像这张图表中所显示的那样。
 图6解释设计Title的状态图 |
用户界面包用户界面包总是在其他包之前，在系统中，它给用户提供服务和信息，显然，这个包基于标准的Java AWT ( Abstract Window Toolkit )类。设计模型中的动态模型已经被分配到GUI包中，因为所有的与用户的交互作用都是通过用户界面开始的，此外，我们还选择序列图表来说明动态模型，本使用案例的设计模型的实现都是用细节描述的，包括类中的实际的操作。序列图表实际上是以一系列迭代的形式创建的。在实现(即编码)阶段更多的细节上的发掘会产生更进一步的迭代。图7表明Add Title的结果设计序列图表。
 图7解释Add Title的序列图 |
我们还可以使用协作图表代替序列图表，象图8。
 图8解释Add Title的协作图。 |
