專家提醒 畫UML流程圖時需要注意的幾個問題
本文和大家重點討論一下畫UML流程圖時需要注意的問題，軟件開發中，分析和設計時，文檔的編寫和思想的交流，經常要繪制各種各樣的圖。
畫UML流程圖時需要注意的問題
軟件開發中，分析和設計時，文檔的編寫和思想的交流，經常要繪制各種各樣的圖。相對于人類的自然語言，描繪復雜結構，圖具有直觀和整體的特征，有著不可替代的表現力。
軟件開發是創造性的勞動，開發人員幾乎在每一分鐘都要做出某些選擇，每一個選擇都好像決定著最后的結果。繪圖的時候也是如此，腦中有完整或不完整的想法，要清晰的表現出來時相當不容易。事實上，我發現許多老手不會畫圖。
在畫UML流程圖實踐的過程中，我總結了一些經驗，得出了一些結論。
1.不畫沒有必要的圖。
如果簡單的文字就能說得很清楚，還畫圖干什么？對代碼級別的細節，不要畫圖來表現；不要借助圖來讓你的文檔得變大；畫蛇莫要添足。
2.忽略底層的細節。
軟件是一個多層的東西，一個圖只展現恰當抽象層次之上的細節。一個過細的圖，大量的信息會掩蓋真正重要的東西。比如：在一個流程圖上，不需要把“文件打開的錯誤判斷”也作為一個分支畫在圖上，除非你“無聊到”要強調這個顯而易見的異常處理；
3.圖不要太大。
UML流程圖中如果一個圖上包含上百個對象，看起來不舒服，應該化整為零，使用多個圖，每個圖描述不同的部分。
4.畫純種的圖。
圖傳遞的信息應該明確，無歧義。一定要明確圖中的各個組成元素都是什么東西，整個圖要表現什么。盡量使用規范的圖。比如：流程圖中，應關注控制的傳遞，不要有從文件中讀取數據的數據流；軟件結構圖中，描述模塊之間的父子關系的同時，不要有模塊之間的數據流。我常見到這樣的圖：在圖中既有“控制流”，也有“數據流”，不倫不類，名之曰“示意圖”。個人認為，交流時，這種示意圖在白板上隨手畫畫還可以，決不應該出現在正式的文檔上。
這些圖中的控制流，實是一個模糊概念，A->B可以表示：
1)A調用B，把控制傳遞給B；
2）A啟動B,把控制傳遞給B；
3）A向B傳遞一個控制信號；
4)有一個第三者調用A完成后，馬上調用B。
5.圖的布局要簡潔，美觀。
我聽說：書寫大幅的毛筆字，特別講究布局。同樣道理，畫UML流程圖，盡量密度分布均勻，減少連線的交叉。為了減少連線的交叉，同樣的單元可以在圖中出現多次。
6.其實并不需要完備的圖。
使用UML有三種方式：UMLassketch(草圖)，使用不完備的圖進行系統某一部分或某一方面的內容進行交流；UMLasblueprint（籃圖），通過完備的UML圖表現詳細設計的所有決定；UMLasprogramminglanguage，自動精確的UML圖，直接編譯成可執行的代碼（現在好像還沒有實現）。MartinFowler說：使用UML繪制草圖的人，真正關注UML的精髓（大師就是大師，說話就是不一樣）。所謂“不足勝有余”，不管什么圖，圖應該集中表現其關注的方面，恰當的忽略一些細節時必要的。類圖中，往往沒有必要包含類的所有函數合成員說明；在表現對象之間協作的順序圖中，大多時候也沒有必要表現存在的分支和循環。
7.所有的規則都是用來遵守和打破的。
上面的所有道理，也并非是不變的真理。但是，道理被打破以前，你應該了解它，熟悉它，批評它，忘記它（追求類似張三豐太極劍的境界）。古人云：事有反道而適權，偽經而和道者。笑傲江湖說：獨孤九劍，無招勝有招。蕭大俠：刪繁就簡，取精用宏。規勸朋友也規勸自己：連有招的境界尚未達到，應該知道自己該做什么。
【編輯推薦】
