用例建模技巧

從參與者的角度並以主動語態編寫用例。

應該以主動語態：「學生表明參加研習班意向」，而不是被動語態「研習班意向被學生表明」來編寫用例。而且，應該從參與者的角度來編寫用例。畢竟，用例的目的是理解使用者如何對系統進行操作。

編寫方案文字，而非功能需求。

用例描述的是對參與者來說有價值的一系列行動，而不是特性集。例如，「招收研習班的學生」用例描述的是學生如何與系統互動來參加研習班。它沒有描述使用者介面看上去是什麼樣子，或者它是如何工作的。有一些其它的模型來描述這些重要的資訊，例如使用者介面模型和增補規範。物件導向分析非常複雜，因此需要對它使用幾種模型，並且應該適當地應用每一種模型。

用例只記載行為需求。

用例既不是類規範，也不是資料規範。這是應該由概念性模型捕捉的一種資訊，在物件世界中，它是通過 uml 類模型建模的。您往往會引用概念性模型中描述的類，例如，「參加研習班」用例包括了「研習班」和「學生」等概念，它們都將由概念性模型描述。

不要忘記使用者介面。

系統用例經常引用主使用者介面 (ui) 元素，這些元素常常稱為「邊界」或「使用者介面」項，例如 html 頁面和報表。用例有時也引用一些次要的 ui 元素，例如按鈕或資料輸入字段，但這種級別的細節並不太常見。

建立用例模板。

用例包含了相當數量的資訊，這些資訊可以輕易地以常見格式記載。您應該考慮開發自己的模板（請參閱技巧「記載用例」）。

始終如一地組織用例圖。

一般的做法是垂直地繪製繼承 (inheritance) 和擴充套件 (extend) 關聯，在父／基本用例下面繪製繼承／擴充套件用例。同樣，通常水平繪製包含 (include) 關聯。請注意，這些是簡單的經驗法則 -- 只要始終遵循這些法則，產生的圖將很容易理解。

不要忘記系統對參與者行動的響應。

用例既應該描述參與者是如何與系統互動的，也應該描述系統如何響應這些互動。例如，在「參加研習班」用例中，如果系統在學生表明他們希望參加研習班時沒有做出響應，學生就會很沮喪地離開。

備選行動過程非常重要。

如果一切順利，使用的將是基本行動過程 -- 但也不要忘記備選過程。引入備選過程是為了描述潛在的使用錯誤以及商業邏輯錯誤和異常。這些重要的資訊對於驅動系統的設計來說很有必要，因此不要忘記在用例中對它們建模。

不要被 <> 和 <> 關聯所困擾。

我不是很確定到底發生了什麼事，但我總是在想包含 (include) 和擴充套件 (extend) 關聯，以及舊版本 uml 中使用 (uses) 和擴充套件 (extends) 關聯的正確使用從來沒有得到很好的描述。結果，用例建模小組往往在這些關聯的正確應用上爭論不休，在整個建模技術中一些有趣但次要的部分上浪費了驚人的時間。我曾在乙個組織中工作，這家組織居然取締了 <> 和 <> 原型的使用，幾個星期後，當意識到公司仍然需要這些概念時不得不撤消了這種極端的解決方案，而這時該組織對它們的正確使用還沒有達成共識。

讓用例帶動使用者文件。

使用者文件的目的是描述如何使用系統。每個用例都描述了參與者通過使用系統所採取的一系列動作。簡而言之，用例包含從中開始編寫問黨使用者穩當的資訊。例如，可以使用「參加研習班」用例作為基礎來編寫系統使用者文件的「如何參加研習班」一節。

讓用例帶動演示。

軟體開發過程中的一部分是向專案資金管理者通報工作成果，因此有時需要提供演示。因為用例是從使用者的角度編寫的，它們包含了演示中對資金管理者可能希望聽到的事物的有價值的深刻見解。換句話說，用例通常包含制定演示稿所需的邏輯。

參考資料

用例建模技巧

用例建模技巧

UML 用例建模技巧

用例建模（設計）

用例建模技巧

用例建模技巧

UML 用例建模技巧

用例建模（設計）

相關推薦