【正文】 D中各部分的構(gòu)造是不斷循環(huán)反復(fù)的 , 而不是一個(gè)個(gè)相繼順序構(gòu)造的。此時(shí)，以這些 OOA類為子類，定義一個(gè)父類。 ?針對(duì)無(wú)繼承語(yǔ)言的調(diào)整 ? 當(dāng)使用無(wú)繼承的程序設(shè)計(jì)語(yǔ)言時(shí)，必須把具有繼承關(guān)系的類層次結(jié)構(gòu)平鋪開來(lái)，成為一組類和對(duì)象。 ? 當(dāng)軟件運(yùn)行在一個(gè) CPU速度很快的計(jì)算機(jī)上，并是單機(jī)的人機(jī)交互時(shí)，大多數(shù)的時(shí)鐘周期都用在了等待用戶輸入上。 ? 預(yù)測(cè)軟件開銷集中在什么地 方是困難的 , 進(jìn)行優(yōu)化最有效的方法是在系統(tǒng)運(yùn)行時(shí)使用性能監(jiān)測(cè)工具對(duì)系統(tǒng)進(jìn)行觀測(cè)。在提交給實(shí)現(xiàn)者的規(guī)格說明中，將這個(gè)類放在一個(gè) 與 ECS的主處理器分離的處理器上 . ? 每個(gè)類增加服務(wù) Self Test來(lái)增強(qiáng)每個(gè)類的性能。 ECS的 HIC ? ECS的 HIC由各種電梯按鈕、指示燈及它們的接口組成，不存在屏幕、窗口等用戶界面需要進(jìn)行設(shè)計(jì)。 ―召喚事件”的執(zhí)行機(jī)制 召喚事件 召喚按鈕 報(bào)告 PDC HIC 我們有一個(gè)召喚 ！ ? 總結(jié) ? 每一個(gè)組織和用戶都有他的文化背景。 ?使用工具 定義一個(gè)高層的用戶界面和一些詳細(xì)的對(duì)話框 ，然后 定義 HIC對(duì)象 ，從而完成設(shè)計(jì)。 ? 用戶可以不需要 HIC，但不能免去用戶界面的設(shè)計(jì)。還要找出任務(wù)協(xié)調(diào)部分，通信的發(fā)、收關(guān)系，處理器的分配（客戶 服務(wù)器）或者消息 /線程序列等。 ―召喚事件”的執(zhí)行機(jī)制 召喚事件 召喚按鈕 PDC HIC 我們有一個(gè)召喚！ ? TMC 召喚中斷 輸入 寄存器 按下 按鈕 ?召喚按鈕共 78個(gè)（除第 1 層和第 40 層各有 1 個(gè)外，其他每層各有 2 個(gè)）。 ? 封裝需要做許多工作，這些開銷是必要的。這個(gè)代價(jià)必須付出，以獲取 復(fù)用性 、 可維護(hù)性 、 可擴(kuò)展性 等優(yōu)點(diǎn)。 ?重點(diǎn)在于 設(shè)計(jì)的明確性 ——看不懂 OOD設(shè)計(jì)，就無(wú)法復(fù)用它。一個(gè)對(duì)象可能自己不能響應(yīng)一個(gè)外部事件， 但它不能與多于 7 ? 2 個(gè)對(duì)象交互來(lái)完成某件事情 。 ? 系統(tǒng)整體規(guī)模的最小化 ——系統(tǒng)規(guī)模越大越不好 。 ? 通過檢查，了解當(dāng)前的層次結(jié)構(gòu)的狀況，發(fā)掘出更好的層次結(jié)構(gòu)。為提高效率和調(diào)度，降低了許多類的可復(fù)用性。 ? 如果設(shè)計(jì)人員在某一個(gè)大陸上，而實(shí)現(xiàn)人員在另一個(gè)大陸上，就需要大量細(xì)節(jié)的說明。為了識(shí)別事件并產(chǎn)生相應(yīng)的響應(yīng)，必須給出所有的設(shè)計(jì)。 ?每個(gè)項(xiàng)目都有自己獨(dú)特的應(yīng)用環(huán)境。但總的說來(lái)， 開發(fā)過程獨(dú)立于開發(fā)環(huán)境或開發(fā)過程 。 預(yù)分析 活動(dòng) 各種需 求定義 , 建模 OOA OOD GUI OOP Deploy ment 預(yù)分析工作產(chǎn)品 (OOA工作表格 , E/R,初始 GUI布局 ) 初始 GUI布局 (包 括各種功能定義 , 數(shù)據(jù)定義等。 初始線程 標(biāo)識(shí)需求 選擇一個(gè)線程 將線程標(biāo)記于矩陣中 與開發(fā)組會(huì)商 要更 改 RDM 嗎？ 要建立 或修改線 程嗎？ 修改 RDM 基于線程的實(shí)現(xiàn)流程圖 ? 然后將所驗(yàn)收的線程交給開發(fā)組，一個(gè)組負(fù)責(zé)設(shè)計(jì)用戶界面，一個(gè)組負(fù)責(zé)面向?qū)ο蠼！? ? 原因在于 RAD工具通常 不支持事物分離規(guī)則 。 ? 所有人機(jī)交互部分中的對(duì)象應(yīng)作為 RAD的屏幕和表格實(shí)現(xiàn)。 ? 黑盒測(cè)試 ? 這種測(cè)試基于系統(tǒng)級(jí)的規(guī)格說明。在普通開發(fā)環(huán)境中利用發(fā)布前的各種結(jié)果就可以做。 ? 總的來(lái)講，白盒測(cè)試是在相關(guān)的黑盒測(cè)試完成之后進(jìn)行的。事實(shí)上，這些日志和記錄可能會(huì)建立某種與合同有關(guān)的里程碑。它是黑盒測(cè)試的基礎(chǔ)。 ? 沒有回頭路可走。 ? 對(duì)大多數(shù)人來(lái)講， 完全拋棄以前的所有成果從頭開始是一種很愚蠢的做法 。 ? 利用這個(gè)試驗(yàn)性項(xiàng)目，學(xué)習(xí)新技術(shù)、新方法。 ? 好的微度量能夠區(qū)分項(xiàng)目的成功或失敗。 ? 每引入一種新技術(shù)，它 與所有其他技術(shù)之間可能的相互作用的數(shù)量是非線性的 ， 按 N次冪增長(zhǎng) 。 ? 對(duì)工作人員的培訓(xùn)不是買一本書給他就完事大吉。它們可能要在以后的幾年中，在對(duì)系統(tǒng)進(jìn)行修改或升級(jí)時(shí)才會(huì)被發(fā)現(xiàn)。 ? 為提高復(fù)用，應(yīng)當(dāng) 制定一些獎(jiǎng)勵(lì)措施 ，如給對(duì)象開發(fā)人員以高報(bào)酬，給利用復(fù)用的用戶以紅包，給項(xiàng)目負(fù)責(zé)人以特殊獎(jiǎng)勵(lì)等。 ? 面向?qū)ο蠓椒ㄋ鶐?lái)的收益不會(huì)出現(xiàn)在你的第一 個(gè)項(xiàng)目中，也許第二個(gè)項(xiàng)目中也不會(huì)。 ? 充分了解你的財(cái)產(chǎn)，并基于這些財(cái)產(chǎn)建立一個(gè)轉(zhuǎn)變計(jì)劃，這對(duì)于成功地轉(zhuǎn)向非常重要。對(duì)復(fù)用的分析、設(shè)計(jì)、測(cè)試、代碼等所進(jìn)行的度量應(yīng)當(dāng)包含在每一個(gè)項(xiàng)目的最重要的統(tǒng)計(jì)中。因此，建議 必須嚴(yán)格遵守項(xiàng)目的進(jìn)度計(jì)劃 。 ? 培訓(xùn)和個(gè)別輔導(dǎo)可能是管理上的最好投資，它能保證成功地轉(zhuǎn)向面向?qū)ο蠓椒ā? ? 解決的辦法是 分而治之 。 步驟 6：準(zhǔn)備一些花招 ? 每個(gè)軟件開發(fā)項(xiàng)目都有它既定的方針策略。 步驟 5：建立有意義的度量 ? 研究證明，在一個(gè)成功的項(xiàng)目中，預(yù)期完成工作的百分比與實(shí)際完成工作的百分比十分接近。 ? 工作產(chǎn)品 是指作為特定項(xiàng)目的里程碑應(yīng)當(dāng)提交的成果； ? 人工制品 是指在開發(fā)過程中產(chǎn)生的不交付的成果，如數(shù)據(jù)流圖、結(jié)構(gòu)圖等。 ? 復(fù)用能帶來(lái)高的投資回報(bào)率 (48個(gè)月后達(dá) 30:1)。該測(cè)試主要是對(duì)所有的服務(wù)及其組成部分進(jìn)行檢查，以確認(rèn)它們與服務(wù)的規(guī)格說明和屬性定義是一致的。 ? 由于對(duì)象可以在許多不同的應(yīng)用程序中復(fù)用，因此必須在通用的復(fù)用環(huán)境中執(zhí)行。 ? 要求執(zhí)行白盒測(cè)試的人熟悉開發(fā)環(huán)境和設(shè)計(jì)方法，對(duì)應(yīng)用領(lǐng)域的知識(shí)不是必須的。 ?白盒測(cè)試 ? 基于各種設(shè)計(jì)文檔中所定義的內(nèi)部系統(tǒng)結(jié)構(gòu) 。黑盒測(cè)試的目的是要確認(rèn)功能的執(zhí)行與規(guī)格說明相一致。 ? 所有的數(shù)據(jù)庫(kù)接口都通過 RAD對(duì)象實(shí)現(xiàn)。由于它以快速系統(tǒng)展開為基礎(chǔ)，因而 RAD工具的成本是合理的。 ? 一天結(jié)束時(shí)，項(xiàng)目開發(fā)組對(duì)這天實(shí)現(xiàn)的線程進(jìn)行評(píng)審?？梢哉J(rèn)為系統(tǒng)一次在執(zhí)行一個(gè)線程。 ? 對(duì)于一個(gè) 大而復(fù)雜的軟件系統(tǒng) ， 采用迭代的軟件開發(fā)過程非常重要 。 ?對(duì)于面向微處理器的嵌入的、實(shí)時(shí)的程序，只能用普通的匯編語(yǔ)言編寫程序?，F(xiàn)在談復(fù)用時(shí)，是指復(fù)用 事務(wù)規(guī)則 、 需求 、 環(huán)境 、 文件 、體系結(jié)構(gòu) 、 測(cè)試計(jì)劃 等。 ? 為了更好地描述 OOD模型， 可以使用任何類型的圖形表示工具或其他規(guī)格說明 。 ? OOD模型的文檔好比建筑師設(shè)計(jì)出來(lái)的建筑樓房用的藍(lán)圖，應(yīng)具有詳細(xì)的細(xì)節(jié)。這些名字是否與對(duì)象的數(shù)據(jù)和服務(wù)相符？如果不符，為什么不符？ 事例分析系統(tǒng)的質(zhì)量問題 ? 良好的設(shè)計(jì)來(lái)自于良好的分析。 ?重視場(chǎng)景評(píng)價(jià)的能力 ——評(píng)價(jià)一個(gè)設(shè)計(jì)的好壞可以通過執(zhí)行各個(gè)類和對(duì)象的行為來(lái)實(shí)現(xiàn)。 一個(gè)消息需要的參數(shù)不多于 3個(gè) ，否則是對(duì)類的層次結(jié)構(gòu)沒有做很好的分解。 ?層次結(jié)構(gòu)和因子分解準(zhǔn)則 ? 類的層次結(jié)構(gòu)不要太深，也不要太淺。 ? 這些成分之間的 耦合度應(yīng)當(dāng)最小化 ； ? 應(yīng)當(dāng)盡量 減少對(duì)象之間的消息數(shù)目 及 消息本身的復(fù)雜性 ； ? 耦合會(huì)通過 泛化 – 特化 或 整體 – 部分 層次結(jié)構(gòu)產(chǎn)生。 ? 在 ECS中沒有數(shù)據(jù)管理部分 ，所有在對(duì)象中存儲(chǔ)的數(shù)據(jù)都駐留在內(nèi)存中。 零表示當(dāng)前沒有按下按鈕。 中斷 召喚按鈕中斷 目的地按鈕中斷 到達(dá)中斷 電梯就緒中斷 寄存器 輸入寄存器 輸出寄存器 ? 可以用一個(gè)類的集合來(lái)表示以上的中斷和寄存器訪問類。 ? 在應(yīng)用中，每一個(gè)對(duì)象中的每一個(gè)服務(wù)最終都要被分配給某一個(gè)計(jì)算機(jī)任務(wù)。 ? HIC設(shè)計(jì)并不是一個(gè)僅當(dāng) OOA模型完成后才開始的處理。由于所建立的系統(tǒng)面對(duì)的是用戶，因此， 其界面必須必須與用戶的文化背景相一致 。這些對(duì)象封裝了 如何接收按鈕被按下 的機(jī)制，以及 如何激活指示燈 的機(jī)制。 電梯馬達(dá) 超載傳感器 電梯調(diào)度器 電梯控制器 電梯監(jiān)視器 電 梯 目的地面板 面 板 到達(dá)面板 樓 層 目的地事件 召喚面板 召喚事件 到達(dá)事件 電梯事件 1 1 1 1 1 1 1,m 1 1 1 1 1 1 1 1,m 1,m ECS問題領(lǐng)域部分 要點(diǎn) ? 完整的未經(jīng)改動(dòng)的 OOA模型將成為初始的OOD模型的 PDC部分。有的代碼看起來(lái)復(fù)雜，但效率不見得低。 有一些事實(shí)表明，非 OOPL的緊湊 代碼的效率比 OOPL的效率高 , 在多數(shù)情況下，OOPL的效率損失約為 10%。有時(shí)， 必須改變問題領(lǐng)域的結(jié)構(gòu)以提高效率 。這些服務(wù)都是虛函數(shù)。 ? 利用可復(fù)用的設(shè)計(jì)／編程方面的類 ?根據(jù)需要 , 把從類庫(kù)或其他來(lái)源得到的可用的既存類增加到問題解決方案中去。 ? 在 OOA模型和 OOD模型中使用了共同的表示法 。必須在問題領(lǐng)域或或其他部分說明。在建