PowerDesigner UML 建模

引言
    PowerDesigner支援UML1.3的所有圖包括使用案例圖、順序圖表和類圖、活動圖表和元件圖表表等，並全面支援UML2.0。改進了物件導向分析與設計(OOAD)分析方法並增強了與開發過程的整合。 

PowerDesigner 能夠協助您構建適應現代 IT 發展的傳統商務和電子商務系統，使用 Java 等物件導向的語言以及 XML 等新技術，以物理或虛擬方式與我們的資料庫技術合并。我們的目標是根據您的需求，提供隨時隨地訪問資訊、控制商務程序的能力，並通過電腦和最新技術賦予企業在當今任何市場上先拔頭籌的競爭優勢。 

我們的分析方法和設計技術將會是多種多樣的，從商務程序建模，到 UML 物件導向分析和設計，以及傳統的關係建模等。本文將協助您深入瞭解 UML 這項強大的技術，它可以協助您的企業建立出高效的傳統商務和電子商務系統。 

物件導向的分析 

    在您準備為企業作出系統和軟體投資前，必須首先瞭解企業的實際需求，明確所部署的技術將如何協助您的企業擷取更大的成功。您可以使用 UML，藉助使用案例圖、順序圖表和活動圖表來進行分析。這些圖表將協助您規劃系統的範圍、動態效能、以及表現方式等。不必考慮實施細節，您希望獲得的只是按照您的需求而表現的系統效能。 

使用案例圖(The Use Case Diagram) 

UML 使用案例圖提供了一個系統內容的建模方式。它能夠協助您確定系統/應用程式的外部和內部元素以及系統範圍。作為圖形建模模式，它在您需要與所收集的系統需求進行對話時也將有所協助，對於研製成品的Team Dev來說，更是有著舉足輕重的重要性。對於企業的所有者，或第一次接觸該軟體產品的使用者也有很大的協助作用。使用案例圖能夠以可視化的方式，表達系統如何滿足所收集的商務規則，以及特定的使用者需求等資訊。 

在項目後期，也能夠用到 UML 使用案例圖。您可以通過使用案例圖中定義的需求來協助測試專案的相關功能。您不僅可以驗證系統效能是否無錯誤（無崩潰或明顯的非邏輯響應），還可以驗證系統運行時是否按照要求，執行了指定命令。這樣，您可以測試系統是否完全滿足了要求，以確信成品可以投入生產——也就是說，它已完全滿足了使用者的需求。 

只有確保滿足了合理、實用的各項需求，才能確保 IT 項目的更大成功。 



順序圖表(The Sequence Diagram) 

您可以使用 UML 順序圖表細化需求並對設計項目進行連結。順序圖表允許高層和低層對象間的互動文檔。該互動在角色（與使用案例圖中的角色相同）和類執行個體（運行於電腦記憶體中的技術對象和細節對象）之間顯示。 

通過順序圖表，您可以按照系統特定方案中事件（訊息）的精確順序來描述隨時間變化的系統行為。使用順序圖表進行用例分析並引導設計：您可以決定將對使用案例圖所定義的管理工作負責的系統物件類型，並決定哪種對象將管理系統內外的“會話”或通訊。由於訊息已從順序圖表中抽出，您可以描述類和介面（我們最後要編譯和部署的代碼元素）所需的某些關鍵操作（方法）。 


活動圖表(The Activity Diagram) 

UML 活動圖表設計用於協助您瞭解系統中對象的動態變化。用於描述某一特定類或一組類如何協同工作。與順序圖表有所不同，活動圖表不是一系列與時間相關的通訊，而是從一個任務到另一任務的控制轉移，同時指定誰（哪個對象）對發生的任務負責。 

UML 活動圖表也是商務程序的技術視圖。可對業務工作流程進行分析或在“商務程序建模”工作後可獲得活動圖表。 

活動圖表還可協助構造系統內元素的詳細動態視圖（EJB 如何互操作等）。 



通過分析推動設計 

通過分析模型可捕獲獨立於實施細節之外的系統意向和預期行為，與使用的語言、部署的應用程式伺服器或使用的體繫結構都沒有關係。但是，設計階段開始後，一切都發生了變化。您必須進入生產環境的細節並將軟體構建至特定的體繫結構。設計是對系統的實施。 

如果設計是由分析得到的，您可以更加確信所編寫的系統行為的正確性，確認所開發的成果將是一個按需求構建的系統。您將獲得高度成功——讓使用者得到所需要的系統。您還可以直接利用分析得出的資訊而無需在設計過程中重建，從而縮減開發時間，由於不必“重新複製”任何工作，因此減少了人為錯誤。 

通過分析，我們可獲得什麼呢。通過使用案例圖可以發現對象並促進類和介面的建立。一個或更多類和介面可以實現一個角色，您可以在角色定義中直接建立類和介面。您還可以將角色連結到現有的類和介面，顯示如何使用一條代碼來滿足所分析的多個元素。 

通過順序圖表可以探索方法並促進類操作的建立。如果您需要向類發送訊息，您可以調用該類的方法。順序圖表中的訊息可以用來自動建立操作或連結到現有操作。您可以通過連結跟蹤方法的功能，包括將哪些作為輸入內容和必須返回哪些內容等等。 

設計所包含的內容 

您已經知道要構建的內容，現在您需要表述如何構建。您需要確定商務邏輯所在的位置：可以置於應用程式伺服器的 EJB 等組件中，也可以置於使用 VB 或 PowerBuilder 等語言、作為用戶端應用程式一部分的類或組件中，或者做為觸發器和過程內建於關聯式資料庫中。您需要根據需求做出一些選擇，包括擴充性、安全、效能和可訪問性等方面。 

UML 類圖和元件圖表將用於定義詳細的技術系統靜態結構。 

類圖 (The Class Diagram) 

UML 類圖、商務邏輯和所有支援結構一同被用於定義全部的代碼結構。既然類圖用來類比開發中所維護的實際代碼，顯然它是 Java 或 PowerBuilder 等對象語言的概括性表述。您還可以使用 UML 類圖來概括 XML 中的複雜結構，令其更易於開發和理解。 

可以從 UML 類圖上產生代碼。還可以在開發過程中編輯該代碼以完善、測試和部署最終啟動並執行應用程式。由於 PowerDesigner 在對象語言和 UML 類圖之間具有 1:1 的映射功能，您還可以實施反向工程代碼，讀取源檔案並建立新的類圖。您可以更深入地理解現有系統並簡化整合和維護工作。 


元件圖表(The Component Diagram) 

UML 元件圖表將被用於在更大的黑匣視圖（Black Box View）中描述進階對象的定義和相關性。它仍然是一個設計模型,並且是代碼的直接概括。例如，一個 EJB 的組件標識直接連結到實施所必需的一系列類和介面，並將產生所需代碼來推動最終 bean 的開發。 



元件圖表比組件體繫結構的代碼層視圖更容易理解和管理。還可以通過編寫組件介面的文檔來實現代碼的共用和反覆使用，使用者無需（或很少）瞭解組件的實施細節即可在其他項目和系統中使用這些代碼。 

右擊Customer EntityBean_CMP，選擇Create/Update Class Diagram,產生如下class diagram: 


迴圈疊代工程 

世界不是一成不變的，您的 IT 項目也如此。在您瞭解需求，通過分析進行了設計，並構建了系統的某些元素後，必然還會遇到新的變化，如要更新定義，又或者現有使用案例圖中存在某些需要改正的錯誤，代碼在 IDE 和文字編輯器中被編輯以及資料庫被DBA 最佳化等。必須管理和掌握所有需要更改的細節，以確保所構建的系統能夠與業務需求保持一致。 

往返工程的一個方案是當代碼在開發過程中被更改時，需要在類圖中反映出來。具體細節如下： 
1. 建立類圖並將商務邏輯元素添加到模型中 
2. 組建檔案系統的應用程式代碼 
3. 在 IDE 或文字編輯器中編輯代碼 
4. 編輯設計，此時忽略在產生的程式碼中所發生的更改 
5. 對編輯內容實施反向工程，直到與現有類圖一致 
6. 將設計過程中完成的工作與開發時編輯的內容同步（合并） 
7. 產生新代碼，該代碼是設計代碼和開發人員更改代碼的總和 

當對類圖進行了修改以反映新的設計內容時，應該使用同步/合并技術防止丟失開發人員的工作成果，同時允許設計人員接受或拒絕開發過程中所做的更改。這樣，PowerDesigner 令 IT 能夠完全控制體繫結構，這正是制勝的關鍵。 

PowerDesigner 的功能並不是僅限於此。現在設計模型已被更新，您可以將這些更改連結到分析中。有可能您在分析中發現了新的需求，可以將這一更改反映到設計中並編寫代碼。使用 PowerDesigner 中領先的 Compare/Merge 技術（在 September Blueprint 中討論過），您可以在開發週期的所有模型和階段中獲得真正的往返同步。 
對象圖(Object Diagram) 

    與類圖一樣，對象圖也是一個 UML 靜態結構圖表；它定義了系統在給定時刻具有的物理元素，而沒有具體考慮系統的動態活動。它與代碼一一對應，但與類圖不同，我們現在討論的是具體的分類器，而不是分類器定義。將對象圖描述為類執行個體圖可能最為合適。 

對象圖的主要用途是進行分析。類圖中無法表示的類之間存在不確定的約束。我們將使用對象圖來記錄這些約束。而且，在我們查看所管理的具體類執行個體樣本以闡明這些元素之間的互動作用關係時，對象圖還允許我們定義具體的“What if”情境。 

以下內容適用於 OO 建模的初學者：分類器是抽象的對象結構定義。分類器可以告訴我們所管理的是什麼類型的資料（屬性/成員表示資料元素）以及該分類器具有什麼能力（操作/方法表示對象的行為）。執行個體是具體的分類器樣本。假定定義一個名為 Customer 的類，該類具有 Name 屬性。類 Customer 的執行個體“Jane Doe”是姓名恰為“Jane Doe”的客戶。執行個體通常具有比分類器更豐富的含義，這是因為分類器表示某種層級的概述。收集某個分類器的若干個執行個體或樣本可能有助於您理解其用途並更好地使用它。 

因此，對象圖是類圖的具體形式，表示類執行個體樣本，並且顯示了索引值和關係。例如，CustomerBean 類具有以下客戶執行個體：該客戶的 ID 為 52271，姓名為“John Doe”。該客戶執行個體與三個訂單一實例（三份訂單）相關，訂單編號分別為122047、122103 和 122399。 


共同作業圖表(Collaboration Diagram) 

    共同作業圖表和順序圖表非常相似。實際上，順序圖表和共同作業圖表可以有效地交替使用，並可以簡便的相互轉換。其區別在於使用者閱讀和理解的方式不同。順序圖表具有很好的層次性，並且圍繞時間構造。共同作業圖表則主要是圍繞對象結構構造。通過在圖中對訊息進行編號可以表示訊息的順序。採用這種方式時，即使圖的結構不是基於時間的，也將保持定時關係。

共同作業圖表藉助於系統中元素或對象之間的互動作用，表示系統的動態方面，即在一段時間內的表現方式。它通過表示系統的靜態結構來對類圖和對象圖進行補充，但不是藉助於基於結構的關係，而是在系統對象之間傳遞互動作用“訊息”。 

構造共同作業圖表時還可以在概念級測試靜態模型。在類圖中定義了類執行個體，這些類執行個體之間的互動作用定義了一個具體的使用方式情節以及將在這些元素之間發生的內部通訊。我們還可以使用其他角色來表示系統的外部作用者和內部使用者，如使用案例圖。 

例如，我們可以建立一個訂單輸入系統，以供客戶和銷售代表使用。客戶通過建立新訂單與該系統互動作用。訂單對象與銷售對象之間進行對話，該對話由連結訊息表示，在此情況下，只有兩個訊息：一個是來自 Orders 類的訂單請求，一個是來自 Sales 類的訂單確認。對一個連結上的訊息數量沒有限制。我們在此討論的對話以一個訂單請求開始，然後是對該訂單的確認。 


適用性 

    共同作業圖表對於設計人員尤其重要，因為它闡明了對象的作用。您可以在順序圖表之前構造共同作業圖表（如果您計劃構造這兩個圖），但通常是在完成類圖之後構造共同作業圖表以說明從類中匯出的對象之間的互動作用。可以使用一個或多個共同作業圖表來實現一個用例，或者將複雜行為分割成多個邏輯子行為。 

狀態圖(Statechart Diagram) 

    狀態圖（也稱為狀態機器）描述了特定類或組件在其整個生命週期中不斷變化時的行為。該圖顯示是什麼觸發了從一種狀態向另一種狀態的轉換，以及在該類上調用哪些操作以提供該狀態的行為或觸發這種轉換。例如，訂單在被建立時處於初始狀態。在客戶確認訂單正確後，訂單將進入確認狀態。在發貨以後，訂單需要從確認狀態進入發貨狀態。


因此，每當一個類在其生命週期的不同階段具有不同的可用選項（不同的有效行為）時，您都可以使用狀態圖來將這些規則和條件建模。生命週期中的每個階段都是該對象的一種狀態，而每個改變狀態的觸發器都代表從一種狀態到另一種狀態的轉換。可以根據需要從某個狀態轉換到任意多個其它狀態，也可以從其它多個狀態進入某個狀態。 

子狀態圖 

    若要保持狀態圖簡單和易讀，您可能發現所定義的一個或多個狀態實際上涉及到更為複雜的行為，以至於它本身就可以定義為一個狀態圖。此時，與向主圖中添加大量複雜細節的做法相比，更好的做法是將這個單獨的狀態分解為多個子狀態，進而組成一個輔助圖，以定義父狀態的更為複雜的內部行為。 

部署圖(Deployment Diagram)

    部署圖可以協助我們確定所有代碼元素在伺服器、工作站和資料庫中的存放位置。有的節點需要依賴硬體或軟體框來運行部分商務邏輯。這些節點互動作用以示範我們開發的多個電腦和系統是如何互動作用和整合的。節點中包含將部署到資料庫、應用程式或 Web 服務器中的組件執行個體。 

部署圖用於將組件實際部署到伺服器中。通過定義希望組件啟動並執行位置，我們可以快捷的映射、部署和管理分布在用戶端應用程式和應用程式伺服器端組件之間的商務邏輯或資料庫端伺服器邏輯。以下是要管理的物理體繫結構的 1:1 模型。 

例如，假定我們已決定實現兩個 Enterprise Java Beans，並且在應用程式伺服器上運行它們。下圖顯示了單個節點以及該節點內的兩個組件（每個 EJB 一個組件）。我們可以看出 EmployeeBean 依賴於同一應用程式伺服器內的 CustomerBean。 


結論 

    在我們藉助使用案例圖、順序圖表、活動圖表、類圖和元件圖表完成基本 UML 建模時，我們將需要其它一些工具來定義有關係統中某些特定元素的詳細資料。我們可能希望在對象圖中使用精確的樣本來表示對象的結構，或者藉助於狀態圖來更多地瞭解在其內部具有多個複雜狀態的類的行為。我們需要使用共同作業圖表從結構角度而不是從時間角度來考察系統組件之間的互動作用。最後，還需要使用部署圖來顯示所有系統組件在運行環境中的物理硬體或伺服器中所處的位置，從而更詳盡的瞭解分布式體繫結構的使用方式。 

UML 為我們提供了更加實用的圖表，以便完成對商務邏輯的技術分析、設計、開發、或部署。將這 9 種圖表與傳統的資料建模方法和新的商務程序建模方法相結合，我們可以在從進階需求到技術和資料需求，以及物理實現的各個方面來全面瞭解推動軟體開發的所有因素