繪制整潔的UML圖明晰才能被人采納

2019-11-18 12:19:20

字體：大中小

來源：轉載

供稿：網友

　　不管您喜歡與否，諸如“統一建模語言 (UML)”類模型和用例模型這樣的軟件圖往往是根據它們的外觀來判定其好壞的?？瓷先ァ罢麧崱钡膱D比看上去雜亂的圖更輕易受到讀者 -- 經常是您的用戶或高級經理 -- 的青睞。本文源自 Building Object applications That Work 的第 3 章。
　　
　　我很愿意描述幾個重要的經驗法則，這些法則將使您比其他建模同仁做得更好。這些雖然簡單但很要害的建議主要集中在如何安排組成軟件圖（包括 UML 類模型、用例模型，甚至持久模型）的那些框和線條，并因此適用于所有種類的圖。
　　要繪制一個外觀整潔的圖，您應該避免：
　　
　　·大小不一的框
　　·對角線
　　·交叉線
　　·曲線
　　·混亂的圖
　　·不必要的細節
　　
　　讓我們從一個示例開始。在圖 1 和 2 中，您可以看到兩個用兩種不同風格繪制的圖。第一個復雜，沒有章法，而第二個簡單，組織良好（雖然有些乏味）。您認為哪個設計更好呢？大多數人都會贊成第二個看上去更好一些，因為雖然這兩種設計在功能上是相等的，但第二個的安排更整潔。
　　
　　圖 1. “雜亂”的圖
　　　繪制整潔的UML圖明晰才能被人采納（圖一）

　　
　　
　　圖 2. “整潔”的圖
　　　繪制整潔的UML圖明晰才能被人采納（圖二）

　　
　　
　　避免大小不一的框
　　如何對圖 1 加以改進呢？首先，確保所有框的大小都一樣。大框看上去比小框更重要一些，假如這是您嘗試表達的，那么這樣做沒錯 -- 但假如讓我選的話，我寧愿將所有框保持相同的大小。這種方法最適合于“UML 用例”圖，因為其中的所有用例框和參與者符號可以很方便地統一成一樣，此外還適用于“UML 協作圖”、“UML 序列圖”和“UML 用戶界面流程圖”。對于框中包含的信息量不同的圖，例如“UML 類圖”（其中個別類有數量不等的屬性和操作），或者“UML 狀態圖表圖”和“持久”（數據）模型，那就有一些困難了。
　　
　　避免對角線
　　圖 2 與圖 1 的另一個不同之處在于它沒有任何對角線。我是通過重新安排框來消除對角線的，就好象它們在一個網格上，使互連的框或者在垂直方向上分離，或者在水平方向上分離。從視覺上說，大多數人對直線更感愛好。
　　
　　避免交叉線
　　在圖 1 中，有兩條線相互交叉，我的一個常規經驗法則是應該盡量減少圖中交叉線的數量。通過將一些框移到旁邊，我在短時間內就可以避免使兩條線交叉。可惜，不是總能這樣幸運 -- 您無法總能避免交叉線。在圖 3 中，我想將 5 個框全部連接起來，但假如不使至少兩條線相交就無法做到這一點。您可以看到，我沒有其它方法將框 3 和 5 連接起來。在不得不交叉線時，我會用適用于電路圖的標準來標記：一條線“跳過”另一條，如圖 4 所示。跳過的好處是它很清楚地表明線只是在圖上交叉，而不以任何方式連接。
　　
　　圖 3. 如何在不交叉線的情況下連接 3 和 5？
　　　繪制整潔的UML圖明晰才能被人采納（圖三）

　　
　　
　　圖 4. 一條線“跳”過另一條
　　　繪制整潔的UML圖明晰才能被人采納（圖四）

　　
　　避免曲線
　　您可以在圖 5 中看出，我對圖 4 做了更進一步的改進：除去了曲線。人們喜歡看到垂直或水平的直線。這次我又假裝是在網格上繪制圖（實際上這是許多計算機輔助系統工程 (CASE) 工具的內置特性），然后只需要象在網格上那樣繪制出框和線條。
　　
　　圖 5. 圖 4 的更整潔版本
　　繪制整潔的UML圖明晰才能被人采納（圖五）

　　
　　避免混亂或復雜的圖
　　顯示太多細節或者外觀很混亂的圖看上去不太好。最好能夠有幾張顯示各種程度的細節的圖，而非一張顯示所有事物的復雜的圖。這就是為什么 UML 擁有幾種圖的原因之一：一個軟件是如此復雜，以至于我們無法在單一圖上對其所有方面建模。而且，UML 答應將包添加到圖中（下星期的技巧主題）。
　　
　　另一個相關的注重事項是對屏幕或頁面區域的使用。在我看來，一張占據幾頁的圖比將所有內容蜷縮在一起，使它能在一頁上打印出的圖要好得多。您應該給圖留出足夠的空間，使它易于理解。
　　
　　避免在圖的美化上浪費太多時間
　　盡管這些經驗法則非常有效，但無休止地調整圖的外觀總是會增加額外的建模時間。解決這個問題的一個方法是嘗試使圖的外觀保持在大致良好的水平上 -- 您在使用圖時，不需要它非常完美。一旦確信圖按照您所需的方式對應用程序建模，就可以開始移動框以避免交叉線，增進其可理解性。
　　
　　您的主要目標是對系統建模，而不是繪制漂亮的圖。有必要指出這些重要的經驗法則也可以被用來美化低劣的設計。例如，我可以從圖 2 開始，將它重排成圖 1，以使設計看上去比實際的更為復雜 -- 可能使得高級治理人員相信我需要更多時間或資源才能完成工作，或者引導他們避開我不是非凡喜歡的備選設計。假設您的動機隨情形而改變，我希望您所處的情形是健康的，您所考慮的最重要的問題是使了不起的設計看上去更引人入勝，而不是在辦公室權術中求生存。
　　
　　參考資料
　　
　　Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology，由 Scott W. Ambler 著。New York: Cambridge University PRess, 1998。
　　Process Patterns -- Building Large-Scale Systems Using Object Technology ，由 Scott Ambler 著。New York: Cambridge University Press, 1998。
　　The Object Primer 2nd Edition，由 Scott W. Ambler 著。New York: Cambridge University Press, 2000。

上一篇：在UML中表示Java繼承和接口

下一篇：使用UML編寫Java應用程序 (1)