養成良好的UML序列圖繪制習慣
驗證決策
在開發圖 1序列圖的過程中，我做了一些對其它模型可能有潛在影響的決策。例如，在對第10步建模時，假設（大致上是個設計決策）費用顯示屏幕同時也處理學生對費用是否可接受所進行的驗證。該決策應該由用戶界面原型反映出來，并由主題問題專家(SME) 進行驗證。 您應該和SME（特別是那些對于如何開發類似模型有著深刻見解的富有經驗的人）一起執行序列圖的繪制工作。
保持簡單
在對第 2 和第 3步建模時，我忽然意識到學生可能應該使用口令進入系統。在向 SME提出了這個概念后發覺我錯了：姓名和學號組合對于我們的目的來說已經足夠唯一，并且學校也不希望增加復雜的口令管理。這是個很有意思的決策，因為這是學校的一個運作策略，所以可以作為一條商業規則記載到增補規范中。通過與SME一起檢驗這個想法，而不是假定我比他們知道得更多，我避免了“鍍金”的機會，因而減少了我們小組開發這一系統所需的工作。
繪制消息和返回值
我更喜歡從左至右地繪制消息，從右至左地繪制返回值，盡管這樣對于復雜的對象／類來說不總是非常合適。我將消息上的標簽和返回值對齊到離箭頭最近的位置。我不喜歡在序列圖上標出返回值，為的是使圖盡可能地簡化。不過，始終標出返回值也同樣有效，特別是在序列圖用于設計而不是分析目的時。（我希望我的分析圖盡量簡單，而設計圖盡量全面。）在分析期間，我的目標是理解邏輯和確保邏輯的正確性。而在設計期間，則要賦予消息精確的細節，如圖 1中的注釋提醒我對 "qualifications()"消息執行的任務。
將序列圖分層
我喜歡將序列圖從左至右地分層。先標出參與者，然后是控制器類，然后是用戶界面類，***是商業類。在設計期間，可能需要添加系統類和持久類，我通常將它們放在序列圖的最右側。以這種方式將序列圖分層往往使它們更易于閱讀，并且更容易找出分層邏輯問題，例如用戶界面類直接訪問持久類（在今后的建模技巧中將對此做更多介紹）。
遵循一致的邏輯風格
請注意，在圖 1序列圖所示的過程中，邏輯風格做了部分更改。一開始，特別是在登錄時，用戶界面處理一些基本邏輯--而在選擇研習班，以及稍后的驗證時，則是控制器類進行處理。這實際上是個設計問題。我不會在這個問題上糾纏太久，但和往常一樣，我建議選擇一種適合于您的建模風格，然后始終如一地貫徹在所有序列圖中。
牢記序列圖是動態的
您可能聽說過諸如動態建模和靜態建模這樣的術語，其他一些熟悉面向對象建模技術的開發人員常常會提到它們。您甚至可能聽到過有關每種風格的優點的爭論。
動態建模技術主要集中在標識系統中的行為，包括序列圖的繪制和活動圖的繪制以及 UML 協作圖的繪制。而靜態建模則集中在系統的靜態方面，包括類、它們的屬性，以及類之間的關聯。類模型和持久／數據模型一樣，都是靜態建模的主要產物。
因此實際上沒有什么好爭論的 --要想恰如其分地說明面向對象系統，同時需要動態和靜態建模技術。
 |
【編輯推薦】
