然而，在用戶界面方面，重要的是要了解《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》對象來產生同步事件。