使用案例圖的方法是Ivar Jacobson於1994年發明了。使用者案例是使用者觀點來看模形化的軟體設計，這是以目標為導向的模型設計。使用者案例可以幫助辨別系統服務。 透過使用案例可以描述系統的行為者與系統間之互動行為與關係
使用案例圖的方法是Ivar Jacobson於1994年發明了。使用者案例是使用者觀點來看模形化的軟體設計，這是以目標為導向的模型設計。使用者案例可以幫助辨別系統服務。 透過使用案例可以描述系統的行為者與系統間之互動行為與關係。從內部觀點來看，使用個案可描述系統做什麼 (What)；從外部觀點來看，可描述行為者與系統如何互動 (How) 。使用者案例可以被進一步被解構成小的使用者案例。
為什麼要使用Use Case 呢?
1.使用Use Case可幫助專案的成員了解這個系統到底是在作什麼。
2.界定系統的範圍有多大。
3.有多少相關外部界接系統。
4.有多少角色會使用這個的系統。
5.系統會提供哪些功能給哪些角色使用。
Use Case的圖形(Element)
Actor : 表示此使用者案例的參與者，通常一個Use Case最少會有一個參與者。也表示『動作／互動』的發生點，参與者為系統中的角色、動作者，但不一定都是人(Human)，也可以是其它的系統或設備。
Use Case : 一種表示法，表示為一個事物，可能是靜態、動態的，或指一件事情，一個系統，或一個工作。
這是參與者與使用者案例有者關係。這條關係線是沒有箭頭，因此為雙向關係，如果有箭頭則表示是單向關係。
這是包含(include)的關係，如下圖，風險分析的使用者案例包含了評估使用者案例。包含是使用虛線，箭頭指向的是被包含的使用者案例。
下面再來看一個較簡單的案例。一個買菜的Use Case，這個Use Case我們可以這樣來解釋：在買菜的這個Use Case中有一個參與者為『家庭主婦』，『家庭主婦』會去做買菜這件事，而買菜這件事包含了『挑選新鮮的』與『結帳』這兩件事情。
解構使用者案例
通常使用者案例會依照某些需求再詳畫出更細部的使用者案例，如下：
使用Use Case 好處還有就是界定系統的分界，以及避免過早陷入細節的部分 (這通常是Developer最常犯的毛病)，如此才能分出系統實際上的內部與外部，這非常重要，這樣才能分出什麼該做，什麼不該做！也較容易表示出此Use Case是屬於什麼層次 (LEVEL)，是企業層級 (Business Level)，還是使用者層級 (Use goal Level)。所以，如果Use Case 沒有界定出好的系統範圍的話，通常需求分析一定做不好。
再拿出最常被拿出來講的範例，百事達租片系統：
既然是租片系統，這個Use Case 顯然界定的相當模糊，雖然顧客也確實會進行租片與還片等動作，但是想想看，百X達是一個提供租片的場所，此場所會有工作人員，且試想租片這個動作才是系統實際會進行的動作，這可能包含了百X達內部的進銷存系統，當然，可能沒有賣這個動作，但是片子租出去後一定會扣掉一個數量，待顧客還片後才會加回來。因為我們要開發的百X達的影片租借系統，這個時候這個Use Case 的實際參與者應該就不是顧客了，應該是百事達的店員才對！這個時候應該是下面這個處理租片這個Use Case 了。
簽名：
學習是一趟奇妙的旅程
這當中，有辛苦、有心酸、也有成果。有時也會有瓶頸。要能夠繼續勇往直前就必須保有一顆最熱誠的心。
軟體開發之路（FB 社團）：https://www.facebook.com/groups/361804473860062/
Gelis 程式設計訓練營（粉絲團）：https://www.facebook.com/gelis.dev.learning/
如果文章對您有用，幫我點一下讚，或是點一下『我要推薦』，這會讓我更有動力的為各位讀者撰寫下一篇文章。
非常謝謝各位的支持與愛護，小弟在此位各位說聲謝謝!!! ^_^
