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

在面向?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(shè)計（OOD）中，強調(diào)的是定義軟件對象及它們?nèi)绾螀f(xié)作以實現(xiàn)需求。（類圖與順序圖）

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

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

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

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

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

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

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

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

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

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

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

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