《基于任務(wù)驅(qū)動模式的軟件工程與UML建模技術(shù)》課件項目九

項目九需求建模任務(wù)一認識用例模型

任務(wù)二使用RationalRose繪制用例圖

任務(wù)一認識用例模型

1992年由Jacobson提出的UseCase的概念及可視化的表示方法—UseCase圖，受到了IT界的歡迎，被廣泛應(yīng)用到了面向?qū)ο蟮南到y(tǒng)分析中。用例驅(qū)動的系統(tǒng)分析與設(shè)計方法已成為面向?qū)ο蟮南到y(tǒng)分析與設(shè)計方法的主流。

用例模型由Jacobson在開發(fā)AXE系統(tǒng)中首先使用，并加入由他所倡導(dǎo)的OOSE和Objectory方法中。用例方法引起了面向?qū)ο箢I(lǐng)域的極大關(guān)注。自1994年IvarJacobson的著作出版后，面向?qū)ο箢I(lǐng)域已廣泛接納了用例這一概念，并認為它是第二代面向?qū)ο蠹夹g(shù)的標(biāo)志。

操作一用例模型概述

用例模型是軟件系統(tǒng)模型的核心。用例圖用于描述系統(tǒng)的功能需求，在宏觀上給出模型的總體輪廓。通過對典型用例的分析，開發(fā)者能夠有效地了解用戶的需求。用例就是從功能的角度來描述系統(tǒng)。通常情況下在系統(tǒng)需求分析階段通過用例來描述參與者是如何使用系統(tǒng)的，因此用例建模通常也稱為需求建模。

1．用例模型的功能

用例模型是把應(yīng)滿足用戶需求的基本功能(集)聚合起來表示的強大工具。

對于正在構(gòu)造的新系統(tǒng)，用例描述該系統(tǒng)應(yīng)該做什么；對于已構(gòu)造完畢的系統(tǒng)，用例則反映了系統(tǒng)能夠完成什么樣的功能。

構(gòu)建用例模型是通過系統(tǒng)開發(fā)者與系統(tǒng)的客戶(或最終使用者)共同協(xié)商完成的，他們要反復(fù)討論需求的規(guī)格說明,達成共識，明確系統(tǒng)的基本功能，為后續(xù)階段的工作打下基礎(chǔ)。另外，系統(tǒng)開發(fā)過程中涉及的各種不同的人員都可以從用例模型中受益：客戶使用用例模型，因為它詳細說明了系統(tǒng)應(yīng)有的功能且描述了系統(tǒng)的使用方法，這樣當(dāng)客戶選擇執(zhí)行某個操作之前，就能知道模型工作起來是否與他的愿望相符合；開發(fā)者使用它，因為它幫助開發(fā)者理解系統(tǒng)應(yīng)該完成些什么工作，為其將來的開發(fā)工作奠定基礎(chǔ)；系統(tǒng)集成和測試人員使用它，因為它可用于驗證被測試的實際系統(tǒng)與其用例圖中說明的功能是否一致；其他人員包括市場、銷售、技術(shù)支持和文檔管理這些方面的人員也同樣關(guān)心用例模型。

2．用例模型的基本組成

用例模型的基本組成部件是用例、參與者和系統(tǒng)。用例用于描述系統(tǒng)的功能，也就是從外部用戶的角度觀察系統(tǒng)應(yīng)具備哪些功能，幫助分析人員理解系統(tǒng)的行為，它是對系統(tǒng)功能的宏觀描述。一個完整的系統(tǒng)中通常包含若干個用例，每個用例具體說明應(yīng)完成的功能，它們代表系統(tǒng)的所有基本功能(集)。

參與者是與系統(tǒng)進行交互的外部實體，它可以是系統(tǒng)用戶，也可以是其它系統(tǒng)或硬件設(shè)備，總之，凡是需要與系統(tǒng)交互的東西都可以稱做參與者。系統(tǒng)的邊界線以內(nèi)的區(qū)域(即用例的活動區(qū)域)則抽象表示系統(tǒng)能夠?qū)崿F(xiàn)的所有基本功能。在用例模型中，系統(tǒng)仿佛是實現(xiàn)各種用例的“黑盒子”，我們只關(guān)心該系統(tǒng)實現(xiàn)了哪些功能，并不關(guān)心內(nèi)部的具體實現(xiàn)細節(jié)。

3．引用用例的目的

(1)確定系統(tǒng)應(yīng)具備哪些功能，這些功能是否滿足系統(tǒng)的需求(開發(fā)者與用戶協(xié)商達成共識的東西)。

(2)為系統(tǒng)的功能提供清晰一致的描述，以便為后續(xù)的開發(fā)工作打下良好的交流基礎(chǔ)，方便開發(fā)人員傳遞需求的功能。

(3)為系統(tǒng)驗證工作打下基礎(chǔ)。通過驗證最終實現(xiàn)的系統(tǒng)能夠執(zhí)行的功能是否與最初需求的功能相一致，保證系統(tǒng)的實用性。

操作二用例圖組成

UML用例圖是非常有用的一種圖，在軟件開發(fā)中的需求分析階段，可以讓人們從繁重的文檔中解脫出來，并且促使人們在做需求時能夠更加準(zhǔn)確、直觀地表達自己的意思。用例模型是用例圖描述的，用例模型可以由若干個用例圖組成。用例圖中包含系統(tǒng)、參與者和用例三種模型元素。繪制用例圖時既要畫出三種模型元素，同時還要畫出元素之間的各種關(guān)系。

1．參與者

1)什么是參與者

參與者不是特指人，是指系統(tǒng)以外的，在使用系統(tǒng)或與系統(tǒng)交互中所扮演的角色。因此參與者可以是人，可以是事物，也可以是時間或其他系統(tǒng)等。參與者在畫圖中用簡筆人物畫來表示，人物下面附上參與者的名稱(見圖9-1)：

圖9-1參與者的表達方式

2)識別參與者

●使用系統(tǒng)主要功能的人是誰(即主要角色)？

●需要借助于系統(tǒng)完成日常工作的人是誰？

●誰來維護和管理系統(tǒng)(次要角色)，保證系統(tǒng)正常工作？

●系統(tǒng)控制的硬件設(shè)備有哪些？

●系統(tǒng)需要與哪些其它系統(tǒng)交互？其它系統(tǒng)包括計算機系統(tǒng)，也包括該系統(tǒng)將要使用的計算機中的其它應(yīng)用軟件。其它系統(tǒng)也分成二類，一類是啟動該系統(tǒng)的系統(tǒng)，另一類是該系統(tǒng)要使用的系統(tǒng)。

●對系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事是哪些？在確定具體參與者時，可以通過以下一些常見的問題來幫助分析：誰使用這個系統(tǒng)，誰安裝這個系統(tǒng)，誰啟動這個系統(tǒng)，誰維護這個系統(tǒng)，誰關(guān)閉這個系統(tǒng)，誰也能使用這個系統(tǒng)，誰從這個系統(tǒng)獲取信息，誰為這個系統(tǒng)提供信息，是否有事情在預(yù)計的時間自動發(fā)生(說明有定時器)，系統(tǒng)是否需要與外部實體交互以幫助自己完成任務(wù)。一旦參與者被標(biāo)識出來后，需求獲取的下一步活動決定了每一個參與者將訪問的功能。

3)參與者之間的關(guān)系

參與者是一種類，因此，可以將參與者之間的關(guān)系進行泛化。通過參與者泛化可以簡化模型，使模型更簡潔。

例如，在軟件系統(tǒng)開發(fā)過程中，系統(tǒng)分析師(子類)和項目經(jīng)理(子類)都屬于系統(tǒng)設(shè)計師(父類)，他們都能承擔(dān)系統(tǒng)設(shè)計師的工作。用UML圖表示他們之間的關(guān)系，如圖9-2所示。圖9-2參與者之間的關(guān)系

2．系統(tǒng)

系統(tǒng)是用例模型的一個組成部分，代表的是一部機器或一個商務(wù)活動等，而并不是真正實現(xiàn)的軟件系統(tǒng)。系統(tǒng)的邊界用來說明構(gòu)建的用例模型的應(yīng)用范圍，比如，一臺自助式售貨機(被看做系統(tǒng))應(yīng)提供售貨、供貨、提取銷售款等功能，這些功能在自動售貨機之內(nèi)的區(qū)域起作用，自動售貨機之外的情況不考慮。準(zhǔn)確定義系統(tǒng)的邊界并不是十分容易的事，因為嚴(yán)格劃分哪種任務(wù)最好由系統(tǒng)自動實現(xiàn)，哪種任務(wù)由其他系統(tǒng)或人工實現(xiàn)是很困難的。另外，系統(tǒng)最初的規(guī)模應(yīng)有多大也應(yīng)該考慮。一般做法是，先識別出系統(tǒng)的基本功能(集)，然后以此為基礎(chǔ)定義一個穩(wěn)定的、精確定義的系統(tǒng)架構(gòu)，以后再不斷地擴充系統(tǒng)功能，逐步完善。這樣做的好處在于避免了一開始系統(tǒng)太大，需求分析不易明確，從而導(dǎo)致浪費大量的開發(fā)時間。

用例圖中的系統(tǒng)用一個長方框表示，系統(tǒng)的名字寫在方框上或方框里面，方框內(nèi)部還可以包含該系統(tǒng)中的用符號表示的用例。

3．用例

1)什么是用例

用例(UseCase)：表示參與者與系統(tǒng)的一次交互過程。用例用橢圓表示，如圖9-3所示。圖9-3用例用例將系統(tǒng)當(dāng)做一個“黑匣子”，它從外部來看與系統(tǒng)之間的信息交換(包括系統(tǒng)的回答)。這樣它簡化對系統(tǒng)的需求的描寫，而且防止對系統(tǒng)的工作方式作任何過早的假設(shè)。有時候我們需要在系統(tǒng)內(nèi)部定時地執(zhí)行一些操作，如檢測系統(tǒng)資源使用情況、定期地生成統(tǒng)計報表等。從表面上看，這些操作并不是由外部的人或系統(tǒng)觸發(fā)的，應(yīng)該怎樣用用例方法來表述這一類功能需求呢？對于這種情況，我們可以抽象出一個系統(tǒng)時鐘或定時器參與者，利用該參與者來觸發(fā)這一類定時操作。從邏輯上，這一參與者應(yīng)該被理解成是系統(tǒng)外部的，由它來觸發(fā)系統(tǒng)所提供的用例對話，如圖9-4所示：圖9-4用例與參與者

2)用例的特點(見圖9-5)

●用例用于描述系統(tǒng)的功能，這個功能是外部使用者看到的系統(tǒng)功能，不反映功能的實現(xiàn)方式。

●用例描述用戶提出的一些可見需求，對應(yīng)一個具體的用戶目標(biāo)。

●用例反映系統(tǒng)與用戶的一次交互過程，應(yīng)該具有交互的信息的傳遞。

●用例是對系統(tǒng)功能的描述，屬于需求建模。圖9-5用例特點

3)用例之間的關(guān)系

在需求分析時，當(dāng)標(biāo)識出參與者后，下一步就是識別用例、組織用例。所謂組織用例，就是首先識別用例之間的關(guān)系，使系統(tǒng)中的用例構(gòu)成一個用例圖。UML有4種用例關(guān)系：關(guān)聯(lián)、包含、擴展和泛化。

(1)關(guān)聯(lián)關(guān)系。

用單向箭頭表示，只表示誰啟動用例，不考慮信息的雙向流動。每個用例都有角色啟動，除包含和擴展用例。無論用例和角色是否存在雙向數(shù)據(jù)交流，關(guān)聯(lián)總是由角色指向用例。如圖9-6所示。圖9-6關(guān)聯(lián)關(guān)系

(2)包含關(guān)系。

包含關(guān)系是通過在關(guān)聯(lián)關(guān)系上應(yīng)用<<include>>構(gòu)造型來表示的，如圖9-7所示。它所表示的語義是指基礎(chǔ)用例會用到被包含用例(Inclusion)，具體地講，就是將被包含用例的事件流插入到基礎(chǔ)用例的事件流中。圖9-7包含關(guān)系

(3)泛化關(guān)系。

泛化又稱為繼承，當(dāng)多個用例共同擁有一種類似的結(jié)構(gòu)和行為的時候，可以將它們的共性抽象成為父用例，其他的用例作為泛化關(guān)系中的子用例，如圖9-8所示。在用例的泛化關(guān)系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系。在實際應(yīng)用中很少使用泛化關(guān)系，子用例中的特殊行為都可以作為父用例中的備選流存在。圖9-8泛化關(guān)系

(4)擴展關(guān)系。

擴展(Extend)關(guān)系是指基礎(chǔ)用例中定義有一至多個已命名的擴展點，擴展關(guān)系是指將擴展用例(Extension)的事件流在一定的條件下按照相應(yīng)的擴展點插入到基礎(chǔ)用例中。例如對于電話業(yè)務(wù)，可以在打電話業(yè)務(wù)上擴展出一些增值業(yè)務(wù)如：呼叫等待和呼叫轉(zhuǎn)移，而這兩個用例在打電話過程中并不一定會被使用?？梢杂脭U展關(guān)系將這些業(yè)務(wù)的用例模型進行描述，如圖9-9所示。圖9-9擴展關(guān)系

4)識別和描述用例

要識別和描述軟件系統(tǒng)中的用例，首先要弄清楚系統(tǒng)的問題域、業(yè)務(wù)流程，整理出系統(tǒng)的功能需求，在此基礎(chǔ)上結(jié)合已經(jīng)識別出來的參與者，識別、抽象出系統(tǒng)用例，并對整個系統(tǒng)用例進行描述。

(1)識別用例。

①與系統(tǒng)實現(xiàn)有關(guān)的主要問題是什么？

②系統(tǒng)需要哪些輸入/輸出？這些輸入/輸出從何而來，到哪里去？

③執(zhí)行者需要系統(tǒng)提供哪些功能？

④執(zhí)行者是否需要對系統(tǒng)中的信息進行讀、創(chuàng)建、修改、刪除或存儲？

(2)用例描述。

圖形化的用例本身不能提供該用例所具有的全部信息，因此還必須描述不可能反映在用例圖上的信息，通常使用文字描述用例的這些信息。描述用例時，應(yīng)著重描述從外界看來會有什么樣的行為，而不管該行為在系統(tǒng)內(nèi)部是如何具體實現(xiàn)的，即只管外部能力，不管內(nèi)部細節(jié)。用例描述模板如圖9-10所示。用例描述實例如圖9-11所示。圖9-10用例描述模板圖9-11用例實例①用例的目標(biāo)。

用例的最終任務(wù)是什么？想得到什么樣的結(jié)果？即每個用例的目標(biāo)一定要明確。

②用例是怎樣被啟動的。

哪個參與者在怎樣的情況下啟動執(zhí)行用例。

③參與者和用例之間的消息流。

參與者和用例之間的哪些消息是用來通知對方的？哪些是修改或檢索信息的？哪些是幫助用例做決定的？系統(tǒng)和參與者之間的主消息流描述了什么問題？系統(tǒng)使用或修改了哪些實體？④用例的多種執(zhí)行方案。

在不同的條件或特殊情況下，用例能根據(jù)當(dāng)時條件選擇一種合適的執(zhí)行方案。

⑤用例怎樣才算完成并把值傳給參與者。

描述中應(yīng)明確指出在什么情況下用例才能被看做完成，當(dāng)用例被看做完成時要把結(jié)果值傳給參與者。任務(wù)二使用RationalRose繪制用例圖

操作一創(chuàng)建用例圖

從用例圖中我們可以看到系統(tǒng)在做什么、與誰交互。用例是系統(tǒng)提供的功能，參與者是系統(tǒng)與誰交互，參與者可以是人、系統(tǒng)或其他實體。一個系統(tǒng)可以創(chuàng)建一個或多個用例圖。

在瀏覽器內(nèi)的UseCase視圖中，雙擊“Main”，讓新的用例圖顯示在框圖窗口中。也可以新建一個包(右擊UseCase視圖，選擇“new”→“package”，并命名)，然后右擊這個新建包的，選擇“new”→“usecasediagram”。如圖9-12所示。系統(tǒng)總的用例一般畫在UseCase視圖中的“Main”里，如果一個系統(tǒng)可以創(chuàng)建多個用例圖，則可以用包的形式來組織。圖9-12創(chuàng)建用例圖

操作二創(chuàng)建參與者

(1)在工具欄中選擇“Actor”，光標(biāo)的形狀變成加號。

(2)在用例圖中要放置參與者符號的地方單擊鼠標(biāo)左鍵，鍵入新參與者的名稱，如“客戶”。

(3)若要簡要地說明參與者，可以執(zhí)行以下步驟：

①在用例圖或瀏覽器中雙擊參與者符號，打開對話框，而且已將原型(Stereotype)設(shè)置定義為“Actor”。

②打開“General”選項卡，在“Documentation”字段中寫入該參與者的簡要說明。

③單擊【OK】按鈕，即可接受輸入的簡要說明并關(guān)閉對話框。

如圖9-13所示。圖9-13創(chuàng)建參與者

操作三創(chuàng)建用例

(1)在工具欄中選擇“UseCase”，光標(biāo)的形狀變成加號。