第一部分 緒論
1、在OO開發中，至關重要的能力是熟練地為軟件對象分配職責；個人認為將對象進行抽象的能力也相當重要。
2、分析(analysis)強調的是對問題和需求的調查研究，而不是解決方案；設計(design)強調的是滿足需求的概念上的解決方案(在軟件方面和硬件方面)，而不是其實現。
有益的分析和設計可以概括為：做正確的事（分析）和正確地做事（設計）。
3、需求分析可能包括人們如何使用應用的情節或場景，這些情節或場景可以被編寫成用例（use case）。
4、面向對象分析關注從對象的角度創建領域描述，面向對象分析需要鑒別重要的概念、屬性和關聯。面向對象分析的結果可以表示為領域模型，在領域模型中展示重要的領域概念或對象。
5、面向對象設計關注軟件對象的定義-它們的職責和協作。
6、與領域模型表示的是真實世界的類，設計類圖表示的是軟件類。
7、敏捷建模（agile modeling）強調了UML作為草圖的方式，這也是適用UML的普通方式，而且通常對時間投入具有高回報（一般費時較短）。
8、迭代開發（iterative development）是UP和大多數其他現代方法中的關鍵實踐。在這種生命周期方法中，開發被組織成一系列固定的短期（如三個星期）小項目，稱為迭代（iteration），每次迭代都產生經過測試、集成并可執行的局部系統。每次迭代都具有各自的需求分析、設計、實現和測試活動。
9、迭代開發的優點包括：
- 減少項目失敗可能性，提高生產率，降低缺陷率。
- 在早期緩解高風險（技術、需求、目標、可用性等等）。
- 早期可見的進展。
- 早期反饋、用戶參與和調整，會產生更接近涉眾真實需求的精化系統。
- 可控復雜性；團隊不會被“分析癱瘓”或長期且復雜的步驟所淹沒。
- 一次迭代中的經驗可以被系統地用于改進開發過程本身，并如此反復進行下去。
10、在復雜、變更系統中（如大多數軟件項目），反饋和調整是成功的關鍵要素。
11、如何進行迭代和進化式分析和設計：
1）在第1次迭代之前，召開第一個時間定量的需求工作會議，例如確切地定義為兩天時間，業務和開發人員（包括首席架構師）需要出席。
- 在第一天上午，進行高階需求分析，例如僅僅確定用例和特性的名稱，以及關鍵的非功能性需求。這種分析不可能是完美的。
- 透過咨詢首席架構師和業務人員，從高階列表中選擇10%列表項，這些項目具備以下三種性質：1，具有重要的架構意義；2，具有高業務價值；3，具有高風險。
- 在剩下的一天半內，對這三個用例的功能和非功能性需求進行詳細的分析。完成這一過程后，對10%進行了深入分析，90%進行了高階分析。
2）在第1次迭代之前，召開迭代計劃會議，選擇上述三個用例的子集，在特定時間內（例如，四周的時間定量迭代）進行設計、構造和測試。
3）在三到四周內完成第1次迭代（選擇時間定量，并嚴格遵守時間）：
- 在開始的兩天內，開發者和其他成員分組進行建模和設計工作，在首席架構師德帶領和指導下，于“公共作戰室”的眾多白板上，畫出UML的草圖（及其他的模型）。
- 然后，開發者摘掉其“建模帽子”并戴上“編程帽子”，開始編程、測試和集成工作并且剩余的時間均用于完成這項工作。
- 進行大量的測試，包括單元測試、驗收測試、負載測試和可用性測試等。
- 在結束前的一周，檢查是否能夠完成初始的迭代目標；如果不能，則縮小迭代的范圍，將次要目標置回任務列表中。
- 在最后一周的星期二，凍結代碼。必須檢入、集成和測試所有代碼，以建立迭代的基線。
- 在星期三的上午，向外部涉眾演示此局部系統，展示早期可視進展，同時要求反饋。
4）在第1次迭代即將結束時（如最后一周的星期三和星期四），召開第二次需求工作會，對上一次會議的所有材料進行復查和精化，然后選擇具有重要架構意義和高業務價值的另外10%到15%的用例，用一到兩天對其進行詳細分析。
5）于周五上午，舉行下一迭代的迭代計劃會議。
6）以相同步驟進行第2次迭代。
7）反復進行四次迭代和五次需求工作會，這樣在第4次迭代結束時，可能已經詳細記錄了大約80%-90%的需求。
8）我們大概推進了整個項目過程的20%。此時，可以估計這些精化的、高質量的需求所需工作量和時間。因為具有依據現實得出的調查、反饋結論并進行了早期編程和測試，因此估計能夠做什么和需要多長時間的結果會更為可靠。
9）此后，一般不需要再召開需求工作會；需求已經穩定了（盡管需求永遠不會被凍結）。接下來是一系列為期三周的迭代，在最后一個周五召開的迭代計劃會上選擇適宜的下一步工作，每次迭代都要反復詢問：“就我們現在所知，下一個三周應該完成的、最關鍵的技術和業務特性是什么？”
利用這種方式，經過早期探索式開發的幾次迭代之后，團隊將能夠更準確地回答“什么、多少、何時”。
12、建模（構建UML草圖……）的目的主要是為理解，而非文檔。
第二部分 初始階段
1、用一句話來概括初始階段：預見項目的范圍、設想和業務案例。用一句話來概括初始階段要解決的主要問題：涉眾是否就項目設想基本達成一致，項目是否值得繼續進行認真研究。
2、需求分析的最大挑戰是尋找、溝通和記?。ㄍǔＪ侵赣涗洠┦裁词钦嬲枰?，并能夠清楚地講解給客戶和開發團隊的成員。
3、在統一過程中，需求按照“FURPS+”模型進行分類，這是一中有效的記憶方法，其含義如下：
- 功能性（Funcational）：特性、功能、安全性。
- 可用性（Usability）：人性化因素、幫助、文檔。
- 可靠性（Reliability）：故障頻率、可恢復性、可預測性。
- 性能（Performance）：響應時間、吞吐量、準確性、有效性、資源利用率。
- 可支持性（Supportability）：適用性、可維護性、國際化、可配制性。
”FURPS+“中的”+“是指一些輔助性的和次要的因素，比如：
- 實現（Implementation）：資源閑置、語言和工具、硬件等。
- 接口（Interface）：強加于外部系統接口之上的約束。
- 操作（Operation）：對其操作設置的系統管理。
- 包裝（Packaging）：例如無力的包裝盒。
- 授權（Legal）：許可證或其他方式。
若想從生活中得到什么，必不可少的第一步就是：決定想要什么。 -本。斯坦(Ben Stein)
4、用例是文本形式的情節描述，廣泛應用于需求的發現和記錄工作中。
5、用例是一種優秀的方法，使領域專家或需求提供者自己編寫（或參與編寫）用例成為可能，并使這項工作難度降低。
第三部分 細化迭代1 基礎
1、細化（elaboration）是一般項目中最初的一系列迭代，其中包括：
- 對核心、有風險的軟件架構進行編程和測試。
- 發現并穩定需求的主體部分。
- 規避主要風險。
細化階段是最初的一系列迭代，在這一階段，小組進行細致的調查、實現（編程和測試）核心架構、澄清大多數需求和應對高風險問題。
2、在細化階段可能出現的一些關鍵思想和最佳實踐包括：
- 實行短時間定量、風險驅動的迭代。
- 及早開始編程。
- 對架構的核心和風險部分進行適應性的設計、實現和測試。
- 盡早、頻繁、實際地測試。
- 基于來自測試、用戶、開發者的反饋進行調整。
- 通過一系列討論會，詳細編寫大部分用例和其他需求，每個細化迭代舉行一次。
3、通過關聯而不是屬性來表示概念類之間的關系。
4、沒有所謂唯一正確的領域模型。所有模型都是對我們試圖要理解的領域的近似。領域模型主要是在特定群體中用于理解和溝通的工具。
5、在同一層內的對象在職責上應該具有緊密關聯，不同層中對象的職責則不應該混淆。
6、需要哪些對象，它們如何通過消息和方法進行協作，通過動態對象建模（例如繪制順序圖）才能真正落實這些準確和詳細的結論。
7、應該把時間花費在交互圖（順序圖或通信圖），而不僅是類圖上。
8、任何順序圖都可以使用sd圖框圍繞起來，并對其命名。當你想要引用相應名字的sd圖框時，可以使用ref圖框。
9、在類圖中，使用依賴線描述對象之間的全局變量、參數變量、局部變量和靜態方法（對其他類的靜態方法加以調用）的依賴。
10、GRASP是通用職責分配軟件模式（General Responsibility Assignment Software Patterns）的縮寫。GRASP的9個模式如下所示：
創建者（Creator）
如果以下的條件之一（越多越好）為真時，將創建類A實例的職責分配給類B：
- B“包含”或組成聚集A。
- B記錄A。
- B直接使用A。
- B具有A的初始化數據，并且在創建A時會將這些數據傳遞給A。因此對于A的創建而言，B是專家。
- B是對象A的創建者。
注意：對象的創建常常具有相當的復雜性，這時最好的方法是把創建職責委派給稱為具體工廠（Concrete Factory）或抽象工廠（Abstract Factory）的輔助類，而不是使用創建者模式所建議的類。
信息專家（Information Expert）
把職責分配給信息專家，它具有實現這個職責所必需的信息。分配職責應當從清晰地描述職責開始。
注意：由于耦合與內聚問題導致某些情況下，專家模式建議的方案并不合適。
低耦合（Low Coupling）
分配職責，使耦合性盡可能低。利用這一原則來評估可選方案。
控制器（Controller）
控制器是UI層之上的第一個對象，它負責接收和處理系統操作消息。
高內聚（High Cohesion）
內聚（或更為專業地說，是功能內聚）是對元素職責的相關性和集中度的度量。
多態性（Polymorphism）
純虛構（Pure Fabrication）
間接性（Indirection）
防止變異（Protected Variations）
喜歡 
頂
難過
囧
圍觀
無聊
