產品經理必學UML(二):用例圖

17 評論 73518 瀏覽 312 收藏 11 分鐘

上一篇中介紹了UML中的類圖,本篇筆者將與大家介紹UML中的用例圖的三個方面內容:用例(Use Case); 參與者(Actor); 參與者、用例之間的關系。

用例圖(Use Case Diagrame):描述了人們希望如何使用一個系統,將相關用戶、用戶需要系統提供的服務以及系統需要用戶提供的服務更清晰的顯示出來,以便使系統用戶更容易理解這些元素的用途,也便于開發人員最終實現這些元素。

之所以說用例圖至關重要,是由于用戶并不關心系統的實現和內部結構,只關心產品所呈現出來的外部特征動態。而用例圖恰好就是描述軟件產品外部特性的視圖,它從用戶的角度而不是從開發者的角度來描述需求,分析產品的功能和動態行為。

用例圖包括三方面內容:用例(Use Case); 參與者(Actor); 參與者、用例之間的關系。用例圖模型如下圖所示,參與者用人形圖標顯示,用例用橢圓形表示,連線描述之間的關系。

一、參與者(Actor)

1. 概念

參與者是系統外部的一個實體,它以某種方式參與了用例的執行過程,在UML中,通常用名字寫在下面的人形圖標表示。

值得注意的是:參與者不一定是人,也可以是任何的事,通??梢詫⑴c者分為以下三類:

1)真實的人,即用戶

這一類是最常用的參與者,幾乎在每個系統中。在命名這一類參與者時,應該按照業務而不是位置命名,因為一個人有可能有多重身份。

比如:汽車租賃公司的客戶服務代表,通常情況下是客戶服務代表,但在她有租賃行為時,就變成了客戶。因此,按照業務而不是位置命名可以獲得更加穩定的參與者。

2)其他的系統

在有的系統中,還需要建立與其他系統的接口,依然以汽車租賃系統為例,它可能要與外部應用程序建立練習,比如:說外部信用卡應用程序,這時候外部信用卡應用系統就是一個參與者。

3)可運行的進程

以時間為例,當經過一定時間觸發系統中的某個時間時,時間就成了參與者。比如:在汽車租賃系統中,到了還車時間客戶仍未歸還,系統便會提醒客戶代表致電客戶。由于時間不再在人的控制內,因此它也是一個參與者。

2. 參與者間的關系

對于一些參與者來說,它既扮演者自己的角色,同時也扮演更一般的角色,在案例圖中用泛化關系來描述他們(此點與上一節類圖中介紹的泛化關系類似)。

假設汽車租賃系統可以接受客戶的電話預定和網上預訂,那么參與者“客戶”就描述了參與者“電話客戶”和“網上用戶”所扮演的一般角色。泛化關系與類圖一樣都使用一個空心三角箭頭表示,指向扮演一般角色的超類。

在確定參與者當中,如果不考慮客戶是如何與系統接觸的,就使用一般角色參與者,即父類;如果強調接觸發生的形式,則必須采用實際的參與者,即子類。

二、用例(Use Case)

1. 概念

用例:是對系統的用戶需求(主要是功能需求)的描述,用例表達了系統的功能和所提供的服務,描述了活動者與系統交互中的對話。

以汽車租賃系統為例,客戶向系統發出租賃請求,并向系統中輸入數據(姓名等信息),系統響應活動者的請求,進行相應的處理,并且將結果返回活動者。

每個用例都必須有一個唯一的名字以示區別,用例名字是一個字符串,包括簡單名(simple)和路徑名(path name),這和類圖中的類名是相同的。

左圖:簡單名/右圖:路徑名

2. 用例與事件流

用例分析處于系統的需求分析階段,這個階段盡量避免考慮系統實現的細節問題。但若要建立系統還需要更加具體的細節,這些細節可以寫在事件流中。

事件流描述的是一個系統做什么,而不是怎么做,舉個栗子,在汽車租賃系統中用例“用戶登錄”可以采取一下方法:

  • 主事件流:客戶輸入自己的用戶名和密碼時,用戶開始。輸入的用戶名和密碼被提交后,服務器判斷密碼是否正確。如果正確,則用戶成功登錄,系統為其展示租賃頁面。
  • 異常事件流:用戶用戶名或密碼錯誤,不能登錄,用例重新開始。
  • 異常事件流:在提交密碼前,用戶清楚用戶名或密碼,重新填寫。

三、參與者、用例之間的關系

1. 關聯關系

這是最常使用的關系,用帶箭頭的實線來描述。以汽車租賃系統中的“客戶”參與這以及和他交互的3個用例(預定、取車和換車)為例。

2. 泛化關系(Generalization)

一個用例可以被列舉為多個子用例,這就被成為用例泛化,這與類間的泛化關系類似。在用例泛化中,子用例表示父用例的特殊形式,可從父用例處繼承行為和屬性。泛化關系的圖形用空心實線箭頭表示,箭頭指向父類。

如下圖所示是汽車租賃公司用例圖中的用例“預定汽車”,該用例有兩個子用例“預定大巴中巴”和“預訂小車”。

3. 包含關系(Include)

包含:指的是其中一個用例(稱為基礎用例)的行為包含了另一個用例(稱為包含用例)。

基礎用例包含用例并依賴包含用例的執行結果。但是二者不能訪問對方的屬性。包含關系的圖形為虛線箭頭加<<include>>,箭頭指向包含用例。

再舉個栗子:仍然是汽車租賃系統,客戶無論是預定、取車還是還車,都需要用戶登錄,所有此時使用例“登錄”被用例“預定”、“取車”和“還車”所包含,這樣就能避免許多重復的動作。

4. 擴展關系(Extend)

擴展用例可以被定義為:基礎用例的增量擴展,它倆之間為擴展關系。

簡單來說,就是當某特定條件出現時,該擴展用例的行為才會被執行。擴展關系的圖形為虛線箭頭加上<<<exclude>>>,箭頭指向基礎用例。

如下圖,客戶在還車超過了一定期限就需要繳納罰款,其中“借車超期”為特定條件,只有該條件出現,才執行“繳納罰款”用例行為,“還車”用例和“繳納罰款”之間就是擴展關系。

四、練習:QQ音樂用戶及其相關用例(簡易版)

  • 其中參與者【用戶】可以泛化為QQ用戶與微信用戶。
  • 【建立歌曲列表】用例包含了【聽歌】和【登錄】用例,因為必須要先登錄才能在聽歌頁面添加到歌曲列表中。
  • 在【聽歌】用例中,有1個擴展點,是有的收費歌曲需要購買才能收聽,其中歌曲收費為特定條件。

相關閱讀

《產品經理必學UML(一):類圖》

 

本文由 @AugTalk 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. Extend箭頭方向都畫錯了,嚴重誤導,還這么多收藏

    來自廣東 回復
  2. 你能不能不要胡寫?include關系也寫錯了,extend也寫錯了,統共也沒幾個關系,亂寫八道,誤導人?。。。。。。。?!

    來自上海 回復
    1. 哈哈哈

      回復
    2. 我也發現了,,

      來自福建 回復
    3. 這何止誤導,簡直是草菅人命,因為畫用例前需要劃分子系統,用例要放在系統里,用例之間還有有層級,用例還要可復用,不信的話去做真實項目,這里全錯

      來自廣東 回復
  3. 作者很詳細的介紹了用例圖概念及實現思路,但是對于產品經理來說,用例圖只是以用戶角度對需求的展現,而更重要的是了解用戶需求背后的邏輯關系。

    很多產品經理因為經驗不足,僅靠摸索去了解,最后甚至挖掘不到用戶的真實需求。

    這里向你推薦起點學院的產品體系課,如果你不了解這門課程,可以先來試聽產品經理公開課,多位10年+經驗的產品老司機分享他們多年實戰沉淀的產品經驗,現場更有1V1互動,點擊這里,立即預約>>http://996.pm/7qaOd

    來自廣東 回復
  4. 查詢歌曲是不是也能泛化為 歌曲名查詢、歌手名查詢

    來自福建 回復
  5. 清晰明了,點贊

    來自廣東 回復
  6. 寫錯啦。

    回復
  7. 有錯誤的內容,請修正,避免學習用例圖的朋友被誤導。

    來自福建 回復
  8. 筆者在畫extend時有問題,它的箭頭應該指向上一級用例,而非被擴展的用例。

    來自河北 回復
  9. 擴展關系三extend,文章中寫成exclude了,箭頭應該指向基礎用例

    來自福建 回復
  10. 用例圖應該是測試的時候用的吧

    來自浙江 回復
    1. 產品畫完業務流程圖 應該繪制用例圖

      回復
  11. 1111

    回復
  12. 手動點贊!請問你一般這些都要寫嗎

    來自四川 回復
    1. 這些工具主要還是用來輔助自己更好的整理和理解業務。同事給別人說業務的時候有圖輔助別人也更好理解你說的。用別的工具也是可以達到目的的,所以不是都要寫的。關鍵是能把業務理清楚講清楚。

      來自浙江 回復