[案例研討] 烏龜訂購系統開發與實作 by UML and Java-04

二、 利用使用案例圖規劃需求架構,決定系統開發範圍

界定系統開發範圍 (system boundary),找出功能性的使用案例 (use case)、以及使用系統的主要參與者 (primary actor),與外部系統提供服務的支援性參與者 (supporting actor)。

圖 2、利用使用案例圖界定系統開發範圍
(點擊圖片鏈接看原圖)圖 2、利用使用案例圖界定系統開發範圍

  • 參考上圖 2,從主要參與者的角度來看,使用案例只有三個: 「訂購烏龜」、「追蹤訂單」、「維護烏龜資訊」 。
  • 至於「結帳」、「新增、查詢、更新、刪除烏龜資訊」等,只是被包含 (include)或擴展 (extend)的子程序 (Sub-procedure)而已。
  • 使用案例實作的優先順序,一般係從關係利益人 (stakeholder) 其角度所看待價值最高的使用案例。

    呈現價值最高者,往往為交易類型的使用案例。如上圖「訂購烏龜」即為交易型的使用案例 (相對「維護烏龜資訊」則為資料維護型)。

  • 從下列實作步驟開始,即以該案例作為實作演練的範例。

三、 為每一個使用案例,撰寫使用案例敘述

Use Case Name 訂購烏龜
Pre Condition 1. 客戶已登入 (Logon)系統。
Brief Description 客戶可以透過本系統線上訂購烏龜。
Flow of Events
  1. 客戶要求系統列出 [所有烏龜清單]。
  2. 系統列出 [所有烏龜清單]。
  3. 客戶選欲購買的烏龜,包括烏龜編號與購買數量。
  4. 客戶送出 [結帳資訊]。
  5. 系統依據 [BR-001: 計算訂購總額],並列出 [確認訂購資訊]。
  6. 客戶確認本次訂購資訊。
  7. 系統儲存本次訂購資訊。
Requirements
    [烏龜清單]

  • 烏龜種類
  • 烏龜價格
  • 烏龜年紀
    [結帳資訊]

  • 烏龜種類
  • 烏龜價格
    [訂購確認資訊]

  • 訂購的烏龜編號、數量。
  • 本次訂購的總額。
    [BR-001: 計算本次訂購金額]

  • 訂購金額 = 烏龜售價 * 烏龜數量
Extension Point
References 1. 烏龜訂購單原型 UI。

文章導覽

   

共有 5 則迴響

  1. 但由於不同的UI設計,可能會有不同的類別物件產生,例如可能會多一些WebUI 及agent程式間的溝通(如果是console介面就不需要額外的agent程式),是否應該在設計階段表達出來,以利實作?

    非常感激您的回應~

    • 所謂 “不同的UI設計,可能會有不同的類別物件產生”,你應該要能理解的是,系統功能在分析與設計階段,是與這些沒啥關係的。

      上述這些議題,會擺在實作的設計議題,此時實作設計人員係將焦點擺在 UI 的畫面設計,以及如何連結至系統 (如控制類型的物件),以取得系統所提供的功能服務。 (而連結可能透過 Local, RMI, Web-Service, Web HTTP 等機制)

      “焦點” 是對軟體設計人員最重要的修練了。”聚焦” 正確的話,往往容易事半功倍的。

  2. 不好意思,能否請教一下:
    甚麼時候須表達出訂購的介面是UI還是command line介面,是系統設計階段(ex:畫class diagram時?)決定,還是寫use case時就要分成兩種use case來寫呢?
    感謝~

    • 全都不是喔。

      決定使用何種 UI 實現呈現,是屬於「實作」議題,與上述系統需求分析及設計階段沒有甚麼關係的。 (最多就是備註一下而已)

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *