軟件水平考試（中級）軟件設計師下午

（應用技術）試題模擬試卷79

一、必答題（本題共12題，每題1.0分，共12分。）

閱讀下列說明洞答問題。【說明】某醫療護理機構為老年人或有護理需求者提供

專業護理，現欲開發一基于Web的醫療管理系統，以改善醫療護理效率。該系統的主

要功能如下：（1）通用信息查詢。客戶提交通用信息查詢請求，查詢通用信息表，返回

查詢結果。（2）醫生.聘用。醫生提出應聘/辭職申請，交由主管進行聘用/解聘審批,

更新醫生表，并給醫生反饋聘用/解聘結果；刪除解聘醫生的出診安排。（3）預約處

理。醫生安排出診時間，存入醫生出診時間表；根據客戶提交的預約查詢請求渣詢

在職醫生.及其出診時間等預約所需數據并返回；創建預約，提交預約請求,在預約表

中新增預約記錄,更新所約醫生出診時間并給醫生發送預約通知；給客戶反饋預約

結果°（4）藥品管理.醫生提交處方，根據藥品名稱從藥品數據中查詢相關藥品庫存

信息，開出藥品，更新對應藥品的庫存以及預約表中的治療信息；給醫生發送藥品已

開出反饋。（5）報表創建。根據主管提交的報表查詢請求（報表類型和時間段），從預

約數據、通用信息、藥品庫存數據、醫生以及醫生出診時間中進行查詢，生成報表

返回給主管。現采用結構化方法對醫療管理系統進行分析與設計，獲得如圖1-1所

示的上下文數據流圖和圖1-2所示的0層數據流圖c

上下文數據流圖

1、使用說明中的詞語,給出圖1“中的實體E1?E3的名稱。

標準答案：E1：客戶E2：醫生E3：主管

知識點解析：暫無解析

2、使用說明中的詞語,給出圖1-2中的數據存儲D1?D5的名稱。

標準答案：D1：通用信息D2：預約數據D3：醫生D4：醫生出診時間D5：藥品

（注：名稱后面可以帶有文件或表）

知識點解析：暫無解析

3、使用說明和圖中術語，補充圖1-2中缺失的數據流及其起點和終點。

標準答案：

數據流起點修點

更新的出診時間P3或預約處理D4或醫生出玲時間

刷除的醫生出診安排P2或醫生19用D4或醫生出診時間

藥從姆存信劃D5或藥品P4或藥品管理

治療信息P4或藥品管用D2或預約數據

（注：數據流沒有?序要求）

知識點解析：暫無解析

4、使用說明中的詞語，說明預約處理可以分解為哪些子加工,并說明建模圖1-1和圖

1-2時如何保持數據流圖平衡。

標準答案：預約處理分解為：安排出診時間、預約杳詢、創建預約、預約反饋。

圖1-1（或父圖）中某加工的輸入輸出數據流必須與圖1-2（或子圖）的輸入輸出數據流

在數量和名字上相同；圖1-1（或父圖）中的?個輸入（或輸出）數據流對應于圖1-2（或

子圖）中幾個輸入（或輸出）數據流，而圖1?2（或子圖）中組成這些數據流的數據項全體

正好是父圖中的這一條數據流。

知識點解析：本題考查采用結構化方法進行軟件系統的分析與設計,主要考查數據

流圖（DFD）的應用，考點與往年類似。DFD是結構化分析與設計方法中面向數據流

建模的工具,它將系統建模成輸入、加工（處理）、輸出的模型,并采用自頂向下分層

且逐層細化的方式,建模不同詳細程度的數據流圖模型。首先需要建模上下文數據

流圖（頂層DFD）來確定系統邊界。在上下文DFD中，待開發軟件系統被看作一個加

工,為系統提供輸入數據以及接收系統輸出數據的外部實體.外部實體和加工之間的

輸入輸出即為流入和流出系統的數據流。在上下文DFD中確定的外部實體以及與

外部實體的輸入輸出數據流的基礎上，將上下文DFD中的加工分解成多個加工，分別

識別這些加工的輸入數刑流以及經過加工變換后的輸出數據流，建模。層DFD,,根據

0層DFD中加工的復雜程度進一步建模加工的內容。在建模分層DFD時,根據需

求情況可以將數據存儲建模在不同層次的DFD中。建模時，需要注意加工和數據流

的使用原則,一個加工必須既有輸入又有輸出：數據流須和加工相關，即數據流至少

有一頭為加工。注意要在繪制下層數據流圖時保持父圖與子圖之間的平衡，即：父

圖中某加工的輸入輸出數據流必須與其子圖的輸入輸出數據流在數量和名字上相

同，或者父圖中的一個輸入（或輸出）數據流對應于子圖中幾個輸入（或輸出）數據流并

集。本題題干描述清晰，易于分析,分析題目中所描述的內容，完成對應題目。【問

題1】本問題考查上下文DFD,要求確定外部實體。在上下文DFD中，待開發系統

名稱醫療管理系統作為唯一加工的名稱,外部實體為這一加工提供輸入數據流或者

接收其輸出數據流。通過考查系統的主要功能發現，系統中涉及客戶、醫生、主

管。根據描述（1）中客戶提交通用信息查詢請求、描述（2）中醫生提出應聘/辭職申

請，交由主管進行聘用/解聘審批、描述⑶中醫生安排出診時間、描述（5）中根據主

管提交的報表查詢請求生成報表返回給主管等信息,對照圖1-1中El、E2和E3相

關的數據流，即可確定E1為客戶實體,E2為醫生實體,E3為主管實體。【問題2］

本問題要求確定圖1-2。層數據流圖中的數據存儲。重點分析說明中與數據存儲有

關的描述。根據說明（1）中查詢通用信息表,可知加工通用信息查詢需要從存儲D1

中根據相關檢索條件查詢相關通用信息，由此可知D1為通用信息。根據說明⑵中

更新醫生表……刪除解聘醫生的出診安排，可知加工醫生聘用需要向D3更新醫生列

表，由此可知D3為醫生,根據說明⑶中存入醫生出診時間表查詢在職醫生及其出

診時間等預約所需數據并返回在預約表中新增預約記錄，可知加工預約處理向存儲

醫生出診時間新增出診時間，向預約數據中新增預約，從醫生表中查詢在職醫生相關

信息。再對應圖1-2中這幾個數據存儲所關聯的數據流名稱，可知D2為預約數

據』94為醫生出診時間,根據說明⑷中根據藥品名稱從藥品數據中查詢相關藥品

庫存信息，開出藥品,更新對應藥品的庫存……，可知D5為藥品。［問題3］本問題

要求補充缺失的數據流及其起點和終點。對照圖1-1和圖1-2的輸入、輸出數據流,

并未缺少外部實體和加工之間的數據流。再考查題干中的說明判定圖1-2中是否缺

失內部的數據流,不難發現圖中缺失的數據流，具體分析如下。根據說明（3）中更新所

約醫生出診時間并給醫生發送預約通知，可知加工預約處理（P3）發給D4（醫生出診

時間）更新的出診時間；根據說明（2）中刪除解聘醫生的出診安排，可知醫生聘用（P2）

向存儲D4提交刪除的醫生出診安排；根據說明⑷中根據藥品名稱從藥品數據中

查詢相關藥品庫存信息,可知藥品管理（P4）從D5（藥品）獲取藥品庫存信息，再根據更

新對應藥品的庫存以及預約表中的治療信息,可知從P4向D2（預約數據）中更新治療

信息。【問題4】在自頂向下建模分層DFD時，根據功能的粒度，可以進一步法行

分解。在圖1-2所示的。層數據流中，預約處理對應于說明（3）,從中分析出需要執行

的加工，進行分解，可以分為4個主要子加工-安排出診時間、預約查詢、創建預

約、預約反饋。自頂向下進行建模時，需要保持數據流平衡，具體為父圖中某加工的

輸入輸出數據流必須與其子圖的輸入輸出數據流在數量和名字上相同，或者父圖中

的一個輸入（或輸出）數據流對應于子圖中幾個輸入｛或輸出）數據流并集。

閱讀下列說明和圖，回答問題。【說明】某海外代購公司為擴展公司業務，需要開發

一個信息化管理系統。請根據公司現有.業務及需求完成該系統的數據庫設計。

【需求描述】（1）記錄公司員工信息。員工信息包括工號、身份證號、姓名、性別

和一個手機號，工號唯一標識每位員工,員工分為代購員和配送員。（2）記錄采購的商

品信息。商品信息包括商品名稱、所在超市名稱、采購價格、銷售價格和商品介

紹,系統內部用商品條碼唯一標識每種商品。一種腐品只在一家超市代購。（3）光錄

顧客信息。顧客信息包不顧客真實姓名、身份證號（清關繳稅用）、一個手機號和一

個收貨地址，系統自動生成唯一的顧客編號。（4）記錄托運公司信息。托運公司信息

包括托運公司名稱，電話和地址，系統自動生成唯一的托運公司編號。（5）顧客登錄

系統之后,可以下訂單購買商品。訂單支付成功后，系統記錄唯一的支付憑證編號，顧

客需要在訂單里指定運送方式：空運或海運。（6）代購員根據顧客的訂單在超方采

購對應商品,一份訂單所含的多個商品可能由多名代購員從不同超市采購。（7）采購

完的商品交由配送員根據顧客訂單組合裝箱，然后交給托運公司運送。托運公司按

顧客訂單核對商品名稱和數量，然后按顧客的地址進行運送。【概念模型設計?】根

據需求階段收集的信息，設計的實體聯系圖（不完整）如圖2-1所示。

【邏輯結構設計】

根據概念模型設計階段完成的實體聯系圖，得出如下關系模式（不完整）：員工（工號,

身份證號，姓名，性別，手機號）商品（條碼，商品名稱，所在超市名稱，采購價格，銷售,介格,

商品介紹）顧客（編號，姓名，身份證號,手機號，收貨地址）托運公司（托運公司編號，托

運公司名稱，電話，地址）訂單（訂單ID,⑶,商品數量運送方式.支付憑證編號）代購（代

購ID,代購員工號,（b））運送（運送ID,配送員工號，托運公司編號，訂單ID,發運時間）

5、根據問題描述，補充圖2-1的實體聯系圖。

標準答案：補充內容如圖中虛線所示。

知識點解析：暫無解析

6、補充邏輯結構設計結果中的（a）、（b）兩處空缺。

標準答案：⑶顧客編號、商品條碼（b）訂:單ID,商品條碼

知識點解析：暫無解析

7、為方便顧客，允許顧客在系統中保存多組收貨地址。請根據此需求，增加顧客地址

弱實體，對圖2-1進行補充，并修改運送關系模式。

標準答案：補充內容如圖中虛線所示。

(運送ID,配送員工號,托運公司編號，訂單ID,發運時間)或者說明:增加屬性顧客地

址

知識點解析：本題考查數據庫概念模型設計及向邏輯結構轉換的應用。此類題目

要求考生認真閱讀題目,根據題目的需求描述,給出實體間的聯系。【問題11根據

題意，由采購完的商品交由配送員根據顧客訂單組合裝箱，然后交給托運公司運送。

托運公司按顧客訂單核對商品名稱和數量，然后按顧客的地址進行運送可知配送

員、托運公司和訂單三方參與運送聯系，三方之間為*：*：*聯系。【問題2】根據

需求描述(3)可知顧客信息包含收貨地址，所以在顧客關系里應該包括收貨地址。根

據需求描述(2)和(6)可知顧客關系和商品關系是*:*聯系，訂單應該包含顧客所購商

品的條碼和數量，所以需要在訂單關系模式中包含商品數量。根據需求描述⑹可知

根據顧客的訂單在超市采購對應商品，所以在代購關系里應該包括商品條碼。【問

題31根據題意由允許顧客在系統中保存多組收貨地址，可知增加的顧客地址弱實

體與顧客關系構成*：1聯系。另外，增加了顧客地址后，運送的時候要選擇顧客地址,

所以運送關系模式中應增加顧客地址。配送員、托運公司、訂單和顧客地址之間構

成*:*：*：*聯系。

閱讀下列說明和圖，回答問題。【說明】某ETC(ElectronicTollCollection,不停車收

費)系統在高速公路沿線的特定位置上設置一個橫跨道路上空的龍門架(Toll

Gantry),龍門架下包括6條車道(TrafficLanes),每條車道上安裝有'雷達傳感器(Radar

Sensor)＞無線傳輸器(RadioTransceiver)和數碼相機(DigitalCamera)等用于不停車收

費的設備，以完成正常行駛速度下的收費工作。該系統的基本工作過程如卜.：U)每

輛汽車上安裝有車載器,駕駛員(Driver)將一張具有唯一識別碼的磁卡插入車載器

中。磁卡中還包含有駕駛員賬戶的當前信用記錄。(2)當汽車通過某條車道時，不停

車收費設備識別車載器內的特有編碼，判斷車型,將收集到的相關信息發送到該路段

所屬的區域系統(RegionalCenter)中，計算通行費用創建收費交易(Transaction),從駕

駛員的專用賬戶中扣除通行費用。如果駕駛員賬戶透支，則記錄透支賬戶交易信

息。區域系統再將交易后的賬戶信息發送到維護駕駛員賬戶信息的中心系統

(CentralSystem)o(3)車載器中的磁卡可以使用郵局的付款機進行充值。充值信息

會傳送至中心系統,以更新駕駛員賬戶的余額。(4)當沒有安裝車載器或者車載器發

生故障的車輛通過車道時，車道上的數碼相機將對車輛進行拍照，并將車輛照片及拍

攝時間發送到區域系統,記錄失敗的交易信息，并將該交易信息發送到中心系統，

(5)區域系統會獲取不停車收費設備所記錄的交通事件(TrafficEvents)；交通廣播電

臺(TrafficAdviceCenter)根據這些交通事件進行路況分析并播報路況。現采用面向

對象方法對上述系統進行分析與設計，得到如表3?1所示的用例列表以及如圖3-1

所示的用例圖和圖3-2所示的分析類圖。

用例列表

用例名稱說明

CreateTransaction記錄收費交易

ChargeCard第食充值

UnderpaidTransaction記錄透支賅戶交媯信息

RecordIllegalUse記錄失敗交易信息

RecordTrafficEvent記錄交通事件

圖3-1用例圖

圖￡2分析類圖

8、根據說明中的描述,給出圖3-1中A1?A4所對應的參與者名稱。

標準答案：Al：DriverA2：CentralSytemA3：TratticAdviceCenterA4：Regional

Center

知識點解析：暫無解析

9、根據說明中的描述及表3-1,給出圖3-1中uUl?U5所對應的用例名稱。

標準答案：UI：UnderpaidTransactionU2：RecordIllegalUseU3：Create

TransactionU4：RecordTrafficEventU5：ChargeCard

知識點解析：暫無解析

10、根據說明中的描述,給出圖3-2中C1?C6所對應的類名。

標準答案：Cl：CentralSystemC2：TollGantryC3：TrafficLanesC4：Radar

SensorC5：RadioTransceiverC6：DigitalCamera

知識點解析：本題主要考查面向對象分析與設計的基本概念及應用。在建模方面，

本題涉及了UML的用例圖和類圖，考查的模式是根據需求說明將模型補充完整。題

目難度不大，屬于經典考題。【問題1】、【問題2］這兩個問題都是針對圖3-1

所示的用例圖，分別補充圖中缺失的參與者和用例。在UML用例圖中,參與者

(Actor)表示要與本系統發生交互的一個角色單元(人或其他系統)。用例(Usecase)表

示由本系統提供的一個業務功能單元。題目中已經給出了用例列表,可以根據這些

用例在需求描述中尋找相關的參與者。表3?1中給出了5個用例。經過簡單的分

析，可以把這5個用例分成三類：①CreateTransaction、UnderpaidTransaction>

RecordIllegalUseo這三個用例都跟通行收費相關，這也暗示著這三個用例之間必定

是有關聯關系的；②ChargeCard,這個用例與通行收費有著間接關聯，因為磁卡中

記錄了駕駛員賬戶的信用記錄；③RecordTrafficEvent,這是個獨立于收費的用

例。所以可以把用例記錄交通事件作為解題的突破點。對于RecordTraffleEvenl

用例，說明中的第(5)條：區域系統會獲取不停車收費設備所記錄的交通事件(Traffic

Events)；交通廣播電臺(TrafficAdviceCenter)根據這些交通事件進行路況分析并播

報路況。由此可以看出，在這個用例中，區域系統做的是寫操作--記錄交通事件；交

通廣播電臺(TrafficAdviceCenter)做的是讀操作-路況分析。所以區域系統、交通

廣播電臺是這個用例的兩個參與者。同時，也可以跟圖3-1所示的用例圖對號入座

了。從圖中可以看出A3、A4和U4組成了一個相對獨立的子用例圖。根據前文的

分析，可以確定U4對應的就是用例RecordTrafficEvent,A3和A4分別對應著參與

者區域系統和交通廣播電臺。對于ChargeCard用例，說明中的第(3)條：車載器中

的磁卡可以使用郵局的時款機進行充值。雖然這里沒有明確地說明充值的主語，但

是磁卡的擁有者是駕駛員，因此可以推斷出，用例磁卡充值的參與者就是駕駛員，現

在可以與用例圖進行對應，根據前文分析可以看出,U5對應著ChargeCard。另外充

值信息會傳送至中心系統，所以ChargeCard用例還有另外一個參與者，就是中心系

統。現在4個參與者已經全部識別出來：駕駛員、中心系統、區域系統和交通廣

播電臺。區域系統和交通廣播電臺已經對應于A3和A4。目前需要確定的是A1

和A2以及U1-U3的對應關系。從圖3-1中可以看出,U3和UI、U2之間是

Extend(擴展關系)。擴展關系是對基礎用例的擴展,基礎用例是一個完整的用例，即

使沒有擴展用例的參與也可以完成一個完整的功能。基礎用例提供了一組擴展點,

在這些新的擴展點中可以添加新的行為，而擴展用例提供了一組片段,這些片段能夠

被插入到基本用例的擴展點上。一般情況下，基礎用例的執行不會涉及擴展用例，只

有擴展點被激活時,擴展用例才會執行。因此擴展美系通常用來描述事件流的異常

或者可選事件。用例CreateTransactionUnderpaidTransactionRecordIllegalUse

+,UnderpaidTransaction和RecordIllegalUse是正常事件流中的特殊情況，可以作

為擴展用例。這樣就可以確定出,U3對應著用例CreateTransaction,U1和U2分別對

應著用例UnderpaidTransaction和RecordIllegalUseoAl和A2分別對應著參與者

駕駛員和中心系統。【問題3】本問題要求補充圖3-2中的類名。解答此類題目

時應先觀察和分析類圖，特別要注意類圖中出現的?些特殊關系，如繼承、聚集、組

裝等,以及關系的多重度。在圖3-2中出現了多個蛆裝關系。組裝表達的是一種部

分-整體關系，在使用組裝關系時，區分清楚哪個類代表整體，哪個類代表部分。由圖

3-2可見,C2和C3的聚集關系的多重度為6。在說明中龍門架下包括6條車道

(TrafficLanes),也就是說這6條車道是龍門架的一個組成部分,所以nJ以初步推斷

C2對應著龍門架(TollGantry)、C3對應著車道(TrafficLanes)。再看說明中每條車

道上安裝有雷達傳感器(RadarSensor)＞無線傳輸器(RadioTransceiver)和數碼相機

(DigitalCamera)等用于不停車收費的設備,即雷達傳感器(RadarSensor)＞無線傳輸

器(RadioTransceiver)和數碼相機(DigitalCamera)與車道之間構成了部分一整體關

系，符合圖中C3與C4、C5、C6之間的關系。由此可以完全確定C3為車道(Traffic

Lanes)oC4、C5、C6分別對應著雷達傳感器(RadarSensor)、無線傳輸器(Radio

Transceiver)和數碼相機(DigitalCamera)o最后來確定Cl。由與Cl有關聯關系的

類RegionalCenter可以得出,CI應該對應著CentralSystemo根據在補充用例圖時對

需求的深入分析,也可以確定這一點：CentralSystem和RegionalCenter共同完成通

行收費的行為。

閱讀卜.列說明和C代碼、回答問題。【說明】某公司購買長鋼條才存其切割后進行

出售。切割鋼條的成本可以忽略不計，鋼條的長度為整英寸。已知價格表P,其中

Pi(i=l、2,…,m)表示長度為i英寸的鋼條的價格。現要求解使銷售收益最大的切割方

案。求解此切割方案的算法基本思想如下：假設長鋼條的長度為n英寸，最佳切割

方案的最左邊切割段長度為i英寸，則繼續求解剩余長度為n-i英寸鋼條的最佳切割

方案。考慮所有可能的i,得到的最大收益如對應的切割方案即為最佳切割方案。3

的遞歸定義如下：rn=maxi<i<n(Pi+rn.i)對此遞歸式，給出自項向下和自底向上兩種

/*常量和受盤說明

m長輛條的長度

p[]:價格數蛆

*/

tdefineLEN100

intTop_DownCutRod(intp(),intn)(/*自頂向下?/

intr-0;

inti;

if(n-0)(

return0;

1

for(1?1;(1)(

inttmp-p(i]?Top_Down_Cut_Rcxl(p,n-i);

r-(r?r:tmp;

)

returnr;

}

intBottomUpCutRod(intp[],intn)(八自底向上*/

intr[LEN]?{0};

inttemp-0?

int1,j;

for(j?1;j<?n;(

temp-0;

for(i-1;(2);1-*??)(

temp-(3);

)

(4)；

)

returnr[n];

實現方式。【C代碼】1

11、根據說明，填充C代碼中的空(1)?(4)。

標準答案：(l)iV=n或其等效形式(2)iV=j或其等效形式(3)temp>=p[i]+r[j-

i]?temp：p[i]+r[j-i]或其等效形式(4)r|j]=temp

知識點解析：暫無解析

12、根據說明和C代碼、算法采用的設計策略為(5)。求解小時，自項向下方法的時

間復雜度為(6)；自底向上方法的時間復雜度為(7)(用O表示)。

標準答案：(5)動態規劃(6)0(2,(7)0(1?)

知識點解析：本題考查算法設計與分析技術的基礎知識和應用能力。解答該類題

目,首先需要理解問題和求解問題的算法思想，一般在題干中已經清晰地描述了算法

的基本思想。鋼條切割問題是一個最優化問題。求解的思路非常簡單，考慮最優方

案中最左邊的切割，此時將一個大問題轉化為一個小問題。題干已經給出了最關鍵

的遞歸式。C程序根據遞歸式,給出自頂向下和自底向上兩種實現方法。【問題

1]在自頂向下的實現巳直接用遞歸方法實現遞歸式，因此空⑴填i〈=n。在自底

向上的實現中，采用迭代方法實現遞歸式，這里采用了兩重循環。外重循環j表示問

題的規模,內重循環計算規模為j的鋼條切割的最優解的值,因此空(2)填iV=j。空(3)

其實就是算法的核心，判斷當前的最優解對應的價值temp大，還是當前的i對應的最

優解的價值p|i]+r|j-i|更大，如果temp小，則更換當前最優解對應的價值。因此，空(3)

填入if(temp<p[i]+r[j-i]){temp=p[i]+r[j-i])也可以參考自頂向下的實現方法中的

語句r=(r>=tmp)?r：tmp,答案為temp>=p[i]+r[j-i]?temp：p[i]+r[j-i]o對某個j計算

得到其最優解之后，將其存到山]中，即空(4)填r|j]=tempo【問題2】根據題干說明

和C程序，應該能比較清晰地看出算法是基于動態規劃策略設計的。在自頂向下的

?T

T(?)=UyT(O

實現中，因為是遞歸實現，可以列出遞歸式如下：XO求解該式子,得到時

間復雜度為O(2n)。那么高的時間復雜度主要是因為相同的子問題會多次重復地被

調用。另外，若不會求解該式子，可以畫出遞歸樹求解。而在自底向上的實現方法中,

采用了兩重循環，因此算法的時間復雜度為0(22)。

二、選答題(本題共2題，每題1.0分，共2分。)

13、閱讀下列說明和C++代碼，回答問題。【說明】生成器(Builder)模式的意圖是

將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表

示。圖5-1所示為其類圖。圖5“生成器模式類圖【C++代

?include<iostrearo>

?lnclude<string>

usingnamespacestd;

classProduct(

private:

stringpartA,partB;

public:

Product()()

voidsetPartA(conststring，s){partA?s;)

voidsetPartB(conststringss)(partB=s;)

〃其余代碼省略

)；

classBuilder(

public:

(1)；

virtualvoidbuildPartBf)-0;

(2);

)；

classConcreteBuilderl:publicBuilder{

private:

Product*product;

public:

ConcreteBuilderl(){product-newProduct();)

voidbuildPartAO{(3)("ComponentA");}

voidbuildPartBO{(4)("ComponentB");}

Product*getResult(){returnproduct;)

//其余代碼省略

}；

classConcreteBuilder2:publicBuilder(

/*代碼省略?/

)；

classDirector(

private:

Builder*builder;

public:

Director(Builder*pBuilder){builder-pBuilder;)

voidconstruct(){

(5);

〃其余代碼省略

)

〃箕余代碼省略

)；

intmain()(

Director*dlxwtocl-newDirector(newConcreteBuilderl(>);

directorl->construct();

deletedirectorlj

return0;

碼】

標準答案：(l)virtualvoidbuildPartA0=0(2)virtualProduct*getResult()=0(3)producl-

>setPartA(4)product->setPartB(5)builder->buildPartA()或builder->buildPartB()

知識點解析：本題考查設計模式中生成器(Builder)模式的基本概念和實現。生成器

模式是一種典型的創建型模式。創建型模式抽象了實例化過程，它們幫助一個系統

獨立于如何創建、組合和表示它的那些對象。一個類創建型模式使用繼承改變被實

例化的類，而一個對象創建型模式將實例化委托給另一個對象。在這些模式中有兩

個不斷出現的主旋律：第一，它們都將關于該系統使用哪些具體的類的信息封裝起

來：第二,它們隱藏了這些類的實例是如何被創建和放在一起的。對于整個系統來

說，這些對象是由抽象類所定義的接口。因此,創建型模式在什么被創建、誰創建

它、它是怎樣被創建的以及何時創建這些方面給予了很大的靈活性。它們允許用

結構和功能差別很大的產品對象配置一個系統。配置可以是靜態的(即在編譯時指

定),也可以是動態的(在運行時)。生成器模式的意圖是，將一個復雜對象的構建與它

的表小分離，使得同樣的構建過程可以創建不同的標識。生成器模式的結構如圖5-

2所示。

圖82生成器模式結構圖其

中：?Builder為創建一個Product對象的各個部件指定抽象接口。ConcreteBuilder

實現Builder的接口以構造和裝配該產品的各個部件,定義并明確它所創建的表示，提

供一個檢索產品的接口。Qireclor構造一個使用Builder接口的對象。?ProducL表

示被構造的復雜對象vConcreteBuilder創建該產品的內部表示并定義它的裝配過

程。包含定義組成組件的類,包括將這些組件裝配成最終產品的接口。生.成器模式

適用于：當創建復雜對象的算法應該獨立于該對象的組成部分以及它們的裝配方式

時；當構造過程必須允許被構造的對象有不同的表示時。圖5-1中的類Product包

含兩個組成部分：partA和partB。因此在類Builder中需要為這兩個組成部分創建

抽象接口。在C++中，抽象接口通常采用純虛擬函數來實現。純虛擬函數是沒有實

現體的虛擬函數，它在基類中定義，在派生類中重置。構造partB的接口在代碼中己

經給出，因此第(1)空應填寫virtualvoidbuiidPartA()=Oo第(2)空的內容可以從

Builder的派生類ConcreteBuilderl來進行推斷。在ConcreteBuilderl中出現了方法

getResnlt.根據卜下文，可以判定該方法可能繼承自其基類Ruilder,并在派生類中重

置。因此第⑵空應填寫virtualProduct*gctResult()=0。第(3)、(4)空用于創建產品的

內部表示。Product包含兩部分：partA和partB,分別調用類Product中提供的方法

setPartA和setPartB來實現。因此(3)、(4)空應分別填入product〉VsetPartA和

product-AselParlB。第(5)空是對Bulider中接口的使用，這里應填入builder->

buildPartA。或builder->buildPartB()o

14、閱讀下列說明和Java代碼，回答問題。【說明】生成器(Builder)模式的意圖是

將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表

示。圖6-1所示為其類圖。圖31生成器模式類圖[Java代碼】

importjava,util

classProduct(

privateStringpartA;

privateStringparts；

publicProduct()()

publicvoidsetPartA(Strings)(partA-s;)

publicvoidsetPartB(Strings)(partB-s;)

interfaceBuilder{

public(1);

publicvoidbuildPartB();

public(2);

)

classConcreteBuilderlimplementsBuilder(

privateProductproduct;

publicConcreteBuilderl(){product-newProduct();)

publicvoidbuildPartAO{(3)("ComponentA");}

publicvoidbuildPartBO{(4)("ComponentB");}

publicProductgetResult(){returnproduct;)

}

classConcreteBuilderJimplementsBuilder(

〃代碼省略

classDirector(

privateBuilderbuilder;

publicDirector(Builderbuilder)