回答：原諒我的偷懶，摘錄「寫給SA的UML/UseCase實務手冊」書中的第3.7節，有我的回答。有興趣，也請您多支持這本書，謝謝 ^^
(到博客來購買本書)
----------
3.7【進階】新增/讀取/更新/刪除的問題
「針對某一種資料的新增、讀取、更新、刪除，這類基本且常見的資料維護功能，表達成什麼樣的使用案例比較適合呢？是四個分開表達嗎？還是，四個合併在一個使用案例內呢？」就跟前面的登入問題一樣，這也是學習使用案例技術的系統分析師很愛問的問題，我覺得這個問題的熱度甚至比前面的登入問題更熱門呢！
針對這個問題，通常有兩種處理方法：第一、拆成四個獨立的使用案例；第二、合併成一個使用案例。以訂單為例，可能有人主張採用圖3-60的處理方式，也有人主張採用圖3-61的處理方式。
圖3-60: 拆成四個使用案例
圖3-61: 合併成一個使用案例
到底採用哪一種處理方式好呢？我聽過很多學員跟我提到，如果採用第一種拆開的作法，那麼恐怕會得到滿手的使用案例，因為系統要維護的資料項目是很多的，特別是商用系統。但是，我們其實應該向系統的使用者找答案，而不是跟開發人員找答案。因為，別忘了，使用案例是用來表達使用者對系統的看法，而不是開發人員對系統的看法。
把這個問題丟給使用者，我們會得知，使用者並不總是在同一個時間點需要這四種使用案例，最常見的情況，反而是在四個不同的時間點上，去分別使用這四種使用案例。所以，拆成四個不同的使用案例，看起來會比合併成一個使用案例，要來得貼近使用者的需求，雖然許多開發人員可能會很不喜歡或者很不習慣。
再者，新增/讀取/更新/刪除的名稱也要改變一下，您有沒有注意到，這幾個詞彙是開發人員慣用的，但使用者恐怕會聽得很不順耳。就以訂單為例，使用者與開發人員的用詞不同，相較如下：
使用者可能會比較喜歡說「訂購書籍」；而開發人員喜歡說「新增訂單」。
使用者可能會比較喜歡說「查看訂單內容」；而開發人員喜歡說「讀取訂單」。
使用者可能會比較喜歡說「更改訂單收件人資料」；而開發人員喜歡說「更新訂單」。
使用者可能會比較喜歡說「取消訂購」；而開發人員喜歡說「刪除訂單」。
所以，這麼看來，把前面的圖3-60改成此處的圖3-62，使用者的接受度可能會更高一些。
圖3-62: 採用使用者慣用的詞彙
還有，《The Elements of UML 2.0 Style》一書的作者，也在書中編號第59條指南中，提到最好使用領域術語來為使用案例命名，亦即採用使用者的詞彙，而非開發人員慣用的詞彙。
第59條指南——使用領域術語為使用案例名稱(Name Use Cases Using Domain Terminology)
然而，真的完全不能使用像是「維護訂單」之類的使用案例嗎？其實，也不盡然。這個問題同樣要回到使用者身上，如果我們的使用者本身就是資料庫管理員，那麼對他而言，或許不需要特別將維護資料硬是拆成四個使用案例，而是可以將這四條流程合併成一個使用案例，如圖3-63和文3-30所示。
圖3-63: 維護存貨
----------
使用案例：維護存貨
事件流程：
新增存貨
1. …
讀取存貨
1. …
更新存貨
1. …
刪除存貨
1. …
----------
文3-30: 維護存貨的使用案例敘述(片段)
接著呢？可能又有人舉手發問了：「那麼可以使用如圖3-64的包含關係嗎？或者，使用如圖3-65的擴充關係呢？」
圖3-64: 包含關係
圖3-65: 擴充關係
我要說，資訊人員永遠都是窮追不捨、好學好問的一群。但我同時也要引用《Use Case Driven Object Modeling With UML: A Practical Approach》一書作者說的話：
----------
分析癱瘓警訊6——別浪費時間去擔心，倒底該採用包含關係、擴充關係、亦或是使用關係。(Don’t spin your wheels worrying about whether to use includes, extends, and/or uses.)
Top 10撰寫使用案例需避免的錯誤1——花費一個月的時間，只是為了決定該採用包含關係或是擴充關係。(Spend a month deciding whether to use includes or extends.)
----------
0 回應:
張貼意見