第十章 使用個案塑模

內容大綱 第一節 導論 第二節 使用個案模式 第三節 建構使用個案圖 第四節 使用個案塑模案例 第五節 應用使用個案模式的好處 第六節 應用使用個案模式應注意事項 第七節 使用個案模式的文件樣板 第八節 結論

導論 若分析與設計之階段採用物件導向技術，則在需求分析時，常以使用個案模式來進行需求塑模。 使用個案模式是利用一些典型的情節來幫助表達使用者需求。 本章將介紹使用個案模式及其建構之步驟與原則等。

使用個案模式(1/2) 使用個案模式是一種使用者需求表達之塑模工具，該工具從使用者之觀點，描述系統提供之功能與定義系統內部之作業，並以使用個案圖表達之。 使用個案圖主要是由行為者、使用個案與關係等元件所組成，其可標示行為者與使用個案間之互動及使用個案與使用個案間之關係。

使用個案模式(2/2) 使用個案圖中，行為者常以人形表示，使用個案以橢圓形表示，行為者與使用個案間之互動以實線表示，使用個案間之關係以箭頭表示，表達符號摘述如圖 10-1。

行為者 行為者是環境中的人或事物，它扮演與企業互動之角色或需與系統交換資訊之任何事物。簡言之，行為者是使用者在系統中所扮演的角色之一，該角色可與系統交換資訊與互動。 行為者和使用者不同，使用者是一個真正使用系統的人，而行為者只是用來表示使用者所執行的某一種角色。 主要行為者、次要行為者 例如：業務人員是系統之使用者，參與銷售與採購兩個使用個案，且是執行這兩個使用個案之主要行為者，而客戶與廠商分別是銷售與採購使用個案之次要行為者。

使用個案(1/2) 一個使用個案是系統中一系列的交易，以完成某一特定工作，並對系統之行為者產生可衡量的價值。也就是說，工作結果對行為者產生一些可看得見、可量化或質化的效益。 一個使用個案就是使用者透過介面要求系統所做一系列相關的事件流，有起點亦有終點，又稱為一個案例。

使用個案(2/2) 使用個案應描述基本路徑與替代路徑。 基本路徑是事件之最重要路徑，它最能讓人瞭解使用個案的作業內容。替代路徑所描述的可包括基本路徑之衍生及可能發生之錯誤等。一般來說，一個使用個案僅有一個基本路徑，但可以有多個替代路徑。 舉例來說，訂購一批貨物會有一個訂貨的使用個案，它包括好幾個對應的情節，例如一個一切都正常的情節、一個貨物不夠的情節、一個信用卡被拒絕的情節等。

使用個案與使用個案間之關係(1/3) 使用個案間的關係主要可以分為三種 包含(Include) 延伸(Extend) Include可視為一種「Delegation」（委派）或是「Aggregation」（整合），也就是說某一使用個案「A」會用到另一使用個案「B」，則稱A委派或整合B，關係之箭頭符號應由A指向B。 延伸(Extend) Extend之關係可視為是某使用個案（例如A）在某情況時（並非所有情況），會被插入至另一使用個案的定義中（例如B），而形成一新的組合使用個案，則關係之箭頭符號應由A指向B。 一般化(Generalization) Generalization之關係意味著使用個案間之繼承關係。

使用個案與使用個案間之關係(2/3) 銀行匯票處理方式的使用個案 查驗密碼：要求使用者輸入密碼後，查核使用者是否為合法使用人員。 掃描視網膜：確認使用者是否具有高優先權時，需利用攝影機將使用者的眼睛影像截取後，比對其視網膜影像資料是否為合法使用人員。 圖10-2 使用個案 關係圖範例

使用個案與使用個案間之關係(3/3) 確認使用者身分：要求使用者比對其身分是否為合法使用人員，正確時才可進入系統。 匯票追蹤：使用者欲追蹤特定匯票狀況時 須先核對使用者身分是否合法 為合法人員者便可進入系統查詢其指定匯票狀況 。 匯入匯票：操作員欲將匯票存入帳戶系統時 為合法人員者便可實施匯入一般程序，若該使用者具有高優先權利時，便可實施快速匯票處理。 快速匯票處理：直接快速將指定匯票匯入系統處理，排除其他限制因素。 主要事件流(1)︰Include（確認使用者身分），取得匯票匯入資料與確認的帳號，設定優先權，依權限處理匯票匯入。 主要事件流(2)︰Include（確認使用者身分），查核匯票的狀況。

建構使用個案圖 使用個案圖之建構應是一個反覆的程序，一開始先建立初步的使用個案圖，然後再反覆精練，最後才能得到較完美之使用個案圖。 建立初步使用個案圖之步驟 找出行為者 找出使用個案 描述使用個案 找出使用個案間之關係 最後劃出初步的使用個案圖

找出行為者(1/2) 找出使用個案圖行為者之方式很多，例如： 可從組織中的成員來找。 可從問題的陳述、使用者領域之專家或檢視蒐集到的文件，也可從其中之名詞、代名詞與名詞片語等，找出合乎行為者定義的人或相關系統。 可從環境圖找出行為者，因環境圖中之外部實體與系統有互動關係，所以這些外部實體將成為系統中使用個案的行為者。

找出行為者(2/2) 亦可以從幾個方向來找出初步與系統相關的行為者，例如： 所開發的系統用在什麼地方？ 這個系統會使用一些外在的資源嗎？ 誰對系統中的某些項目有興趣？ 誰是系統的資訊提供者？ 誰是系統的資訊使用者？ 誰是此一系統的操作者？ 誰會支援及維護這個系統？ 一個行為者扮演許多不同的角色嗎？ 或是多個行為者扮演相同的角色呢？

找出使用個案(1/2) 先找出某一行為者，再逐一檢討該行為者，以找出其所參與的每一個使用個案。完成後，再以此方式檢討其他行為者，直到檢討完其他所有行為者為止。 一般來說，行為者使用系統時，必先啟動一個事件，之後會有相關事件之回應，直到完成使用系統的目的為止，這一系列事件有組織地集合起來便成為一個使用個案。 一個使用個案是使用者透過介面要求系統所做的一連串相關的事件流，應有起點亦有終點。從使用者之角度來看，每一個使用個案就是一個案例，可完成某一功能。

找出使用個案(2/2) 此外，也可以從一些方向來找出初步與系統相關的使用個案，例如： 行為者做什麼工作？ 行為者是否會建立、儲存、修改、移除、或讀取此系統資訊？ 行為者是否會通知系統有關外在環境的改變？ 若系統發生任何狀況，是否會通知行為者？ 使用者如何支援及維護這個系統？

描述使用個案(1/5) 使用個案描述是從行為者之觀點描述使用者達成某目標、目的或功能之作業行為，此時應著重企業處理或功能描述，而不應涉及電腦化之操作。 使用個案的描述方式有兩種： 自然語言 事件條列式

描述使用個案(2/5) 以取消訂單為例，該使用個案之描述如下： 以自然語言方式描述 以事件條列式描述 當業務部收到取消訂單的要求時，先找到系統中的訂單並取消之。然後，再將這個要求送到會計系統去更正客戶的訂單。 以事件條列式描述 業務部收到客戶取消訂單的要求 業務員輸入訂單編號，並按下「尋找」的按鈕 系統展示所尋得的訂單，並將訂單標示為「已 取消」 會計系統被告知更正客戶的訂單

描述使用個案(3/5) 以自然語言之文句敘述來描述使用個案時，若使用個案中包含許多替代路徑，則很容易變得難以瞭解，因此建議用一些結構化之寫作方式來描述較佳。也就是說，以事件條列式描述優於自然語言方式。 使用個案主要描述使用者達成某目標（目的或功能）的行為，故事件描述之內容應包括： 工作項目與流程 工作內容 資料特性

描述使用個案(4/5) 工作項目與流程 工作內容 事件描述應確定每一事件有哪些工作、工作間之流程與控制等，這些工作在系統分析與設計階段將被轉換成電腦化的操作項目。 工作內容 工作內容描述每一工作項目之細節，包括事件所傳送資料之每一項目或欄位及其來源，如送貨單之客戶名稱、地址、電話號碼。 若有公式亦應列出，若涉及其他資料之異動更應詳加描述。

描述使用個案(5/5) 資料特性 對於工作內容之資料應進一步描述其特性，資料特性應包含： 資料型態，如字串或數字與長度。 鍵，如主鍵或副鍵。 排序，如以ASCII CODE作為排序順序。 資料範圍，如設定數值必須小於100。 資料出現次數，如一張送貨單有六筆送貨明細。 　以上這些描述將有助於物件或類別之屬性描述與資料庫之設計。

找出使用個案間之關係(1/6) 完成使用個案之描述後，可從使用個案之描述看出 : 哪些個案之描述中有共同的行為，便可將之獨立成一個新的使用個案及修改原個案之描述，並考慮新使用個案與原使用個案間之關係，例如這可能是Include或Extend。 哪些個案一定會用到某些個案，這是Include關係。 哪些個案僅在某些情況下會用到某些個案，這可能是Extend關係。 哪些個案某部分與另一個案相同且另外多出一些功能時，這可能是Generalization關係。

找出使用個案間之關係(2/6) 以門禁系統為例說明使用個案間之關係，該系統包含以下八個使用個案（如圖10-4門禁系統使用個案圖）：

找出使用個案間之關係(3/6) 進入未啟動安全監控的門：當門禁系統未啟動，學生及管理員可自由的經由這個門進出。 進入安全監控門：學生及管理員經由這個門進入的方式： 在數字鍵盤上輸入進入密碼 經由這個門進入 進入以後關上門 改變進入密碼：管理員改變進入密碼的方式： 按下控制板上的進入密碼改變按鈕 在數字鍵盤上輸入安全密碼作為認證 在數字鍵盤上輸入新的進入密碼 在數字鍵盤上重新輸入新的進入密碼作為確認

找出使用個案間之關係(4/6) 啟動門禁系統：管理員啟動門禁系統的程序： 解除門禁系統：管理員解除門禁系統的程序： 按下控制板上的啟動按鈕 在數字鍵盤上輸入安全密碼作為認證 未啟動指示燈熄掉 啟動指示燈打開 將門鎖上 解除門禁系統：管理員解除門禁系統的程序： 按下控制板上的解除按鈕 啟動指示燈熄掉 未啟動指示燈打開 打開門鎖

找出使用個案間之關係(5/6) 輸入進入密碼：學生及管理員先按「Enter」鍵再輸入8碼的進入密碼。門禁系統每按一個按鍵就發一聲「嗶」，並確認輸入密碼。 輸入安全密碼：學生及管理員先按Enter鍵再輸入8碼的安全密碼。門禁系統每按一個按鍵就發一聲「嗶」，並確認輸入密碼。 啟動警報器：如果門打開太久或者當門禁系統啟動而門沒有被關上，警報器發出響聲。管理員輸入安全密碼解除警報器。

找出使用個案間之關係(6/6) Extend可視為某使用個案，也就是某使用個案的定義在某種情況發生時會被插入至另一使用個案的定義中，而形成一新的組合使用個案。 以圖10-4為例，使用個案「啟動警報器」與「進入安全控制門」間有Extend之關係，且是從前者Extend至後者。 Include是一種使用關係，如使用個案「啟動警報器」與「輸入安全密碼」間有Include之關係，且是前者Include 後者。

繪製使用個案圖 完成上述工作後，最後是繪製使用個案圖，繪製步驟為先繪出將所有行為者與使用個案，將行為者與使用個案間有互動者以互動符號連結，接著再確定使用個案間之關係，並以適當之關係符號連結。 完成使用個案圖後，必要時可以用活動圖來表達使用個案間之執行順序（例如循序或同步），以清楚表達系統之外部（巨觀）作業行為，因為這些關係在使用個案圖上不易表達。

使用個案塑模案例 本節將以西子灣文化事業公司（以下簡稱西子灣公司）之網路線上訂購系統（這個案是虛擬案例），說明如何以使用個案圖配合藍圖與資料詞彙及活動圖等進行使用個案塑模（或稱需求塑模）。以下將先介紹使用者與企業需求，接者再建構使用個案圖（含藍圖與資料詞彙）及活動圖。

使用者與企業需求描述(1/8) 西子灣公司需要一套網路線上訂購系統以擴展銷售業務，由於西子灣公司並無足夠之資訊人力，因此對線上訂購系統之建置採取委外開發之策略，並將系統委由ABC公司開發。ABC公司接受該系統開發專案後，立即組成專案團隊著手進行規劃，接著由分析師透過查閱文件、訪談、開會討論等需求擷取方法（請參考第3章）進行需求擷取，並將所得之使用者與企業需求等資訊整理如下 :

使用者與企業需求描述(2/8) 背景 西子灣公司成立於1980年，專門從事文化出版事業，公司除了有出版社負責出版書籍刊物外，在全省北、中、南三大都會成立書店門市，主要經營書籍銷售，並將其定位為專業領域書籍的出版供應商。由於網際網路的興起與個人PC及上網之普及，公司為了掌握契機，因此決定建置線上訂購系統，以服務全國廣大的消費大眾及擴展商機。

使用者與企業需求描述(3/8) 新系統的目標與限制 建構一個Web-based線上訂購系統，使客戶能很容易地在線上完成所有訂購交易。 訂購系統必須能提供客戶線上交易查詢與付款。     客戶不論使用任何一種瀏覽器（如Microsoft IE、Netscape Navigator等）上網訂購產品，皆必須能看到同樣的介面，執行所有的操作功能。 系統必須容易維護，便於功能擴充。

使用者與企業需求描述(4/8) 使用者與企業（作業與功能）需求描述 客戶可以透過瀏覽器，經由網際網路到本公司的網站上閱覽公司書籍產品型錄。 如果客戶對某本書有興趣並希望獲得更進一步的資訊時，必須能在網頁上查看有關該書籍的細部說明。 客戶如果有意訂購某本書，可點選該書籍產品並將之置入購物車內及設定訂購數量。 未送出訂單前，客戶對已置入購物車內的任一書籍產品，可以隨時修改訂購數量（同時可單筆或多筆）。

使用者與企業需求描述(5/8) 未送出訂單前，客戶對已置入購物車內的任一書籍產品，可以隨時刪除（同時可單筆或多筆）。 客戶對購物車內書籍名稱與數量進行新增、修改、刪除動作後，系統必須能重新計算總金額及顯示目前購物車內容。 客戶進行線上訂購的過程中，可隨時檢視購物車內容（例如書籍編號、書籍名稱、單位、單價、數量、總金額），以瞭解目前訂購的狀況。

使用者與企業需求描述(6/8) 客戶選完欲訂購的所有書籍產品後，必須經由櫃檯結帳以確認該採購訂單，此時網頁須能顯示本次客戶訂購的所有資訊（例如書籍名稱、單價、數量及總金額等），以便客戶再次確認。 進入櫃檯結帳時，如有需要，客戶仍可以再進行新增、修改或刪除訂購項目或數量等動作。 櫃檯結帳時，客戶必須線上填寫客戶資料表及交貨地址等相關交貨資料，完成後再由其確認本次訂購內容，最後再送出一張新訂單。

使用者與企業需求描述(7/8) 客戶完成一次線上訂購行為後，交貨資料及購物車內容就拋轉成一張訂單（內容包括客戶資料與訂購內容等），並賦予訂單編號。為考量後續訂單處理作業的順暢，同一位客戶若當日有多次線上採購行為，應視為多張新訂單處理，不得要求合併成單一訂單。 系統接收到客戶送來的新訂單後，須顯示「銘謝惠顧」之類的感謝詞句，並告知客戶本次線上採購的訂單編號。 訂單尚未送出前，客戶可逕行取消該次採購訂單。此時，所有被置入購物車內的書籍資料將被清空。

使用者與企業需求描述(8/8) 表單需求 西子灣公司目前之表單需求包括訂單、客戶資料表、書籍產品型錄等，這些表單之內容與呈現方式分別以案例展示如表10-1a至表10-1c。

表10-1a 訂單

表10-1b 客戶資料表 表10-1c 書籍產品型錄 

建構使用個案圖(1/10) 建構使用個案圖之步驟依序為： 找出行為者 找出使用個案 描述使用個案 找出使用個案間之關係 最後繪出使用個案圖

建構使用個案圖(2/10) 找出行為者 行為者可從上述使用者與企業需求描述中之名詞、代名詞與名詞片語等，找出合乎行為者定義的人或相關系統。因此，從實際作業與功能需求描述可整理出客戶、書籍產品型錄、購物車、書籍產品、訂單等，而其間之關係如下： 客戶 + 閱覽 + 書籍產品型錄（參考需求描述1） 客戶 + 將書籍放入 + 購物車（參考需求描述3） 客戶+ 設定訂購數量（對） + 書籍產品（參考需求描述3＆4） 客戶 + 檢視 + 購物車（參考需求描述7） 客戶 + 送出 + 訂單（參考需求描述10） 客戶 + 取消 + 訂單（參考需求描述13） 從上述之描述，可看出唯有客戶分別與書籍產品型錄、購物車、書籍產品、訂單等產生互動，所以客戶是線上訂購系統的行為者。

建構使用個案圖(3/10) 找出使用個案 找出使用個案可逐一由行為者找出其所引發或參與的每一個事件，之後會有哪些相關事件的回應，直到完成某功能或目的，這一連串相關事件的組合（需符合內聚力原則）就可成為一個使用個案。因此，一個使用個案可以說是一連串相關事件的集合，以完成某一功能或目的。因為本個案僅有一個行為者，也就是客戶，因此我們可以直接從客戶所引發或參與的事件及其所完成的功能或目的找出所有的使用個案。行為者及其參與之使用個案可整理如下： 找出所有的

建構使用個案圖(4/10) 由使用者與企業需求1至3的一系列事件描述，可找出客戶有新增訂購項目之使用個案，客戶→新增訂購項目（購物車）。 由使用者與企業需求4&6的事件描述，可找出客戶有修改訂購數量之使用個案，客戶→修改訂購數量（購物車）。 由使用者與企業需求5&6的事件描述，可找出客戶有刪除訂購項目之使用個案，客戶→刪除訂購項目（購物車）。 由使用者與企業需求7至12的一系列事件描述，可找出客戶有確認採購訂單之使用個案，客戶→確認採購訂單（訂單）。 由用者與企業需求13的事件描述，可找出客戶有取消採購訂單之使用個案，客戶→取消採購訂單（購物車）。

建構使用個案圖(5/10) 描述使用個案 使用個案之描述，原則上以事件條列式之描述為主，應表達事件之起始行為者、動作及參與動作之物件等，其格式盡量採主詞＋動詞＋受詞方式描述。 主詞可視為一行為者，而動詞為一項處理，最後受詞可為資料或其他行為者，其中若碰上較複雜之流程與控制活動（例如有關循序或同步之活動）之描述，可用活動圖來輔助表達。 使用個案描述是從使用者之觀點描述使用者之作業行為，此時應著重作業處理或功能描述，例如內容應包括：(1)工作項目與流程；(2)工作內容；(3)資料特性，而盡量不應涉及電腦化之操作。如表 10-2a至表10-2e。

表10-2a 新增訂購項目使用個案 使用個案名稱：新增訂購項目 行為者：客戶 前提：購物車是空車或已有書籍產品 結束狀態：將書籍產品置入購物車 一系列之事件： 客戶上網，透過瀏覽器瀏覽西子灣公司網站的書籍產品型錄 客戶對本書希望獲得更進一步的資訊，可查看細部說明 客戶如果對本書有意願購買，可點選該書籍產品置入購物車內 客戶對新置入購物車內設定訂購數量(若未設定則以預設值1計之) 客戶設定訂購數量後系統自動計算購物車內的訂購金額並顯示之 計算單項產品金額＝單價×數量 計算訂購總金額＝Σ(單項產品金額) 每位客戶一次可訂購一項或多項書籍產品，訂購數量不加以限制

表10-2b 修改訂購數量使用個案

表10-2c 刪除訂購項目使用個案

表10-2d 取消採購訂單使用個案

表10-2e 確定採購訂單使用個案

建構使用個案圖(6/10) 完成上述工作後，接著須配合使用個案之流程與資料需求進一步與使用者討論（合理化與確認）表單與資訊需求。經確認後，上述使用個案中之表單等資料可用藍圖與資料詞彙整理如表10-3a至表10-5b。

表10-3a 訂單藍圖

表10-3b 訂單資料詞彙

表10-4a 客戶資料表藍圖

表10-4b 客戶資料表資料詞彙

表10-5a 書籍產品型錄藍圖

表10-5b 書籍產品型錄資料詞彙

建構使用個案圖(7/10) 找出使用個案間的關係 使用個案間的關係有三種，分別為一般化、包含與延伸。經逐一檢視每一個使用個案之描述，我們僅發現「取消採購訂單」個案中之部分行為與「刪除訂購項目」個案中有共同的行為「執行『刪除訂購項目』」的動作，因此便可將「取消採購訂單」個案中之共同行為修改成Include「刪除訂購項目」，並與「刪除訂購項目」個案間建立Include關係。 除了上述之Include關係外，「新增訂購項目」個案與「修改訂購數量」個案內也有共同行為「計算購物車內的訂購金額」，其實可以將之獨立出來成一個新的使用個案，修改兩個原個案描述，並將原個案與新個案間建立Include關係。然而，因考慮該共同行為「計算購物車內的訂購金額」僅有兩個個案參與又非常簡單，且該個案非常單純，因此保留此重複部分也可接受。

建構使用個案圖(8/10) 繪製使用個案圖 完成上述工作後，最後是繪製使用個案圖。繪製步驟為先繪出將所有行為者與使用個案，將行為者與使用個案間有互動者以互動符號連結，接著再確定使用個案間之關係，並以適當之關係符號連結，結果表達如圖10-5。

圖10-5 西子灣公司在線上訂購使用個案圖

建構使用個案圖(9/10) 完成使用個案圖後，必要時可以用活動圖來表達使用個案間之執行順序，以清楚表達系統之外部（巨觀）作業行為。由於西子灣公司線上訂購系統之作業行為如下所述，其活動圖可以表達如圖10-6。 客戶上網訂購書籍必須先執行「新增訂購項目」，讓購物車內有書籍產品，才能進行其他活動。 客戶可以反覆執行「新增訂購項目」以增加購物車內書籍產品的項目。

建構使用個案圖(10/10) 客戶執行過「新增訂購項目」後，可以選擇執行下列四項活動之一（「修改訂購數量」、「刪除訂購項目」、「取消採購訂單」、「確認採購訂單」）。由於四項活動不是平行進行，只有在成立條件符合時才會執行其中一項（如圖10-6 [決定修改訂購數量]為成立條件，假使該條件成立就執行「修改訂購數量」的活動），所以在四項活動上方用菱形表示分支。 「修改訂購數量」或「刪除訂購項目」兩個活動執行完畢後，客戶可以繼續執行「新增訂購項目」。 如果客戶選擇執行「取消採購訂單」或「確認採購訂單」，待活動完畢，本次「線上訂購作業」也一併結束。

圖10-6 西子灣公司網路購物活動圖

應用使用個案模式應注意事項 由於使用個案模式具有許多的好處且普遍被應用，它已成為物件導向技術的基礎部分，且已被整合入主要的物件導向開發方法中，但使用個案模式仍有許多限制。 以下提供一些與使用個案模式誤用有關之情況： 使用個案模式不是真正物件導向的工具。 使用個案圖原每個元素缺乏正式的定義。 使用個案是由一個或多個行為者與系統之間的交互作用定義而成，然而並不是所有的系統都一定要由行為者輸入才有反應。

使用個案模式的文件樣板(1/2) 完成使用個案塑模後，有很多相關的文件須加以整理，以便日後之系統維護或修改，這些文件至少應包括完整之使用個案圖及各個使用個案文件之記錄。 使用個案之文件至少應包括： 使用個案名稱：一個使用個案有唯一的名稱，命名要簡短且有意義，通常是以一個名詞或片語來描述。 行為者：應列出參與該個案之所有行為者。

使用個案模式的文件樣板(2/2) 前提與結束狀態：前提是指這個使用個案開始前必須成立的條件，而結束狀態是指這個使用個案結束之後必須成立的條件。 Generalization、Extend與Include之使用個案：列出與該使用個案有Generalization、Extend與Include關係之使用個案。 使用個案描述：描述其一系列之事件。

表10-6 使用個案文件樣板

結論 使用個案模式已普遍地用在物件導向的系統開發上，亦可用在結構化之系統開發。 使用個案模式與以流程圖為主之塑模工具都是功能導向，且都能表達系統與實體之互動、使用者之作業處理、程序與控制等，但是在使用者所需資訊及其展示格式之表達方面，流程圖以藍圖及資料詞彙來描述，而使用個案模式僅能以文字描述所需資訊。

表10-7 使用個案模式與流程圖之比較