然而，在用户界面方面，重要的是要了解《boundary》类是如何与这个异常分层结构进行关联的。

《exception》类的对象可以作为《control》类的对象。因此，《exception》类能够聚合《boundary》类。

参见图12，《exception》DatabaseFail 则是作为一个《control》类，来对《boundary》DatabaseFailUI类进行处理。可以使用构造型《handles》来标识《boundary》类及其控制者的关系。

6.1.2 UI 异常处理的行为

异常也会影响用户界面的任务模型，这是因为它们能够更改一次用户交互中的活动控制流。例如，图3(b)中的活动Perform search 在执行一次查询时可能会引发一个数据库异常（database exception）。

由于UML 的活动图提供了一种分支标记，使得我们能够直接建模那些在任务模型的控制流中所可能做出的改动。根据布尔型的警戒表达式，可选择不同路径外向转移（outgoing transition）至不同的活动中去。为了对异常处理进行建模，图13 中扩展了图3(b)所示的活动图。在执行Perform search 中发生异常时，活动Perform search之后的一个分支（标识为一个菱形）可以选择不同的路径来对控制流进行更改。当一个ODMGException 异常没有被其处理者进行处理时， 警戒条件[non-solved ODMGExceptions] 便会将控制流的路径选择到HandleODMGException 活动上去。否则，控制流则按照正常的路径进行（由关键字else 进行标识）。

图13：任务模型中的异常

6.2 同步事件建模

同步UI（synchronous UIs）指的是那些当《boundary》对象可见（visible）时，能够频繁地对所显示的数据进行更新的UI。否则便为异步UI（asynchronous UIs）。

用户界面，特别是指图形用户界面，通常用异步消息（asynchronous messages）[4]来实现。所以另外一个需要考虑的问题便是，如何只使用异步消息来对同步UI 进行建模。解决这个问题的一般思路是，按照所要求的频率通过数据更新来完成《boundary》对象的刷新（refresh）。由于事件的产生能够引起UI 的更新，因此可将其作为同步UI 建模的一种可能的方法。在该种情况下，产生的事件称为同步事件（synchronisation event）。我们能够很自然地想到，《entity》对象能够产生同步事件，因为它们是存储更新数据的地方。而《boundary》和《control》对象也能够产生同步事件，但是由于它们在产生每个同步事件时，需要对《entity》进行查询来获取所需的更新数据。

因此在这里，我们只考虑同步事件由《entity》对象产生这一种情况。

图14 所示的类图表明了一种可能的建模方法，即使用《entity》对象来产生同步事件。