第一篇：石河子大學 信息學院 面向對象的設計與分析 OOAD考試總結

OOAD總復習

第一章

1、什么是分析與設計？

1、分析強調對問題和需求的調查研究

2、設計強調的是滿足需求的概念上的解決方案

2、什么是面向對象分析與設計？

1、在面向對象分析過程中，強調的是在問題領域內發現和描述對象（或概念）

2、在面對對象設計過程中，強調的是定義軟件對象以及它們如何協作以實現需求。

3、簡單示例：

1、定義用例（use case）

需求分析可能包括人們如何使用應用的情節或場景，這些情節或場景可以被編寫成用例。

2、定義領域模型（domain model）

面向對象分析的結果可以表示為領域模型，在領域模型中展示重要的領域概念或對象。需要注意的是，領域模型并不是對軟件對象的描述，它使真實世界領域中的概念和想象可視化。（也被稱為概念領域模型—conceptual object model）

3、定義交互圖

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

4、定義設計類圖

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

與領域模型表示的是真實世界的類，設計類圖表示的是軟件類

要注意的是，盡管設計類圖不同于領域模型，但是其中的某些類名和內容還是相似的。

第二章

1、什么是UML？

統一建模語言（UML）是描述、構造和文檔化系統制品的可視化語言。

UML表示法的基礎是UML元模型，它描述建模元素的語義，UML元模型對模型驅動架構（Model Driven Architecture, MDA）CASE工具供應商具有影響。開發者并不需要對其進行學習。

2、三種UML應用方式

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

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

3、UML作為編程語言—用UML完成軟件系統可執行規格說明。

3、什么是UP？

軟件開發過程（software development process）描述了構造、部署以及維護軟件的方式。統一過程（UP）已經成為一種流行的構造面向對象系統的迭代軟件開發過程。

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

1、迭代開發是UP和大多數其他現代方法中的關鍵實踐。每次迭代都具有各自的需求分析、設計、實現和測試活動。

2、迭代進化開發

小步驟、快速反饋和調整是迭代開發的重要思想。短時迭代為上。迭代的一個關鍵時光可見

第 1 頁

2013-3-31 OOAD總復習

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

3、瀑布生命周期

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

4、什么是敏捷模型？

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

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

3、不要對所有或大多數軟件建模或者應用UML。

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

5、UP所倡導的核心思想是：短時間定量迭代、進化和可適應性開發。

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

第五章

1、進化式需求

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

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

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

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

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

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

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

3、可靠性：故障頻率、可恢復性、可預測性

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

5、可支持性：適應性、可維護性、國際化、可配置性

6、一些次要因素：實現、接口、操作、包裝、授權

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

1、用例模型：一組使用系統的典型場景。

2、補充性規格說明：基本上是用例之外的所有內容。

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

4、設想：概括了高階需求，項目的業務案例。

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

第六章

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

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

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

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

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

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

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

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

時光可見

第 2 頁

2013-3-31 OOAD總復習

3、用例是一組相關的成功和失敗場景的集合，用來描述參與者如何使用系統來實現其目標。

4、準則：如何發現用例？

1、選擇系統邊界

2、辨別主要參與者

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

4、定義用例以滿足目標

5、準則：什么樣的測試有助于發現有用的用例？

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

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

3、規模測試(the size test)

6、示范：應用上述測試

1、就供應者合同進行協商：

比ERP更廣泛，用時更長。更適合作為業務用例，而非系統用例。

2、處理退貨

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

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

4、在游戲板上移動棋子

單一步驟，不能通過規模測試

第八章

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

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

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

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

1、對核心、有風險的軟件架構進行編程和測試

2、發現并穩定需求的主要成分

3、規避主要風險

第九章

1、領域模型是對領域內的概念類或現實世界中對象的可視化表示。領域模型也稱為概念膜性能高、領域對象模型和分析對象模型。

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

1、領域對象或者概念類

2、概念類之間的關聯

3、概念類的屬性

3、準則：如何創建領域模型？

1、尋找概念類

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

3、添加關聯和屬性

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

時光可見

第 3 頁

2013-3-31 OOAD總復習

1、重用和修改現有的模型

2、使用分類列表

3、確定名詞短語

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

1、需要有關商品或者服務的描述，獨立于任何商品或服務的現有實例

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

3、減少冗余或重復信息

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

7、準則：在UML中如何對關聯命名？

以“類名—動詞短語—類名”的格式為關聯命名，其中的動詞短語構成了可讀和有意義的順序。

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

第十章

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

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

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

4、什么是系統順序圖？

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

第十一章

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

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

1、操作：操作的名稱和參數

2、交叉引用：會發生此操作的用例

3、前置條件：執行操作之前，對系統或領域模型對象狀態的重要假設。

4、后置條件：最重要的部分。完成操作后，領域模型對象的狀態。

3、什么是系統操作？

系統操作是作為黑盒構件的系統在其公共接口中提供的操作。系統操作可以在繪制SSD草圖時確定。

4、后置條件描述了領域模型內對象狀態變化。領域模型狀態變化包括創建實例、形成或消除關聯以及改變屬性。

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

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

6、準則：如何創建和編寫契約？

1、從SSD圖中確定系統操作

時光可見

第 4 頁

2013-3-31 OOAD總復習

2、如果系統操作復雜，其結果可能不明顯，或者在用例中不清楚，則可以為其構造契約

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

1、創建或刪除實例

2、屬性值的變化

3、形成或消除關聯（UML連接）

第十三章

1、什么是邏輯架構和層？

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

層是對類、包或子系統的甚為粗粒度的分組，具有對系統主要方面加以內聚的職責。

OO系統中通常包括的層有：

1、用戶界面

2、應用邏輯和領域對象

3、技術服務

2、什么是軟件架構？

架構是一組重要的決策，其中涉及軟件系統的組織，對結構元素及其組成系統所籍接口的選擇，這些元素特定于其相互協作的行為，這些結構和行為元素到規模更大的子系統的組成，以及指導該組織結構的架構風格。

第十五章

1、交互圖這一術語是對以下兩種更為特化的UML圖的統稱

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

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

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

1、消息：實心箭頭

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

3、異步調用：虛線

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

1、鏈是連接兩個對象的路徑，它指明了對象間某種可能的導航和可見性。鏈是關聯的實例。

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

3、消息的順序編號：

1、不為第一個消息編號

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

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

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

6、迭代或循環：在順序編號后面加*

第十六章

時光可見

第 5 頁

2013-3-31 OOAD總復習

1、表示UML屬性的方法：屬性文本和關聯線

2、在DCD中使用關聯表示屬性時的風格：導航性箭頭、角色名、3、對于領域模型使用類圖的時候，需要表示關聯名稱，但是要避免使用導航箭頭，因為領域模型不是軟件透視圖。

3、對數據類型對象使用屬性文本表示法，對其他對象使用關聯線。

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

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

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

2、向提供者發送消息

3、接收提供者類型的參數

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

6、依賴標簽

7、插座法表示接口

8、限定關聯

第十七章

1、GRASP：基本OO設計的系統方法

2、GRASP：使用職責進行OO設計的學習工具

3、RDD（responsibility-driven design）：職責驅動設計。

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

1、行為職責：

1、自身執行一些行為，如創建對象或計算。

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

3、控制和協調其他對象中的活動

2、認知職責：

1、對私有封裝數據的認知

2、對相關對象的認知

3、對其能夠導出或計算的事物的認知

5、對于軟件領域對象來說，由于領域模型描述了領域對象的屬性和關聯，因此其通常產生與“認知”相關的職責。

6、職責的粒度會影響職責到類和方法的轉換。

7、什么是模式？

如果以結構化形式對這些問題、解決方案和命名進行描述使其系統化，那么這些原則和習慣用法就可以稱為模式。

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

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

1、創建者

2、信息專家

3、低耦合4、控制器

5、高內聚

9、創建者：誰創建了A？

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

時光可見

第 6 頁

2013-3-31 OOAD總復習

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

2、B記錄A

3、B緊密地使用A

4、B具有A的初始化數據

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

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

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

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

12、控制器：在UI層之上首先接受和協調系統操作的對象是什么？

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

1、代表全部“系統”、“根對象”、運行軟件的設備或主要的子系統

2、代表發生系統操作的用例場景（用例或會話）

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

解決方案：職責分配應保持高內聚，依此來評估備選方案

第十八章

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

2、下面說明了一些制品之間的關系：

1、用例指出了SSD中所示的系統操作

2、系統操作可以稱為輸入到領域層交互圖的控制器中的起始消息

3、領域層交互圖闡述了對象如何交互完成所需任務—用例實現

第十九章

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

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

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

2、參數可見性—B是A中方法的參數

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

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

第二十章

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

2、在UP中具有實現模型。源代碼、數據庫定義、JSP/XML/HTML頁面等都是實現制品

3、面向對象語言中的實現需要以下元素編寫源代碼：

1、類和接口的定義

2、方法的定義

第二十三章

1、在迭代1結束的時候，應該已經完成以下任務：

1、所有軟件都已經被充分地測試

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

3、已經對系統進行了完成的集成和固化，使其成為基線化的內部版本

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

時光可見

第 7 頁

2013-3-31 OOAD總復習

1、支持第三方外部服務的變化

2、復雜的定價規則

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

第二十五章

1、之前介紹了5個GRASP模式：信息專家、創建者、高內聚、低耦合、控制器

2、下面介紹最后4個GRASP模式：多態、間接性、純虛構、防止變異

3、多態：如何處理基于類型的選擇？如何創建可插拔的軟件構件？

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

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

解決方案：對人為制造的類分配一組高內聚的職責，該類并不代表問題領域的概念—虛構的事物，用以支持高內聚、低耦合和復用。這種類是憑空虛構的。

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

解決方案：將職責分配給中介對象，使其作為其他構件或服務之間的媒介，以避免它們之間的直接耦合。中介實現了其他構件之間的間接性

6、防止變異：如何設計對象、子系統和系統，使其內部的變化或不穩定不會對其他元素產生不良影響？

解決方案：識別預計變化或不穩定之處，分配職責用以在這些變化之外創建穩定接口

第二十六章

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

解決方案：通過中介適配器對象，將構件的原有接口轉換為其他接口。增加一層間接性對象，通過這些對象將不同的外部接口調整為在應用程序內使用的一致接口

2、工廠：當有特殊考慮（例如存在復雜創建邏輯，為了改良內聚而分離創建職責等）時，應該由誰來負責創建對象？

解決方案：創建稱為工廠的純虛構對象來處理這些創建職責

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

解決方案：對類定義靜態方法用以返回單實例

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

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

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

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

6、外觀：對一組完全不同的實現或接口需要公共、統一的接口。可能會與子系統內部的大量事物產生耦合，或者子系統的實現可能會改變，怎么辦？

解決方案：對子系統定義惟一的接觸點—使用外觀對象封裝子系統。該外觀對象提供了惟一和統一的接口，并負責與子系統構件進行協作

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

第 8 頁

2013-3-31 OOAD總復習

且想要在發布者產生事件時以自己獨特的方式作出反應。此外，發布者想要保持與訂閱者的低耦合。如何對此進行設計呢？

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

第三十章

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

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

1、用例在其他用例中重復使用

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

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

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

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

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

7、擴展關系的思路是，創建擴展或附加用例，并且在其中描述：在何處何何種條件下該用例擴展某基礎用例的行為

8、事實上，直接更新基礎用例的擴展部分是推薦的方法，這樣避免了創建復雜的用例關系

9、擴展關系的UML表示法：

1、擴展用例指向基礎用例

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

第三十一章

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

2、概念超類與子類之間是什么關系？

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

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

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

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

潛在的子類應該遵守下述規則：

1、100%規則（定義的一致性）

2、Is-a規則（集合成員關系的一致性）

8、在下述幾種情形下創建概念類的子類

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

2、子類有額外的有意義的關聯

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

9、在下述情形下可以創建與子類具有泛化關系的超類

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

2、子類滿足100%和Is-a規則

時光可見

第 9 頁

2013-3-31 OOAD總復習

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

4、所有子類都具有相同的關聯，可以將其解析出來并與超類關聯

10、在領域模型中，如果類C可能同時有多個相同的屬性A，則不要將屬性A置于C至中，應該將屬性A放在另一個類中，并且將其與C關聯

11、在領域模型中增加關聯類的可能線索有：

1、有某個屬性與關聯有關

2、關聯類的實例具有依賴于關聯的生命期

3、兩個概念之間有多對多關聯，并且存在于關聯自身相關的信息

12、在下述情況下，可以考慮組合關系：

1、部分的生命期在組成生命期界限之內，部分的創建和刪除依賴于整體

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

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

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

13、在關聯中可能會

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

第二篇：面向對象的設計與分析(網上商城的建模設計)

第4章江西師范大學“網上商城”建模實例

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

4.1系統的需求分析 4.1.1系統的設計背景

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

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

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

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

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

3.商城用戶信息管理:對商城注冊用戶信息的管理，以及其應用權限

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

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

6.訂單分析:管理員可以對收集到的數據進行分析，得出商品之間的關聯性。建議商戶調整銷售策略，從而提高商店利潤。

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

9.商城登錄:系統管理員、用戶、商戶都可以登錄商城相應的模塊在相應權限內操作。

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

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

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

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

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

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

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

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

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

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

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

23.查看商品銷售記錄:商戶可以對本商店的商品信息隨時查看。24.查詢分析結果:商戶可以登錄商城查詢商品的關聯分析結果，通過結果設置相應的銷售捆綁包或交叉銷售。

25.設置銷售捆綁包:對分析到的關聯商品，通過后臺輸入設置到捆綁包中。

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

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

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

4.2需求建模

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

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

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

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

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

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

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

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

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

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

支付系統用例有:支付，網上支付，貨到支付。支付系統的用例圖，如圖4.10所示。

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

4.3靜態結構建模

靜態結構模型是對有關系統實現內部和應用領域的概念進行建模，本文通過分析上述需求建模中的用例和問題域，抽取相關的類，并將這些類之間的關系表示出來，以及類的內部結構，最后完成類圖，反應了系統的一種靜態關系。(1)抽取系統中的類

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

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

控制類:下訂單。

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

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

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

3.實體類:用戶信息類，商品信息，訂單信息，配送員信息類，購物車信息類，配送訂單信息類，商戶信息類，商品銷售記錄信息類，評論信息類。管理員和客戶都屬于系統的非商業用戶，所以將它們統稱為用戶信息類。電子商務配送系統在Internet中使用，所以為了安全起見，在分析實體類中，將經常使用的類所涉及操作和基本信息分別設計一個類。例如，客戶信息類，客戶涉及到的信息設計到客戶信息類中，而客戶所涉及到的方法操作則歸為客戶信息操作類。這樣體現了而向對象的封裝性和安全性，能更好的滿足系統運作要求。

（2）生成類圖

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

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

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

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

根據以上分析，下訂單的類圖如圖4.12。實線箭頭表示的是關聯關系，虛線箭頭表示的是依賴關系。

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

4.4動態結構建模

用例圖和類圖描述了系統的靜態結構，接下來建立系統的動態行為模型，動態行為模型主要是建立系統的順序圖和活動圖，川頁序圖主要來表示對一象之間的關系和對象之間傳送消息的時間順序。活動圖則是描述活動的順序的一種流程圖，是從一個活動到另一個活動的控制流。

（1）順序圖

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

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

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

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

(2)活動圖

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

4.5數據庫建模

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

系統的數據庫模型圖建立之后，將模型圖映射為數據表，此處數據庫模型中的屬性映射為數據表的列，系統的數據結構表如下表所示。4.6物理建模

完成系統的邏輯設計后，下一步要定義設計的物理實現，為了將邏輯設計圖轉化成實際的事物，面向對一象系統的物理建模有兩種圖:組件圖和配置圖。組件圖是系統實現視圖的圖形表示，描述了系統的各種組件和組件之間的依賴關系。配置圖是系統執行過程中資源元素的配置情況以及軟件到這些資源元素的映射，描述了系統中硬件和軟件的物理結構。(1)組件圖

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

2.配置圖

配置圖用來表示系統的運行結構或者系統軟件和硬件組織之間的關系，由節點和節點之間的聯系構成，配置建模就是將軟件系統在互聯網上的運作方式模式化，南昌大學“網上商城”是一個基于其數據庫和校園網的應用系統，根據第三章中電子商務系統多層B/S體系結構，“網上商城”的系統配置圖如圖4.19。

4.7小結

電子商務系統是一個結構復雜、規模龐大的系統，根據本文提出的基于UML的系統建模過程，本章以江西師范大學“網上商城”為實例，對其進行了系統的需求分析，建立了系統的需求模型、系統的靜態結構模型、系統的動態結構模型、系統的數據庫模型、系統的物理模型。確立了系統的功能模塊，分別建立了業務流程圖、用例圖、類圖、順序圖和活動圖、數據庫模型和數據表、組件圖和配置圖。

第5章基于數據挖掘的商品訂單分析

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

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

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

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

第三篇：山東大學軟件學院面向對象方法考試口述精簡版

教務系統的用例圖（UML+代碼）

電梯運行狀態圖

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

網頁下載（http/ftp）的兩種下載方式用什么模式實現 同上

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

第四篇：面向對象程序設計教學大綱-計算機科學與軟件學院

面向對象技術

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

課內總時數：40 任課教師姓名及職稱：陳勇副教授、柯永振講師、劉坤良講師 開課學期：第2學期 教學方式：講授

一、教學要求及目的：

理解面向對象的基本思想、基本概念；掌握面向對象程序設計語言的基本結構、各種語法成分的作用、語法結構及運用方式；掌握面向對象程序設計的方法和技巧；能比較熟練地用C#語言進行一般面向對象的程序分析、設計，提高編寫和調試應用程序的能力。

二、課程的主要內容

1．面向對象方法的歷史與現狀

面向對象技術的發展歷史，主要的面向對象語言介紹。

2．.Net Framework概述.Net Framework基本框架，.Net Framework的優點，以及開發平臺。3．C#概述

C#的起源和特點，C#源程序的基本構成，C#中非面向對象方面的—些程序特性。4．C#中類和對象

類與對象的基本概念，構造函數，方法與屬性，參數傳遞，靜態成員。5．派生、繼承、多態性

數據的抽象與封裝，派生類的概念，派生類的構造函數，C#中多重繼承的處理方法，虛方法的實現，抽象類，重載的實現，接口的實現，代理的實現。6． 基于Windows 與Web的應用程序開發

開發Windows，Web應用程序的基本框架。7．Web Service實現

使用XML的Web Service實現。8.面向對象技術實踐

根據所掌握的面向對象技術，分析一個具體案例，利用C#實現其功能。

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

1．C#面向對象程序設計，黃聰明，科學出版社，2004年 2.C#程序設計，田原，清華大學出版社，2005 3．C#高級編程，李敏波，清華大學出版社，2005（第3版）.4．C#程序設計教程，余安萍，電子工業出版社，2002 5．面向對象的分析與設計，（美）Grady Booch著，機械工業出版社，2005年

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

C語言程序設計、數據結構、程序設計方法學

五、適用專業、范圍

計算機應用技術專業、計算機軟件與理論專業

第五篇：河南城建學院信息系統分析與設計考試總結

一．填空。（20）

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

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

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

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

5.業務流程是指一個組織在完成其使命、實現其目標的過程中必需的、邏輯上相關的一組活動。

6.可行性研究的目的是說明該IT項目的實現在技術上、經濟上和運行條件上的可行性。

7.需求分析是系統開發的一個重要步驟，是整個系統開發的基礎。

8.邏輯模型在系統分析中起著重要的作用，是新系統設計的基礎和依據。

9.概念設計是把用戶的信息要求統一到一個整體邏輯結構中。

10.系統設計的主要任務是依據系統需求規格說明書，全面地確定系統應具有的功能和性能要求。

11.面向對象設計是在面向對象分析的基礎上，增加實現的細節來完成的。

12.結構化設計的優點之一是通過分解技術，使得軟件結構易于理解。

二．名詞解釋。（20）

1.項目管理是以項目為對象的系統管理方法，通過一個臨時性專門機構的柔性組織，對項目進行高效率的計劃、組織、指導和控制，以實現項目全過程的動態管理和項目目標的綜合協調和優化。項目管理需要通過一個專門的組織實施，通過規劃資源，從時間、成本、質量、客戶關系等方面滿足項目目標。

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

3.數據庫設計是指在特定的DBMS環境下開發數據庫應用系統，并非設計DBMS本身。數據庫設計所涉及的內容包括“結構特性的設計”和“行為特性的設計”兩個方面。結構特性設計是指數據庫總體概念的設計，它是一個反應不同用戶需求的、實現數據共享的系統。結構特性是靜態的。行為特性設計是指數據庫用戶的業務活動。一般而言，用戶的業務活動通過應用程序訪問和操作數據庫，與結構特性有關。

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

5.活動圖是狀態圖的一個特例，其中所有的狀態都是動作狀態，且轉換都是由源狀態中的動作完成觸發的。活動圖與特定的類活用里相關，特描述某個方法的內部表現，使用活動圖可以表示由內部生成的動作驅動的事件流。

三．問答。（30）

1.原型法的優點和缺點：

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

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

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

系統的質量。

4）減少了系統開發費用。

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

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

3）通過原型法所開發的系統不具備靈活性，難以適應用戶需求的變化。

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

2.IT規劃的作用是

1）全局性。從企業戰略發展的高度出發，縱覽全局，目標明確，規劃整個企業信息系統的全景遠景圖，確保信息架構能更好地應付業務流程和組織的變化。

2）預警性。通過考察、借鑒和學習，總結成功經驗，吸取失敗教訓，能有效預防各種信息化建設中易出現的問題，知道系統選型和項目實施，從而有效地規避、降低企業信息化的各種風險。

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

4）經濟性。始終考慮成本投入與產出的關系問題，降低成本，科學地確定信息化建設的投資，用較少的資金做更多的事情。依據信息化建設的目標和全局架構，避免無效投資、重復投資等。

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

6）挖掘潛在的應用系統。

3.邏輯模型是與實施無關的模型。他描述了系統的本質，即系統必須做什么，而與系統是如何實施的無關。也就是說，邏輯模型是用來描述數據的內容及處理功能的，而不關心這些功能是如何實現的。其優點是：

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

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

3）邏輯模型可以使系統開發人員以非技術語言或盡可能少的技術語言與最終用戶進行交流。

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

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

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

3）數據服務層主要提供對數據庫進行各種操作的方法。它主要由中間業務層來調用比昂完成業務邏輯，當數據庫的結構確定后，對于它的改動也就比較小了。

4）系統的安全性得以提高。它可以對每個業務功能組件進行授權，限制了非法訪問。

5）便于進行事務管理。