UML 用例建模技巧

2019-11-17 04:44:34

字體：大中小

來源：轉載

供稿：網友

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

應該以主動語態：“學生表明參加研習班意向”，而不是被動語態“研習班意向被學生表明”來編寫用例。而且，應該從參與者的角度來編寫用例。究竟，用例的目的是理解用戶如何對系統進行操作。編寫方案文本，而非功能需求。

用例描述的是對參與者來說有價值的一系列行動，而不是特性集。例如，“招收研習班的學生”用例描述的是學生如何與系統交互來參加研習班。它沒有描述用戶界面看上去是什么樣子，或者它是如何工作的。有一些其它的模型來描述這些重要的信息，例如用戶界面模型和增補規范。面向對象分析非常復雜，因此需要對它使用幾種模型，并且應該適當地應用每一種模型。用例只記載行為需求。

用例既不是類規范，也不是數據規范。這是應該由概念性模型捕捉的一種信息，在對象世界中，它是通過 UML 類模型建模的。您往往會引用概念性模型中描述的類，例如，“參加研習班”用例包括了“研習班”和“學生”等概念，它們都將由概念性模型描述。不要忘記用戶界面。

系統用例經常引用主用戶界面 (UI) 元素，這些元素經常稱為“邊界”或“用戶界面”項，例如 Html 頁面和報表。用例有時也引用一些次要的 UI 元素，例如按鈕或數據輸入字段，但這種級別的細節并不太常見。創建用例模板。

用例包含了相當數量的信息，這些信息可以輕易地以常見格式記載。您應該考慮開發自己的模板（請參閱技巧“記載用例”）。始終如一地組織用例圖。

一般的做法是垂直地繪制繼續 (inheritance) 和擴展 (extend) 關聯，在父／基本用例下面繪制繼續／擴展用例。同樣，通常水平繪制包含 (include) 關聯。請注重，這些是簡單的經驗法則 -- 只要始終遵循這些法則，產生的圖將很輕易理解。不要忘記系統對參與者行動的響應。

用例既應該描述參與者是如何與系統交互的，也應該描述系統如何響應這些交互。例如，在“參加研習班”用例中，假如系統在學生表明他們希望參加研習班時沒有做出響應，學生就會很沮喪地離開。備選行動過程非常重要。

假如一切順利，使用的將是基本行動過程 -- 但也不要忘記備選過程。引入備選過程是為了描述潛在的使用錯誤以及商業邏輯錯誤和異常。這些重要的信息對于驅動系統的設計來說很有必要，因此不要忘記在用例中對它們建模。不要被 <<include>> 和 <<extend>> 關聯所困擾。

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

用戶文檔的目的是描述如何使用系統。每個用例都描述了參與者通過使用系統所采取的一系列動作。簡而言之，用例包含從中開始編寫問黨用戶穩當的信息。例如，可以使用“參加研習班”用例作為基礎來編寫系統用戶文檔的“如何參加研習班”一節。讓用例帶動演示。

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

上一篇：CMM與質量管理

下一篇：走出一般性的建模誤區