jude-用例图概述

原文：http://www.dotblogs.com.tw/jimmyyu/archive/2010/01/18/use-case-diagram.aspx

本篇主要針對Use Case Diagram 的目的、撰寫注意事項、Use Case不做哪些事情做些說明。

目的
Use Case Diagram 主要是為了增進我們與客戶間的需求雜訊，避免客戶的期望與系統分析師的認知有落差，之前有寫過一篇文章，其實Use Case Diagram 是解決此問題一個很好的方法：[系統分析]談談需求分析(RA)

Use Case Diagram主要是描述一個系統或類別提供給外界之交互作用者的功能。簡單來說就是說明一個系統的功能及其使用者。

Use Case透過很簡單的表達方式，讓我們可以較輕易的向客戶確認需求，以下說明一下Use Case如何撰寫。

撰寫注意事項
Use Case Diagram非常單純，主要分為以下兩個部分：

• Actor：代表使用者與系統使用案例互動的代表，一般而言角色可為：人(human)、硬體設備(hardware device)、其他系統，而非只針對人而已。
• Use Case：使用案例描述系統要完成的成果，而不是如何進行，通常Use Case是一個動作，例如：儲存資料、加入會員等等…

 
如果以jude這套UML工具來說，Actor與Use Case的圖示分別如下，非常簡單且可愛。

 

在VS2010中則分別是：

 

簡單的Use Case範例如下，代表了兩個Use Case，其中一個是Customer觸發了Browse Web Site的Use Case，另一個則是Customer觸發了Buy Merchandise的動作，從這樣的範例中，我們就可以跟客戶說，一個Customer對我們網路購物車，最少會有這兩個可能的Use Case，並詢問客戶是否還有其他動作需要再加的。

上圖中Actor與Use Case間的連接線，我們稱為連結(Association)，它表現出參與者(Actor)與系統使用案例之間的溝通 (communicate )，可以在雙方之間傳送及接收訊息(Message)，其他相關的關連還有：

• Extends：單一Use Case的功能被選擇性地插入到叧一個 Use Case，如下例，客戶瀏覽網站不見得會購買商品。

• Includes：單一Use Case的功能完全包含到叧一個 Use Case，如下例，要寄出訂購的商品前，一定要先填寫訂單才行。

 

不過以上兩個我們儘量少用，避免我們的Use Case Diagram過度分支而複雜，原則上我們撰寫的Use Case一定要讓客戶跟開發人員都能看懂，否則這個Use Case就不是一個好的Use Case了。

Use Case不做的事情
Use Case並不是將所有的需求都描述進去，以下幾項是不會在Use Case中被撰寫的：

• Implementation details：不要描述實作細節，只講概要功能就好，例如不要說明資料將被存到Oracle資料庫，而說資料將被儲存就好。
• GUI Information：不要講UI上的內容，例如按下『存檔』按鈕，避免到時候畫面作多國語言時，我們還要將Use Case改成多語內容。
• Internal processing unrelated to a stakeholder request：不要講與使用者無關的系統內部作業，這一點跟第一項很像，就是不用講過多的邏輯內容在裡頭。
• Non-functional requirements：不要講非功能性需求，例如系統每個操作要在2秒內回應，同時上線人數要達3000人等。

 
Use Case Diagram本身並不複雜，最困難的還是在識別出系統的關鍵人員(Actor)跟關鍵應用(Use Case)，只要找出這兩者，圖很快就可以畫出來，並跟客戶做確認了，若有興趣討論這部分我可以再分享一下。

--------------------------------------------------------------------------------------------------------------------------------

原文：https://kb.cnblogs.com/page/129491/ 

用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

　　【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。

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

　　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这些文档。但为什么不把这些功能直接集成到用例里面，双击用例就弹出一份文档岂不更容易理解，非要画蛇添足地加一个元件，仅仅为了提供个链接功能。 

　　用例描述表：

　　鉴于用列图并不能清楚地表达功能需求，开发中大家通常用描述表来补充某些不易表达的用例，下图的表给大家提供一个参考：