【正文】 的層次結(jié)構(gòu)。 ?檢查 繼承的層次結(jié)構(gòu) ，確保父類不依賴子類。 ? 利用以上準(zhǔn)則來檢查 ECS的 OOD設(shè)計，看是否有需要改進(jìn)的地方。 ?重視場景評價的能力 ——評價一個設(shè)計的好壞可以通過執(zhí)行各個類和對象的行為來實現(xiàn)。 ? 系統(tǒng)整體規(guī)模的最小化 ——系統(tǒng)規(guī)模越大越不好 。 ? 例如，為改正軟件缺陷，對一個類作一些小改動，或者在軟件中增加一個新的特性，都會在許多其他類中引起一連串的反應(yīng)。使用 Smalltalk語言， 每個服務(wù)的代碼行數(shù)通常不超過 10行。 一個消息需要的參數(shù)不多于 3個 ，否則是對類的層次結(jié)構(gòu)沒有做很好的分解。一個對象可能自己不能響應(yīng)一個外部事件， 但它不能與多于 7 ? 2 個對象交互來完成某件事情 。 ? 除了處理內(nèi)部事務(wù)所用的私有服務(wù)外， 類所具有的公共服務(wù)不應(yīng)多于 6 ~ 7 個 。影響層次的因素有程序設(shè)計語言、 用單繼承還是多繼承等。 ?層次結(jié)構(gòu)和因子分解準(zhǔn)則 ? 類的層次結(jié)構(gòu)不要太深，也不要太淺。 ?重點在于 設(shè)計的明確性 ——看不懂 OOD設(shè)計，就無法復(fù)用它。在面向?qū)ο笤O(shè)計時，從 3個層次來考察內(nèi)聚性： ?單個服務(wù)的內(nèi)聚性； ?封裝在類和對象中的數(shù)據(jù)和服務(wù)的內(nèi)聚性； ?整個類的層次結(jié)構(gòu)的內(nèi)聚性。 ?內(nèi)聚性準(zhǔn)則 ——描述系統(tǒng)組成中各元素的關(guān)聯(lián)度或強度。 ? 這些成分之間的 耦合度應(yīng)當(dāng)最小化 ； ? 應(yīng)當(dāng)盡量 減少對象之間的消息數(shù)目 及 消息本身的復(fù)雜性 ； ? 耦合會通過 泛化 – 特化 或 整體 – 部分 層次結(jié)構(gòu)產(chǎn)生。這個代價必須付出，以獲取 復(fù)用性 、 可維護(hù)性 、 可擴展性 等優(yōu)點。但這不一定是唯一的，也不一定是最好的。之所以將數(shù)據(jù)庫管理技術(shù)從 OOD PDC 中分離出來，是為了將來更換 DBMS時可以只修改 DMC讓系統(tǒng)其他部分可一概不動。 ? 在 ECS中沒有數(shù)據(jù)管理部分 ，所有在對象中存儲的數(shù)據(jù)都駐留在內(nèi)存中。 ? 封裝需要做許多工作，這些開銷是必要的。 ?類“ 召喚按鈕 ”封裝了如何將寄存器值轉(zhuǎn)換為按鈕號碼的機制，它通知相應(yīng)“ 召喚按鈕 ”對象：你被按下了，你要開始工作了。 ?一旦按下召喚按鈕，第一個反應(yīng)是“ 召喚中斷 ”類被喚醒，并報告“我接收到一個召喚”。 零表示當(dāng)前沒有按下按鈕。 ―召喚事件”的執(zhí)行機制 召喚事件 召喚按鈕 PDC HIC 我們有一個召喚！ ? TMC 召喚中斷 輸入 寄存器 按下 按鈕 ?召喚按鈕共 78個（除第 1 層和第 40 層各有 1 個外，其他每層各有 2 個）。 ? 當(dāng) 召喚按鈕被按下時（在 ECS之外），產(chǎn)生了一個中斷，終止正在運行的程序。在設(shè)計中采用輪詢超載傳感器的方式產(chǎn)生超載事件。 中斷 召喚按鈕中斷 目的地按鈕中斷 到達(dá)中斷 電梯就緒中斷 寄存器 輸入寄存器 輸出寄存器 ? 可以用一個類的集合來表示以上的中斷和寄存器訪問類。還要找出任務(wù)協(xié)調(diào)部分，通信的發(fā)、收關(guān)系，處理器的分配（客戶 服務(wù)器）或者消息 /線程序列等。 ? 首先， 要標(biāo)識一些新的類 ，這些類建立后將負(fù)責(zé)處理并發(fā)、中斷 、調(diào)度（在操作系統(tǒng)級）以及其他有關(guān)特定平臺的一些問題 . ? TMC把與特定硬 /軟件平臺有關(guān)的處理機制封裝在自己內(nèi)部 ， 對系統(tǒng)的其他部分隱藏起來 ，一旦決定將 ECS移植到另一個平臺上時，只需替換 TMC中的類就可以了。 ? 在 ECS系統(tǒng)中有大量的系統(tǒng)必須對其響應(yīng)的異步事件 。 ? 在應(yīng)用中，每一個對象中的每一個服務(wù)最終都要被分配給某一個計算機任務(wù)。 ? 用戶可以不需要 HIC，但不能免去用戶界面的設(shè)計。 ? 事實上，使用各種所謂的可視化開發(fā)環(huán)境，如Delphi, PowerBuilder, Vasual Basic等，開發(fā)人員可能連 HIC都不要。在開發(fā)目標(biāo)系統(tǒng)的HIC時，應(yīng)允許用戶對其試用。 ? HIC設(shè)計并不是一個僅當(dāng) OOA模型完成后才開始的處理。 ?使用工具 定義一個高層的用戶界面和一些詳細(xì)的對話框 ，然后 定義 HIC對象 ，從而完成設(shè)計。 ?使用用戶開發(fā)的場景或用況來驅(qū)動界面 。其目的是讓人機界面適應(yīng)用戶。由于所建立的系統(tǒng)面對的是用戶，因此， 其界面必須必須與用戶的文化背景相一致 。 ―召喚事件”的執(zhí)行機制 召喚事件 召喚按鈕 報告 PDC HIC 我們有一個召喚 ！ ? 總結(jié) ? 每一個組織和用戶都有他的文化背景。 ? 實際上，“ 召喚事件 ” 在它接收到從 “ 召喚按鈕 ”發(fā)送來的消息之前，根本就不理會周圍的任何事務(wù)。在 OOA模型中敘述“當(dāng)召喚請求發(fā)生時 ?? ，對象 ‘召喚事件’ 將向?qū)ο蟆賳久姘濉? 報告召喚事件的發(fā)生。這些對象封裝了 如何接收按鈕被按下 的機制，以及 如何激活指示燈 的機制。 ECS的 HIC ? ECS的 HIC由各種電梯按鈕、指示燈及它們的接口組成，不存在屏幕、窗口等用戶界面需要進(jìn)行設(shè)計。 ? HIC部分在系統(tǒng)行為和用戶交互的實現(xiàn)之間架起了一座橋梁。 ? 由于性能、將來的復(fù)用、程序設(shè)計語言的限制、規(guī)范化等原因，可能還需要對 PDC作出一些其他改動。 電梯馬達(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)域部分 要點 ? 完整的未經(jīng)改動的 OOA模型將成為初始的OOD模型的 PDC部分。在提交給實現(xiàn)者的規(guī)格說明中，將這個類放在一個 與 ECS的主處理器分離的處理器上 . ? 每個類增加服務(wù) Self Test來增強每個類的性能。 ECS的 PDC ? 決定使用一個中央控制器（電梯控制器）控制和協(xié)調(diào)電梯的所有動作，包括解決電梯每到一個樓層減速問題。 ? 提高性能最好的方法是采用最出色的解決方案，而不是拼命地去節(jié)省幾個微秒、幾個字節(jié)。有的代碼看起來復(fù)雜，但效率不見得低。 ? 預(yù)測軟件開銷集中在什么地 方是困難的 , 進(jìn)行優(yōu)化最有效的方法是在系統(tǒng)運行時使用性能監(jiān)測工具對系統(tǒng)進(jìn)行觀測。 ? 通常系統(tǒng) 80%的開銷都集中在 20%的代碼段上。 ? 提高一個現(xiàn)存系統(tǒng)的工作效率比重新設(shè)計一個高效的系統(tǒng)要容易。 有一些事實表明，非 OOPL的緊湊 代碼的效率比 OOPL的效率高 , 在多數(shù)情況下，OOPL的效率損失約為 10%。 ? 當(dāng)軟件運行在一個 CPU速度很快的計算機上，并是單機的人機交互時，大多數(shù)的時鐘周期都用在了等待用戶輸入上。但 要作出平衡 ， 要使PDC與原來的 OOA模型盡可能相近 而減少測試開銷和維護(hù)開銷。 ?增加某些屬性到原來的類中，或增加低層的類，以保存暫時結(jié)果，避免每次都要重復(fù)計算造成速度損失。有時， 必須改變問題領(lǐng)域的結(jié)構(gòu)以提高效率 。 ?針對無繼承語言的調(diào)整 ? 當(dāng)使用無繼承的程序設(shè)計語言時，必須把具有繼承關(guān)系的類層次結(jié)構(gòu)平鋪開來，成為一組類和對象。 ? 把多繼承的層次結(jié)構(gòu)平鋪，成為單繼承的層次結(jié)構(gòu)。 ? 對繼承進(jìn)行調(diào)整 ?在 OOA模型中可能包括有多繼承關(guān)系 , 但實現(xiàn)時使用的程序設(shè)計語言可能只有單繼承，甚至沒有繼承機制，這樣就需變更 PDC中類的層次結(jié)構(gòu) 。這些服務(wù)都是虛函數(shù)。此時，以這些 OOA類為子類，定義一個父類。 ?修改 OOA類的結(jié)構(gòu)和連接。 ?增加從既存類到 OOA類之間的泛化 特化關(guān)系，盡可能繼承既存類的屬性和方法。 ? 利用可復(fù)用的設(shè)計／編程方面的類 ?根據(jù)需要 , 把從類庫或其他來源得到的可用的既存類增加到問題解決方案中去。 ? 與 OOA模型一樣， OOD中各部分的構(gòu)造是不斷循環(huán)反復(fù)的 , 而不是一個個相繼順序構(gòu)造的。這種策略能夠幫助提高產(chǎn)品的可復(fù)用性。 ? 與 OOA模型一樣， OOD 模型也有 5 層結(jié)構(gòu)，又被劃分成了 4 個組成部分。 ? 在 OOA模型和 OOD模型中使用了共同的表示法 。 ? OOD模型類似于構(gòu)造藍(lán)圖 。 要點 ? 從 OOA轉(zhuǎn)到 OOD需要 在 OOA模型的基礎(chǔ)上加入實現(xiàn)方面的限制 。 ? 數(shù)據(jù)庫管理 ：系統(tǒng)將管理什么類型的數(shù)據(jù)？ ? 可復(fù)用性 ：可以考慮購買一個商品類庫來實現(xiàn)OOA的對象。必須在問題領(lǐng)域或或其他部分說明。也可以增加用于監(jiān)控傳感器的對象?？赡苄枰黾印皽囟扔嫛睂ο螅{(diào)整傳感器讀數(shù)的安全性。 ? 性能限制 ：如電梯每到一個樓層時都要減速，乘客就不得不忍受失重狀態(tài)，需要考慮調(diào)度算法，讓 ECS來預(yù)測什么時候電梯應(yīng)停在某一