軟件工程(研)復(fù)習(xí)提綱答案VIP

1、.復(fù)習(xí)提綱第一章軟件工程概述1、分析 60 年代末出現(xiàn)的軟件危機(jī)的原因。如何理解“越早潛伏的錯(cuò)誤越晚發(fā)現(xiàn)，越晚發(fā)現(xiàn)的錯(cuò)誤，修正的費(fèi)用越高”。答：軟件危機(jī)是指在軟件開(kāi)發(fā)過(guò)程中遇到的一系列嚴(yán)重問(wèn)題，如：開(kāi)發(fā)周期延長(zhǎng)，成本增加，可靠性降低等。開(kāi)發(fā)大型軟件與編制小程序主要有以下區(qū)別：人員：小程序從確定要求、設(shè)計(jì)、編制、使用，直到維護(hù)通常由一個(gè)人完成；大型軟件則由用戶、項(xiàng)目負(fù)責(zé)人、分析員、程序員、資料員、操作員等組成一支開(kāi)發(fā)隊(duì)伍來(lái)協(xié)同完成。文檔：小程序很少有書面文檔；大型軟件則是集體勞動(dòng)的“產(chǎn)物”，必須有規(guī)化的文檔，便于開(kāi)發(fā)和維護(hù)。產(chǎn)品。小程序工作量小，如果需作大的修改，可舍棄舊程序而重新編寫；但大型軟

2、件的開(kāi)發(fā)耗費(fèi)了大量的人力與物力， 一般不會(huì)輕易拋棄， 而總是在舊軟件的基礎(chǔ)上一再改動(dòng)，以延長(zhǎng)它的使用期，因此“版本”在不斷升級(jí)。大型軟件的開(kāi)發(fā)提出了許多新的問(wèn)題，而開(kāi)發(fā)方法卻還停留在編制小程序的方法上，經(jīng)驗(yàn)和技巧已不能滿足開(kāi)發(fā)大型軟件的需要， 導(dǎo)致軟件開(kāi)發(fā)過(guò)程混亂； 使用的開(kāi)發(fā)方法和技術(shù)不當(dāng)， 沒(méi)有適當(dāng)?shù)奈臋n， 不易交流， 維護(hù)困難， 開(kāi)發(fā)成本高， 軟件質(zhì)量低等，這些問(wèn)題是造成軟件危機(jī)的主要原因。2、軟件復(fù)用的概念及兩類軟件復(fù)用技術(shù)：合成技術(shù)和生成技術(shù)。答：軟件復(fù)用是指在構(gòu)造新的軟件系統(tǒng)過(guò)程中，對(duì)已存在的軟件產(chǎn)品(設(shè)計(jì)結(jié)構(gòu)、源代碼、文檔等 )重復(fù)使用的技術(shù)。(1)合成技術(shù)利用部件 (compo

3、nent,組件，構(gòu)件 )合成軟件系統(tǒng)的技術(shù)。部件是可復(fù)用的一小段軟件(可為二進(jìn)制形式) ，可以是對(duì)某一函數(shù)、過(guò)程、子程序、數(shù)據(jù)類型、算法等可復(fù)用軟件成分的抽象，封裝了功能細(xì)節(jié)和數(shù)據(jù)結(jié)構(gòu)，有詳細(xì)的接口。(2) 生成技術(shù)利用可復(fù)用的模式， 通過(guò)生成程序產(chǎn)生一個(gè)新的程序或程序段， 產(chǎn)生的程序可以看成是模式的實(shí)例?？蓮?fù)用的模式有兩種：代碼模式和規(guī)則模式。代碼模式可復(fù)用的代碼模式存在于應(yīng)用生成器中， 通過(guò)特定的參數(shù)替換， 生成抽象軟件模塊的具體實(shí)體。各種程序生成器。Word 資料.規(guī)則模式利用程序變換系統(tǒng)， 把用超高級(jí)規(guī)格說(shuō)明語(yǔ)言編寫的程序轉(zhuǎn)化成某種可執(zhí)行語(yǔ)言的程序。 IDL CORBA 的接口定義語(yǔ)言

4、。第二章 需求分析工程3、簡(jiǎn)述需求分析工程的重要性。答： (1)在軟件生命周期中，一個(gè)錯(cuò)誤發(fā)現(xiàn)越晚，修復(fù)錯(cuò)誤的費(fèi)用越高。(2) 許多錯(cuò)誤是潛伏的，且在錯(cuò)誤產(chǎn)生后很長(zhǎng)一段時(shí)間才被檢測(cè)出。(3) 需求分析中會(huì)產(chǎn)生大量錯(cuò)誤。(4) 需求分析中的錯(cuò)誤多為疏忽、不一致和二義性。(5) 需求錯(cuò)誤是可以被檢測(cè)出來(lái)的。4、掌握和分析 Petri 網(wǎng)的有關(guān)問(wèn)題；會(huì)用可達(dá)樹(shù)分析死鎖問(wèn)題。分析餓死現(xiàn)象并改進(jìn) 。答： Petri 網(wǎng)的局限性1、令牌缺乏表示信息容的能力令牌只是表示動(dòng)作控制的流向，無(wú)法表達(dá)信息的容。2、缺乏描述選擇“使能”變遷的策略3、 Petri 網(wǎng)不能描述有定時(shí)要求的計(jì)算問(wèn)題，而很多系統(tǒng)的定時(shí)問(wèn)題則

5、很重要。用可達(dá)樹(shù)分析死鎖問(wèn)題：若出現(xiàn)葉結(jié)點(diǎn)，則系統(tǒng)中有死鎖。Word 資料.分析餓死現(xiàn)象并改進(jìn)：P1P2t 1t 2P3P4tP6tP5t 43P75t 6圖中存在激發(fā)序列 <t1,t3,t5> 無(wú)限循環(huán)，而 <t2,t4,t6> 被“餓死”，原因是 Petri 網(wǎng)不能描述選擇策略。修改 Petri 網(wǎng)，強(qiáng)制它使用一種選擇策略，避免了t3 在 t4 激發(fā)之前激發(fā)兩次。如下圖：Word 資料.5、分析、理解電梯運(yùn)動(dòng)的Petri 網(wǎng)。PPT 第二章 49按下tmin (C)=0.05tmax (C)=0.05t min =0.1Word 資料.Word 資料.第三章軟件開(kāi)發(fā)

6、的結(jié)構(gòu)化方法6、傳統(tǒng)的瀑布模型將軟件開(kāi)發(fā)分為幾個(gè)步驟，每一步得到什么結(jié)果。問(wèn)題定義可行性研究需求分析總體設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼單元測(cè)試綜合測(cè)試軟件維護(hù)圖1-1瀑布模問(wèn)題定義的結(jié)果： 問(wèn)題目標(biāo)和規(guī)模報(bào)告書可行性研究的結(jié)果:可行性研究報(bào)告 。需求分析的結(jié)果： 需求規(guī)格說(shuō)明書7、簡(jiǎn)述結(jié)構(gòu)化方法需求分析的綜合要求。答：需求分析階段的任務(wù)主要是確定目標(biāo)系統(tǒng)必須具備哪些功能。結(jié)構(gòu)化需求分析的綜合要求： 功能要求：指系統(tǒng)必須完成的所有功能。 性能要求：如聯(lián)機(jī)系統(tǒng)的響應(yīng)時(shí)間，系統(tǒng)的存儲(chǔ)容量、健壯性和安全性等方面的要求。 運(yùn)行要求：指系統(tǒng)運(yùn)行所需要的軟硬件環(huán)境。Word 資料. 未來(lái)要求：指系統(tǒng)將來(lái)可能的擴(kuò)充要求。

7、數(shù)據(jù)要求：指系統(tǒng)所要處理的數(shù)據(jù)以及它們之間的聯(lián)系。需求分析的結(jié)果： 需求規(guī)格說(shuō)明書8、能繪制 DFD，并能將 DFD 映射為軟件結(jié)構(gòu)圖。PPT 第三章 18例子：某工廠采購(gòu)部門每天要開(kāi)出定貨清單，清單中包括訂購(gòu)部件的部件號(hào)、部件名、規(guī)格、說(shuō)明、訂購(gòu)量、當(dāng)前價(jià)格、主要供應(yīng)商和輔助供應(yīng)商。部件入庫(kù)或出庫(kù)稱為業(yè)務(wù)，通過(guò)倉(cāng)庫(kù)中的終端把業(yè)務(wù)報(bào)告給定貨系統(tǒng)，處理庫(kù)存業(yè)務(wù)。當(dāng)某種部件的庫(kù)存量少于標(biāo)準(zhǔn)線以下時(shí)，倉(cāng)庫(kù)管理員就應(yīng)該及時(shí)通知定貨系統(tǒng)開(kāi)出定貨清單，交由采購(gòu)員采購(gòu)。根據(jù)畫數(shù)據(jù)流圖的步驟畫出定貨系統(tǒng)的數(shù)據(jù)流圖。（不需要答 ）(1)從系統(tǒng)的簡(jiǎn)述中提取數(shù)據(jù)流圖的四個(gè)成分;1) 源點(diǎn)和匯點(diǎn)。倉(cāng)庫(kù)管理員視為源點(diǎn)，

8、采購(gòu)員視為匯點(diǎn)2) 處理。處理通常是系統(tǒng)簡(jiǎn)述中的動(dòng)詞短語(yǔ)，如產(chǎn)生定貨清單，處理庫(kù)存業(yè)務(wù)等。3) 數(shù)據(jù)流。從系統(tǒng)的源點(diǎn)流出和流入?yún)R點(diǎn)的數(shù)據(jù)流即是系統(tǒng)的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流。4) 數(shù)據(jù)存儲(chǔ)。 確定哪些數(shù)據(jù)應(yīng)保存在數(shù)據(jù)存儲(chǔ)中。庫(kù)存業(yè)務(wù)一旦產(chǎn)生就立即被處理，所以不必保存。定貨清單一天只產(chǎn)生一次，故需要保存產(chǎn)生定貨清單的數(shù)據(jù)。有關(guān)庫(kù)存零部件的信息包括定貨標(biāo)準(zhǔn)線也應(yīng)作為數(shù)據(jù)存儲(chǔ)，統(tǒng)稱為庫(kù)存數(shù)據(jù)。（2 ）定貨系統(tǒng)數(shù)據(jù)流圖的基本成分源點(diǎn) / 匯點(diǎn)處理數(shù)據(jù)流數(shù)據(jù)存儲(chǔ)管理員產(chǎn)生定貨清單定貨清單定貨數(shù)據(jù)采購(gòu)員處理庫(kù)存業(yè)務(wù)庫(kù)存業(yè)務(wù)庫(kù)存數(shù)據(jù)(3) 畫出系統(tǒng)的高層數(shù)據(jù)流圖 ;圖在 PPT 第三章 28、 29將 DFD

9、 映射為軟件結(jié)構(gòu)圖圖在 PPT 第三章 909、簡(jiǎn)述軟件測(cè)試的三個(gè)步驟、黑盒和白盒測(cè)試方法。聚、耦合類型分析。Word 資料.(1)單元測(cè)試：又稱模塊測(cè)試測(cè)試對(duì)象是軟件設(shè)計(jì)中最小的單元 模塊，其目的是發(fā)現(xiàn)模塊部存在的錯(cuò)誤。單元測(cè)試發(fā)現(xiàn)編碼階段的錯(cuò)誤。測(cè)試容 :(a) 模塊間的接口 ;(b) 模塊的局部數(shù)據(jù)結(jié)構(gòu)(c) 模塊的重要通路尤其是錯(cuò)誤處理的通路和影響上述各方面的邊界條件。(2) 集成測(cè)試：又稱組裝測(cè)試或聯(lián)合測(cè)試集成測(cè)試發(fā)現(xiàn)軟件設(shè)計(jì)階段的錯(cuò)誤。在單元測(cè)試的基礎(chǔ)上， 需要將所有模塊按設(shè)計(jì)要求組裝成系統(tǒng)。在經(jīng)過(guò)單元測(cè)試未發(fā)現(xiàn)錯(cuò)誤的模塊，組裝之后仍可能出現(xiàn)各種問(wèn)題。集成測(cè)試的基本方法：邊組裝邊測(cè)

10、試。有自頂向下或自底向上兩種方法。(a) 自頂向下測(cè)試從主控模塊開(kāi)始， 沿著模塊層次， 邊組裝邊測(cè)試已組裝部分的功能，直到全部組裝完畢，系統(tǒng)達(dá)到設(shè)計(jì)的功能和性能要求為止。 為保證測(cè)試的進(jìn)行， 必須提供保證測(cè)試條件的樁模塊。樁模塊：用來(lái)模擬被測(cè)模塊的下層模塊的模塊。再用實(shí)際的下層模塊代替樁模塊，并進(jìn)行回歸測(cè)試?；貧w測(cè)試是相對(duì)于原始測(cè)試而言的，它部分或全部地重復(fù)前面進(jìn)行過(guò)的測(cè)試工作。(b) 自底向上測(cè)試與自頂向下測(cè)試相反，它先組裝最低層模塊，向上逐步組裝。每組裝一個(gè)模塊，便測(cè)試由此模塊及其下層模塊組成的子功能。 直到全部裝配完畢， 達(dá)到系統(tǒng)設(shè)計(jì)的功能和性能要求為止。為保證測(cè)試的進(jìn)行，必須提供保證測(cè)

11、試條件的“驅(qū)動(dòng)程序 ”。用實(shí)際的上層模塊代替該驅(qū)動(dòng)程序。(3) 確認(rèn)測(cè)試：又稱有效性測(cè)試或驗(yàn)收測(cè)試確認(rèn)測(cè)試檢查系統(tǒng)的功能和性能是否達(dá)到系統(tǒng)分析說(shuō)明書提出的設(shè)計(jì)指標(biāo)，即是否滿足用戶要求，檢查文檔是否齊全等。確認(rèn)測(cè)試發(fā)現(xiàn)軟件分析階段的錯(cuò)誤。黑盒測(cè)試法是根據(jù)程序的功能和性能進(jìn)行測(cè)試的方法。它把被測(cè)程序看成一個(gè)黑盒子，完全不考慮程序部的數(shù)據(jù)結(jié)構(gòu)和邏輯通路。也就是說(shuō)， 黑盒測(cè)試是在程序接口進(jìn)行的測(cè)試，它只檢查程序功能和性能是否滿足預(yù)期需要，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)產(chǎn)生正確的輸出數(shù)據(jù)，并保持外部信息的完整性。產(chǎn)生黑盒測(cè)試的測(cè)試用例的方法有如下幾種：等價(jià)類劃分法邊界值分析法、因果圖法、錯(cuò)誤推測(cè)法白盒測(cè)試

12、法是根據(jù)程序的邏輯結(jié)構(gòu)進(jìn)行測(cè)試的方法。 它把程序看成是裝在一個(gè)透明的白盒中，也就是完全了解程序部的結(jié)構(gòu)和處理過(guò)程。 這種方法按程序部的邏輯來(lái)測(cè)試程序，檢驗(yàn)程序的每條通路是否都能按規(guī)定要求正確工作。Word 資料.產(chǎn)生白盒測(cè)試用例的方法有如下幾種：語(yǔ)句覆蓋、判定覆蓋、條件覆蓋、判定/ 條件覆蓋、條件組合覆蓋。一般而言，測(cè)試時(shí)以黑盒測(cè)試法為主，白盒測(cè)試法為輔。模塊間的耦合程度按從低到高分類如下:無(wú)耦合。 如果兩模塊之間沒(méi)有任何聯(lián)系， 每一個(gè)都能獨(dú)立地工作而不需要另一模塊的存在，是彼此完全獨(dú)立的，則這兩個(gè)模塊間屬于無(wú)耦合的情況。數(shù)據(jù)耦合。 如果兩個(gè)模塊是通過(guò)參數(shù)表僅傳遞數(shù)據(jù)型信息，則這種耦合稱為數(shù)據(jù)

13、耦合。數(shù)據(jù)耦合是松散的耦合，模塊間的獨(dú)立性較強(qiáng)。軟件結(jié)構(gòu)中至少有這種耦合。特征耦合。 若兩個(gè)模塊通過(guò)參數(shù)表傳遞的是某一數(shù)據(jù)結(jié)構(gòu)的子結(jié)構(gòu)，而不是簡(jiǎn)單變量，這就是特征耦合。是數(shù)據(jù)耦合的一種變種。增加出錯(cuò)的機(jī)會(huì)，不易改動(dòng)（數(shù)據(jù)結(jié)構(gòu)變化時(shí)）。將該數(shù)據(jù)結(jié)構(gòu)上的操作全部集中在一個(gè)模塊中，就可消除這種耦合?？刂岂詈稀Ｈ绻麄鬟f控制型信息，這就是控制耦合。對(duì)被控制的模塊做任何修改，都會(huì)影響到控制模塊，降低模塊的獨(dú)立性。公共耦合。若一組模塊使用了公共數(shù)據(jù)，則它們之間的耦合稱為公共耦合。公共數(shù)據(jù)包括全程變量、共享的通信區(qū)、存的公共覆蓋區(qū)等。公共數(shù)據(jù)的使用，必然降低軟件的可讀性、可修改性和可靠性。容耦合。如果發(fā)生下列

14、情況之一，兩個(gè)模塊間就是容耦合：? 一個(gè)模塊直接訪問(wèn)另一個(gè)模塊的部數(shù)據(jù)；? 一個(gè)模塊通過(guò)不正常入口直接轉(zhuǎn)入另一模塊部；? 一個(gè)模塊有多個(gè)入口；? 兩模塊有一部分代碼重疊 ( 只在匯編語(yǔ)言中出現(xiàn) )；容耦合是耦合性最高的耦合， 即是模塊間最壞的聯(lián)系方式， 現(xiàn)在大多數(shù)高級(jí)程序設(shè)計(jì)語(yǔ)言中已經(jīng)不會(huì)出現(xiàn)這種耦合。在進(jìn)行設(shè)計(jì)時(shí)應(yīng)該采取以下原則：以數(shù)據(jù)耦合為主，特征耦合為輔，少用控制耦合，限制公共耦合，杜絕容耦合。模塊的聚性按從低到高分類如下:偶然聚。 如果模塊中各組成成分間彼此沒(méi)有實(shí)質(zhì)聯(lián)系，即使有聯(lián)系也是很松散的，模塊功能模糊，則稱為偶然聚。例如有時(shí)寫完一段程序后，發(fā)現(xiàn)一組語(yǔ)句在程序中多處出現(xiàn)，便將其組織

15、在一個(gè)模塊以節(jié)省存，就出現(xiàn)了偶然聚的模塊。在模塊設(shè)計(jì)時(shí)，如果發(fā)覺(jué)一個(gè)模塊難以命名，就應(yīng)考慮是否出現(xiàn)偶然聚。邏輯聚。如果一個(gè)模塊完成的是邏輯上相同或相似的一組功能，則稱為邏輯聚。例如，設(shè)計(jì)一個(gè)模塊打印各種報(bào)表，如固定資產(chǎn)報(bào)表、產(chǎn)品成本報(bào)表、利潤(rùn)報(bào)表等，打印何種報(bào)表靠傳遞控制參數(shù)調(diào)用。由于不同功能在一個(gè)模塊中，通常在設(shè)計(jì)模塊時(shí)會(huì)出現(xiàn)幾種功能共用部分代碼，從而使得修改、添加或去掉功能都很困難。時(shí)間聚。若一個(gè)模塊中包含的任務(wù)必須在同一時(shí)間執(zhí)行， 而這些任務(wù)的次序無(wú)關(guān)緊要，則叫時(shí)間聚。例如各種初始化工作由初始化模塊完成，而各種結(jié)束工作被組合到結(jié)束模塊中，這樣它的執(zhí)行將涉及到其它許多模塊。Word 資料.

16、過(guò)程聚。 如果一個(gè)模塊的處理成分間是相關(guān)的， 而且必須以特定順序執(zhí)行， 則稱為過(guò)程聚。例如把程序流程圖中的循環(huán)、判斷和計(jì)算分成三個(gè)模塊，則這三個(gè)模塊就是過(guò)程聚的模塊。通信聚。模塊的所有成分都通過(guò)公共數(shù)據(jù)而發(fā)生關(guān)系的聚就是通訊聚。例如對(duì)同一文件進(jìn)行輸入、修改、輸出操作。模塊中各成分經(jīng)模塊的局部的公共數(shù)據(jù)進(jìn)行通信。順序聚。 若模塊中每個(gè)處理成分對(duì)應(yīng)一個(gè)功能， 且這些處理必須按順序執(zhí)行， 則稱為順序聚。例如一個(gè)處理成分的輸出是下一個(gè)處理成分的輸入的模塊就是順序聚。功能聚。模塊中各處理成分屬于一個(gè)整體，都為了完成同一功能，很難分割，這就是功能聚。這種模塊通常有明確表達(dá)模塊功能的名稱。第四章軟件開(kāi)發(fā)的面

17、向?qū)ο蠓椒?0、與 OO 方法相比，傳統(tǒng)方法存在哪些問(wèn)題。OO 方法有哪些優(yōu)點(diǎn)。答： 傳統(tǒng)方法存在下列問(wèn)題：(1)對(duì)現(xiàn)實(shí)世界的認(rèn)識(shí)與編程之間存在理解上的鴻溝；功能與數(shù)據(jù)相分離造成。(2) 修改困難；系統(tǒng)是圍繞如何實(shí)現(xiàn)一定的行為進(jìn)行，當(dāng)需求變化時(shí)，數(shù)據(jù)常常發(fā)生變化，最終導(dǎo)致數(shù)據(jù)的結(jié)構(gòu)變化，難于修改。(3) 維護(hù)困難；為了得到“好的軟件結(jié)構(gòu)” ，使作用域在控制域之中，導(dǎo)致系統(tǒng)總體結(jié)構(gòu)混亂，難于維護(hù)。(4) 自頂向下功能分解的分析方法限制了軟件的可復(fù)用性。面向?qū)ο蠓椒ǖ膬?yōu)點(diǎn)(1)與人類習(xí)慣的思維方法一致核心是對(duì)象，它是現(xiàn)實(shí)世界實(shí)體的正確抽象。而傳統(tǒng)方法忽略了數(shù)據(jù)和操作之間的聯(lián)系。(2) 穩(wěn)定性好它基

18、于構(gòu)造問(wèn)題領(lǐng)域的對(duì)象模型， 以對(duì)象為中心構(gòu)造軟件系統(tǒng)， 當(dāng)功能發(fā)生需求變化時(shí)，不會(huì)引起軟件結(jié)構(gòu)的整體變化。而傳統(tǒng)方法基于功能分析和分解， 以算法為核心， 功能變化通常會(huì)引起軟件結(jié)構(gòu)的整體變化。(3) 可重用性好對(duì)象類固有的封裝性和信息隱蔽以及很好的繼承機(jī)制， 使得面向?qū)ο蠓椒ň哂泻芎玫目蓮?fù)用性。傳統(tǒng)方法只是庫(kù)一級(jí)的復(fù)用。Word 資料.(4) 可維護(hù)性好OO 方法的模塊機(jī)制、繼承機(jī)制、多態(tài)性機(jī)制，使得設(shè)計(jì)的軟件易于理解、修改、測(cè)試，更易于維護(hù)。而傳統(tǒng)方法及其面向過(guò)程開(kāi)發(fā)的軟件是難以維護(hù)的。11、找出問(wèn)題域有關(guān)對(duì)象的兩種方法：LIA 和 3VM.簡(jiǎn)述 LIA 和 3VM 及其作用，并比較之。答：

19、 (1)基于語(yǔ)言的信息分析方法（LIA）主要思想： 先對(duì)要建立的系統(tǒng)及其需求用自然語(yǔ)言描述，然后對(duì)這些描述進(jìn)行語(yǔ)法分析。名詞對(duì)象，形容詞屬性，動(dòng)詞服務(wù)填進(jìn)一 OOA/OOD 工作表格。最后對(duì)表中的項(xiàng)進(jìn)行分析，從中確定問(wèn)題域中的對(duì)象。(2) 三視圖模型法（ 3VM ）觀察一個(gè)事物的角度不同， 將得到不同的視圖。 從多個(gè)角度觀察得到的同一個(gè)事物的多個(gè)視圖更能完整地、全面地反映該事物。LIA 方法要求分析員從眾多的侯選對(duì)象中識(shí)別出目標(biāo)系統(tǒng)的對(duì)象，這依賴于分析員的抽象和分析能力，隨意性大，可操作性不強(qiáng)。LIA 方法提供了一個(gè)發(fā)現(xiàn)對(duì)象的出發(fā)點(diǎn)，一般將該方法用于對(duì)象模型建立的初始階段。3VM法也依賴于分析

20、人員的抽象和分析能力，但運(yùn)用建立3VM的方法，確實(shí)提供了分析對(duì)象的入口點(diǎn)和細(xì)化的方法，具有相對(duì)較好的操作性。該方法一般用于對(duì)象模型的細(xì)化。12、分析電梯到達(dá)調(diào)度樓層的事件-響應(yīng)對(duì)象交互圖、實(shí)例連接圖。電梯到達(dá)調(diào)度樓層的事件-響應(yīng)對(duì)象交互圖PPT 第四章 931當(dāng)電梯到達(dá)某一樓層時(shí)，就會(huì)產(chǎn)生一個(gè)電梯到達(dá)事件Arrival Event 。其屬性有：該到達(dá)事件的唯一標(biāo)識(shí)：ECS/OOA EROI圖第3個(gè)事件：電梯到達(dá)調(diào)度樓層arrival_id到到目目電超召 召生成到達(dá)事件的電梯：達(dá)達(dá)的的電 梯樓載喚 喚事面事面梯 電層傳件板件板機(jī)感事 面elevator_id件 板器生成該到達(dá)事件的樓層：arri

21、val_floor圖3-12 電梯到達(dá)調(diào)度樓層Word 資料.2 電梯到達(dá)事件生成后，將會(huì)向與 elevator_id 相關(guān)聯(lián)的到達(dá)面板發(fā)送一個(gè)單向的消息，該消息是： （arrival_floor ）（電梯 elevator_id所到達(dá)的樓層）與 elevator_id相關(guān)聯(lián)的到達(dá)面板根據(jù)收到的消息刷新到達(dá)面板的顯示ECS/OOA EROI圖第3個(gè)事件：電梯到達(dá)調(diào)度樓層到到目目電超召 召達(dá)達(dá)的的電梯樓載喚 喚事面事面梯電層傳事 面件板件板機(jī)感件 板器圖3-12 電梯到達(dá)調(diào)度樓層3 電梯到達(dá)事件將會(huì)向與floor_id相關(guān)聯(lián)的floor 發(fā)送一個(gè)單向的消息，該消息是：(到達(dá)事件的唯一標(biāo)識(shí), 電梯

22、唯一標(biāo)識(shí)，到達(dá)的樓層號(hào))（ arrival_id,report_elevator_id,report_arrival_floor_id)ECS/OOA EROI圖第3個(gè)事件：電梯到達(dá)調(diào)度樓層到到目目電超召召達(dá)達(dá)的的電梯樓載喚喚事面事面梯電層傳事面件板件板機(jī)感件板器圖3-12 電梯到達(dá)調(diào)度樓層4. 樓層 Floor 收到上述消息后，由服務(wù) Floor.Process_Elevator_Arrival_ 處理。該服務(wù)將向電梯 report_elevator_id 發(fā)送一個(gè)雙向的消息：(report_status_direction?,report_current_direction?)ECS/OO

23、A EROI圖第3個(gè)事件：電梯到達(dá)調(diào)度樓層到到目目電超 召召達(dá)達(dá)的的電梯樓載 喚喚事面事面梯電層傳 事面件板件板機(jī)感 件板器Word 資料.電梯 report_elevator_id收到該消息后， 會(huì)有相應(yīng)的服務(wù)Elevator.Report_Status_Direction和 levator.Report_Current_Direction服務(wù)向樓層Floor 報(bào)告電梯當(dāng)前的運(yùn)行方向和狀態(tài)方向。5.Floor 發(fā)給與 report_elevator_id所關(guān)聯(lián)的電梯的目的面板一個(gè)雙向消息：(report_arrival_floor,destination_pending_above?,des

24、tination_pending_beloow?)ECS/OOA EROI圖第3個(gè)事件：電梯到達(dá)調(diào)度樓層到到目目電超召召達(dá)達(dá)的的電梯樓載喚喚事面事面梯電層傳事面件板件板機(jī)感件板器圖3-12 電梯到達(dá)調(diào)度樓層目的面板收到該消息后，即可知道樓層report_arrival_floor是否是調(diào)度樓層。6.Floor 發(fā)給與 arrival_floor 所關(guān)聯(lián)的召喚面板一個(gè)雙向消息：(report_summons_pending_up? report_summons_pending_down?)ECS/OOA EROI圖第3個(gè)事件：電梯到達(dá)調(diào)度樓層到到目目電超召召達(dá)達(dá)的的電梯樓載喚喚事面事面梯電層傳事

25、面件板件板機(jī)感件板器圖3-12 電梯到達(dá)調(diào)度樓層該樓層的召喚面板收到該消息后，相應(yīng)的服務(wù)即可報(bào)告該樓層的召喚請(qǐng)上、下或是沒(méi)有請(qǐng)求。知道該樓層是否有召喚，以及電梯的狀態(tài)方向和當(dāng)前運(yùn)行方向等信息，即可判定該樓層是否是調(diào)度樓層。Word 資料.7. 如果是調(diào)度樓層（這里假設(shè)是該樓層的召喚導(dǎo)致的） ，則(1) Floor 向與其相關(guān)聯(lián)的召喚面板對(duì)象發(fā)消息，使其刷新面板 ;（2） 向與 report_elevator_id所關(guān)聯(lián)的電梯發(fā)消息。電梯接受到消息后，更新其當(dāng)前狀態(tài) (current_status) 、(current_direction) 、(status_direction)等;（3） 電梯

26、向與其關(guān)聯(lián)的電梯電機(jī)對(duì)象發(fā)送停止消息（Stop）。ECS/OOA EROI圖第3個(gè)事件：電梯到達(dá)調(diào)度樓層到到目目電超召召達(dá)達(dá)的的電梯樓載喚喚事面事面梯電層傳事面件板件板機(jī)感件板器圖3-12 電梯到達(dá)調(diào)度樓層8. 到達(dá)事件結(jié)束。實(shí)例連接圖 :實(shí)例連接分類Word 資料.有 3 種類型的實(shí)例連接：(1)一對(duì)一型 :一個(gè)對(duì)象只依賴于另外一個(gè)對(duì)象。如一個(gè)飛行員駕駛一架飛機(jī)。(2) 一對(duì)多型：一個(gè)對(duì)象同時(shí)依賴多個(gè)對(duì)象。如一個(gè)教師指導(dǎo) 5 個(gè)學(xué)生的畢業(yè)設(shè)計(jì)。(3) 多對(duì)多型：相互依賴的對(duì)象數(shù)在一個(gè)以上。如全班 30 名學(xué)生學(xué)習(xí) 6 門課程。對(duì)下圖分析1,m11FloorElevator11Overweig

27、thSensor11,m0,m111ElevatorMotorSummonsArrival1PanelEventArrival0,m1Panel1SummonsDestination1DestinationEventEvent0,mPanel13-14電梯控制系統(tǒng)實(shí)例連接13、在 Coad 和 Yourdon 的 OOD中，從哪四個(gè)方面對(duì) OOA 進(jìn)行了擴(kuò)充，簡(jiǎn)述其容。答： Coad 和 Yourdon提出從以下四個(gè)方面考慮：(1)問(wèn)題域部分 (Problem Domain Component， PDC)問(wèn)題域部分是為了消除系統(tǒng)的存貯容量無(wú)限及對(duì)象間的通信速度無(wú)限快等假設(shè)的。 (2) 人 -機(jī)

28、接口部分 (Human Interface Component， HIC)人 -機(jī)接口部分是為了將系統(tǒng)和外界的通信任務(wù)由特定的對(duì)象承擔(dān)，使得系統(tǒng)的功能和實(shí)現(xiàn)相分離。 這樣，如果系統(tǒng)與外界的接口發(fā)生改變時(shí)，只需要改變這部分對(duì)象即可。 (3) 任務(wù)管理部分（Task Management Component， TMC ）任務(wù)管理部分是為了將系統(tǒng)和具體的操作系統(tǒng)提供的任務(wù)調(diào)用由特定的對(duì)象來(lái)承擔(dān)。如果操作系統(tǒng)的環(huán)境改變，只需要改變這部分對(duì)象即可。(4) 數(shù)據(jù)庫(kù)管理部分(Database Management Component， DMC)Word 資料.數(shù)據(jù)庫(kù)管理部分為了將系統(tǒng)和由特定數(shù)據(jù)庫(kù)系統(tǒng)所管理

29、的數(shù)據(jù)的訪問(wèn)有特定的對(duì)象來(lái)承擔(dān)。 如果系統(tǒng)所應(yīng)用到的一些由數(shù)據(jù)庫(kù)管理的數(shù)據(jù)， 而數(shù)據(jù)庫(kù)的類型或結(jié)構(gòu)發(fā)生改變時(shí)，只需要改變這部分對(duì)象。14、分析電梯控制系統(tǒng)中召喚事件和圖書管理系統(tǒng)中借閱事件的完整執(zhí)行機(jī)制。PDCHIC問(wèn)題域部分人- 機(jī)接口部分SummonsSummonsEventButton報(bào)告按下按鈕召喚按鈕產(chǎn)生了一個(gè)召喚事件！圖3-19召喚事件的執(zhí)行機(jī)制當(dāng)按鈕按下時(shí)， 將產(chǎn)生一個(gè)中斷， 即 “所發(fā)出的信號(hào) ” 中應(yīng)包含樓層的信息或編碼， 這個(gè)編碼應(yīng)存放到該中斷對(duì)應(yīng)的中斷寄存器中。圖書管理系統(tǒng)中借閱事件的完整執(zhí)行機(jī)制。借閱一本書的過(guò)程，涉及了三個(gè)實(shí)體：“Reader ”實(shí)體存儲(chǔ)借閱者；“Bo

30、ok ”實(shí)體存儲(chǔ)書；“Reader-Book ”存儲(chǔ)某個(gè)借閱者借閱某本書的記錄。對(duì)象 “Borrow ”來(lái)負(fù)責(zé)處理 “借閱 ”事件。Word 資料.ReaderBook111,m1,mReader-Book圖3-22 “借閱”所涉及的實(shí)體關(guān)系數(shù)據(jù)庫(kù)DBMSDMCPDCHIC數(shù)據(jù)庫(kù)管理部分問(wèn)題域部分人-機(jī)接口部分Book4Book按下Table7書按鈕書基表82Borrow Book滿意的用戶WindowReader-10借閱窗口1BookBorrowBorrow Book借閱11借閱12Finish Window基表借閱完成窗口93Reader5ReaderTable讀者基6讀者表圖3-23借

31、閱事件的執(zhí)行機(jī)制第五章統(tǒng)模語(yǔ)言 UML 與實(shí)例15、簡(jiǎn)述 UML 中的狀態(tài)圖和活動(dòng)圖以及它們之間的差異。Word 資料.答：（1）狀態(tài)圖：狀態(tài)機(jī)對(duì)類的對(duì)象可能生命歷史建模。狀態(tài)機(jī)用來(lái)描述一個(gè)特定對(duì)象的所有可能狀態(tài)及其引起狀態(tài)轉(zhuǎn)移的事件。狀態(tài)描述了一個(gè)類對(duì)象生命期中的一個(gè)時(shí)間段，對(duì)對(duì)象生命期中的一段時(shí)間建模，該時(shí)間對(duì)象滿足一定的條件。當(dāng)事件發(fā)生時(shí)，它可能導(dǎo)致遷移的激發(fā)，使對(duì)象改變至新?tīng)顟B(tài)。當(dāng)遷移激發(fā)時(shí)，附屬于遷移的移動(dòng)可能被執(zhí)行。狀態(tài)機(jī)顯示為狀態(tài)圖 (State Diagram) 。狀態(tài)圖可用于描述用戶界面、設(shè)備控制和其它交互式子系統(tǒng)。狀態(tài)機(jī)和 OOA 中的狀態(tài)遷移圖一致。（2）活動(dòng)圖 ：活動(dòng)圖

32、顯示動(dòng)作及其結(jié)果。 活動(dòng)圖著重描述操作 (方法 )實(shí)現(xiàn)中所完成的工作以及用例實(shí)例或?qū)ο笾械幕顒?dòng)。 活動(dòng)圖是另一種描述交互的方式， 描述采取何種動(dòng)作， 做什么 (對(duì)象狀態(tài)改變 ) ，何時(shí)發(fā)生 (動(dòng)作序列 ) 。差別：活動(dòng)圖描述動(dòng)作執(zhí)行的工作和活動(dòng)及對(duì)象狀態(tài)改變的結(jié)果，不需指定任何事件。當(dāng)狀態(tài)中的動(dòng)作被執(zhí)行 ( 不象狀態(tài)圖需指定任何事件 )時(shí)，活動(dòng)圖中的狀態(tài)（稱為動(dòng)作狀態(tài)）直接轉(zhuǎn)移到下一個(gè)階段。活動(dòng)圖可以用作下述目的：(1)描述操作執(zhí)行過(guò)程中所完成的工作( 動(dòng)作 )；(2) 描述對(duì)象部的工作；(3) 顯示如何執(zhí)行一組相關(guān)的動(dòng)作，以及這些動(dòng)作如何影響它們周圍的對(duì)象；(4) 顯示用例的實(shí)例是如何執(zhí)行動(dòng)

33、作以及如何改變對(duì)象狀態(tài)；(5) 說(shuō)明一次商務(wù)活動(dòng)中的角色、工作流組織和對(duì)象是如何工作的。16、理解、分析和繪制UML 的各種視圖 (戲院管理系統(tǒng)、汽車租賃系統(tǒng)、教學(xué)管理系統(tǒng)等)。戲院管理系統(tǒng)： PPT 第五章：用例圖（ 23 ）、類圖 (32) 、順序圖（ 36 ）協(xié)作圖（ 39）、狀態(tài)圖：（42 ）、活動(dòng)圖（ 46）教學(xué)管理系統(tǒng)： PPT 第五章用例圖（ 71、72 ）、類圖 (78 、79) 、順序圖（ 86、 87 ）、協(xié)作圖（ 88 ）、狀態(tài)圖：（ 89 、 90 ）、活動(dòng)圖（ 91）Word 資料.第六章 面向?qū)ο箝_(kāi)發(fā)中的設(shè)計(jì)模式17、簡(jiǎn)述設(shè)計(jì)模式的作用、設(shè)計(jì)模式的四個(gè)基本要素。答：

34、作用：有經(jīng)驗(yàn)的軟件員總是將面向?qū)ο筌浖O(shè)計(jì)的經(jīng)驗(yàn)記錄成“設(shè)計(jì)模式” ，以便在今后的軟件開(kāi)發(fā)中復(fù)用以往的成功設(shè)計(jì)。四個(gè)基本要素：模式名稱、問(wèn)題、解決方案和后果（1）模式名稱：通常用來(lái)描述一個(gè)設(shè)計(jì)問(wèn)題、它的解法和后果，由一到兩個(gè)詞描述。模式名稱可以在更高的抽象層次上進(jìn)行設(shè)計(jì)并交流設(shè)計(jì)思想。（2）問(wèn)題：描述模式使用的時(shí)間、條件、解釋問(wèn)題及其背最。它可能描述諸如如何將一個(gè)算法表示成一個(gè)對(duì)象這樣的特殊設(shè)計(jì)問(wèn)題。（ 3 ）解決方案：描述設(shè)計(jì)的基本組成要素，如它們的關(guān)系、各自的任務(wù)以及相互之間的合作。 它并非針對(duì)某個(gè)特殊問(wèn)題。 設(shè)計(jì)模式提供有關(guān)設(shè)計(jì)問(wèn)題的一個(gè)抽象描述以及如何安排這些基本要素以解決問(wèn)題。（ 4

35、 ）后果：描述應(yīng)用設(shè)計(jì)模式后的結(jié)果和利弊。對(duì)于軟件設(shè)計(jì)來(lái)說(shuō)，通常要考慮的是空間和時(shí)間的權(quán)衡，還有語(yǔ)言問(wèn)題和實(shí)現(xiàn)問(wèn)題。對(duì)于 OO 設(shè)計(jì)，可重用性很重要。此外，后果還包括對(duì)系統(tǒng)靈活性、可擴(kuò)充性及可移植性的影響。18、理解 ModelView合約。答：（ 1）形式合約是一種描述框架設(shè)計(jì)的方法，它強(qiáng)調(diào)組成框架的對(duì)象間的交互關(guān)系。（2）形式合約的特點(diǎn)：符號(hào)少且能映射到OO 編程語(yǔ)言中的概念，如參與者映射到對(duì)象。考慮到了復(fù)雜行為由簡(jiǎn)單行為組成的事實(shí)， 合約的修訂和擴(kuò)充操作使得合約靈活，易于應(yīng)用。（3）形式合約的基本元素：參與者：形式合約的第一個(gè)組成部分。對(duì)每個(gè)參與者要規(guī)定它應(yīng)承擔(dān)的責(zé)任。責(zé)任有：類型責(zé)任：

36、與實(shí)例變量和方法有關(guān)的責(zé)任。因果責(zé)任：描述與類型責(zé)任相關(guān)的操作與條件“-> ” : 表示方法調(diào)用。如 s->Update() 表示對(duì) Subscribers 中的方法 Update() 的調(diào)用。 “ v ”: 表示對(duì)實(shí)例變量 v 賦值?！?lt;ov:c:e> ”: 表示用操作符o 將所有滿足條件c 的變量 v 所構(gòu)成的表達(dá)式e 連接起來(lái)。Word 資料.如<|s:s Subscriber:s->Update()>意味著s1->Update()|s2->Update()| .,即對(duì) Subscriber 集合中的所有對(duì)象發(fā)送Update() 消息

37、?！?”:表示參與者必須滿足的條件的說(shuō)明。如AttachSubscriber(s:Subscriber)=>s Subscriber: 表示一個(gè)條件，s 是Subscriber 集合的成員在以s為參數(shù)執(zhí)行AttachSubscriber 后必須為真。19、簡(jiǎn)述選擇設(shè)計(jì)模式的方法。答：設(shè)計(jì)模式依據(jù)其目的可分為創(chuàng)建型、結(jié)構(gòu)型、行為型三種。共23 個(gè)模式下面是幾個(gè)幫助選擇設(shè)計(jì)模式的方法：·考慮設(shè)計(jì)模式是怎樣解決設(shè)計(jì)問(wèn)題的：對(duì)設(shè)計(jì)模式的討論，能幫助找到合適的對(duì)象、 決定對(duì)象的粒度、 指定對(duì)象接口以及設(shè)計(jì)模式解決設(shè)計(jì)問(wèn)題的幾個(gè)其他方法。·瀏覽模式的意圖部分： 通讀每個(gè)模式的意圖， 找出