《2012年下半年（下午）《軟件設計師》真題》由會員分享，可在線閱讀，更多相關《2012年下半年（下午）《軟件設計師》真題（9頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、2012年下半年（下午）《軟件設計師》真題 注意：圖片可根據(jù)實際需要調整大小 卷面總分：6分 答題時間：240分鐘 試卷題量：6題 練習次數(shù)：0次 問答題 （共6題，共6分） 1.某城市的各國家公園周邊建造了許多供游客租用的小木屋和營地，為此，該城市設置了一個中心售票處和若干個區(qū)域售票處。游客若想租用小木屋或營地，必須前往中心售票處進行預定并用現(xiàn)金支付全額費用。所有的預定操作全部由售票處的工作人員手工完成?，F(xiàn)欲開發(fā)一信息系統(tǒng)，實現(xiàn)小木屋和營地的預定及管理功能，以取代手工操作。該系統(tǒng)的 主要功能描述如下：

2、 1．管理預定申請。游客可以前往任何一個售票處提出預定申請。系統(tǒng)對來自各個售票處的預定申請進行統(tǒng)一管理。 2．預定。預定操作包含登記游客預定信息、計算租賃費用、付費等步驟。 3．支付管理。游客付費時可以選擇現(xiàn)金和信用卡付款兩種方式。使用信用卡支付可以享受3%的折扣，現(xiàn)金支付沒有折扣。 4．游客取消預定。預定成功之后，游客可以在任何時間取消預定，但需支付賠償金，剩余部分則退還給游客。賠償金的計算規(guī)則是，在預定入住時間之前的48小時內取消，支付租賃費用10%的賠償金；在預定入住時間之后取消，則支付租賃費用50%的賠償金。 5．自動取消預定。如果遇到惡劣天氣（如暴雨、山洪等），系統(tǒng)會自動取

3、消所有的預定，發(fā)布取消預定消息，全額退款。 6．信息查詢。售票處工作人員查詢小木屋和營地的預定情況和使用情況，以判斷是否能夠批準游客的預定申請。 現(xiàn)采用面向對象方法開發(fā)上述系統(tǒng)，得到如表3-1所示的用例列表和表3-2所示的類列表。對應的用例圖和類圖分別如圖3-1和3-2所示。 表3-1 表3-2類列表 圖3-1用例圖 【問題1】（6分） 根據(jù)說明中的描述與表3-1，給出圖3-1中UC1～UC6處所對應的用例名稱。 【問題2】(7分) 根據(jù)說明中的描述與表3-2，給出圖3-2中C1～C7處所對應的類名。 【問題3】（2分） 對于某些需求量非常大的小木屋或營地

4、，說明中功能4的賠償金計算規(guī)則，不足以彌補取消預定所帶來的損失。如果要根據(jù)預定的時段以及所預定場地的需求量，設計不同層次的賠償金計算規(guī)則，需要對圖3-2進行怎樣的修改？（請用文字說明） 正確答案： 本題解析： 【問題1】 UC1:CheckAvailability?UC2:MakeReservation UC3:GetDiscount?UC4:MangeCashPayment UC5:ManageCrCardPayment UC6:CalcuateRefund 注：4和5可以互換 【問題2】

5、 C1 NationaIPark C2:Rate C3:TicketingOfficer C4:Payment C5:Discount C6:CasbPayment C7:CreditCardPayment 注：6和7可以互換 【問題3】 解答1：增加一個新的類．該類與類Reservationltem之間有關聯(lián)關系。 或 解答2：修改Rate類．使其具有計算賠償金的功能。 回答出其中一種修改方式即可。 本題考查用例圖和類圖。涉及到用例之間的關系、類之間的關系等問題。 【問題1】 本題要我們補充完整用例圖，這是考試中常考的知識點。在題目的描述中，其實已經(jīng)給出了本題中相關的

6、用例，我們只需要通過閱讀題目的描述，理解清楚這些用例之間的關系，然后結合用例圖就可以完成這個問題。 在用例圖中，只有一個參與者，就是售票處工作人員，通過題目的描述，我們不難知道，他應該與自動取消預訂、游客取消預定、管理預定申請和信息查詢這些用例有直接關系，因此可以知道用例UC2是預定用例（MakeReservation）。而從用例圖中可以看出，UC1與信息查詢和管理預定申請都是一種包含關系，說明用例UC1是預定和管理預定申請這兩個用例必須都經(jīng)歷的一種行為，因此可以知道此用例是信息查詢（CheckAvailability）。 而UC3是支付管理的包含用例，根據(jù)題目的描述不難知道，在每次付款時

7、，都要首先計算付款折扣，因此，支付管理用例肯定包含了計算付款折扣這個用例，因此UC3就是計算付款折扣（GetDiscount）。而支付方式有現(xiàn)金支付和信用卡支付兩種方式，這兩種方式與支付管理是一種泛化關系，因此可以UC4和UC5分別是現(xiàn)金支付（MangeCashPayment）和信用卡支付（ManageCrCardPayment），當然，他們倆的位置可以互換。 另外，從用例圖不難看出，UC6是游客取消預定和系統(tǒng)自動取消預定用例所包含的用例，而這兩個用例都必須包含的部分是計算機賠償金，因此UC6是計算取消預定的賠償金（CalcuateRefund）。 【問題2】 本題要我們補充完整類圖，也

8、是考試中?？嫉闹R點。題目中給出了相關的類，要我們根據(jù)題目的描述并結合類圖來完成。 C1與類預定申請內容是一種組合關系，而其內容其實就是供游客租用的小木屋和營地以及它們的價格等信息，再結合類圖可知，C1應該是國家公園。而從類圖可以看出，C2聚合而成預定申請內容類，那么根據(jù)前面的分析，不難知道C2是租憑費用類。 而從類圖不難看出，C6和C7是繼承與C4，而從題目的分析中，只有付款、現(xiàn)金支付、信用卡支付存在這種繼承關系，因此可以確定C4是付款，而C6和C7分別對應現(xiàn)金支付和信用卡支付。位置可以互換。這樣就剩下C3和C5沒有確定，而沒有確定的類還有售票處和付款折扣。其中C3與預定申請有關，根據(jù)題

9、目描述，預定申請是要提交給售票處的，因此可以確定C3就是售票處，而付款的時候有個付款折扣信息，因此C5就是付款折扣。 【問題3】 問題3主要是要設計賠償金計算規(guī)則，要實現(xiàn)這個功能，可以添加一個類來實現(xiàn)，這類要與類Reservationltem之間有關聯(lián)關系，也可以在原來的類中實現(xiàn)，如果是這樣，就應該是類Rate中實現(xiàn)，因為這個類實現(xiàn)的是租憑費用，且這個類與Reservationltem之間是一種聚合的關聯(lián)關系。 2.現(xiàn)欲開發(fā)一個軟件系統(tǒng)，要求能夠同時支持多種不同的數(shù)據(jù)庫，為此采用抽象工廠模式設計該系統(tǒng)。以SQL Server和Access兩種數(shù)據(jù)庫以及系統(tǒng)中

10、的數(shù)據(jù)庫表Department為例，其類圖如圖5-1所示。 圖5-1類圖 【C++代碼】 #include＜iostream> using namespace std; class Department{/*代碼省略*/}； class IDepartment{ public: (1)=0； (2)=0； }； class SqlserverDepartment:(3){ public: void Insert(Department*department){ cout＜＜"Insert a record into Department in SQL Server

11、!\n"; ∥其余代碼省略 } Department GetDepartment(int id){ /*代碼省略*/ } }； class AccessDepartment:(4){ public: void Insert(Department*department){ cout＜＜"Insert a record into Department in ACCESS!\n"； ∥其余代碼省略 } Department GetDepartment(int id){ /*代碼省略*/ } }； (5){ public: (6)=0； }； class Sq

12、lServerFactory:public IFactory{ public: IDepartment*CreateDepartment（　?。﹞return new SqlserverDepartment（　?。?} ∥其余代碼省略 }； class AccessFactory:public IFactory{ public: IDepartment*CreateDepartment（　?。﹞return new AccessDepartment（　?。?} ∥其余代碼省略 }； 正確答案： 本題

13、解析： (1)virtual void Insert(Departmet*department) (2)virlual Department GetDepartment(int id) (3)public IDepartment (4)public IDepartmcnt (5)class Ifactory (6)virtual IDcpartment*CreateDepartment() 本題考查基本面向對象設計模式的運用能力。 抽象工廠設計模式主要是提供一個創(chuàng)建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。從題目給出的類圖可知SqlserverDepa

14、rtment和AccessDepartment繼承于Idepartment。而從第（1）和第（2）空處的程序語句可以知道，這里是定義純虛函數(shù)，而類Idepartment一個抽象類，而在這里需要定義一個什么樣的純虛函數(shù)，就需要根據(jù)SqlserverDepartment和AccessDepartment類的內容來了解。在這兩個類里面都有Insert和GetDepartment這兩個函數(shù)，因此在Idepartment類中定義的純虛函數(shù)就是這兩個函數(shù)，因此第（1）空應該填virtual void Insert(Departmet*department)，而第（2）空應該填virlual Departm

15、ent GetDepartment(int id)。 第（3）空和第（4）空是一樣的，因為類SqlserverDepartment和AccessDepartment都是繼承抽象類Idepartment，而一般情況下的繼承方式都是public，所以這兩空的答案都是public Idepartment。 從第（5）空出現(xiàn)的位置，不難知道這里是定義一個類，結合前后程序，可以知道這里定義的類是Ifactory，這是一個抽象類，因此該空的答案為class Ifactory。 第（6）空是定義抽象類Ifactory的純虛函數(shù)，從后面的程序可以看出，需要定義的純虛函數(shù)是CreateDepartment

16、，因此第（6）空的答案是virtual IDcpartment*CreateDepartment()。 3.某電子商務系統(tǒng)采用以數(shù)據(jù)庫為中心的集成方式改進購物車的功能，詳細需求如下： （1）加入購物車。顧客瀏覽商品，點擊加入購物車，根據(jù)商品標識從商品表中讀取商品信息，并更新購物車表。 （2）瀏覽購物車。顧客提交瀏覽購物車請求后，顯示出購物車表中的商品信息。 （3）提交訂單。顧客點擊提交訂單請求，后臺計算購物車表中商品的總價（包括運費）加入訂單表，將購物車表中的商品狀態(tài)改為待付款，顯示訂單詳情。若商家改變價格，則刷新后可看到更改后的價格。 （4）改變價格。

17、商家查看訂購自家商品的訂單信息，根據(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ù)，調用第三方服務Crystal Reports生成相關報表。

18、（8）維護信息。管理員維護（增、刪、改、查）顧客表、商品分類表和商品表中的信息。 現(xiàn)采用結構化方法實現(xiàn)上述需求，在系統(tǒng)分析階段得到如圖1-1所示的頂層數(shù)據(jù)流圖和圖1-2所示的0層數(shù)據(jù)流圖。 圖1-1頂層數(shù)據(jù)流圖 【問題1】(4分) 使用說明中的詞語，給出圖1-1中的實體E1～E4的名稱。 【問題2】(4分) 使用說明中的詞語，給出圖1-2中的數(shù)據(jù)存儲D1～D4的名稱。 【問題】(4分) 圖1-2中缺失了數(shù)據(jù)流，請用說明或圖1-2中的詞語，給出其起點和終點。 【問題4】（3分） 根據(jù)說明，給出數(shù)據(jù)流“轉賬請求”、“顧客訂單物流查詢請求”和“商家訂單物流查詢請求”的各組

19、成數(shù)據(jù)項。 正確答案： 本題解析： 【問題1】 E1：商家 E2：支付系統(tǒng) E3：物流系統(tǒng) E4：CrystaI Reports或第三方服務 【問題2】 D1:訂單表 D2：商品表 D3：商品分類表 D4：購物車表 【問題3】 圖1-2中缺少的數(shù)據(jù)流： 【問題4】 轉賬請求=驗證碼+價格+賬號信息 顧客訂單物流查詢請求=顧客標識+訂單標識 商家訂單物流查詢請求=商家標識+{訂單標識} 該題以電子商務的購物車系統(tǒng)為載體來考核考生對數(shù)據(jù)流圖知識點的把握。從題目的問答形式上

20、來看，和往年差不多，仍然是要求補充外部實體、補充數(shù)據(jù)存儲、補充缺失數(shù)據(jù)流等。 解答這類問題，有以下兩個原則： （1）緊扣試題的系統(tǒng)說明部分，數(shù)據(jù)流圖與系統(tǒng)說明有著嚴格的對應關系，系統(tǒng)說明部分的每一句話都能對應到圖中，解題時可以一句一句地對照著圖來分析。 （2）數(shù)據(jù)的平衡原則，這一點在解題過程中也是至關重要的。數(shù)據(jù)平衡原則有兩方面的意思：一方面是分層數(shù)據(jù)流圖中父子圖之間的數(shù)據(jù)流平衡原則；另一方面是每張數(shù)據(jù)流圖中輸入與輸出數(shù)據(jù)流的平衡原則。 【問題1】 外部實體一般是人、組織或者外部系統(tǒng)。在本題中，根據(jù)頂層數(shù)據(jù)流圖中購物車與E1的兩天數(shù)據(jù)流，再結合題目的描述“商家發(fā)貨后，需按訂單標識添加

21、物流標識（物流公司、運單號）；然后可根據(jù)顧客或商家的標識以及訂單標識，查詢訂單表中的物流標識，并從相應物流系統(tǒng)查詢物流信息”，可知E1就是商家。 同理，根據(jù)說明中的“將轉賬請求（驗證碼、價格等）提交給支付系統(tǒng)（如信用卡系統(tǒng)）進行轉賬；然后根據(jù)轉賬結果返回支付狀態(tài)”，再結合頂層數(shù)據(jù)流圖可以知道E2是支付系統(tǒng)。根據(jù)說明中的“從相應物流系統(tǒng)查詢物流信息”，再結合頂層數(shù)據(jù)流圖中E3與購物車之間的數(shù)據(jù)流信息，可以知道E3是物流系統(tǒng)。根據(jù)說明中（7）的描述，再結合頂層圖中E4與購物車系統(tǒng)的數(shù)據(jù)流可以知道E4是Crystal Reports（或第三方服務）。 【問題2】 數(shù)據(jù)存儲一般是說明中所牽涉到的

22、某某文件或某某表。在本題中，描述中有描述過的數(shù)據(jù)存儲有：顧客表、訂單表、商品表、商品分類表和購物車表。 由圖0層數(shù)據(jù)流圖可知，D1與付款、提交訂單、物流跟蹤、改變價格等處理有關，可知D1是訂單表。由描述“顧客瀏覽商品，點擊加入購物車，根據(jù)商品標識從商品表中讀取商品信息，并更新購物車表”，再結合0層數(shù)據(jù)流可知D2是商品表，另外，根據(jù)描述“管理員維護（增、刪、改、查）顧客表、商品分類表和商品表中的信息”，再結合0層數(shù)據(jù)流可知D2和D3應該對應商品表和商品分類表，而D2是商品表，因此D3就是商品分類表。同理可以知道D4就是購物車表。 【問題3】 本題要求我們找出0層數(shù)據(jù)流圖中缺失的數(shù)據(jù)流，是一

23、類?？嫉闹R點，對應這類題目的求解，我們要充分利用數(shù)據(jù)的平衡原則，仔細閱讀題目給出的描述。 根據(jù)說明中（5）的描述，我們不難知道，在付款這個加工時，要更改購物車表中商品的狀態(tài)，很顯然這個過程在0層數(shù)據(jù)流圖中并沒有體現(xiàn)出來，因此缺少了一條從付款到購物車表的數(shù)據(jù)流。另外，在付款時，系統(tǒng)先要根據(jù)顧客表中關聯(lián)的支付賬戶，將轉賬請求提交給支付系統(tǒng)進行轉賬，那么就應該有一條從顧客表到付款的數(shù)據(jù)流。 根據(jù)說明中（3）的描述，我們不難知道，在顧客點擊提交訂單請求，后臺將要計算購物車表中商品的總價，那么就需要從購物車表中獲取商品的價格信息，因此就有一條從購物車表到提交訂單的數(shù)據(jù)流，而顯然在0層數(shù)據(jù)流圖中并沒

24、有體現(xiàn)出來這樣一條數(shù)據(jù)流，因此缺少了一條從購物車表到提交訂單的數(shù)據(jù)流。 根據(jù)說明中（7）的描述，可以知道從訂單表、商品表以及商品分類表都有到生成報表加工的數(shù)據(jù)流。從0層數(shù)據(jù)流圖中來看，顯然還缺少從訂單表到生成報表的數(shù)據(jù)流。 【問題4】 數(shù)據(jù)項也稱為數(shù)據(jù)元素，是最小的數(shù)據(jù)組成單位，也就是不可再分的數(shù)據(jù)單位。如學號、姓名等。 在題目中，對于轉賬請求，已經(jīng)給出了其包含了驗證碼、價格，另外根據(jù)常識，我們知道還應該有賬號信息。而顧客訂單物流查詢請求應包含顧客標識和訂單標識。商家訂單物流查詢請求應包含商家標識和訂單標識這些數(shù)據(jù)項，而且一個商家可能有多個訂單，因此訂單標識也有多個。

25、 4.某會議策劃公司為了方便客戶，便于開展和管理各項業(yè)務活動，需要構建一個基于網(wǎng)絡的會議預定系統(tǒng)。 【需求分析】 1．會議策劃公司設有受理部、策劃部和其他部門。部門信息包括部門號、部門名稱、部門主管、電話和郵箱號。每個部門有多名員工處理部門的日常事務，每名員工只能在一個部門工作。每個部門有一名主管負責管理本部門的事務和人員。 2．員工信息包括員工號、姓名、部門號、職位、聯(lián)系方式和工資；其中，職位包括主管、業(yè)務員、策劃員等。業(yè)務員負責受理會議申請。若申請符合公司規(guī)定，則置受理標志并填寫業(yè)務員的員工號。策劃部主管為已受理的會議申請制定策劃任務，包括策劃內容、參與人數(shù)、要求完成時

26、間等。一個已受理的會議申請對應一個策劃任務，一個策劃任務只對應一個已受理的會議申請，但—個策劃任務可由多名策劃員參與執(zhí)行，且一名策劃員可以參與多項策劃任務。 3．客戶信息包括客戶號、單位名稱、通信地址、所屬省份、聯(lián)系人、聯(lián)系電話、銀行賬號。其中，一個客戶號唯一標識一個客戶。一個客戶可以提交多個會議申請，但一個會議申請對應唯一的一個客戶號， 4．會議申請信息包括申請?zhí)枴㈤_會日期、會議地點、持續(xù)天數(shù)、會議人數(shù)、預算費用、會議類型、酒店要求、會議室要求、客房類型、客房數(shù)、聯(lián)系人、聯(lián)系方式、受理標志和業(yè)務員的員工號等?？头款愋陀泻廊A套房、普通套房、標準間、三人間等，且申請?zhí)柡涂头款愋蜎Q定客房數(shù)。

27、 【概念模型設計】 根據(jù)需求階段收集的信息，設計的實體聯(lián)系圖和關系模式（不完整）如下： 【關系模式設計】 部門（部門號，部門名稱，主管，電話，郵箱號） 員工（員工號，姓名，（a），聯(lián)系方式，工資） 客戶（客戶號，單位名稱，通信地址，所屬省份，聯(lián)系人，聯(lián)系電話，銀行賬號） 會議申請（（b），開會日期，會議地點，持續(xù)天數(shù)，會議人數(shù)，預算費用，會議類型，酒店要求，會議室要求，客房數(shù)，聯(lián)系人，聯(lián)系方式，受理標志，員工號） 策劃任務（（c），策劃內容，參與人數(shù)，要求完成時間） 執(zhí)行策劃（（d），實際完成時間） 【問題1】（5分） 根據(jù)問題描述，補充五個聯(lián)系、聯(lián)系的類型，完善圖2-

28、1的實體聯(lián)系圖。 【問題2】（7分） 根據(jù)實體聯(lián)系圖，將關系模式中的空（a）～（d）補充完整（1個空缺處可能有多個數(shù)據(jù)項）。對會議申請、策劃任務和執(zhí)行策劃關系模式，用下劃線和#分別指出各關系模式的主鍵和外鍵。 【問題3】（3分） 請說明關系模式“會議申請”存在的問題及解決方案。 正確答案： 本題解析： 【問題2】 （a）部門號，職位 （b）申請?zhí)枺头款愋?，客戶? （c）申請?zhí)?，員工號 （d）申請?zhí)枺瑔T工號 關系模式為： 會議申請（申請?zhí)?，客房類型，客戶?，開會日期，會議地點，持

29、續(xù)天數(shù)，會議人數(shù)，預算費用，會議類型，酒店要求，會議室要求，客房數(shù)，聯(lián)系人，聯(lián)系方式，受理標志，員工號#） 策劃任務（申請?zhí)?，員工號#，策劃內容，參與人數(shù)，要求完成時間） 執(zhí)行策劃（申請?zhí)?，員工號#，實際完成時間） 【問題3】 會議申請存在數(shù)據(jù)冗余及數(shù)據(jù)修改的不一致性問題，應該將關系模式分解為如下兩個模式： 會議申請1（申請?zhí)?，客戶號，開會日期，會議地點，持續(xù)天數(shù)，會議人數(shù)，預算費用，會議類型，酒店要求，會議室要求，聯(lián)系人，聯(lián)系方式，受理標志，員工號） 會議申請2（申請?zhí)?，客房類型，客房?shù)）。 本題考查數(shù)據(jù)庫相關知識，涉及的知識點包括：ER模型、關系模式、主鍵、范式。 【問

30、題1】 問題1考查考生對ER模型的理解。 本題主要考查根據(jù)題目描述補充完整ER圖。 在解答本問題時，需要注意將題目描述與已給出的圖進行對照分析。在題目中有“業(yè)務員負責受理會議申請。”，這說明業(yè)務員與會議申請之間有聯(lián)系，聯(lián)系的名稱可直接取題目中的“受理”一詞。同時，由于題目中有“若申請符合公司規(guī)定，則置受理標志并填寫業(yè)務員的員工號”，這說明一個申請只由一個員工受理，但一個員工卻可以受理多項業(yè)務，也就是說業(yè)務員與會議申請之間是1:n的關系。與此同時，通過常識加題目描述，可以意識到一個問題：對于會議申請只表明了受理人員，而誰來提出申請，并未直接說明。縱觀系統(tǒng)全局，可以看出會議是由客戶申請的。所

31、以客戶也與會議申請有聯(lián)系，這種聯(lián)系類型也是1:n。 從“一個已受理的會議申請對應一個策劃任務，一個策劃任務只對應一個已受理的會議申請，但—個策劃任務可由多名策劃員參與執(zhí)行，且—名策劃員可以參與多項策劃任務。”可以得知，策劃任務與策劃員之間存在“執(zhí)行”的聯(lián)系，而且這種聯(lián)系是n:m的。 從“每個部門有多名員工處理部門的日常事務，每名員工只能在一個部門工作?！笨梢钥闯?，部門與員工之間存在聯(lián)系，聯(lián)系類型是1：n。從“每個部門有一名主管負責管理本部門的事務和人員?！笨梢钥闯觯鞴苓@個角色與部門之間存在聯(lián)系，由于每個部門只有1名主管，而1名主管也只能負責1個部門的工作，所以他們之間的聯(lián)系是1：1的。

32、 【問題2】 當完成問題1的分析之后，問題2就很好解決了。其解題步驟的第一個環(huán)節(jié)，應是看題目已經(jīng)給出的信息。例如，第（a）空要求補充員工關系，而題目中已經(jīng)說明“員工信息包括員工號、姓名、部門號、職位、聯(lián)系方式和工資”，此時，只要把缺失的“部門號，職位”填入即可。但有時，這一招并不能完全解決問題，例如第（b）空，從題目的描述“會議申請信息包括申請?zhí)?、開會日期、會議地點、持續(xù)天數(shù)、會議人數(shù)、預算費用、會議類型、酒店要求、會議室要求、客房類型、客房數(shù)、聯(lián)系人、聯(lián)系方式、受理標志和業(yè)務員的員工號等?！笨梢缘弥P系模式缺了申請?zhí)柵c客房類型，但補充這些是否足矣？不行，還缺了屬性，即客戶號，因為問題1中

33、，已經(jīng)分析了系統(tǒng)業(yè)務邏輯，應是由客戶提出申請，所以需要記錄客戶號。 接下來分析會議申請的主鍵與外鍵。在會議申請這個關系模式中，由于存在“客房類型有豪華套房、普通套房、標準間、三人間等，且申請?zhí)柡涂头款愋蜎Q定客房數(shù)?！钡那闆r，所以有函數(shù)依賴：（申請?zhí)?，客戶類型?>客戶數(shù)。同時其它所有屬性都依賴于（申請?zhí)?，客戶類型）。所以（申請?zhí)?，客戶類型）是本關系模式的主鍵。而會議申請中的客戶號是相對于客戶關系的外鍵，員工號是相對于員工關系的外鍵。 （c）與（d）的內容補充，也需要進行分析才能得出結論，正是由于從題目中有“個已受理的會議申請對應一個策劃任務，一個策劃任務只對應一個已受理的會議申請，但—個策

34、劃任務可由多名策劃員參與執(zhí)行，且—名策劃員可以參與多項策劃任務。”，這說明“策劃任務”與“執(zhí)行策劃”都與會議申請有關，所以這兩個關系中，也需要有申請?zhí)枴? 在策劃任務關系模式中申請?zhí)柲艽_定員工號（因為策劃部主管為已受理的會議申請制定策劃任務，所以有確定的關系），也能確定策劃內容，參與人數(shù)，要求完成時間。所以申請?zhí)柺侵麈I。同時，由于申請?zhí)柵c員工號在其它關系中充當主鍵，所以他們也是外鍵。 在執(zhí)行策劃關系中，由于“—個策劃任務可由多名策劃員參與執(zhí)行，且一名策劃員可以參與多項策劃任務”，所以必須要（申請?zhí)枺瑔T工號）這個組合屬性才能充當主鍵。同時這兩個屬性也是外鍵。 【問題3】 問題3要求分析關系

35、模式“會議申請”存在的問題及解決方案。分析關系模式的問題，往往需要從關系模式的規(guī)范程度入手，規(guī)范程度不高的模式，可能出現(xiàn)：插入異常、修改異常、刪除異常、數(shù)據(jù)冗余等問題。 在問題2的分析中，已經(jīng)提到了會議申請關系的主鍵是：（申請?zhí)?，客戶類型）。但同時存在：申請?zhí)?>開會日期、申請?zhí)?>會議地點依賴關系，這就導致了部分依賴的產(chǎn)生。這使得數(shù)據(jù)冗余、修改異常等問題產(chǎn)生。解決的辦法就是拆分。把：（申請?zhí)?，客戶類型，客戶?shù)）拆分為一個新表，而另一個表中去除客戶類型與客戶數(shù)，將申請?zhí)柖x為主鍵。 5.現(xiàn)欲開發(fā)一個軟件系統(tǒng)，要求能夠同時支持多種不同的數(shù)據(jù)庫，為此采用抽象工廠模

36、式設計該系統(tǒng)。以SQL Server和Access兩種數(shù)據(jù)庫以及系統(tǒng)中的數(shù)據(jù)庫表Department為例，其類圖如圖6-1所示。 圖6-1類圖 【Java代碼】 import javA．util.*; class Department{/*代碼省略*/} interface IDepartment{ (1)； (2)； } class SqlserverDepartment(3){ public voidInsert(Department department){ System.out.println(”Insert a record into Department

37、in SQL Server!"); ∥其余代碼省略 } public Department GetDepartment(int id){ /*代碼省略*/ } } classAccessDepartment(4){ public void Insert(Department department){ System.out.println("Insert a record into Department in ACCESS!”); ∥其余代碼省略 } public Department GetDepartment(int id){ /*代碼省略*/ } } (5)

38、{ (6)； } class SqlServerFactory implements IFactory{ public IDepartment CreateDepartment（　?。﹞ retum new SqlserverDepartment（　?。? } ∥其余代碼省略 } class AccessFactory implements IFactory{ public IDepartment CreateDepartment（　?。﹞ return new AccessDepartment（　　）; } ∥其余代碼省略 }

39、 正確答案： 本題解析： (1)void Insert(Department department) (2)Department GetDepartment(int id) (3)implements lDepartment (4)implements IDepartment (5)interface IFactory (6)IDepartment CreateDepartment() 本題考查基本面向對象設計模式的運用能力。 抽象工廠設計模式主要是提供一個創(chuàng)建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。從題目給出

40、的類圖可知SqlserverDepartment和AccessDepartment繼承于接口Idepartment。而從第（1）和第（2）空處的程序語句可以知道，這里是定義抽象函數(shù)，但在這里需要定義一個什么樣的抽象函數(shù)，就需要根據(jù)SqlserverDepartment和AccessDepartment類的內容來了解。在這兩個類里面都有Insert和GetDepartment這兩個函數(shù)，因此在Idepartment中定義的抽象函數(shù)就是這兩個函數(shù)，因此第（1）空應該填void Insert(Departmet department)，而第（2）空應該填Department GetDepartmen

41、t(int id)。 第（3）空和第（4）空是一樣的，因為類SqlserverDepartment和AccessDepartment都是實現(xiàn)接口Idepartment，而實現(xiàn)接口都是用關鍵字implements，所以這兩空的答案都是implements Idepartment。 從第（5）空出現(xiàn)的位置，不難知道這里是定義一個接口，結合前后程序，可以知道這里定義的接口是Ifactory，因此該空的答案為interface Ifactory。 第（6）空是定義接口Ifactory的抽象函數(shù)，從后面的程序可以看出，需要定義的抽象函數(shù)是CreateDepartment，因此第（6）空的答案是Id

42、cpartment CreateDepartment()。 6.設有n個貨物要裝入若干個容量為C的集裝箱以便運輸，這n個貨物的體積分別為{S1，S2，．．．，Sn}，且有si≤C(1≤i≤n)。為節(jié)省運輸成本，用盡可能少的集裝箱來裝運這n個貨物。 下面分別采用最先適宜策略和最優(yōu)適宜策略來求解該問題。 最先適宜策略(firstfit)首先將所有的集裝箱初始化為空，對于所有貨物，按照所給的次序，每次將一個貨物裝入第一個能容納它的集裝箱中。 最優(yōu)適宜策略(bestfit)與最先適宜策略類似，不同的是，總是把貨物裝到能容納它且目前剩余容量最小的集裝箱，使得該箱子裝

43、入貨物后閑置空間最小。 【C代碼】 下面是這兩個算法的C語言核心代碼。 (1)變量說明 n：貨物數(shù) C：集裝箱容量 s：數(shù)組，長度為n，其中每個元素表示貨物的體積，下標從0開始 b：數(shù)組，長度為n，b[i]表示第i+1個集裝箱當前已經(jīng)裝入貨物的體積，下標從0開始 i，j：循環(huán)變量 k：所需的集裝箱數(shù) min:當前所用的各集裝箱裝入了第i個貨物后的最小剩余容量 m:當前所需要的集裝箱數(shù) temp：臨時變量 (2)函數(shù)firstfit int firstfit（　?。﹞ inti，j； k=0： for(i=0；i＜n；i++){ b[i]=0； } for

44、（i=0；i＜n；i++）{ (1)； while(C-b[j]＜s[i]){ j++; } (2)； k=k>(j+1）k：(j+1)； } return k； } (3)函數(shù)bestfit int bestfit（　?。﹞ int i，j，min，m，temp; k=0； for（i=0；i＜n；i++）{ b[i]=0； } for(i=0；i＜n；i++）{ min=C； m=k+1； for(j=0;j＜k+l；j++){ temp=C-b[j]-s[i]; if(temp>0&&temp＜min){ (3)； m=j， } }

45、(4)； k=k>(m+1）k:(m+1)； } return k； } 【問題1】（8分） 根據(jù)和【C代碼】，填充C代碼中的空(1)～(4)。 【問題2】（4分） 根據(jù)和【C代碼】，該問題在最先適宜和最優(yōu)適宜策略下分別采用了(5)和(6)算法設計策略，時間復雜度分別為(7)和(8)（用O符號表示）。 【問題3】（3分） 考慮實例n=10，C=10，各個貨物的體積為{4，2，7，3，5，4，2，3，6，2}。該實例在最先適宜和最優(yōu)適宜策略下所需的集裝箱數(shù)分別為(9)和(10)?？紤]一般的情況，這兩種求解策略能否確保得到最優(yōu)解？(11)（能或否）

46、 正確答案： 本題解析： 【問題1】 (1)j=0 (2)b[j]=b[j]+s[i] (3)min=temp (4)b[m]=b[m]+s[i] 【問題2】 (5)貪心 (6)貪心 (7)O(n2) (8)O(n2) 【問題3】 (9)5 (10)4 (11)否 本題考查最先適宜策略和最優(yōu)適宜策略。這兩種策略在題目的描述中給出了清楚的解析，對于最先適宜策略，其關鍵是每次將一個貨物裝入第一個能容納它的集裝箱中；而對于最優(yōu)適宜策略，則總是把貨物裝到能容納它且目前剩余容量最小的集裝箱。 下面我們來具體分析程

47、序。函數(shù)firstfit()是實現(xiàn)最先適宜策略的，從程序不難看出，第（1）空所在的for循環(huán)，就是要將n各貨物裝入到集裝箱。根據(jù)算法的描述，是依次從第一個集裝箱找，找到合適的就裝入貨物，依次沒裝入一個貨物，都是依次從第一個集裝箱找。結合后面的程序不難知道j標識這當前是第幾個集裝箱。因此每裝入一個貨物后，要將j清0，標識從頭再找，因此第（1）空的答案是j=0。而接下來的while循環(huán)，從其條件表達式C-b[j]＜s[i]不難知道，是比較當前集裝箱和當前貨物的體積大小，如果當前集裝箱體積小，則比較下一個集裝箱，否則，就應該將貨物裝入該集裝箱，并且調整集裝箱剩余體積的大小，在本題中，這個是通過數(shù)組b

48、來實現(xiàn)的，因此第（2）空的答案應該為b[j]=b[j]+s[i]。 第（3）和第（4）空是在函數(shù)bestfit()下，這個函數(shù)是實現(xiàn)最優(yōu)適宜策略的。從程序中不難看出，for(j=0;j＜k+l；j++)就是要在眾多的集裝箱中找到最合適的集裝箱，而第（3）空是條件if(temp>0&&temp＜min)成立時，執(zhí)行的語句，該條件成立，表示當前找到的集裝箱比原來確定的集裝箱更合適，而最合適的集裝箱的剩余體積存放在min中，因此第3空的答案為min=temp，而循環(huán)結束后，就應該找到了合適的集裝箱，這時應該將貨物存放到集裝箱里面，即第（4）空的答案為b[m]=b[m]+s[i]。 在本題中，不管

49、是采用最先適宜策略，還是最優(yōu)適宜策略，他們都是根據(jù)不同策略選擇目前看來最優(yōu)的情況，這都屬于貪心算法的思想。從兩個函數(shù)不難看出，其時間復雜度是一樣的，都是O(n2)。 第3個問題，其實是這個題目中最簡單的問題，也是算法的一個實際應用。對于這個實例，如果采用最先適宜策略，那么貨物{4，2，3}存放在第一個集裝箱，而{7，2}存放在第二個集裝箱，{5，4}存放在第三個集裝箱，{3，6}存放在第四個集裝箱，而{2}存放在第五個集裝箱。 如果采用最優(yōu)適宜策略，那么貨物{4，2，4}存放在第一個集裝箱，而{7，3}存放在第二個集裝箱，{5，2，3}存放在第三個集裝箱，{6，2}存放在第四個集裝箱。 因為這兩種方法都是采用的貪心策略，那么在一般情況下，是不能確保得到最優(yōu)解的。