用例模組化技巧

簡介： 本文介紹了一些提高系統用例模型品質的技巧和技術。本文改編自 object primer 2nd edition 的第 6 章。

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

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

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

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

用例隻記載行為需求。

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

不要忘記使用者界面。

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

建立用例模闆。

用例包含了相當數量的資訊，這些資訊可以輕易地以常見格式記載。您應該考慮開發自己的模闆

始終如一地組織用例圖。

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

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

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

備選行動過程非常重要。

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

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

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

讓用例帶動使用者文檔。

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

讓用例帶動示範。

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