在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%）的具有重要架構意義和高價值的用例）。用例應該包含所有涉眾關注點的事物。
準則：
以無用戶界面的本質風格編寫用例；排除用戶界面而關注參與者的意圖。
編寫簡潔的用例。
編寫黑盒用例，不對系統內部工作、構件或設計進行描述。而是通過職責來描述系統。
采用參與者和參與者目標的視點。
這些天主要在做一些翻譯的事情。周日的時候抽了半天時間給一本書做了一章的試譯。似乎并不是太意外，編輯今天告訴我試譯沒有通過，與他們的要求還有一定的差距。然后他把他批注過的試譯發給了我。看得出編輯是一個非常負責任的人，幾乎所有的句子都被他詳細的review過。總結了一下原因：
1.沒有經驗。這是我第一次翻譯書，犯了很多常識性錯誤。例如少用被字句，章號用阿拉伯數字，圖題和圖中需  要翻譯的英文應該對應，我、你、你的這些代詞，能不翻譯盡量不要翻譯等等。
2.對專業知識不熟悉。這本書是關于swing,java2d\3d的，而自己在這方面沒有什么經驗，只是使用過Swing，這  樣就使一些專業術語翻譯很不到位。對英文的理解會存在問題。
3.自己翻譯的理解問題。一些句子不通順，不好理解，措辭的不當。其實這個問題我認為主要是匆忙不負責任引  起的。
盡管被cut了，但我認為自己還是學到了很多東西的：一些常用的翻譯技巧和注意事項，對相關知識不熟悉時不要隨便翻譯，遇到難度的句子要做批注，翻譯完畢后一定要review等等。感謝華章圖書的編輯，他讓我懂得許多。也讓我長長出了口氣：不用再去網上找java2d/3d方面的文檔和書籍，不用狂補相關的知識。另外要感謝的是阿敏總司令，是他介紹給我這個機會，但是我沒有把握住。
翻譯，并不是一件簡單的事情。
UML有三種使用方式：用作草圖繪制，用于藍圖繪制，用于程序編制。
傾向于將UML用于草圖繪制，繪制草圖的實質是選擇，重點是進行交流，常用的介質是白板。
草圖是故意不完備的，要突出重要的信息。草圖是探究性的，藍圖是定義性的。草圖用于正向工程（設計階段），藍圖用于逆向工程（根據已有的代碼導出）。詳細文檔應該根據代碼生成。

UML最重要的是類圖和順序圖。

瀑布風格和迭代風格
瀑布風格是基于活動來分解項目的，迭代風格根據功能子集來分解項目。
迭代的一種常用技術是時間框定法，迫使各次迭代的時間長度固定。通過定時擱置功能，使人們能夠在擱置日期和擱置功能之間進行明智的選擇。

敏捷過程是強適應性的過程。敏捷方法強調項目成功最重要的因素是人的素質以及人之間的良好協同，敏捷方法傾向使用時間框定的短小迭代。每一次迭代結束時要進行一次迭代回顧。

RUP本質上是一個迭代過程，分為四個階段：初始，細化，構造，移交。
需求分析最重要的是與用戶及客戶的交流。

類圖
類圖表述系統中各個對象的類型以及其間存在的各種靜態關系。
對不重要的事（如日期或布爾值，一般說，值類型）使用屬性，對較為重要的類使用關聯。
非常反感那些除了一組域及其get/set方法沒有行為的類。如果你在利用get方法重復調用數據，這預示著某一行為應該移往具有數據的對象。
依賴應該單向，依賴越少越好，特別謹慎循環依賴，尤其反對包間的循環依賴。對類使用依賴最常見的情形是闡明瞬間關系，比如，把一個對象作為參數傳遞到另一個對象時。
不要試圖使用對你可用的所有圖示法，保持圖示簡單，集中考慮關鍵方面。繪制類圖時總以使用某種形式的行為技術為宜。

順序圖
盡量省去回送。
單一職責，提倡分布式控制（把處理分散到多個對象里去）。
減少過程式編程，如if/else，改用多態解決類似問題。
把順序圖看作各個對象如何交互的形象化表示而不是一種對控制基理的建模方法。順序圖擅長示明對象間的協作，不擅長于示明行為的精確定義。

CRC卡
CRC的一個重要部分是認識職責。任意一個類都可以用少量職責對其概括。對具有三項以上職責的卡片提出質問，是否應該把類分解，或把職責合并成一個更高層次
的概述。
工作流開發已經有一段時間了，這里把自己的一些想法小結一下。僅僅就工作流引擎來說，不包括一些外圍的實現，例如流程定義器，管理控制，工作項列表等。
工作流引擎其實就是一個狀態機，只不過在狀態變化的過程中加入了其他一些工作。我把工作流引擎的職責理解為以下四個方面：
1、對工作流模式的支持。
   這無疑是最重要的部分，狀態的變遷往往取決于不同模式的選擇。支持的模式越多則客戶的開發代碼會越少。衡量一個工作流引擎的技術水準很大程度取決于引擎支持模式的多少。
2、工作流變量的傳遞和轉換。
   工作流引擎通過工作流變量與外部應用交互，工作流變量在各個活動節點以及父流程與子流程之間傳遞。變量除基本類型（String,int等）以外，也需要支持一些復雜的數據類型（例如對象，以一種配置映射的方式）。這里還涉及到一個上下文的問題。
3、任務項的分配。
   任務項的分配往往和工作流組織權限聯系起來，其實工作流組織權限存在的目的就是決定任務項分配，決定由誰來完成這個工作項。工作項涉及到的內容也比較多，比如工作項的回退，撤回等等。
4、調用外部應用。
   單純的表單推動已經不再適用，活動節點本身需要支持許多的業務操作，而這些操作與引擎本身是無關的，與外部的應用有關，所以就需要引擎提供一種調用外部應用的機制。外部應用可以是javabean,webservice,rcp等等形式。
除去上述四方面還有一些外圍的工作：例如時間服務，節點的事件機制等等。
對客戶而言，他們需要的僅僅只有兩個接口：任務項管理接口（比如提交任務項，委派任務項等等）和流程狀態管理接口（比如啟動一個新的流程實例，推動流程流轉等等）。在理想的情況下，給用戶提供一個封裝完全的提交頁面和父類Action也是很好的一種方法。
今天終于有空看看了Fielding的rest論文，沒有看完，很多文字確實難懂，但有些還是很有感觸的，做個記號。
一個軟件架構是一個軟件系統在其操作的某個階段的運行時元素的抽象。
架構元素：組件，連接器，數據，配置。
架構風格：一組協作的架構約束。
一種特定的架構可以由多種架構風格組成。
關鍵關注點的架構屬性
性能
最佳的應用性能是通過不使用網絡而獲得的。這意味著對于一個基于網絡的應用，最高效的架構風格是在可能的情況下能夠將對于網絡使用減少到最少的架構風格。
可伸縮性
表示在一個主動的配置中，架構支持大量的組件或大量的組件之間交互的能力。
簡單性
對組件之間的功能分配應用分離關注點原則。使得單個的組件足夠簡單，更容易被理解和實現。
可修改性
基于網絡的系統的一個特殊的關注點是動態的可修改性，它要求在對一個已部署的應用做出修改時，無需停止和重啟整個系統。包括：可進化性，可擴展性，可定制性，可配置性，可重用性。
可見性
能夠通過限制必須使用通用性的接口，或者提供訪問監視功能的方法，來影響基于網絡的應用中交互的可見性。在這種情況下，可見性是指一個組件對于其他兩個組件之間的交互進行監視或仲裁的能力。
可移植性
能夠在不同的環境下運行。
可靠性
當在組件、連接器或數據之中出現部分故障時，一個架構容易受到系統層面故障影響的程度。