二、 利用使用案例圖規劃需求架構，決定系統開發範圍
界定系統開發範圍 (system boundary)，找出功能性的使用案例 (use case)、以及使用系統的主要參與者 (primary actor)，與外部系統提供服務的支援性參與者 (supporting actor)。
（點擊圖片鏈接看原圖）圖 2、利用使用案例圖界定系統開發範圍
- 參考上圖 2，從主要參與者的角度來看，使用案例只有三個： 「訂購烏龜」、「追蹤訂單」、「維護烏龜資訊」 。
- 至於「結帳」、「新增、查詢、更新、刪除烏龜資訊」等，只是被包含 (include)或擴展 (extend)的子程序 (Sub-procedure)而已。
- 使用案例實作的優先順序，一般係從關係利益人 (stakeholder) 其角度所看待價值最高的使用案例。
呈現價值最高者，往往為交易類型的使用案例。如上圖「訂購烏龜」即為交易型的使用案例 (相對「維護烏龜資訊」則為資料維護型)。
- 從下列實作步驟開始，即以該案例作為實作演練的範例。
三、 為每一個使用案例，撰寫使用案例敘述
| Use Case Name | 訂購烏龜 |
|---|---|
| Pre Condition | 1. 客戶已登入 (Logon)系統。 |
| Brief Description | 客戶可以透過本系統線上訂購烏龜。 |
| Flow of Events |
|
| Requirements |
|
|
|
|
|
|
|
| Extension Point | |
| References | 1. 烏龜訂購單原型 UI。 |
謝謝您的提醒喔~
但由於不同的UI設計，可能會有不同的類別物件產生，例如可能會多一些WebUI 及agent程式間的溝通(如果是console介面就不需要額外的agent程式)，是否應該在設計階段表達出來，以利實作?
非常感激您的回應~
所謂 “不同的UI設計，可能會有不同的類別物件產生”，你應該要能理解的是，系統功能在分析與設計階段，是與這些沒啥關係的。
上述這些議題，會擺在實作的設計議題，此時實作設計人員係將焦點擺在 UI 的畫面設計，以及如何連結至系統 (如控制類型的物件)，以取得系統所提供的功能服務。 (而連結可能透過 Local, RMI, Web-Service, Web HTTP 等機制)
“焦點” 是對軟體設計人員最重要的修練了。”聚焦” 正確的話，往往容易事半功倍的。
不好意思，能否請教一下：
甚麼時候須表達出訂購的介面是UI還是command line介面，是系統設計階段(ex:畫class diagram時?)決定，還是寫use case時就要分成兩種use case來寫呢？
感謝~
全都不是喔。
決定使用何種 UI 實現呈現，是屬於「實作」議題，與上述系統需求分析及設計階段沒有甚麼關係的。 (最多就是備註一下而已)