關鍵字: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.anti-gravitydesign.com