在OO開發(fā)中，至關(guān)重要的能力是熟練地為軟件對象分配職責。

在面向?qū)ο蠓治鲋校∣OA），強調(diào)的是在問題領(lǐng)域內(nèi)發(fā)現(xiàn)和描述對象。OOA關(guān)注從對象的角度創(chuàng)建領(lǐng)域描述，OOA的結(jié)果可以表示為領(lǐng)域模型。需要注意的是，領(lǐng)域模型并不是對軟件對象的描述（區(qū)別于軟件中的對象類），它是真實世界領(lǐng)域中的概念和想象可視化。

在面向?qū)ο笤O計（OOD）中，強調(diào)的是定義軟件對象及它們?nèi)绾螀f(xié)作以實現(xiàn)需求。（類圖與順序圖）

迭代開發(fā)是OOA/D成為最佳實踐的核心。建議迭代的時間在2-6周之間，小步驟、快速反饋和調(diào)整。迭代的一個關(guān)鍵思想是時間定量，或時長固定。
1、在第一次迭代之前，召開第一個時間定量的需求工作會議（兩天）。業(yè)務和開發(fā)人員需要出席。
   a、高階需求分析。僅僅確定用例和特性的名稱，以及關(guān)鍵的非功能性需求（性能，可伸縮性等等）。
   b、通過架構(gòu)師和業(yè)務人員，從高階列表選擇10%列表項（例如，30個用例名中的10%，3個）。這3個用例      需要具備：具有重要的架構(gòu)意義；具有高業(yè)務價值；具有高風險（例如，可處理500個并發(fā)交易）。標      識這3個用例：UC2，UC11和UC14。
   c、剩下的一天半對這3個用例的功能和非功能性需求進行詳細的分析。
2、在第一次迭代之前，召開迭代計劃會議，選擇UC2，UC11和UC14的子集，在特定的時間內(nèi)（例如，四周）    進行設計、構(gòu)造和測試。要注意，并不是在第一次迭代中就要構(gòu)造全部的3個用例，可以將其分解為一系   列更為詳細的迭代任務。
3、在三到四周內(nèi)完成第一次迭代（嚴格遵守時間）
   a、在開始的兩天內(nèi)，開發(fā)者在架構(gòu)師指導下分組進行建模和設計工作。白板，UML草圖，界面、討論。
   b、編程。注意UML草圖只是參考
   c、測試
   d、結(jié)束前一周，檢查是否能夠完成初始迭代目標，如果不能，縮小迭代范圍。
   e、最后一周的周二，凍結(jié)代碼，集成和測試所有代碼，建立迭代的基線。
   f、周三上午，演示此局部系統(tǒng)，展示早期可視進展，要求反饋。
4、在第一次迭代即將結(jié)束時（最后一周的周三周四），召開第二次需求會議，對上次會議的所有資料進行復   查和精化。然后選擇具有重要架構(gòu)意義和高業(yè)務價值的另外10%到15%的用例，一到兩天詳細分析。這項工   作完成后，大約20-25%的用例得到了詳細記錄。
5、周五上午，舉行下一迭代的迭代計劃會議。
6、相同步驟2次迭代。
7、反復四次迭代和五次需求會議，這樣在第四次迭代結(jié)束后，可能已經(jīng)詳細記錄了80-90%的需求，但系統(tǒng)只   實現(xiàn)了10%。
8、大概推進了整個項目過程的20%。up里，屬于細化階段。此時，可以估計整個項目的工作量和時間。
9、一般不再需要需求會議，需求已經(jīng)穩(wěn)定了。接下來是一系列為期三周的迭代，在最后一個周五召開的迭代   計劃會上選擇適宜的下一步工作。
  
早期的迭代要致力于核心架構(gòu)的構(gòu)造，應該首先處理困難的和具有風險的事物。

建模（構(gòu)建UML草圖）的主要目的是為了理解，而非文檔。只需對設計中不常見、困難和棘手的一小部分問題建模和應用UML。不要單獨建模，而是結(jié)對（或三個人）在白板上建模。并行的創(chuàng)建模型（例如，類圖和順序圖交替開始）。UML細節(jié)是否精準不重要，重要的是人員能夠互相理解。堅持用最簡單、常用的UML元素。開發(fā)者應該為自己進行OO設計建模，而不是創(chuàng)建模型圖后交給其他人實現(xiàn)。

UP的核心思想是：短時間定量迭代、進化和可適應性開發(fā)。

初始階段是建立項目共同設想和基本范圍的比較簡短的起始步驟。包括確定大部分用例名稱，對10%的用例進行分析，關(guān)鍵的非功能需求的分析，業(yè)務案例創(chuàng)建和開發(fā)環(huán)境的準備。包含第一次需求研討會，并為第一次迭代制定計劃。要解決的主要問題：涉眾是否就項目設想基本達成一致，項目是否值得繼續(xù)進行認真研究。

用例是文本形式的情節(jié)描述，特別注意，用例是文本不是圖形！用例建模主要是編寫文本的活動，而非制圖。用例名稱應使用動詞開頭。
參與者的三種類型：主要參與者，協(xié)助參與者，幕后參與者。
用例的三種常用形式：摘要，非正式，詳述（在第一次需求會中，詳細的編寫其中少量（例如10%）的具有重要架構(gòu)意義和高價值的用例）。用例應該包含所有涉眾關(guān)注點的事物。
準則：
以無用戶界面的本質(zhì)風格編寫用例；排除用戶界面而關(guān)注參與者的意圖。
編寫簡潔的用例。
編寫黑盒用例，不對系統(tǒng)內(nèi)部工作、構(gòu)件或設計進行描述。而是通過職責來描述系統(tǒng)。
采用參與者和參與者目標的視點。


http://m.tkk7.com/ronghao 榮浩原創(chuàng)，轉(zhuǎn)載請注明出處：）