【正文】 試 。 ? 老的設(shè)計(jì)方法 , 如結(jié)構(gòu)化設(shè)計(jì)方法，有它自己的一套完善的設(shè)計(jì)準(zhǔn)則。 ? 用 圖形表示 表達(dá)設(shè)計(jì)。 ? 在面向?qū)ο箝_發(fā)模式中， 分析和設(shè)計(jì)之間的界限是模糊的 。 ? 評(píng)審者可以利用這些手段，監(jiān)控、改變、標(biāo)記 OOA模型的動(dòng)態(tài)行為。 ? 在實(shí)際的項(xiàng)目評(píng)審中，可以采用兩個(gè)顯示器：一個(gè)顯示器用來 顯示 OOA模型 ，另一個(gè)顯示器用來 顯示 EROI圖表 。 ? 對(duì)語義正確性的評(píng)審采用的策略類似于在開發(fā)面向用戶的文檔時(shí)采用的策略， 將模型的行為對(duì)照用戶描述的場(chǎng)景或用戶事例 ， 一一加以確認(rèn) 。 ? 可 將檢查表嵌入到每個(gè) 屬性 、 服務(wù) 、對(duì)象中去，跟蹤定義 使用情況 。 ? 評(píng)審過程 應(yīng)是 非正式的 ， 持續(xù)的 ，貫 穿在項(xiàng)目的整個(gè)生存期中 的 過程 。? 評(píng)審和修正分析模型 ? 過渡到設(shè)計(jì) ? 問題領(lǐng)域中的問題 ? 定義用戶界面 ? 任務(wù)管理問題 ? 數(shù)據(jù)庫設(shè)計(jì) ? 設(shè)計(jì)級(jí)的質(zhì)量問題 ? 設(shè)計(jì)模型的文檔編制和評(píng)審 ? 實(shí)現(xiàn)方面的問題 ? 轉(zhuǎn)向面向?qū)ο蠓椒ǖ氖€(gè)步驟 ? 評(píng)審 OOA模型的目的是為了保證在實(shí)現(xiàn)系統(tǒng)之前，能夠正確理解和解釋用戶的需求 。就是說首先把 OOA模型充分地文檔化，分發(fā)給各評(píng)審者，然后召集評(píng)審會(huì)，共同評(píng)審。 ? 好處： 評(píng)審過程已成為開發(fā)過程的一部分。 ? 需要有關(guān)人員共同討論，不一定舉行正式的評(píng)審會(huì)議。 ? 對(duì)于這樣的正式評(píng)審，需要一個(gè)“驅(qū)動(dòng)者”，一個(gè)“記錄者”。 ? 在實(shí)際項(xiàng)目中，應(yīng)把以上建議轉(zhuǎn)換為方針和過程。 ? 通常， 分析 涉及 系統(tǒng)做什么 ， 設(shè)計(jì) 則涉及 需求如何實(shí)現(xiàn) 。 ? OOD的表示法應(yīng)盡可能地接近 OOA表示法 。其中最著名、最重要的概念是模塊的耦合、內(nèi)聚性。 ? 編程語言對(duì)設(shè)計(jì)過程及設(shè)計(jì)者的設(shè)計(jì)思想都將產(chǎn)生巨大的影響。將 OOD 體系結(jié)構(gòu)分為三個(gè)主要成分： ? 模型 (Model) : 為底層應(yīng)用建立模型的類和對(duì)象； ? 視圖 (View) : 為用戶提供與模型有關(guān)的類接口視圖的類和對(duì)象； ? 控制器 (Controller) : 用于控制（或同步）其他類的行為的類和對(duì)象。 ? 由于 OOA和 OOD采用相同的基本圖形表示法，更容易體現(xiàn) OOA與 OOD工作的連續(xù)性和無縫隙性 。 ? 問題是：改變用戶接口和數(shù)據(jù)庫容易破壞體系結(jié)構(gòu)，使得類和對(duì)象的內(nèi)部結(jié)構(gòu)更為復(fù)雜。 ? 性能限制 ：如電梯每到一個(gè)樓層時(shí)都要減速，乘客就不得不忍受失重狀態(tài)，需要考慮調(diào)度算法，讓 ECS來預(yù)測(cè)什么時(shí)候電梯應(yīng)停在某一樓層。也可以增加用于監(jiān)控傳感器的對(duì)象。 ? 數(shù)據(jù)庫管理 ：系統(tǒng)將管理什么類型的數(shù)據(jù)？ ? 可復(fù)用性 ：可以考慮購買一個(gè)商品類庫來實(shí)現(xiàn)OOA的對(duì)象。 ? OOD模型類似于構(gòu)造藍(lán)圖 。 ? 與 OOA模型一樣， OOD 模型也有 5 層結(jié)構(gòu)，又被劃分成了 4 個(gè)組成部分。 ? 與 OOA模型一樣， OOD中各部分的構(gòu)造是不斷循環(huán)反復(fù)的 , 而不是一個(gè)個(gè)相繼順序構(gòu)造的。 ?增加從既存類到 OOA類之間的泛化 特化關(guān)系，盡可能繼承既存類的屬性和方法。此時(shí)，以這些 OOA類為子類，定義一個(gè)父類。 ? 對(duì)繼承進(jìn)行調(diào)整 ?在 OOA模型中可能包括有多繼承關(guān)系 , 但實(shí)現(xiàn)時(shí)使用的程序設(shè)計(jì)語言可能只有單繼承，甚至沒有繼承機(jī)制，這樣就需變更 PDC中類的層次結(jié)構(gòu) 。 ?針對(duì)無繼承語言的調(diào)整 ? 當(dāng)使用無繼承的程序設(shè)計(jì)語言時(shí)，必須把具有繼承關(guān)系的類層次結(jié)構(gòu)平鋪開來，成為一組類和對(duì)象。 ?增加某些屬性到原來的類中，或增加低層的類，以保存暫時(shí)結(jié)果，避免每次都要重復(fù)計(jì)算造成速度損失。 ? 當(dāng)軟件運(yùn)行在一個(gè) CPU速度很快的計(jì)算機(jī)上，并是單機(jī)的人機(jī)交互時(shí)，大多數(shù)的時(shí)鐘周期都用在了等待用戶輸入上。 ? 提高一個(gè)現(xiàn)存系統(tǒng)的工作效率比重新設(shè)計(jì)一個(gè)高效的系統(tǒng)要容易。 ? 預(yù)測(cè)軟件開銷集中在什么地 方是困難的 , 進(jìn)行優(yōu)化最有效的方法是在系統(tǒng)運(yùn)行時(shí)使用性能監(jiān)測(cè)工具對(duì)系統(tǒng)進(jìn)行觀測(cè)。 ? 提高性能最好的方法是采用最出色的解決方案，而不是拼命地去節(jié)省幾個(gè)微秒、幾個(gè)字節(jié)。在提交給實(shí)現(xiàn)者的規(guī)格說明中，將這個(gè)類放在一個(gè) 與 ECS的主處理器分離的處理器上 . ? 每個(gè)類增加服務(wù) Self Test來增強(qiáng)每個(gè)類的性能。 ? 由于性能、將來的復(fù)用、程序設(shè)計(jì)語言的限制、規(guī)范化等原因，可能還需要對(duì) PDC作出一些其他改動(dòng)。 ECS的 HIC ? ECS的 HIC由各種電梯按鈕、指示燈及它們的接口組成，不存在屏幕、窗口等用戶界面需要進(jìn)行設(shè)計(jì)。在 OOA模型中敘述“當(dāng)召喚請(qǐng)求發(fā)生時(shí) ?? ，對(duì)象 ‘召喚事件’ 將向?qū)ο蟆賳久姘濉? 報(bào)告召喚事件的發(fā)生。 ―召喚事件”的執(zhí)行機(jī)制 召喚事件 召喚按鈕 報(bào)告 PDC HIC 我們有一個(gè)召喚 ！ ? 總結(jié) ? 每一個(gè)組織和用戶都有他的文化背景。其目的是讓人機(jī)界面適應(yīng)用戶。 ?使用工具 定義一個(gè)高層的用戶界面和一些詳細(xì)的對(duì)話框 ，然后 定義 HIC對(duì)象 ，從而完成設(shè)計(jì)。在開發(fā)目標(biāo)系統(tǒng)的HIC時(shí)，應(yīng)允許用戶對(duì)其試用。 ? 用戶可以不需要 HIC，但不能免去用戶界面的設(shè)計(jì)。 ? 在 ECS系統(tǒng)中有大量的系統(tǒng)必須對(duì)其響應(yīng)的異步事件 。還要找出任務(wù)協(xié)調(diào)部分，通信的發(fā)、收關(guān)系，處理器的分配（客戶 服務(wù)器）或者消息 /線程序列等。在設(shè)計(jì)中采用輪詢超載傳感器的方式產(chǎn)生超載事件。 ―召喚事件”的執(zhí)行機(jī)制 召喚事件 召喚按鈕 PDC HIC 我們有一個(gè)召喚！ ? TMC 召喚中斷 輸入 寄存器 按下 按鈕 ?召喚按鈕共 78個(gè)（除第 1 層和第 40 層各有 1 個(gè)外，其他每層各有 2 個(gè)）。 ?一旦按下召喚按鈕，第一個(gè)反應(yīng)是“ 召喚中斷 ”類被喚醒，并報(bào)告“我接收到一個(gè)召喚”。 ? 封裝需要做許多工作，這些開銷是必要的。之所以將數(shù)據(jù)庫管理技術(shù)從 OOD PDC 中分離出來，是為了將來更換 DBMS時(shí)可以只修改 DMC讓系統(tǒng)其他部分可一概不動(dòng)。這個(gè)代價(jià)必須付出，以獲取 復(fù)用性 、 可維護(hù)性 、 可擴(kuò)展性 等優(yōu)點(diǎn)。 ?內(nèi)聚性準(zhǔn)則 ——描述系統(tǒng)組成中各元素的關(guān)聯(lián)度或強(qiáng)度。 ?重點(diǎn)在于 設(shè)計(jì)的明確性 ——看不懂 OOD設(shè)計(jì)，就無法復(fù)用它。影響層次的因素有程序設(shè)計(jì)語言、 用單繼承還是多繼承等。一個(gè)對(duì)象可能自己不能響應(yīng)一個(gè)外部事件， 但它不能與多于 7 ? 2 個(gè)對(duì)象交互來完成某件事情 。使用 Smalltalk語言， 每個(gè)服務(wù)的代碼行數(shù)通常不超過 10行。 ? 系統(tǒng)整體規(guī)模的最小化 ——系統(tǒng)規(guī)模越大越不好 。 ? 利用以上準(zhǔn)則來檢查 ECS的 OOD設(shè)計(jì)，看是否有需要改進(jìn)的地方。 ? 通過檢查，了解當(dāng)前的層次結(jié)構(gòu)的狀況，發(fā)掘出更好的層次結(jié)構(gòu)。從產(chǎn)生的 OOA/OOD 模型來看，幾乎所有的對(duì)象都是高內(nèi)聚、低耦合的。為提高效率和調(diào)度，降低了許多類的可復(fù)用性。 ? 各個(gè)項(xiàng)目要求的詳細(xì)程度各不相同 。 ? 如果設(shè)計(jì)人員在某一個(gè)大陸上，而實(shí)現(xiàn)人員在另一個(gè)大陸上，就需要大量細(xì)節(jié)的說明。 ? 我們希望將所開發(fā)的用戶界面屏幕放到設(shè)計(jì)文檔中。為了識(shí)別事件并產(chǎn)生相應(yīng)的響應(yīng)，必須給出所有的設(shè)計(jì)。面向?qū)ο笫且环N先進(jìn)的技術(shù)，它使得可以復(fù)用的東西遠(yuǎn)遠(yuǎn)超過了代碼。 ?每個(gè)項(xiàng)目都有自己獨(dú)特的應(yīng)用環(huán)境。其結(jié)果就是自頂向下，從功能上分解對(duì)象。但總的說來， 開發(fā)過程獨(dú)立于開發(fā)環(huán)境或開發(fā)過程 。 ? 圖中的各種活動(dòng)并不是以瀑布流水的方式組織起來的。 預(yù)分析 活動(dòng) 各種需 求定義 , 建模 OOA OOD GUI OOP Deploy ment 預(yù)分析工作產(chǎn)品 (OOA工作表格 , E/R,初始 GUI布局 ) 初始 GUI布局 (包 括各種功能定義 , 數(shù)據(jù)定義等。 ? 下圖描述了項(xiàng)目開發(fā)組在某一天根據(jù)迭代的開 發(fā)過程進(jìn)行的活動(dòng)。 初始線程 標(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ū)ο蠼?。有些線程可以接受，有些現(xiàn)成需要重做。 ? 原因在于 RAD工具通常 不支持事物分離規(guī)則 。需要有項(xiàng)目標(biāo)準(zhǔn)和開發(fā)人員守則。 ? 所有人機(jī)交互部分中的對(duì)象應(yīng)作為 RAD的屏幕和表格實(shí)現(xiàn)。 ? RAD對(duì)象之間的消息傳遞都通過函數(shù)或子程序調(diào)用來完成。 ? 黑盒測(cè)試 ? 這種測(cè)試基于系統(tǒng)級(jí)的規(guī)格說明。從用戶角度捕捉系統(tǒng)行為。在普通開發(fā)環(huán)境中利用發(fā)布前的各種結(jié)果就可以做。 ? 在 EROI圖中定義的類所