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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

參考圖三：

圖三、求得明牌的循序圖

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

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

參考圖四：

圖四、求得子息的循序圖