【正文】 ? 建立有利于復(fù)用的機制如同引入面向?qū)ο蠓椒ê驼Z言一樣重要。 ? 應(yīng)當(dāng) 用有實際意義的方法對復(fù)用進(jìn)行度量 。 步驟 10：嚴(yán)格遵守第一個項目的進(jìn)度 ? 第一個項目可能很難控制。應(yīng) 先派一個人參加面向?qū)ο蟮呐嘤?xùn) ， 再由這個人對其他人員進(jìn)行培訓(xùn) 。以致于無法集中精力作好任何事情。 應(yīng)在這些微度量有意義的環(huán)境中使用它們 。 ? 優(yōu)點是可以 減少引入一個新技術(shù)所帶來的風(fēng)險 ，有助于將某些新技術(shù)應(yīng)用到主流項目中 。 步驟 3：對財產(chǎn)進(jìn)行評估 ? 在評估軟件開發(fā)過程時，要識別和區(qū)分 工作產(chǎn)品 和 人工制品 。 步驟 2：理解，理解，還是理解 ? 轉(zhuǎn)向面向?qū)ο蟮脑? —復(fù)用 (Reuse)。 ?對象級的白盒測試 ? 對象級的白盒測試也是由開發(fā)組完成的。 對象級的測試 ? 對象級測試獨立于任何特定的應(yīng)用系統(tǒng)。 ? 白盒測試最好由 不屬于 該項目組織的人 來做。但需要說明的是，要保存所有測試的日志和記錄。規(guī)格說明包括需求定義模型、事件－響應(yīng)模型和用戶界面規(guī)格說明。這部分可能不封裝事務(wù)規(guī)則或數(shù)據(jù)庫訪問規(guī)則，屏幕和表格只與 RAD對象通信。就是說，它們可以將 事務(wù)規(guī)則 、 用戶界面技術(shù)以及 數(shù)據(jù)庫訪問技術(shù) 等集成在單個單元之中（如 Visual Basic表格）。 ? 兩個組完成設(shè)計后，線程的設(shè)計交給實現(xiàn)組，他們將其快速實現(xiàn)，解決所發(fā)現(xiàn)的問題。 ) 基本模型 圖形用戶 界面設(shè)計 OOD工作表格 分 配 各 需 種 求 實現(xiàn) 設(shè) 計 模 型 產(chǎn)品 各種 軟件 需求 其他信息 , 文獻(xiàn) ,手 冊 ,類似 產(chǎn)品等 支持包括： 追蹤能力矩陣 , 配置管理 ,各種 管理報告 ,各種 度量等 文檔 項目數(shù)據(jù)庫 ? 在實現(xiàn)時， 線程可以是系統(tǒng)的一個工作片段 。 ? 如果一個項目的各個階段和工作成果在一個可控制的和可管理的方式下可以重做，那么這樣的軟件開發(fā)過程就是一個迭代的過程。有些項目不可能將程序轉(zhuǎn)換為面向?qū)ο蟮某绦?。結(jié)論是：如果在一個給定的設(shè)計中說明了所有的系統(tǒng)事件和響應(yīng)，那么這個系統(tǒng)就一定能成功！ 程序設(shè)計語言的考慮 ?以往談到復(fù)用，總是想到代碼復(fù)用。 ? 不同的項目可能有不同的文檔標(biāo)準(zhǔn)需求 。 ? 關(guān)于 OOA模型的文檔編制和評審過程方面的大部分說明也同樣適用于 OOD模型，一個明顯的區(qū)別則在于 OOD模型的文檔所面對的對象是設(shè)計人員和實現(xiàn)人員 ， 而不是用戶 。 ? 最后檢查 OOD的命名約定。中型應(yīng)用的類層次不應(yīng)超過幾十個，每個類所包含的子類只應(yīng)有十幾個左右。 ? 保持 消息協(xié)議的簡單性 ——復(fù)雜的消息協(xié)議常常意味著在類或?qū)ο笾g有很強的耦合。建議： ? 命名屬性和服務(wù)的詞要求前后一致； ? 避免使用過多的消息模板； ? 不要對類的定義摸棱兩可，遵從類的現(xiàn)有協(xié)議或行為。 ? 評價面向?qū)ο笤O(shè)計的準(zhǔn)則 : ?耦合性準(zhǔn)則 ——指系統(tǒng)各個具體成份之間相互連接或相互依賴的強度。如決定增加第三個按鈕用于召喚運貨電梯，只需改動一個類“ 召喚按鈕 ”即可，而系統(tǒng)其他部分可一概不予改動。 向下的召喚按鈕編號為奇數(shù)，向上的召喚按鈕編號為偶數(shù)。 ECS的類與對象 ? 考察 ECS OOA/OOD工作表格 , 可以發(fā)現(xiàn) 中斷處理 和 寄存器訪問 是設(shè)計需求的重要部分。 使用菜單樹或狀態(tài) 遷移圖，連同某些原型，來說明用戶界面的設(shè)計思想。建立原型時必須對所有 HIC設(shè)計進(jìn)行嚴(yán)格的檢驗?？赡懿粌H僅意味著語言、傳統(tǒng)和習(xí)慣。 上行召喚按鈕 下行召喚按鈕 召喚按鈕 目的地按鈕 按 鈕 人機交互部分 ? ECS的 HIC由各種按鈕和指示燈對象組成。在運行時執(zhí)行有必要驗證其功能的操作，并向電梯監(jiān)視器報告。一些像繼承、動態(tài)綁定、消息傳遞等處理雖然看起來簡單，但需要大量的系統(tǒng)開銷 。 ? 不要認(rèn)為象 C++之類的 OOPL就一定效率不高。 人 醫(yī)生 教授 醫(yī)學(xué)教授 人 角色 醫(yī)生角色 教授角色 多繼承 通過實例連接 分解多繼承 醫(yī)生 醫(yī)學(xué)教授 教授 人 平鋪為繼承 ? 修改設(shè)計以提高性能 ?提高執(zhí)行效率和速度是系統(tǒng)設(shè)計的主要指標(biāo)之一。 ?該父類定義為所有這些子類共用的一組服務(wù)名，作為公共的協(xié)議，用來與 DMC或其他外部系統(tǒng)部件通信。 ? 首先復(fù)制 OOA模型為 OOD模型的問題領(lǐng)域部分，然后對這個部分進(jìn)行修改。 OOD模型以最完整的形式全面地定義了如何用特定的實現(xiàn)技術(shù)建立起一個目標(biāo)系統(tǒng)。 ?開發(fā)環(huán)境 ：系統(tǒng)如何實現(xiàn)？對開發(fā)環(huán)境有什么限制？多重異步通信靠什么支持？如果分析模型中存在多繼承，而編程語言只能支持單繼承，應(yīng)如何調(diào)整？ ?初始化活動和結(jié)束活動 ：執(zhí)行初始化活動和結(jié)束活動的過程是必不可少的。 ECS的 OOD問題 ? 設(shè)計 ECS系統(tǒng)的體系結(jié)構(gòu)的策略基本按照前面所述的方法。 MVC模型 ? 我們的 OOD體系結(jié)構(gòu)與 MVC結(jié)構(gòu)類似，但增加了一個成分： 數(shù)據(jù)庫管理部分 。而針對OOD的準(zhǔn)則與它們很類似，其中有一些準(zhǔn)則在本質(zhì)上與老的方法相同，有些具有面向?qū)ο蟮莫毺靥攸c。 ? 分析通常建立在“完美的”技術(shù)的假設(shè)之上，而對于設(shè)計，則通常涉及具體的實現(xiàn)環(huán)境，包括系統(tǒng)的運行硬件平臺、操作系統(tǒng)、使用的編程語言等。驅(qū)動者控制計算機設(shè)備、巡航 OOA模型和 EROI圖，記錄者訪問公共CASE工具庫。所生成的 管理報告可以監(jiān)控 、 跟蹤工程進(jìn)度 ， 保證每一模型成分的質(zhì)量 。 ? 如果在系統(tǒng)開始運行之后才發(fā)現(xiàn)對用戶的需求理解錯了或解釋錯了。 ? 對這些評審項目進(jìn)行評審，目的是確保 OOA模型的 語法正確性 ，確?！敖⒛Ｐ驼_”。 ? 在評審過程中使用 CASE工具，可以動態(tài)地描述和執(zhí)行 OOA模型。 ? 生成一個好的系統(tǒng)，需要有 許多素質(zhì)良好的工作人員 ， 好的構(gòu)思 ，還需要 好的項目管理 。 ? 以往評價一個項目的設(shè)計時，常用效率、完備性、靈活性等指標(biāo)來衡量。一些商品化的 OOD形式就受到 Ada、 Eiffel、C++、 Smalltalk、 Java等語言的影響。產(chǎn)生的問題是：作為系統(tǒng)的核心 — 問題領(lǐng)域部分將與外部世界隔絕，不再與外部世界交往?？赡苄枰黾印皽囟扔嫛睂ο?，調(diào)整傳感器讀數(shù)的安全性。 要點 ? 從 OOA轉(zhuǎn)到 OOD需要 在 OOA模型的基礎(chǔ)上加入實現(xiàn)方面的限制 。這種策略能夠幫助提高產(chǎn)品的可復(fù)用性。 ?修改 OOA類的結(jié)構(gòu)和連接。 ? 把多繼承的層次結(jié)構(gòu)平鋪，成為單繼承的層次結(jié)構(gòu)。但 要作出平衡 ， 要使PDC與原來的 OOA模型盡可能相近 而減少測試開銷和維護開銷。 ? 通常系統(tǒng) 80%的開銷都集中在 20%的代碼段上。 ECS的 PDC ? 決定使用一個中央控制器（電梯控制器）控制和協(xié)調(diào)電梯的所有動作，包括解決電梯每到一個樓層減速問題。 ? HIC部分在系統(tǒng)行為和用戶交互的實現(xiàn)之間架起了一座橋梁。 ? 實際上，“ 召喚事件 ” 在它接收到從 “ 召喚按鈕 ”發(fā)送來的消息之前，根本就不理會周圍的任何事務(wù)。 ?使用用戶開發(fā)的場景或用況來驅(qū)動界面 。 ? 事實上，使用各種所謂的可視化開發(fā)環(huán)境，如Delphi, PowerBuilder, Vasual Basic等，開發(fā)人員可能連 HIC都不要。 ? 首先， 要標(biāo)識一些新的類 ，這些類建立后將負(fù)責(zé)處理并發(fā)、中斷 、調(diào)度（在操作系統(tǒng)級）以及其他有關(guān)特定平臺的一些問題 . ? TMC把與特定硬 /軟件平臺有關(guān)的處理機制封裝在自己內(nèi)部 ， 對系統(tǒng)的其他部分隱藏起來 ，一旦決定將 ECS移植到另一個平臺上時，只需替換 TMC中的類就可以了。 ? 當(dāng) 召喚按鈕被按下時（在 ECS之外），產(chǎn)生了一個中斷，終止正在運行的程序。 ?類“ 召喚按鈕 ”封裝了如何將寄存器值轉(zhuǎn)換為按鈕號碼的機制，它通知相應(yīng)“ 召喚按鈕 ”對象：你被按下了，你要開始工作了。但這不一定是唯一的，也不一定是最好的。在面向?qū)ο笤O(shè)計時，從 3個層次來考察內(nèi)聚性： ?單個服務(wù)的內(nèi)聚性； ?封裝在類和對象中的數(shù)據(jù)和服務(wù)的內(nèi)聚性； ?整個類的層次結(jié)構(gòu)的內(nèi)聚性。 ? 除了處理內(nèi)部事務(wù)所用的私有服務(wù)外， 類所具有的公共服務(wù)不應(yīng)多于 6 ~ 7 個 。 ? 例如，為改正軟件缺陷，對一個類作一些小改動，或者在軟件中增加一個新的特性，都會在許多其他類中引起一連串的反應(yīng)。 ?檢查 繼承的層次結(jié)構(gòu) ，確保父類不依賴子類。 ? ECS系統(tǒng)的大部分設(shè)計簡單明了，對象包含了數(shù)量合理的屬性和服務(wù)，耦合性和內(nèi)聚性也很好。 ? 在小規(guī)模的項目中，實現(xiàn)人員就是設(shè)計人員。 ? 設(shè)計評審過程是一個持續(xù)進(jìn)行的過程