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