在oo開發中，至關重要的能力是熟練地為軟體物件分配職責；
分析(analysis)強調的是對問題和需求的調查研究，而不是解決方案；有益的分析和設計可以概括為：做正確的事（分析）和正確地做事（設計）。設計(design)強調的是滿足需求的概念上的解決方案(在軟體方面和硬體方面)，而不是其實現。
物件導向分析，強調的是在問題領域內發現和描述物件（或概念）。定義用例物件導向設計，強調的是定義軟體物件以及他們如何協作以實現需求。
需求分析可能包括人們如何使用應用的情節或場景，這些情節或場景可以被編寫成用例（use case）。分配物件職責和繪製互動圖
順序圖是描述協作的常見表示法。他展示出軟體物件之間的訊息流，和由為訊息引起的方法呼叫定義領域模型
物件導向分析關注從物件的角度建立領域描述，物件導向分析需要鑑別重要的概念、屬性和關聯。定義設計類圖設計類圖有效的表示類定義的靜態檢視。這樣可以描述類的屬性和方法。物件導向分析的結果可以表示為領域模型，在領域模型中展示重要的領域概念或物件。（也稱概念物件模型）。
與領域模型表示的是真實世界的類，設計類圖表示的是軟體類。迭代開發：
迭代開發（iterative development）是up和大多數其他現代方法中的關鍵實踐。在這種生命週期方法中，開發被組織成一系列固定的短期（如三個星期）小專案，稱為迭代（iteration），每次迭代都產生經過測試、整合並可執行的區域性系統。每次迭代都具有各自的需求分析、設計、實現和測試活動。迭代開發的優點：反饋改寫的必要性
在複雜、變更系統中（如大多數軟體專案），反饋和調整是成功的關鍵要素。1）在第1次迭代之前，召開第乙個時間定量的需求工作會議，例如確切地定義為兩天時間，業務和開發人員（包括首席架構師）需要出席。
2）在第1次迭代之前，召開迭代計畫會議，選擇上述三種用例的子集，在特定時間內（例如，四周的時間定量迭代）進行設計、構造和測試。
3）在三到四周內完成第1次迭代（選擇時間定量，並嚴格遵守時間）：
4）在第1次迭代即將結束時（如最後一周的星期三和星期四），召開第二次需求工作會，對上一次會議的所有材料進行複查和精化，然後選擇具有重要架構意義和高業務價值的另外10%到15%的用例，用一到兩天對其進行詳細分析。
5）於周五上午，舉行下一迭代的迭代計畫會議。
6）以相同步驟進行第2次迭代。
7）反覆進行四次迭代和五次需求工作會，這樣在第4次迭代結束時，可能已經詳細記錄了大約80%-90%的需求。
8）我們大概推進了整個專案過程的20%。此時，可以估計這些精化的、高質量的需求所需工作量和時間。因為具有依據現實得出的調查、反饋結論並進行了早期程式設計和測試，因此估計能夠做什麼和需要多長時間的結果會更為可靠。
9）此後，一般不需要再召開需求工作會；需求已經穩定了（儘管需求永遠不會被凍結）。接下來是一系列為期三周的迭代，在最後乙個周五召開的迭代計畫會上選擇適宜的下一步工作，每次迭代都要反覆詢問：「就我們現在所知，下乙個三周應該完成的、最關鍵的技術和業務特性是什麼？」
利用這種方式，經過早期探索式開發的幾次迭代之後，團隊將能夠更準確地回答「什麼、多少、何時」。敏捷開發方法通常應時間定量的迭代和進化式開發，使用自適應計畫，提倡增量交付幷包含其他提倡敏捷性的價值和實踐。並沒有精確定義。
建模（構建uml草圖……）的目的主要是為理解，而非文件。
up描述了科目中的活動，例如編寫用例。科目：是在乙個主題域中的一組活動（及相關製品），eg.需求分析中的活動
製品：是對所有工作產品的統稱（eg.**，文件，圖，模型等）
讀書筆記 UML和模式應用 用例
通俗地講，用例是文字形式的情節描述，用以說明某參與者使用系統以實現某些目標。注意 用例不是圖形，而是文字。用例初學者的常見錯誤就是注重於次要的uml用例圖，而非重要的用例文字。本質上，用例是通過編寫使用系統實現使用者目標的情節來發現和記錄功能性需求，也就是使用的案例 cases of use 定義 ...
設計模式讀書筆記（一） UML
統一建模語言 unified modeling language,uml s 是一種視覺化的標準建模語言，是一種分析和設計語言，通過uml可以構造軟體系統的藍圖。uml通過統一的表示方法，讓不同知識背景的領域專家 系統分析設計人員和開發人員以及使用者可以方便的交流。1.uml的結構 5種檢視 vie...
UML讀書筆記（1）
uml的定義 unified modeling language 統一建模語言。在系統的開發過程中，最關鍵的一點是要用一種系統分析員，客戶，程式設計師和其他系統開發所涉及到的人員能夠理解和達成一致的方式來組織系統的設計過程，uml就提供了這種組織方式。uml的組成包括類圖，物件圖，用例圖，狀態圖，順...