Use case

首先，來點文言文…

A use case describes what your system does to accomplish a particular customer goal.

use case 是捕捉新系統或軟體變更的潛在需求之技術。每個 use case 提供一或多個 scenario，傳達系統如何與 end user 或其他系統互動，完成特定目標。

以上文言文看完我也不知道自己是不是知道它在寫什麼。(喂)

白話文來說，use case 會寫出一堆使用這軟體的情境跟過程，藉由這些情境跟流程來描述軟體要做些什麼好達到客戶的目標。（這樣有白話文一點嗎？）

use case 描述軟體要「做什麼」（what），而非描述「如何做」（how）。

組成 Use case 的三部分

1. clear value
   軟體要幫客戶做的事，也是客戶的目標。
2. starting and stoping point
   use case 的開始及結束點，總不會一直繞圈圈沒完沒了吧。
3. external initialtor
   既然是軟體的使用流程，總有個開始「使用軟體」的人或其他系統。

Main & Alternative path

main path 是當世界一片美好、沒有任何事情出錯時，使用者會遵循的使用流程。但通常世界不是那麼美好的，工程師的工作之一就是要找出這些不美好(?)，讓軟體也能妥妥善善的處理它。alternative path 即是在 use case 中負責描述及處理這些「出錯狀況」的使用流程。

alternative path 可以是…

1. 完全替代原本的部分 path。遇到某個選擇時可以選 main path 繼續下去，也可以選 alternative path 做。
   例如可以選吃飯或吃麵完成吃晚餐這件事。
2. optional 的，用來處理額外、例外以及出錯的狀況。
   例如想吃牛肉麵但沒開的時候該怎麼辦。

關於 Use case

形式上沒有固定的限制，我通常會寫成流程步驟，不管形式如何，重點只有一個──看得懂、能正確表達意思。

寫 use case 的時候會進到幾乎可以將 use case 裡的 logic 變成 code 的細節部分。

use case 也要包含檢驗步驟，例如檢驗輸入是否合法、某個物件是否存在等等。

Textual Analysis

寫好 use case，然後咧？跟程式有什麼關係？這時候就是 textual analysis 上場的時候啦！

分析 use case 裡的名詞及動詞，整理出 class 及 method 即為 texttual analysis。

use case 中的名詞有可能是系統中的 class，動詞通常是 class 的 method。當然不是 use case 裡所有的名詞跟動詞都是 class 跟 method，所以需要經過分析，好決定要為那些名詞及動詞建立 class 跟 method。

做完 textual analysis 決定要有哪些 class 跟 method 後，就可以進入設計物件跟物件間關係的階段了。