每次看到使用案例的橢圓形與使用案例所要凸顯的目的,就聯想到,使用案例就如同去道教的廟宇,有個許願池,投入十元、五十元不等的硬幣,在心裡許願,以求得平安、健康、財富與愛情...等等各種願望。許願池是道教的廟宇所特有的,而道教的神明,各據地方的廟祀,各司其掌,保佑地方眾生的平安。

使用案例與崇信道教的信徒至廟宇許願,有許多相似之處,例如:

  • 眾神明所居住的廟宇,就如同寫使用案例時,需界定系統範圍,廟宇=系統。
  • 信徒向神明許願,信徒就是使用系統(廟宇)的參與者(Actor),而所許的願就是使用案例(Use Case)。
  • 許願後還願,是一種契約(Contract),契約就是一種交易(Transaction)。道教是崇尚交易的信仰,向神明許願,若神明滿足信徒的願望,信徒是要還願的;這就如同系統能滿足參與者使用系統的目的(Goal),那麼,每一個所滿足的使用案例就是一個交易,每一個交易是要向客戶計價收費的。
  • 信徒向神明許願,不需要瞭解神明是如何能達成信徒的願望,最終只要能完成你所許的願即可;這如同參與者使用系統的使用案例,不需要瞭解系統是如何(How-to)完成參與者的使用案例,只要能滿足其目的(Goal)即可。

舉個例子,來說明如何利用使用案例 “塑模(Modeling)” 信徒的許願。
「兩個信徒,到烘爐地福德宮土地公廟許願。其中信男許的願是 “求得大樂透明牌”;信女許的願是 “求得子息”。」

初期的系統分析,界定系統是 “南山福德宮(烘爐地土地公廟)”,參與者有兩個:一個是 “信男”,另一個是 “信女”;使用案例是 “求得大樂透明牌” 與 “求得子息”,參考下圖一:

南山福德宮廟使用案例圖-01
圖一、南山福德宮廟使用案例圖

土地公如同人間的里長一般,是屬於地方的行政官員,職司庇佑地方升斗小民包括求財、出外、入厝、動土、農作物的收成、家畜的繁衍...等。但是卻非執掌婦女的生育,這應該是註生娘娘的職掌才對呢。怎麼辦?既然信女都向土地公求子生育了...。

經過玉皇大帝左右手三官大帝(其角色如同系統分析人員)的作業協調與分派,確定求得子息的願望需交由註生娘娘才能完成其目的。但總不能直接在土地公廟拒絕該信女的願望吧?所以,其未來生得子息的實現會轉由註生娘娘來負責的。註生娘娘也是系統,但是祂並不屬於土地公廟的管轄,所以是屬於外部的系統,也就是土地公廟的 “支援性參與者(Supporting Actor)”。

第二次的使用案例系統分析如下圖二:

南山福德宮廟使用案例圖(新增註生娘娘的外部參與者)-02
圖二、南山福德宮廟使用案例圖(新增註生娘娘的外部參與者)

信男與信女都不需要知道土地公是如何(How-to)達成他們的願意,最終就是只要能滿足其願望即可。所以,信女也根本不需要知道 “求得子息” 的實際工作是由土地公轉派交付給註生娘娘來實現(Realize)的。

若是想知道系統是 “如何” 實現其願望,那麼,就勢必要 “打開” 土地公廟的系統,探究其內部是由哪些人員來協調、互動與合作,以完成信徒們所交付的願望。

找出工作人員、分派工作人員的職掌,就如同系統分析中的找出物件、分派物件的責任(Responsibility Assign),是屬於系統內部的結構分析與設計(Structure Analysis/Design)。

我們可以利用循序圖(Sequence Diagram),來表達系統內部中,有哪些物件會參與完成一個使用案例。循序圖內,就是明確地表達參與使用案例物件之間的協調與合作。

例如上圖一,每天有那麼多信眾來許願,土地公可無法一人就可以獨立來完成所有信眾們的願望,這樣責任太重了,萬一土地公生病了怎麼辦?

所以土地公顯然會分派責任給祂下轄的隨從們,協調、互動與合作來實現(Realize)其願望(使用案例)。

土地公擔任窗口(Facade),祂也是控制者(Controller)。信男送出訊息(Message)給土地公後,土地公將該訊息交付給文隨從,而文隨從又將訊息傳送至祂的樂透邏輯演算機,來取得明牌號碼。(至於準不準,那是另外一回事了。 ;) )

參考圖三:

求得明牌的循序圖
圖三、求得明牌的循序圖

又,土地公接到信女求得子息的許願,因執掌生育是屬於註生娘娘的司掌的範疇,所以土地公派祂的坐騎 “虎爺”,將該訊息送到註生娘娘那,以實現其願望。

“虎爺” 負責對外界神明的聯絡,所以祂是屬於 “Boundary” 的角色,也可說是 “Adapter”。

參考圖四:

求得子息的循序圖
圖四、求得子息的循序圖