【文章內(nèi)容簡介】 指示燈 人機(jī)交互部分 到達(dá)指示燈 目的地指示燈 上行召喚指示燈 ? 例如，考慮召喚請(qǐng)求如何發(fā)生。在 OOA模型中敘述“當(dāng)召喚請(qǐng)求發(fā)生時(shí) ?? ，對(duì)象 ‘召喚事件’ 將向?qū)ο蟆賳久姘濉? 報(bào)告召喚事件的發(fā)生?！? 等等。 ? 實(shí)際上，“ 召喚事件 ” 在它接收到從 “ 召喚按鈕 ”發(fā)送來的消息之前，根本就不理會(huì)周圍的任何事務(wù)。 ? 這個(gè)從 “ 召喚按鈕 ” 發(fā)送來的消息是向類 “ 召喚事件 ”報(bào)告有一個(gè)召喚事件發(fā)生了。 ―召喚事件”的執(zhí)行機(jī)制 召喚事件 召喚按鈕 報(bào)告 PDC HIC 我們有一個(gè)召喚 ！ ? 總結(jié) ? 每一個(gè)組織和用戶都有他的文化背景?？赡懿粌H僅意味著語言、傳統(tǒng)和習(xí)慣。由于所建立的系統(tǒng)面對(duì)的是用戶，因此， 其界面必須必須與用戶的文化背景相一致 。 ?一種適應(yīng)用戶文化背景的有效方法是“ 直觀表示 ”。其目的是讓人機(jī)界面適應(yīng)用戶。常用的直觀表示是 預(yù)置一些用戶常用的標(biāo)準(zhǔn)形式 ，學(xué)習(xí)和掌握它非常簡單和容易。 ?使用用戶開發(fā)的場景或用況來驅(qū)動(dòng)界面 。在執(zhí)行一個(gè)特定的工作時(shí)，用戶界面應(yīng)能告訴用戶下面將做什么。 ?使用工具 定義一個(gè)高層的用戶界面和一些詳細(xì)的對(duì)話框 ，然后 定義 HIC對(duì)象 ，從而完成設(shè)計(jì)。建立原型時(shí)必須對(duì)所有 HIC設(shè)計(jì)進(jìn)行嚴(yán)格的檢驗(yàn)。 ? HIC設(shè)計(jì)并不是一個(gè)僅當(dāng) OOA模型完成后才開始的處理。事實(shí)上， 在建立 OOA模型的同時(shí)就開始著手 HIC的設(shè)計(jì)了 。在開發(fā)目標(biāo)系統(tǒng)的HIC時(shí)，應(yīng)允許用戶對(duì)其試用。 ? 多數(shù)用戶都不會(huì)從頭開始設(shè)計(jì) HIC類 。 ? 事實(shí)上，使用各種所謂的可視化開發(fā)環(huán)境，如Delphi, PowerBuilder, Vasual Basic等，開發(fā)人員可能連 HIC都不要。直接使用這些工具提供的控件，就可以作出用戶界面。 ? 用戶可以不需要 HIC，但不能免去用戶界面的設(shè)計(jì)。 使用菜單樹或狀態(tài) 遷移圖，連同某些原型，來說明用戶界面的設(shè)計(jì)思想。 ? 在應(yīng)用中，每一個(gè)對(duì)象中的每一個(gè)服務(wù)最終都要被分配給某一個(gè)計(jì)算機(jī)任務(wù)。這樣一些任務(wù)可以被看作是一些獨(dú)立的可調(diào)度的實(shí)體。 ? 在 ECS系統(tǒng)中有大量的系統(tǒng)必須對(duì)其響應(yīng)的異步事件 。下面將介紹 ECS OOD模型的任務(wù)管理部分（ TMC）。 ? 首先， 要標(biāo)識(shí)一些新的類 ，這些類建立后將負(fù)責(zé)處理并發(fā)、中斷 、調(diào)度（在操作系統(tǒng)級(jí)）以及其他有關(guān)特定平臺(tái)的一些問題 . ? TMC把與特定硬 /軟件平臺(tái)有關(guān)的處理機(jī)制封裝在自己內(nèi)部 ， 對(duì)系統(tǒng)的其他部分隱藏起來 ，一旦決定將 ECS移植到另一個(gè)平臺(tái)上時(shí)，只需替換 TMC中的類就可以了。 ? 為建立 TMC，首先要找出可能被封裝在 TMC類中那些與特定平臺(tái)有關(guān)的部分。還要找出任務(wù)協(xié)調(diào)部分，通信的發(fā)、收關(guān)系，處理器的分配（客戶 服務(wù)器）或者消息 /線程序列等。 ECS的類與對(duì)象 ? 考察 ECS OOA/OOD工作表格 , 可以發(fā)現(xiàn) 中斷處理 和 寄存器訪問 是設(shè)計(jì)需求的重要部分。 中斷 召喚按鈕中斷 目的地按鈕中斷 到達(dá)中斷 電梯就緒中斷 寄存器 輸入寄存器 輸出寄存器 ? 可以用一個(gè)類的集合來表示以上的中斷和寄存器訪問類。 ? 與事件 – 響應(yīng)模型中其他事件不同，超載事件沒有相應(yīng)的中斷，故沒有“ 超載中斷 ”類。在設(shè)計(jì)中采用輪詢超載傳感器的方式產(chǎn)生超載事件。 ? 下面完整地說明一下召喚事件的機(jī)制。 ? 當(dāng) 召喚按鈕被按下時(shí)（在 ECS之外），產(chǎn)生了一個(gè)中斷，終止正在運(yùn)行的程序。同時(shí)一 個(gè)二進(jìn)制數(shù)存儲(chǔ)到輸入寄存器中。 ―召喚事件”的執(zhí)行機(jī)制 召喚事件 召喚按鈕 PDC HIC 我們有一個(gè)召喚！ ? TMC 召喚中斷 輸入 寄存器 按下 按鈕 ?召喚按鈕共 78個(gè)（除第 1 層和第 40 層各有 1 個(gè)外，其他每層各有 2 個(gè)）。 向下的召喚按鈕編號(hào)為奇數(shù)，向上的召喚按鈕編號(hào)為偶數(shù)。 零表示當(dāng)前沒有按下按鈕。因此，存入輸入寄存器中的二進(jìn)制數(shù)的范圍是 00000000, 0000001001001111。 ?一旦按下召喚按鈕，第一個(gè)反應(yīng)是“ 召喚中斷 ”類被喚醒，并報(bào)告“我接收到一個(gè)召喚”。 ?相應(yīng)的“ 召喚中斷 ”對(duì)象就 向“ 輸入寄存器 ”對(duì)象發(fā)送一個(gè)消息 , 詢問輸入寄存器的 當(dāng)前值 . ?中斷優(yōu)先級(jí)規(guī)定這個(gè)值只能由“召喚中斷”對(duì)象獲取 . ?這個(gè)“ 召喚中斷 ”對(duì)象 向類“ 召喚按鈕 ”發(fā)送一個(gè)消息，告訴它：你的一個(gè)按鈕按下了。 ?類“ 召喚按鈕 ”封裝了如何將寄存器值轉(zhuǎn)換為按鈕號(hào)碼的機(jī)制，它通知相應(yīng)“ 召喚按鈕 ”對(duì)象：你被按下了，你要開始工作了。 ?“ 召喚按鈕 ”對(duì)象向類“ 召喚事件 ”發(fā)送一個(gè)消息，然后開始進(jìn)行事件的處理。 ? 封裝需要做許多工作，這些開銷是必要的。如決定增加第三個(gè)按鈕用于召喚運(yùn)貨電梯，只需改動(dòng)一個(gè)類“ 召喚按鈕 ”即可，而系統(tǒng)其他部分可一概不予改動(dòng)。 ? 在 ECS中沒有數(shù)據(jù)管理部分 ，所有在對(duì)象中存儲(chǔ)的數(shù)據(jù)都駐留在內(nèi)存中。 ? DMC說明了對(duì)系統(tǒng)生成的永久數(shù)據(jù)的訪問和管理 ，這些數(shù)據(jù)將可以在設(shè)計(jì)的其他部分中使用。之所以將數(shù)據(jù)庫管理技術(shù)從 OOD PDC 中分離出來，是為了將來更換 DBMS時(shí)可以只修改 DMC讓系統(tǒng)其他部分可一概不動(dòng)。 ? 創(chuàng)建 DMC的最簡單的策略就是請(qǐng)求。但這不一定是唯一的，也不一定是最好的。 ? 標(biāo)準(zhǔn) ? 可復(fù)用性 ? 可理解性 ? 可以用一個(gè)簡單的場景說明在一個(gè)基于對(duì)象的系統(tǒng)中可能需要大量的通信和協(xié)調(diào)工作。這個(gè)代價(jià)必須付出，以獲取 復(fù)用性 、 可維護(hù)性 、 可擴(kuò)展性 等優(yōu)點(diǎn)。 ? 評(píng)價(jià)面向?qū)ο笤O(shè)計(jì)的準(zhǔn)則 : ?耦合性準(zhǔn)則 ——指系統(tǒng)各個(gè)具體成份之間相互連接或相互依賴的強(qiáng)度。 ? 這些成分之間的 耦合度應(yīng)當(dāng)最小化 ； ? 應(yīng)當(dāng)盡量 減少對(duì)象之間的消息數(shù)目 及 消息本身的復(fù)雜性 ； ? 耦合會(huì)通過 泛化 – 特化 或 整體 – 部分 層次結(jié)構(gòu)產(chǎn)生。這要通過內(nèi)聚性準(zhǔn)則來衡量。 ?內(nèi)聚性準(zhǔn)則 ——描述系統(tǒng)組成中各元素的關(guān)聯(lián)度或強(qiáng)度。 應(yīng)盡量避免內(nèi)聚性低 。在面向?qū)ο笤O(shè)計(jì)時(shí)，從 3個(gè)層次來考察內(nèi)聚性： ?單個(gè)服務(wù)的內(nèi)聚性； ?封裝在類和對(duì)象中的數(shù)據(jù)和服務(wù)的內(nèi)聚性； ?整個(gè)類的層次結(jié)構(gòu)的內(nèi)聚性。 ? 從微觀的層次上，對(duì)服務(wù)的內(nèi)聚性評(píng)價(jià) 與結(jié)構(gòu)化設(shè)計(jì)中的相同 ： 一個(gè)服務(wù)應(yīng)只執(zhí)行一個(gè)功能 ； ? 在類層次結(jié)構(gòu)這一級(jí)上，可以通過檢查 子類重載 或刪除 從它們的父類中繼承的屬性和服務(wù)的多少 來進(jìn)行評(píng)價(jià)。 ?重點(diǎn)在于 設(shè)計(jì)的明確性 ——看不懂 OOD設(shè)計(jì)，就無法復(fù)用它。建議： ? 命名屬性和服務(wù)的詞要求前后一致； ? 避免使用過多的消息模板； ? 不要對(duì)類的定義摸棱兩可，遵從類的現(xiàn)有協(xié)議或行為。 ?層次結(jié)構(gòu)和因子分解準(zhǔn)則 ? 類的層次結(jié)構(gòu)不要太深，也不要太淺。 ? 一個(gè)約有 100個(gè)類的中等規(guī)模的系統(tǒng)中，泛化 – 特化結(jié)構(gòu)和整體 – 部分結(jié)構(gòu)的層次大概有 7 ? 2 層。影響層次的因素有程序設(shè)計(jì)語言、 用單繼承還是多繼承等。 ?保持 類和對(duì)象的簡單性 ? 平均起來， 每個(gè)服務(wù)所使用的屬性不應(yīng)超過 1 ~ 2 個(gè) ，而且有 2／ 3 應(yīng)當(dāng)能夠追溯到 OOA模型。 ? 除了處理內(nèi)部事務(wù)所用的私有服務(wù)外， 類所具有的公共服務(wù)不應(yīng)多于 6 ~ 7 個(gè) 。 ? 對(duì)象之間的耦合不能過多 。一個(gè)對(duì)象可能自己不能響應(yīng)一個(gè)外部事件， 但它不能與多于 7 ? 2 個(gè)對(duì)象交互來完成某件事情 。 ? 保持 消息協(xié)議的簡單性 ——復(fù)雜的消息協(xié)議常常意味著在類或?qū)ο笾g有很強(qiáng)的耦合。 一個(gè)消息需要的參數(shù)不多于 3個(gè) ，否則是對(duì)類的層次結(jié)構(gòu)沒有做很好的分解。 ? 保持 服務(wù)的簡單性 —— 使用某種高級(jí)語言編寫程序代碼， 盡可能把為每個(gè)服務(wù)所編寫的代碼限制在一頁紙之內(nèi) 。使用 Smalltalk語言， 每個(gè)服務(wù)的代碼行數(shù)通常不超過 10行。 ?將設(shè)計(jì)的易變性降到最低 ——一個(gè)差的設(shè)計(jì) 會(huì)在項(xiàng)目的開發(fā)過程中或在日后的維護(hù)工作中 顯示出一定的易變性 。 ? 例如，為改正軟件缺陷，對(duì)一個(gè)類作一些小改動(dòng)，或者在軟件中增加一個(gè)新的特性，都會(huì)在許多其他類中引起一連串的反應(yīng)。 ? 利用配置管理，可以對(duì)類的變更及變更時(shí)的影響進(jìn)行跟蹤和分析，檢測項(xiàng)目穩(wěn)定性。 ? 系統(tǒng)整體規(guī)模的最小化 ——系統(tǒng)規(guī)模越大越不好 。中型應(yīng)用的類層次不應(yīng)超過幾十個(gè)，每個(gè)類所包含的子類只應(yīng)有十幾個(gè)左右。 ?重視場景評(píng)價(jià)的能力 ——評(píng)價(jià)一個(gè)設(shè)計(jì)的好壞可以通過執(zhí)行各個(gè)類和對(duì)象的行為來實(shí)現(xiàn)。如果無法做行為的測試，說明各個(gè)類的職責(zé)沒有描述清楚，或沒有考慮清楚。 ? 利用以上準(zhǔn)則來檢查 ECS的 OOD設(shè)計(jì)，看是否有需要改進(jìn)的地方。例如 ?觀