計(jì)算機(jī)軟件及應(yīng)用面向?qū)ο筌浖_發(fā)事例3

實(shí)用面向?qū)ο筌浖こ探坛蘡asestudiesinOBJECTORIENTED評(píng)審和修正分析模型過(guò)渡到設(shè)計(jì)問(wèn)題領(lǐng)域中的問(wèn)題定義用戶界面任務(wù)管理問(wèn)題數(shù)據(jù)庫(kù)設(shè)計(jì)設(shè)計(jì)級(jí)的質(zhì)量問(wèn)題設(shè)計(jì)模型的文檔編制和評(píng)審實(shí)現(xiàn)方面的問(wèn)題轉(zhuǎn)向面向?qū)ο蠓椒ǖ氖€(gè)步驟評(píng)審和修正評(píng)審OOA模型的目的是為了保證在實(shí)現(xiàn)系統(tǒng)之前，能夠正確理解和解釋用戶的需求。如果在系統(tǒng)開始運(yùn)行之后才發(fā)現(xiàn)對(duì)用戶的需求理解錯(cuò)了或解釋錯(cuò)了。當(dāng)系統(tǒng)正式運(yùn)行之后再修正這種錯(cuò)誤，所付出的代價(jià)要遠(yuǎn)遠(yuǎn)大于在工程的分析階段修正錯(cuò)誤所付出的代價(jià)。評(píng)審過(guò)程應(yīng)是非正式的，持續(xù)的，貫穿在工程的整個(gè)生存期中的過(guò)程。就是說(shuō)首先把OOA模型充分地文檔化，分發(fā)給各評(píng)審者，然后召集評(píng)審會(huì)，共同評(píng)審。OOA模型的一個(gè)評(píng)審策略建立一個(gè)評(píng)審檢查表，列出各種評(píng)審工程。對(duì)這些評(píng)審工程進(jìn)行評(píng)審，目的是確保OOA模型的語(yǔ)法正確性，確?！敖⒛Ｐ驼_〞。可將檢查表嵌入到每個(gè)屬性、效勞、對(duì)象中去，跟蹤定義-使用情況。好處：評(píng)審過(guò)程已成為開發(fā)過(guò)程的一局部。所生成的管理報(bào)告可以監(jiān)控、跟蹤工程進(jìn)度，保證每一模型成分的質(zhì)量。OOA模型—評(píng)審者的檢查表OOA模型—評(píng)審者的檢查表〔續(xù)〕OOA模型—評(píng)審者的檢查表〔續(xù)〕現(xiàn)有的所有檢查表都無(wú)法保證語(yǔ)義正確性，即是否建立了“正確的模型〞。對(duì)語(yǔ)義正確性的評(píng)審采用的策略類似于在開發(fā)面向用戶的文檔時(shí)采用的策略，將模型的行為對(duì)照用戶描述的場(chǎng)景或用戶事例，一一加以確認(rèn)。需要有關(guān)人員共同討論，不一定舉行正式的評(píng)審會(huì)議。檢查語(yǔ)義正確性從事件-響應(yīng)模型和EROI圖入手，走查每一個(gè)場(chǎng)景或事例，一步一步驗(yàn)證事件如何識(shí)別，相關(guān)響應(yīng)如何產(chǎn)生。在評(píng)審過(guò)程中使用CASE工具，可以動(dòng)態(tài)地描述和執(zhí)行OOA模型。在實(shí)際的工程評(píng)審中，可以采用兩個(gè)顯示器：一個(gè)顯示器用來(lái)顯示OOA模型，另一個(gè)顯示器用來(lái)顯示EROI圖表。對(duì)于這樣的正式評(píng)審，需要一個(gè)“驅(qū)動(dòng)者〞，一個(gè)“記錄者〞。驅(qū)動(dòng)者控制計(jì)算機(jī)設(shè)備、巡航OOA模型和EROI圖，記錄者訪問(wèn)公共CASE工具庫(kù)。在一步一步走查事件或場(chǎng)景，驗(yàn)證OOA模型的行為時(shí)，他們可以對(duì)OOA模型、EROI圖或其他工作結(jié)果進(jìn)行可視化的交互修改。評(píng)審者可以利用這些手段，監(jiān)控、改變、標(biāo)記OOA模型的動(dòng)態(tài)行為。在實(shí)際工程中，應(yīng)把以上建議轉(zhuǎn)換為方針和過(guò)程。一個(gè)好的工程管理所應(yīng)具備的根本特點(diǎn)之一就是要堅(jiān)持文檔化和評(píng)審。生成一個(gè)好的系統(tǒng)，需要有許多素質(zhì)良好的工作人員，好的構(gòu)思，還需要好的工程管理。過(guò)渡到設(shè)計(jì)在面向?qū)ο箝_發(fā)模式中，分析和設(shè)計(jì)之間的界限是模糊的。通常，分析涉及系統(tǒng)做什么，設(shè)計(jì)那么涉及需求如何實(shí)現(xiàn)。分析通常建立在“完美的〞技術(shù)的假設(shè)之上，而對(duì)于設(shè)計(jì)，那么通常涉及具體的實(shí)現(xiàn)環(huán)境，包括系統(tǒng)的運(yùn)行硬件平臺(tái)、操作系統(tǒng)、使用的編程語(yǔ)言等。OOD表示法OOD涉及到實(shí)現(xiàn)，它的表示涉及任務(wù)、模塊、處理器、隊(duì)列，以及其他硬件/軟件等。用圖形表示表達(dá)設(shè)計(jì)。OOD的表示法應(yīng)盡可能地接近OOA表示法。問(wèn)題：利用OOA模型描述的需求，軟件工程師應(yīng)當(dāng)如何籌劃面向?qū)ο蟮脑O(shè)計(jì)？從哪兒開始著手？采取什么步驟？應(yīng)該得出什么類型的體系結(jié)構(gòu)或結(jié)構(gòu)？OOD策略O(shè)OD的評(píng)價(jià)準(zhǔn)那么制定評(píng)價(jià)準(zhǔn)那么的目的是使得我們能夠以一種客觀的方法來(lái)對(duì)一個(gè)設(shè)計(jì)作出評(píng)價(jià)。以往評(píng)價(jià)一個(gè)工程的設(shè)計(jì)時(shí)，常用效率、完備性、靈活性等指標(biāo)來(lái)衡量。老的設(shè)計(jì)方法,如結(jié)構(gòu)化設(shè)計(jì)方法，有它自己的一套完善的設(shè)計(jì)準(zhǔn)那么。其中最著名、最重要的概念是模塊的耦合、內(nèi)聚性。而針對(duì)OOD的準(zhǔn)那么與它們很類似，其中有一些準(zhǔn)那么在本質(zhì)上與老的方法相同，有些具有面向?qū)ο蟮莫?dú)特特點(diǎn)。其他問(wèn)題用OOD方法產(chǎn)生的設(shè)計(jì)還不是軟件的最終成品。必須將這個(gè)設(shè)計(jì)翻譯成語(yǔ)言程序，然后對(duì)產(chǎn)生的代碼進(jìn)行測(cè)試。編程語(yǔ)言對(duì)設(shè)計(jì)過(guò)程及設(shè)計(jì)者的設(shè)計(jì)思想都將產(chǎn)生巨大的影響。連面向?qū)ο蟮姆椒ㄒ矔?huì)受到編程語(yǔ)言的影響。一些商品化的OOD形式就受到Ada、Eiffel、C++、Smalltalk、Java等語(yǔ)言的影響。OOD體系結(jié)構(gòu)最早Smalltalk公司提出了一種稱之為MVC(Model-View-Controller)的結(jié)構(gòu)。將OOD體系結(jié)構(gòu)分為三個(gè)主要成分：模型(Model):為底層應(yīng)用建立模型的類和對(duì)象；視圖(View):為用戶提供與模型有關(guān)的類接口視圖的類和對(duì)象；控制器(Controller):用于控制〔或同步〕其他類的行為的類和對(duì)象。MVC模型我們的OOD體系結(jié)構(gòu)與MVC結(jié)構(gòu)類似，但增加了一個(gè)成分：數(shù)據(jù)庫(kù)管理局部。模型視圖控制器OOD模型的體系結(jié)構(gòu)類與對(duì)象層屬性層服務(wù)層結(jié)構(gòu)層主題層問(wèn)題領(lǐng)域部分人機(jī)交互部分任務(wù)管理部分?jǐn)?shù)據(jù)管理部分主題服務(wù)消息屬性實(shí)例連接類邊界實(shí)例邊界這個(gè)體系結(jié)構(gòu)中使用的類和對(duì)象與OOA模型中的一樣，然后圍繞著這些類和對(duì)象，又參加了另外一些類和對(duì)象，用來(lái)處理與實(shí)現(xiàn)有關(guān)的活動(dòng)，如任務(wù)管理(TMC)、數(shù)據(jù)管理(DMC)以及人機(jī)交互(HIC)。OOD方法與以往方法不同，它以O(shè)OA模型為設(shè)計(jì)的雛形。由于OOA和OOD采用相同的根本圖形表示法，更容易表達(dá)OOA與OOD工作的連續(xù)性和無(wú)縫隙性。通過(guò)OOD將面向?qū)ο笙到y(tǒng)結(jié)構(gòu)分為4個(gè)局部，通過(guò)人機(jī)交互局部(HIC)與外部世界接口。產(chǎn)生的問(wèn)題是：作為系統(tǒng)的核心—問(wèn)題領(lǐng)域局部將與外部世界隔絕，不再與外部世界交往。代替方案是將OOD體系結(jié)構(gòu)設(shè)計(jì)為：每個(gè)類和對(duì)象都知道如何在終端用戶的PC機(jī)或終端上與終端用戶進(jìn)行交互；知道如何讀寫磁盤文件中的數(shù)據(jù)。問(wèn)題是：改變用戶接口和數(shù)據(jù)庫(kù)容易破壞體系結(jié)構(gòu)，使得類和對(duì)象的內(nèi)部結(jié)構(gòu)更為復(fù)雜。ECS的OOD問(wèn)題設(shè)計(jì)ECS系統(tǒng)的體系結(jié)構(gòu)的策略根本按照前面所述的方法。在建立OOD模型時(shí)，必須考慮實(shí)現(xiàn)時(shí)所加的各種限制。在OOA模型的根底上增加相應(yīng)的類和對(duì)象。性能限制：如電梯每到一個(gè)樓層時(shí)都要減速，乘客就不得不忍受失重狀態(tài)，需要考慮調(diào)度算法，讓ECS來(lái)預(yù)測(cè)什么時(shí)候電梯應(yīng)停在某一樓層。功能限制：超重傳感器如果在夏天校準(zhǔn)，可能在冬天超重狀態(tài)檢測(cè)不到?？赡苄枰黾印皽囟扔?jì)〞對(duì)象，調(diào)整傳感器讀數(shù)的平安性。系統(tǒng)的可靠性和一致性：傳感器可能會(huì)失效，需要參加一個(gè)輪詢機(jī)制定時(shí)詢問(wèn)傳感器的狀況，并把結(jié)果傳給封裝傳感器的對(duì)象。也可以增加用于監(jiān)控傳感器的對(duì)象。開發(fā)環(huán)境：系統(tǒng)如何實(shí)現(xiàn)？對(duì)開發(fā)環(huán)境有什么限制？多重異步通信靠什么支持？如果分析模型中存在多繼承，而編程語(yǔ)言只能支持單繼承，應(yīng)如何調(diào)整？初始化活動(dòng)和結(jié)束活動(dòng)：執(zhí)行初始化活動(dòng)和結(jié)束活動(dòng)的過(guò)程是必不可少的。必須在問(wèn)題領(lǐng)域或或其他局部說(shuō)明。例如，早上ECS如何開始運(yùn)行：晚上電梯關(guān)閉后如何結(jié)束運(yùn)行.人機(jī)交互：對(duì)人機(jī)界面是否有特殊的設(shè)計(jì)限制？發(fā)給電梯機(jī)構(gòu)的通信指令中是否存在什么協(xié)議？是否可能是校驗(yàn)和？對(duì)于具有智能輔助或聯(lián)機(jī)文檔的幫助工具有什么協(xié)議？對(duì)于需求文檔中未提到的，設(shè)計(jì)者可以不考慮。數(shù)據(jù)庫(kù)管理：系統(tǒng)將管理什么類型的數(shù)據(jù)？可復(fù)用性：可以考慮購(gòu)置一個(gè)商品類庫(kù)來(lái)實(shí)現(xiàn)OOA的對(duì)象。盡可能保證設(shè)計(jì)出來(lái)的對(duì)象在將來(lái)的系統(tǒng)中也能用。要點(diǎn)從OOA轉(zhuǎn)到OOD需要在OOA模型的根底上參加實(shí)現(xiàn)方面的限制。OOA模型需要用實(shí)現(xiàn)技術(shù)和環(huán)境方面的詳細(xì)的規(guī)格說(shuō)明來(lái)加以補(bǔ)充。OOD模型類似于構(gòu)造藍(lán)圖。OOD模型以最完整的形式全面地定義了如何用特定的實(shí)現(xiàn)技術(shù)建立起一個(gè)目標(biāo)系統(tǒng)。在OOA模型和OOD模型中使用了共同的表示法。這有助于從分析到設(shè)計(jì)的轉(zhuǎn)換。與OOA模型一樣，OOD模型也有5層結(jié)構(gòu)，又被劃分成了4個(gè)組成局部。問(wèn)題解決局部(ProblemDomainComponent)人機(jī)界面局部(HumanInterfaceComponent)任務(wù)管理局部(TaskManagementComponent)數(shù)據(jù)管理局部(DataManagementComponent)這些組成局部把實(shí)現(xiàn)技術(shù)隱藏起來(lái)，使之與系統(tǒng)的根本問(wèn)題領(lǐng)域行為別離開來(lái)。這種策略能夠幫助提高產(chǎn)品的可復(fù)用性。對(duì)于HIC，要精心設(shè)計(jì)窗口和屏幕，為用戶提供友好的GUI。問(wèn)題領(lǐng)域中的問(wèn)題與OOA模型一樣，OOD中各局部的構(gòu)造是不斷循環(huán)反復(fù)的,而不是一個(gè)個(gè)相繼順序構(gòu)造的。首先復(fù)制OOA模型為OOD模型的問(wèn)題領(lǐng)域局部，然后對(duì)這個(gè)局部進(jìn)行修改。利用可復(fù)用的設(shè)計(jì)／編程方面的類根據(jù)需要,把從類庫(kù)或其他來(lái)源得到的可用的既存類增加到問(wèn)題解決方案中去。標(biāo)明既存類中不需要的屬性和操作。增加從既存類到OOA類之間的泛化-特化關(guān)系，盡可能繼承既存類的屬性和方法。把OOA類中因繼承既存類而成為多余的屬性和操作標(biāo)出。修改OOA類的結(jié)構(gòu)和連接。參加泛化類以建立類間協(xié)議有時(shí)某些OOA類要求一組類似的效勞。此時(shí)，以這些OOA類為子類，定義一個(gè)父類。該父類定義為所有這些子類共用的一組效勞名，作為公共的協(xié)議，用來(lái)與DMC或其他外部系統(tǒng)部件通信。這些效勞都是虛函數(shù)。在各個(gè)子類中定義其實(shí)現(xiàn)。

對(duì)繼承進(jìn)行調(diào)整在OOA模型中可能包括有多繼承關(guān)系,但實(shí)現(xiàn)時(shí)使用的程序設(shè)計(jì)語(yǔ)言可能只有單繼承，甚至沒(méi)有繼承機(jī)制，這樣就需變更PDC中類的層次結(jié)構(gòu)。針對(duì)單繼承語(yǔ)言的調(diào)整把子類對(duì)象看做是一個(gè)父類對(duì)象所扮演的角色，通過(guò)實(shí)例連接把多繼承的層次結(jié)構(gòu)轉(zhuǎn)換為單繼承的層次結(jié)構(gòu)。把多繼承的層次結(jié)構(gòu)平鋪，成為單繼承的層次結(jié)構(gòu)。在這種情況下，有些屬性或操作在同層的子類中會(huì)重復(fù)出現(xiàn)。針對(duì)無(wú)繼承語(yǔ)言的調(diào)整當(dāng)使用無(wú)繼承的程序設(shè)計(jì)語(yǔ)言時(shí)，必須把具有繼承關(guān)系的類層次結(jié)構(gòu)平鋪開來(lái)，成為一組類和對(duì)象。人醫(yī)生教授醫(yī)學(xué)教授人角色醫(yī)生角色教授角色多繼承通過(guò)實(shí)例連接分解多繼承醫(yī)生醫(yī)學(xué)教授教授人平鋪為繼承修改設(shè)計(jì)以提高性能提高執(zhí)行效率和速度是系統(tǒng)設(shè)計(jì)的主要指標(biāo)之一。有時(shí)，必須改變問(wèn)題領(lǐng)域的結(jié)構(gòu)以提高效率。如果類之間經(jīng)常需要傳送大量消息，可合并相關(guān)的類，使得通信成為對(duì)象內(nèi)的通信，或者使用全局?jǐn)?shù)據(jù)作用域，打破封裝的原那么，以減少消息傳遞引起的速度損失。增加某些屬性到原來(lái)的類中，或增加低層的類，以保存暫時(shí)結(jié)果，防止每次都要重復(fù)計(jì)算造成速度損失。軟件的效率性能很重要。但要作出平衡，要使PDC與原來(lái)的OOA模型盡可能相近而減少測(cè)試開銷和維護(hù)開銷。為提高性能，在對(duì)OOA模型進(jìn)行大規(guī)模的改動(dòng)之前，應(yīng)考慮下面一些問(wèn)題：如果沒(méi)有性能準(zhǔn)那么，不要去人為地建立。當(dāng)軟件運(yùn)行在一個(gè)CPU速度很快的計(jì)算機(jī)上，并是單機(jī)的人機(jī)交互時(shí)，大多數(shù)的時(shí)鐘周期都用在了等待用戶輸入上。不要認(rèn)為象C++之類的OOPL就一定效率不高。有一些事實(shí)說(shuō)明，非OOPL的緊湊代碼的效率比OOPL的效率高,在多數(shù)情況下，OOPL的效率損失約為10%。且用非OOPL編程會(huì)令程序員非常疲勞，易出錯(cuò)。提高一個(gè)現(xiàn)存系統(tǒng)的工作效率比重新設(shè)計(jì)一個(gè)高效的系統(tǒng)要容易。如果對(duì)設(shè)計(jì)有性能要求，只需參加少量的工作就可以了。通常系統(tǒng)80%的開銷都集中在20%的代碼段上。與其為了盡量處處節(jié)省系統(tǒng)開銷而破壞完善的系統(tǒng)結(jié)構(gòu)，還不如找出系統(tǒng)開銷最集中的地方，只對(duì)那局部做優(yōu)化。預(yù)測(cè)軟件開銷集中在什么地方是困難的,進(jìn)行優(yōu)化最有效的方法是在系統(tǒng)運(yùn)行時(shí)使用性能監(jiān)測(cè)工具對(duì)系統(tǒng)進(jìn)行觀測(cè)。一些像繼承、動(dòng)態(tài)綁定、消息傳遞等處理雖然看起來(lái)簡(jiǎn)單，但需要大量的系統(tǒng)開銷;有的代碼看起來(lái)復(fù)雜，但效率不見得低。在代碼復(fù)雜性與運(yùn)行的低效之間沒(méi)有相關(guān)性。提高性能最好的方法是采用最出色的解決方案，而不是拼命地去節(jié)省幾個(gè)微秒、幾個(gè)字節(jié)。這個(gè)結(jié)論在面向?qū)ο蠹夹g(shù)出現(xiàn)是這樣，在面向?qū)ο箢I(lǐng)域仍然是這樣。ECS的PDC決定使用一個(gè)中央控制器〔電梯控制器〕控制和協(xié)調(diào)電梯的所有動(dòng)作，包括解決電梯每到一個(gè)樓層減速問(wèn)題。增加“電梯監(jiān)視器〞，用一個(gè)獨(dú)立的對(duì)象來(lái)執(zhí)行監(jiān)測(cè)功能〔性能、平安性等〕。在提交給實(shí)現(xiàn)者的規(guī)格說(shuō)明中，將這個(gè)類放在一個(gè)與ECS的主處理器別離的處理器上.每個(gè)類增加效勞SelfTest來(lái)增強(qiáng)每個(gè)類的性能。在運(yùn)行時(shí)執(zhí)行有必要驗(yàn)證其功能的操作，并向電梯監(jiān)視器報(bào)告。電梯馬達(dá)超載傳感器電梯調(diào)度器電梯控制器電梯監(jiān)視器電梯目的地面板面板到達(dá)面板樓層目的地事件召喚面板召喚事件到達(dá)事件電梯事件1111111,m11111111,m1,mECS問(wèn)題領(lǐng)域部分要點(diǎn)完整的未經(jīng)改動(dòng)的OOA模型將成為初始的OOD模型的PDC局部。根據(jù)實(shí)現(xiàn)技術(shù)及實(shí)現(xiàn)方面的限制，修改原始的PDC局部，但保存在OOA模型中所捕獲到的根本的系統(tǒng)行為，如果使用可復(fù)用的類，那么它也要引入到PDC中。由于性能、將來(lái)的復(fù)用、程序設(shè)計(jì)語(yǔ)言的限制、標(biāo)準(zhǔn)化等原因，可能還需要對(duì)PDC作出一些其他改動(dòng)。定義用戶界面設(shè)計(jì)一個(gè)良好的用戶界面是成功地實(shí)現(xiàn)一個(gè)軟件系統(tǒng)的關(guān)鍵.在開發(fā)OOA模型時(shí)，有意避開了如窗口、屏幕等依賴于實(shí)現(xiàn)的細(xì)節(jié)，目的是讓系統(tǒng)規(guī)格說(shuō)明獨(dú)立于實(shí)現(xiàn)。HIC局部在系統(tǒng)行為和用戶交互的實(shí)現(xiàn)之間架起了一座橋梁。例如，可用GUIHIC或語(yǔ)音對(duì)答式HIC實(shí)現(xiàn)用戶界面。ECS的HICECS的HIC由各種電梯按鈕、指示燈及它們的接口組成，不存在屏幕、窗口等用戶界面需要進(jìn)行設(shè)計(jì)。上行召喚按鈕下行召喚按鈕召喚按鈕目的地按鈕按鈕人機(jī)交互部分ECS的HIC由各種按鈕和指示燈對(duì)象組成。這些對(duì)象封裝了如何接收按鈕被按下的機(jī)制，以及如何激活指示燈的機(jī)制。

下行召喚指示燈召喚指示燈指示燈人機(jī)交互部分到達(dá)指示燈目的地指示燈

上行召喚指示燈例如，考慮召喚請(qǐng)求如何發(fā)生。在OOA模型中表達(dá)“當(dāng)召喚請(qǐng)求發(fā)生時(shí)，對(duì)象‘召喚事件’將向?qū)ο蟆賳久姘濉瘓?bào)告召喚事件的發(fā)生。〞等等。實(shí)際上，“召喚事件〞在它接收到從“召喚按鈕〞發(fā)送來(lái)的消息之前，根本就不理會(huì)周圍的任何事務(wù)。這個(gè)從“召喚按鈕〞發(fā)送來(lái)的消息是向類“召喚事件〞報(bào)告有一個(gè)召喚事件發(fā)生了?！罢賳臼录暤膱?zhí)行機(jī)制召喚事件召喚按鈕報(bào)告PDCHIC我們有一個(gè)召喚！總結(jié)每一個(gè)組織和用戶都有他的文化背景?？赡懿粌H僅意味著語(yǔ)言、傳統(tǒng)和習(xí)慣。由于所建立的系統(tǒng)面對(duì)的是用戶，因此，其界面必須必須與用戶的文化背景相一致。一種適應(yīng)用戶文化背景的有效方法是“直觀表示〞。其目的是讓人機(jī)界面適應(yīng)用戶。常用的直觀表示是預(yù)置一些用戶常用的標(biāo)準(zhǔn)形式，學(xué)習(xí)和掌握它非常簡(jiǎn)單和容易。使用用戶開發(fā)的場(chǎng)景或用況來(lái)驅(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,VasualBasic等，開發(fā)人員可能連HIC都不要。直接使用這些工具提供的控件，就可以作出用戶界面。

用戶可以不需要HIC，但不能免去用戶界面的設(shè)計(jì)。使用菜單樹或狀態(tài)-遷移圖，連同某些原型，來(lái)說(shuō)明用戶界面的設(shè)計(jì)思想。任務(wù)管理問(wèn)題在應(yīng)用中，每一個(gè)對(duì)象中的每一個(gè)效勞最終都要被分配給某一個(gè)計(jì)算機(jī)任務(wù)。這樣一些任務(wù)可以被看作是一些獨(dú)立的可調(diào)度的實(shí)體。在ECS系統(tǒng)中有大量的系統(tǒng)必須對(duì)其響應(yīng)的異步事件。下面將介紹ECSOOD模型的任務(wù)管理局部〔TMC〕。首先，要標(biāo)識(shí)一些新的類，這些類建立后將負(fù)責(zé)處理并發(fā)、中斷、調(diào)度〔在操作系統(tǒng)級(jí)〕以及其他有關(guān)特定平臺(tái)的一些問(wèn)題.TMC把與特定硬/軟件平臺(tái)有關(guān)的處理機(jī)制封裝在自己內(nèi)部，對(duì)系統(tǒng)的其他局部隱藏起來(lái)，一旦決定將ECS移植到另一個(gè)平臺(tái)上時(shí)，只需替換TMC中的類就可以了。為建立TMC，首先要找出可能被封裝在TMC類中那些與特定平臺(tái)有關(guān)的局部。還要找出任務(wù)協(xié)調(diào)局部，通信的發(fā)、收關(guān)系，處理器的分配〔客戶-效勞器〕或者消息/線程序列等。ECS的類與對(duì)象考察ECSOOA/OOD工作表格,可以發(fā)現(xiàn)中斷處理和存放器訪問(wèn)是設(shè)計(jì)需求的重要局部。中斷召喚按鈕中斷目的地按鈕中斷到達(dá)中斷電梯就緒中斷寄存器輸入寄存器輸出寄存器可以用一個(gè)類的集合來(lái)表示以上的中斷和存放器訪問(wèn)類。與事件–響應(yīng)模型中其他事件不同，超載事件沒(méi)有相應(yīng)的中斷，故沒(méi)有“超載中斷〞類。在設(shè)計(jì)中采用輪詢超載傳感器的方式產(chǎn)生超載事件。下面完整地說(shuō)明一下召喚事件的機(jī)制。當(dāng)召喚按鈕被按下時(shí)〔在ECS之外〕，產(chǎn)生了一個(gè)中斷，終止正在運(yùn)行的程序。同時(shí)一個(gè)二進(jìn)制數(shù)存儲(chǔ)到輸入存放器中?！罢賳臼录暤膱?zhí)行機(jī)制召喚事件召喚按鈕PDCHIC我們有一個(gè)召喚！TMC召喚中斷輸入寄存器按下按鈕召喚按鈕共78個(gè)〔除第1層和第40層各有1個(gè)外，其他每層各有2個(gè)〕。向下的召喚按鈕編號(hào)為奇數(shù)，向上的召喚按鈕編號(hào)為偶數(shù)。零表示當(dāng)前沒(méi)有按下按鈕。因此，存入輸入存放器中的二進(jìn)制數(shù)的范圍是00000000,00000010-01001111。一旦按下召喚按鈕，第一個(gè)反響是“召喚中斷〞類被喚醒，并報(bào)告“我接收到一個(gè)召喚〞。相應(yīng)的“召喚中斷〞對(duì)象就向“輸入存放器〞對(duì)象發(fā)送一個(gè)消息,詢問(wèn)輸入存放器的當(dāng)前值.中斷優(yōu)先級(jí)規(guī)定這個(gè)值只能由“召喚中斷〞對(duì)象獲取.這個(gè)“召喚中斷〞對(duì)象向類“召喚按鈕〞發(fā)送一個(gè)消息，告訴它：你的一個(gè)按鈕按下了。類“召喚按鈕〞封裝了如何將存放器值轉(zhuǎn)換為按鈕號(hào)碼的機(jī)制，它通知相應(yīng)“召喚按鈕〞對(duì)象：你被按下了，你要開始工作了?！罢賳景粹o〞對(duì)象向類“召喚事件〞發(fā)送一個(gè)消息，然后開始進(jìn)行事件的處理。封裝需要做許多工作，這些開銷是必要的。如決定增加第三個(gè)按鈕用于召喚運(yùn)貨電梯，只需改動(dòng)一個(gè)類“召喚按鈕〞即可，而系統(tǒng)其他局部可一概不予改動(dòng)。數(shù)據(jù)庫(kù)設(shè)計(jì)在ECS中沒(méi)有數(shù)據(jù)管理局部，所有在對(duì)象中存儲(chǔ)的數(shù)據(jù)都駐留在內(nèi)存中。DMC說(shuō)明了對(duì)系統(tǒng)生成的永久數(shù)據(jù)的訪問(wèn)和管理，這些數(shù)據(jù)將可以在設(shè)計(jì)的其他局部中使用。之所以將數(shù)據(jù)庫(kù)管理技術(shù)從OODPDC中別離出來(lái)，是為了將來(lái)更換DBMS時(shí)可以只修改DMC讓系統(tǒng)其他局部可一概不動(dòng)。創(chuàng)立DMC的最簡(jiǎn)單的策略就是請(qǐng)求。但這不一定是唯一的，也不一定是最好的。標(biāo)準(zhǔn)可復(fù)用性可理解性可以用一個(gè)簡(jiǎn)單的場(chǎng)景說(shuō)明在一個(gè)基于對(duì)象的系統(tǒng)中可能需要大量的通信和協(xié)調(diào)工作。這個(gè)代價(jià)必須付出，以獲取復(fù)用性、可維護(hù)性、可擴(kuò)展性等優(yōu)點(diǎn)。設(shè)計(jì)級(jí)的質(zhì)量問(wè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ì)通過(guò)泛化–特化或整體–局部層次結(jié)構(gòu)產(chǎn)生。這要通過(guò)內(nèi)聚性準(zhǔn)那么來(lái)衡量。內(nèi)聚性準(zhǔn)那么——描述系統(tǒng)組成中各元素的關(guān)聯(lián)度或強(qiáng)度。應(yīng)盡量防止內(nèi)聚性低。在面向?qū)ο笤O(shè)計(jì)時(shí)，從3個(gè)層次來(lái)考察內(nèi)聚性：?jiǎn)蝹€(gè)效勞的內(nèi)聚性；封裝在類和對(duì)象中的數(shù)據(jù)和效勞的內(nèi)聚性；整個(gè)類的層次結(jié)構(gòu)的內(nèi)聚性。從微觀的層次上，對(duì)效勞的內(nèi)聚性評(píng)價(jià)與結(jié)構(gòu)化設(shè)計(jì)中的相同：一個(gè)效勞應(yīng)只執(zhí)行一個(gè)功能；在類層次結(jié)構(gòu)這一級(jí)上，可以通過(guò)檢查子類重載或刪除從它們的父類中繼承的屬性和效勞的多少來(lái)進(jìn)行評(píng)價(jià)。重點(diǎn)在于設(shè)計(jì)的明確性——看不懂OOD設(shè)計(jì)，就無(wú)法復(fù)用它。建議：命名屬性和效勞的詞要求前后一致；防止使用過(guò)多的消息模板；不要對(duì)類的定義摸棱兩可，遵從類的現(xiàn)有協(xié)議或行為。層次結(jié)構(gòu)和因子分解準(zhǔn)那么類的層次結(jié)構(gòu)不要太深，也不要太淺。一個(gè)約有100個(gè)類的中等規(guī)模的系統(tǒng)中，泛化–特化結(jié)構(gòu)和整體–局部結(jié)構(gòu)的層次大概有72層。影響層次的因素有程序設(shè)計(jì)語(yǔ)言、用單繼承還是多繼承等。保持類和對(duì)象的簡(jiǎn)單性平均起來(lái)，每個(gè)效勞所使用的屬性不應(yīng)超過(guò)1~2個(gè)，而且有2／3應(yīng)當(dāng)能夠追溯到OOA模型。除了處理內(nèi)部事務(wù)所用的私有效勞外，類所具有的公共效勞不應(yīng)多于6~7個(gè)。對(duì)象之間的耦合不能過(guò)多。一個(gè)對(duì)象可能自己不能響應(yīng)一個(gè)外部事件，但它不能與多于72個(gè)對(duì)象交互來(lái)完成某件事情。保持消息協(xié)議的簡(jiǎn)單性——復(fù)雜的消息協(xié)議常常意味著在類或?qū)ο笾g有很強(qiáng)的耦合。一個(gè)消息需要的參數(shù)不多于3個(gè)，否那么是對(duì)類的層次結(jié)構(gòu)沒(méi)有做很好的分解。保持效勞的簡(jiǎn)單性——使用某種高級(jí)語(yǔ)言編寫程序代碼，盡可能把為每個(gè)效勞所編寫的代碼限制在一頁(yè)紙之內(nèi)。使用Smalltalk語(yǔ)言，每個(gè)效勞的代碼行數(shù)通常不超過(guò)10行。將設(shè)計(jì)的易變性降到最低——一個(gè)差的設(shè)計(jì)會(huì)在工程的開發(fā)過(guò)程中或在日后的維護(hù)工作中顯示出一定的易變性。例如，為改正軟件缺陷，對(duì)一個(gè)類作一些小改動(dòng)，或者在軟件中增加一個(gè)新的特性，都會(huì)在許多其他類中引起一連串的反響。利用配置管理，可以對(duì)類的變更及變更時(shí)的影響進(jìn)行跟蹤和分析，檢測(cè)工程穩(wěn)定性。系統(tǒng)整體規(guī)模的最小化——系統(tǒng)規(guī)模越大越不好。中型應(yīng)用的類層次不應(yīng)超過(guò)幾十個(gè)，每個(gè)類所包含的子類只應(yīng)有十幾個(gè)左右。重視場(chǎng)景評(píng)價(jià)的能力——評(píng)價(jià)一個(gè)設(shè)計(jì)的好壞可以通過(guò)執(zhí)行各個(gè)類和對(duì)象的行為來(lái)實(shí)現(xiàn)。如果無(wú)法做行為的測(cè)試，說(shuō)明各個(gè)類的職責(zé)沒(méi)有描述清楚，或沒(méi)有考慮清楚。利用以上準(zhǔn)那么來(lái)檢查ECS的OOD設(shè)計(jì)，看是否有需要改進(jìn)的地方。例如觀察對(duì)象之間的協(xié)同情況，檢查對(duì)象之間傳遞大而復(fù)雜的數(shù)據(jù)結(jié)構(gòu)(差耦合)在對(duì)象之間進(jìn)行長(zhǎng)距離接力傳遞的數(shù)據(jù)檢查對(duì)象中的效勞，看封裝機(jī)制是否完全。檢查繼承的層次結(jié)構(gòu)，確保父類不依賴子類。檢查父類與子類之間的消息通信。通過(guò)檢查，了解當(dāng)前的層次結(jié)構(gòu)的狀況，開掘出更好的層次結(jié)構(gòu)。最后檢查OOD的命名約定。這些名字是否與對(duì)象的數(shù)據(jù)和效勞相符？如果不符，為什么不符？事例分析系統(tǒng)的質(zhì)量問(wèn)題良好的設(shè)計(jì)來(lái)自于良好的分析。一個(gè)好的設(shè)計(jì)是從預(yù)分析技術(shù)開始的。從產(chǎn)生的OOA/OOD模型來(lái)看，幾乎所有的對(duì)象都是高內(nèi)聚、低耦合的。因?yàn)樗鼈兪窃趯?duì)應(yīng)用領(lǐng)域概念進(jìn)行基于語(yǔ)言的分析后產(chǎn)生的。ECS系統(tǒng)的大局部設(shè)計(jì)簡(jiǎn)單明了，對(duì)象包含了數(shù)量合理的屬性和效勞，耦合性和內(nèi)聚性也很好。但在作出決策建立集中控制的“控制器〞和“調(diào)度〞類時(shí)存在一些問(wèn)題。為提高效率和調(diào)度，降低了許多類的可復(fù)用性。關(guān)于OOA模型的文檔編制和評(píng)審過(guò)程方面的大局部說(shuō)明也同樣適用于OOD模型，一個(gè)明顯的區(qū)別那么在于OOD模型的文檔所面對(duì)的對(duì)象是設(shè)計(jì)人員和實(shí)現(xiàn)人員，而不是用戶。OOD模型的文檔好比建筑師設(shè)計(jì)出來(lái)的建筑樓房用的藍(lán)圖，應(yīng)具有詳細(xì)的細(xì)節(jié)。其詳細(xì)程度應(yīng)當(dāng)能讓實(shí)現(xiàn)系統(tǒng)的人清楚地知道他們所要建立的系統(tǒng)到底是一個(gè)什么樣的系統(tǒng)。設(shè)計(jì)模型的文檔各個(gè)工程要求的詳細(xì)程度各不相同。最重要的是看實(shí)現(xiàn)人員是誰(shuí)。在小規(guī)模的工程中，實(shí)現(xiàn)人員就是設(shè)計(jì)人員。這時(shí)，幾乎不要求或很少要求設(shè)計(jì)文檔。如果設(shè)計(jì)人員在某一個(gè)大陸上，而實(shí)現(xiàn)人員在另一個(gè)大陸上，就需要大量細(xì)節(jié)的說(shuō)明。不同的工程可能有不同的文檔標(biāo)準(zhǔn)需求。為了更好地描述OOD模型，可以使用任何類型的圖形表示工具或其他規(guī)格說(shuō)明。在與實(shí)現(xiàn)人員就設(shè)計(jì)進(jìn)行通信時(shí)，這些圖形表示和規(guī)格說(shuō)明是很有用的。我們希望將所開發(fā)的用戶界面屏幕放到設(shè)計(jì)文檔中。對(duì)于某些系統(tǒng)時(shí)序圖、算法規(guī)格說(shuō)明、圖解、統(tǒng)計(jì)–預(yù)報(bào)曲線、電子數(shù)據(jù)表格、流程圖等，都可以放在設(shè)計(jì)文檔中。設(shè)計(jì)評(píng)審過(guò)程是一個(gè)持續(xù)進(jìn)行的過(guò)程，與工程組織的文化背景有關(guān)，與正式的里程碑評(píng)審過(guò)程不同。事件、場(chǎng)景、使用事例的概念是設(shè)計(jì)評(píng)審的依據(jù)。為了識(shí)別事件并產(chǎn)生相應(yīng)的響應(yīng)，必須給出所有的設(shè)計(jì)。結(jié)論是：如果在一個(gè)給定的設(shè)計(jì)中說(shuō)明了所有的系統(tǒng)事件和響應(yīng)，那么這個(gè)系統(tǒng)就一定能成功！實(shí)現(xiàn)方面的問(wèn)題程序設(shè)計(jì)語(yǔ)言的考慮以往談到復(fù)用，總是想到代碼復(fù)用?，F(xiàn)在談復(fù)用時(shí)，是指復(fù)用事務(wù)規(guī)那么、需求、環(huán)境、文件、體系結(jié)構(gòu)、測(cè)試方案等。事實(shí)上，軟件工程生存期內(nèi)所有的工作結(jié)果都可以被復(fù)用。面向?qū)ο笫且环N先進(jìn)的技術(shù)，它使得可以復(fù)用的東西遠(yuǎn)遠(yuǎn)超過(guò)了代碼?？梢允褂梅敲嫦?qū)ο蟪绦蛘Z(yǔ)言實(shí)現(xiàn)面向?qū)ο蟪绦颉＠碛墒牵涸S多老程序員對(duì)面向?qū)ο蟛皇煜ぃ麄兞私鈽I(yè)務(wù)和事務(wù)規(guī)那么。以前遺留下來(lái)的大量程序代碼全部重寫是不明智的。每個(gè)工程都有自己獨(dú)特的應(yīng)用環(huán)境。有些工程不可能將程序轉(zhuǎn)換為面向?qū)ο蟮某绦?。?duì)于面向微處理器的嵌入的、實(shí)時(shí)的程序，只能用普通的匯編語(yǔ)言編寫程序。有的人只學(xué)習(xí)了C++的語(yǔ)法，而沒(méi)有學(xué)習(xí)任何有關(guān)面向?qū)ο蟮拈_發(fā)模式。其結(jié)果就是自頂向下，從功能上分解對(duì)象。所以應(yīng)首先在OOA和OOD方面對(duì)程序員進(jìn)行培訓(xùn)。一個(gè)迭代的軟件開發(fā)過(guò)程任何一個(gè)軟件系統(tǒng)的分析和設(shè)計(jì)都是在整個(gè)軟件開發(fā)過(guò)程的上下文環(huán)境中執(zhí)行的。開發(fā)過(guò)程會(huì)影響對(duì)象技術(shù)。但總的說(shuō)來(lái)，開發(fā)過(guò)程獨(dú)立于開發(fā)環(huán)境或開發(fā)過(guò)程。如果一個(gè)工程的各個(gè)階段和工作成果在一個(gè)可控制的和可管理的方式下可以重做，那么這樣的軟件開發(fā)過(guò)程就是一個(gè)迭代的過(guò)程。對(duì)于一個(gè)大而復(fù)雜的軟件系統(tǒng)，采用迭代的軟件開發(fā)過(guò)程非常重要。以下圖給出一個(gè)通用的迭代的軟件開發(fā)過(guò)程，這個(gè)過(guò)程稱為基于線程的開發(fā)過(guò)程。圖中的各種活動(dòng)并不是以瀑布流水的方式組織起來(lái)的。這些活動(dòng)進(jìn)行了一次又一次。用于履行這種迭代的機(jī)制就是線程。從概念上，可以認(rèn)為線程就是事件的分片實(shí)現(xiàn)。預(yù)分析活動(dòng)各種需求定義,建模OOAOODGUIOOPDeploy-ment預(yù)分析工作產(chǎn)品(OOA工作表格,E/R,初始GUI布局)初始GUI布局(包括各種功能定義,數(shù)據(jù)定義等。)基本模型圖形用戶界面設(shè)計(jì)OOD工作表格分配各需種求實(shí)現(xiàn)設(shè)計(jì)模型產(chǎn)品各種軟件需求其他信息,文獻(xiàn),手冊(cè),類似產(chǎn)品等支持包括：追蹤能力矩陣,配置管理,各種管理報(bào)告,各種度量等文檔項(xiàng)目數(shù)據(jù)庫(kù)在實(shí)現(xiàn)時(shí)，線程可以是系統(tǒng)的一個(gè)工作片段?？梢哉J(rèn)為系統(tǒng)一次在執(zhí)行一個(gè)線程。優(yōu)點(diǎn)：很多問(wèn)題，如誤解了用戶要求或技術(shù)缺陷等，能夠在開發(fā)過(guò)程的早期被暴露出來(lái)。以下圖描述了工程開發(fā)組在某一天根據(jù)迭代的開發(fā)過(guò)程進(jìn)行的活動(dòng)。首先，根據(jù)所標(biāo)識(shí)的需求和工程方案，選擇出當(dāng)天所要實(shí)現(xiàn)的線程，再開會(huì)討論?？赡芴岢龅木€程中有一些不能實(shí)現(xiàn)，這些線程就需要修改，或者對(duì)需求提出質(zhì)疑。最后，用戶要求中不能實(shí)現(xiàn)的局部要重新商定。初始線程標(biāo)識(shí)需求選擇一個(gè)線程將線程標(biāo)記于矩陣中與開發(fā)組會(huì)商要更改RDM嗎？要建立或修改線程嗎？修改RDM基于線程的實(shí)現(xiàn)流程圖然后將所驗(yàn)收的線程交給開發(fā)組，一個(gè)組負(fù)責(zé)設(shè)計(jì)用戶界面，一個(gè)組負(fù)責(zé)面向?qū)ο蠼?。兩個(gè)組完成設(shè)計(jì)后，線程的設(shè)計(jì)交給實(shí)現(xiàn)組，他們將其快速實(shí)現(xiàn)，解決所發(fā)現(xiàn)的問(wèn)題。一天結(jié)束時(shí)，工程開發(fā)組對(duì)這天實(shí)現(xiàn)的線程進(jìn)行評(píng)審。評(píng)審使用系統(tǒng)的一個(gè)實(shí)際可以運(yùn)行的版本，將所實(shí)現(xiàn)的線程納入該版本。有些線程可以接受，有些現(xiàn)成需要重做。在一段時(shí)期內(nèi)所實(shí)現(xiàn)的線程構(gòu)成最終產(chǎn)品的一個(gè)不完整版本。將線程分布到各組產(chǎn)生實(shí)現(xiàn)方案評(píng)審線程需要產(chǎn)生數(shù)據(jù)庫(kù)嗎？線程可接受嗎？產(chǎn)生數(shù)據(jù)庫(kù)實(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)境。用這些RAD工具開發(fā)應(yīng)用程序，其優(yōu)點(diǎn)在于復(fù)用和可維護(hù)性。原因在于RAD工具通常不支持事物別離規(guī)那么。就是說(shuō)，它們可以將事務(wù)規(guī)那么、用戶界面技術(shù)以及數(shù)據(jù)庫(kù)訪問(wèn)技術(shù)等集成在單個(gè)單元之中〔如VisualBasic表格〕。由于它以快速系統(tǒng)展開為根底，因而RAD工具的本錢是合理的。使用RAD工具，應(yīng)當(dāng)遵守根本的面向?qū)ο箝_發(fā)模式。需要有工程標(biāo)準(zhǔn)和開發(fā)人員守那么。將所有的問(wèn)題領(lǐng)域局部中的對(duì)象映射到RAD局部中，稱之為“RAD對(duì)象〞。使所有的系統(tǒng)邏輯都包含在其中。這種實(shí)現(xiàn)獨(dú)立于用戶界面和數(shù)據(jù)庫(kù)問(wèn)題。所有人機(jī)交互局部中的對(duì)象應(yīng)作為RAD的屏幕和表格實(shí)現(xiàn)。這局部可能不封裝事務(wù)規(guī)那么或數(shù)據(jù)庫(kù)訪問(wèn)規(guī)那么，屏幕和表格只與RAD對(duì)象通信。所有的數(shù)據(jù)庫(kù)接口都通過(guò)RAD對(duì)象實(shí)現(xiàn)。對(duì)象的屬性和效勞都是由RAD工具提供的程序設(shè)計(jì)語(yǔ)言的變量和子程序。RAD對(duì)象之間的消息傳遞都通過(guò)函數(shù)或子程序調(diào)用來(lái)完成。實(shí)例連接、泛化-特化關(guān)系、整體-局部關(guān)系由RAD對(duì)象間的共享變量實(shí)現(xiàn)。對(duì)基于對(duì)象的設(shè)計(jì)進(jìn)行測(cè)試將系統(tǒng)級(jí)測(cè)試與對(duì)象級(jí)測(cè)試區(qū)分開是很重要的。下面就前面介紹的分析和設(shè)計(jì)技術(shù)的范圍內(nèi)進(jìn)行討論。

黑盒測(cè)試這種測(cè)試基于系統(tǒng)級(jí)的規(guī)格說(shuō)明。規(guī)格說(shuō)明包括需求定義模型、事件－響應(yīng)模型和用戶界面規(guī)格說(shuō)明。黑盒測(cè)試的目的是要確認(rèn)功能的執(zhí)行與規(guī)格說(shuō)明相一致。測(cè)試的最有效方法是建立應(yīng)用領(lǐng)域的場(chǎng)景(即使用實(shí)例)。從用戶角度捕捉系統(tǒng)行為。黑盒測(cè)試必須要有實(shí)際用戶，最好是在一個(gè)真實(shí)世界的環(huán)境中進(jìn)行。系統(tǒng)級(jí)的測(cè)試黑盒測(cè)試需要兩類測(cè)試人員：一類是熟悉開發(fā)方法的人，他們能夠看懂各種圖表、符號(hào)；另一類是用戶，他們對(duì)用戶界面最有發(fā)言權(quán)。黑盒測(cè)試的優(yōu)點(diǎn)是不需要特殊的測(cè)試環(huán)境。在普通開發(fā)環(huán)境中利用發(fā)布前的各種結(jié)果就可以做。但需要說(shuō)明的是，要保存所有測(cè)試的日志和記錄。白盒測(cè)試基于各種設(shè)計(jì)文檔中所定義的內(nèi)部系統(tǒng)結(jié)構(gòu)。這些文檔包括EROI圖、OOA和OOD模型以及GUI設(shè)計(jì)文檔等。在EROI圖中定義的類所能識(shí)別的每一個(gè)事件都必須經(jīng)過(guò)驗(yàn)證。各個(gè)類之間的協(xié)同，以及EROI圖中所定義的對(duì)事件的響應(yīng)也必須經(jīng)過(guò)驗(yàn)證。這種驗(yàn)證不包括效勞級(jí)的測(cè)試。因?yàn)樗鼘儆趯?duì)象級(jí)測(cè)試?？偟膩?lái)講，白盒測(cè)試是在相關(guān)的黑盒測(cè)試完成之后進(jìn)行的。白盒測(cè)試最好由不屬于該工程組織的人來(lái)做。要求執(zhí)行白盒測(cè)試的人熟悉開發(fā)環(huán)境和設(shè)計(jì)方法，對(duì)應(yīng)用領(lǐng)域的知識(shí)不是必須的。由一個(gè)工程組的成員來(lái)測(cè)試另一個(gè)工程組的工作成果，往往是很有效的。白盒測(cè)試的準(zhǔn)備工作由一個(gè)獨(dú)立的小組完成。首先建立測(cè)試環(huán)境。其次，要求能夠訪問(wèn)軟件的消息、屬性，及其他軟件成分。這種測(cè)試環(huán)境應(yīng)當(dāng)有助于維護(hù)所有已完成的測(cè)試的日志和記錄。事實(shí)上，這些日志和記錄可能會(huì)建立某種與合同有關(guān)的里程碑。對(duì)象級(jí)的測(cè)試對(duì)象級(jí)測(cè)試獨(dú)立于任何特定的應(yīng)用系統(tǒng)。由于對(duì)象可以在許多不同的應(yīng)用程序中復(fù)用，因此必須在通用的復(fù)用環(huán)境中執(zhí)行。對(duì)象級(jí)黑盒測(cè)試對(duì)每一個(gè)對(duì)象進(jìn)行的黑盒測(cè)試是通過(guò)一個(gè)對(duì)象級(jí)的測(cè)試臺(tái)來(lái)完成的。這個(gè)測(cè)試臺(tái)能夠讓對(duì)象接收消息，并能對(duì)所生成的消息進(jìn)行顯示、捕捉和分析。黑盒測(cè)試應(yīng)當(dāng)由開發(fā)組進(jìn)行。這種測(cè)試要求在消息的源端或目的端用虛擬的樁(stub)操作代替實(shí)際的源端效勞或目的端效勞，以便獨(dú)立地對(duì)每個(gè)效勞進(jìn)行測(cè)試。每個(gè)對(duì)象還應(yīng)帶有一個(gè)用戶手冊(cè)，這個(gè)用戶手冊(cè)中的對(duì)象描述應(yīng)獨(dú)立于任何特定應(yīng)用。它是黑盒測(cè)試的根底。對(duì)象級(jí)的白盒測(cè)試對(duì)象級(jí)的白盒測(cè)試也是由開發(fā)組完成的。該測(cè)試主要是對(duì)所有的效勞及其組成局部進(jìn)行檢查，以確認(rèn)它們與效勞的規(guī)格說(shuō)明和屬性定義是一致的。該測(cè)試要求使用特定的測(cè)試平臺(tái)，測(cè)試平臺(tái)能將所要測(cè)試的對(duì)象從其他對(duì)象中別離出來(lái)，從而獨(dú)立于其他對(duì)象和應(yīng)用環(huán)境。轉(zhuǎn)向面向?qū)ο蠓椒ㄓ捎谔峤淮蠖鴱?fù)雜的軟件系統(tǒng)所造成的在預(yù)算和進(jìn)度上不斷增加的壓力，促使許多開發(fā)機(jī)構(gòu)從當(dāng)前傳統(tǒng)的軟件開發(fā)方法倉(cāng)促地轉(zhuǎn)向面向?qū)ο蠓椒?。我們給出12個(gè)步驟，幫你轉(zhuǎn)向面向?qū)ο蟮姆椒?。我們不能保證這些步驟很容易實(shí)現(xiàn)，但按這些步驟認(rèn)真去做，肯定不會(huì)失敗。步驟1：接受必然發(fā)生的事情不遠(yuǎn)的將來(lái)，面向?qū)ο蠓椒▽?huì)在各種軟件開發(fā)方法中占據(jù)統(tǒng)治地位：在質(zhì)量和產(chǎn)量方面它占有巨大的潛能；經(jīng)銷商的支持正在迅速增長(zhǎng)；第一批采納面向?qū)ο蠓椒ǖ膱F(tuán)體正在顯示他們的成功；許多重要的標(biāo)準(zhǔn)正在制定中，有些已公布；接受這些必然發(fā)生的事情，在思想上建立起這些概念，這是通向成功的關(guān)鍵因素。沒(méi)有回頭路可走。步驟2：理解，理解，還是理解轉(zhuǎn)向面向?qū)ο蟮脑颉獜?fù)用(Reuse)。復(fù)用能帶來(lái)高的投資回報(bào)率(48個(gè)月后達(dá)30:1)。進(jìn)行復(fù)用不一定非用面向?qū)ο蠓椒?，但面向?qū)ο蠓椒苁箯?fù)用成為可能。面向?qū)ο蠓椒ㄋ鶐?lái)的收益將在下一個(gè)工程中得到。也許可能要到再下一個(gè)工程。轉(zhuǎn)向面向?qū)ο蟮倪^(guò)程有兩種觀點(diǎn)：逐漸演變或全新變革。必須了解哪種方式適合自己。對(duì)大多數(shù)人來(lái)講，完全拋棄以前的所有成果從頭開始是一種很愚蠢的做法。步驟3：對(duì)財(cái)產(chǎn)進(jìn)行評(píng)估在評(píng)估軟件開發(fā)過(guò)程時(shí)，要識(shí)別和區(qū)分工作產(chǎn)品和人工制品。工作產(chǎn)品是指作為特定工程的里程碑應(yīng)當(dāng)提交的成果；人工制品是指在開發(fā)過(guò)程中產(chǎn)生的不交付的成果，如數(shù)據(jù)流圖、結(jié)構(gòu)圖等。這些人工制品應(yīng)成為面向?qū)ο筮^(guò)程的一局部。還需要評(píng)估人力資源。然后擬訂過(guò)渡方案，標(biāo)識(shí)出新的面向?qū)ο蠊ぷ鳟a(chǎn)品和支持這些工作產(chǎn)品的人工制品，將這些對(duì)應(yīng)到當(dāng)前的過(guò)程中。步驟4：標(biāo)識(shí)一個(gè)“共生工程〞(Symbioject)如果對(duì)一個(gè)新的陌生的技術(shù)沒(méi)有充分了解，沒(méi)有弄清它對(duì)工程、組織和人員有什么影響之前，貿(mào)然使用它開發(fā)一個(gè)重大工程是非常莽撞的。理想的做法是先上一個(gè)試驗(yàn)性的工程，它與負(fù)有重大任務(wù)的工程有共生關(guān)系，可能就是那個(gè)工程的一局部。利用這個(gè)試驗(yàn)性工程，學(xué)習(xí)新技術(shù)、新方法。優(yōu)點(diǎn)是可以減少引入一個(gè)新技術(shù)所帶來(lái)的風(fēng)險(xiǎn)，有助于將某些新技術(shù)應(yīng)用到主流工程中。步驟5：建立有意義的度量研究證明，在一個(gè)成功的工程中，預(yù)期完成工作的百分比與實(shí)際完成工作的百分比十分接近。這說(shuō)明，成功的工程可以監(jiān)控。良好監(jiān)控的關(guān)鍵在于微度量，即對(duì)進(jìn)度、質(zhì)量、效率等的度量。一種好的度量是監(jiān)控每人每個(gè)單位時(shí)間的