軟體工程之用例模型總結

文章目錄

• 怎樣確定用例？
• 3.如何確保正確的用例
• 4.使用案例圖

一、用例模型1.用例概念

用例：使用系統時發現的功能性需求，不應過於複雜，簡單的來說就是你希望系統能夠有什麼功能，能夠增加系統的價值。

用例模型包括用例描述和使用案例圖，我們主要把中心放在用例描述上。

用例模型包含參與者和情境，情境包括成功情境和失敗情境。

因此用例模型中有多個情境；每個情境是一個用例。

用例必須注重為使用者提供可觀察的傳回值，就是系統觸發了一個用例之後能夠給使用者帶來什麼。

一般用例都是黑盒用例，即不考慮如何?。

2.Use Case Description
每個用例都有一個描述。怎樣確定用例？

(1)確定一個功能；
(2)寫一個用例；

(1)主要參與者：調用系統服務完成目標的人。

(2)次要參與者：為系統提供服務的人。

(3)寫出每個項目相關人員的理想需求，從中分析功能。

(4)PreCondition:執行到這個用例之前必須為真的情況，比如必須已成功登入或通過驗證。

(5)PostCondition:成功執行完此用例後的情況，比如登入用例的後置條件是成功登入（不考慮其他失敗情況）。

(6)main flow：將最理想的步驟列出。

一般main flow步驟如下：

    (1)參與者發生動作。

    (2)系統驗證。

    (3)返回結果。

(7)extension flow：擴充步驟,通常格式為：(1)系統檢測到**有問題;

在main flow中的第一步擴充，則用1a,1b,1c;

3.如何確保正確的用例

EBP原則:一般用例都需要遵守這個規則，即確定主要用例。

用例中的主要用例是一些重複做但是有意義的事，比如收銀員收錢，重複多次是有意義的，因為錢收得多了；但是像登入系統，這種做100次卻沒有意義的用例，不能被稱為主要用例；

(1)EBP（基本業務過程）原則的用例寫入；

(2)如果要寫編輯A，刪除A，添加A，可以合并成“管理A”；

4.使用案例圖

每個用例描述都是一個用例，左邊是主要參與者（希望系統為他提供服務）和次要參與者（提供給系統服務的人）；

 

在次要參與者中不能有資料庫，因為在使用者角度看是不知道系統有資料庫的；

 

關係：

(1)泛化關係，在參與者和用例中都能泛化。

(2)內含項目關聯性：

 

表示A包含B；比如A是管理資料，B可以是添加資料、刪除資料等；

(3)擴充關係：

表示D被C擴充，D包含新的功能，比如D是查詢資料，C可以是列印資料，即使用者可以查詢但不列印資料，列印資料只是一個擴充功能。

用例描述模板

用例模型根據系統邊界的確定，描述了系統的輸入和輸出，確定了系統外部的參與者，通過用例描述了系統的主要功能，描述了外部參與者與系統的互動，將系統作為一個黑盒，從使用者角度描繪出系統需要提供的功能; 
Use Case：用例名稱Actor：參與者Precondition：前置條件，即執行這個用例一定要滿足的條件Postcondition：後置條件，如果成功執行，則一定會變成的狀態Main flow：1.使用者開始一次會話2.使用者輸入資訊3.系統驗證並反饋4.使用者重複2，3步Extensions：3a：資料無效    1.系統提示出錯