經(jīng)驗總結(jié) UML用例建模技巧
本節(jié)向大家介紹一下UML用例建模技巧，在學習UML建模語言過程中經(jīng)常會遇到UML用例建模方面的問題，所以這里很有必要向大家介紹一下，相信通過本節(jié)的介紹你對UML用例建模技巧一定會有深刻的認識。
UML用例建模技巧
從參與者的角度并以主動語態(tài)編寫用例。
應該以主動語態(tài)：“學生表明參加研習班意向”，而不是被動語態(tài)“研習班意向被學生表明”來編寫用例。而且，應該從參與者的角度來編寫用例。畢竟，用例的目的是理解用戶如何對系統(tǒng)進行操作。
編寫方案文本，而非功能需求。
用例描述的是對參與者來說有價值的一系列行動，而不是特性集。例如，“招收研習班的學生”用例描述的是學生如何與系統(tǒng)交互來參加研習班。它沒有描述用戶界面看上去是什么樣子，或者它是如何工作的。有一些其它的模型來描述這些重要的信息，例如用戶界面模型和增補規(guī)范。面向?qū)ο蠓治龇浅碗s，因此需要對它使用幾種模型，并且應該適當?shù)貞妹恳环N模型。
用例只記載行為需求。
用例既不是類規(guī)范，也不是數(shù)據(jù)規(guī)范。這是應該由概念性模型捕捉的一種信息，在對象世界中，它是通過UML類模型建模的。您往往會引用概念性模型中描述的類，例如，“參加研習班”用例包括了“研習班”和“學生”等概念，它們都將由概念性模型描述。
不要忘記用戶界面。
UML用例建模技巧中，系統(tǒng)用例經(jīng)常引用主用戶界面(UI)元素，這些元素常常稱為“邊界”或“用戶界面”項，例如HTML頁面和報表。用例有時也引用一些次要的UI元素，例如按鈕或數(shù)據(jù)輸入字段，但這種級別的細節(jié)并不太常見。
創(chuàng)建用例模板。
用例包含了相當數(shù)量的信息，這些信息可以輕易地以常見格式記載。您應該考慮開發(fā)自己的模板（請參閱技巧“記載用例”）。
始終如一地組織用例圖。
一般的做法是垂直地繪制繼承(inheritance)和擴展(extend)關(guān)聯(lián)，在父／基本用例下面繪制繼承／擴展用例。同樣，通常水平繪制包含(include)關(guān)聯(lián)。請注意，這些是簡單的經(jīng)驗法則--只要始終遵循這些法則，產(chǎn)生的圖將很容易理解。
不要忘記系統(tǒng)對參與者行動的響應。
UML用例建模技巧中，用例既應該描述參與者是如何與系統(tǒng)交互的，也應該描述系統(tǒng)如何響應這些交互。例如，在“參加研習班”用例中，如果系統(tǒng)在學生表明他們希望參加研習班時沒有做出響應，學生就會很沮喪地離開。
備選行動過程非常重要。
如果一切順利，使用的將是基本行動過程--但也不要忘記備選過程。引入備選過程是為了描述潛在的使用錯誤以及商業(yè)邏輯錯誤和異常。這些重要的信息對于驅(qū)動系統(tǒng)的設(shè)計來說很有必要，因此不要忘記在用例中對它們建模。
不要被<<include>>和<<extend>>關(guān)聯(lián)所困擾。
我不是很確定到底發(fā)生了什么事，但我總是在想包含(include)和擴展(extend)關(guān)聯(lián)，以及舊版本UML中使用(uses)和擴展(extends)關(guān)聯(lián)的正確使用從來沒有得到很好的描述。結(jié)果，用例建模小組往往在這些關(guān)聯(lián)的正確應用上爭論不休，在整個建模技術(shù)中一些有趣但次要的部分上浪費了驚人的時間。我曾在一個組織中工作，這家組織居然取締了<<include>>和<<extend>>原型的使用，幾個星期后，當意識到公司仍然需要這些概念時不得不撤消了這種極端的解決方案，而這時該組織對它們的正確使用還沒有達成共識。
讓用例帶動用戶文檔。
用戶文檔的目的是描述如何使用系統(tǒng)。每個用例都描述了參與者通過使用系統(tǒng)所采取的一系列動作。簡而言之，用例包含從中開始編寫問黨用戶穩(wěn)當?shù)男畔?。例如，可以使?ldquo;參加研習班”用例作為基礎(chǔ)來編寫系統(tǒng)用戶文檔的“如何參加研習班”一節(jié)。
讓用例帶動演示。
UML用例建模技巧中，軟件開發(fā)過程中的一部分是向項目資金管理者通報工作成果，因此有時需要提供演示。因為用例是從用戶的角度編寫的，它們包含了演示中對資金管理者可能希望聽到的事物的有價值的深刻見解。換句話說，用例通常包含制定演示稿所需的邏輯。
【編輯推薦】
- 解析UML用例建模的慨念和應用
- UML用例模型及其應用解析
- UML動態(tài)建模中合作圖和活動圖解析
- UML建模過程中需要注意要點專家提醒
- 體驗免費UML建模工具
