UML學習心得體會

——uml學習體會

養成良好的繪製uml序列圖的習慣

在學習uml的過程中，你可能會遇到繪製uml序列圖的問題，這裡就討論一下怎樣才能養成良好的繪製uml序列圖的習慣

有一些方法可以幫助您提高uml序列圖的質量和效力。它們包括：和主題問題專家一起驗證決策；使解決方案盡量簡單；為繪製訊息和返回值選擇一種一

致且有效的風格；將序列圖分層；遵循一致的邏輯風格；牢記序列圖是動態的

一：驗證決策

繪製uml序列圖時，我做了一些對其它模型可能有潛在影響的決策。例如，在對第10步建模時，假設（大致上是個設計決策）費用顯示螢幕同時也處理學生對費用是否可接受所進行的驗證。該決策應該由使用者介面原型反映出來，並由主題問題專家(**e)進行驗證。

您應該和**e（特別是那些對於如何開發類似模型有著深刻見解的富有經驗的人）一起執行序列圖的繪製工作

二：保持簡單

在對第2和第3步建模時，我忽然意識到學生可能應該使用口令進入系統。在向**e提出了這個概念後發覺我錯了：姓名和學號組合對於我們的目的來說已經足夠唯一，並且學校也不希望增加複雜的口令管理。

這是個很有意思的決策，因為這是學校的乙個運作策略，所以可以作為一條商業規則記載到增補規範中。通過與**e一起檢驗這個想法，而不是假定我比他們知道得更多，我避免了「鍍金」的機會，因而減少了我們小組開發這一系統所需的工作

三：繪製訊息和返回值

繪製uml序列圖時我更喜歡從左至右地繪製訊息，從右至左地繪製返回值，儘管這樣對於複雜的物件／類來說不總是非常合適。我將訊息上的標籤和返回值對齊到離箭頭最近的位置。我不喜歡在序列圖上標出返回值，為的是使圖盡可能地簡化。

不過，始終標出返回值也同樣有效，特別是在序列圖用於設計而不是分析目的時。（我希望我的分析圖盡量簡單，而設計圖盡量全面。）在分析期間，我的目標是理解邏輯和確保邏輯的正確性。

而在設計期間，則要賦予訊息精確的細節

四：將序列圖分層

繪製uml序列圖時我喜歡將序列圖從左至右地分層。先標出參與者，然後是控制器類，然後是使用者介面類，最後是商業類。在設計期間，可能需要新增系統類和持久類，我通常將它們放在序列圖的最右側。

以這種方式將序列圖分層往往使它們更易於閱讀，並且更容易找出分層邏輯問題，例如使用者介面類直接訪問持久類

五：遵循一致的邏輯風格

請注意，在圖1序列圖所示的過程中，邏輯風格做了部分更改。一開始，特別是在登入時，使用者介面處理一些基本邏輯--而在選擇研習班，以及稍後的驗證時，則是控制器類進行處理。這實際上是個設計問題。

我不會在這個問題上糾纏太久，但和往常一樣，我建議選擇一種適合於您的建模風格，然後始終如一地貫徹在所有序列圖中

六：牢記序列圖是動態的

繪製uml序列圖時您可能聽說過諸如動態建模和靜態建模這樣的術語，其他一些熟悉物件導向建模技術的開發人員常常會提到它們。您甚至可能聽到過有關每種風格的優點的爭論

動態建模技術主要集中在標識系統中的行為，包括序列圖的繪製和活**的繪製（請參閱「如何繪製uml活**」）以及uml協作圖的繪製。而靜態建模則集中在系統的靜態方面，包括類、它們的屬性，以及類之間的關聯。類模型和持久／資料模型一樣，都是靜態建模的主要產物

uml學習心得

(一) uml（unified modeling language，統一建模語言）是一組用於描述ooad過程的圖形化表達方式

uml為交流物件導向的設計中的需求，行為、體系結構的實現提供了一套綜合的表示法

(二) uml由9個不同型別的圖組成

用例圖：顯示了系統的外部可視行為

用例圖描述了系統外的人員和系統的互動動作，以及系統的響應，該型別的圖可以用於描述系統的功能需求

活**：顯示系統行為的峽谷納西描述

活**描述了單個功能需求內部的細節行為，包括基本的場景和一些可選的場景

元件圖：顯示了系統的體系結構

元件圖描述了系統的可部署單元（可執行檔案，元件，資料儲存和其他一些內容）以及一些藉口，可部署單元通過這些介面進行互動，該圖可以用於研究系統的體系結構

順序圖：顯示了物件隨著時間的互動

順序圖描述了某個功能需求的路徑或場景內相對時間的詳細行為，該圖可用於理解系統元素之間的訊息流程

協作圖：顯示了物件的互動，強調物件之間的關係。（在uml2.0裡面找不到了

類圖：顯示了類的定義和關係

類圖描述了系統設計中的類和介面，以及他們之間的關係。該圖可用於定義內部的，物件導向的**結構

狀態圖：顯示了響應時間的狀態改變