第一篇：UML用例圖總結

UML用例圖

用例圖主要用來圖示化系統的主事件流程，它主要用來描述客戶的需求，即用戶希望系統具備的完成一定功能的動作，通俗地理解用例就是軟件的功能模塊，所以是設計系統分析階段的起點，設計人員根據客戶的需求來創建和解釋用例圖，用來描述軟件應具備哪些功能模塊以及這些模塊之間的調用關系，用例圖包含了用例和參與者，用例之間用關聯來連接以求把系統的整個結構和功能反映給非技術人員（通常是軟件的用戶），對應的是軟件的結構和功能分解。

用例是從系統外部可見的行為，是系統為某一個或幾個參與者（Actor）提供的一段完整的服務。從原則上來講，用例之間都是獨立、并列的，它們之間并不存在著包含從屬關系。但是為了體現一些用例之間的業務關系，提高可維護性和一致性，用例之間可以抽象出包含(include)、擴展(extend)和泛(generalization)幾種關系。

共性：都是從現有的用例中抽取出公共的那部分信息，作為一個單獨的用例，然后通后過不同的方法來重用這個公共的用例，以減少模型維護的工作量。

1、包含(include)

包含關系：使用包含（Inclusion）用例來封裝一組跨越多個用例的相似動作（行為片斷），以便多個基（Base）用例復用。基用例控制與包含用例的關系，以及被包含用例的事件流是否會插入到基用例的事件流中。基用例可以依賴包含用例執行的結果，但是雙方都不能訪問對方的屬性。

包含關系對典型的應用就是復用，也就是定義中說的情景。但是有時當某用例的事件流過于復雜時，為了簡化用例的描述，我們也可以把某一段事件流抽象成為一個被包含的用例；相反，用例劃分太細時，也可以抽象出一個基用例，來包含這些細顆粒的用例。這種情況類似于在過程設計語言中，將程序的某一段算法封裝成一個子過程，然后再從主程序中調用這一子過程。

例如：業務中，總是存在著維護某某信息的功能，如果將它作為一個用例，那新建、編輯以及修改都要在用例詳述中描述，過于復雜；如果分成新建用例、編輯用例和刪除用例，則劃分太細。這時包含關系可以用來理清關系。

2、擴展(extend)擴展關系：將基用例中一段相對獨立并且可選的動作，用擴展（Extension）用例加以封裝，再讓它從基用例中聲明的擴展點（Extension Point）上進行擴展，從而使基用例行為更簡練和目標更集中。擴展用例為基用例添加新的行為。擴展用例可以訪問基用例的屬性，因此它能根據基用例中擴展點的當前狀態來判斷是否執行自己。但是擴展用例對基用例不可見。對于一個擴展用例，可以在基用例上有幾個擴展點。

例如，系統中允許用戶對查詢的結果進行導出、打印。對于查詢而言，能不能導出、打印查詢都是一樣的，導出、打印是不可見的。導入、打印和查詢相對獨立，而且為查詢添加了新行為。因此可以采用擴展關系來描述：

4、泛化(generalization)泛化關系：子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。在實際應用中很少使用泛化關系，子用例中的特殊行為都可以作為父用例中的備選流存在。

例如，業務中可能存在許多需要部門領導審批的事情，但是領導審批的流程是很相似的，這時可以做成泛化關系表示：

上面是我參考的一篇文章，覺得將三種關系的區別講得很清晰，在此基礎上結合自己的系統，對項目(在線購物系統)的用例做了整體的描繪。

*****************************************************************

(1)系統整體用例圖

(商品用例圖)

（購買信息用例）

(用戶資料用例)

按照先整體用例，后子系統用例來進行描繪的，歡迎大家提出好的建議!

轉：UML中擴展和泛化的區別

泛化表示類似于OO術語“繼承”或“多態”。UML中的Use Case泛化過程是將不同Use Case之間的可合并部分抽象成獨立的父Use Case，并將不可合并部分單獨成各自的子Use Case；包含以及擴展過程與泛化過程類似，但三者對用例關系的優化側重點是不同的。如下：

●泛化側重表示子用例間的互斥性；

●包含側重表示被包含用例對Actor提供服務的間接性；

●擴展側重表示擴展用例的觸發不定性；詳述如下：

既然用例是系統提供服務的UML表述，那么服務這個過程在所有用例場景中是必然發生的，但發生按照發生條件可分為如下兩種情況：

⒈無條件發生：肯定發生的；

⒉有條件發生：未必發生，發生與否取決于系統狀態；

因此，針對用例的三種關系結合系統狀態考慮，泛化與包含用例屬于無條件發生的用例，而擴展屬于有條件發生的用例。進一步，用例的存在是為Actor提供服務，但用例提供服務的方式可分為間接和直接兩種，依據于此，泛化中的子用例提供的是直接服務，而包含中的被包含用例提供的是間接服務。同樣，擴展用例提供的也是直接服務，但擴展用例的發生是有條件的。

另外一點需要提及的是：泛化中的子用例和擴展中的擴展用例均可以作為基本用例事件的備選擇流而存在。

第二篇：Uml用例圖心得（精選）

Uml用例圖心得

序言：用例圖主要用來描述“用戶、需求、系統功能單元”之間的關系。它展示了一個外部用戶能夠觀察到的系統功能模型圖。

【用途】：幫助開發團隊以一種可視化的方式理解系統的功能需求。

用例圖所包含的元素如下：

1.參與者(Actor)

表示與您的應用程序或系統進行交互的用戶、組織或外部系統。用一個小人表示。

2.用例(Use Case)

用例就是外部可見的系統功能，對系統提供的服務進行描述。用橢圓表示。

3.子系統(Subsystem)

用來展示系統的一部分功能，這部分功能聯系緊密。

4.關系

用例圖中涉及的關系有：關聯、泛化、包含、擴展。

如下表所示：

a.關聯(Association)

表示參與者與用例之間的通信，任何一方都可發送或接受消息。

【箭頭指向】：指向消息接收方

b.泛化(Inheritance)

就是通常理解的繼承關系，子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。

【箭頭指向】：指向父用例

c.包含(Include)

包含關系用來把一個較復雜用例所表示的功能分解成較小的步驟。

【箭頭指向】：指向分解出來的功能用例

d.擴展(Extend)

擴展關系是指用例功能的延伸，相當于為基礎用例提供一個附加功能。

【箭頭指向】：指向基礎用例

e.依賴(Dependency)

以上4種關系，是UML定義的標準關系。但VS2010的用例模型圖中，添加了依賴關系，用帶箭頭的虛線表示，表示源用例依賴于目標用例。

【箭頭指向】：指向被依賴項

5.項目(Artifact)

用例圖雖然是用來幫助人們形象地理解功能需求，但卻沒多少人能夠通看懂它。很多時候跟用戶交流甚至用Excel都比用例圖強，VS2010中引入了“項目”這樣一個元素，以便讓開發人員能夠在用例圖中鏈接一個普通文檔。

用依賴關系把某個用例依賴到項目上：

然后把項目-》屬性 的Hyperlink設置到你的文檔上；

這樣當你在用例圖上雙擊項目時，就會打開相關聯的文檔。

6.注釋(Comment)

包含(include)、擴展(extend)、泛化(Inheritance)的區別：

條件性：泛化中的子用例和include中的被包含的用例會無條件發生，而extend中的延伸用例的發生是有條件的；

直接性：泛化中的子用例和extend中的延伸用例為參與者提供直接服務，而include中被包含的用例為參與者提供間接服務。

對extend而言，延伸用例并不包含基礎用例的內容，基礎用例也不包含延伸用例的內容。

對Inheritance而言，子用例包含基礎用例的所有內容及其和其他用例或參與者之間的關系；

一個用例圖示例：

第三篇：(用例圖)Use Cases總結

用例圖主要用來描述“用戶、需求、系統功能單元”之間的關系。它展示了一個外部用戶能夠觀察到的系統功能模型圖。

【用途】：幫助開發團隊以一種可視化的方式理解系統的功能需求。

用例圖所包含的元素如下：

1.參與者(Actor)

表示與您的應用程序或系統進行交互的用戶、組織或外部系統。用一個小人表示。

2.用例(Use Case)

用例就是外部可見的系統功能，對系統提供的服務進行描述。用橢圓表示。

3.子系統(Subsystem)

用來展示系統的一部分功能，這部分功能聯系緊密。

4.關系

用例圖中涉及的關系有：關聯、泛化、包含、擴展。

如下表所示：

a.關聯(Association)

表示參與者與用例之間的通信，任何一方都可發送或接受消息。

【箭頭指向】：指向消息接收方

b.泛化(Inheritance)

就是通常理解的繼承關系，子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。

【箭頭指向】：指向父用例

c.包含(Include)

包含關系用來把一個較復雜用例所表示的功能分解成較小的步驟。

【箭頭指向】：指向分解出來的功能用例

d.擴展(Extend)

擴展關系是指用例功能的延伸，相當于為基礎用例提供一個附加功能。

【箭頭指向】：指向基礎用例

e.依賴(Dependency)

以上4種關系，是UML定義的標準關系。但VS2010的用例模型圖中，添加了依賴關系，用帶箭頭的虛線表示，表示源用例依賴于目標用例。

【箭頭指向】：指向被依賴項

5.項目(Artifact)

用例圖雖然是用來幫助人們形象地理解功能需求，但卻沒多少人能夠通看懂它。很多時候跟用戶交流甚至用Excel都比用例圖強，VS2010中引入了“項目”這樣一個元素，以便讓開發人員能夠在用例圖中鏈接一個普通文檔。

用依賴關系把某個用例依賴到項目上：

然后把項目-》屬性 的Hyperlink設置到你的文檔上；

這樣當你在用例圖上雙擊項目時，就會打開相關聯的文檔。

6.注釋(Comment)

包含(include)、擴展(extend)、泛化(Inheritance)的區別：

條件性：泛化中的子用例和include中的被包含的用例會無條件發生，而extend中的延伸用例的發生是有條件的；

直接性：泛化中的子用例和extend中的延伸用例為參與者提供直接服務，而include中被包含的用例為參與者提供間接服務。

對extend而言，延伸用例并不包含基礎用例的內容，基礎用例也不包含延伸用例的內容。

對Inheritance而言，子用例包含基礎用例的所有內容及其和其他用例或參與者之間的關系；

一個用例圖示例：

牢騷：

感覺用例圖還不成熟，并不能很好地表達系統的需求，沒有UML背景的用戶幾乎不知道畫的是些什么。

其次，包含關系、擴展關系的箭頭符號竟然是同樣的箭頭，僅靠上方寫個文字來加以區別，翻譯成其他語言的話，幾乎就不知道代表什么意思。擴展關系的箭頭朝向也很難理解，為何要指向基用例，而不指向擴展用例。

VS2010添加的“項目”元素，是個很好的創新，能夠在用例圖中關聯word, excel這些文檔。但為什么不把這些功能直接集成到用例里面，雙擊用例就彈出一份文檔豈不更容易理解，非要畫蛇添足地加一個元件，僅僅為了提供個鏈接功能。

用例描述表：

鑒于用列圖并不能清楚地表達功能需求，開發中大家通常用描述表來補充某些不易表達的用例，下圖的表給大家提供一個參考：

第四篇：UML類圖幾種關系的總結-tf

UML類圖幾種關系的總結

在UML類圖中，常見的有以下幾種關系: 泛化（Generalization）, 實現（Realization），關聯（Association)，聚合（Aggregation），組合(Composition)，依賴(Dependency)1.泛化（Generalization）

【泛化關系】：是一種繼承關系，表示一般與特殊的關系，它指定了子類如何特化父類的所有特征和行為。例如：馬是動物的一種，即有馬的特性也有動物的共性。

【箭頭指向】：帶三角箭頭的實線，箭頭指向父類

2.實現（Realization）

【實現關系】：是一種類與接口的關系，它表示不繼承結構而只繼承行為，是類與接口之間最常見的關系。準確的說，類不是繼承(inherit)接口，而是實現(implement)接口。

【箭頭指向】：UML中用帶三角箭頭的虛線，箭頭指向接口

3.關聯（Association)

【關聯關系】：是一種擁有的關系，它使一個類知道另一個類的屬性和方法；如：老師與學生，丈夫與妻子關聯可以是雙向的，也可以是單向的。雙向的關聯可以有兩個箭頭或者沒有箭頭，單向的關聯有一個箭頭。

【代碼體現】：成員變量

【箭頭及指向】：單向關聯為帶普通箭頭的實心線，箭頭指向被擁有者，如下圖

上圖中，老師與學生是雙向關聯，老師有多名學生，學生也可能有多名老師。但學生與某課程間的關系為單向關聯，一名學生可能要上多門課程，課程是個抽象的東西他不擁有學生。

4.聚合（Aggregation）【聚合關系】：是整體與部分的關系，且部分可以離開整體而單獨存在。如車和輪胎是整體和部分的關系，輪胎離開車仍然可以存在。

聚合關系是關聯關系的一種，是強的關聯關系；關聯和聚合在語法上無法區分，必須考察具體的邏輯關系。

【代碼體現】：成員變量

【箭頭及指向】：帶空心菱形的實心線，菱形指向整體

5.組合(Composition)

【組合關系】：是整體與部分的關系，但部分不能離開整體而單獨存在。如線段和點是整體和部分的關系，沒有點就不存在線段。

組合關系是關聯關系的一種，是比聚合關系還要強的關系，它要求普通的聚合關系中代表整體的對象負責代表部分的對象的生命周期。【代碼體現】：成員變量

【箭頭及指向】：帶實心菱形的實線，菱形指向整體

6.依賴(Dependency)

【依賴關系】：是一種使用的關系，即一個類的實現需要另一個類的協助，所以要盡量不使用雙向的互相依賴.【依賴擴展】：Trufun Plato工具根據實際開發中的需要，在工具箱還提供兩個預定義的依賴：許可(permission)依賴和使用(usage)依賴。

? 許可依賴（通常作為特定的構造類型）將包或者類與另一個允許它使用某些內容的包或者類相連。許可依賴關系的構造類型有訪問、友元、輸入。

? 使用依賴關系（關鍵字《use》）將客戶元素與服務者元素相連。服務者的變化將導致客戶的變化。使用通常表示一種實現的依賴關系，其中的一個元素依靠另一個元素的服務來實現自身的操作。使用的構造類型包括調用、實例（關鍵字《instantiate》）、參數、發送。

【代碼表現】：局部變量、方法的參數或者對靜態方法的調用

【箭頭及指向】：帶箭頭的虛線，指向被使用者

各種關系的強弱順序：

泛化 = 實現 > 組合 > 聚合 > 關聯 > 依賴

下面這張UML圖，比較形象地展示了各種類圖關系： UML因其簡單、統一的特點，而且能表達軟件設計中的動態和靜態信息，目前已成為可視化建模語言的工業標準。

好處：幫助開發團隊以一種可視化的方式理解系統的功能需求，UML為交流面向對象的設計中的需求，行為、體系結構以及最后實現提供了一套綜合的表示法。

1，UML統一了各種方法對不同類型的系統、不同開發階段以及不同內部概念的不同觀點，從而有效的消除了各種建模語言之間不必要的差異。

2，UML建模能力比其它面向對象建模方法更強。它不僅適合于一般系統的開發，而且對并行、分布式系統的建模尤為適宜。

3，使用UML使硬件組件和軟件組件之間將會有更大的透明度。便攜性和綜合效率將會增加。

我們會編程只是實現的能力，而我們會進行UML建模，則是從全局出發設計和管理的能力。

Trufun致力于軟件工程全過程解決方案，提供從需求到測試的完整跟蹤過程，愿與各方進行科研、開發等方面的合作。

第五篇：uml實驗三 構建類圖

實驗三 構建類圖

【實驗目的】

1.理解類的基本概念 2.理解類間的關系 3.掌握類圖的繪制方法

4.掌握簡單的類圖設計方法

【實驗器材】

1.計算機一臺；

2.Rational Rose 工具軟件；

【實驗內容】

【題目一】

分析選課系統中的類及關系，然后畫出它們的類圖。

1）.分析

在選課系統中，通過分析可抽象出如下幾個類：（1）學生類（2）管理員類（3）課程類

學生類和管理員類的屬性較容易分析，這里只列出課程類的屬性和方法：（1）課程名稱（2）開課教室（3）課程號（4）授課教師（5）選課的學生（6）開課起始時間

（7）允許選課的學生人數（8）設置課程號（9）設置課程名稱（10）查詢課程號

（11）查詢允許選課的學生人數 2）繪圖步驟

下面介紹在Rose2003中創建類和它們之間關系的過程：

（1）在“Logical View“中雙擊Main圖，或者右擊“Logical View“，彈出在快捷菜單中選擇“New”－>“Class Diagram”，雙擊圖標，出現圖2.1，為編輯類圖做好準備。

圖2.1（2）在邏輯視圖中，從工具欄中選擇class圖標，在右邊的繪圖區中添加一個新元素，并取名Student表明新增一個類，如圖2.2所示。

圖2.2（3）選擇新創建的元素，點擊鼠標右鍵，在彈出的菜單中選擇“Open Sepcification”,彈出圖2.3對話框。

（4）在對話框中，可以修改元素的名稱，這里新元素的名稱定為“Student”，如圖2.4所示。

圖2.3

圖2.4（5）點擊“Attributes”選項卡，添加屬性，如圖2.5所示。

圖2.5（6）點擊“operations”選項卡，添加方法如圖2.6所示。

圖2.6（7）同樣的方法添加Course類，如圖2.7所示。

圖2.7（8）創建兩個類之間的關系，通過分析得出：學生類和課程類之間為單向關聯。選擇圖標欄的“關聯”，由學生類指向課程類。如圖2.8所示。

圖2.8（9）創建關聯名。右擊關聯，選擇“open specification“，鍵入關聯名（select），如圖2.9所示。

圖2.9（10）分別在“Role A Detail“和“Role B Detail“選項卡中鍵入名稱和多重性，如圖2.10所示。

圖2.10（11）重復（2）－（10）中的步驟完成選課系統整個類圖的創建。（12）如圖2.11轉換生成代碼，查看所生成的三個的代碼。

圖2.11

【題目二】

已知三個類A、B和C，其中類A由類B的一個實例類和類C的1個或多個實例類構成，請畫出能夠正確表示類A、B和C之間關系的UML類圖。

【題目三】

根據以下描述畫出類圖，并注明多重性關系：一個學生可以選修多門課程，也可能沒有任何課程；一門課程可以被多個學生選修；一個老師可以教多門課程或者不教課；每門課程至少有一個老師，也可以有多個老師任教；每門課程可以有0或1本教材，每本教材只能用于一門課程。

【題目四】

根據下面的代碼畫出Invoice類的類圖，要求標明各屬性的類型和可見性以及類方法。

public class Invoice { public double amount;public Date date = new Date();public string customer;public string specification;public string administrator = “unspecified”;static private int number_of_invoices=0;public invoice（）{

number_of_invoices++； } public void print（）

{ System.out.println("The number of invoices is ”+ number_of_invoices);} }

【題目五】

下圖是一個倉庫管理系統的類模型局部，其中IncomeOrder是指入庫單，OrderItem是指入庫中的每一項，Product則是產品信息。請指出模型中的錯誤，說明原因并改正類圖。

IncomeOrder11ProductOrderItem

【題目六】

（1）現有一系統需要對商品進行管理，包括添加，刪除商品，修改商品信息三項功能，畫出系統類圖。（商品信息包括商品編號，商品名稱，價格，生產廠商等）

（2）如果現在系統需求發生變化，需要能夠對損壞商品進行打折，以及可以按照商品的顏色和外形進行查詢，則系統類圖應該如何修改？

【實驗報告要求】

1． 整理實驗結果。

2． 小結實驗心得體會。

3.所有題目以doc文檔或Rose文檔形式上傳到服務器，而實驗報告中只需寫題目五和題目六。