軟件工程研復習提綱答案2023

復習提綱第一章軟件工程概述1、分析60年代末出現(xiàn)的軟件危機的原因。如何理解“越早潛伏的錯誤越晚發(fā)現(xiàn)，越晚發(fā)現(xiàn)的錯誤，修正的費用越高〞。答：軟件危機是指在軟件開發(fā)過程中遇到的一系列嚴重問題，如：開發(fā)周期延長，本錢增加，可靠性降低等。開發(fā)大型軟件與編制小程序主要有以下區(qū)別：⑴人員：小程序從確定要求、設計、編制、使用，直到維護通常由一個人完成；大型軟件那么由用戶、工程負責人、分析員、程序員、資料員、操作員等組成一支開發(fā)隊伍來協(xié)同完成。⑵文檔：小程序很少有書面文檔；大型軟件那么是集體勞動的“產(chǎn)物〞，必須有標準化的文檔，便于開發(fā)和維護。⑶產(chǎn)品。小程序工作量小，如果需作大的修改，可舍棄舊程序而重新編寫；但大型軟件的開發(fā)消耗了大量的人力與物力，一般不會輕易拋棄，而總是在舊軟件的根底上一再改動，以延長它的使用期，因此“版本〞在不斷升級。大型軟件的開發(fā)提出了許多新的問題，而開發(fā)方法卻還停留在編制小程序的方法上，經(jīng)驗和技巧已不能滿足開發(fā)大型軟件的需要，導致軟件開發(fā)過程混亂；使用的開發(fā)方法和技術(shù)不當，沒有適當?shù)奈臋n，不易交流，維護困難，開發(fā)本錢高，軟件質(zhì)量低等，這些問題是造成軟件危機的主要原因。2、軟件復用的概念及兩類軟件復用技術(shù)：合成技術(shù)和生成技術(shù)。答：軟件復用是指在構(gòu)造新的軟件系統(tǒng)過程中，對已存在的軟件產(chǎn)品(設計結(jié)構(gòu)、源代碼、文檔等)重復使用的技術(shù)。(1)合成技術(shù)利用部件(component,組件，構(gòu)件)合成軟件系統(tǒng)的技術(shù)。部件是可復用的一小段軟件(可為二進制形式)，可以是對某一函數(shù)、過程、子程序、數(shù)據(jù)類型、算法等可復用軟件成分的抽象，封裝了功能細節(jié)和數(shù)據(jù)結(jié)構(gòu)，有詳細的接口。(2)生成技術(shù)利用可復用的模式，通過生成程序產(chǎn)生一個新的程序或程序段，產(chǎn)生的程序可以看成是模式的實例?？蓮陀玫哪Ｊ接袃煞N：代碼模式和規(guī)那么模式。①代碼模式可復用的代碼模式存在于應用生成器中，通過特定的參數(shù)替換，生成抽象軟件模塊的具體實體。各種程序生成器。②規(guī)那么模式利用程序變換系統(tǒng)，把用超高級規(guī)格說明語言編寫的程序轉(zhuǎn)化成某種可執(zhí)行語言的程序。IDL——CORBA的接口定義語言。第二章需求分析工程3、簡述需求分析工程的重要性。答：(1)在軟件生命周期中，一個錯誤發(fā)現(xiàn)越晚，修復錯誤的費用越高。(2)許多錯誤是潛伏的，且在錯誤產(chǎn)生后很長一段時間才被檢測出。(3)需求分析中會產(chǎn)生大量錯誤。(4)需求分析中的錯誤多為疏忽、不一致和二義性。(5)需求錯誤是可以被檢測出來的。4、掌握和分析Petri網(wǎng)的有關(guān)問題；會用可達樹分析死鎖問題。分析餓死現(xiàn)象并改良。答：Petri網(wǎng)的局限性1、令牌缺乏表示信息內(nèi)容的能力令牌只是表示動作控制的流向，無法表達信息的內(nèi)容。2、缺乏描述選擇“使能〞變遷的策略3、Petri網(wǎng)不能描述有定時要求的計算問題，而很多系統(tǒng)的定時問題那么很重要。用可達樹分析死鎖問題：假設出現(xiàn)葉結(jié)點，那么系統(tǒng)中有死鎖。分析餓死現(xiàn)象并改良：P2PP2P1P4P5P6P7P3t1t2t3t4t5t6圖中存在激發(fā)序列<t1,t3,t5>無限循環(huán)，而<t2,t4,t6>被“餓死〞，原因是Petri網(wǎng)不能描述選擇策略。修改Petri網(wǎng)，強制它使用一種選擇策略，防止了t3在t4激發(fā)之前激發(fā)兩次。如以下圖：5、分析、理解電梯運動的Petri網(wǎng)。PPT第二章49按下按下tmin=0.1tmin(C)=0.05tmax(C)=0.05第三章軟件開發(fā)的結(jié)構(gòu)化方法6、傳統(tǒng)的瀑布模型將軟件開發(fā)分為幾個步驟，每一步得到什么結(jié)果。問題定義問題定義可行性研究需求分析總體設計詳細設計編碼與單元測試綜合測試軟件維護圖1-1瀑布模型問題定義的結(jié)果：?問題目標和規(guī)模報告書?可行性研究的結(jié)果:?可行性研究報告?。需求分析的結(jié)果：?需求規(guī)格說明書?7、簡述結(jié)構(gòu)化方法需求分析的綜合要求。答：需求分析階段的任務主要是確定目標系統(tǒng)必須具備哪些功能。結(jié)構(gòu)化需求分析的綜合要求：⑴功能要求：指系統(tǒng)必須完成的所有功能。⑵性能要求：如聯(lián)機系統(tǒng)的響應時間，系統(tǒng)的存儲容量、健壯性和平安性等方面的要求。⑶運行要求：指系統(tǒng)運行所需要的軟硬件環(huán)境。⑷未來要求：指系統(tǒng)將來可能的擴充要求。⑸數(shù)據(jù)要求：指系統(tǒng)所要處理的數(shù)據(jù)以及它們之間的聯(lián)系。需求分析的結(jié)果：?需求規(guī)格說明書?8、能繪制DFD，并能將DFD映射為軟件結(jié)構(gòu)圖。PPT第三章18例子：某工廠采購部門每天要開出定貨清單，清單中包括訂購部件的部件號、部件名、規(guī)格、說明、訂購量、當前價格、主要供給商和輔助供給商。部件入庫或出庫稱為業(yè)務，通過倉庫中的終端把業(yè)務報告給定貨系統(tǒng)，處理庫存業(yè)務。當某種部件的庫存量少于標準線以下時，倉庫管理員就應該及時通知定貨系統(tǒng)開出定貨清單，交由采購員采購。根據(jù)畫數(shù)據(jù)流圖的步驟畫出定貨系統(tǒng)的數(shù)據(jù)流圖?！膊恍枰稹?1)從系統(tǒng)的簡述中提取數(shù)據(jù)流圖的四個成分;1)源點和匯點。倉庫管理員視為源點，采購員視為匯點2)處理。處理通常是系統(tǒng)簡述中的動詞短語，如產(chǎn)生定貨清單，處理庫存業(yè)務等。3)數(shù)據(jù)流。從系統(tǒng)的源點流出和流入?yún)R點的數(shù)據(jù)流即是系統(tǒng)的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流。4)數(shù)據(jù)存儲。確定哪些數(shù)據(jù)應保存在數(shù)據(jù)存儲中。庫存業(yè)務一旦產(chǎn)生就立即被處理，所以不必保存。定貨清單一天只產(chǎn)生一次，故需要保存產(chǎn)生定貨清單的數(shù)據(jù)。有關(guān)庫存零部件的信息包括定貨標準線也應作為數(shù)據(jù)存儲，統(tǒng)稱為庫存數(shù)據(jù)?！?〕定貨系統(tǒng)數(shù)據(jù)流圖的根本成分源點/匯點處理數(shù)據(jù)流數(shù)據(jù)存儲管理員產(chǎn)生定貨清單 定貨清單定貨數(shù)據(jù)采購員處理庫存業(yè)務庫存業(yè)務庫存數(shù)據(jù)(3)畫出系統(tǒng)的高層數(shù)據(jù)流圖;圖在PPT第三章28、29將DFD映射為軟件結(jié)構(gòu)圖圖在PPT第三章909、簡述軟件測試的三個步驟、黑盒和白盒測試方法。內(nèi)聚、耦合類型分析。(1)單元測試：又稱模塊測試測試對象是軟件設計中最小的單元——模塊，其目的是發(fā)現(xiàn)模塊內(nèi)部存在的錯誤。單元測試發(fā)現(xiàn)編碼階段的錯誤。測試內(nèi)容:(a)模塊間的接口;(b)模塊內(nèi)的局部數(shù)據(jù)結(jié)構(gòu)(c)模塊內(nèi)的重要通路尤其是錯誤處理的通路和影響上述各方面的邊界條件。(2)集成測試：又稱組裝測試或聯(lián)合測試集成測試發(fā)現(xiàn)軟件設計階段的錯誤。在單元測試的根底上，需要將所有模塊按設計要求組裝成系統(tǒng)。在經(jīng)過單元測試未發(fā)現(xiàn)錯誤的模塊，組裝之后仍可能出現(xiàn)各種問題。集成測試的根本方法：邊組裝邊測試。有自頂向下或自底向上兩種方法。(a)自頂向下測試從主控模塊開始，沿著模塊層次，邊組裝邊測試已組裝局部的功能，直到全部組裝完畢，系統(tǒng)到達設計的功能和性能要求為止。為保證測試的進行，必須提供保證測試條件的樁模塊。樁模塊：用來模擬被測模塊的下層模塊的模塊。再用實際的下層模塊代替樁模塊，并進行回歸測試?；貧w測試是相對于原始測試而言的，它局部或全部地重復前面進行過的測試工作。(b)自底向上測試與自頂向下測試相反，它先組裝最低層模塊，向上逐步組裝。每組裝一個模塊，便測試由此模塊及其下層模塊組成的子功能。直到全部裝配完畢，到達系統(tǒng)設計的功能和性能要求為止。為保證測試的進行，必須提供保證測試條件的“驅(qū)動程序〞。用實際的上層模塊代替該驅(qū)動程序。(3)確認測試：又稱有效性測試或驗收測試確認測試檢查系統(tǒng)的功能和性能是否到達系統(tǒng)分析說明書提出的設計指標，即是否滿足用戶要求，檢查文檔是否齊全等。確認測試發(fā)現(xiàn)軟件分析階段的錯誤。黑盒測試法是根據(jù)程序的功能和性能進行測試的方法。它把被測程序看成一個黑盒子，完全不考慮程序內(nèi)部的數(shù)據(jù)結(jié)構(gòu)和邏輯通路。也就是說，黑盒測試是在程序接口進行的測試，它只檢查程序功能和性能是否滿足預期需要，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)產(chǎn)生正確的輸出數(shù)據(jù)，并保持外部信息的完整性。產(chǎn)生黑盒測試的測試用例的方法有如下幾種：等價類劃分法邊界值分析法、因果圖法、錯誤推測法白盒測試法是根據(jù)程序的邏輯結(jié)構(gòu)進行測試的方法。它把程序看成是裝在一個透明的白盒中，也就是完全了解程序內(nèi)部的結(jié)構(gòu)和處理過程。這種方法按程序內(nèi)部的邏輯來測試程序，檢驗程序的每條通路是否都能按規(guī)定要求正確工作。產(chǎn)生白盒測試用例的方法有如下幾種：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋。一般而言，測試時以黑盒測試法為主，白盒測試法為輔。模塊間的耦合程度按從低到高分類如下:⑴無耦合。如果兩模塊之間沒有任何聯(lián)系，每一個都能獨立地工作而不需要另一模塊的存在，是彼此完全獨立的，那么這兩個模塊間屬于無耦合的情況。⑵數(shù)據(jù)耦合。如果兩個模塊是通過參數(shù)表僅傳遞數(shù)據(jù)型信息，那么這種耦合稱為數(shù)據(jù)耦合。數(shù)據(jù)耦合是松散的耦合，模塊間的獨立性較強。軟件結(jié)構(gòu)中至少有這種耦合。⑶特征耦合。假設兩個模塊通過參數(shù)表傳遞的是某一數(shù)據(jù)結(jié)構(gòu)的子結(jié)構(gòu)，而不是簡單變量，這就是特征耦合。是數(shù)據(jù)耦合的一種變種。增加出錯的時機，不易改動〔數(shù)據(jù)結(jié)構(gòu)變化時〕。將該數(shù)據(jù)結(jié)構(gòu)上的操作全部集中在一個模塊中，就可消除這種耦合。⑷控制耦合。如果傳遞控制型信息，這就是控制耦合。對被控制的模塊做任何修改，都會影響到控制模塊，降低模塊的獨立性。⑸公共耦合。假設一組模塊使用了公共數(shù)據(jù)，那么它們之間的耦合稱為公共耦合。公共數(shù)據(jù)包括全程變量、共享的通信區(qū)、內(nèi)存的公共覆蓋區(qū)等。公共數(shù)據(jù)的使用，必然降低軟件的可讀性、可修改性和可靠性。⑹內(nèi)容耦合。如果發(fā)生以下情況之一，兩個模塊間就是內(nèi)容耦合：?一個模塊直接訪問另一個模塊的內(nèi)部數(shù)據(jù)；?一個模塊通過不正常入口直接轉(zhuǎn)入另一模塊內(nèi)部；?一個模塊有多個入口；?兩模塊有一局部代碼重疊(只在匯編語言中出現(xiàn))；內(nèi)容耦合是耦合性最高的耦合，即是模塊間最壞的聯(lián)系方式，現(xiàn)在大多數(shù)高級程序設計語言中已經(jīng)不會出現(xiàn)這種耦合。在進行設計時應該采取以下原那么：以數(shù)據(jù)耦合為主，特征耦合為輔，少用控制耦合，限制公共耦合，杜絕內(nèi)容耦合。模塊的內(nèi)聚性按從低到高分類如下:⑴偶然內(nèi)聚。如果模塊中各組成成分間彼此沒有實質(zhì)聯(lián)系，即使有聯(lián)系也是很松散的，模塊功能模糊，那么稱為偶然內(nèi)聚。例如有時寫完一段程序后，發(fā)現(xiàn)一組語句在程序中多處出現(xiàn)，便將其組織在一個模塊內(nèi)以節(jié)省內(nèi)存，就出現(xiàn)了偶然內(nèi)聚的模塊。在模塊設計時，如果覺察一個模塊難以命名，就應考慮是否出現(xiàn)偶然內(nèi)聚。⑵邏輯內(nèi)聚。如果一個模塊完成的是邏輯上相同或相似的一組功能，那么稱為邏輯內(nèi)聚。例如，設計一個模塊打印各種報表，如固定資產(chǎn)報表、產(chǎn)品本錢報表、利潤報表等，打印何種報表靠傳遞控制參數(shù)調(diào)用。由于不同功能在一個模塊中，通常在設計模塊時會出現(xiàn)幾種功能共用局部代碼，從而使得修改、添加或去掉功能都很困難。⑶時間內(nèi)聚。假設一個模塊中包含的任務必須在同一時間內(nèi)執(zhí)行，而這些任務的次序無關(guān)緊要，那么叫時間內(nèi)聚。例如各種初始化工作由初始化模塊完成，而各種結(jié)束工作被組合到結(jié)束模塊中，這樣它的執(zhí)行將涉及到其它許多模塊。⑷過程內(nèi)聚。如果一個模塊內(nèi)的處理成分間是相關(guān)的，而且必須以特定順序執(zhí)行，那么稱為過程內(nèi)聚。例如把程序流程圖中的循環(huán)、判斷和計算分成三個模塊，那么這三個模塊就是過程內(nèi)聚的模塊。⑸通信內(nèi)聚。模塊內(nèi)的所有成分都通過公共數(shù)據(jù)而發(fā)生關(guān)系的內(nèi)聚就是通訊內(nèi)聚。例如對同一文件進行輸入、修改、輸出操作。模塊中各成分經(jīng)模塊的局部的公共數(shù)據(jù)進行通信。⑹順序內(nèi)聚。假設模塊中每個處理成分對應一個功能，且這些處理必須按順序執(zhí)行，那么稱為順序內(nèi)聚。例如一個處理成分的輸出是下一個處理成分的輸入的模塊就是順序內(nèi)聚。⑺功能內(nèi)聚。模塊中各處理成分屬于一個整體，都為了完成同一功能，很難分割，這就是功能內(nèi)聚。這種模塊通常有明確表達模塊功能的名稱。第四章軟件開發(fā)的面向?qū)ο蠓椒?0、與OO方法相比，傳統(tǒng)方法存在哪些問題。OO方法有哪些優(yōu)點。答：傳統(tǒng)方法存在以下問題：(1)對現(xiàn)實世界的認識與編程之間存在理解上的鴻溝；功能與數(shù)據(jù)相別離造成。(2)修改困難；系統(tǒng)是圍繞如何實現(xiàn)一定的行為進行，當需求變化時，數(shù)據(jù)常常發(fā)生變化，最終導致數(shù)據(jù)的結(jié)構(gòu)變化，難于修改。(3)維護困難；為了得到“好的軟件結(jié)構(gòu)〞，使作用域在控制域之中，導致系統(tǒng)總體結(jié)構(gòu)混亂，難于維護。(4)自頂向下功能分解的分析方法限制了軟件的可復用性。面向?qū)ο蠓椒ǖ膬?yōu)點(1)與人類習慣的思維方法一致核心是對象，它是現(xiàn)實世界實體的正確抽象。而傳統(tǒng)方法忽略了數(shù)據(jù)和操作之間的聯(lián)系。(2)穩(wěn)定性好它基于構(gòu)造問題領(lǐng)域的對象模型，以對象為中心構(gòu)造軟件系統(tǒng)，當功能發(fā)生需求變化時，不會引起軟件結(jié)構(gòu)的整體變化。而傳統(tǒng)方法基于功能分析和分解，以算法為核心，功能變化通常會引起軟件結(jié)構(gòu)的整體變化。(3)可重用性好對象類固有的封裝性和信息隱蔽以及很好的繼承機制，使得面向?qū)ο蠓椒ň哂泻芎玫目蓮陀眯?。傳統(tǒng)方法只是庫一級的復用。(4)可維護性好OO方法的模塊機制、繼承機制、多態(tài)性機制，使得設計的軟件易于理解、修改、測試，更易于維護。而傳統(tǒng)方法及其面向過程開發(fā)的軟件是難以維護的。11、找出問題域有關(guān)對象的兩種方法：LIA和3VM.簡述LIA和3VM及其作用，并比擬之。答：(1)基于語言的信息分析方法〔LIA〕主要思想：先對要建立的系統(tǒng)及其需求用自然語言描述，然后對這些描述進行語法分析。名詞對象，形容詞屬性，動詞效勞填進一張OOA/OOD工作表格。最后對表中的項進行分析，從中確定問題域中的對象。(2)三視圖模型法〔3VM〕觀察一個事物的角度不同，將得到不同的視圖。從多個角度觀察得到的同一個事物的多個視圖更能完整地、全面地反映該事物。LIA方法要求分析員從眾多的侯選對象中識別出目標系統(tǒng)的對象，這依賴于分析員的抽象和分析能力，隨意性大，可操作性不強。LIA方法提供了一個發(fā)現(xiàn)對象的出發(fā)點，一般將該方法用于對象模型建立的初始階段。3VM法也依賴于分析人員的抽象和分析能力，但運用建立3VM的方法，確實提供了分析對象的入口點和細化的方法，具有相對較好的操作性。該方法一般用于對象模型的細化。12、分析電梯到達調(diào)度樓層的事件-響應對象交互圖、實例連接圖。電梯到達調(diào)度樓層的事件-響應對象交互圖PPT第四章931．當電梯到達某一樓層時，就會產(chǎn)生一個電梯到達事件ArrivalEvent。其屬性有：該到達事件的唯一標識：arrival_id生成到達事件的電梯：elevator_id生成該到達事件的樓層：arrival_floor2．電梯到達事件生成后，將會向與elevator_id相關(guān)聯(lián)的到達面板發(fā)送一個單向的消息，該消息是：〔arrival_floor〕〔電梯elevator_id所到達的樓層〕與elevator_id相關(guān)聯(lián)的到達面板根據(jù)收到的消息刷新到達面板的顯示3．電梯到達事件將會向與floor_id相關(guān)聯(lián)的floor發(fā)送一個單向的消息，該消息是：(到達事件的唯一標識,電梯唯一標識，到達的樓層號)〔arrival_id,report_elevator_id,report_arrival_floor_id)4.樓層Floor收到上述消息后，由效勞Floor.Process_Elevator_Arrival_處理。該效勞將向電梯report_elevator_id發(fā)送一個雙向的消息：(report_status_direction?,report_current_direction?)電梯report_elevator_id收到該消息后，會有相應的效勞Elevator.Report_Status_Direction和levator.Report_Current_Direction效勞向樓層Floor報告電梯當前的運行方向和狀態(tài)方向。5.Floor發(fā)給與report_elevator_id所關(guān)聯(lián)的電梯的目的面板一個雙向消息：(report_arrival_floor,destination_pending_above?,destination_pending_beloow?)目的面板收到該消息后，即可知道樓層report_arrival_floor是否是調(diào)度樓層。6.Floor發(fā)給與arrival_floor所關(guān)聯(lián)的召喚面板一個雙向消息：(report_summons_pending_up?report_summons_pending_down?)該樓層的召喚面板收到該消息后，相應的效勞即可報告該樓層的召喚請求是上、下或是沒有請求。知道該樓層是否有召喚，以及電梯的狀態(tài)方向和當前運行方向等信息，即可判定該樓層是否是調(diào)度樓層。7.如果是調(diào)度樓層〔這里假設是該樓層的召喚導致的〕，那么(1)Floor向與其相關(guān)聯(lián)的召喚面板對象發(fā)消息，使其刷新面板;〔2〕向與report_elevator_id所關(guān)聯(lián)的電梯發(fā)消息。電梯接受到消息后，更新其當前狀態(tài)(current_status)、(current_direction)、(status_direction)等;〔3〕電梯向與其關(guān)聯(lián)的電梯電機對象發(fā)送停止消息〔Stop〕。8.到達事件結(jié)束。實例連接圖:實例連接分類有3種類型的實例連接：(1)一對一型:一個對象只依賴于另外一個對象。如一個飛行員駕駛一架飛機。(2)一對多型：一個對象同時依賴多個對象。如一個教師指導5個學生的畢業(yè)設計。(3)多對多型：相互依賴的對象數(shù)在一個以上。如全班30名學生學習6門課程。對以下圖分析13、在Coad和Yourdon的OOD中，從哪四個方面對OOA進行了擴充，簡述其內(nèi)容。答：Coad和Yourdon提出從以下四個方面考慮：(1)問題域局部(ProblemDomainComponent，PDC)問題域局部是為了消除系統(tǒng)的存貯容量無限及對象間的通信速度無限快等假設的。(2)人-機接口局部(HumanInterfaceComponent，HIC)人-機接口局部是為了將系統(tǒng)和外界的通信任務由特定的對象承當，使得系統(tǒng)的功能和實現(xiàn)相別離。這樣，如果系統(tǒng)與外界的接口發(fā)生改變時，只需要改變這局部對象即可。(3)任務管理局部〔TaskManagementComponent，TMC〕任務管理局部是為了將系統(tǒng)和具體的操作系統(tǒng)提供的任務調(diào)用由特定的對象來承當。如果操作系統(tǒng)的環(huán)境改變，只需要改變這局部對象即可。(4)數(shù)據(jù)庫管理局部(DatabaseManagementComponent，DMC)數(shù)據(jù)庫管理局部為了將系統(tǒng)和由特定數(shù)據(jù)庫系統(tǒng)所管理的數(shù)據(jù)的訪問有特定的對象來承當。如果系統(tǒng)所應用到的一些由數(shù)據(jù)庫管理的數(shù)據(jù)，而數(shù)據(jù)庫的類型或結(jié)構(gòu)發(fā)生改變時，只需要改變這局部對象。14、分析電梯控制系統(tǒng)中召喚事件和圖書管理系統(tǒng)中借閱事件的完整執(zhí)行機制。當按鈕按下時，將產(chǎn)生一個中斷，即“所發(fā)出的信號〞中應包含樓層的信息或編碼，這個編碼應存放到該中斷對應的中斷存放器中。圖書管理系統(tǒng)中借閱事件的完整執(zhí)行機制。借閱一本書的過程，涉及了三個實體：“Reader〞實體存儲借閱者；“Book〞實體存儲書；“Reader-Book〞存儲某個借閱者借閱某本書的記錄。對象“Borrow〞來負責處理“借閱〞事件。第五章統(tǒng)一建模語言UML與實例15、簡述UML中的狀態(tài)圖和活動圖以及它們之間的差異。答：〔1〕狀態(tài)圖：狀態(tài)機對類的對象可能生命歷史建模。狀態(tài)機用來描述一個特定對象的所有可能狀態(tài)及其引起狀態(tài)轉(zhuǎn)移的事件。狀態(tài)描述了一個類對象生命期中的一個時間段，對對象生命期中的一段時間建模，該時間內(nèi)對象滿足一定的條件。當事件發(fā)生時，它可能導致遷移的激發(fā)，使對象改變至新狀態(tài)。當遷移激發(fā)時，附屬于遷移的移動可能被執(zhí)行。狀態(tài)機顯示為狀態(tài)圖(StateDiagram)。狀態(tài)圖可用于描述用戶界面、設備控制和其它交互式子系統(tǒng)。狀態(tài)機和OOA中的狀態(tài)遷移圖一致?！?〕活動圖：活動圖顯示動作及其結(jié)果?；顒訄D著重描述操作(方法)實現(xiàn)中所完成的工作以及用例實例或?qū)ο笾械幕顒印；顒訄D是另一種描述交互的方式，描述采取何種動作，做什么(對象狀態(tài)改變)，何時發(fā)生(動作序列)。差異：活動圖描述動作執(zhí)行的工作和活動及對象狀態(tài)改變的結(jié)果，不需指定任何事件。當狀態(tài)中的動作被執(zhí)行(不象狀態(tài)圖需指定任何事件)時，活動圖中的狀態(tài)〔稱為動作狀態(tài)〕直接轉(zhuǎn)移到下一個階段?；顒訄D可以用作下述目的：(1)描述操作執(zhí)行過程中所完成的工作(動作)；(2)描述對象內(nèi)部的工作；(3)顯示如何執(zhí)行一組相關(guān)的動作，以及這些動作如何影響它們周圍的對象；(4)顯示用例的實例是如何執(zhí)行動作以及如何改變對象狀態(tài)；(5)說明一次商務活動中的角色、工作流組織和對象是如何工作的。16、理解、分析和繪制UML的各種視圖(戲院管理系統(tǒng)、汽車租賃系統(tǒng)、教學管理系統(tǒng)等)。戲院管理系統(tǒng)：PPT第五章：用例圖〔23〕、類圖(32)、順序圖〔36〕協(xié)作圖〔39〕、狀態(tài)圖：〔42〕、活動圖〔46〕教學管理系統(tǒng)：PPT第五章用例圖〔71、72〕、類圖(78、79)、順序圖〔86、87〕、協(xié)作圖〔88〕、狀態(tài)圖：〔89、90〕、活動圖〔91〕第六章面向?qū)ο箝_發(fā)中的設計模式17、簡述設計模式的作用、設計模式的四個根本要素。答：作用：有經(jīng)驗的軟件員總是將面向?qū)ο筌浖O計的經(jīng)驗記錄成“設計模式〞，以便在今后的軟件開發(fā)中復用以往的成功設計。四個根本要素：模式名稱、問題、解決方案和后果〔1〕模式名稱：通常用來描述一個設計問題、它的解法和后果，由一到兩個詞描述。模式名稱可以在更高的抽象層次上進行設計并交流設計思想?！?〕問題：描述模式使用的時間、條件、解釋問題及其背最。它可能描述諸如如何將一個算法表示成一個對象這樣的特殊設計問題?！?〕解決方案：描述設計的根本組成要素，如它們的關(guān)系、各自的任務以及相互之間的合作。它并非針對某個特殊問題。設計模式提供有關(guān)設計問題的一個抽象描述以及如何安排這些根本要素以解決問題?！?〕后果：描述應用設計模式后的結(jié)果和利弊。對于軟件設計來說，通常要考慮的是空間和時間的權(quán)衡，還有語言問題和實現(xiàn)問題。對于OO設計，可重用性很重要。此外，后果還包括對系統(tǒng)靈活性、可擴充性及可移植性的影響。18、理解ModelView合約。答：〔1〕形式合約是一種描述框架設計的方法，它強調(diào)組成框架的對象間的交互關(guān)系?！?〕形式合約的特點：①符號少且能映射到OO編程語言中的概念，如參與者映射到對象。②考慮到了復雜行為由簡單行為組成的事實，合約的修訂和擴充操作使得合約靈活，易于應用?！?〕形式合約的根本元素：參與者：形式合約的第一個組成局部。對每個參與者要規(guī)定它應承當?shù)呢熑?。責任有：類型責任：與實例變量和方法有關(guān)的責任。因果責任：描述與類型責任相關(guān)的操作與條件“->〞:表示方法調(diào)用。如s->Update()表示對Subscribers中的方法Update()的調(diào)用?！皏〞:表示對實例變量v賦值?！?lt;ov:c:e>〞:表示用操作符o將所有滿足條件c的變量v所構(gòu)成的表達式e連接起來。如<||s:s∈Subscriber:s->Update()>意味著s1->Update()||s2->Update()||...,即對Subscriber集合中的所有對象發(fā)送Update()消息。“{}〞:表示參與者必須滿足的條件的說明。如AttachSubscriber(s:Subscriber)=>{s∈Subscriber}:表示一個條件，s是Subscriber集合的成員在以s為參數(shù)執(zhí)行AttachSubscriber后必須為真。19、簡述選擇設計模式的方法。答：設計模式依據(jù)其目的可分為創(chuàng)立型、結(jié)構(gòu)型、行為型三種。共23個模式下面是幾個幫助選擇設計模式的方法：·考慮設計模式是怎樣解決設計問題的：對設計模式的討論，能幫助找到適宜的對象、決定對象的粒度、指定對象接口以及設計模式解決設計問題的幾個其他方法。·瀏覽模式的意圖局部：通讀每個模式的意圖，找出和問題相關(guān)的一個或多個模式?？梢允褂们氨硭@示的分類方法縮小搜查范圍?！ぱ芯磕Ｊ皆鯓踊ハ嚓P(guān)聯(lián)：前圖以圖形方式顯示了設計