PowerDesigner UML 建模簡介(第二部分)

來源:互聯網
上載者:User
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 種圖表與傳統的資料建模方法和新的商務程序建模方法相結合,我們可以在從進階需求到技術和資料需求,以及物理實現的各個方面來全面瞭解推動軟體開發的所有因素。


相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

11.11 Big Sale for Cloud

Get Unbeatable Offers with up to 90% Off,Oct.24-Nov.13 (UTC+8)

Get It Now >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。