【正文】 ，與項(xiàng)目組織的文化背景有關(guān)，與正式的里程碑評審過程不同。理由是： ?許多老程序員對面向?qū)ο蟛皇煜?，但他們了解業(yè)務(wù)和事務(wù)規(guī)則。 一個迭代的軟件開發(fā)過程 ? 任何一個軟件系統(tǒng)的分析和設(shè)計(jì)都是在整個軟件開發(fā)過程的上下文環(huán)境中執(zhí)行的。 ? 用于履行這種迭代的機(jī)制就是線程。 ? 可能提出的線程中有一些不能實(shí)現(xiàn)，這些線程就需要修改，或者對需求提出質(zhì)疑。 將線程分布到各組 產(chǎn)生實(shí)現(xiàn)方案 評審線程 需要 產(chǎn)生數(shù)據(jù)庫 嗎？ 線程 可接受 嗎？ 產(chǎn)生數(shù) 據(jù)庫實(shí) 現(xiàn)方案 基于線程的實(shí)現(xiàn)流程圖 (續(xù) ) 將線程分布到各組 產(chǎn)生 OOM線程段 解除處理 在快速應(yīng)用開發(fā) (RAD)環(huán)境下實(shí)現(xiàn)面向?qū)ο蟮脑O(shè)計(jì) ? 目前存在多種應(yīng)用程序構(gòu)造系統(tǒng)，即 RAD環(huán)境。使所有的系統(tǒng)邏輯都包含在其中。 對基于對象的設(shè)計(jì)進(jìn)行測試 ? 將系統(tǒng)級測試與對象級測試區(qū)分開是很重要的。 系統(tǒng)級的測試 ? 黑盒測試需要兩類測試人員：一類是熟悉開發(fā)方法的人，他們能夠看懂各種圖表、符號；另一類是用戶，他們對用戶界面最有發(fā)言權(quán)。 ? 這種驗(yàn)證 不包括 服務(wù)級的測試 。其次，要求能夠訪問軟件的消息、屬性，及其他軟件成分。 ? 這種測試要求在消息的源端或目的端用虛擬的樁 (stub)操作代替實(shí)際的源端服務(wù)或目的端服務(wù)，以便獨(dú)立地對每個服務(wù)進(jìn)行測試。我們不能保證這些步驟很容易實(shí)現(xiàn)，但按這些步驟認(rèn)真去做，肯定不會失敗。 ? 轉(zhuǎn)向面向?qū)ο蟮倪^程有兩種觀點(diǎn)： 逐漸演變 或全新變革 。 步驟 4：標(biāo)識一個“共生項(xiàng)目” (Symbioject) ? 如果對一個新的陌生的技術(shù)沒有充分了解，沒有弄清它對項(xiàng)目、組織和人員有什么影響之前，貿(mào)然使用它開發(fā)一個重大項(xiàng)目是非常莽撞的。 一個模塊開發(fā)接近完成時，這個度量結(jié)果應(yīng)接近于零。 ? 一個解決辦法是 激發(fā)全體項(xiàng)目組人員的信心 ，通過良好的培訓(xùn)和個別輔導(dǎo) ， 使他們成為項(xiàng)目負(fù)責(zé)人的積極擁戴者 。 步驟 8：避免學(xué)習(xí)走彎路 ? 在轉(zhuǎn)向面向?qū)ο髸r，注意培訓(xùn)和咨詢。 ? 對這個最初的信息模型，應(yīng)征求其他人的意見。 步驟 11：開始建立復(fù)用庫 ? 在開發(fā)的機(jī)構(gòu)中應(yīng)建立起用于復(fù)用的最基礎(chǔ)的機(jī)制。 要點(diǎn) ? 面向?qū)ο蠓椒赡懿⒉贿m合于所有的項(xiàng)目。 ? 項(xiàng)目組織也許需要改變其結(jié)構(gòu)以適應(yīng)面向?qū)ο蟮拈_發(fā)。 ? 在實(shí)現(xiàn)了第一個項(xiàng)目后，組織機(jī)構(gòu)會有一些分化：一些人是 對象創(chuàng)建者 ，他們負(fù)責(zé)生成對象，是 實(shí)現(xiàn)領(lǐng)域方面的專家 ；另一些人是系統(tǒng)創(chuàng)建者 ，他們 是應(yīng)用領(lǐng)域方面的專家 。 但千萬、千萬不要將項(xiàng)目的交付日期提前 。 ? 如果不考慮面向?qū)ο蠓椒ǖ奶厥獠糠?，那么所有的面向?qū)ο蠓椒ǘ紩赃@種或那種方式建立一個 信息模型 ?？赡艿脑挘?將它們引入到一 些并行的試驗(yàn)性項(xiàng)目中 。 ? 例如，發(fā)揮項(xiàng)目組全體成員的積極性，是項(xiàng)目成功的關(guān)鍵。 ? 良好監(jiān)控的關(guān)鍵在于 微度量 ，即對進(jìn)度、質(zhì)量、效率等的度量。 ? 還需要評估人力資源。 ? 面向?qū)ο蠓椒ㄋ鶐淼?收益將在下一個項(xiàng)目中得到 。 ? 由于提交大而復(fù)雜的軟件系統(tǒng)所造成的在預(yù)算和進(jìn)度上不斷增加的壓力，促使許多開發(fā)機(jī)構(gòu)從當(dāng)前傳統(tǒng)的軟件開發(fā)方法倉促地轉(zhuǎn)向面向?qū)ο蠓椒ā＿@個測試臺能夠讓對象接收消息，并能對所生成的消息進(jìn)行顯示、捕捉和分析。 ? 白盒測試的準(zhǔn)備工作由一個獨(dú)立的小組完成。 ? 在 EROI圖中定義的類所能識別的每一個事件都必須經(jīng)過驗(yàn)證。從用戶角度捕捉系統(tǒng)行為。 ? RAD對象之間的消息傳遞都通過函數(shù)或子程序調(diào)用來完成。需要有項(xiàng)目標(biāo)準(zhǔn)和開發(fā)人員守則。有些線程可以接受，有些現(xiàn)成需要重做。 ? 下圖描述了項(xiàng)目開發(fā)組在某一天根據(jù)迭代的開 發(fā)過程進(jìn)行的活動。 ? 圖中的各種活動并不是以瀑布流水的方式組織起來的。其結(jié)果就是自頂向下，從功能上分解對象。面向?qū)ο笫且环N先進(jìn)的技術(shù)，它使得可以復(fù)用的東西遠(yuǎn)遠(yuǎn)超過了代碼。 ? 我們希望將所開發(fā)的用戶界面屏幕放到設(shè)計(jì)文檔中。 ? 各個項(xiàng)目要求的詳細(xì)程度各不相同 。從產(chǎn)生的 OOA/OOD 模型來看，幾乎所有的對象都是高內(nèi)聚、低耦合的。 ? 利用以上準(zhǔn)則來檢查 ECS的 OOD設(shè)計(jì)，看是否有需要改進(jìn)的地方。使用 Smalltalk語言， 每個服務(wù)的代碼行數(shù)通常不超過 10行。影響層次的因素有程序設(shè)計(jì)語言、 用單繼承還是多繼承等。 ?內(nèi)聚性準(zhǔn)則 ——描述系統(tǒng)組成中各元素的關(guān)聯(lián)度或強(qiáng)度。之所以將數(shù)據(jù)庫管理技術(shù)從 OOD PDC 中分離出來，是為了將來更換 DBMS時可以只修改 DMC讓系統(tǒng)其他部分可一概不動。 ?一旦按下召喚按鈕，第一個反應(yīng)是“ 召喚中斷 ”類被喚醒，并報告“我接收到一個召喚”。在設(shè)計(jì)中采用輪詢超載傳感器的方式產(chǎn)生超載事件。 ? 在 ECS系統(tǒng)中有大量的系統(tǒng)必須對其響應(yīng)的異步事件 。在開發(fā)目標(biāo)系統(tǒng)的HIC時，應(yīng)允許用戶對其試用。其目的是讓人機(jī)界面適應(yīng)用戶。在 OOA模型中敘述“當(dāng)召喚請求發(fā)生時 ?? ，對象 ‘召喚事件’ 將向?qū)ο蟆賳久姘濉? 報告召喚事件的發(fā)生。 ? 由于性能、將來的復(fù)用、程序設(shè)計(jì)語言的限制、規(guī)范化等原因，可能還需要對 PDC作出一些其他改動。 ? 提高性能最好的方法是采用最出色的解決方案，而不是拼命地去節(jié)省幾個微秒、幾個字節(jié)。 ? 提高一個現(xiàn)存系統(tǒng)的工作效率比重新設(shè)計(jì)一個高效的系統(tǒng)要容易。 ?增加某些屬性到原來的類中，或增加低層的類，以保存暫時結(jié)果，避免每次都要重復(fù)計(jì)算造成速度損失。 ? 對繼承進(jìn)行調(diào)整 ?在 OOA模型中可能包括有多繼承關(guān)系 , 但實(shí)現(xiàn)時使用的程序設(shè)計(jì)語言可能只有單繼承，甚至沒有繼承機(jī)制，這樣就需變更 PDC中類的層次結(jié)構(gòu) 。 ?增加從既存類到 OOA類之間的泛化 特化關(guān)系，盡可能繼承既存類的屬性和方法。 ? 與 OOA模型一樣， OOD 模型也有 5 層結(jié)構(gòu)，又被劃分成了 4 個組成部分。 ? 數(shù)據(jù)庫管理 ：系統(tǒng)將管理什么類型的數(shù)據(jù)？ ? 可復(fù)用性 ：可以考慮購買一個商品類庫來實(shí)現(xiàn)OOA的對象。 ? 性能限制 ：如電梯每到一個樓層時都要減速，乘客就不得不忍受失重狀態(tài)，需要考慮調(diào)度算法，讓 ECS來預(yù)測什么時候電梯應(yīng)停在某一樓層。 ? 由于 OOA和 OOD采用相同的基本圖形表示法，更容易體現(xiàn) OOA與 OOD工作的連續(xù)性和無縫隙性 。 ? 編程語言對設(shè)計(jì)過程及設(shè)計(jì)者的設(shè)計(jì)思想都將產(chǎn)生巨大的影響。 ? OOD的表示法應(yīng)盡可能地接近 OOA表示法 。 ? 在實(shí)際項(xiàng)目中，應(yīng)把以上建議轉(zhuǎn)換為方針和過程。 ? 需要有關(guān)人員共同討論，不一定舉行正式的評審會議。就是說首先把 OOA模型充分地文檔化，分發(fā)給各評審者，然后召集評審會，共同評審。 ? 評審過程 應(yīng)是 非正式的 ， 持續(xù)的 ，貫 穿在項(xiàng)目的整個生存期中 的 過程 。 ? 對語義正確性的評審采用的策略類似于在開發(fā)面向用戶的文檔時采用的策略， 將模型的行為對照用戶描述的場景或用戶事例 ， 一一加以確認(rèn) 。 ? 評審者可以利用這些手段，監(jiān)控、改變、標(biāo)記 OOA模型的動態(tài)行為。 ? 用 圖形表示 表達(dá)設(shè)計(jì)。 必須將這個設(shè)計(jì)翻譯成語言程序 ，然后對產(chǎn)生的代碼進(jìn)行測試 。 ? OOD方法與以往方法不同，它以 OOA模型為設(shè)計(jì)的雛形。在 OOA模型的基礎(chǔ)上增加相應(yīng)的類和對象。例如，早上 ECS如何開始運(yùn)行：晚上電梯關(guān)閉后如何結(jié)束運(yùn)行 . ?人機(jī)交互 ：對人機(jī)界面是否有特殊的設(shè)計(jì)限制？發(fā)給電梯機(jī)構(gòu)的通信指令中是否存在什么協(xié)議？是否可能是校驗(yàn)和？對于具有智能輔助或聯(lián)機(jī)文檔的幫助工具有什么協(xié)議？對于需求文檔中未提到的，設(shè)計(jì)者可以不考慮。這有助于從分析到設(shè)計(jì)的轉(zhuǎn)換。 ?標(biāo)明既存類中不需要的屬性和操作。 ?在各個子類中定義其實(shí)現(xiàn)。 ?如果類之間經(jīng)常需要傳送大量消息，可合并相關(guān)的類，使得通信成為對象內(nèi)的通信，或者使用全局?jǐn)?shù)據(jù)作用域，打破封裝的原則，以 減少消息傳遞引起的速度損失 。且用非 OOPL編程會令程序員非常疲勞，易出錯。在代碼復(fù)雜性與運(yùn)行的低效之間沒有相關(guān)性。 ? 根據(jù)實(shí)現(xiàn)技術(shù)及實(shí)現(xiàn)方面的限制，修改原始的PDC部分，但保留在 OOA模型中所捕獲到的基本的系統(tǒng)行為， ? 如果使用可復(fù)用的類，那么它也要引入到 PDC中。 下行召喚指示燈 召喚指示燈 指示燈 人機(jī)交互部分 到達(dá)指示燈 目的地指示燈 上行召喚指示燈 ? 例如，考慮召喚請求如何發(fā)生。 ?一種適應(yīng)用戶文化背景的有效方法是“ 直觀表示 ”。事實(shí)上， 在建立 OOA模型的同時就開始著手 HIC的設(shè)計(jì)了 。這樣一些任務(wù)可以被看作是一些獨(dú)立的可調(diào)度的實(shí)體。 ? 與事件 – 響應(yīng)模型中其他事件不同，超載事件沒有相應(yīng)的中斷，故沒有“ 超載中斷 ”類。因此，存入輸入寄存器中的二進(jìn)制數(shù)