Java 建模： UML 活頁簿：第 2 部分

Java 建模： UML 活頁簿：第 2 部分		英文原文

內容： 順序圖表的兩種類型 條件邏輯 繪製 for 循環圖表 繪製 while 循環圖表 結束語 參考資料 關於作者 對本文的評價 相關內容： 建立帶有樣式的 UML 順序圖表 物件導向設計過程：用例簡介 Java 建模系列所有文章 順序圖表中的條件邏輯 Granville Miller (rmiller@togethersoft.com) 顧問，TogetherSoft 2001 年 6 月 Granville 繼續討論“整合模組化語言”和順序圖表的繪製。他仔細研究了順序圖表繪製過程中條件邏輯的角色，並討論了為什麼要在圖中包含或排除條件和迴圈。Granville 還描述了順序圖表的兩種形態 -- 常規和執行個體 -- 並說明了它們在開發週期中各自的應用。 我在介紹性專欄中曾經解釋過，順序圖表用於描述系統隨時間而產生的內部行為。因為系統行為是對象相互之間發送訊息的結果，因此順序圖表繪製了那些訊息在對象之間移動時的路線。歸根結底，順序圖表就是互動圖。在前一部分中，儘管我們描述了無數互動，但只建立了一個相當簡單的圖。這次，我們將做進一步的研究，看看 UML 指定的順序圖表的兩種形態。這兩種形態是常規和執行個體。讓我們從每種形態的正確應用開始。 順序圖表的兩種類型 順序圖表用於描述對象之間兩種不同類型的互動。一種互動類型是必須 (must) 互動，其中對象 A 必須向對象 B 發送特定訊息。另一種互動類型是可能 (may) 互動，其中對象 A 可能（但不一定）向對象 B 發送特定訊息。這兩種形態的順序圖表描述了這兩種不同類型的互動。常規形態描述的是 必須互動，而執行個體形態則描述了可能互動。 常規形態的順序圖表描述初始刺激因素所產生的類互動。常規形態則記述了初始刺激因素能夠產生的一切互動。成功和失敗條件與迴圈、條件和分支一樣，都是這種圖的組成部分。 常規順序圖表在水平軸方向上的每個框中只包含一個類名， 1 所示。它的含義是，互動背後的對象是匿名的，該類的任何對象都可以參與到互動中。因此，必須為所有路徑明確建模。在常規順序圖表中，對象 A 必須向對象 B 發送模型中的一條訊息。 圖 1. 常規順序圖表 順序圖表的第二種形態是執行個體形態。執行個體順序圖表描述了兩個執行個體之間可能發生的單一訊息交換。這樣的圖將在水平軸方向的框中包含一個變數名及其類類型， 2 所示。這種形態不包括常規形態中常見的迴圈、條件和分支。在系統中實際的控制流程程中，在互動過程中所進行的某些斷言可能為假。如果發現斷言為假，執行個體順序圖表中的所有訊息都為空白，這種情形將不出現。執行個體順序圖表描述了可能發生也可能不發生的單一情形。 圖 2. 執行個體順序圖表 執行個體順序圖表最適合於在軟體開發生命週期的分析階段對個別方案建模。常規順序圖表可以為包含多個方案的整個用例建模。其它一些類型的活動 -- 例如為子系統或架構與其各個部分之間使用的協議建模 -- 可以使用任何一種形態，這取決於組件在軟體開發生命週期中所處的位置。與執行個體形態相比，常規形態更接近於在最終產品中出現的實際代碼。 我們在前一專欄中使用的是常規形態，並將在此繼續研究這種形態。這一次，我們將探究條件邏輯在常規順序圖表中所扮演的角色，通過它來讓您瞭解有關 UML 表示的更多知識。 順序圖表繪製中的條件邏輯 常規順序圖表利用了條件邏輯，這對於描述互動過程中事件的可選流程來說很有用處。根據軟體開發生命週期中所處的不同階段，可以繪製詳略度不同的圖。在分析階段，您可能願意將詳細資料排除在條件運算式以外，而在設計階段，您卻可能希望將最終產品中要使用的代碼的片段包括在條件運算式中。 無論處於開發週期中的哪個階段，隨著條件運算式圖的繪製，順序圖表與如 Java 語言這樣的物件導向語言之間那種自然的一致性就愈發清楚了。例如，請考慮一個允許出納員接受存款的銀行業務應用。除了其它一些事項以外，還規定了系統必須防止出納員把負的金額記入帳戶貸方，因為這會導致從帳戶中扣除。因此系統必須有一種檢查鍵入的所有金額均為正數的機制。清單 1 顯示了確儲存款為正數的條件運算式。 清單 1. 帶有條件運算式的方法 \** This is a method in a Teller class **\public void receiveDeposit(Account account, BigDecimal deposit)throws ImproperDepositException { // Check to ensure the deposit is positive if (deposit.compareTo(new BigDecimal(0.0)) > 0) { account.credit(deposit); } else { throw new ImproperDepositException(); }} 在分析階段，您不是很關心細節，因此圖只需要表明存款為正數。在常規順序圖表中，條件作為帶有訊息名的保護機制出現，位於水平調用箭頭上方。這些保護條件用方括弧括起，放在訊息名的左側， 3 所示。 圖 3. 在分析期間添加的條件 上述方法和順序圖表之間的關係在圖 4 中顯現得更為清楚，我們在圖 4 中看到了在設計階段可能用到的更明確的圖。當然沒有顯示全部方法：缺少了 else 子句。不過，圖中訊息箭頭的語義規定只能在條件有效時發送訊息。 圖 4. 更明確的條件 可以通過在 Teller 類和 ImproperDepositException 之間添加另一個調用箭頭來為 else 子句建模。在這個調用上會有一個與 if 相反的條件；在本例中，即存款必須小於等於 0。您不妨自己嘗試為這個語句建模。 繪製 for 循環圖表 如上例所示，常規順序圖表 -- 以及實際上所有 UML 圖 -- 幾乎映射了 Java 語言的文法。所以，大多數 Java 開發人員對這些圖都有一個直觀的理解，並且可以很快地學會如何使用它們。為進一步探討常規順序圖表和 Java 語言之間的一致性，我們將繪製 for 循環圖表，如清單 2 所示。 清單 2. for 迴圈 for ( int i =0; i < 4; i++) { squareRoom.examineCorner(i);} 在順序圖表中，迭代是通過水平箭頭上訊息名之前的星號 (*) 來表示的。如果迭代的次數已知並且固定 -- 這種情況非常少見 -- 這個數字出現在星號後面的方括弧中。因為大多數 for 迴圈處理的複雜邏輯不允許靜態地確定迭代次數，因此您不會經常使用這種格式的括弧表示。圖 5 顯示了上述 for 迴圈的順序圖表。 圖 5. for 迴圈順序圖表 繪製 while 循環圖表 因為 while 迴圈將迴圈與條件結合起來，因此它是個非常容易接受的樣本。我們將對清單 3 中顯示的 while 迴圈繪製圖。 清單 3. while 迴圈 while ( value.notFound() ) { value = database.search( key );} 我們的 while 循環圖表既包含條件，又包含表明迭代的星號，但您會發現，沒有迭代的次數。 while 迴圈很少包含迭代次數 -- 除非它是一個偽裝的 for 迴圈。圖 6 顯示了 while 循環圖表。 圖 6. while 迴圈順序圖表 結束語 一般來說，必須和可能行為是 UML 和軟體開發的基本概念。用例捕捉必須行為；方案捕捉可能行為。類圖捕捉必須行為；執行個體圖捕捉可能行為。我主要討論這一概念是因為我發現許多人沒能掌握順序圖表的根本靈活性，而分化成直覺和形態使用這兩個極端。 在閱讀這些文章時，您應該把精力集中在發展模型語義的直觀理解上。隨著看到越來越多的順序圖表並開始建立自己的順序圖表，您會發現許多順序圖表依賴於條件邏輯和圖表上下文來說明圖所表示的是 必須還是可能的系統檢視表。隨著我們深入到更加複雜的圖表繪製技術，及早學習如何識別和使用這種差別將對您今後有所協助。 除了探討順序圖表繪製中必須和可能行為的重要性以外，我還向您介紹了如何在圖中表示條件和迭代。既然您已經知道如何繪製 for 和 while 循環圖表，我建議您在其它 Java 構造（例如 do-while 迴圈）上實踐一下建模表示。隨著您自己練習繪製這些簡單構造圖，自然會逐漸加深對順序圖表繪製的理解。 參考資料 通過單擊本文頂部或底部的討論來參與有關該文章的討論論壇。 有關“整合模組化語言”和順序圖表繪製的介紹，請參閱本系列的第一個專欄。 要瞭解有關 UML 和順序圖表繪製的詳細資料，請仔細查看 Hans-Erik Eriksson 和 Magnus Penker 的 UML Toolkit (John Wiley & Sons, 1997)。 另一個非常有協助的資源是 UML in a Nutshell，由 Sinan Si Alhir 著 (O'Reilly & Associates, 1998)。 “UML 標準”的權威來源是 OMG 的整合模組化語言規範 (Unified Modeling Language Specification)（在本文寫作時是版本 1.4）。 有關順序圖表和 UML 的其它資訊，請參閱 "建立帶有樣式的 UML 順序圖表"，由 Scott W. Ambler 著（developerWorks，2001 年 2 月）。 Allen Holub 在他有關物件導向設計過程的系列中提供了 用例方案的深入說明（developerWorks，2001 年 1 月）。 閱讀 OCL，它是 UML 的運算式語言。 IBM 和其它一些業界領先者建立了 XMI，一種新的開放業界標準，它將一些基於 Web 的用於定義、確認和共用文檔格式等 XML 標準的優點和 UML 的優點結合了起來。 關於作者 Granville 加入物件導向社區已有 13 年了。他是進階用例建模 (Advanced Use Case Modeling)系列的合著者，並在全世界範圍的各種物件導向技術會議中介紹過教程。他的物件導向開發的實踐方法來自於他在多家公司供職的經驗，其中包括從處於創業階段的公司到相當成熟的軟體業巨擘在內的各種公司。 他目前正在教授有關靈活過程、方法和 Java 技術的研習班、教程和課程，同時還在輔導和協助實現一些積極的項目。可以通過 rmiller@togethersoft.com 與 Granville 聯絡。