計(jì)算機(jī)水平考試中級軟件設(shè)計(jì)師2012年下半年下午真題

1、計(jì)算機(jī)水平考試中級軟件設(shè)計(jì)師2012年下半年下午真題（總分：225.00，做題時(shí)間：150分鐘）試題試題一（共15分）閱讀下列說明和圖，回答問題 1至問題4,將解答填入答題紙的對應(yīng)欄內(nèi)。說明某電子商務(wù)系統(tǒng)采用以數(shù)據(jù)庫為中心的集成方式改進(jìn)購物車的功能，詳細(xì)需求如下：1 加入購物車。顧客瀏覽商品，點(diǎn)擊加入購物車，根據(jù)商品標(biāo)識從商品表中讀取商品信息，并更新購物車表。2 瀏覽購物車。顧客提交瀏覽購物車請求后，顯示岀購物車表中的商品信息。3 .提交訂單。顧客點(diǎn)擊提交訂單請求，后臺計(jì)算購物車表中商品的總價(jià)（包括運(yùn)費(fèi)）加入訂單表，將購物車表中的商品狀態(tài)改為待付款，顯示訂單詳 情。若商家改變價(jià)格，則刷新后可看

2、到更改后的價(jià)格。4.改變價(jià)格。商家查看訂購自家商品的訂單信息，根據(jù)特殊優(yōu)惠條件修改價(jià)格，更新訂單表中的商品價(jià)格。5 付款。顧客點(diǎn)擊付款后，系統(tǒng)先根據(jù)顧客表中關(guān)聯(lián)的支付賬戶，將轉(zhuǎn)賬請求 （驗(yàn)證碼、價(jià)格等）提交給支付系統(tǒng)（如信用卡系統(tǒng)）進(jìn)行轉(zhuǎn)賬：然后根據(jù)轉(zhuǎn) 賬結(jié)果返回支付狀態(tài)并更改購物車表中商品的狀態(tài)。6 物流跟蹤。商家發(fā)貨后，需按訂單標(biāo)識添加物流標(biāo)識（物流公司、運(yùn)單號）；然后可根據(jù)顧客或商家的標(biāo)識以及訂單標(biāo)識，查詢訂單表中的物流標(biāo)識，并從 相應(yīng)物流系統(tǒng)查詢物流信息。7 .生成報(bào)表。根據(jù)管理員和商家設(shè)置的報(bào)表選項(xiàng)，從訂單表、商品表以及商品分類表中讀取數(shù)據(jù)，調(diào)用第三方服務(wù) Crystal Repor

3、ts生成相關(guān)報(bào)表。8.維護(hù)信息。管理員維護(hù)（增、刪、改、查）顧客表、商品分類表和商品表中的信息?，F(xiàn)采用結(jié)構(gòu)化方法實(shí)現(xiàn)上述需求，在系統(tǒng)分析階段得到如圖1-1所示的頂層數(shù)據(jù)流圖和圖 1-2所示的0層數(shù)據(jù)流圖。丨 （分?jǐn)?shù)：15.00 ）（1）.問題1（4分）使用說明中的詞語，給出圖 1-1中的實(shí)體E1E4的名稱。（分?jǐn)?shù)：3.75 ） 正確答案：（E1 :商家E2 :支付系統(tǒng)E3 :物流系統(tǒng)E4 : Crystal Reports 或第三方服務(wù)）解析：本題考查采用結(jié)構(gòu)化方法進(jìn)行系統(tǒng)分析與設(shè)計(jì)，主要考查數(shù)據(jù)流圖（DFD）的應(yīng)用，是比較傳統(tǒng)的題目，要求考生細(xì)心分析題目中所描述的內(nèi)容。DFD是一種便于用戶理

4、解、分析系統(tǒng)數(shù)據(jù)流程的圖形化建模工具，是系統(tǒng)邏輯模型的重要組成部分。本問題考查頂層 DFD頂層DFD般用宋確定系統(tǒng)邊界，將待開發(fā)系統(tǒng)看作一個(gè)加工，圖中只有唯一的一個(gè)處理和一些外部實(shí)體，以及這兩者之間的輸入輸出數(shù)據(jù)流。題 目要求根據(jù)描述確定圖中的外部實(shí)體。外部實(shí)體可以是和系統(tǒng)交互的人，以及和系統(tǒng)交互的外部系統(tǒng)或服 務(wù)。分析題目中的描述，并結(jié)合已經(jīng)在頂層數(shù)據(jù)流圖中給岀的數(shù)據(jù)流進(jìn)行分析。分析題目中的說明，管理 員維護(hù)系統(tǒng)中信息，顧客和商家是系統(tǒng)的主要使用者；商家查看訂購自家商品的訂單信息，根據(jù)特殊優(yōu)惠 條件修改價(jià)格，更新訂單表中的商品價(jià)格，還可以添加物流標(biāo)識并進(jìn)行物流跟蹤；使用支付系統(tǒng)進(jìn)行支付，通過

5、物流系統(tǒng)進(jìn)行物流跟蹤，以及第三方服務(wù)Crystal Report生成報(bào)表?？梢钥闯?，和系統(tǒng)的交互者包括管理員、顧客、商家三類人，支付系統(tǒng)、物流系統(tǒng)和Crystal Report 三種外部系統(tǒng)。 對應(yīng)圖1-1中數(shù)據(jù)流和實(shí)體的對應(yīng)關(guān)系，管理員和顧客已經(jīng)給出，可知E1為商家，E2為支付系統(tǒng)，E3為物流系統(tǒng)，E4為第三方服務(wù) Crystal Report 。.問題2（4分）使用說明中的詞語，給出圖 1-2中的數(shù)據(jù)存儲D1D4的名稱。（分?jǐn)?shù)：3.75 ） 正確答案：（D1 :訂單表D2 :商品表D3 :商品分類表 D4 :購物車表）解析：本問題考查0層DFD中數(shù)據(jù)存儲的確定。根據(jù)說明中所描述的處理和相關(guān)

6、數(shù)據(jù)存儲之間的連接關(guān)系， 判定每個(gè)數(shù)據(jù)存儲。加入購物車和瀏覽購物車分別讀取和更新購物車表中的數(shù)據(jù)：改變價(jià)格和提交訂單要 讀取和更新訂單表中的數(shù)據(jù)；維護(hù)信息時(shí)需要維護(hù)商品表和商品分類表，生成報(bào)告要讀取商品表和商品分 類表，加入購物車時(shí)，需要讀取商品表中的商品信息。根據(jù)描述和圖1-2中的數(shù)據(jù)存儲的輸入輸岀數(shù)據(jù)流提示，可知：D1為訂單表，D2為商品表，D3為商品分類表，D4為購物車表。（3）.問題3（4分）圖1-2中缺失了數(shù)據(jù)流，請用說明或圖 l-2中的詞語，給出其起點(diǎn)和終點(diǎn)。（分?jǐn)?shù):3.75 ）me正確答案：（I）解析：本問題考查繪制0層DFD時(shí)是否將本層該繪制的數(shù)據(jù)流全部繪制岀。對照項(xiàng)層數(shù)據(jù)流圖

7、和0層數(shù)據(jù)流圖，檢查是否和外部實(shí)體之間的數(shù)據(jù)流一致；仔細(xì)對照說明中的描述和圖1-2中給出的數(shù)據(jù)流，檢查是否遺漏掉信息。說明中：提交訂單處理時(shí)，后臺計(jì)算購物車表中的商品的總價(jià)，即需要讀岀購物車表中的 相關(guān)價(jià)格進(jìn)行計(jì)算，讀取岀其中數(shù)據(jù)；付款需要讀取顧客表中關(guān)聯(lián)的支付賬戶，并向支付系統(tǒng)提交轉(zhuǎn)賬請 求，然后根據(jù)轉(zhuǎn)賬結(jié)果更改購物車表中商品的狀態(tài)：生成報(bào)告時(shí)根據(jù)管理員和商家設(shè)置的報(bào)告選項(xiàng)，從訂 單表、商品表以及商品分類表中讀取數(shù)據(jù)，再調(diào)用第三方服務(wù)Crystal Reports生成相關(guān)報(bào)告。將這些說明和圖1-2進(jìn)行對照，發(fā)現(xiàn)缺少了從付款到購物車表（D4）、從購物車表到提交訂單、從顧客表到付款，以及從訂單表

8、（D1）到生成報(bào)表等4條數(shù)據(jù)流。（4）.問題4（3分）根據(jù)說明，給出數(shù)據(jù)流“轉(zhuǎn)賬請求”、“顧客訂單物流查詢請求”和“商家訂單物流 查詢請求”的各組成數(shù)據(jù)項(xiàng)。（分?jǐn)?shù)：3.75 ） 正確答案：（轉(zhuǎn)賬請求=驗(yàn)證碼+價(jià)格+賬號信息顧客訂單物流查詢請求=顧客標(biāo)識 +訂單標(biāo)識商家訂單物 流查詢請求=商家標(biāo)識 +訂單標(biāo)識）解析：本問題考查在繪制數(shù)據(jù)流圖時(shí)數(shù)據(jù)流的數(shù)據(jù)項(xiàng)組成。數(shù)據(jù)流圖描述了系統(tǒng)的分解，但它并沒有給岀 圖中各成分的說明。通常采用數(shù)據(jù)字典為數(shù)據(jù)流圖中的每個(gè)數(shù)據(jù)流、文件、處理，以及組成數(shù)據(jù)流或文件 的數(shù)據(jù)項(xiàng)做岀說明。對于數(shù)據(jù)流，通常列岀該數(shù)據(jù)流的各組成數(shù)據(jù)項(xiàng)，并采用數(shù)據(jù)字典定義式中岀現(xiàn)的符 號進(jìn)行表

9、示，如“=”表示“被定義為”，“+”表示“與”“ ”表示其中數(shù)據(jù)可以有多個(gè)等等。本試題說明中；付款時(shí)，需根據(jù)顧客表中關(guān)聯(lián)的支付賬戶將轉(zhuǎn)賬請求（驗(yàn)證碼、價(jià)格等）提交給支付系統(tǒng)：物流跟蹤時(shí)，根據(jù)顧客和商家的標(biāo)識以及訂單標(biāo)識進(jìn)行查詢，而且在改變價(jià)格時(shí)商家查看訂購自家商品的訂 單信息，可知商家可以查詢一批訂單。 可以看岀，提交給支付系統(tǒng)的請求中包含支付賬戶、驗(yàn)證碼與價(jià)格；顧客訂單查詢請求中有顧客標(biāo)識、訂單標(biāo)識：商家訂單查詢請求中有商家標(biāo)識、訂單標(biāo)識（一批訂購自家商品的訂單標(biāo)識）。因此“轉(zhuǎn)賬請求=支付賬戶 +驗(yàn)證碼+價(jià)格”；“商家訂單物流查詢請求=物流標(biāo)識 +訂單 標(biāo)識 ”； “顧客訂單物流標(biāo)識=物流標(biāo)

10、識+訂單標(biāo)識”。試題二（共15分）閱讀下列說明和圖，回答問題 1至問題3,將解答填入答題紙的對應(yīng)欄內(nèi)。說明某會議策劃公司為了方便客戶，便于開展和管理各項(xiàng)業(yè)務(wù)活動，需要構(gòu)建一個(gè)基于網(wǎng)絡(luò)的會議預(yù)定系統(tǒng)。需求分析1 會議策劃公司設(shè)有受理部、策劃部和其他部門。部門信息包括部門號、部門名稱、部門主管、 電話和郵箱號。每個(gè)部門有多名員工處理部門的日常事務(wù)，每名員工只能在一個(gè)部門工作。每個(gè)部門有一 名主管負(fù)責(zé)管理本部門的事務(wù)和人員。2員工信息包括員工號、姓名、部門號、職位、聯(lián)系方式和工資；其中，職位包括主管、業(yè)務(wù)員、策劃員等。業(yè)務(wù)員負(fù)責(zé)受理會議申請。若申請符合公司規(guī)定，則置受理標(biāo) 志并填寫業(yè)務(wù)員的員工號。策

11、劃部主管為已受理的會議申請制定策劃任務(wù)，包括策劃內(nèi)容、參與人數(shù)、要 求完成時(shí)間等。一個(gè)已受理的會議申請對應(yīng)一個(gè)策劃任務(wù)，一個(gè)策劃任務(wù)只對應(yīng)一個(gè)己受理的會議申請， 但一個(gè)蛾IJ任務(wù)可由多名策劃員參與執(zhí)行，且一名策劃員可以參與多項(xiàng)策劃任務(wù)。3 客戶信息包括客戶號、單位名稱、通信地址、所屬省份、聯(lián)系人、聯(lián)系電話、銀行賬號。其中，一個(gè)客戶號唯一標(biāo)識一個(gè)客 戶。一個(gè)客戶可以提交多個(gè)會議申請，但一個(gè)會議申請對應(yīng)唯一的一個(gè)客戶號。4 會議申請信息包括申請?zhí)?、開會日期、會議地點(diǎn)、持續(xù)天數(shù)、會議人數(shù)、預(yù)算費(fèi)用、會議類型、酒店要求、會議室要求、客房類型、客房數(shù)、聯(lián)系人、聯(lián)系方式、受理標(biāo)志和業(yè)務(wù)員的員工號等?？头款?/p>

12、型有豪華套房、普通套房、標(biāo)準(zhǔn)間、三人間等，且申請?zhí)柡涂头款愋蜎Q定客房數(shù)。概念模型設(shè)計(jì)根據(jù)需求階段收集的信息，設(shè)計(jì)的實(shí)體聯(lián)系圖和關(guān)系模式（不完整）如下:箱號）員工（員工號，姓名， （a）_關(guān)系模式設(shè)計(jì)部門（部門號，部門名稱，主管，電話，郵 ，聯(lián)系方式，工資）客戶（客戶號，單位名稱，通信地址，所屬省份，聯(lián)系人，聯(lián)系電話，銀行賬號 ）會議申請（_（b）_，開會日期，會議地點(diǎn)，持續(xù)天數(shù)，會議人數(shù)， 預(yù)算費(fèi)用會議類型，酒店要求，會議室要求，客房數(shù)，聯(lián)系人，聯(lián)系方式，受理標(biāo)志，員工號）策劃任務(wù)（c），策劃內(nèi)容，參與人數(shù)，要求完成時(shí)間）執(zhí)行策劃（d），實(shí)際完成時(shí)間）（分?jǐn)?shù):15.00 ）（1）.問題1（5分

13、）根據(jù)問題描述，補(bǔ)充五個(gè)聯(lián)系、聯(lián)系的類型，完善圖2-1的實(shí)體聯(lián)系圖。（分?jǐn)?shù)：5.00 ）解析：本題考查數(shù)據(jù)庫設(shè)計(jì)方面的應(yīng)用知識。根據(jù)題意，一個(gè)客戶可以提交多個(gè)會議申請，但一個(gè)會議申請對應(yīng)唯一的一個(gè)客戶號， 故應(yīng)在客戶和會議申請之間增加一個(gè)1： n的“提交”聯(lián)系；由于業(yè)務(wù)員負(fù)責(zé)受理會議申請，若申請符合公司規(guī)定則置受理標(biāo)志并填寫業(yè)務(wù)員的員工號，因此業(yè)務(wù)員和會議申請之間有一個(gè)1: n的“受理”聯(lián)系；由于一個(gè)已受理的會議申請對應(yīng)一個(gè)策劃任務(wù)，一個(gè)策劃任務(wù)只對應(yīng)一個(gè)已受理的會議申請，但一個(gè)策劃任務(wù)可由多名策劃員參與執(zhí)行，且一名策劃員可以參與多項(xiàng)策劃任務(wù)，因此策 劃任務(wù)和策劃員之間有一個(gè) n: m的“執(zhí)行

14、”聯(lián)系：由于每個(gè)部門有多名員工處理部門的日常事務(wù)，每名員工只能在一個(gè)部門工作，因此部門和員工之間有一個(gè)1: n的“所屬”聯(lián)系：又由于每個(gè)部門有一名主管負(fù)責(zé)管理本部門的事務(wù)和人員，而該主管也是一名員工，因此主管和部門之間有一個(gè)1:1的“管理”聯(lián)系。根據(jù)上述分析，完善圖 2-1所示的實(shí)體聯(lián)系圖可參見參考答案。.問題2（7分）根據(jù)實(shí)體聯(lián)系圖，將關(guān)系模式中的空（a）（d）補(bǔ)充完整（1個(gè)空缺處可能有多個(gè)數(shù)據(jù)項(xiàng)） 對會議申請、策劃任務(wù)和執(zhí)行策劃關(guān)系模式，用下劃線和參分別指岀各關(guān)系模式的主鍵和外鍵。（分?jǐn)?shù):5.00 ）正確答案：（a）部門號，職位（b）申請?zhí)?，客房類型，客戶號（c）申請?zhí)?，員工號（d）申請?zhí)?/p>

15、，員工號& nbsp關(guān)系模式為：&nbsp會議申請（申請?zhí)?，客房類型，客戶?#，開會日期，會議地點(diǎn)，持續(xù)天數(shù)，會議人數(shù)，預(yù)算 費(fèi)用，會議類型，酒店要求，會議室要求，客房數(shù)，聯(lián)系人，聯(lián)系方式，受理標(biāo)志，員工號#）&nbsp策劃任務(wù)（申請?zhí)?，員工號#，策劃內(nèi)容，參與人數(shù)，要求完成時(shí)間）&nbsp執(zhí)行策劃（申請?zhí)?,員工號#，實(shí)際完成時(shí)間）解析：根據(jù)題意，在員工關(guān)系模式中，部門與員工之間是一個(gè)1： n的聯(lián)系，需要將1端（即部門）的碼“部 門號"并入員工關(guān)系；又因?yàn)槊總€(gè)員工擔(dān)任相應(yīng)職位，故員工關(guān)系模式歡迎添加"職位”屬性；可見，空（a）應(yīng)填寫“部

16、門號，職位”。 在會議申請關(guān)系模式中，由于申請?zhí)枴⒖头款愋?、客戶號為主鍵，故空（b）應(yīng)填寫“申請?zhí)枺头款愋?，客戶號”：在策劃任?wù)關(guān)系模式中，申請?zhí)?、員工號為主鍵，故空（c）應(yīng)填寫“申請?zhí)?，客戶號”：由于一個(gè)策劃任務(wù)可由多名策劃員參與執(zhí)行，且一名策劃員可以參與多項(xiàng)策劃任務(wù)，故在執(zhí)行策劃關(guān)系模式中，執(zhí)行策劃又由于一個(gè)業(yè)務(wù)員可以安排多個(gè)托運(yùn)申請，申請?zhí)?、員工號為主鍵， 故空（d）應(yīng)填寫“申請?zhí)枺蛻籼枴?。會議申請關(guān)系模式的主鍵為“申請?zhí)?，客房類型”，因?yàn)?，申請?zhí)枴⒖头款愋湍芪ㄒ粯?biāo)識該關(guān)系模式的每一個(gè)元組。會議申請關(guān)系模式的外鍵為客戶號及員工號，因?yàn)?，客?號及員工號分別為客戶及員工關(guān)系模式的主鍵，

17、故為該關(guān)系模式的外鍵。策劃任務(wù)關(guān)系模式的主鍵為申請?zhí)?，因?yàn)椋暾執(zhí)柲芪ㄒ粯?biāo)識該關(guān)系模式的每一個(gè)元組，故申請?zhí)枮樵撽P(guān)系模式的主鍵。策劃任務(wù)關(guān)系模 式的外鍵為員工號，因?yàn)椋瑔T工號為員工關(guān)系模式的主鍵，故為該關(guān)系模式的外鍵。執(zhí)行策劃關(guān)系模式的主鍵為“申請?zhí)?，員工號”，因?yàn)椋暾執(zhí)柤皢T工號能唯一標(biāo)識該關(guān)系模式的每一個(gè)元組，故“申請?zhí)枺?員工號”為該關(guān)系模式的主鍵。執(zhí)行策劃關(guān)系模式的外鍵為申請?zhí)柤皢T工號，因?yàn)椋暾執(zhí)柡蛦T工號分別 為會議申請和員工關(guān)系模式的主鍵，故為該關(guān)系模式的外鍵。（3）.問題3（3分）請說明關(guān)系模式“會議申請”存在的問題及解決方案。（分?jǐn)?shù)：5.00 ）正確答案：（會議申請存在數(shù)據(jù)冗余

18、及數(shù)據(jù)修改的不一致性問題，應(yīng)該將關(guān)系模式分解為如下兩個(gè)模式：會議申請1（申請?zhí)枺蛻籼?，開會日期，會議地點(diǎn)，持續(xù)天數(shù)，會議人數(shù)，預(yù)算費(fèi)用，會議類型，酒店要求， 會議室要求，聯(lián)系人，聯(lián)系方式，受理標(biāo)志，員工號 ）會議申請2（申請?zhí)?，客房類型，客房?shù)）。） 解析：關(guān)系模式“會議申請”存在數(shù)據(jù)冗余及數(shù)據(jù)修改的不一致性問題，應(yīng)該將關(guān)系模式分解，分解后的 關(guān)系模式參見參考答案。試題三（15分）閱讀下列說明和圖，回答問題 1至問題3,將解答填入答題紙的對應(yīng)欄內(nèi)。說明某城市的各國家公園周邊建造了許多供游客租用的小木屋和營地，為此，該城市設(shè)置了一個(gè)中心售票處和若干個(gè) 區(qū)域售票處。游客若想租用小木屋或營地，必須

19、前往中心售票處進(jìn)行預(yù)定并用現(xiàn)金支付全額費(fèi)用。所有的 預(yù)定操作全部由售票處的工作人員手工完成。現(xiàn)欲開發(fā)一信息系統(tǒng)，實(shí)現(xiàn)小木屋和營地的預(yù)定及管理功能，以取代手工操作。該系統(tǒng)的主要功能描述如下：1 管理預(yù)定申請。游客可以前往任何一個(gè)售票處提岀預(yù)定申請。系統(tǒng)對來自各個(gè)售票處的預(yù)定申請進(jìn)行統(tǒng)一管理。2 預(yù)定。預(yù)定操作包含登記游客預(yù)定信息、計(jì)算租賃費(fèi)用、付費(fèi)等步驟。3 支付管理。游客付費(fèi)時(shí)可以選擇現(xiàn)金和信用卡付款兩種方式。使用信用卡支付可以享受3%的折扣，現(xiàn)金支付沒有折扣。4 游客取消預(yù)定。預(yù)定成功之后，游客可以在任何時(shí)問取消預(yù)定，但需支付賠償金，剩余部分則退還給游客。賠償金的計(jì)算規(guī)則是，在預(yù)定入住時(shí)間之

20、前的48小時(shí)內(nèi)取消，支付租賃費(fèi)用10%的賠償金；在預(yù)定入住時(shí)間之后取消，則支付租賃費(fèi)用50%的賠償金。5.自 動取消預(yù)定。如果遇到惡劣天氣 (如暴雨、山洪等)，系統(tǒng)會自動取消所有的預(yù)定，發(fā)布取消預(yù)定消息，全 額遲款。6 信息查詢。售票處工作人員查詢小木屋和營地的預(yù)定情況和使用情況，以判斷是否能夠批準(zhǔn)（分?jǐn)?shù)：15.00 ）游客的預(yù)定申請?，F(xiàn)采用面向?qū)ο蠓椒ㄩ_發(fā)上述系統(tǒng)，得到如表3-1所示的用例列表和表 3-2所示的類列表。對應(yīng)的用例圖和類圖分別如圖3-1和3-2所示。5.00 ）(1).問題1(6分)根據(jù)說明中的描述與表 3-1，給出圖3-1中UCIUC6處所對應(yīng)的用例名稱。(分?jǐn)?shù):正確答案：(

21、)解析：本題要求將圖3-1所給出的用例圖補(bǔ)充完整。題目說明中已經(jīng)給出了所有可能的用例的列表(如表3-1所示)。這就省去了尋找用例的步驟，只需要依據(jù)用例列表中給出的用例，在說明中確定用例與Actor之間的關(guān)系即可將圖補(bǔ)充完整。用例圖的構(gòu)成要素有：參與者 (Actor)、用例(Usecase)以及用例之間的關(guān)系。題目中的信息系統(tǒng)的主要用戶是售票處的工作人員(Ticketing Officer) ，所以在圖3-1中只給出了 1個(gè)參與者。由說明可知，售票處工作人員利用該系統(tǒng)可以實(shí)現(xiàn)6個(gè)主要的功能：管理預(yù)定申請(Manageinquiries)、預(yù)定(MakeReservation)、支付管理(Mana

22、gePayment)、游客取消預(yù)定 (CancelReservation)、自動取消預(yù)定(AutoCancelReservation)和信息查詢(CheckAvailability) 。其中“管理預(yù)定申請”、“支付管理”、“游客取消預(yù)定”、“自動取消預(yù)定”和“支付管理”均已經(jīng)岀現(xiàn)在 圖3-1中。支付租賃費(fèi)用是預(yù)定過程中的一個(gè)必要步驟，而UC2和“交付管理”之間又是“include ”關(guān)系，可以推斷出UC2應(yīng)該對應(yīng)用例“預(yù)定(MakeReservation) ”。那么用例“管理預(yù)定申請”和“預(yù)定”具有的 相同步驟就是UCl所對應(yīng)的用例，由此推斷出UCl對應(yīng)用例“信息查詢(CheckAvailab

23、ility) ”。 由功能“支付管理”的說明可知，它具備兩個(gè)能力：管理支付方式(信用卡或現(xiàn)金)以及計(jì)算折扣。UC4和 UC5與用例“支付管理”之間是概括關(guān)系，說明UC4和UC5是支付方式的兩個(gè)特化，所以UC4為“現(xiàn)金支付(MangeCashPaynent)”，UC5為“信用卡支付(ManageCrCardPayment)"。UC3對應(yīng)“計(jì)算折扣(GetDiscount) ”。 這時(shí)用例列表中只剩下用例CalcuateRefund(計(jì)算取消預(yù)定的賠償金)沒有出現(xiàn)在圖中了，那么它就是UC6對應(yīng)的用例。從圖3-1來看，UC6應(yīng)該表示用例“游客取消預(yù)定 (CancelReservatio n

24、)” 和“自動取消預(yù)定(AutoCancelReservation) ”中包含的公共事件流。不管是哪種類型的取消預(yù)定，都需要計(jì)算賠償金，以決定退還給用戶的費(fèi)用，所以UC6對應(yīng)用例Calcuate Refund 。.問題2(7分)根據(jù)說明中的描述與表 3-2，給出圖3-2中C1C7處所對應(yīng)的類名。(分?jǐn)?shù)：5.00 )正確答案：(解析：本題考察的是類圖建模。題目中已經(jīng)給岀了類的列表，要求考生根據(jù)說明指岀每個(gè)類在類圖中的位置。在解題時(shí)，可以同時(shí)參考用例圖中給岀的信息。先整體地看一下類圖，尋找其中是否包含繼承、聚集或組裝等這些層次結(jié)構(gòu)，這是快速確定部分類的關(guān)鍵。在圖3-2中有一個(gè)繼承結(jié)構(gòu)：C4、C6和

25、C7。在圖3-1中，用例之間也有一個(gè)概括的關(guān)系，這就提示我們，C4 C6和C7這3個(gè)類一定與支付功能相關(guān)。在表3-2中尋找與支付功能相關(guān)的類：Payment、CashPayment和CreditCardPayment。下來就是確定這 3個(gè)類中，哪個(gè)是父類。很明顯，Payment應(yīng)該作為父類。因此 C4對應(yīng)Payment，C6對應(yīng)CashPayment，C7對應(yīng)CreditCardPayment(C6和C7可以互換)。支付管理中還有一項(xiàng)計(jì)算折扣的能力，類列表中的類Discount表示付款折扣，而與 C5與C4之間具有關(guān)聯(lián)關(guān)系，所以C5應(yīng)該對應(yīng)類Discout。C1、C2分別與類“Reservat

26、ionitem ”之間具有組裝和聚集的關(guān)系，而從說明中可知，具有這種整體部分關(guān)系的只有公園、預(yù)定及租賃費(fèi)用之間，所以Cl對應(yīng)NationalPark ,C2對應(yīng)Rate。最后的一個(gè)類 C3對應(yīng)TicketingOfficer ， 即用例圖中的Actor。(3).問題3(2分)對于某些需求量非常大的小木屋或營地，說明中功能4的賠償金計(jì)算規(guī)則，不足以彌補(bǔ)取消預(yù)定所帶來的損失。如果要根據(jù)預(yù)定的時(shí)段以及所預(yù)定場地的需求量，設(shè)計(jì)不同層次的賠償金計(jì)算 規(guī)則，需要對圖3-2進(jìn)行怎樣的修改？(請用文字說明)(分?jǐn)?shù)：5.00 )正確答案：(解答1 ：增加一個(gè)新的類，該類與類Reservationitem 之間有

27、關(guān)聯(lián)關(guān)系?；蚪獯?：修改Rate類，使其具有計(jì)算賠償金的功能。)解析：在面向?qū)ο蠓椒ㄖ?，好的類模型對需求的變化?yīng)該具有一定的適應(yīng)性。本題考察的就是這一點(diǎn)。根 據(jù)題目現(xiàn)在對原有的賠償金計(jì)算規(guī)則要進(jìn)行修正。除了考慮取消預(yù)定的時(shí)間之外，同時(shí)要考慮所預(yù)定的 小木屋或營地的地段以及需求量。修正類模型時(shí)通常兩種基本方式，一種是修改已有的類，使其適應(yīng)新的 需求；第二種是增加一個(gè)新的類來完成新的需求，但是需要同時(shí)考慮新增加的類與已有類之間的關(guān)系。這 道題目兩種修改方法都可以采用。若要修改已有的類，需要首先了解哪個(gè)類與現(xiàn)在的新需求是有相關(guān)性的。 新需求針對的是賠償金，賠償金又與租賃費(fèi)用相關(guān)，所以要找原先與租賃費(fèi)

28、用相關(guān)的那個(gè)類，即Rate。解決方案之一就是修改 Rate，使其能夠按照新的規(guī)則計(jì)算賠償金。第二種修改方式，增加一個(gè)專門計(jì)算賠償金的類。按照新的計(jì)算規(guī)則，這個(gè)類就與游客的每次預(yù)定內(nèi)容相關(guān)，因此這個(gè)新增加的類應(yīng)該與類Reservationitem 之間有關(guān)聯(lián)關(guān)系。飛叵畢百i：匡譎旳1頁;12| (分?jǐn)?shù)：15.00 )問題1(8分)根據(jù)說明和C代碼，填充C代碼中的空(1)。(分?jǐn)?shù)：5.00 )正確答案：(j = 0 (2)bj= bj+si及其等價(jià)形式(3)min = temp (4)bm = bm+si 及其等價(jià)形式)解析：根據(jù)最先適宜算法思想，每取岀一個(gè)貨物，從第一個(gè)集裝箱開始判斷該貨物是否能

29、放入集裝箱，若 能則放入，因此空(1)填i = 0。while循環(huán)判斷，若貨物不能放入集裝箱，則考慮下一個(gè)集裝箱。不滿足 while循環(huán)中的條件，說明貨物能放入集裝箱，因此空 (2)填bj = bj+si。根據(jù)最優(yōu)適宜算法思想， 每取出一個(gè)貨物，從第一個(gè)集裝箱開始，確定能放入該貨物且剩余容量最小的集裝箱，并把該貨物放入該 集裝箱中。if條件判斷，若找到了比能放入貨物且剩余容量更小的集裝箱，則剩余容量最小值改為當(dāng)前的 集裝箱的剩余容量，因此空 填min = tempo確定了集裝箱后，把貨物裝入集裝箱中，空(4)bm = bm+si (2).問題2(4分)根據(jù)說明和C代碼，該問題在最先適宜和最優(yōu)適

30、宜策略下分別采用了 (5)和(6) 算法設(shè)計(jì)策略，時(shí)間復(fù)雜度分別為 (7)和(8)(用0符號表示)。(分?jǐn)?shù)：5.00 )正確答案：(5)貪心(6)貪心(7)O(n 2) (8)O(n 2)解析：最先適宜算法總是把貨物放入第一個(gè)能放入的集裝箱，最優(yōu)適宜算法總是把貨物放入能容納該貨物且剩余容量最小的集裝箱，因此都是基于貪心策略進(jìn)行的，空(5)和(6)填貪心。函數(shù)firstfit 中的for循環(huán)考慮n個(gè)貨物，其中嵌套了while循環(huán)，最多的集裝箱數(shù)為n,因此時(shí)間復(fù)雜度為0(n2)。函數(shù)bestfit中的for循環(huán)考慮n個(gè)貨物，其中嵌套了 for循環(huán)檢查每個(gè)集裝箱的剩余容量，最多的集裝箱數(shù)為n,因此時(shí)

31、間復(fù)雜度為O(n2)。.問題3(3分)考慮實(shí)例n = 10，C= 10,各個(gè)貨物的體積為4，2，7，3, 5，4，2，3, 6，2。該實(shí) 例在最先適宜和最優(yōu)適宜策略下所需的集裝箱數(shù)分別為 (9)和(10) o考慮一般的情況，這兩種求解策略能否確保得到最優(yōu)解 ?(11)(能或否)(分?jǐn)?shù)：5.00 ) 正確答案：(9)5 (16)4 (11) 否)解析：對實(shí)例n= 10, C= 10, S= 4 , 2 , 7, 3, 5, 4, 2 , 3, 6, 2，根據(jù)最先適宜和最優(yōu)適宜算法,因此最先適宜和最優(yōu)適宜方法所需的集裝箱數(shù)分別為具體的裝箱方案分別如下圖(a)和(b)所示。和4，裝箱問題是一個(gè)非常難

32、的問題，這兩種貪心策略不能確保得到最優(yōu)解，即最少的裝箱數(shù)。1.試題五(共15分)閱讀下列說明和C+代碼，將應(yīng)填入(n) 處的字句寫在答題紙的對應(yīng)欄內(nèi)。明現(xiàn)欲開發(fā)一個(gè)軟件系統(tǒng)，要求能夠同時(shí)支持多種不同的數(shù)據(jù)庫，為此采用抽象工廠模式設(shè)計(jì)該系統(tǒng)。以SQLServer和Access兩種數(shù)據(jù)庫以及系統(tǒng)中的數(shù)據(jù)庫表Department為例，其類圖如圖5-1所示。（分?jǐn)?shù)：15.00 ）正確答案：（解析：本題考查抽象工廠（Abstract Factory）模式的概念及應(yīng)用。 Abstract Factory模式的意圖是，提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。Abstract Fa

33、ctor模式的結(jié)構(gòu)如下圖所示其中，類 AbstractFactory聲明一個(gè)創(chuàng)建抽象產(chǎn)品對象的操作接口；類ConcreteFactory 實(shí)現(xiàn)創(chuàng)建具體產(chǎn)品對象的操作；類 ProductA為一類產(chǎn)品對象聲明一個(gè)接口；類ConcreteProduct具有2個(gè)功能：定義一個(gè)將被相應(yīng)的具體工廠創(chuàng)建的產(chǎn)品對象：實(shí)現(xiàn)ProductA接口；類Client 僅使用由AbstractFactory 和AbstractProduct 類聲明的接口。 在以下情況可以使用 AbstractFactory模式：（1） 一個(gè)系統(tǒng)要獨(dú)立于它的產(chǎn)品的創(chuàng)建、組合和表示時(shí)；（2） 個(gè)系統(tǒng)要由多個(gè)產(chǎn)品系統(tǒng)中的一個(gè)來配置時(shí)；（3）當(dāng)要強(qiáng)調(diào)一系列相關(guān)的產(chǎn)品對象的設(shè)計(jì)一邊進(jìn)行聯(lián)合使用時(shí)；（4）提供一個(gè)產(chǎn)品類庫，而只想顯示它們的接口而不是實(shí)現(xiàn)時(shí)。題目利用抽象工廠模式來解決在同一個(gè)軟件系統(tǒng)中支持多種不同數(shù)據(jù)庫的問題，這也是軟件開發(fā)中比較常見的情形。其中的類IFactory相當(dāng)于上圖中的類AbstractFa