第一篇：石河子大學(xué) 信息學(xué)院 面向?qū)ο蟮脑O(shè)計與分析 OOAD考試總結(jié)

OOAD總復(fù)習(xí)

第一章

1、什么是分析與設(shè)計？

1、分析強調(diào)對問題和需求的調(diào)查研究

2、設(shè)計強調(diào)的是滿足需求的概念上的解決方案

2、什么是面向?qū)ο蠓治雠c設(shè)計？

1、在面向?qū)ο蠓治鲞^程中，強調(diào)的是在問題領(lǐng)域內(nèi)發(fā)現(xiàn)和描述對象（或概念）

2、在面對對象設(shè)計過程中，強調(diào)的是定義軟件對象以及它們?nèi)绾螀f(xié)作以實現(xiàn)需求。

3、簡單示例：

1、定義用例（use case）

需求分析可能包括人們?nèi)绾问褂脩?yīng)用的情節(jié)或場景，這些情節(jié)或場景可以被編寫成用例。

2、定義領(lǐng)域模型（domain model）

面向?qū)ο蠓治龅慕Y(jié)果可以表示為領(lǐng)域模型，在領(lǐng)域模型中展示重要的領(lǐng)域概念或?qū)ο?。需要注意的是，領(lǐng)域模型并不是對軟件對象的描述，它使真實世界領(lǐng)域中的概念和想象可視化。（也被稱為概念領(lǐng)域模型—conceptual object model）

3、定義交互圖

關(guān)注的是軟件對象的定義—它們的職責(zé)和協(xié)作。順序圖（sequence diagram）是描述協(xié)作的常見方法。它展示對象之間的信息流，和由消息引起的方法調(diào)用。

4、定義設(shè)計類圖

除了在交互圖中顯示對象協(xié)作的動態(tài)視圖外，還可以用設(shè)計類圖（design class diagram）來有效的表示類定義的靜態(tài)視圖。這樣可以描述類的屬性和方法。

與領(lǐng)域模型表示的是真實世界的類，設(shè)計類圖表示的是軟件類

要注意的是，盡管設(shè)計類圖不同于領(lǐng)域模型，但是其中的某些類名和內(nèi)容還是相似的。

第二章

1、什么是UML？

統(tǒng)一建模語言（UML）是描述、構(gòu)造和文檔化系統(tǒng)制品的可視化語言。

UML表示法的基礎(chǔ)是UML元模型，它描述建模元素的語義，UML元模型對模型驅(qū)動架構(gòu)（Model Driven Architecture, MDA）CASE工具供應(yīng)商具有影響。開發(fā)者并不需要對其進行學(xué)習(xí)。

2、三種UML應(yīng)用方式

1、UML作為草圖—非正式的、不完整的圖，借助可視化語言的功能，用于探討問題或解決方案空間的負責(zé)部分。

2、UML作為藍圖—相對詳細的設(shè)計圖。用于：①逆向工程；②代碼生成。

3、UML作為編程語言—用UML完成軟件系統(tǒng)可執(zhí)行規(guī)格說明。

3、什么是UP？

軟件開發(fā)過程（software development process）描述了構(gòu)造、部署以及維護軟件的方式。統(tǒng)一過程（UP）已經(jīng)成為一種流行的構(gòu)造面向?qū)ο笙到y(tǒng)的迭代軟件開發(fā)過程。

4、迭代（iterative）、進化（evolutionary）和敏捷（agile）

1、迭代開發(fā)是UP和大多數(shù)其他現(xiàn)代方法中的關(guān)鍵實踐。每次迭代都具有各自的需求分析、設(shè)計、實現(xiàn)和測試活動。

2、迭代進化開發(fā)

小步驟、快速反饋和調(diào)整是迭代開發(fā)的重要思想。短時迭代為上。迭代的一個關(guān)鍵時光可見

第 1 頁

2013-3-31 OOAD總復(fù)習(xí)

思想是時間定量，或者時長固定。

3、瀑布生命周期

在瀑布（或順序）生命周期過程中，試圖在編程之前（詳細）定義所有或大部分需求。而且通常于編程之前創(chuàng)建出完整的設(shè)計（或模型集）。

4、什么是敏捷模型？

1、采用敏捷方法并不意味著不進行任何建模，這是錯誤理解。

2、建模和模型的目的主要用于理解和溝通，而不是構(gòu)建文檔

3、不要對所有或大多數(shù)軟件建?；蛘邞?yīng)用UML。

4、盡可能使用最簡單的工具。

5、UP所倡導(dǎo)的核心思想是：短時間定量迭代、進化和可適應(yīng)性開發(fā)。

6、UP的四個階段：初始（inc）、細化（elaboration）、構(gòu)造（construction）、移交（transition）

第五章

1、進化式需求

1、需求就是系統(tǒng)（廣義的說法是項目）必須提供的能力和必須遵從的條件。

2、需求分析的最大挑戰(zhàn)是尋找、溝通和記住（通常是指記錄）什么事真正需要的，并能夠清楚的講解給客戶和開發(fā)團隊的成員。

3、需求變更是不可避免的，因此有效的管理和關(guān)鍵

4、進化式需求VS瀑布式需求：??

5、需求按照“FURPS+”模型進行分類：

1、功能性：特性、功能、安全

2、可用性：人性化因素、幫助、文檔

3、可靠性：故障頻率、可恢復(fù)性、可預(yù)測性

4、性能：響應(yīng)時間、吞吐量、準確性、有效性、資源利用率

5、可支持性：適應(yīng)性、可維護性、國際化、可配置性

6、一些次要因素：實現(xiàn)、接口、操作、包裝、授權(quán)

6、UP制品如何組織需求：

1、用例模型：一組使用系統(tǒng)的典型場景。

2、補充性規(guī)格說明：基本上是用例之外的所有內(nèi)容。

3、詞匯表：詞匯表以最簡單的形式定義重要的術(shù)語。

4、設(shè)想：概括了高階需求，項目的業(yè)務(wù)案例。

5、業(yè)務(wù)規(guī)劃（領(lǐng)域規(guī)劃）：通常描述了凌駕于某一軟件項目的需求或政策，這些規(guī)則是領(lǐng)域或者業(yè)務(wù)所要求的，并且許多應(yīng)用應(yīng)該遵從這些規(guī)則。

第六章

1、用例是文本文檔，而非圖形；用例建模主要是編寫文本的活動，而非制圖。

2、用例常用的三種形式：

1、摘要（brief）：簡潔的一段式概要，主要用于主成功場景。

2、非正式（casual）：非正式的段落格式。

3、詳述（fully-dressed）：詳細編寫所有步驟及各種變化，同時具有補充部分，如前置條件和保證成功。

3、參與者（actor）、場景（scenario）、用例（use-case）

1、參與者是某些具有行為的事物，可以是人、計算機系統(tǒng)或者組織。

2、場景是參與者與系統(tǒng)之間的一系列特定的活動和交互，也稱為用例實例

時光可見

第 2 頁

2013-3-31 OOAD總復(fù)習(xí)

3、用例是一組相關(guān)的成功和失敗場景的集合，用來描述參與者如何使用系統(tǒng)來實現(xiàn)其目標。

4、準則：如何發(fā)現(xiàn)用例？

1、選擇系統(tǒng)邊界

2、辨別主要參與者

3、辨別每個參與者的目標

4、定義用例以滿足目標

5、準則：什么樣的測試有助于發(fā)現(xiàn)有用的用例？

1、老板測試（the boss test）：老板的一問一答

2、EBP測試(the ERP test)基本業(yè)務(wù)過程

3、規(guī)模測試(the size test)

6、示范：應(yīng)用上述測試

1、就供應(yīng)者合同進行協(xié)商：

比ERP更廣泛，用時更長。更適合作為業(yè)務(wù)用例，而非系統(tǒng)用例。

2、處理退貨

能夠通過老板測試。看上去與ERP類似。規(guī)模適合3、登陸

如果你一整天都在登陸，老板不會滿意

4、在游戲板上移動棋子

單一步驟，不能通過規(guī)模測試

第八章

1、迭代1的需求和重點：OOA/D技術(shù)的核心

2、過程：初始（inception）和細化（elaboration）

初始階段是邁向細化階段的一小步。在該階段決定基本的可行性、風(fēng)險和范圍，對項目是否值得進行更深入的調(diào)查進行決策。

細化是一般項目中最初的一些列迭代，其中包括：

1、對核心、有風(fēng)險的軟件架構(gòu)進行編程和測試

2、發(fā)現(xiàn)并穩(wěn)定需求的主要成分

3、規(guī)避主要風(fēng)險

第九章

1、領(lǐng)域模型是對領(lǐng)域內(nèi)的概念類或現(xiàn)實世界中對象的可視化表示。領(lǐng)域模型也稱為概念膜性能高、領(lǐng)域?qū)ο竽Ｐ秃头治鰧ο竽Ｐ汀?/p>

2、應(yīng)用UML表示法，領(lǐng)域模型被描述為一組沒有定義操作（方法的特征標記）的類圖（class diagram）：

1、領(lǐng)域?qū)ο蠡蛘吒拍铑?/p>

2、概念類之間的關(guān)聯(lián)

3、概念類的屬性

3、準則：如何創(chuàng)建領(lǐng)域模型？

1、尋找概念類

2、將其繪制成UML類圖中的類

3、添加關(guān)聯(lián)和屬性

4、準則：如何找到概念類？

時光可見

第 3 頁

2013-3-31 OOAD總復(fù)習(xí)

1、重用和修改現(xiàn)有的模型

2、使用分類列表

3、確定名詞短語

5、準則：何時需要描述類？

1、需要有關(guān)商品或者服務(wù)的描述，獨立于任何商品或服務(wù)的現(xiàn)有實例

2、刪除其所描述事物的實例后，導(dǎo)致信息丟失，而這些信息也是需要維護的，但是被錯誤地與所刪除的事物關(guān)聯(lián)起來

3、減少冗余或重復(fù)信息

6、關(guān)聯(lián)（association）是類（更精確的說，是這些類之間的實例）之間的關(guān)系，表示有意義和值得關(guān)注的連接

7、準則：在UML中如何對關(guān)聯(lián)命名？

以“類名—動詞短語—類名”的格式為關(guān)聯(lián)命名，其中的動詞短語構(gòu)成了可讀和有意義的順序。

8、準則：任何屬性都不表示外鍵

第十章

1、系統(tǒng)順序圖（SSD）是為闡述與討論系統(tǒng)相關(guān)的輸入和輸出事件而快速、簡單地創(chuàng)建制品。它們是操作契約和（最重要的）對象設(shè)計的輸入

2、SSD中的操作可以在操作契約中進行分析，在詞匯表中被詳細描述，并且作為設(shè)計協(xié)作對象的起點。

3、對于用例中一系列特定事件，SSD展示了直接與系統(tǒng)交互的外部參與者、系統(tǒng)（作為黑盒）以及由參與者發(fā)起的系統(tǒng)事件。

4、什么是系統(tǒng)順序圖？

系統(tǒng)順序圖表示的是，對于用例的一個特定場景，外部參與者產(chǎn)生的事件，其順序和系統(tǒng)之間的事件，所有系統(tǒng)被視為黑盒，該圖強調(diào)的是從參與者到系統(tǒng)的跨越系統(tǒng)邊界的事件。

第十一章

1、操作契約可以視為UP用例模型的一部分，因為它對用例指出的系統(tǒng)操作的效用提供了更詳細的分析。

2、定義：契約有哪些部分？

1、操作：操作的名稱和參數(shù)

2、交叉引用：會發(fā)生此操作的用例

3、前置條件：執(zhí)行操作之前，對系統(tǒng)或領(lǐng)域模型對象狀態(tài)的重要假設(shè)。

4、后置條件：最重要的部分。完成操作后，領(lǐng)域模型對象的狀態(tài)。

3、什么是系統(tǒng)操作？

系統(tǒng)操作是作為黑盒構(gòu)件的系統(tǒng)在其公共接口中提供的操作。系統(tǒng)操作可以在繪制SSD草圖時確定。

4、后置條件描述了領(lǐng)域模型內(nèi)對象狀態(tài)變化。領(lǐng)域模型狀態(tài)變化包括創(chuàng)建實例、形成或消除關(guān)聯(lián)以及改變屬性。

5、準則：契約在何時有效？

在UP中，用例是項目需求的主要知識庫。用例可以為設(shè)計提供大部分或全部所需細節(jié)。這中情況下，契約就沒什么用處。

6、準則：如何創(chuàng)建和編寫契約？

1、從SSD圖中確定系統(tǒng)操作

時光可見

第 4 頁

2013-3-31 OOAD總復(fù)習(xí)

2、如果系統(tǒng)操作復(fù)雜，其結(jié)果可能不明顯，或者在用例中不清楚，則可以為其構(gòu)造契約

3、使用以下幾種類表來描述后置條件：

1、創(chuàng)建或刪除實例

2、屬性值的變化

3、形成或消除關(guān)聯(lián)（UML連接）

第十三章

1、什么是邏輯架構(gòu)和層？

邏輯架構(gòu)是軟件類的宏觀組織結(jié)構(gòu)，它將軟件類組織為包（或命名空間）、子系統(tǒng)和層等。之所以稱之為邏輯架構(gòu)，是因為并未決定如何在不同的操作系統(tǒng)進程或網(wǎng)絡(luò)中物理計算機上對這些元素進行部署。

層是對類、包或子系統(tǒng)的甚為粗粒度的分組，具有對系統(tǒng)主要方面加以內(nèi)聚的職責(zé)。

OO系統(tǒng)中通常包括的層有：

1、用戶界面

2、應(yīng)用邏輯和領(lǐng)域?qū)ο?/p>

3、技術(shù)服務(wù)

2、什么是軟件架構(gòu)？

架構(gòu)是一組重要的決策，其中涉及軟件系統(tǒng)的組織，對結(jié)構(gòu)元素及其組成系統(tǒng)所籍接口的選擇，這些元素特定于其相互協(xié)作的行為，這些結(jié)構(gòu)和行為元素到規(guī)模更大的子系統(tǒng)的組成，以及指導(dǎo)該組織結(jié)構(gòu)的架構(gòu)風(fēng)格。

第十五章

1、交互圖這一術(shù)語是對以下兩種更為特化的UML圖的統(tǒng)稱

1、順序圖：以一種柵欄格式描述交互，其中在右側(cè)添加新創(chuàng)建的對象。

2、通信圖：以圖或者網(wǎng)絡(luò)格式描述對象交互，其中對象可以置于圖中的任何位置。

2、順序圖的基本表示法：

1、消息：實心箭頭

2、應(yīng)答或返回：在活動條末端使用應(yīng)答（或返回）消息線

3、異步調(diào)用：虛線

3、通信圖的基本表示法：

1、鏈是連接兩個對象的路徑，它指明了對象間某種可能的導(dǎo)航和可見性。鏈是關(guān)聯(lián)的實例。

2、消息：對象間的每個消息都可以使用消息表達式和指明消息方向的小箭頭表示。

3、消息的順序編號：

1、不為第一個消息編號

2、使用合法編號方案來表示后續(xù)消息的順序和嵌套，其中的嵌套消息要使用附加的數(shù)字

4、可以在順序編號后使用帶有方括號[]的條件句子來表示有條件消息。為真時發(fā)送消息

5、互斥的有條件路徑：在順序編號后面加上字母，第一個字母是a

6、迭代或循環(huán)：在順序編號后面加*

第十六章

時光可見

第 5 頁

2013-3-31 OOAD總復(fù)習(xí)

1、表示UML屬性的方法：屬性文本和關(guān)聯(lián)線

2、在DCD中使用關(guān)聯(lián)表示屬性時的風(fēng)格：導(dǎo)航性箭頭、角色名、3、對于領(lǐng)域模型使用類圖的時候，需要表示關(guān)聯(lián)名稱，但是要避免使用導(dǎo)航箭頭，因為領(lǐng)域模型不是軟件透視圖。

3、對數(shù)據(jù)類型對象使用屬性文本表示法，對其他對象使用關(guān)聯(lián)線。

4、依賴用從客戶到提供者的虛線箭頭表示（A?B，B發(fā)生變化會影響A）

5、比較常見的依賴類型：

1、擁有提供者類型的屬性

2、向提供者發(fā)送消息

3、接收提供者類型的參數(shù)

4、提供者是超類或者接口

6、依賴標簽

7、插座法表示接口

8、限定關(guān)聯(lián)

第十七章

1、GRASP：基本OO設(shè)計的系統(tǒng)方法

2、GRASP：使用職責(zé)進行OO設(shè)計的學(xué)習(xí)工具

3、RDD（responsibility-driven design）：職責(zé)驅(qū)動設(shè)計。

4、UML把職責(zé)定義為“類元的契約或義務(wù)”。就對象的角色而言，職責(zé)與對象的義務(wù)和行為相關(guān)。職責(zé)分為以下兩種類型：行為和認知。

1、行為職責(zé)：

1、自身執(zhí)行一些行為，如創(chuàng)建對象或計算。

2、初始化其他對象中的動作

3、控制和協(xié)調(diào)其他對象中的活動

2、認知職責(zé)：

1、對私有封裝數(shù)據(jù)的認知

2、對相關(guān)對象的認知

3、對其能夠?qū)С龌蛴嬎愕氖挛锏恼J知

5、對于軟件領(lǐng)域?qū)ο髞碚f，由于領(lǐng)域模型描述了領(lǐng)域?qū)ο蟮膶傩院完P(guān)聯(lián)，因此其通常產(chǎn)生與“認知”相關(guān)的職責(zé)。

6、職責(zé)的粒度會影響職責(zé)到類和方法的轉(zhuǎn)換。

7、什么是模式？

如果以結(jié)構(gòu)化形式對這些問題、解決方案和命名進行描述使其系統(tǒng)化，那么這些原則和習(xí)慣用法就可以稱為模式。

在OO設(shè)計中，模式是對問題和解決方案的已命名描述，它可以用于新的語境。

8、使用GRASP進行對象設(shè)計的簡短示例

1、創(chuàng)建者

2、信息專家

3、低耦合4、控制器

5、高內(nèi)聚

9、創(chuàng)建者：誰創(chuàng)建了A？

解決方案：（有一個為真即可）

時光可見

第 6 頁

2013-3-31 OOAD總復(fù)習(xí)

1、B“包含”或組成聚集了A

2、B記錄A

3、B緊密地使用A

4、B具有A的初始化數(shù)據(jù)

10、信息專家：如果給定鍵值，誰知道Square對象的信息？

解決方案：把職責(zé)分配給具有完成該職責(zé)所需信息的那個類

11、低耦合：為什么是Board而不是Dog？如何減少變化產(chǎn)生的影響？

解決方案：分配職責(zé)以使耦合保持在較低的水平。用該原則對可選方案進行評估

12、控制器：在UI層之上首先接受和協(xié)調(diào)系統(tǒng)操作的對象是什么？

解決方案：把職責(zé)分配給能代表下列選擇之一的對象：

1、代表全部“系統(tǒng)”、“根對象”、運行軟件的設(shè)備或主要的子系統(tǒng)

2、代表發(fā)生系統(tǒng)操作的用例場景（用例或會話）

13、高內(nèi)聚：怎樣使對象保持有內(nèi)聚、可理解和可管理，同時具有支持低耦合的附加作用？

解決方案：職責(zé)分配應(yīng)保持高內(nèi)聚，依此來評估備選方案

第十八章

1、用例實現(xiàn)描述某個用例基于協(xié)作對象如何在設(shè)計模型中實現(xiàn)。更精確的說，設(shè)計者能夠描述用例的一個或多個場景的設(shè)計，其中的每一個設(shè)計都稱為用例實現(xiàn)。

2、下面說明了一些制品之間的關(guān)系：

1、用例指出了SSD中所示的系統(tǒng)操作

2、系統(tǒng)操作可以稱為輸入到領(lǐng)域?qū)咏换D的控制器中的起始消息

3、領(lǐng)域?qū)咏换D闡述了對象如何交互完成所需任務(wù)—用例實現(xiàn)

第十九章

1、可見性是一個對象看見其他對象或引用其他對象的能力

2、實現(xiàn)對象A到對象B的可見性通常有四種方式：

1、屬性可見性—B是A的屬性

2、參數(shù)可見性—B是A中方法的參數(shù)

3、局部可見性—B是A中方法的局部對象（不是參數(shù)）

4、全局可見性—B具有某種方法的全局可見性

第二十章

1、用OO語言（java或者C#）創(chuàng)建代碼并不是OOA/D的一部分，它是最重的目標

2、在UP中具有實現(xiàn)模型。源代碼、數(shù)據(jù)庫定義、JSP/XML/HTML頁面等都是實現(xiàn)制品

3、面向?qū)ο笳Z言中的實現(xiàn)需要以下元素編寫源代碼：

1、類和接口的定義

2、方法的定義

第二十三章

1、在迭代1結(jié)束的時候，應(yīng)該已經(jīng)完成以下任務(wù)：

1、所有軟件都已經(jīng)被充分地測試

2、客戶定期地參與對已完成部分的評估

3、已經(jīng)對系統(tǒng)進行了完成的集成和固化，使其成為基線化的內(nèi)部版本

2、迭代2的需求和重點：對象設(shè)計和模式

時光可見

第 7 頁

2013-3-31 OOAD總復(fù)習(xí)

1、支持第三方外部服務(wù)的變化

2、復(fù)雜的定價規(guī)則

3、需要進行設(shè)計，使得在銷售總額變化時刷新GUI窗口

第二十五章

1、之前介紹了5個GRASP模式：信息專家、創(chuàng)建者、高內(nèi)聚、低耦合、控制器

2、下面介紹最后4個GRASP模式：多態(tài)、間接性、純虛構(gòu)、防止變異

3、多態(tài)：如何處理基于類型的選擇？如何創(chuàng)建可插拔的軟件構(gòu)件？

解決方案：當相關(guān)選擇或行為隨類型（類）有所不同時，使用多態(tài)操作作為變化的行為類型分配職責(zé)。推論：不要測試對象的類型，也不要使用條件邏輯來執(zhí)行基于類型的不同選擇

4、純虛構(gòu)：當你并不想違背高內(nèi)聚和低耦合或者其他目標，但是基于專家模式所提供的方案又不合適時，哪些對象應(yīng)該承擔這一職責(zé)？

解決方案：對人為制造的類分配一組高內(nèi)聚的職責(zé)，該類并不代表問題領(lǐng)域的概念—虛構(gòu)的事物，用以支持高內(nèi)聚、低耦合和復(fù)用。這種類是憑空虛構(gòu)的。

5、間接性：為了避免兩個或多個事物之間直接耦合，應(yīng)該如何分配職責(zé)？如何使用對象解耦合，以支持低耦合并提高復(fù)用性潛力？

解決方案：將職責(zé)分配給中介對象，使其作為其他構(gòu)件或服務(wù)之間的媒介，以避免它們之間的直接耦合。中介實現(xiàn)了其他構(gòu)件之間的間接性

6、防止變異：如何設(shè)計對象、子系統(tǒng)和系統(tǒng)，使其內(nèi)部的變化或不穩(wěn)定不會對其他元素產(chǎn)生不良影響？

解決方案：識別預(yù)計變化或不穩(wěn)定之處，分配職責(zé)用以在這些變化之外創(chuàng)建穩(wěn)定接口

第二十六章

1、適配器（GoF）：如何解決不相容的借口問題，或者如何為具有不同接口的類似構(gòu)件提供穩(wěn)定的借口？

解決方案：通過中介適配器對象，將構(gòu)件的原有接口轉(zhuǎn)換為其他接口。增加一層間接性對象，通過這些對象將不同的外部接口調(diào)整為在應(yīng)用程序內(nèi)使用的一致接口

2、工廠：當有特殊考慮（例如存在復(fù)雜創(chuàng)建邏輯，為了改良內(nèi)聚而分離創(chuàng)建職責(zé)等）時，應(yīng)該由誰來負責(zé)創(chuàng)建對象？

解決方案：創(chuàng)建稱為工廠的純虛構(gòu)對象來處理這些創(chuàng)建職責(zé)

3、單實例類：只有唯一實例的類即為“單實例類”。對象需要全局可見性和單點訪問

解決方案：對類定義靜態(tài)方法用以返回單實例

4、策略：如何設(shè)計變化但相關(guān)的算法或政策？如何設(shè)計才能使這些算法或政策具有可變更能力？

解決方案：在單獨的類中分別定義每種算法/政策/策略，并且使其具有共同接口

5、組合：如何能夠像處理非組織（原子）對象一樣，（多態(tài)地）處理一組對象或具有組合解耦股的對象呢？

解決方案：定義組合和原子對象的類，使它們實現(xiàn)相同的接口

6、外觀：對一組完全不同的實現(xiàn)或接口需要公共、統(tǒng)一的接口?？赡軙c子系統(tǒng)內(nèi)部的大量事物產(chǎn)生耦合，或者子系統(tǒng)的實現(xiàn)可能會改變，怎么辦？

解決方案：對子系統(tǒng)定義惟一的接觸點—使用外觀對象封裝子系統(tǒng)。該外觀對象提供了惟一和統(tǒng)一的接口，并負責(zé)與子系統(tǒng)構(gòu)件進行協(xié)作

7、觀察者（發(fā)布—訂閱）：不同類型的訂閱者對象關(guān)注于發(fā)布者對象的狀態(tài)變化或事件，并時光可見

第 8 頁

2013-3-31 OOAD總復(fù)習(xí)

且想要在發(fā)布者產(chǎn)生事件時以自己獨特的方式作出反應(yīng)。此外，發(fā)布者想要保持與訂閱者的低耦合。如何對此進行設(shè)計呢？

解決方案：定義“訂閱者”和“監(jiān)聽器”接口。訂閱者實現(xiàn)此接口。發(fā)布者可以動態(tài)注冊關(guān)注某事件的訂閱者，并在事件發(fā)生時通知它們

第三十章

1、包含關(guān)系：多個用例中存在部分相同的行為，這是常見的現(xiàn)象

2、如下情形可以分解出子功能用例并使用包含關(guān)系：

1、用例在其他用例中重復(fù)使用

2、用例非常復(fù)雜并冗長，將其分解為子單元便于理解

3、具體用例是由參與者發(fā)起，完成了參與者所期望的完整行為。它們通常是基本業(yè)務(wù)過程用例

4、抽象用例永遠不能被自己實例化，它是其他用例的子功能用例

5、包含其他用例的用例，或者是被其他用例擴展或者泛化的用例被稱為基礎(chǔ)用例

6、被其他用例包含的用例，或者擴展、泛化其他用例的用例被稱為附加用例

7、擴展關(guān)系的思路是，創(chuàng)建擴展或附加用例，并且在其中描述：在何處何何種條件下該用例擴展某基礎(chǔ)用例的行為

8、事實上，直接更新基礎(chǔ)用例的擴展部分是推薦的方法，這樣避免了創(chuàng)建復(fù)雜的用例關(guān)系

9、擴展關(guān)系的UML表示法：

1、擴展用例指向基礎(chǔ)用例

2、在線上可以表示條件和擴展點

第三十一章

1、泛化是在多個概念中識別共性和定義超類（普通概念）與子類（具體概念）關(guān)系的活動

2、概念超類與子類之間是什么關(guān)系？

3、概念超類的定義較子類的定義更為概括或包含范圍更廣

4、泛化和類集的關(guān)系：概念子類集合的所有成員都是其超類集合的成員 5、100%規(guī)則：概念超類的定義必須100%適用于子類，子類必須100%與超類一致：屬性、關(guān)聯(lián)

6、Is-a規(guī)則：子類集合的所有成員必須是其超類集合的成員

7、什么是正確的概念子類？

潛在的子類應(yīng)該遵守下述規(guī)則：

1、100%規(guī)則（定義的一致性）

2、Is-a規(guī)則（集合成員關(guān)系的一致性）

8、在下述幾種情形下創(chuàng)建概念類的子類

1、子類有額外的有意義的屬性

2、子類有額外的有意義的關(guān)聯(lián)

3、子類概念的操作、處理、反應(yīng)或使用的方式不同于其超類或其他子類，而這些方式是我們所關(guān)注的4、子類概念表示了一個活動體（例如動物、機器人等），其行為與超類或者其他子類不同，而這些行為是我們所關(guān)注的

9、在下述情形下可以創(chuàng)建與子類具有泛化關(guān)系的超類

1、潛在的概念子類表示的是相似概念的不同變體

2、子類滿足100%和Is-a規(guī)則

時光可見

第 9 頁

2013-3-31 OOAD總復(fù)習(xí)

3、所有子類都具有相同的屬性，可以將其解析出來并在超類中表達

4、所有子類都具有相同的關(guān)聯(lián)，可以將其解析出來并與超類關(guān)聯(lián)

10、在領(lǐng)域模型中，如果類C可能同時有多個相同的屬性A，則不要將屬性A置于C至中，應(yīng)該將屬性A放在另一個類中，并且將其與C關(guān)聯(lián)

11、在領(lǐng)域模型中增加關(guān)聯(lián)類的可能線索有：

1、有某個屬性與關(guān)聯(lián)有關(guān)

2、關(guān)聯(lián)類的實例具有依賴于關(guān)聯(lián)的生命期

3、兩個概念之間有多對多關(guān)聯(lián)，并且存在于關(guān)聯(lián)自身相關(guān)的信息

12、在下述情況下，可以考慮組合關(guān)系：

1、部分的生命期在組成生命期界限之內(nèi)，部分的創(chuàng)建和刪除依賴于整體

2、在物理或邏輯組裝上，整體—部分關(guān)系很明確

3、組成的某些屬性會傳遞給部分

4、對組成的操作可能傳遞給部分

13、在關(guān)聯(lián)中可能會

時光可見 第 10 頁 2013-3-31

第二篇：面向?qū)ο蟮脑O(shè)計與分析(網(wǎng)上商城的建模設(shè)計)

第4章江西師范大學(xué)“網(wǎng)上商城”建模實例

本文所要進行建模分析的系統(tǒng)是學(xué)校小型電子商務(wù)系統(tǒng)，以欲構(gòu)建的江西師范大學(xué)的便利店和生活超市“網(wǎng)上商城”為例，是滿足校園客戶(主要在校學(xué)生)網(wǎng)購要求的綜合性的應(yīng)用系統(tǒng)，本文以Rational rose 2003為建模工具，并應(yīng)用第三章提出的基于UML的電子商務(wù)系統(tǒng)建模過程，完成該系統(tǒng)的詳細分析和設(shè)計。對系統(tǒng)進行需求分析，建立系統(tǒng)需求模型、靜態(tài)結(jié)構(gòu)視圖、動態(tài)結(jié)構(gòu)視圖、數(shù)據(jù)庫模型、物理模型。

4.1系統(tǒng)的需求分析 4.1.1系統(tǒng)的設(shè)計背景

江西師范大學(xué)瑤湖校區(qū)江西師范大學(xué)新校區(qū)，地處南昌市昌東鎮(zhèn)，在校學(xué)生3萬余人，由于學(xué)校占地面積很大，離市區(qū)比較遠，周圍設(shè)施還不是很齊全，該校區(qū)為解決師生日常生活需要，建設(shè)了商業(yè)街并且每個宿舍區(qū)都有便利超市，這些店是一個小型的生活用品采購區(qū)，在校學(xué)生平時的大部分消費都是在這些地方，包便利店和小型超市等生活服務(wù)的實體商店，滿足了師生不出校門就能買到自己想要的東西。近些年，隨著高校的擴招，該校區(qū)學(xué)生和老師的數(shù)量也不斷增加，新的問題也隨之而來，高校學(xué)生由于社會發(fā)展帶來的的巨大壓力，生活節(jié)奏也日益加快，空閑時間也越來越少。所以如果他們每次生活消費都要到實體店購買，就給他們的生活帶來不便，因而如果能夠網(wǎng)上購物就解決了這個矛盾。另外，據(jù)數(shù)據(jù)顯示，該校學(xué)生80%是網(wǎng)民，該群體的素質(zhì)較高，接受新事物速度快，而且他們的消費興趣和傾向也有高度的相似性。該校區(qū)學(xué)生居住地也比較集中，大都住在學(xué)校統(tǒng)一安排的公寓或者學(xué)校周圍的小區(qū)，使物流配送更加方便和及時。目前學(xué)校的實體商店很多，但是大多數(shù)商店還沒有自己的電子商務(wù)系統(tǒng)，所以如果通過一個統(tǒng)一的網(wǎng)上購物平臺，商店將這些商品都發(fā)布在網(wǎng)上商城上，師生就可以足不出戶選購商品，非常方便。只要授予他們可以在平臺上銷售自己的商品，提高了商店的知名度，也提高了他們的服務(wù)能力和影響力。該網(wǎng)上商城具有一般網(wǎng)上購物系統(tǒng)的功能: 1.師生可以通過該網(wǎng)上商城注冊為商城用戶，瀏覽商品訂購商品放入購物車;客戶可以通過該商城發(fā)布評論信息;客戶可以查看自己訂單;客戶可以支付商品貨款。

2.商戶可以通過該商城發(fā)布自己的商品信息、供師生購買;可以通過該商城管理自己的商品信息和員工信息;可以進行訂單處理。3.系統(tǒng)管理員對商戶申請信息進行審核;對評論信息管理:對系統(tǒng)日常的維護和數(shù)據(jù)備份;對用戶信息管理。

除了以上三個一般購物系統(tǒng)的功能商城的系統(tǒng)管理員可以通過對歷史訂單信息進行數(shù)據(jù)挖掘，找出顧客購買商品間的關(guān)聯(lián)關(guān)系，建議商戶對其營銷策略進行調(diào)整或者綁定銷售一些商品，以提高商戶的銷售利潤，達到在線交易和實體店雙重贏利。該功能模塊的設(shè)計將在第五章詳細說明。4.1.2系統(tǒng)的模塊設(shè)計

根據(jù)以上背景，本文欲構(gòu)建一個具有上述功能的江西師范大學(xué)“網(wǎng)上商城”。該商城可以滿足師生網(wǎng)上購物的要求，注冊該商城用戶都可以直接登錄到該商城。該商城為校園的客戶提供了一個統(tǒng)一的網(wǎng)上交易平臺，該網(wǎng)上商城的業(yè)務(wù)流程圖，如圖4.1所示。

通過以上背景分析和業(yè)務(wù)流程的設(shè)計，根據(jù)一般網(wǎng)上購物系統(tǒng)的功能，并結(jié)合該“網(wǎng)上商城”的特殊功能需求，根據(jù)商城所涉及到的主要參與者將該商城主要功能描述如下: 1，商城維護:管理員可以對商城日常維護和數(shù)據(jù)備份。2.商戶信息管理:管理員對申請加盟的商戶等級管理和商戶信息修改，添加等操作。

3.商城用戶信息管理:對商城注冊用戶信息的管理，以及其應(yīng)用權(quán)限

4.評論管理:管理員可以對評論信息進行處理，對于不符合要求的評論可以刪除。

5.收集數(shù)據(jù):系統(tǒng)管理員可以根據(jù)數(shù)據(jù)庫中一段時間的訂單歷史記錄查詢分析，收集到分析數(shù)據(jù)。

6.訂單分析:管理員可以對收集到的數(shù)據(jù)進行分析，得出商品之間的關(guān)聯(lián)性。建議商戶調(diào)整銷售策略，從而提高商店利潤。

7.商城注冊:非家園網(wǎng)或非商城用戶的客戶可以注冊為商城用戶。8.修改個人資料:注冊用戶可以修改自己的注冊資料。包括地址，電話等基本信息。

9.商城登錄:系統(tǒng)管理員、用戶、商戶都可以登錄商城相應(yīng)的模塊在相應(yīng)權(quán)限內(nèi)操作。

IO.查看商品信息:進入商城的師生都可以瀏覽商品信息，該商品信息包括商品的基本信息和商品的庫存。

11.購物:如果商品有庫存則客戶可以購買，如果缺貨則不能購買，客戶將商品放入購物車，進行購物。客戶可以對購物車里的商品隨時修改，刪除，添加和清空。

12.下訂單:客戶將商品加入購物車后，可以填寫訂單，對于訂單，在未處理之前，客戶也可以隨時登錄系統(tǒng)修改并提交。

13.支付:訂單提交以后，客戶可選擇支付方式，如選擇貨到付款則訂單完成，如選擇網(wǎng)上支付，則客戶要登錄網(wǎng)上銀行支付，支付完成則該訂單完成。

14.訂單查看:客戶可以隨時登錄系統(tǒng)查看自己的歷史訂單信息，可以刪除歷史訂單，可以查看訂單狀態(tài)，訂單在未處理之前都可以修改然后再提交，也可以對取消未處理的訂單。

15.評論:收到商品以后客戶對商品和商戶的服務(wù)是否滿意可以對此訂單進行評論。

16.申請加盟商城:商戶申請加盟商城，資格審核通過后可以在商城建立自己的網(wǎng)上商店，擁有該商店的管理權(quán)限，可以進行網(wǎng)上交易。17.商品信息維護:商戶可以隨時添加、修改、刪除商品的信息。18.配送員信息管理:商戶可以對商店里的配送員信息進行添加、修改、刪除，以更好的管理商店的配送工作。

19.訂單處理:客戶提交訂單以后，商戶接收訂單并與客戶確認訂單以后對訂單進行處理，根據(jù)訂單所購買的商品，商戶查詢庫存，確認庫存中有該商品，對訂單進行審批，審批完了后則打印配送訂單，安排送貨。

20.派遣配送員:商戶點擊相關(guān)功能，將輸出配送員編號，商戶把送貨單和商品交予該配送員負責(zé)，配送員把商品送到客戶指定的地點，如果無人收貨，則在訂單回執(zhí)中填寫“無人接貨”，如果收貨成功，則填寫“收貨成功”，如收貨人推遲收貨則填寫“推遲收貨”。并將訂單回執(zhí)交予商戶。

21.庫存管理:商戶可以對商品庫存進行定期清點，并修改商品信息中的庫存信息。

22.配送訂單管理:對已經(jīng)處理的訂單，商戶打印出配送訂單，并安排配送員配送，對配送訂單的完成情況進行管理。

23.查看商品銷售記錄:商戶可以對本商店的商品信息隨時查看。24.查詢分析結(jié)果:商戶可以登錄商城查詢商品的關(guān)聯(lián)分析結(jié)果，通過結(jié)果設(shè)置相應(yīng)的銷售捆綁包或交叉銷售。

25.設(shè)置銷售捆綁包:對分析到的關(guān)聯(lián)商品，通過后臺輸入設(shè)置到捆綁包中。

滿足上述需求的系統(tǒng)主要包括以下幾個模塊: 系統(tǒng)管理模塊:該模塊是系統(tǒng)提供給系統(tǒng)管理員的接口模塊。主要包括對校園商戶的加盟審核，對商店申請信息的管理，根據(jù)商戶等級和信譽來決定刪除和添加商戶，另外對網(wǎng)站用戶信息的管理。該模塊可以對系統(tǒng)日常維護和數(shù)據(jù)備份，并且通過對訂單信息進行數(shù)據(jù)分析，以幫助商戶制定營銷策略，贏得更大的利潤。

用戶接口模塊:該模塊為想購買該網(wǎng)站商品的學(xué)生提供的了入口，所有校園的師生都可以通過瀏覽器瀏覽該網(wǎng)站商品，可以注冊為該系統(tǒng)用戶并登錄該系統(tǒng)訂購自己喜愛的商品。

商戶操作模塊:該模塊是“網(wǎng)上商城”的核心模塊。主要包括接受客戶完成的訂單需求，指派特定的配送員，配送員根據(jù)訂單所需提貨，配送員送貨上門，客戶簽收商品并生成回執(zhí)單，商戶可以查看最近一段時間某商品的銷售記錄，根據(jù)查看的商品訂單分析結(jié)果制定相應(yīng)的捆綁銷售或者交叉銷售策略。

4.2需求建模

該系統(tǒng)需求建模描述系統(tǒng)用戶使用一個系統(tǒng)的方式，描述系統(tǒng)應(yīng)該具備什么功能，是系統(tǒng)用戶或者另一個系統(tǒng)與系統(tǒng)之間的一次交互過程，是系統(tǒng)分析和設(shè)一計的第一步，以系統(tǒng)全局的功能作為參考，把系統(tǒng)所涉及的參與者和他們從外部觀察到的系統(tǒng)的功能描述出來，而并不描述這些功能在系統(tǒng)功能的實現(xiàn)形式。這個過程使用UML建立系統(tǒng)的用例圖，分離出系統(tǒng)執(zhí)行者和用例，以及用例之間的關(guān)系。4.2.1系統(tǒng)參與者

參與者是系統(tǒng)外部的一個實體，可以是系統(tǒng)用戶、與所建造的系統(tǒng)交互的其他系統(tǒng)或者是一些可以運行的進程。第一，在每一個系統(tǒng)中，幾乎都存在著最常用的參與者一真實的人(用戶);第二，需要建立聯(lián)系的其他外部應(yīng)用程序，即其他系統(tǒng);第三，一些可運行的進程，如時一間;通過上面對該系統(tǒng)的功能分析和系統(tǒng)功能模塊的設(shè)計，系統(tǒng)參與者主要有:系統(tǒng)管理員、客戶、商戶和支付系統(tǒng)。4.2.2識別用例

確定用例最常用的方法是從分析系統(tǒng)參與者開始，把每個系統(tǒng)參與者如何使用系統(tǒng)的行為都考慮進來。根據(jù)上一節(jié)系統(tǒng)的需求分析功能模塊，可以確定系統(tǒng)參與者有系統(tǒng)管理員、客戶、商戶和支付系統(tǒng)。根據(jù)上一小節(jié)的功能模塊分析，得出系統(tǒng)的頂層用例圖，如圖4.2 0

下面分別對三個用例細化，系統(tǒng)管理所涉及到的用例有:商城登錄，商戶信息管理，用戶信自、管理，評論管理，商城日常維護和訂單分析。涉及到的參與者是系統(tǒng)管理員，系統(tǒng)管理的用例圖如4.3所示。

用戶接口用例細化有:商城注冊，商城登錄，查看商品信息，修改個人資料，購物，下訂單，支付，評論，訂單查看。用戶接口的用例圖如圖4.4所示。

其中“購物”用例細化的用例有:清空購物車，修改購物車商品，添加商品到購物車，查看購物車信息，刪除購物車中的商品。細化后的用例圖如圖4.5

“訂單查看”用例細化的用例有:修改訂單，提交訂單.，刪除訂單，查看歷史訂單，訂單狀態(tài)查詢，取消訂單。細化后用例圖如圖4.6所示。

商戶操作的細化用例有:申請加盟商城，商城登錄，商品信息維護，配送信息管理，訂單處理，配送訂單管理，派遣配送員，查看商品銷售記錄，庫存管理，查看訂單分析結(jié)果，設(shè)置商品銷售捆綁包。商戶操作用例細化圖，如圖4.7所示。

商品信息維護的細化的用例有:增加商品信息，刪除商品信息，修改商品信息。細化后的用例圖如圖4.8所示。

訂單處理的細化用例有:確認訂單，接收發(fā)貨，查詢商品庫存。如圖4.9

支付系統(tǒng)用例有:支付，網(wǎng)上支付，貨到支付。支付系統(tǒng)的用例圖，如圖4.10所示。

根據(jù)以上對系統(tǒng)參與者的用例圖分析與建模，得出系統(tǒng)的完整的用例圖，如圖4.11所示。

4.3靜態(tài)結(jié)構(gòu)建模

靜態(tài)結(jié)構(gòu)模型是對有關(guān)系統(tǒng)實現(xiàn)內(nèi)部和應(yīng)用領(lǐng)域的概念進行建模，本文通過分析上述需求建模中的用例和問題域，抽取相關(guān)的類，并將這些類之間的關(guān)系表示出來，以及類的內(nèi)部結(jié)構(gòu)，最后完成類圖，反應(yīng)了系統(tǒng)的一種靜態(tài)關(guān)系。(1)抽取系統(tǒng)中的類

系統(tǒng)中存在三種類，一種是系統(tǒng)與外界的交界處，包括各種窗體和接口(與報表、打印機和掃描儀等硬件的接口或者與其他系統(tǒng)的接口);另一種是負責(zé)協(xié)調(diào)其他類工作的控制類，是控制使用事件的順序的類;第三種是保存放入永久存儲體的數(shù)據(jù)信息類，即實體類。本文將以“下訂單”舉例說明分析類的整個流程。

下訂單用例的主要功能是:客戶登錄商品信息查看頁面，系統(tǒng)驗證客戶注冊信息，系統(tǒng)打開下訂單頁面，填寫訂單并提交訂單信息，根據(jù)以上描述，該用例涉及到的類如下: 邊界類:商品信息查看頁面，填寫訂單頁面。

控制類:下訂單。

實體類:客戶信息類，商品詳細信息類，訂單信息類。

據(jù)以上方法分析系統(tǒng)其它用例并經(jīng)過整理合并，得出網(wǎng)上商城的類如下: 1.邊界類:用戶注冊界面，用戶登錄界面，商品詳細信息界面，商品查看界面，下訂單界面，評論界面，支付界面，個人資料修改界面，訂單查看界面，商品信息維護界面，查看訂單分析結(jié)果界面，派遣配送員界面，設(shè)置商品銷售捆綁包界面，訂單處理界面，配送訂單管理界面，配送員信息管理界面，庫存管理界面，查看商品銷售記錄界面，商戶信息管理界面，用戶信息管理界面，商城維護界面，審核界面，評論管理界面，收集數(shù)據(jù)界面，訂單分析界面。

2.控制類:用戶注冊，用戶登錄，瀏覽商品，下訂單，評論，支付，個人資料修改，訂單查看，商品管理，配送員管理，查看訂單分析結(jié)果，派遣配送員，設(shè)置商品銷售捆綁包，訂單處理，配送訂單管理，庫存管理，查看商品銷售記錄，用戶管理，商戶管理，商城維護審核，評論管理，收集數(shù)據(jù)，訂單分析。

3.實體類:用戶信息類，商品信息，訂單信息，配送員信息類，購物車信息類，配送訂單信息類，商戶信息類，商品銷售記錄信息類，評論信息類。管理員和客戶都屬于系統(tǒng)的非商業(yè)用戶，所以將它們統(tǒng)稱為用戶信息類。電子商務(wù)配送系統(tǒng)在Internet中使用，所以為了安全起見，在分析實體類中，將經(jīng)常使用的類所涉及操作和基本信息分別設(shè)計一個類。例如，客戶信息類，客戶涉及到的信息設(shè)計到客戶信息類中，而客戶所涉及到的方法操作則歸為客戶信息操作類。這樣體現(xiàn)了而向?qū)ο蟮姆庋b性和安全性，能更好的滿足系統(tǒng)運作要求。

（2）生成類圖

通過上述類的分析，要生成類圖還需要弄清楚類與類之間的關(guān)系，并且要確定類的屬性和方法。上文分析了與“下訂單”用例相關(guān)的類，下面接著討論類的屬性和方法，并生成相關(guān)類圖。

邊界類:商品詳細信息界面(GoodsDetailslnterface)填寫訂單頁面(OrdersInterface)，主要是打開新的界面。

控制類:下訂單C Order)。協(xié)作類之間的工作，起到“中介”的作用。

實體類:用戶信息類(ClientInformations)，商品信息類(GoodsInformations)訂單信息類(OrderInformations)，用戶信息操作類(ClientOP)，商品信息操作類（GoodsOP），訂單信息操作類(OrderOP)。ClientInfornlations類的重要屬性有:用戶ID號，用戶名，注冊日期，登錄密碼，電子郵件;ClientOP類的主要操作有:系統(tǒng)注冊，系統(tǒng)登錄，查看商品，訂購商品，支付;GoodsInformations類主要屬性有:商品ID號，商品名稱，商品描述，商品價格，商品庫存，商品類別;GoodsOP類的主要操作有:獲取商品ID號、商品名稱和價格;OrderInformations類主要屬性有:訂單ID號，商品ID號，商戶ID號，用戶ID號，客戶姓名，訂購日期，訂購者地址，商品數(shù)量，商品價格;OrderOP類涉及的操作有:搜索訂單，查看訂單，處理訂單，添加訂單，刪除訂單。

根據(jù)以上分析，下訂單的類圖如圖4.12。實線箭頭表示的是關(guān)聯(lián)關(guān)系，虛線箭頭表示的是依賴關(guān)系。

由于電子商務(wù)配送系統(tǒng)涉及到類圖比較龐大，而分析類圖的過程可以通過上述方法一一得出用例的類圖，本文只對系統(tǒng)中的實體類圖進行建模。運用上文方法分析實體類所涉及到的信息類，實體類圖4.13a

4.4動態(tài)結(jié)構(gòu)建模

用例圖和類圖描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)，接下來建立系統(tǒng)的動態(tài)行為模型，動態(tài)行為模型主要是建立系統(tǒng)的順序圖和活動圖，川頁序圖主要來表示對一象之間的關(guān)系和對象之間傳送消息的時間順序?；顒訄D則是描述活動的順序的一種流程圖，是從一個活動到另一個活動的控制流。

（1）順序圖

該商城系統(tǒng)涉及到的順序圖有很多，比如用戶登錄順序圖，下訂單順序圖，刪除訂單順序圖，增加訂單順序圖，訂單處理順序圖。本文將通過“系統(tǒng)登錄”順序圖和“下訂單”順序圖建模為例來說明系統(tǒng)動態(tài)結(jié)構(gòu)建模。

“商城登錄”用例涉及到參與者是用戶，包括管理員和其他用戶，這里以客戶登錄系統(tǒng)為例，涉及到的對象有“登錄界面”，“服務(wù)器”和“數(shù)據(jù)中心”，根據(jù)ROSE中的順序圖的建模方法，本文得到“商城登錄”用例的順序圖如圖4.14。

根據(jù)上文分析的“下訂單”用例類圖，“下訂單”用例的順序圖參與者是客戶，所涉及到的對象有“登錄界面(login)”“商品信息查看界面(GoodsDetailsInterface)"“下訂單界面(OrdersInterface“

“訂單信息操作（OrderOP）”，用ROSE建模得出的“下訂單”順序圖如圖4.15所示。

(2)活動圖

活動圖表示一個事件正在運行的狀態(tài)，事件是系統(tǒng)中某個對象的一個操作，主要表現(xiàn)一個活動到另一個活動控制流，是系統(tǒng)內(nèi)部的驅(qū)動流程。一個系統(tǒng)涉及到的活動圖很多，本文提到的系統(tǒng)活動圖有:客戶下訂單的活動圖，商城用戶登錄活動圖，派遣配送員的活動圖等，本文將以“下訂單”活動圖為例。根據(jù)活動圖的組成元素，“下訂單”包括很多活動狀態(tài)，比如:查看商品，提交訂單，訂單處理等一系列狀態(tài)，“下訂單”就是從一個活動狀態(tài)轉(zhuǎn)換為另一個活動狀態(tài)，直至完成該動作，活動圖中涉及兩個對象，客戶和商戶，根據(jù)以上描述，在ROSE中建模的“下訂單”活動圖如圖4.16所示。

4.5數(shù)據(jù)庫建模

在以上小節(jié)本文成功建立了江西師范大學(xué)網(wǎng)上商城的業(yè)務(wù)流程圖、需求模型、靜態(tài)模型和動態(tài)模型，接下來就要介紹如何通過已建立L1ML靜態(tài)結(jié)構(gòu)模型中的類圖轉(zhuǎn)換為數(shù)據(jù)庫模型。在類圖轉(zhuǎn)換為數(shù)據(jù)庫模型，控制類和邊界類不需要轉(zhuǎn)換為系統(tǒng)數(shù)據(jù)庫模型，這些類是為了實現(xiàn)用例的流程而產(chǎn)生的類，所以只有那些持久存儲信息的實體類需要轉(zhuǎn)換為數(shù)據(jù)庫模型。轉(zhuǎn)換過程由于篇幅問題不再一一敘述，如圖4.17系統(tǒng)實體類圖轉(zhuǎn)換的數(shù)據(jù)庫模型圖。

系統(tǒng)的數(shù)據(jù)庫模型圖建立之后，將模型圖映射為數(shù)據(jù)表，此處數(shù)據(jù)庫模型中的屬性映射為數(shù)據(jù)表的列，系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)表如下表所示。4.6物理建模

完成系統(tǒng)的邏輯設(shè)計后，下一步要定義設(shè)計的物理實現(xiàn)，為了將邏輯設(shè)計圖轉(zhuǎn)化成實際的事物，面向?qū)σ幌笙到y(tǒng)的物理建模有兩種圖:組件圖和配置圖。組件圖是系統(tǒng)實現(xiàn)視圖的圖形表示，描述了系統(tǒng)的各種組件和組件之間的依賴關(guān)系。配置圖是系統(tǒng)執(zhí)行過程中資源元素的配置情況以及軟件到這些資源元素的映射，描述了系統(tǒng)中硬件和軟件的物理結(jié)構(gòu)。(1)組件圖

組件是表示將類、接口等打包而形成的物理模塊。組件圖是用來描述代碼的物理模塊之間的關(guān)系，顯示了代碼的結(jié)構(gòu)。組件圖能夠幫助客戶和系統(tǒng)開發(fā)人員理解最終的系統(tǒng)結(jié)構(gòu)。根據(jù)上文對江西師范大學(xué)“網(wǎng)上商城”的邏輯視圖的分析，在ROSE中得到系統(tǒng)的組件圖，圖4.18所示，組件圖中只有用虛線表示的依賴關(guān)系。

2.配置圖

配置圖用來表示系統(tǒng)的運行結(jié)構(gòu)或者系統(tǒng)軟件和硬件組織之間的關(guān)系，由節(jié)點和節(jié)點之間的聯(lián)系構(gòu)成，配置建模就是將軟件系統(tǒng)在互聯(lián)網(wǎng)上的運作方式模式化，南昌大學(xué)“網(wǎng)上商城”是一個基于其數(shù)據(jù)庫和校園網(wǎng)的應(yīng)用系統(tǒng)，根據(jù)第三章中電子商務(wù)系統(tǒng)多層B/S體系結(jié)構(gòu)，“網(wǎng)上商城”的系統(tǒng)配置圖如圖4.19。

4.7小結(jié)

電子商務(wù)系統(tǒng)是一個結(jié)構(gòu)復(fù)雜、規(guī)模龐大的系統(tǒng)，根據(jù)本文提出的基于UML的系統(tǒng)建模過程，本章以江西師范大學(xué)“網(wǎng)上商城”為實例，對其進行了系統(tǒng)的需求分析，建立了系統(tǒng)的需求模型、系統(tǒng)的靜態(tài)結(jié)構(gòu)模型、系統(tǒng)的動態(tài)結(jié)構(gòu)模型、系統(tǒng)的數(shù)據(jù)庫模型、系統(tǒng)的物理模型。確立了系統(tǒng)的功能模塊，分別建立了業(yè)務(wù)流程圖、用例圖、類圖、順序圖和活動圖、數(shù)據(jù)庫模型和數(shù)據(jù)表、組件圖和配置圖。

第5章基于數(shù)據(jù)挖掘的商品訂單分析

電子商務(wù)的迅速發(fā)展使其規(guī)模越來越復(fù)雜，客戶獲得有效商品信息的難度也在增加，因此如何增加商品信息的針對性，提高網(wǎng)站的可用性成為了現(xiàn)今電子商務(wù)研究的熱點。國內(nèi)對該熱點的研究很少，但是也有了一些研究成果，比如王兆紅((2005)利用關(guān)聯(lián)規(guī)則提出了商品的最佳打包組合：金偉健，金文進(2010)從理論上提出了基于關(guān)聯(lián)規(guī)則的商品推薦模型;章杰鑫，張烈平(2009)提出了時序關(guān)聯(lián)規(guī)則挖掘算法，并通過模擬超市數(shù)據(jù)預(yù)測了顧客在時間單位內(nèi)的商品關(guān)聯(lián)規(guī)則，使企業(yè)更好的了解客戶需求。本文應(yīng)用數(shù)據(jù)挖掘的關(guān)聯(lián)規(guī)則對商城的“訂單分析”功能進行了分析和設(shè)計。首先對商城歷史訂單進行數(shù)據(jù)預(yù)處理，然后應(yīng)用關(guān)聯(lián)規(guī)則挖掘客戶購買商品的關(guān)聯(lián)關(guān)系，這樣商戶可以掌握客戶的購物興趣，設(shè)置相應(yīng)的捆綁或交叉銷售，使商戶在降低成本的同時為廣大師生提供更好的生活服務(wù)，增加現(xiàn)有客戶的滿意度。5.1數(shù)據(jù)挖掘技術(shù) 5.1.1數(shù)據(jù)挖掘的概念

1997年SAS研究所將數(shù)據(jù)挖掘定義為將大量相關(guān)數(shù)據(jù)進行探索，最后建立相關(guān)模型的方法;1999年Bhavani將數(shù)據(jù)挖掘定義為一個過程，即利用數(shù)學(xué)，統(tǒng)計和模式識別技術(shù)，在大量的數(shù)據(jù)中發(fā)現(xiàn)新的趨勢、新關(guān)系和模式的過程;最后一種是最具有影響力且至今被廣泛采用的Usama M.Fayyad等給出的，即數(shù)據(jù)挖掘(Data Mining)是從大量的、有噪聲、模糊的、不完全的、隨機的數(shù)據(jù)中挖掘出隱含的、未知的、用戶可能感興趣的但又有潛在價值的知識和信息的過程。5.1.2數(shù)據(jù)挖掘的功能一可以挖掘什么類型的模式

數(shù)據(jù)挖掘的目標從大量的數(shù)據(jù)中發(fā)現(xiàn)隱含的、有意義的知識并對現(xiàn)有數(shù)據(jù)記錄進行分析，預(yù)測未來趨勢和行為，做出基于知識的決策，主要有以下功能。

1.描述功能:將數(shù)據(jù)庫中的對象通過數(shù)據(jù)分類、聚類分析、數(shù)據(jù)匯總與歸納、概括等過程最終獲得數(shù)據(jù)簡明、準確的描述。

第三篇：山東大學(xué)軟件學(xué)院面向?qū)ο蠓椒荚嚳谑鼍啺?/a>

教務(wù)系統(tǒng)的用例圖（UML+代碼）

電梯運行狀態(tài)圖

門的（有把手/無把手）裝潢模式（模式+類圖+代碼）時鐘（鐘表/數(shù)字）同上

網(wǎng)頁下載（http/ftp）的兩種下載方式用什么模式實現(xiàn) 同上

interator模式（迭代器模式）一個容器 作用是裝載以及迭代的方式取出所有數(shù)據(jù)

第四篇：面向?qū)ο蟪绦蛟O(shè)計教學(xué)大綱-計算機科學(xué)與軟件學(xué)院

面向?qū)ο蠹夹g(shù)

Technology of Object-Oriented Programming 課程編號：30420032 學(xué)分數(shù)：2 開課單位：計算機技術(shù)與自動化學(xué)院

課內(nèi)總時數(shù)：40 任課教師姓名及職稱：陳勇副教授、柯永振講師、劉坤良講師 開課學(xué)期：第2學(xué)期 教學(xué)方式：講授

一、教學(xué)要求及目的：

理解面向?qū)ο蟮幕舅枷?、基本概念；掌握面向?qū)ο蟪绦蛟O(shè)計語言的基本結(jié)構(gòu)、各種語法成分的作用、語法結(jié)構(gòu)及運用方式；掌握面向?qū)ο蟪绦蛟O(shè)計的方法和技巧；能比較熟練地用C#語言進行一般面向?qū)ο蟮某绦蚍治觥⒃O(shè)計，提高編寫和調(diào)試應(yīng)用程序的能力。

二、課程的主要內(nèi)容

1．面向?qū)ο蠓椒ǖ臍v史與現(xiàn)狀

面向?qū)ο蠹夹g(shù)的發(fā)展歷史，主要的面向?qū)ο笳Z言介紹。

2．.Net Framework概述.Net Framework基本框架，.Net Framework的優(yōu)點，以及開發(fā)平臺。3．C#概述

C#的起源和特點，C#源程序的基本構(gòu)成，C#中非面向?qū)ο蠓矫娴摹┏绦蛱匦浴?．C#中類和對象

類與對象的基本概念，構(gòu)造函數(shù)，方法與屬性，參數(shù)傳遞，靜態(tài)成員。5．派生、繼承、多態(tài)性

數(shù)據(jù)的抽象與封裝，派生類的概念，派生類的構(gòu)造函數(shù)，C#中多重繼承的處理方法，虛方法的實現(xiàn)，抽象類，重載的實現(xiàn)，接口的實現(xiàn)，代理的實現(xiàn)。6． 基于Windows 與Web的應(yīng)用程序開發(fā)

開發(fā)Windows，Web應(yīng)用程序的基本框架。7．Web Service實現(xiàn)

使用XML的Web Service實現(xiàn)。8.面向?qū)ο蠹夹g(shù)實踐

根據(jù)所掌握的面向?qū)ο蠹夹g(shù)，分析一個具體案例，利用C#實現(xiàn)其功能。

三、課程教材及主要參考書

1．C#面向?qū)ο蟪绦蛟O(shè)計，黃聰明，科學(xué)出版社，2004年 2.C#程序設(shè)計，田原，清華大學(xué)出版社，2005 3．C#高級編程，李敏波，清華大學(xué)出版社，2005（第3版）.4．C#程序設(shè)計教程，余安萍，電子工業(yè)出版社，2002 5．面向?qū)ο蟮姆治雠c設(shè)計，（美）Grady Booch著，機械工業(yè)出版社，2005年

6．C#范例解析，朱沭紅，電子工業(yè)出版社，2002 7．Visual C#程序設(shè)計基礎(chǔ)教程，邵鵬鳴，清華大學(xué)出版社，2005.四、預(yù)修課程

C語言程序設(shè)計、數(shù)據(jù)結(jié)構(gòu)、程序設(shè)計方法學(xué)

五、適用專業(yè)、范圍

計算機應(yīng)用技術(shù)專業(yè)、計算機軟件與理論專業(yè)

第五篇：河南城建學(xué)院信息系統(tǒng)分析與設(shè)計考試總結(jié)

一．填空。（20）

1.項目人力資源管理包括項目團隊組建和管理的各個過程，其作用是保證最有效的使用項目人力資源完成項目活動。

2.項目溝通管理是指對于項目過程中各種不同方式和不同內(nèi)容的溝通活動的管理。

3.軟件危機是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題。

4.模型是運用某種圖標工具對系統(tǒng)特征（包括靜態(tài)特征和動態(tài)特征）的一種表示。

5.業(yè)務(wù)流程是指一個組織在完成其使命、實現(xiàn)其目標的過程中必需的、邏輯上相關(guān)的一組活動。

6.可行性研究的目的是說明該IT項目的實現(xiàn)在技術(shù)上、經(jīng)濟上和運行條件上的可行性。

7.需求分析是系統(tǒng)開發(fā)的一個重要步驟，是整個系統(tǒng)開發(fā)的基礎(chǔ)。

8.邏輯模型在系統(tǒng)分析中起著重要的作用，是新系統(tǒng)設(shè)計的基礎(chǔ)和依據(jù)。

9.概念設(shè)計是把用戶的信息要求統(tǒng)一到一個整體邏輯結(jié)構(gòu)中。

10.系統(tǒng)設(shè)計的主要任務(wù)是依據(jù)系統(tǒng)需求規(guī)格說明書，全面地確定系統(tǒng)應(yīng)具有的功能和性能要求。

11.面向?qū)ο笤O(shè)計是在面向?qū)ο蠓治龅幕A(chǔ)上，增加實現(xiàn)的細節(jié)來完成的。

12.結(jié)構(gòu)化設(shè)計的優(yōu)點之一是通過分解技術(shù)，使得軟件結(jié)構(gòu)易于理解。

二．名詞解釋。（20）

1.項目管理是以項目為對象的系統(tǒng)管理方法，通過一個臨時性專門機構(gòu)的柔性組織，對項目進行高效率的計劃、組織、指導(dǎo)和控制，以實現(xiàn)項目全過程的動態(tài)管理和項目目標的綜合協(xié)調(diào)和優(yōu)化。項目管理需要通過一個專門的組織實施，通過規(guī)劃資源，從時間、成本、質(zhì)量、客戶關(guān)系等方面滿足項目目標。

2.企業(yè)信息化戰(zhàn)略(BIS)也稱為信息技術(shù)戰(zhàn)略，是企業(yè)戰(zhàn)略的有機組成部分，是關(guān)于信息功能的目標及其實現(xiàn)的總體規(guī)劃。從功能劃分的角度來講，企業(yè)信息化戰(zhàn)略是一類獨立的戰(zhàn)略；從信息功能實現(xiàn)的角度來看，企業(yè)信息化戰(zhàn)略又必須與企業(yè)戰(zhàn)略相融合。企業(yè)信息化戰(zhàn)略描述了企業(yè)未來的信息化藍圖，并描繪了如何獲取與整合這些藍圖的能力。

3.數(shù)據(jù)庫設(shè)計是指在特定的DBMS環(huán)境下開發(fā)數(shù)據(jù)庫應(yīng)用系統(tǒng)，并非設(shè)計DBMS本身。數(shù)據(jù)庫設(shè)計所涉及的內(nèi)容包括“結(jié)構(gòu)特性的設(shè)計”和“行為特性的設(shè)計”兩個方面。結(jié)構(gòu)特性設(shè)計是指數(shù)據(jù)庫總體概念的設(shè)計，它是一個反應(yīng)不同用戶需求的、實現(xiàn)數(shù)據(jù)共享的系統(tǒng)。結(jié)構(gòu)特性是靜態(tài)的。行為特性設(shè)計是指數(shù)據(jù)庫用戶的業(yè)務(wù)活動。一般而言，用戶的業(yè)務(wù)活動通過應(yīng)用程序訪問和操作數(shù)據(jù)庫，與結(jié)構(gòu)特性有關(guān)。

4.系統(tǒng)分析是指運用一定的方法，對問題域和系統(tǒng)責(zé)任進行分析和理解，對其中的事物和它們之間的關(guān)系產(chǎn)生正確的認識，并產(chǎn)生一個符合用戶需求，能夠直接反映問題域和系統(tǒng)責(zé)任的模型及其詳細說明。系統(tǒng)分析的主要任務(wù)是需求開發(fā)和管理。

5.活動圖是狀態(tài)圖的一個特例，其中所有的狀態(tài)都是動作狀態(tài)，且轉(zhuǎn)換都是由源狀態(tài)中的動作完成觸發(fā)的?；顒訄D與特定的類活用里相關(guān)，特描述某個方法的內(nèi)部表現(xiàn)，使用活動圖可以表示由內(nèi)部生成的動作驅(qū)動的事件流。

三．問答。（30）

1.原型法的優(yōu)點和缺點：

優(yōu)點：1）減少了開發(fā)時間，大大提高了系統(tǒng)開發(fā)效率。這主要是由于最終用戶更加積極地參與系統(tǒng)的開發(fā)，尤其是信息系統(tǒng)需求的確定。

2）由于用戶在看到原型以前往往很難理解和詳細陳述其需求，而且用戶所看到的是實際的工作模型而不是單調(diào)的語言或圖來描述的需求，因此，通過原型法使信息需求的定義工作更為直觀、簡單。

3）通過一系列對原型的修改和完善，大大增加了用戶對設(shè)計的滿意程度，進而提高了信息

系統(tǒng)的質(zhì)量。

4）減少了系統(tǒng)開發(fā)費用。

缺點：1）分析和設(shè)計上的深度不夠，從而可能造成在未能很好地理解用戶需求的情況下就著手程序代碼的編寫。

2）快速原型法中的第一個工作原型可能并不是一個最優(yōu)方案。

3）通過原型法所開發(fā)的系統(tǒng)不具備靈活性，難以適應(yīng)用戶需求的變化。

4）工作原型不容易修改。

2.IT規(guī)劃的作用是

1）全局性。從企業(yè)戰(zhàn)略發(fā)展的高度出發(fā)，縱覽全局，目標明確，規(guī)劃整個企業(yè)信息系統(tǒng)的全景遠景圖，確保信息架構(gòu)能更好地應(yīng)付業(yè)務(wù)流程和組織的變化。

2）預(yù)警性。通過考察、借鑒和學(xué)習(xí)，總結(jié)成功經(jīng)驗，吸取失敗教訓(xùn)，能有效預(yù)防各種信息化建設(shè)中易出現(xiàn)的問題，知道系統(tǒng)選型和項目實施，從而有效地規(guī)避、降低企業(yè)信息化的各種風(fēng)險。

3）有序性。根據(jù)企業(yè)各方面的資源約束，以及企業(yè)的預(yù)算，按照輕重緩急給出信息化建設(shè)的階段性目標。

4）經(jīng)濟性。始終考慮成本投入與產(chǎn)出的關(guān)系問題，降低成本，科學(xué)地確定信息化建設(shè)的投資，用較少的資金做更多的事情。依據(jù)信息化建設(shè)的目標和全局架構(gòu)，避免無效投資、重復(fù)投資等。

5）集成性。整合信息資源，解決“信息孤島”問題，確保各應(yīng)用系統(tǒng)的整體集成。

6）挖掘潛在的應(yīng)用系統(tǒng)。

3.邏輯模型是與實施無關(guān)的模型。他描述了系統(tǒng)的本質(zhì)，即系統(tǒng)必須做什么，而與系統(tǒng)是如何實施的無關(guān)。也就是說，邏輯模型是用來描述數(shù)據(jù)的內(nèi)容及處理功能的，而不關(guān)心這些功能是如何實現(xiàn)的。其優(yōu)點是：

1）邏輯模型不考慮系統(tǒng)具體的實施方式，因而可以最大程度地發(fā)揮系統(tǒng)分析師的創(chuàng)造性。

2）邏輯模型減少了遺漏用戶功能需求的風(fēng)險。系統(tǒng)一旦實施，修正這種錯去的費用極大。通過將系統(tǒng)做什么與如何去做分離開來，有助于更好地保持需求的完整性、準確性、一致性。

3）邏輯模型可以使系統(tǒng)開發(fā)人員以非技術(shù)語言或盡可能少的技術(shù)語言與最終用戶進行交流。

4.交互圖包括協(xié)作圖和順序圖。協(xié)作圖和順序圖都表示出了對象間的交互作用，但是他們側(cè)重點不同。順序圖將交互關(guān)系表示為一個二維圖?？v向是時間軸，時間沿豎線向下延伸。橫向軸代表了在協(xié)作中各獨立對象的類元角色。順序圖清楚地表示了交互作用中的時間順序，但沒有明確表示對象間的關(guān)系。協(xié)作圖清楚地表示了對象間的關(guān)系，但時間順序必須從順序圖中獲得。順序圖常常用于表示方案，而協(xié)作圖用于過程的詳細設(shè)計。

5.三層結(jié)構(gòu)由以下幾部分組成：客戶機、應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器。實際上，B/S結(jié)構(gòu)是將應(yīng)用邏輯從客戶機和數(shù)據(jù)庫服務(wù)器中分離出來。三層結(jié)構(gòu)的優(yōu)點是：1）使客戶端人機界面部分的程序開發(fā)工作得以簡化。它不必關(guān)心業(yè)務(wù)邏輯是如何訪問數(shù)據(jù)庫的，只需把精力集中在人機界面上即可。

2）中間業(yè)務(wù)邏輯層包含了大量的供客戶端程序調(diào)用的業(yè)務(wù)邏輯規(guī)則，以幫助其完成業(yè)務(wù)操作。它的優(yōu)點就在于它所具有的可伸縮性，可使其隨具體業(yè)務(wù)的變化而改變，但在客戶層和數(shù)據(jù)服務(wù)層所做的改動較小，適合于快速開發(fā)。

3）數(shù)據(jù)服務(wù)層主要提供對數(shù)據(jù)庫進行各種操作的方法。它主要由中間業(yè)務(wù)層來調(diào)用比昂完成業(yè)務(wù)邏輯，當數(shù)據(jù)庫的結(jié)構(gòu)確定后，對于它的改動也就比較小了。

4）系統(tǒng)的安全性得以提高。它可以對每個業(yè)務(wù)功能組件進行授權(quán)，限制了非法訪問。

5）便于進行事務(wù)管理。