【正文】 ? 項(xiàng)目組織也許需要改變其結(jié)構(gòu)以適應(yīng)面向?qū)ο蟮拈_發(fā)。 ? 充分了解你的財產(chǎn)，并基于這些財產(chǎn)建立一個轉(zhuǎn)變計劃，這對于成功地轉(zhuǎn)向非常重要。 ? 面向?qū)ο蠓椒ㄋ鶐淼氖找娌粫霈F(xiàn)在你的第一 個項(xiàng)目中，也許第二個項(xiàng)目中也不會。 要點(diǎn) ? 面向?qū)ο蠓椒赡懿⒉贿m合于所有的項(xiàng)目。 ? 在實(shí)現(xiàn)了第一個項(xiàng)目后，組織機(jī)構(gòu)會有一些分化：一些人是 對象創(chuàng)建者 ，他們負(fù)責(zé)生成對象，是 實(shí)現(xiàn)領(lǐng)域方面的專家 ；另一些人是系統(tǒng)創(chuàng)建者 ，他們 是應(yīng)用領(lǐng)域方面的專家 。對復(fù)用的分析、設(shè)計、測試、代碼等所進(jìn)行的度量應(yīng)當(dāng)包含在每一個項(xiàng)目的最重要的統(tǒng)計中。 ? 為提高復(fù)用，應(yīng)當(dāng) 制定一些獎勵措施 ，如給對象開發(fā)人員以高報酬，給利用復(fù)用的用戶以紅包，給項(xiàng)目負(fù)責(zé)人以特殊獎勵等。 步驟 11：開始建立復(fù)用庫 ? 在開發(fā)的機(jī)構(gòu)中應(yīng)建立起用于復(fù)用的最基礎(chǔ)的機(jī)制。 但千萬、千萬不要將項(xiàng)目的交付日期提前 。因此，建議 必須嚴(yán)格遵守項(xiàng)目的進(jìn)度計劃 。它們可能要在以后的幾年中，在對系統(tǒng)進(jìn)行修改或升級時才會被發(fā)現(xiàn)。 ? 對這個最初的信息模型，應(yīng)征求其他人的意見。 ? 如果不考慮面向?qū)ο蠓椒ǖ奶厥獠糠?，那么所有的面向?qū)ο蠓椒ǘ紩赃@種或那種方式建立一個 信息模型 。 ? 培訓(xùn)和個別輔導(dǎo)可能是管理上的最好投資，它能保證成功地轉(zhuǎn)向面向?qū)ο蠓椒ā? ? 對工作人員的培訓(xùn)不是買一本書給他就完事大吉。 步驟 8：避免學(xué)習(xí)走彎路 ? 在轉(zhuǎn)向面向?qū)ο髸r，注意培訓(xùn)和咨詢?？赡艿脑挘?將它們引入到一 些并行的試驗(yàn)性項(xiàng)目中 。 ? 解決的辦法是 分而治之 。 ? 每引入一種新技術(shù)，它 與所有其他技術(shù)之間可能的相互作用的數(shù)量是非線性的 ， 按 N次冪增長 。 ? 一個解決辦法是 激發(fā)全體項(xiàng)目組人員的信心 ，通過良好的培訓(xùn)和個別輔導(dǎo) ， 使他們成為項(xiàng)目負(fù)責(zé)人的積極擁戴者 。 ? 例如，發(fā)揮項(xiàng)目組全體成員的積極性，是項(xiàng)目成功的關(guān)鍵。 步驟 6：準(zhǔn)備一些花招 ? 每個軟件開發(fā)項(xiàng)目都有它既定的方針策略。 ? 好的微度量能夠區(qū)分項(xiàng)目的成功或失敗。 一個模塊開發(fā)接近完成時，這個度量結(jié)果應(yīng)接近于零。 ? 良好監(jiān)控的關(guān)鍵在于 微度量 ，即對進(jìn)度、質(zhì)量、效率等的度量。 步驟 5：建立有意義的度量 ? 研究證明，在一個成功的項(xiàng)目中，預(yù)期完成工作的百分比與實(shí)際完成工作的百分比十分接近。 ? 利用這個試驗(yàn)性項(xiàng)目，學(xué)習(xí)新技術(shù)、新方法。 步驟 4：標(biāo)識一個“共生項(xiàng)目” (Symbioject) ? 如果對一個新的陌生的技術(shù)沒有充分了解，沒有弄清它對項(xiàng)目、組織和人員有什么影響之前，貿(mào)然使用它開發(fā)一個重大項(xiàng)目是非常莽撞的。 ? 還需要評估人力資源。 ? 工作產(chǎn)品 是指作為特定項(xiàng)目的里程碑應(yīng)當(dāng)提交的成果； ? 人工制品 是指在開發(fā)過程中產(chǎn)生的不交付的成果，如數(shù)據(jù)流圖、結(jié)構(gòu)圖等。 ? 對大多數(shù)人來講， 完全拋棄以前的所有成果從頭開始是一種很愚蠢的做法 。 ? 轉(zhuǎn)向面向?qū)ο蟮倪^程有兩種觀點(diǎn)： 逐漸演變 或全新變革 。 ? 面向?qū)ο蠓椒ㄋ鶐淼?收益將在下一個項(xiàng)目中得到 。 ? 復(fù)用能帶來高的投資回報率 (48個月后達(dá) 30:1)。 ? 沒有回頭路可走。我們不能保證這些步驟很容易實(shí)現(xiàn)，但按這些步驟認(rèn)真去做，肯定不會失敗。 ? 由于提交大而復(fù)雜的軟件系統(tǒng)所造成的在預(yù)算和進(jìn)度上不斷增加的壓力，促使許多開發(fā)機(jī)構(gòu)從當(dāng)前傳統(tǒng)的軟件開發(fā)方法倉促地轉(zhuǎn)向面向?qū)ο蠓椒?。該測試主要是對所有的服務(wù)及其組成部分進(jìn)行檢查，以確認(rèn)它們與服務(wù)的規(guī)格說明和屬性定義是一致的。它是黑盒測試的基礎(chǔ)。 ? 這種測試要求在消息的源端或目的端用虛擬的樁 (stub)操作代替實(shí)際的源端服務(wù)或目的端服務(wù)，以便獨(dú)立地對每個服務(wù)進(jìn)行測試。這個測試臺能夠讓對象接收消息，并能對所生成的消息進(jìn)行顯示、捕捉和分析。 ? 由于對象可以在許多不同的應(yīng)用程序中復(fù)用，因此必須在通用的復(fù)用環(huán)境中執(zhí)行。事實(shí)上，這些日志和記錄可能會建立某種與合同有關(guān)的里程碑。其次，要求能夠訪問軟件的消息、屬性，及其他軟件成分。 ? 白盒測試的準(zhǔn)備工作由一個獨(dú)立的小組完成。 ? 要求執(zhí)行白盒測試的人熟悉開發(fā)環(huán)境和設(shè)計方法，對應(yīng)用領(lǐng)域的知識不是必須的。 ? 總的來講，白盒測試是在相關(guān)的黑盒測試完成之后進(jìn)行的。 ? 這種驗(yàn)證 不包括 服務(wù)級的測試 。 ? 在 EROI圖中定義的類所能識別的每一個事件都必須經(jīng)過驗(yàn)證。 ?白盒測試 ? 基于各種設(shè)計文檔中所定義的內(nèi)部系統(tǒng)結(jié)構(gòu) 。在普通開發(fā)環(huán)境中利用發(fā)布前的各種結(jié)果就可以做。 系統(tǒng)級的測試 ? 黑盒測試需要兩類測試人員：一類是熟悉開發(fā)方法的人，他們能夠看懂各種圖表、符號；另一類是用戶，他們對用戶界面最有發(fā)言權(quán)。從用戶角度捕捉系統(tǒng)行為。黑盒測試的目的是要確認(rèn)功能的執(zhí)行與規(guī)格說明相一致。 ? 黑盒測試 ? 這種測試基于系統(tǒng)級的規(guī)格說明。 對基于對象的設(shè)計進(jìn)行測試 ? 將系統(tǒng)級測試與對象級測試區(qū)分開是很重要的。 ? RAD對象之間的消息傳遞都通過函數(shù)或子程序調(diào)用來完成。 ? 所有的數(shù)據(jù)庫接口都通過 RAD對象實(shí)現(xiàn)。 ? 所有人機(jī)交互部分中的對象應(yīng)作為 RAD的屏幕和表格實(shí)現(xiàn)。使所有的系統(tǒng)邏輯都包含在其中。需要有項(xiàng)目標(biāo)準(zhǔn)和開發(fā)人員守則。由于它以快速系統(tǒng)展開為基礎(chǔ)，因而 RAD工具的成本是合理的。 ? 原因在于 RAD工具通常 不支持事物分離規(guī)則 。 將線程分布到各組 產(chǎn)生實(shí)現(xiàn)方案 評審線程 需要 產(chǎn)生數(shù)據(jù)庫 嗎？ 線程 可接受 嗎？ 產(chǎn)生數(shù) 據(jù)庫實(shí) 現(xiàn)方案 基于線程的實(shí)現(xiàn)流程圖 (續(xù) ) 將線程分布到各組 產(chǎn)生 OOM線程段 解除處理 在快速應(yīng)用開發(fā) (RAD)環(huán)境下實(shí)現(xiàn)面向?qū)ο蟮脑O(shè)計 ? 目前存在多種應(yīng)用程序構(gòu)造系統(tǒng)，即 RAD環(huán)境。有些線程可以接受，有些現(xiàn)成需要重做。 ? 一天結(jié)束時，項(xiàng)目開發(fā)組對這天實(shí)現(xiàn)的線程進(jìn)行評審。 初始線程 標(biāo)識需求 選擇一個線程 將線程標(biāo)記于矩陣中 與開發(fā)組會商 要更 改 RDM 嗎？ 要建立 或修改線 程嗎？ 修改 RDM 基于線程的實(shí)現(xiàn)流程圖 ? 然后將所驗(yàn)收的線程交給開發(fā)組，一個組負(fù)責(zé)設(shè)計用戶界面，一個組負(fù)責(zé)面向?qū)ο蠼！? ? 可能提出的線程中有一些不能實(shí)現(xiàn)，這些線程就需要修改，或者對需求提出質(zhì)疑。 ? 下圖描述了項(xiàng)目開發(fā)組在某一天根據(jù)迭代的開 發(fā)過程進(jìn)行的活動?？梢哉J(rèn)為系統(tǒng)一次在執(zhí)行一個線程。 預(yù)分析 活動 各種需 求定義 , 建模 OOA OOD GUI OOP Deploy ment 預(yù)分析工作產(chǎn)品 (OOA工作表格 , E/R,初始 GUI布局 ) 初始 GUI布局 (包 括各種功能定義 , 數(shù)據(jù)定義等。 ? 用于履行這種迭代的機(jī)制就是線程。 ? 圖中的各種活動并不是以瀑布流水的方式組織起來的。 ? 對于一個 大而復(fù)雜的軟件系統(tǒng) ， 采用迭代的軟件開發(fā)過程非常重要 。但總的說來， 開發(fā)過程獨(dú)立于開發(fā)環(huán)境或開發(fā)過程 。 一個迭代的軟件開發(fā)過程 ? 任何一個軟件系統(tǒng)的分析和設(shè)計都是在整個軟件開發(fā)過程的上下文環(huán)境中執(zhí)行的。其結(jié)果就是自頂向下，從功能上分解對象。 ?對于面向微處理器的嵌入的、實(shí)時的程序，只能用普通的匯編語言編寫程序。 ?每個項(xiàng)目都有自己獨(dú)特的應(yīng)用環(huán)境。理由是： ?許多老程序員對面向?qū)ο蟛皇煜?，但他們了解業(yè)務(wù)和事務(wù)規(guī)則。面向?qū)ο笫且环N先進(jìn)的技術(shù)，它使得可以復(fù)用的東西遠(yuǎn)遠(yuǎn)超過了代碼。現(xiàn)在談復(fù)用時，是指復(fù)用 事務(wù)規(guī)則 、 需求 、 環(huán)境 、 文件 、體系結(jié)構(gòu) 、 測試計劃 等。為了識別事件并產(chǎn)生相應(yīng)的響應(yīng)，必須給出所有的設(shè)計。 ? 設(shè)計評審過程是一個持續(xù)進(jìn)行的過程 ，與項(xiàng)目組織的文化背景有關(guān)，與正式的里程碑評審過程不同。 ? 我們希望將所開發(fā)的用戶界面屏幕放到設(shè)計文檔中。 ? 為了更好地描述 OOD模型， 可以使用任何類型的圖形表示工具或其他規(guī)格說明 。 ? 如果設(shè)計人員在某一個大陸上，而實(shí)現(xiàn)人員在另一個大陸上，就需要大量細(xì)節(jié)的說明。 ? 在小規(guī)模的項(xiàng)目中，實(shí)現(xiàn)人員就是設(shè)計人員。 ? 各個項(xiàng)目要求的詳細(xì)程度各不相同 。 ? OOD模型的文檔好比建筑師設(shè)計出來的建筑樓房用的藍(lán)圖，應(yīng)具有詳細(xì)的細(xì)節(jié)。為提高效率和調(diào)度，降低了許多類的可復(fù)用性。 ? ECS系統(tǒng)的大部分設(shè)計簡單明了，對象包含了數(shù)量合理的屬性和服務(wù)，耦合性和內(nèi)聚性也很好。從產(chǎn)生的 OOA/OOD 模型來看，幾乎所有的對象都是高內(nèi)聚、低耦合的。這些名字是否與對象的數(shù)據(jù)和服務(wù)相符？如果不符，為什么不符？ 事例分析系統(tǒng)的質(zhì)量問題 ? 良好的設(shè)計來自于良好的分析。 ? 通過檢查，了解當(dāng)前的層次結(jié)構(gòu)的狀況，發(fā)掘出更好