iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 0
1
自我挑戰組

30天認識軟體設計及架構系列 第 3

Day 3 軟體設計及架構---Use Case Diagram

第一大類要介紹的是行為圖(Behavior Diagram),強調系統模型中觸發的事件、行動,在這個類組中有 Use Case Diagram、Activity Diagram、State Machine Diagram、Interaction Diagram。其中我會介紹比較重要的 Use Case Diagram 和 Activity Diagram。

第一種要介紹的是 Use Case Diagram,Use Case Diagram 主要是描述一個系統或類別提供給外界交互作用者的功能。它以外部觀察者角度來描述觀察到的系統功能,強調系統能作什麼事,而不是如何作這些事,簡而言之就是說明一個系統的功能及使用者。

使用者案例圖可以讓我們知道有那些需求,每增加一種使用案例就代表有新的需求,而使用者案例圖也是依照客戶角度來觀察系統,他不需要深奧的程式技巧,也不需要了解物件導向的概念,是一種開發者易於和客戶溝通的工具,另外這種圖形也可以讓我們產生測試案例,記得之前曾經應徵過一間公司,他的職位雖然是寫工程師,但是詳細了解過後才知道他只是要一位負責想 Use Case 的員工,不需要負責任和程式設計,只需要對他們的產品發想 Use Case 好讓開發的工程師去了解需要哪些 Test Case,當時我才了解到原來開發產品不是只要會 Coding 而已,不過因為當時我實習是想要精進的是我的 Coding 能力,所以就拒絕了這份工作,這又是後話了哈哈!!

OK,開始介紹 Use Case Diagram~
Use Case Diagram 中只有兩種腳色,其一是參與者(Actor),其二則是使用案例(Use case)

參與者所代表的是一個角色,例如 : 會計師、顧客、服務生等等,並非是一個個體,當然參與者也可以是一個系統,例如資料庫系統
https://ithelp.ithome.com.tw/upload/images/20191002/20111858DGTicC2Cym.jpg

例如: 廚房裡有三個廚師,前台有五個客人,雖然總共有八個人,但是實際上只有兩種腳色,廚師和客人。

再來是 「使用案例」,也可以看作是一種情節,通常使用案例的符號是用橫的橢圓形表示,而使用案例從字面上的意思可以視為「使用者行為的描述」,例如上面的例子有顧客和廚師,則使用案例可以有「煮菜」、「切菜」、「點餐」、「吃飯」等等行為,當然煮菜、切菜對應到廚師這個角色,點餐吃飯則對應到顧客,下面的圖就是 Use Case Diagram 的例子。
https://ithelp.ithome.com.tw/upload/images/20191002/20111858XeSuZgUaW5.jpg

可以看到圖中的參與者有「美食評論家」和「廚師」,而使用案例有四種,吃飯、付錢、喝酒、煮飯,前三種當然對應到美食評論家,而煮飯就是廚師的行為。

從上面的圖我們還可以看到在使用案例和使用者之間是用線來連接,這是一條沒有方向性的線,代表參與者參與使用案例,並不表示之間有任何資訊交換。

另外圍住 Restaurant 的矩形框框就是系統邊界(System Boundaries),用來明確標示系統的範圍,參與者則會在邊界之外。

除了以上對於圖形的基本介紹之外,使用者案例圖還有一些特性,例如包含(Include),以及延伸(extend)關係。

包含關係可以讓我們在使用案例重複使用其他使用案例,類似程式的程序與函數, 可以讓多個使用案例包含同一個使用案例的行為或功能。例如: 買票這個使用案例,之中也包含著付錢這個行為。

延伸關係是在某些情況或條件下, 可以延伸現有使用案例的行為或功能。延伸關係並不會影響原來的使用案例,只是增加一些選項的行為或功能,例如: 買東西時店員常會問你說需不需要統編,這時你可以選擇要或不要,這並非強制性,是可以選擇的。

我想這篇的篇幅也有點長了,太多的話應該也很難有耐心看完哈哈,畢竟我也是專注力不太夠,所以希望能用很簡短白化的方式讓大家吸收到知識、觀念,也盡可能讓大家夠利用短短的五分、十分鐘的時間就把我的文章閱讀完!

敬請期待明天囉,一樣會繼續介紹 UML 的其他種圖形。


上一篇
Day 2 軟體設計及架構---UML 入門
下一篇
Day 4 軟體設計及架構---Class Diagram
系列文
30天認識軟體設計及架構10

尚未有邦友留言

立即登入留言