實施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中需要記住的一點是我們并不需要使用每一個存在的組件。讓過程盡量簡單化。流程化一個項目的文檔和建模方法對項目的進行有非凡的作用。

　用UML建模和有時和座在一大堆事物面前很相似，開始吃之前就有不能吃完盤子里面的所有食物的想法可能毀了你的食欲。同樣的現象可能發生在UML建模過程中。用完全詳細的動態模型描述系統的每一個用例，而不得不創建一系列完整的時序圖、協作圖、狀態圖、部署圖，用例和類圖的想法可能會讓一個團隊完全脫離面向對象分析和設計。

　在一個給定的建模方法中決定使用哪一個組件簡單同樣是要考慮的。舉例來說，在一個用例圖上同時使用USES 和EXTENDS真的有必要嗎？或者我們只需要使用USES？我的經驗是流程化的東西越多，建模成功的可能性越大。

　Write the User Manual Before You Design the Classes設計類之前寫使用手冊

　寫程序的一條老的規矩是在寫代碼之前寫使用手冊。在我學習的時候我認為這是一條好的建議，并且到今天為止我仍然認為是好的建議。在面向過程的年代和面向對象方法的早期，這條規矩很少被遵從。在用例驅動建模方法中，Jacobson把這個規律編寫成一系列的步驟，通過這些步驟可以為對象服務并且能用UML描述。每一個步驟建立在上一個步驟的基礎之上，形成一個可以跟蹤的方法，直道最后，管理能加強這個方法把它作為一個設計范例并且確認在分析和設計的過程中能被遵守。

　基礎層次的人理解Objectory和用例驅動對象建模的本質的簡單方法是：在設計類之前寫使用手冊。大腦里一直有這個想法將會幫助你在UML的迷宮里穿越靜態和動態的建模符號。每一個用例代表著用戶手冊的一部分，并且應該按著“用例分析的目的是產生對象模型”的方式寫。

　Organize Use Cases into Packages用例打包

　一旦你準備為你的系統的每一個用例書寫使用手冊的時候，你將很快會意識到需要更高層次的把用例組裝起來。UML允許你把用例打包。這些可以用文件標簽代表。每一個包至少應該包括一個用例圖，這個圖可以作為一個上下文圖，它可能把設計階段每個用例的動態視圖和用例描述聯系起來。有一些項目從高層次的包分割開始。這些分割并不總是代表最終的分割，有時是很好的開始起點。

　Use the Objectory Stereotypes使用Objectory模板

　整個設計過程從用例中分離出來，表明注重描述它們是“正確“的方法。同時在需求分析和業務過程建模中用例作為一種備選方案正越來越受到歡迎。不同形式的用例建模有一些不同的向導，我遇到的大部分項目仍把用例作為得到對象模型的方法。

　Jacobson的早期的OOSE/Objectory包括這樣一個我們稱之為健壯性分析的階段。在健壯性分析中，用例描述被解釋為粗略地分割一系列協作對象。在分析的過程中，Jacobson提出將對象進行分類，把它們分為接口對象，控制對象，和實體對象。

　這個小又快的建模步驟產生令人驚訝的收益。它幫助人們寫出正確的用例，較早地確認客戶端/服務器端和MVC設計信息，很可能最重要的是快速的瀏覽所有用例能確認可重用的對象。同時也填補了需求分析和詳細設計之間的空白。

　不幸的是，由于某些原因，健壯性分析的一些符號（三個容易畫的符號），在轉變的過程中只有部分保留在UML中。符號仍然存在，但被分離到一個稱為對象過程擴展的文檔當中，并且工具支持也缺少。我把健壯性分析作為一個整體部分描述用例（圖變成了文本的完全檢查）時，發現學生已經很快適應了這個對象。

　Important Questions重要的問題

　你可以把整個領域的面向對象的分析和設計減少到兩個簡單的問題: 首先，系統中的對象是什么？其次，需要的系統行為如何在對象中分配？

　已經明確要建立的正確的對象集，并且你已經為一個系統分配了合適的類集，你的項目將會進展順利。最難的工作恐怕是我們聽起來覺得很很順耳的“分配行為是不錯的工作”這句話，這也是有經驗的面向對象分析者的生存之本。

　Drive the Static Model from the Dynamic Models從動態模型中分離出靜態模型

　無論你打算在哪個過程使用UML，從動態模型中分離出靜態模型（類圖）是不錯的實踐方式，從較高層次的用例圖開始，尤其是使用UML 時序圖在類圖中分配行為。 這個理論，是從Jacobson的OOSE/Objectory 過程中得來的，是1993年的時候一個關系好的Objectory咨詢者解釋給我聽的。在過去的四年中我繼續把它作為一種設計形式在教，它內在的智慧和廣泛的應用讓我已經越來越信服它了。

　這個觀點的本質在于： 通過遵從對象模型方法我們可以開始并且得到一個系統的粗略的對象集，這同通過問題描述來尋找名詞得到“現實世界”或“問題領域”很相似。有時，我們可以做出聰明的猜測，一個特殊的類可能會是一個特殊操作的容器。但是，通常在面向對象的設計過程中，我們發現缺少用例開發來考慮靜態模型是幼稚的。

　以我的經驗，面向對象分析與設計的實質在于真正好的方法解決類中分配行為的問題，把用例在更詳細的（信息傳遞/方法）階段。正規的或者非正規的，我所遇到的年長的的面向對象分析者大部分是這樣設計的。當方法不正式時（不可見），設計者對怎樣從一系列給定的領域對象和用例中得到一個明確的方法充滿疑惑。通常，在使用一個系列像“多態、封裝接口“這樣的行話時這樣的疑慮又會產生。這樣能限制項目組成員完成有用的設計評估，讓水平高的程序員更靈活地根據情況完成任務。

　然而，在我看來，在UML（參看“UML模型如何匹配“，關注UML， SR4 頁，時序圖例子）中使用時序圖設計方法才能更好的完成。時序圖通過左側的早先的（需求階段，用戶手冊視圖）父用例文本描述，圖中間的實際的詳細的動態行為（每一個方法和觸發事件）描述來實現的。在一頁紙上描述看出詳細設計和需求階段用例描述需要快速的瀏覽需求，可以證明至少你的用例設計符合需求。簡單的重復系統中所有用例，將會得到一個可跟蹤的設計。

　畫時序圖的過程中，在設計中要確認具體的操作并把它分給具體的對象。雖然畫動態（時序）圖實際上也是在創建靜態類模型。時序圖是教我們如何從抽象的世界中找到對象模型的。

　Defer Assigning Operations to Classes操作遲些分配給類

　在項目分析階段不要過多的去關注將操作放進哪個類中。除了大部分顯而易見的情況外（有時連這些也會出錯），很可能規劃錯誤。經驗告訴我，做這些行為分配決定的時候最好仔細，隨著動態模型的開發一次一個。

　要把這種分離一直記?。ǚ治觯菏裁词菍ο?？設計：行為如何分配？）會幫助項目組定義分析和設計的界限。我們最先的統一對象建模過程方法在最初的分析階段使用了對象建模方法符號，在設計階段使用了Booch符號。在分析的過程中對象建模方法被使用，更詳細的設計階段的模型使用Booch方法。在UML中，這些符號被融合成單一的，對象模型方法。隨著分析和設計符號的模糊不清，項目組經常要分清分析和設計的界限在哪兒會很困難。

　即使我在教跌代和遞增過程， 在某些邏輯點上，需求和設計評估是必須的。如果我在評估一個分析模型，我并不會很在意類的操作（在大多數場合，如果沒有我會很高興）。我在尋找一個好的域類集和可以理解的用例模型。而在設計評估時，所有的操作都需要考慮在內，在時序圖中需求和設計必須可以跟蹤。設計者必須能解釋清楚為什么他會把一些操作放在特定的類中。

　Simply Suclearcase/" target="_blank" >ccessful簡單既成功

　在項目中使用UML，需要時刻記住的是保持簡單，先寫用戶手冊（一次一個用例），同時讓項目組對過程有統一的認識。記住，UML是一種符號，而不是過程。我所見到的最成功的項目都采用用例驅動，迭代，遞增方法的。如果能把過程細化并且讓項目組掌握技巧，UML項目已經離成功不遠了。

原文轉自：http://www.anti-gravitydesign.com