從鳥瞰的觀點看 Use Case Diagram

我個人一向主張寫 Use Case 的敘述之前,先畫使用案例圖(Use Case Diagram) 。原因在於我們可以從鳥瞰的視野綜觀系統的全貌:

  1. 可以利用套件(Package)界定系統的設計範圍(Boundary)。
  2. 避免過早涉及至細節(Detail)。

先說明,什麼是鳥瞰?

  • 從高處俯視低處。
  • 對事實情況作概略的觀察。

利用使用案例圖,可以協助我們從 "鳥瞰" 的視野來看系統的外觀,避免從系統的內部來看 Use Case (這是許多 Developer 常犯的毛病)。
同時,因為鳥瞰,所以,比較容易能看出系統的全貌、界定系統的範圍、區分系統的內與外(這很重要,如此才能知道什麼該作,什麼不需作)。還有,也比較容易看出使用案例的所表達的層次(level),如企業層級(Business level)、使用者目標層級(User-goal level)等。

寫使用案例若不知道系統的設計範圍,我很難相信 RA(Requirement Analyst)能寫得好 Use Case。
理由為何?若未能確定系統邊界,那麼,你如何能將系統視為一個黑箱(Black box)?你又如何能確認誰是使用系統的主要參與者(Primary Actor)?

而 Developer 常常以為很清楚系統範圍,但事實上系統範圍的界定在團隊成員之間往往會有見解上的落差。
例如,觀察下圖一,顧客至錄影帶店租片,很直覺地,我們發現有個 Use Case:租片 。

使用案例圖(沒有以Package界定範圍)
圖一、使用案例圖(沒有以Package界定範圍)

沒有畫出系統邊界,一般是常見於單一系統的開發,且系統的範圍很明確。但我們觀察圖一,試著問問團隊內部的開發成員們,她們所認知的系統是界定在那個範圍呢?
可能會以為,不就是要開發一個影片租借系統嗎?


我們來反思,顧客會直接去 "使用" 軟體應用系統嗎?不然吧,直接使用系統的實際參與者(Actor)是錄影帶店的櫃臺人員。

所以,若把圖一的系統範圍界定於 "影片租借系統",Actor 是 "顧客",Use Case 是 "租片",其實是大有問題的。

實際上,圖一的使用案例圖是屬於 "企業層級(Business level)" 的 Use Case,偏向於描述企業的流程,而非操作系統功能面的 "使用者目標(User-goal level)" 層級的 Use Case。
系統界定的範圍一般以企業為單位,如下圖二。

企業層級的使用案例圖
圖二、 企業層級的使用案例圖

圖二是以百X達為系統的範圍,內部包括了 "內部的工作者(internal worker)",如店長、櫃臺人員;同時也可能包括了如影片租借、會計、人事等軟體應用系統。
所以,是不是百X達所有的內部的系統均是由同一個開發團隊來開發的?還只是負責開發其中單一個子系統呢?

很有可能,只是承包 "影片租借系統" 的開發。那麼,顯然,主要參與者就不是顧客了,而是實際操作系統的櫃臺人員;使用系統的 "Goal" 也不是 "租片",而是成為 "處理租片" 的 Use Case 了。如下圖三。

影片租借系統的使用案例圖
圖三、 影片租借系統的使用案例圖

我們可以發現,因為系統的範圍很明確的界定在 "影片租借系統",所以,當系統若是接受是以信用卡刷卡的方式付款,那麼,系統就需要連到外部銀行的系統,此時,銀行的外部系統就成為 "影片租借系統" 的 "Supporting Actor" 了。

圖三所表達的使用案例圖,其層次是偏於 "使用者目標等級"。亦即,當 RA 要寫 Use Case 敘述時,所訪談的 Actor,大部分是直接操作系統的使用者(Operator),如櫃臺人員。而圖二企業層級的使用案例圖,所訪談的主要對象不是主要的參與者:顧客,反而是制訂企業案例流程的利益關係人(Stakeholder)了。

企業層級的使用案例圖,著重於描述企業內部的流程;非著重於描述系統的行為。通常會以白箱式(White-box)的作法打開企業內部,以瞭解內部 internal worker的互動情形。

而使用者目標等級的使用案例圖,是經常最被討論的層次。系統範圍經常是指軟體應用系統,為滿足主要參與者(Primary Actor)來使用系統的目的。而通常是使用者在某一段時間(3~30分鐘)操作系統後所完成的目標。
在此一層次,我們會以”黑箱(black-box)”的方式來描述使用案例,瞭解參與者與系統之間的互動(或稱之為對話)關係。

利用使用案例圖,協助我們確定及界定了系統的廣度(系統範圍)與深度(系統層次),可以讓我們看到 "誰(Actor)"來使用系統,以及系統要作的"事(系統行為或稱之為系統責任)。然後再進一步去瞭解 Use Case 的敘述,紀錄 參與者 與 系統 之間的操作對話的互動過程。
再更進一步,才去設計系統內部是如何 "實現(Realize)" Use Case。

由整體、全貌的觀照,找出及界定系統的範圍,然後將焦點擺在橢圓的 Use Case, 釐清參與者的目的(Goal)。再來才是寫出正確易讀的 Use Case 敘述,瞭解參與者與系統之間對話的過程。
由簡入繁,逐步增加使用案例的精確度(precision)。不要一開始就陷入繁雜的細節,如此才不至於將過多的精神擺在錯誤的設計及描述上。

使用案例圖, 就是協助你由簡入繁、減少不必要的謬誤發生。

文章導覽

   

共有 9 則迴響

  1. 以上大致都能瞭解,唯獨您對於白箱與黑箱的描述有些疑惑~

    我認為白箱與黑箱可以用透明度來做二分法,白箱是具透明度的,黑箱反之

    而白箱與黑箱又屬於具動態性的詞語~

    當我們以宏觀的態度看待事物時,很多事物都可以當作是黑箱,因為我們並未深入去瞭解它,所以黑箱有封裝的概念存在,它隱藏了一些資訊,因此不具透明度
    但我們可能會想要瞭解事物之間的互動關係,因此就這個整個宏觀來看,事物之間的互動關係是一個白箱

    若當我們以微觀的態度看待宏觀中的某個黑箱時,原本在宏觀中的黑箱可能屬於微觀中的白箱
    因為白箱具透明性,揭露了足夠的資訊
    而其中或許又有些事物是我們並不想瞭解的,那麼它們又屬於黑箱

    因此,我認為畫 use case 時要以白箱式或黑箱式的作法
    應該是看今天的表達對象是誰,也就是這張 use case 是要畫面誰看的

    回到您的例子,因為您並未特別強調圖二、 企業層級的使用案例圖圖三、 影片租借系統的使用案例圖是畫給誰看的,因此可能比較難說明它們是以白箱式或黑箱式的作法

    您認為呢?

    • 非常高興您能有自己這樣的想法表達。 🙂

      那個 “透明度” 的解釋非常有意思,也很清楚。

      我個人是用 “聚焦” 這個字眼來看待 “白箱” 與 “黑箱” 的相對性關係。 當我想看某個聚焦的主題內部,就會用 “白箱” 的角度頗開;當我只想看那個主體的表面所呈現 “用” 的服務時,就會以 “黑箱” 的角度看待。

      最後,圖例的 2 與 3,我這裡做一點解釋。 那個用 Package 標出的框框,稱之為 “系統範圍 (system boundary)” 就是界定外為 “黑箱” 的角度 (所以,從 Actor 來看待系統,就是黑箱的角度);而若要頗開內容的元素分析,則為 “白箱” 的角度。

      “黑箱” 與 “白箱” 是一種看待的角度,也是一種相對性的關係。 🙂

  2. 寫的太好了,因為我是完全沒有基礎的門外漢,連我都了解,看懂了,我想應該大家都懂了吧,一個好的說明書,和一個好老師就是應該把一個完全不了解的人教會!五顆星!!!!!

  3. Hi Jeff:

    上圖是藉由影片出租系統的範例來討論本篇的主題:系統範圍。
    而不是窮究去探討影片出租系統這個 “Domain” 內有幾個 UC。

  4. 呵這個 Case 跟我們討論的喝咖啡的很像
    看了這篇後果然感受不同~~
    呵~~
    不過影片出租系統應該不只有租 還有還 還有退款等UC
    還是我的觀念有誤呢? 請指教!!

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *