用户界面的UML建模12

图14：同步BookStatusUI 模型

我们还可以使用一些上面没有讨论到的UML 特性来对同步UI 进行建模：使用粗线表示的类，具有一个信号隔间（signal compartment）的类，一个依赖关系的时间约束，和构造型《signal》。因此，在解释模型之前，我们需要先来解释一下这些特性。

􀂄 BookStatusController 和StockItem 上的粗线是指这些类的实例为主动对象（active object）。
实际上，BookStatusController 实例必须具有一些主动的行为来“接收”（receive）由StockItem 实例所产生的StockUpdate 事件。

􀂄 约束{every update}，位于StockItem 和StockUpdate 之间的《send》依赖中，则是指当
StockItem 每次被更新时，StockItem 实例都必须产生一个StockUpdate 事件。该约束的意思是StockItem实例具有一种主动的机制来标识状态的更新。

􀂄 构造型《signal》指的是该类的实例将会发送信号来通知系统，当前产生了一个StockUpdate 类型的事件。在该环境（context）下，这个事件是则指StockItem 类的对象正在将藏书项（stock item）的更新状态推（push）给那些监听该种事件的类。

􀂄 BookStatusController 中的Signals 隔间，则标识了该类的实例能够作为StockUpdate 事件的
监听器（listener）。这便意味着每当一个StockUpdate 事件产生时，该实例便可作为监听器被通知。

让我们回到图14 所示的类图中去，可以注意到每当发生一个StockItem 的更新时，则StockItem 实例便会产生一个StockUpdate 同步事件，该同步事件具有这个藏书项的当前状态。然后，BookStatusController实例将会监听到这些事件，并发送消息至《boundary》类的实例，进行数据的更新显示。信号StockUpdate内部的属性stockCode 可作为一种身份鉴别机制，以防止BookStatusController 对象显示的是不同库存项的状态。

该建模方法尤其适合那些以同步UI 为主的系统。事实上，《entity》对象内部所用的推机制的复杂程度是相同的。举个例子来说，复杂的《entity》对象可能具有许多可以改变其状态的操作。然而，由于对状态的更新进行监听，则使用该建模方法就不必再对对象内部方法中的那些状态修改进行标识。此外，《entity》对象无论是被一个或多个《boundary》对象来显示，其推机制的复杂程度都是相同的。实际上，发往每个对象的事件都具有一个签名（signature）。所以说，一个单独的同步事件无论有多少个监听器，都能够进行通知。

7 装配：打包应用程序

图15：图书馆系统的包图

图15 所示的包图（package diagram）给出了整个系统的概况。进一步而言，该包图展示了系统各个组件之间的依赖关系。

类和类的实例被分成六个包（package），如下。

􀂄 User Interface 包由《boundary》类及其对象组成。
􀂄 Abstract Presentation Model 包由图6 所示的《apm》类组成。
􀂄 Control 包由《control》类组成。这些类可参见图6。
􀂄 Domain Model 包是由《entity》类组成。这些类的类图可参见图2 中所示的领域模型。
􀂄 Environment 包则包括那些用于构建用户界面的类。环境可以是一门面向对象的程序设计语言，如C++[18]，Java[6]和Smalltalk，也可以是一些组件，如ActiveX 和Java Bean，或者甚至是组件和面向对象程序设语言的组合体。环境主要是作为用户界面的可视化部分来考虑的，但它还可以对用户界面的行为进行负责，特别是在使用复杂组件的时候。