為基本用例建模

基本建模是以使用為核心的設計的基本方面。本周 Scott Ambler 介紹有關開發基本用例模型的一些背景知識和建議。
需求建模中的重要目的是要理解系統將處理的業務問題，以理解它的行為需求。至于面向對象的開發，您應該開發以對行為需求建模的基本構件是用例模型。用例圖表是標準的“統一建模語言 (UML)”構件之一。用例模型有兩種基本風格：基本用例模型和系統用例模型。 基本用例模型，通常稱為商業或抽象用例模型，對行為需求的與技術無關的視圖建模。 系統用例模型，也稱為具體用例模型或詳細用例模型，為行為需求的分析建模，詳細描述用戶將如何使用系統，同時它還提及系統用戶接口方面的問題。

什么是基本建模？
基本建模是以使用為核心的設計的基本方面——它是一種軟件開發方法，Software for Use 一書（請閱讀參考資料）詳細描述了該方法?；灸Ｐ椭荚谕ㄟ^與技術無關、理想化和抽象的描述來表示問題本質。產生的設計模型更加靈活，它使更多選項公開并且在技術方面更容易進行更改?；灸Ｐ捅染唧w表示法更加強健，這是因為在需要更改需求和更改實現技術時，它們更易保持有效。用法的基本模型強調目的，即用戶試圖實現什么任務以及他們這樣做的原因。簡而言之，基本模型是表示系統需求的理想構件。

什么是用例？
用例是向參與者提供重要價值的操作序列。認識它的另一種途徑是：用例描述實際參與者與系統交互的方式?；居美且环N簡化、抽象且通用的用例，它以獨立于技術和實現的方式描述用戶的意圖?；居美且环N結構化的敘述，用應用程序領域和用戶的語言來表達，它包含對任務或交互的簡化、通用、抽象、與技術無關且獨立于實現的描述。從擔當某個（或某些）系統角色的用戶的觀點來看，基本用例是完整而有意義的，并且設計得很好，這就體現了交互背后的目的或意圖。

比較系統用例和基本用例
請仔細查看示例 1 和示例 2 提供的兩種版本的用例“參加研習班”，前者顯示了簡化的系統用例（也稱作傳統或具體用例），后者將它表示為基本用例。經過觀察，我們會發現以下一些有趣事項：

系統用例嵌入了很多實現細節。例如，登記員的概念消失并且被術語系統取代，這表示已經決定自動處理許多有關參加的瑣碎事件。系統用例的作者分析和描述了由混有關于將使用什么樣的用戶界面的隱含決策的問題所引發的需求；而基本用例的作者不這樣做。 系統用例提及屏幕和報告，如“UI23 安全性登錄屏幕”和“UI89 登記摘要報告”。 基本用例不引用它們。這再一次反映了實現的詳細信息；某人已經決定系統將作為屏幕（或許與 HTML 頁面相反）和打印的報告實現。然而，基本用例也可以只簡單地引用主要的用戶界面元素（即，屏幕和報告的基本版本），并且告訴您，這是我推薦的作法。 我沒有在示例 2 中引用 UI 元素， 以便為您提供沒有執行這些任務的示例。 因為商業規則反映系統必須實現的域的基本特征，所以兩種版本都引用商業規則定義，如“BR129 確定參加資格”。 系統用例的步驟比基本用例的步驟多。實際上，這反映了我編寫用例的風格；我相信每個用例步驟應該只反映一個步驟。這種方法有幾個優點：用例更容易測試，因為每條語句都更加容易理解和驗證；備用課程更加容易編寫，因為當語句只做一件事時更容易從語句中分支。 用例步驟以主動語態、而不是以被動語態編寫。語句“登記員通知學生有關收費情況”比語句“學生被登記員通知有關收費情況”更加簡潔。 兩個版本都以類似“用例結束”或“在某些情況下用例結束”的步驟結束，以表示已經完全定義了操作過程的邏輯。
通常，傳統或系統用例本身對有關基本技術實現和有待設計的用戶界面方面所作的假設太多，通常是隱藏的或暗示的。在分析和設計期間，這是一個較好的特性，但對于您的需求實現來講，并不理想。另一方面，基本用例基于用戶的目的或意圖，而不是基于實現目的或意圖可能依據的具體步驟或機制。編寫基本用例作為所需的構思工作的一部分，然后在分析和設計期間，將它們發展成系統用例。

原文轉自：http://www.anti-gravitydesign.com