【正文】 ？如果分析模型中存在多繼承，而編程語言只能支持單繼承，應(yīng)如何調(diào)整？ ?初始化活動(dòng)和結(jié)束活動(dòng) ：執(zhí)行初始化活動(dòng)和結(jié)束活動(dòng)的過程是必不可少的。盡可能保證設(shè)計(jì)出來的對象在將來的系統(tǒng)中也能用。 OOD模型以最完整的形式全面地定義了如何用特定的實(shí)現(xiàn)技術(shù)建立起一個(gè)目標(biāo)系統(tǒng)。 ? 問題解決部分 (Problem Domain Component) ? 人機(jī)界面部分 (Human Interface Component) ? 任務(wù)管理部分 (Task Management Component) ? 數(shù)據(jù)管理部分 (Data Management Component) ? 這些組成部分把實(shí)現(xiàn)技術(shù)隱藏起來 ， 使之與系統(tǒng)的基本問題領(lǐng)域行為分離開來 。 ? 首先復(fù)制 OOA模型為 OOD模型的問題領(lǐng)域部分，然后對這個(gè)部分進(jìn)行修改。 ?把 OOA類中因繼承既存類而成為多余的屬性和操作標(biāo)出。 ?該父類定義為所有這些子類共用的一組服務(wù)名，作為公共的協(xié)議，用來與 DMC或其他外部系統(tǒng)部件通信。 ?針對單繼承語言的調(diào)整 ? 把子類對象看做是一個(gè)父類對象所扮演的角色，通過實(shí)例連接把多繼承的層次結(jié)構(gòu)轉(zhuǎn)換為單繼承的層次結(jié)構(gòu)。 人 醫(yī)生 教授 醫(yī)學(xué)教授 人 角色 醫(yī)生角色 教授角色 多繼承 通過實(shí)例連接 分解多繼承 醫(yī)生 醫(yī)學(xué)教授 教授 人 平鋪為繼承 ? 修改設(shè)計(jì)以提高性能 ?提高執(zhí)行效率和速度是系統(tǒng)設(shè)計(jì)的主要指標(biāo)之一。 ?軟件的效率性能很重要。 ? 不要認(rèn)為象 C++之類的 OOPL就一定效率不高。 如果對設(shè)計(jì)有性能要求，只需加入少量的工作就可以了。一些像繼承、動(dòng)態(tài)綁定、消息傳遞等處理雖然看起來簡單，但需要大量的系統(tǒng)開銷 。 這個(gè)結(jié)論在面向?qū)ο蠹夹g(shù)出現(xiàn)是這樣，在面向?qū)ο箢I(lǐng)域仍然是這樣。在運(yùn)行時(shí)執(zhí)行有必要驗(yàn)證其功能的操作，并向電梯監(jiān)視器報(bào)告。 ? 設(shè)計(jì)一個(gè)良好的用戶界面是成功地實(shí)現(xiàn)一 個(gè)軟件系統(tǒng)的關(guān)鍵 . ? 在開發(fā) OOA模型時(shí)，有意避開了如窗口、屏幕等依賴于實(shí)現(xiàn)的細(xì)節(jié)，目的是 讓系統(tǒng)規(guī)格說明獨(dú)立于實(shí)現(xiàn) 。 上行召喚按鈕 下行召喚按鈕 召喚按鈕 目的地按鈕 按 鈕 人機(jī)交互部分 ? ECS的 HIC由各種按鈕和指示燈對象組成?！? 等等?？赡懿粌H僅意味著語言、傳統(tǒng)和習(xí)慣。常用的直觀表示是 預(yù)置一些用戶常用的標(biāo)準(zhǔn)形式 ，學(xué)習(xí)和掌握它非常簡單和容易。建立原型時(shí)必須對所有 HIC設(shè)計(jì)進(jìn)行嚴(yán)格的檢驗(yàn)。 ? 多數(shù)用戶都不會(huì)從頭開始設(shè)計(jì) HIC類 。 使用菜單樹或狀態(tài) 遷移圖，連同某些原型，來說明用戶界面的設(shè)計(jì)思想。下面將介紹 ECS OOD模型的任務(wù)管理部分（ TMC）。 ECS的類與對象 ? 考察 ECS OOA/OOD工作表格 , 可以發(fā)現(xiàn) 中斷處理 和 寄存器訪問 是設(shè)計(jì)需求的重要部分。 ? 下面完整地說明一下召喚事件的機(jī)制。 向下的召喚按鈕編號(hào)為奇數(shù)，向上的召喚按鈕編號(hào)為偶數(shù)。 ?相應(yīng)的“ 召喚中斷 ”對象就 向“ 輸入寄存器 ”對象發(fā)送一個(gè)消息 , 詢問輸入寄存器的 當(dāng)前值 . ?中斷優(yōu)先級規(guī)定這個(gè)值只能由“召喚中斷”對象獲取 . ?這個(gè)“ 召喚中斷 ”對象 向類“ 召喚按鈕 ”發(fā)送一個(gè)消息，告訴它：你的一個(gè)按鈕按下了。如決定增加第三個(gè)按鈕用于召喚運(yùn)貨電梯，只需改動(dòng)一個(gè)類“ 召喚按鈕 ”即可，而系統(tǒng)其他部分可一概不予改動(dòng)。 ? 創(chuàng)建 DMC的最簡單的策略就是請求。 ? 評價(jià)面向?qū)ο笤O(shè)計(jì)的準(zhǔn)則 : ?耦合性準(zhǔn)則 ——指系統(tǒng)各個(gè)具體成份之間相互連接或相互依賴的強(qiáng)度。 應(yīng)盡量避免內(nèi)聚性低 。建議： ? 命名屬性和服務(wù)的詞要求前后一致； ? 避免使用過多的消息模板； ? 不要對類的定義摸棱兩可，遵從類的現(xiàn)有協(xié)議或行為。 ?保持 類和對象的簡單性 ? 平均起來， 每個(gè)服務(wù)所使用的屬性不應(yīng)超過 1 ~ 2 個(gè) ，而且有 2／ 3 應(yīng)當(dāng)能夠追溯到 OOA模型。 ? 保持 消息協(xié)議的簡單性 ——復(fù)雜的消息協(xié)議常常意味著在類或?qū)ο笾g有很強(qiáng)的耦合。 ?將設(shè)計(jì)的易變性降到最低 ——一個(gè)差的設(shè)計(jì) 會(huì)在項(xiàng)目的開發(fā)過程中或在日后的維護(hù)工作中 顯示出一定的易變性 。中型應(yīng)用的類層次不應(yīng)超過幾十個(gè)，每個(gè)類所包含的子類只應(yīng)有十幾個(gè)左右。例如 ?觀察 對象之間的協(xié)同情況 ，檢查 ? 對象之間傳遞大而復(fù)雜的數(shù)據(jù)結(jié)構(gòu) (差耦合 ) ? 在對象之間進(jìn)行長距離接力傳遞的數(shù)據(jù) ?檢查 對象中的服務(wù) ，看封裝機(jī)制是否完全。 ? 最后檢查 OOD的命名約定。因?yàn)樗鼈兪窃趯?yīng)用領(lǐng)域概念進(jìn)行基于語言的分析后產(chǎn)生的。 ? 關(guān)于 OOA模型的文檔編制和評審過程方面的大部分說明也同樣適用于 OOD模型，一個(gè)明顯的區(qū)別則在于 OOD模型的文檔所面對的對象是設(shè)計(jì)人員和實(shí)現(xiàn)人員 ， 而不是用戶 。最重要的是看實(shí)現(xiàn)人員是誰。 ? 不同的項(xiàng)目可能有不同的文檔標(biāo)準(zhǔn)需求 。對于某些系統(tǒng)時(shí)序圖、算法規(guī)格說明、圖解、統(tǒng)計(jì) – 預(yù)報(bào)曲線、電子數(shù)據(jù)表格、流程圖等，都可以放在設(shè)計(jì)文檔中。結(jié)論是：如果在一個(gè)給定的設(shè)計(jì)中說明了所有的系統(tǒng)事件和響應(yīng)，那么這個(gè)系統(tǒng)就一定能成功！ 程序設(shè)計(jì)語言的考慮 ?以往談到復(fù)用，總是想到代碼復(fù)用。 ? 可以使用 非面向?qū)ο蟪绦蛘Z言 實(shí)現(xiàn) 面向?qū)ο蟪绦?。有些項(xiàng)目不可能將程序轉(zhuǎn)換為面向?qū)ο蟮某绦?。所?應(yīng)首先在 OOA和OOD方面對程序員進(jìn)行培訓(xùn) 。 ? 如果一個(gè)項(xiàng)目的各個(gè)階段和工作成果在一個(gè)可控制的和可管理的方式下可以重做，那么這樣的軟件開發(fā)過程就是一個(gè)迭代的過程。這些活動(dòng)進(jìn)行了一次又一次。 ) 基本模型 圖形用戶 界面設(shè)計(jì) OOD工作表格 分 配 各 需 種 求 實(shí)現(xiàn) 設(shè) 計(jì) 模 型 產(chǎn)品 各種 軟件 需求 其他信息 , 文獻(xiàn) ,手 冊 ,類似 產(chǎn)品等 支持包括： 追蹤能力矩陣 , 配置管理 ,各種 管理報(bào)告 ,各種 度量等 文檔 項(xiàng)目數(shù)據(jù)庫 ? 在實(shí)現(xiàn)時(shí)， 線程可以是系統(tǒng)的一個(gè)工作片段 。 ? 首先， 根據(jù)所標(biāo)識(shí)的需求和項(xiàng)目計(jì)劃，選擇出當(dāng)天所要實(shí)現(xiàn)的線程，再開會(huì)討論。 ? 兩個(gè)組完成設(shè)計(jì)后，線程的設(shè)計(jì)交給實(shí)現(xiàn)組，他們將其快速實(shí)現(xiàn)，解決所發(fā)現(xiàn)的問題。 ? 在一段時(shí)期內(nèi)所實(shí)現(xiàn)的線程構(gòu)成最終產(chǎn)品的一個(gè)不完整版本。就是說，它們可以將 事務(wù)規(guī)則 、 用戶界面技術(shù)以及 數(shù)據(jù)庫訪問技術(shù) 等集成在單個(gè)單元之中（如 Visual Basic表格）。 ? 將所有的問題領(lǐng)域部分中的對象映射到 RAD部分中，稱之為“ RAD對象”。這部分可能不封裝事務(wù)規(guī)則或數(shù)據(jù)庫訪問規(guī)則，屏幕和表格只與 RAD對象通信。 ? 實(shí)例連接、泛化 特化關(guān)系、整體 部分關(guān)系由RAD對象間的共享變量實(shí)現(xiàn)。規(guī)格說明包括需求定義模型、事件－響應(yīng)模型和用戶界面規(guī)格說明。 ? 黑盒測試必須要有實(shí)際用戶，最好是在一個(gè)真實(shí)世界的環(huán)境中進(jìn)行。但需要說明的是，要保存所有測試的日志和記錄。 ? 各個(gè)類之間的協(xié)同，以及 EROI圖中所定義的對事件的響應(yīng)也必須經(jīng)過驗(yàn)證。 ? 白盒測試最好由 不屬于 該項(xiàng)目組織的人 來做。首先建立測試環(huán)境。 對象級的測試 ? 對象級測試獨(dú)立于任何特定的應(yīng)用系統(tǒng)。 ? 黑盒測試應(yīng)當(dāng)由開發(fā)組進(jìn)行。 ?對象級的白盒測試 ? 對象級的白盒測試也是由開發(fā)組完成的。 ? 我們給出 12個(gè)步驟，幫你轉(zhuǎn)向面向?qū)ο蟮姆椒ā? 步驟 2：理解，理解，還是理解 ? 轉(zhuǎn)向面向?qū)ο蟮脑? —復(fù)用 (Reuse)。也許可能要到再下一個(gè)項(xiàng)目。 步驟 3：對財(cái)產(chǎn)進(jìn)行評估 ? 在評估軟件開發(fā)過程時(shí)，要識(shí)別和區(qū)分 工作產(chǎn)品 和 人工制品 。 ? 然后擬訂 過渡計(jì)劃 ，標(biāo)識(shí)出 新的面向?qū)ο蠊ぷ鳟a(chǎn)品 和 支持這些工作產(chǎn)品的人工制品 ，將這些對應(yīng)到當(dāng)前的過程中。 ? 優(yōu)點(diǎn)是可以 減少引入一個(gè)新技術(shù)所帶來的風(fēng)險(xiǎn) ，有助于將某些新技術(shù)應(yīng)用到主流項(xiàng)目中 。 ? 一種好的度量是 監(jiān)控每人每個(gè)單位時(shí)間的請求編譯的次數(shù) 。 應(yīng)在這些微度量有意義的環(huán)境中使用它們 。如果項(xiàng)目成員失去主動(dòng)性或惡意地屈從，可能回導(dǎo)致項(xiàng)目失敗。以致于無法集中精力作好任何事情。在完全掌握了這些新技術(shù)之后，再將它們集成。應(yīng) 先派一個(gè)人參加面向?qū)ο蟮呐嘤?xùn) ， 再由這個(gè)人對其他人員進(jìn)行培訓(xùn) 。這個(gè)模型生成了一個(gè) 基本的對象集合 。 步驟 10：嚴(yán)格遵守第一個(gè)項(xiàng)目的進(jìn)度 ? 第一個(gè)項(xiàng)目可能很難控制。 ? 按預(yù)定日期交付你的第一個(gè)項(xiàng)目完全是出于士氣的考慮，這樣可以提高你的可信度，增加策略上的資本。 ? 應(yīng)當(dāng) 用有實(shí)際意義的方法對復(fù)用進(jìn)行度量 。他們側(cè)重于理解事務(wù)過程，集成對象協(xié)同工作，構(gòu)建起系統(tǒng)。 ? 建立有利于復(fù)用的機(jī)制如同引入面向?qū)ο蠓椒ê驼Z言一樣重要。