當我們利用使用案例圖界定了系統設計範圍(Boundary)後,
同時也找出主要參與者(Primary Actor)及其對系統的期望(Goal)。
參考下圖一。

ATM系統的使用案例-提款
圖一、ATM系統的使用案例-提款

圖一說明了系統必須對 "顧客" 提供 "提款" 的功能。從顧客的角度來看,系統被視為黑箱(Black-box)。系統是如何實現(Realize) "提款" 的功能,顧客並不需要知道,他只要系統能滿足及確保其利益即可。

從圖一,我們可以很明確地看出來參與者使用該系統的目的,不過,參與者為了達成該目的,會有一連串的操作系統過程,這些過程稱之為 "動作步驟"
。從使用案例圖並無法看出參與者與系統之間的互動過程。互動過程的描述,我們會以使用案例(Use Case)來記錄。
使用案例的內容,就在於描述參與者與系統間一段的互動過程,以達成參與者的某個目的。一般其內容的描述,我們是以文字來表達,畢竟,文字可說是最通用、簡單的溝通工具。

文字是最容易溝通、表達的工具,但,相對地,寫使用案例的敘述,要能寫得易讀流暢,不是一件簡單的事。
RA(Requirement Analyst)在寫使用案例時,最常見的一個問題,在於無法明確描述某個動作步驟到底是由誰來負責,是 "參與者",還是 "系統" 所做的事呢? 另外,何時需要描述到系統內部的動作,但又不能描述太多系統內部的細節(請記得,使用案例一直是將系統視為一個整體(whole),是一個黑箱(Black-box),原則上只專注在系統外觀上的行為描述),這是個為難之處。

還有,若我想先將焦點專注於參與者與系統之間互動的描述,而且是針對正常的情節(Normal Scenario),同時又能減少上述兩個問題的發生,我發現到,利用循序圖(Sequence Diagram)來表達參與者與系統之間的互動,是蠻理想的。

這還有個好處,在寫正式格式的使用案例之前,架構師(Architect)或 PM(Project Manager)可以快速檢驗 RA 寫使用案例的正確性。而且,參考該循序圖,也可以快速建構原型(Prototype),可能是以表單元件(Form Component)、控制物件(Control Object)、功能測試碼等諸多實做方式,以簡單的程式碼來檢視系統所提供參與者的基本功能(人們往往喜歡眼見為憑,有程式碼的執行,會安心許多)。

循序圖,一般是被用來表達系統內部物件之間的互動合作。在這裡,是把 "系統" 視為一個整體(whole),所以,只有一個物件:"系統"。這也代表了,我們只描述到系統邊界的行為,至於系統內部是如何被實做,我們仍未涉及至細節的結構設計。

參考下列範例圖二,上方實線橢圓代表系統要做的 "事(do what)";下方虛線橢圓代表系統要如何(how-to) "實現(Realize)" 橢圓的使用案例。

Use Case Realization 的語法表達
圖二、Use Case Realization 的語法表達

系統要如何實現該使用案例,必須知道參與者與系統之間的互動關係,利用循序圖所表達的範例下圖三。

利用循序圖描述參與者與系統的互動關係
圖三、利用循序圖描述參與者與系統的互動關係

從圖三,可以觀察幾點系統的特性:

  • 系統擔負實現(Realize) “提款” Use Case 的責任。
  • 從圖三每一條的動作步驟,代表了要傳送的訊息(Message, 以實線表達))以及回傳的資訊(以虛線表達),箭頭表達了傳送的方向。所以可以很清晰明確的瞭解那個動作步驟是由誰負責的。例如,動作步驟 3 是由系統所負責的行為。
  • 為確保及滿足關係人的利益,系統需描述出其系統私有動作。
    • 證實用動作。例如,上圖動作3(保障),系統證實輸入密碼無誤。
    • 內部狀態變化。例如,上圖動作7(滿足),系統更新顧客餘額。
  • 從圖三仍未能看出系統是如何實做 ”提款” UC(未描述系統內部的結構)。亦即,未來系統的實做是以2-tier、3-tier或物件導向等方式尚未決定。
  • Actor 與系統的對話(Dialogue)過程期間(Session),系統必須保存其對話過程的狀態(State),亦即,從 Actor 的角度來看待系統時,系統為 “Stateful”。(但不代表系統內部所參與的物件均必須為 Stateful)。
  • 再次強調,Use Case 與物件導向沒有直接關聯,但會是導入物件導向技術重要的需求捕捉關鍵技術。