UML用例圖用法詳解
本節(jié)向大家介紹一下UML用例圖，在軟件開發(fā)過程中常用到UML建模語言，而UML用例圖是UML中經(jīng)常用的建模工具，希望通過本節(jié)的介紹大家對UML用例圖有一定的了解。下面是具體介紹。
1.UML用例圖
(1)用例模型(Usecasemodel)
長期以來,在面向?qū)ο箝_發(fā)和傳統(tǒng)的軟件開發(fā)中,人們根據(jù)典型的使用情景來了解需求。但是,這些使用情景是非正式的,雖然經(jīng)常使用,卻難以建立正式文擋。用例模型由IvarJacobson在開發(fā)AXE系統(tǒng)中首先使用,并加入由他所倡導(dǎo)的OOSE和Objectory方法中。用例方法引起了面向?qū)ο箢I(lǐng)域的極大關(guān)注。自1994年IvarJacobson的著作出版后,面向?qū)ο箢I(lǐng)域已廣泛接納了用例這一概念,并認為它是第二代面向?qū)ο蠹夹g(shù)的標志。
用例模型描述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。用例模型用于需求分析階段,它的建立是系統(tǒng)開發(fā)者和用戶反復(fù)討論的結(jié)果,表明了開發(fā)者和用戶對需求規(guī)格達成的共識。首先,它描述了待開發(fā)系統(tǒng)的功能需求;其次,它將系統(tǒng)看作黑盒,從外部執(zhí)行者的角度來理解系統(tǒng);第三,它驅(qū)動了需求分析之后各階段的開發(fā)工作,不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實現(xiàn),而且被用于驗證和檢測所開發(fā)的系統(tǒng),從而影響到開發(fā)工作的各個階段和UML的各個模型。在UML中,一個用例模型由若干個用例圖描述,用例圖主要元素是用例和執(zhí)行者。
(2)用例(usecase)
從本質(zhì)上講,一個用例是用戶與計算機之間的一次典型交互作用。以字處理軟件為例,"將某些正文置為黑體"和"創(chuàng)建一個索引"便是兩個典型的用例。在UML中,用例被定義成系統(tǒng)執(zhí)行的一系列動作,動作執(zhí)行的結(jié)果能被指定執(zhí)行者察覺到。
在UML中,用例表示為一個橢圓。圖1顯示了一個金融貿(mào)易系統(tǒng)的UML用例圖。其中,"風險分析","交易估價","進行交易","設(shè)置邊界","超越邊界的交易","評價貿(mào)易","更新帳目"等都是用例的實例。概括地說,用例有以下特點:
·用例捕獲某些用戶可見的需求,實現(xiàn)一個具體的用戶目標。
·用例由執(zhí)行者激活,并提供確切的值給執(zhí)行者。
·用例可大可小,但它必須是對一個具體的用戶目標實現(xiàn)的完整描述。
(3)執(zhí)行者(Actor)
UML用例圖中執(zhí)行者是指用戶在系統(tǒng)中所扮演的角色。其圖形化的表示是一個小人。圖1中有四個執(zhí)行者:貿(mào)易經(jīng)理、營銷人員、售貨員和記帳系統(tǒng)。在某些組織中很可能有許多營銷人員,但就該系統(tǒng)而言,他們均起著同一種作用,扮演著相同的角色,所以用一個執(zhí)行者表示。一個用戶也可以扮演多種角色(執(zhí)行者)。例如,一個高級營銷人員既可以是貿(mào)易經(jīng)理,也可以是普通的營銷人員;一個營銷人員也可以是售貨員。在處理執(zhí)行者時,應(yīng)考慮其作用,而不是人或工作名稱,這一點是很重要的。
圖1中,不帶箭頭的線段將執(zhí)行者與用例連接到一起,表示兩者之間交換信息,稱之為通信聯(lián)系。執(zhí)行者觸發(fā)用例,并與用例進行信息交換。單個執(zhí)行者可與多個用例聯(lián)系;反過來,一個用例可與多個執(zhí)行者聯(lián)系。對同一個用例而言,不同執(zhí)行者有著不同的作用:他們可以從用例中取值,也可以參與到用例中。
需要注意的是執(zhí)行者在用例圖中是用類似人的圖形來表示,盡管執(zhí)行的,但執(zhí)行者未必是人。例如,執(zhí)行者也可以是一個外界系統(tǒng),該外界系統(tǒng)可能需要從當前系統(tǒng)中獲取信息,與當前系統(tǒng)有進行交互。在圖1中,我們可以看到,記帳系統(tǒng)是一個外界系統(tǒng),它需要更新帳目。
通過實踐,我們發(fā)現(xiàn)執(zhí)行者對提供用例是非常有用的。面對一個大系統(tǒng),要列出用例清單常常是十分困難。這時可先列出執(zhí)行者清單,再對每個執(zhí)行者列出它的用例,問題就會變得容易很多。
(4)使用和擴展(UseandExtend)
圖1中除了包含執(zhí)行者與用例之間的連接外,還有另外兩種類型的連接,用以表示用例之間的使用和擴展關(guān)系。使用和擴展是兩種不同形式的繼承關(guān)系。當一個用例與另一個用例相似,但所做的動作多一些,就可以用到擴展關(guān)系。例如圖1中,基本的用例是"進行交易"。交易中可能一切都進行得很順利,但也可能存在擾亂順利進行交易的因素。其中之一便是超出某些邊界值的情況。例如,貿(mào)易組織會對某個特定客戶規(guī)定***貿(mào)易量,這時不能執(zhí)行給定用例提供的常規(guī)動作,而要做些改動。我們可在"進行交易"用例中做改動。但是,這將把該用例與一大堆特殊的判斷和邏輯混雜在一起,使正常的流程晦澀不堪。圖1中將常規(guī)的動作放在"進行交易"用例中,而將非常規(guī)的動作放置于"超越邊界的交易"用例中,這便是擴展關(guān)系的實質(zhì)。當有一大塊相似的動作存在于幾個用例,又不想重復(fù)描述該動作時,就可以用到使用關(guān)系。例如,現(xiàn)實中風險分析和交易估價都需要評價貿(mào)易,為此可單獨定義一個用例,即"評價貿(mào)易",而"風險分析"和"交易估價"用例將使用它。
請注意擴展與使用之間的相似點和不同點。它們兩個都意味著從幾個用例中抽取那些公共的行為并放入一個單獨用例中,而這個用例被其他幾個用例使用或擴展。但使用和擴展的目的是不同的。
(5)UML用例圖中用例模型的獲取
幾乎在任何情況下都會使用用例。用例用來獲取需求,規(guī)劃和控制項目。用例的獲取是需求分析階段的主要任務(wù)之一,而且是首先要做的工作。大部分用例將在項目的需求分析階段產(chǎn)生,并且隨著工作的深入會發(fā)現(xiàn)更多的用例,這些都應(yīng)及時增添到已有的用例集中。用例集中的每個用例都是一個潛在的需求。
a.獲取執(zhí)行者
獲取用例首先要找出系統(tǒng)的執(zhí)行者。可以通過用戶回答一些問題的答案來識別執(zhí)行者。以下問題可供參考:
·誰使用系統(tǒng)的主要功能(主要使用者)。
·誰需要系統(tǒng)支持他們的日常工作。
·誰來維護、管理使系統(tǒng)正常工作(輔助使用者)。
·系統(tǒng)需要操縱哪些硬件。
·系統(tǒng)需要與哪些其它系統(tǒng)交互,包含其它計算機系統(tǒng)和其它應(yīng)用程序。
·對系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事物。
b.獲取用例
一旦獲取了執(zhí)行者,就可以對每個執(zhí)行者提出問題以獲取用例。
以下問題可供參考:
·執(zhí)行者要求系統(tǒng)提供哪些功能(執(zhí)行者需要做什么)?
·執(zhí)行者需要讀、產(chǎn)生、刪除、修改或存儲的信息有哪些類型。
·必須提醒執(zhí)行者的系統(tǒng)事件有哪些?或者執(zhí)行者必須提醒系統(tǒng)的事件有哪些?怎樣把這些事件表示成用例中的功能?
·為了完整地描述用例,還需要知道執(zhí)行者的某些典型功能能否被系統(tǒng)自動實現(xiàn)?
還有一些不針對具體執(zhí)行者問題(即針對整個系統(tǒng)的問題):
·系統(tǒng)需要何種輸入輸出?輸入從何處來?輸出到何處?
·當前運行系統(tǒng)(也許是一些手工操作而不是計算機系統(tǒng))的主要問題?
需要注意,***兩個問題并不是指沒有執(zhí)行者也可以有用例,只是獲取用例時尚不知道執(zhí)行者是什么。一個用例必須至少與一個執(zhí)行者關(guān)聯(lián)。還需要注意:不同的設(shè)計者對用例的利用程度也不同。例如,IvarJacobson說,對一個十人年的項目,他需要二十個用例。而在一個相同規(guī)模的項目中,MartinFowler則用了一百多個用例。我們認為:任何合適的用例都可使用,確定用例的過程是對獲取的用例進行提煉和歸納的過程,對一個十人年的項目來說,二十個用例似乎太少,一百多個用例則嫌太多,需要保持二者間的相對均衡。本節(jié)關(guān)于UML用例圖內(nèi)容介紹到這里。
【編輯推薦】
