計算機水平考試中級軟件設計師2012年下半年下午真題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16、門號，職位”。 在會議申請關系模式中，由于申請?zhí)?、客房類型、客戶號為主鍵，故空（b）應填寫“申請?zhí)?，客房類型，客戶號”：在策劃任務關系模式中，申請?zhí)?、員工號為主鍵，故空（c）應填寫“申請?zhí)枺蛻籼枴保河捎谝粋€策劃任務可由多名策劃員參與執(zhí)行，且一名策劃員可以參與多項策劃任務，故在執(zhí)行策劃關系模式中，執(zhí)行策劃又由于一個業(yè)務員可以安排多個托運申請，申請?zhí)?、員工號為主鍵， 故空（d）應填寫“申請?zhí)?，客戶號”。會議申請關系模式的主鍵為“申請?zhí)?，客房類型”，因為，申請?zhí)?、客房類型能唯一標識該關系模式的每一個元組。會議申請關系模式的外鍵為客戶號及員工號，因為，客戶 號及員工號分別為客戶及員工關系模式的主鍵，

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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