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

在面向對象分析中（OOA），強調的是在問題領域內發現和描述對象。OOA關注從對象的角度創建領域描述，OOA的結果可以表示為領域模型。需要注意的是，領域模型并不是對軟件對象的描述（區別于軟件中的對象類），它是真實世界領域中的概念和想象可視化。

在面向對象設計（OOD）中，強調的是定義軟件對象及它們如何協作以實現需求。（類圖與順序圖）

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

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

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

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

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


http://www.tkk7.com/ronghao 榮浩原創，轉載請注明出處：）