UML超新手入門(8)循序圖型
「循序圖型、Sequence diagrams」應該是最常使用的動態模型。UML制定的許多圖型,都是為了要讓複雜的軟體系統架構和行為更容易瞭解,循序圖型就是用來顯示軟體系統行為的動態圖型。 在傳統的軟體系統中,用來表示系統運作的圖型只有類似「活動圖型、Activity Diagrams」的流程圖。但是在物件導向的軟體系統中,傳統的流程圖已經無法表達系統的運作,尤其是在分散式的環境中,例如Java企業元件(Enterprise JavaBean)中的Stateful Session Bean,使用循序圖型可以清楚的呈現出從建立元件到使用的過程: 建立循序圖型主要的基礎在「時間順序」和「合作物件」的概念上,你可以從圖型中清楚的瞭解有哪些物件在完成某一項任務,更重要的是,圖型中可以顯示出完成這樣任務的先後順序: 元素循序圖型由下列的基本元素構成:
物件節點當你決定建立某一項任務的循序圖型之後,要先將參與這項任務的物件找出來,這些物件就是你要放在循序圖型上的物件節點。以下列的範例程式來說,它是一個模擬開飲機的主程式:
這個包含有程式進入點的類別,建立了四個主要的開飲機類別物件,包含這個主程式,這些就是你要在循序圖型上呈現出來的物件節點: 在上圖的範例中,除了「TestThermos」以外,全部都是物件節點,這也是一般比較常見的情況,在循序圖型裡大都是使用物件節點。但是依照上列範例程式來看,「TestThermos」只是一個主程式,並沒有建立物件,所以使用類別節點來表示。在這種情況下,如果類別名稱相對來說不是很重要的話,會用「使用案例圖型」中的行為者來代替: 不過在下列的情形下,你還是得使用類別節點。在模擬開飲機的程式中,有一個將冷水加熱為開水的方法:
如果你需要在循序圖型裡加入這個動作的話,因為不必建立「Heater」類別的物件就可以呼叫「brew」方法,所以會在循序圖型裡使用類別節點。以下列的敘述來說: 顯示將冷水燒成開水任務的循序圖型會像這樣: 生命線與活化區塊循序圖型裡使用生命線來表示物件的時間順序,它的樣式是一條連接物件節點或使用者的虛線。活化區塊指的是物件存活的時間,使用一個條狀的方塊放在生命線上,表示這個物件存在的時間範圍: 訊息循序圖型裡使用「訊息」來表示物件之間的互動,訊息是一個從一個物件到另一個物件的箭頭,在Java的程式碼中,通常是代表方法的呼叫或使用建構式: 上列圖型對應的程式碼會像這樣:
在物件之間的訊息傳遞,使用下列的語法來宣告: 在上列的語法中:
在循序圖型裡通常只會使用操作名稱和參數。下列的圖型是使用其它選項的範例: 如果不在訊息傳遞時指定操作的回傳值,也可以使用下列圖型中的虛線線條來表示執行某一項操作後的回傳值。這種表示方法的好處是從圖型上來看會比在訊息傳遞時指定操作的回傳值清楚一些: 在訊息參數和回傳值方面,除了上列的表示方法外,還可以使用「資料標記、Data tokens」的表示方法: 內部訊息上列的討論中,都是不同物件之間的互動,在很多情況下也會呼叫同一個物件的方法,這在循序圖型裡稱為「內部訊息」。例如下列的敘述: 循序圖型使用下列的表示方法來顯示這類的實作: 解構物件一般來說,使用Java程式語言,並不會特別去處理物件的「解構、deconstruct」;在循序圖型裡使用一個「X」符號來表示物件的解構,這對其它的程式語言可能很重要,從圖型裡可以讓程式設計師知道什麼時候該把物件給釋放掉。 Java程式語言裡雖然不會特別去使用這個特性,可是你可以把這個特性應用在資源的釋放,例如串流或網路連線的關閉,這對Java程式設計師來說,與其它的程式語言相對於物件解構是一樣重要的: 上面圖型對應的程式碼會像這樣:
迴圈在程式的實作上,反覆執行某一些工作的情形非常多,以下列的敘述來說: 上列的範例程式,包含了一組重複執行的訊息,所以不適合使用訊息宣告語法中的重複選項。不過你可以使用循序圖型中的「迴圈方塊」表示方法: 多執行緒多執行緒的應用程式一向是最難以理解的,尤其是在發生錯誤的時候,想要從程式碼去排除錯誤會是比較困難的。除了在靜態圖型中可以看出誰是具有多執行緒特性的物件以外,循序圖型使用「主動物件、Active objects」來加入圖型中,讓執行緒與其它物件的互動可以更清楚。在開飲機的模擬程式裡,使用了好幾個多執行緒物件來模擬真實的開飲機。例如開水容器中的溫度會隨著時間慢慢降低(每秒中降低一度),當溫度降到80度以下時,開飲機會自動將開水加溫到100度,這些動作都是使用執行緒在背景中偵測和執行: 你可以使用下列的圖型來表現上列圖中的動作: 上列圖形中的「DropTemperature」和「ReBrew」都是實作「Runnable」的類別,由「HotWaterContainer」物件來建立它們,一旦它們建立起來以後,就由自己控制執行緒。 相關的檔案都可以GitHub瀏覽與下載。 |