省考軟件設計師考試模擬題及答案資格證從業(yè)考試題卷(6)

1、 軟件設計師考試模擬題及答案-試題一 閱讀以下說明和圖，回答問題1至問題3，將解答填入對應欄內(nèi)。 說明 某時裝郵購提供商擬開發(fā)訂單處理系統(tǒng)，用于處理客戶通過電話、傳真、郵件或Web站點所下訂單。其主要功能如下： (1)增加客戶記錄。將新客戶信息添加到客戶文件，并分配一個客戶號以備后續(xù)使用。 (2)查詢商品信息。接收客戶提交的商品信息請求，從商品文件中查詢商品的價格和可訂購數(shù)量等商品信息，返回給客戶。 (3)增加訂單記錄。根據(jù)客戶的訂購請求及該客戶記錄的相關信息，產(chǎn)生訂單并添加到訂單文件中。 (4)產(chǎn)生配貨單。根據(jù)訂單記錄產(chǎn)生配貨單，并將配貨單發(fā)送給倉庫進行備貨；備好貨后，發(fā)送備貨就緒通知。如果

2、現(xiàn)貨不足，則需向供應商訂貨。 (5)準備發(fā)貨單。從訂單文件中獲取訂單記錄，從客戶文件中獲取客戶記錄，并產(chǎn)生發(fā)貨單。 (6)發(fā)貨。當收到倉庫發(fā)送的備貨就緒通知后，根據(jù)發(fā)貨單給客戶發(fā)貨；產(chǎn)生裝運單并發(fā)送給客戶。 (7)創(chuàng)建客戶賬單。根據(jù)訂單文件中的訂單記錄和客戶文件中的客戶記錄，產(chǎn)生并發(fā)送客戶賬單，同時更新商品文件中的商品數(shù)量和訂單文件中的訂單狀態(tài)。 (8)產(chǎn)生應收賬戶。根據(jù)客戶記錄和訂單文件中的訂單信息，產(chǎn)生并發(fā)送給財務部門應收賬戶報表。 現(xiàn)采用結構化方法對訂單處理系統(tǒng)進行分析與設計，獲得如圖1-1所示的頂層數(shù)據(jù)流圖和圖1-2所示的0層數(shù)據(jù)流圖。 1、使用說明中的詞語，給出圖1-1中的實體E1E

3、3的名稱。2、使用說明中的詞語，給出圖1-2中的數(shù)據(jù)存儲D1D3的名稱。給出圖1-2中處理(加工)P1和P2的名稱及其相應的輸入輸出流。 3除加工P1和P2的輸入輸出流外，圖1-2還缺失了1條數(shù)據(jù)流，請給出其起點和終點。起點終點 注：名稱使用說明中的詞匯，起點和終點均使用圖1-2中的符號或詞匯。試題二 閱讀以下說明，回答問題1至問題3，將解答填入對應欄內(nèi)。 說明 某公司擬開發(fā)一套小區(qū)物業(yè)收費管理系統(tǒng)。初步的需求分析結果如下： (1)業(yè)主信息主要包括：業(yè)主編號、姓名、房號、房屋面積、工作單位、聯(lián)系電話等。房號可唯一標識一條業(yè)主信息，且一個房號僅對應一套房屋；一個業(yè)主可以有一套或多套的房屋。 (2

4、)部門信息主要包括：部門號、部門名稱、部門負責人、部門電話等。一個員工只能屬于一個部門，一個部門只有一位負責人。 (3)員工信息主要包括：員工號、姓名、出生年月、性別、住址、聯(lián)系電話、所在部門號、職務和密碼等。根據(jù)職務不同，員工可以有不同的權限：職務為“經(jīng)理”的員工具有更改(添加、刪除和修改)員工表中本部門員工信息的操作權限；職務為“收費”的員工只具有收費的操作權限。 (4)收費信息包括：房號、業(yè)主編號、收費日期、收費類型、數(shù)量、收費金額、員工號等。收費類型包括物業(yè)費、衛(wèi)生費、水費和電費，并按月收取，收費標準如表2-1所示。其中：物業(yè)費=房屋面積(平方米)每平方米單價，衛(wèi)生費=套房數(shù)量(套)每

5、套房單價，水費=用水數(shù)量(噸)每噸水單價，電費=用電數(shù)量(度)每度電單價。表2-1收費標準 收費類型單位單價物業(yè)費平方米1.00衛(wèi)生費套10.00水費噸0.70電費度0.80 (5)收費完畢應為業(yè)主生成收費單，收費單示例如表2-2所示。 表2-2收費單示例 房號：A1608業(yè)主姓名：李斌 序號收費類型數(shù)量金額1物業(yè)費98.698.602衛(wèi)生費110.003水費64.204電費10281.60合計壹佰玖拾肆元肆角整194.40收費日期：010-9-2員工號：001 概念模型設計 根據(jù)需求階段收集的信息，設計的實體聯(lián)系圖(不完整)如圖2-1所示。圖2-1中收費員和經(jīng)理是員工的子實體。 邏輯結構設計

6、 根據(jù)概念模型設計階段完成的實體聯(lián)系圖，得出如下關系模式(不完整)： 業(yè)主( (1) , 姓名, 房屋面積, 工作單位, 聯(lián)系電話) 員工( (2) , 姓名, 出生年月, 性別, 住址, 聯(lián)系電話, 職務, 密碼) 部門( (3) , 部門名稱, 部門電詁) 權限(職務, 操作權限) 收費標準( (4) ) 收費信息( (5) , 收費類型, 收費金額, 員工號)根據(jù)圖2-1，將邏輯結構設計階段生成的關系模式中的空56補充完整，然后給出各關系模式的主鍵和外鍵。填寫圖2-1中(a)(f)處聯(lián)系的類型(注：一方用1表示，多方用m或n或*表示)，并補充完整圖2-1中的實體、聯(lián)系和聯(lián)系的類型。16、

7、業(yè)主關系屬于第幾范式?請說明存在的問題。試題三 閱讀下列說明和圖，回答問題1至問題3，將解答填入對應欄內(nèi)。說明 某網(wǎng)上藥店允許顧客憑借醫(yī)生開具的處方，通過網(wǎng)絡在該藥店購買處方上的藥品。該網(wǎng)上藥店的基本功能描述如下： 17注冊。顧客在買藥之前，必須先在網(wǎng)上藥店注冊。注冊過程中需填寫顧客資料以及付款方式(信用卡或者支付寶賬戶)。此外顧客必須與藥店簽訂一份授權協(xié)議書，授權藥店可以向其醫(yī)生確認處方的真?zhèn)巍?18登錄。已經(jīng)注冊的顧客可以登錄到網(wǎng)上藥房購買藥品。如果是沒有注冊的顧客，系統(tǒng)將拒絕其登錄。 19錄入及提交處方。登錄成功后，顧客按照“處方錄入界面”顯示的信息，填寫開具處方的醫(yī)生的信息以及處方上的

8、藥品信息。填寫完成后，提交該處方。 20驗證處方。對于已經(jīng)提交的處方(系統(tǒng)將其狀態(tài)設置為“處方已提交”)，其驗證過程為： 核實醫(yī)生信息。如果醫(yī)生信息不正確，該處方的狀態(tài)被設置為“醫(yī)生信息無效”，并取消這個處方的購買請求；如果醫(yī)生信息是正確的，系統(tǒng)給該醫(yī)生發(fā)送處方確認請求，并將處方狀態(tài)修改為“審核中”。 如果醫(yī)生回復處方無效，系統(tǒng)取消處方，并將處方狀態(tài)設置為“無效處方”。如果醫(yī)生沒有在7天內(nèi)給出確認答復，系統(tǒng)也會取消處方，并將處方狀態(tài)設置為“無法審核”。 如果醫(yī)生在7天內(nèi)給出了確認答復，該處方的狀態(tài)被修改為“準許付款”。 系統(tǒng)取消所有未通過驗證的處方，并自動發(fā)送一封電子郵件給顧客，通知顧客處方被

9、取消以及取消的原因。 21對于通過驗證的處方，系統(tǒng)自動計算藥品的價格并郵寄藥品給已經(jīng)付款的顧客。 該網(wǎng)上藥店采用面向對象方法開發(fā)，使用UML進行建模。系統(tǒng)的類圖如圖3-1所示。 17、根據(jù)說明中的描述，給出圖3-1中缺少的C1C5所對應的類名以及(1)(6)處所對應的多重度。18、圖3-2給出了“處方”的部分狀態(tài)圖。根據(jù)說明中的描述，給出圖3-2中缺少的S1S4所對應的狀態(tài)名以及(7)(10)處所對應的遷移(transition)名。19、圖3-1中的符號“”和“”在UML中分別表示類和對象之間的哪兩種關系?兩者之間的區(qū)別是什么?試題四 閱讀下列說明和C代碼，回答問題1至問題3，將解答寫在對應

10、欄內(nèi)。 說明 堆數(shù)據(jù)結構定義如下： 對于n個元素的關鍵字序列a1, a2, , an，當且僅當滿足下列關系時稱其為堆。 在一個堆中，若堆頂元素為最大元素，則稱為大頂堆；若堆項元素為最小元素，則稱為小頂堆。堆常用完全二叉樹表示，圖4-1是一個大頂堆的例子。 堆數(shù)據(jù)結構常用于優(yōu)先隊列中，以維護由一組元素構成的集合。對應于兩類堆結構，優(yōu)先隊列也有最大優(yōu)先隊列和最小優(yōu)先隊列，其中最大優(yōu)先隊列采用大頂堆，最小優(yōu)先隊列采用小頂堆。以下考慮最大優(yōu)先隊列。 假設現(xiàn)已建好大頂堆A，且已經(jīng)實現(xiàn)了調整堆的函數(shù)heapify(A,n,index)。 下面將C代碼中需要完善的三個函數(shù)說明如下： (1)heapMaxim

11、umA.：返回大頂堆A中的最大元素。 (2)heapExtractMaxA.：去掉并返回大頂堆A的最大元素，將最后一個元素“提前”到堆頂位置，并將剩余元素調整成大頂堆。 (3)maxHeapInsert(A,key)：把元素key插入到大頂堆A的最后位置，再將A調整成大頂堆。 優(yōu)先隊列采用順序存儲方式，其存儲結構定義如下： #define PARENT(i) i/2 typedef struct array int *int_array; /優(yōu)先隊列的存儲空間首地址 int array_size; /優(yōu)先隊列的長度 int capacity; /優(yōu)先隊列存儲空間的容量 ARRAY; C代碼 (

12、1)函數(shù)heapMaximum int heapMaximum(ARRAY *A. return (1) ; (2)函數(shù)heapExtractMax int heapExtractMax(ARRAY *A. int max; max=A-int_array0; (2) ; A-array_size -; heapify(A,A-array_size,0); /將剩余元素調整成大項堆 return max; (3)函數(shù)maxHeapInsert int maxHeapInsert(ARRAY *A, int key) int i, *p; if (A-array_size=A-capacity)

13、 /存儲空間的容量不夠時擴充空間 P=(int*)realloc(A-int_array, A-capacity *2 * sizeof(int); if (!p) return -1; A-int_array=p; A-capacity=2 * A-capacity; A-array_size +; i = (3) ; while (i0 (4) ) A-int_arrayi=A-int_arrayPARENT(i); i=PARENT(i); (5) ; return 0; 根據(jù)以上說明和C代碼，填充C代碼中的空2021。根據(jù)以上C代碼，函數(shù)heapMaximum、heapExtractM

14、ax和maxHeapInsert的時間復雜度的緊致上界分別為 25 、 26 和 27 (用O符號表示)。28、若將元素10插入到堆A=(15,13,9,5,12,8,7,4,0,6,2,1)中，調用maxHeapInsert函數(shù)進行操作，則新插入的元素在堆A中第 個位置(從1開始)。試題五 閱讀下列說明和C+代碼，將應填入 (n) 處的字句寫在對應欄內(nèi)。說明 某公司的組織結構圖如圖5-1所示，現(xiàn)采用組合(Composition)設計模式來構造該公司的組織結構，得到如圖5-2所示的類圖。 其中Company為抽象類，定義了在組織結構圖上添加(Add)和刪除(Delete)分公司/辦事處或者部門

15、的方法接口。類ConcreteCompany表示具體的分公司或者辦事處，分公司或辦事處下可以設置不同的部門。類HRDepartment和FinanceDepartment分別表示人力資源部和財務部。 C+代碼 #include iostream #include list #include string using namespace std; class Company /抽象類 protected: string name; public: Company(string name) 29 =name; 30 ; /增加子公司、辦事處或部門 31 ; /刪除子公司、辦事處或部門 ; clas

16、s ConcreteCompany: public Company private: list 32 children; /存儲子公司、辦事處或部門 public: ConcreteCompany(string name):Company(name) void Add(Company* c) 33 . push_back(c); void Delete(Company* c) 34 . remove(c); ; class HRDepartment : public Company public: HRDepartment(string name): Company(name) /其他代碼省略

17、 ; class FinanceDepartment: public Company public: FinanceDepartment(string name): Company(name) /其他代碼省略 ; void main37 ConcreteCompany *root=new ConcreteCompany(北京總公司); root-Add(new HRDepartment(總公司人力資源部); root-Add(new FinanceDepartment(總公司財務部); ConcreteCompany *comp=new ConcreteCompany(上海分公司); comp

18、-Add(new HRDepartment(上海分公司人力資源部); comp-Add(new FinanceDepartment(上海分公司財務部); 35 ; ConcreteCompany *comp1=new ConcreteCompany(南京辦事處); comp1-Add(new HRDepartment(南京辦事處人力資源部); comp1-Add(new FinanceDepartment(南京辦事處財務部); 36 ; /其他代碼省略 試題六 閱讀下列說明和Java代碼，將應填入 (n) 處的字句寫在對應欄內(nèi)。說明 某公司的組織結構圖如圖6-1所示，現(xiàn)采用組合(Composi

19、tion)設計模式來設計，得到如圖6-2所示的類圖。 其中Company為抽象類，定義了在組織結構圖上添加(Add)和刪除(Delete)分公司/辦事處或者部門的方法接口。類ConcreteCompany表示具體的分公司或者辦事處，分公司或辦事處下可以設置不同的部門。類HRDepartment和FinanceDepartment分別表示人力資源部和財務部。 Java代碼 import java.util.*; 37 Company protected String name; public Company(String name)( 38 =name; public abstract void

20、 Add(Company c); /增加子公司、辦事處或部門 public abstract void Delete(Company c); /刪除子公司、辦事處或部門 class ConcreteCompany extends Company private List 39 children=new ArrayList 40 45; /存儲子公司、辦事處或部門 public ConcreteCompany(String name) super(name); public void Add(Company c) 41 . add(c); public void Delete(Company c

21、) 42 .remove(c); class HRDepartment extends Company public HRDepartment(String name) super(name); /其他代碼省略 Class FinanceDepartment extends Company public FinanceDepartment(String name) super(name); /其他代碼省略 public class Test public Static void main(String args) ConcreteCompany root=new ConcreteCompany

22、(北京總公司); root.Add(new HRDepartment(總公司人力資源部); root.Add(new FinanceDepartment(總公司財務部); ConcreteCompany comp=new ConcreteCompany(上海分公司); comp.Add(new HRDepartment(上海分公司人力資源部); comp.Add(new FinanceDepartment(上海分公司財務部); 43 ; ConcreteCompany comp1=new ConcreteCompany(南京辦事處); comp1.Add(new HRDepartment(南京

23、辦事處人力資源部); comp1.Add(new FinanceDepartment(南京辦事處財務部); 44 ; /其他代碼省略 答案:試題一1、E1:客戶 E2:財務部門 E3:倉庫本題考查采用結構化方法進行系統(tǒng)分析與設計的知識，是比較傳統(tǒng)的題目，要求考生細心分析題目中所描述的內(nèi)容。 數(shù)據(jù)流圖(DFD)是一種便于用戶理解、分析系統(tǒng)數(shù)據(jù)流程的圖形化建模工具，是系統(tǒng)邏輯模型的重要組成部分。 本問題考查頂層DFD。頂層DFD一般用來確定系統(tǒng)邊界，將待開發(fā)系統(tǒng)看作一個加工，因此圖中只有唯一的一個處理和一些外部實體，以及這兩者之間的輸入輸出數(shù)據(jù)流。題目要求根據(jù)描述確定圖中的外部實體。根據(jù)題目中的描

24、述，并結合已經(jīng)在項層數(shù)據(jù)流圖中給出的數(shù)據(jù)流進行分析。從題目的說明中可以看出：客戶提交商品信息請求、訂購請求等；將配貨單發(fā)送給倉庫、倉庫向系統(tǒng)發(fā)送備貨就緒通知；發(fā)送給財務部門應收賬戶報表。由此可知該訂單系統(tǒng)有客戶、倉庫和財務部門三個外部實體。對應圖1-1中數(shù)據(jù)流和實體的對應關系，可知E1為客戶，E2為財務部門，E3為倉庫。本題中需注意說明(4)中向供應商訂貨是系統(tǒng)外部的行為，因此，供應商并非本系統(tǒng)的外部實體。2、D1:客戶文件 D2:商品文件 D3:訂單文件本題考查采用結構化方法進行系統(tǒng)分析與設計的知識，是比較傳統(tǒng)的題目，要求考生細心分析題目中所描述的內(nèi)容。 數(shù)據(jù)流圖(DFD)是一種便于用戶理解

25、、分析系統(tǒng)數(shù)據(jù)流程的圖形化建模工具，是系統(tǒng)邏輯模型的重要組成部分。 本問題考查0層DFD中數(shù)據(jù)存儲的確定。根據(jù)說明中的以下描述：將新客戶信息添加到客戶文件；從商品文件中查詢商品的價格和可訂購數(shù)量等商品信息；產(chǎn)生訂單并添加到訂單文件中，得出數(shù)據(jù)存儲為客戶文件、商品文件以及訂單文件，再根據(jù)圖1-2中D1的輸入和輸出數(shù)據(jù)流均為客戶記錄，D2的輸入數(shù)據(jù)流為從處理“創(chuàng)建客戶賬單”來的新商品數(shù)量，輸出數(shù)據(jù)流為到處理“查詢商品信息”的商品數(shù)量和價格，D3的輸入數(shù)據(jù)流為從處理“增加客戶訂單”來的訂單，可知，D1為客戶文件，D2為商品文件，D3為訂單文件。3、處理(加工)名稱，數(shù)據(jù)流。P1:產(chǎn)生配貨單P2:準備

26、發(fā)貨單 數(shù)據(jù)流名稱起點終點訂單記錄D3或訂單文件P1或產(chǎn)生配貨單配貨單P1或產(chǎn)生配貨單E3或倉庫訂單記錄D3或訂單文件P2或準備發(fā)貨單客戶記錄D1或客戶文件P2或準備發(fā)貨單發(fā)貨單P2或準備發(fā)貨單發(fā)貨 上表中各行次序無關，但每條數(shù)據(jù)流的名稱、起點、終點必須相對應。 P1和P2可互換，即P1為“準備發(fā)貨單”、P2為“產(chǎn)生配貨單”。 4、缺少的數(shù)據(jù)流：起點終點D1或客戶文件創(chuàng)建客戶賬單本題考查采用結構化方法進行系統(tǒng)分析與設計的知識，是比較傳統(tǒng)的題目，要求考生細心分析題目中所描述的內(nèi)容。 數(shù)據(jù)流圖(DFD)是一種便于用戶理解、分析系統(tǒng)數(shù)據(jù)流程的圖形化建模工具，是系統(tǒng)邏輯模型的重要組成部分。 本問題考查

27、0層DFD中缺失的處理和數(shù)據(jù)流。從說明中的描述功能和圖1-2，可知產(chǎn)生配貨單和準備發(fā)貨單沒有在圖1-2中，即缺少兩個處理：產(chǎn)生配貨單和準備發(fā)貨單。根據(jù)說明(4)中的描述：根據(jù)訂單記錄產(chǎn)生配貨單，并將配貨單發(fā)送給倉庫進行備貨；備好貨后，發(fā)送備貨就緒通知?？芍?，產(chǎn)生配貨單的輸入流為訂單記錄，該輸入流的起點為訂單文件(D3)，輸出流為配貨單，其終點為倉庫(E3)。根據(jù)說明(5)中的描述：從訂單文件中獲取訂單記錄，從客戶文件中獲取客戶記錄，并產(chǎn)生發(fā)貨單。可知，準備發(fā)貨單的輸入流為訂單記錄和客戶記錄，訂單記錄的起點為訂單文件，客戶記錄的起點為客戶文件；輸出流為發(fā)貨單。再根據(jù)說明(6)中處理發(fā)貨的描述：根

28、據(jù)發(fā)貨單給客戶發(fā)貨，發(fā)貨單的終點為處理發(fā)貨。產(chǎn)生配貨單和準備發(fā)貨單分別對應P1和P2(或P2和P1)。 P1和P2及其輸入輸出流均識別出來之后，再對照說明和圖1-2，以找出缺少的另外一條數(shù)據(jù)流。對照說明(7)中的描述：根據(jù)訂單文件中的訂單記錄和客戶文件中的客戶記錄，產(chǎn)生并發(fā)送客戶賬單。因此，創(chuàng)建客戶賬單缺少一條輸入流：客戶記錄，其起點為客戶文件(D1)。試題二5、業(yè)主編號，房號 主鍵：房號 外鍵：無 6、員工號，所在部門號 主鍵：員工號 外鍵：所在部門號 7、部門號，部門負責人 主鍵：部門號 外鍵：部門負責人 8、收費類型，單位，單價 主鍵：收費類型 外鍵：無 9、房號，業(yè)主編號，收費日期 主

29、鍵：房號，業(yè)主編號，收費日期 外鍵：房號，員工號根據(jù)題意，業(yè)主關系中信息主要包括：業(yè)主編號、姓名、房號、房屋面積、工作單位、聯(lián)系電話等，因此，空(1)應填寫“業(yè)主編號，房號”。又因為房號可唯一標識一條業(yè)主信息，所以以“房號”為主鍵。完整的關系模式如下： 業(yè)主(業(yè)主編號, 房號, 姓名, 房屋面積, 工作單位, 聯(lián)系電話) 根據(jù)題意，員工信息主要包括：員工號、姓名、出生年月、性別、住址、聯(lián)系電話、所在部門號、職務和密碼等，因此，空(2)應填寫“員工號，所在部門號”。又因為員工號可唯一標識一條員工信息，所以“員工號”為主鍵。根據(jù)題意，一個員工只能屬于一個部門，“所在部門號”應參照部門關系的“部門號

30、”，因此，“所在部門號”為外鍵。完整的關系模式如下： 員工(員工號, 所在部門號, 姓名, 出生年月, 性別, 住址, 聯(lián)系電話, 職務, 密碼) 部門信息主要包括：部門號、部門名稱、部門負責人、部門電話等，因此，部門關系的空(3)應填寫“部門號，部門負責人”，顯然該關系的主鍵為“部門號”。又因為部門關系的“部門負責人”應參照員工關系的“員工號”，因此，“部門負責人”為外鍵。 根據(jù)題意分析收費標準關系的空(4)應填寫“收費類型，單位，單價”，這樣收費信息關系可以根據(jù)收費類型(如水費、電費或物業(yè)費)去收費標準關系中查出單價來計算收費金額。顯然收費標準關系的主鍵為“收費類型”。 收費信息的空(5)

31、應填寫“房號，業(yè)主編號，收費日期”，由于“房號，業(yè)主編號，收費日期”能唯一確定該關系的每一個元組，故“房號，業(yè)主編號，收費日期”為關系的主鍵。又由于房號、員工號分別為業(yè)主和員工關系的主鍵，故“房號，員工號”為收費信息關系的外鍵。完整的關系模式如下： 收費信息(房號, 業(yè)主編號, 收費日期, 收費類型, 收費金額, 員工號)10、n，或m，或* 11、n，或m，或* 12、 13、n，或m，或* 14、 15、n，或m，或* 根據(jù)題意，一個員工可以為多個業(yè)主收費，同樣一個業(yè)主也可以有多個員工為其收費，因此業(yè)主和收費員之間的收費聯(lián)系為多對多。故空(a)應填寫*，空(b)應填寫*。 因為一個員工只能

32、屬于一個部門，所以部門與員工之間的隸屬聯(lián)系是一對多的。故空(c)應填寫1，空(d)應填寫*。 根據(jù)題意，職務不同員工可以有不同的權限，所以權限和員工之間的合法聯(lián)系是一對多。 又由于收費員收費時必需根據(jù)收費類型(如水費、電費或物業(yè)費)到收費標準關系中查出單價來計算收費金額，所以需要增加一個收費標準關系，以及收費標準到收費聯(lián)系的連線。16、業(yè)主關系屬于第2范式。 問題是當某業(yè)主有多套住房時，屬性“業(yè)主編號，姓名，房屋面積，工作單位，聯(lián)系電話”等信息在業(yè)主關系表中重復存儲，存在數(shù)據(jù)冗余。由業(yè)主關系可知：房號業(yè)主編號，業(yè)主編號姓名，房號姓名，所以存在傳遞依賴房號姓名。故業(yè)主關系屬于第2范式。業(yè)主關系存

33、在的問題是當某業(yè)主有多套住房時，屬性“業(yè)主編號，姓名，房屋面積，工作單位，聯(lián)系電話”等信息在業(yè)主關系表中重復存儲，存在數(shù)據(jù)冗余。試題三17、C1：付款方式 C2：處方 C3：信用卡 C4：支付寶賬戶 C5：處方上的藥品(或藥品) (C3，C4可以互換) (1)1 (2)0.* (3)1 (4)1.* (5)0.* (6)1本題考查UML的應用，是比較傳統(tǒng)的題目，要求考生細心分析題目中所描述的內(nèi)容。 本問題考查UML的類圖。類圖展現(xiàn)了一組對象、接口、協(xié)作和它們之間的關系。在面向對象系統(tǒng)的建模中，最常用的模型之一就是類圖。 類圖用于對系統(tǒng)的靜態(tài)設計視圖建模。這種視圖主要支持系統(tǒng)的功能需求，即系統(tǒng)要

34、提供給用戶的服務。但對系統(tǒng)的靜態(tài)設計視圖建模時，通常有三種使用方式： (1)對系統(tǒng)的詞匯建模 對系統(tǒng)的詞匯建模涉及做出這樣的決定：哪些抽象是考慮中的系統(tǒng)的一部分，哪些抽象處于系統(tǒng)邊界之外。用類圖詳細描述這些抽象和它們的職責。 (2)對簡單的協(xié)作建模 協(xié)作是一些共同工作的類、接口和其他元素的群體，該群體提供的一些合作行為強于所有這些元素的行為之和。例如當對分布式系統(tǒng)的事務語義建模時，不能僅僅盯著一個單獨的類來推斷要發(fā)生什么，而要有相互協(xié)作的一組類來實現(xiàn)這些語義。用類圖對這組類以及它們之間的關系進行可視化和詳述。 (3)對邏輯數(shù)據(jù)庫模式建模 將模式看作數(shù)據(jù)庫的概念設計的藍圖。在很多領域中，要在關系

35、數(shù)據(jù)庫或面向對象數(shù)據(jù)庫中存儲永久信息?？梢杂妙悎D對這些數(shù)據(jù)庫的模式建模。 本題主要使用類圖對系統(tǒng)詞匯進行建模。題目中已經(jīng)給出了類圖的基本框架及部分的類，要求考生將類圖中其余的類補充完整。在解答這類題目時，需要細心閱讀說明中的文字，并記錄和整理其中出現(xiàn)的名詞。這些名詞將來有可能成為類。其次應特別關注類圖中出現(xiàn)的特殊關聯(lián)關系，如繼承關系、聚集/組裝關系等。 在本題中，首先考查類圖中的Customer、C2和Doctor這三個類。由說明可知，在網(wǎng)上購藥時，顧客與醫(yī)生之間不會直接發(fā)生交互，而是通過顧客持有的“處方”而發(fā)生關聯(lián)。由此可以確定C2對應的類應該是“處方”。 C2與C5之間是聚集關系，其中C2

36、表示整體類，C5表示部分類。由于已經(jīng)確定了C2表示的是“處方”類，那么C5表示就應該是處方所包含的內(nèi)容。處方中包含的是藥品，所以C5對應的類應該是“處方上的藥品”。 下面來分析類圖中的繼承關系。繼承關系表示類之間的“一般/特殊”關系。C1表示一般類，C3和C4是C1的兩個具體類；并且這三個類與Customer之間具有組裝關系。那么在說明中出現(xiàn)的所有名詞詞匯中，具有明顯的一般/特殊關系的就是“付款方式”、“信用卡”和“支付寶賬戶”?！靶庞每ā焙汀爸Ц秾氋~戶”是具體的付款形式，當顧客付款的時候選擇二者中的一個。而且每一次付款都與一個特定的顧客(即類Customer的一個實例)相關，沒有顧客就不會發(fā)

37、生付款行為。所以C1對應的類應該是“付款方式”、C3和C4分別對應的是類“信用卡”、“支付寶賬戶”。 多重度表示一個類的實例與多少個另一個類的實例發(fā)生關聯(lián)。因此，在確定多重度時需要關注說明中關于類之間關系的描述。 首先來看C2和C5，這兩個類之間是聚集關系。前面已經(jīng)確定了C2和C5分別對應類“處方”和“處方上的藥品”。一張?zhí)幏缴蠎?種或多種藥品。這樣很容易確定出(3)和(4)的多重度應分別為1以及1.*。 “處方”和“醫(yī)生”之間的關系如下：一名醫(yī)生可以開多張?zhí)幏?，也可以不開處方，所以(5)處的多重度應該為0.*；而一張?zhí)幏奖囟ㄊ怯梢幻t(yī)生開具的，所以(6)處的多重度應該為1。 “顧客”與“

38、處方”之間的關系如下：一個顧客可以持有多張?zhí)幏絹碣I藥，也可以沒有處方，這樣就不會發(fā)生購買行為。所以(2)處的多重度應該為0.*。而每張?zhí)幏揭欢▽儆谝幻櫩停?1)處的多重度應該為1。18、S1：審核中 S2：無法審核 S3：醫(yī)生信息無效 S4：無效處方 (7)醫(yī)生信息不正確 (8)醫(yī)生信息正確 (9)醫(yī)生回復處方無效 (10)醫(yī)生沒有在7天內(nèi)給出確認答復 或者： S2：無效處方 S4：無法審核 (9)醫(yī)生沒有在7天內(nèi)給出確認答復 (10)醫(yī)生回復處方無效 S1、S3、(7)、(8)同上本題考查UML的應用，是比較傳統(tǒng)的題目，要求考生細心分析題目中所描述的內(nèi)容。 狀態(tài)圖關注系統(tǒng)的動態(tài)視圖，它

39、注重描述可能的狀態(tài)序列，以及在特定狀態(tài)下對象對外部離散事件的響應動作。 本題考查的是類“處方”的對象的狀態(tài)變化。關于網(wǎng)上藥店對“處方”的處理流程，在說明的(4)驗證處方中，給出了詳細的描述。對該描述進行分析之后，可以用下面的表來說明“處方”在整個驗證流程中所經(jīng)歷的狀態(tài)。處方狀態(tài)產(chǎn)生該狀態(tài)的原因驗證結果醫(yī)生信息無效醫(yī)生信息不正確不通過審核中醫(yī)生信息正確無效處方醫(yī)生回復處方無效不通過無法審核醫(yī)生沒有在7天內(nèi)給出答復不通過準許付款醫(yī)生在7天內(nèi)給出確認答復通過 下一步工作就是把上表中的信息與題中的狀態(tài)圖對應起來。 由說明可知，處方提交后的第一步操作就是核實醫(yī)生信息，而這個操作會產(chǎn)生兩種結果：醫(yī)生信息正

40、確，或者不正確。醫(yī)生信息不正確會使處方的狀態(tài)變更為“醫(yī)生信息無效”，并導致購買行為被取消，即表中的第一行。對于這種情況，“處方”的狀態(tài)變更軌跡為：處方已提交醫(yī)生信息無效結束。而在狀態(tài)圖中與這條軌跡匹配的狀態(tài)序列就是：處方已提交S3結束。由此可以確定，S3對應的就是狀態(tài)“醫(yī)生信息無效”，而(7)對應的遷移就是“醫(yī)生信息不正確”。 相應地，就可以判斷出(8)應該代表的是核實醫(yī)生信息的另一種結果，因此(8)對應的遷移應該是“醫(yī)生信息正確”。由上表可知，醫(yī)生信息正確時，處方狀態(tài)會變更為“審核中”，這樣S1對應的狀態(tài)就是“審核中”。 但處方在狀態(tài)“審核中”時，實際上會有三個后續(xù)狀態(tài)：一個是圖中已經(jīng)給出的

41、“準許付款”，另外兩個是“無效處方”和“無法審核”。而產(chǎn)生這兩個狀態(tài)的原因分別是“醫(yī)生回復處方無效”和“醫(yī)生沒有在7天內(nèi)給出答復”。由此得出，(9)對應“醫(yī)生回復處方無效”，S4對應狀態(tài)“無效處方”；(10)對應“醫(yī)生沒有在7天內(nèi)給出答復”，S2對應“無法審核”。 如果S2為狀態(tài)“無效處方”，那么(10)就對應著“醫(yī)生回復處方無效”；S4對應狀態(tài)“無法審核”，那么(9)就對應著“醫(yī)生沒有在7天內(nèi)給出答復”。19、表示組合(composition)，表示聚合(aggregation)。 在組合關系中，整體對象與部分對象具有同一的生存周期。當整體對象不存在時，部分對象也不存在。 而在聚合關系中，對

42、整體對象與部分對象沒有這樣的要求。本題考查UML的應用，是比較傳統(tǒng)的題目，要求考生細心分析題目中所描述的內(nèi)容。 在UML中，和分別表示組合(composition)和聚合(aggregation)。兩者的主要區(qū)別是，在組合關系中，整體對象與部分對象具有同一的生存周期。當整體對象不存在時，部分對象也不存在。而在聚合關系中，對整體對象與部分對象沒有這樣的要求。試題四20、A-int_array0 21、A-int_array0=A-int_arrayA-array_size-1 22、A-array_size-1 23、A-int_arrayPARENT(i)key 24、A-int_arrayi

43、=key本題考查算法設計與分析以及C程序設計語言的相關知識。 根據(jù)題干說明，函數(shù)heapMaximum返回大頂堆A的最大元素，即堆頂元素，因此空(1)處應填A-int_array0。 函數(shù)heapExtractMax(A)取出大頂堆A的最大元素，將最后一個元素“提前”到堆頂位置，并將剩余元素調整成大頂堆。因此在將堆頂元素賦給max后，應該將堆的最后一個元素移到堆頂位置，即空(2)處應填A-int_array0=A-int_arrayA-array_size-1。 函數(shù)maxHeapInsert(A,key)把元素key插入到大頂堆A的最后位置，再將A調整成大頂堆。該函數(shù)前面的代碼行考慮的是當存

44、儲空間不夠時擴展存儲空間。而后面是根據(jù)該函數(shù)的定義實現(xiàn)的問題求解的算法表示，A-array_size +；表示為堆的規(guī)模增加1，i表示堆的最后一個元素的下標，即新插入的元素的下標，應該為A-array_size-1。while循環(huán)是自下而上調整堆，當還沒有到堆頂位置，且新插入的元素大于其父親元素，即A-int_arrayPARENT(i) key時，i變?yōu)槠涓赣H元素的下標。直到i到達堆頂位置，說明新插入的元素為最大值，或者i的父親元素大于新插入的元素，說明新插入的元素在i處，因此空(5)處填A-int_arrayi=key。25、O(1) 26、O(lgn) 27、O(lgn)本題考查算法設計

45、與分析以及C程序設計語言的相關知識。 本問題考查算法的時間復雜度。 根據(jù)上述C代碼，函數(shù)heapMaximum返回數(shù)組A的第1個元素，因此為常數(shù)時間即O(1)。 函數(shù)heapExtractMax首先將數(shù)組A的第1個元素的值放到變量max中，然后將最后一個元素提到堆頂，最后再進行堆的調整，因此該時間復雜度實際上是調整堆的時間復雜度，即O(lgn)。 函數(shù)maxHeapInsert將一個元素key插入到堆A中，具體的過程為先將堆的規(guī)模增加1，然后將元素插入到堆的最后一個位置，最后自下而上調整該元素，其時間復雜度為堆(二叉樹)的高度，即O(lgn)。28、本題考查算法設計與分析以及C程序設計語言的相

46、關知識。 將元素10插入到堆A=(15,13,9,5,12,8,7,4,0,6,2,1)中，根據(jù)maxHeapInsert函數(shù)進行操作，則過程如下圖(a)(c)所示。 新插入的元素10在堆A中處于第3個位置，15和13分別處于第1和第2個位置。試題五29、this-name 30、virtual void Add(Company* c)=0 31、virtual void Delete(Company* c)=0 32、Company* 33、children 34、children 35、root-Add(comp) 36、comp-Add(comp1)Composite模式將對象組合成樹形

47、結構以表示“整體-部分”的層次結構，其中的組合對象使得用戶可以組合基元對象以及其他的組合對象，從而形成任意復雜的結構。 Composite模式使得用戶對單個對象和組合對象的使用具有一致性。 Composite模式的結構如下圖所示。 其中： 類Component為組合中的對象聲明接口，在適當?shù)那闆r下，實現(xiàn)所有類共有接口的缺省行為，聲明一個接口用于訪問和管理Component的子部件; 類Leaf在組合中表示葉節(jié)點對象，葉節(jié)點沒有子節(jié)點；并在組合中定義圖元對象的行為； 類Composite定義有子部件的那些部件的行為，存儲子部件，并在Component接口中實現(xiàn)與子部件有關的操作； 類Client

48、通過Component接口操縱組合部件的對象。 下列情況可以使用Composite模式： (1)表示對象的整體-部分層次結構； (2)希望用戶忽略組合對象與單個對象的不同，用戶將統(tǒng)一地使用組合結構中的所有對象。 圖5-2中的Company對應的就是上圖中的類Component, ConcreteCompany對應的是類Composite；而上圖中的FinanceDepartment和HRDepartment扮演的就是類Leaf的角色。 由于類Company的作用是為其子類提供統(tǒng)一的操作接口，所以將其定義為抽象類。在C+中，抽象類的定義是：至少包含一個純虛擬函數(shù)的類。而純虛擬函數(shù)是沒有函數(shù)體的虛

49、擬函數(shù)，其作用是為子類提供統(tǒng)一接口。若要使用純虛擬函數(shù)，必須在子類中對其進行重置。定義純虛擬函數(shù)的語法為： virtual返回值函數(shù)名(參數(shù)列表)=0; 空(1)(3)考查的是如何定義抽象類Company。Company提供了兩個方法接口Add和Delete，即該類中應包含兩個純虛擬函數(shù)。如何確定Add和Delete的函數(shù)原型呢?這要借助于Company的子類。因為子類重置父類定義的虛擬函數(shù)時，不能改變其接口定義。所以從ConcreteCompany中的Add和Delete方法就能夠確定出空(2)和(3)處應分別填入“virtual void Add(Company* c)=0”和“virtual void Delete(Company* c)=0”?？?1)考察的是在構造函數(shù)中如何給數(shù)據(jù)成員賦初值。當構造函數(shù)的參數(shù)與類的數(shù)據(jù)成員同名時，可以借助this指針來進行區(qū)別，因此空(1)處應填入this-name。 空(4)(6)考查對模式中Composite節(jié)點的定義。由圖5-2可知，ConcreteCompany與Company之間是聚集關系，即ConcreteCompany的實例中包含多個Company的子類的實例。為了表示這種聚集關系，使用了C+標準類庫中的類模板list。C+的類模板必須在實例化之后才能使用。實例化類模板時，要給出類型實參。由于children表示的