關鍵字：UML 為了成功使用UML，在使用的過程中必須流程化。因此本文介紹了實施UML時的九項注意點，通過這些使UML符號更好的滿足不同項目的需求。
1997年的最后一個季度，我在教一些來自不同項目的開發者使用UML作面向對象分析與實際。這些項目涉及許多應用領域包括零售貨架空間管理，臨床藥物實驗，移動電話等。開發語言包括Visual Basic, C++, Java, DB2還有其他。通過我們公司的用例驅動統一對象建模過程（是建立在Booch, Jacobson, and Rumbaugh方法的基礎之上的）來從幾個方面介紹UML符號如何更好得滿足不同項目的需求。為如何使用UML提供了實際的指導。
UML的符號比較多（可能太多）而且足夠靈活能適應大范圍項目的需求。為了成功使用UML，在使用的過程中必須流程化。不同的項目需要不同的內容。項目中使用UML符號的哪些具體元素取決于項目的本質（使用關系數據庫客戶端/服務器端或實時嵌入式）及要使用的開發語言。使用JAVA或Smalltalk時一些詳細的C++設計組件將不會被使用；如果使用VB，你可能想避免使用更多的泛化和繼承。有時，純粹的建模組件可能太龐大了，尤其對那些剛開始接觸面向對象分析和設計的學生來說。但是，好消息是幾乎任何事情都可以使用UML來建模來實現。有很多建模組件可供使用。
You Still Need a Process過程仍然需要
UML本身僅僅是一種符號，為了創建有效的模型，仍然需要一個建模過程。使用UML有很多種建模方法；建模語言本身并不描述過程。在UML產生的幾年前，我們一直把作了微小變化的Objectory過程（從Ivar Jacobson的 《面向對象軟件工程：一個用例驅動方法》而來，Addison-Wesley, 1992）作為Booch/Rumbaugh/Jacobson的綜合來授課，并取得了成功。我們的方法將重點放在了區分更高層次的靜態模型（域模型），同時也產生用例。然后我們精煉出靜態模型，在開發用例和動態模型時反復精練。
或者你更傾向于使用Objectory，對象模型方法，我們的ICONIX統一對象模型過程，或其他一些方法。在從事建模工作之前，理解UML不是一個過程是重要的。讓項目組處于同一個開發階段尤其重要。讓項目組對UML有統一的理解使建模成功的保證。UML的規模（文檔符號的龐大相對于過程而言）很容易陷入“分析麻痹”。關注項目組通過UML符號對過程的統一理解，能讓建模更容易。
Legacy Methods Are Important 過去的方法依然重要
我的大部分學生會問我理解Booch, Jacobson, and Rumbaugh過去的方法是否仍然很重要。我的答案是非常重要。就像知道電流設計并沒有排除知道電路理論一樣，雖然UML符號而不排除理解對象建模理論的必要性。自從UML代表了Jacobson, Booch, and Rumbaugh三人方法的綜合，但早期的方法是信息的來源。
Keep It Simple保持簡單
讓一個項目組有效的使用UML是有難度的。項目組成員對于面向對象分析和設計以及UML的理解層次各自不同。開始之前統一培訓是不錯的方法，培訓需要認真考慮項目組每個成員的背景及項目的特殊要求。最重要的決定在于課程表的明智選擇和指導老師在工作期間的調整。
在學習UML中需要記住的一點是我們并不需要使用每一個存在的組件。讓過程盡量簡單化。流程化一個項目的文檔和建模方法對項目的進行有非凡的作用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/