PowerDesigner UML 建模簡介（第二部分）
2024-07-21 02:07:05
供稿：網友
powerdesigner uml 簡介（第二部分）
作者：sybase, inc. powerdesigner 產品經理 david dichmann
在 blueprint #4（訪問 http://www.sybase.com/blueprint 以獲取以往問題的電子版）中，我們探討了 5 種 uml 圖表：用例圖、序列圖、活動圖、類圖和組件圖，它們可以幫助您掌握系統的需求，設計其物理結構和預期功能，并轉換為代碼。我們還可以使用另外 4 個 uml圖來進一步精簡前 5 個圖中包含的定義，或者從完全不同的可取角度來定義系統。
這些圖表（對象圖、協作圖、狀態圖和部署圖）與前面的圖一起組成了powerdesigner 中的全部圖表，并可在powerdesigner9.5中使用。
對象圖(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 種圖表與傳統的數據建模方法和新的業務流程建模方法相結合，我們可以在從高級需求到技術和數據需求，以及物理實現的各個方面來全面了解推動軟件開發的所有因素。
