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