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 Successful簡單既成功
在項目中使用UML，需要時刻記住的是保持簡單，先寫用戶手冊（一次一個用例），同時讓項目組對過程有統一的認識。記住，UML是一種符號，而不是過程。我所見到的最成功的項目都采用用例驅動，迭代，遞增方法的。如果能把過程細化并且讓項目組掌握技巧，UML項目已經離成功不遠了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
