- UML 建模、設(shè)計與分析:從新手到高手
- 夏麗華
- 5687字
- 2019-12-09 14:44:22
3.1 用例圖的構(gòu)成
用例圖是一種將用例和軟件工具相結(jié)合的圖形表示方式,它由參與者發(fā)起,主要顯示了一組用例、參與者以及它們之間的關(guān)系。
3.1.1 什么是用例圖
用例圖是由軟件需求分析到最終實現(xiàn)的第一步,它從用戶角度來描述系統(tǒng)功能,描述系統(tǒng)的參與者與系統(tǒng)用例之間的關(guān)系。
用例圖通常在進行需求分析時使用,由開發(fā)人員與用戶經(jīng)過多次商討而共同完成,這些圖以每一個參與系統(tǒng)開發(fā)的人員都可以理解的方式列舉系統(tǒng)的業(yè)務(wù)需求。
用例圖使用系統(tǒng)與一個或多個參與者之間的一系列消息來描述系統(tǒng)中的交互,它將系統(tǒng)功能劃分為對參與者(系統(tǒng)的理想用戶)有用的需求,其交互部分被稱作用例。除此之外,用例圖僅僅是從外部觀察系統(tǒng)功能,也就是從參與者使用系統(tǒng)的角度描述系統(tǒng)中的信息,并不描述這些功能在系統(tǒng)內(nèi)部的實現(xiàn)過程。
用例圖不僅包含系統(tǒng)、參與者和用例3個元素,而且還包含表示這些元素之間存在的泛化關(guān)系、關(guān)聯(lián)關(guān)系和依賴關(guān)系等各種關(guān)系。
用例圖是描述參與者與系統(tǒng)的關(guān)系,因此用例圖整體上分為3部分:參與者、系統(tǒng)和關(guān)系,通過關(guān)系將參與者與系統(tǒng)聯(lián)系起來。下圖描述了一個學(xué)生成績管理系統(tǒng)的用例圖,它是一個實際系統(tǒng)簡化后的示例。

人形表示參與者;矩形為系統(tǒng);橢圓形是用例;線條為關(guān)系,連接用例和參與者。在下面的小節(jié)中將對上述元素作詳細介紹。
3.1.2 系統(tǒng)
系統(tǒng)是用例圖的一個重要組成部分,用于執(zhí)行特定功能。它不單指一個軟件系統(tǒng),而是為用戶執(zhí)行某類功能的一個或多個軟件構(gòu)件。如圖書館管理系統(tǒng)、學(xué)生選課系統(tǒng)、信息發(fā)布系統(tǒng)等都屬于系統(tǒng)。
系統(tǒng)的邊界用來說明用例圖應(yīng)用的范圍。例如,系統(tǒng)擁有一定應(yīng)用范圍,例如一臺自動售貨機,提供售貨、供貨、提取銷售款等功能,這些功能在自動售貨機內(nèi)的區(qū)域起作用,自動售貨機外的情況將不考慮。
準(zhǔn)確定義系統(tǒng)的邊界并不總是很容易的,因為有些情況下,嚴(yán)格地劃分哪些任務(wù)是由系統(tǒng)完成,而哪些是由人工或其他系統(tǒng)完成是很困難的。另外,系統(tǒng)最初的規(guī)模應(yīng)有多大也應(yīng)該考慮。一般的做法是,先識別出系統(tǒng)的基本功能,然后以此為基礎(chǔ)定義一個穩(wěn)定的、精確定義的系統(tǒng)架構(gòu),以后再不斷地擴充系統(tǒng)功能,逐步完善系統(tǒng)。這樣做可以避免由于系統(tǒng)太大,需求分析不易明確,從而導(dǎo)致浪費大量的開發(fā)時間。
系統(tǒng)在用例圖中用一個長方框表示,系統(tǒng)的名稱被寫在方框上面或方框內(nèi)。方框內(nèi)包含了該系統(tǒng)中用符號標(biāo)識的用例,如下圖所示。

3.1.3 參與者
參與者是系統(tǒng)外的一個實體,它代表了與系統(tǒng)交互的用戶、設(shè)備或另一個系統(tǒng)。
參與者是系統(tǒng)服務(wù)的對象,通過向系統(tǒng)輸入信息或系統(tǒng)為參與者提供信息來進行交互,以實現(xiàn)系統(tǒng)功能。在確定系統(tǒng)的用例時,首要問題就是識別參與者。
1.參與者的概念
參與者用于表示使用系統(tǒng)的對象。參與者可以是一個人、一個計算機系統(tǒng)、另一個子系統(tǒng)或另外一種對象。例如,計算機網(wǎng)絡(luò)系統(tǒng)的參與者可以包括操作員、系統(tǒng)管理員、數(shù)據(jù)庫管理員和普通用戶,也可以有非人類參與者,如網(wǎng)絡(luò)打印機。參與者的特征是其作為外部用戶與系統(tǒng)發(fā)生交互。在系統(tǒng)的實際運作中,一個實際用戶可能對應(yīng)系統(tǒng)的多個參與者。同樣,不同的多個用戶也可以只對應(yīng)于一個參與者,從而代表同一個參與者的不同實例。
每個參與者定義了一個角色集合,當(dāng)系統(tǒng)用戶與系統(tǒng)相互作用時會采用它們。參與者的一個集合完整描述了外部用戶與系統(tǒng)通信的所有途徑。當(dāng)系統(tǒng)被實現(xiàn)時,參與者也被物理對象實現(xiàn)。物理對象如果可以滿足多個參與者的角色,那么它就可以實現(xiàn)多個參與者。例如,一個人可以既是商店售貨員又是顧客。這些參與者不是本質(zhì)上相關(guān)的,但是它們可以由一個人來實現(xiàn)。當(dāng)系統(tǒng)的設(shè)計被實施時,系統(tǒng)內(nèi)的多個參與者被設(shè)計成類實現(xiàn)。
在用例圖中,參與者由固定的圖形表示,并在參與者下面列出參與者的角色名。當(dāng)為用例圖中參與者命名時,給作為系統(tǒng)用戶的參與者提供一個最能描述其功能的合適名稱是非常重要的。當(dāng)為參與者命名時要避免為代表人的參與者起一個實際的人名,而應(yīng)該以其使用系統(tǒng)時的角色為參與者命名。例如下圖表示的參與者,老師表示所有以老師身份使用系統(tǒng)的人,而并不單指某個人。

參與者與系統(tǒng)的交互作用量化為用例,用例是設(shè)計系統(tǒng)和它的參與者連接的功能塊,用來完成對參與者有意義的事情。一個用例可以被一個或多個參與者使用,同樣,一個參與者也可以與一個或多個用例交互。最終,參與者由用例和參與者在不同用例中所擔(dān)任的角色決定。沒有參加任何用例的參與者是無意義的。
用例模型刻畫了一個實體(如系統(tǒng)、子系統(tǒng)或類)與外部實體相互作用時產(chǎn)生的行為的特征。外部實體是實體的參與者。對于一個系統(tǒng),參與者既可以由人類用戶實現(xiàn),也可以由其他系統(tǒng)實現(xiàn)。對于一個子系統(tǒng)或類,外部元素可以是整個系統(tǒng)的參與者,或者參與者可以是系統(tǒng)內(nèi)的其他元素,如其他子系統(tǒng)或類。
在建模初期,參與者和用例交互,但是隨著項目的進展,用例被類和組件實現(xiàn),這時參與者也發(fā)生了變化。參與者不再是用戶扮演的角色,而變成了用戶接口。例如,系統(tǒng)分析階段的用例圖中,圖書管理員與借出書目用例交互,以借出某本圖書。在設(shè)計階段,該參與者就變成了兩個元素,即圖書管理員這個角色和圖書管理員所使用的接口,用例在這時就變成了許多對象,負(fù)責(zé)處理與用戶接口以及系統(tǒng)的其他部分交互。
2.識別參與者
一個系統(tǒng)在建模之前雖然能確定一些用戶和參與者,但并不能全面地不遺漏地將參與者找出,這將導(dǎo)致建模不完善、開發(fā)不完善,開發(fā)過程中的修改又將導(dǎo)致開發(fā)效率降低,漏洞產(chǎn)生。
全面識別參與者才能使建模很好地進行下去。為了能找出所有參與者,可以借助以下幾個問題。
□ 系統(tǒng)的主要客戶是誰?
□ 誰需要借助系統(tǒng)完成日常工作?
□ 誰來安裝、維護和管理系統(tǒng),保證系統(tǒng)正常運行?
□ 系統(tǒng)控制的硬件設(shè)備有哪些?
□ 系統(tǒng)需要與哪些其他系統(tǒng)進行交互?
□ 在預(yù)定的時刻,是否有事件自動發(fā)生?
□ 系統(tǒng)是否需要定期產(chǎn)生事件或結(jié)果?
□ 系統(tǒng)如何獲取信息?
在尋找系統(tǒng)用戶時,建模人員不應(yīng)把目光只停留在使用計算機的人員身上,而應(yīng)注意直接或間接地與系統(tǒng)交互或從系統(tǒng)中獲取信息的任何人和任何事。在完成參與者的識別后,建模人員就可以從參與者的角度考慮參與者需要系統(tǒng)完成什么功能,從而建立參與者所需要的用例。
一個用例通常要與多個參與者發(fā)生交互。其中,不同的參與者所充當(dāng)?shù)慕巧煌挥行﹨⑴c者接收用例所提供的數(shù)據(jù),有些參與者則為用例提供某種服務(wù),而另一些參與者要完成系統(tǒng)的管理。這就需要將參與者分類,以保證把系統(tǒng)中所有用例都表示出來。
參與者通常可以被分為主要參與者與次要參與者兩類。其中,主要參與者是使用系統(tǒng)較頻繁、業(yè)務(wù)量較大的用戶,系統(tǒng)建模人員在識別用例時應(yīng)該首先識別主要參與者;次要參與者用來給用例提供某些服務(wù)。次要參與者與用例進行交互的主要目的是給其他參與者提供所需要的服務(wù),也就是說,次要參與者要使用系統(tǒng)的次要功能。次要功能是指完成系統(tǒng)維護的一般功能。區(qū)分主要參與者與次要參與者不應(yīng)該以參與者使用系統(tǒng)時的權(quán)限為依據(jù),一般情況下,應(yīng)該以使用系統(tǒng)時的業(yè)務(wù)量為依據(jù)。例如,在圖書管理系統(tǒng)中,將參與者以主要與次要區(qū)分,可以將參與者分成圖書管理員和系統(tǒng)管理員。其中,主要參與者負(fù)責(zé)圖書的日常借閱任務(wù),而次要管理者則完成對系統(tǒng)的維護。
除了對參與者進行主次區(qū)分外,還可以存在許多其他分類方法。例如,當(dāng)參與者使用系統(tǒng)時,它們可能會承擔(dān)著不同的“職責(zé)”,建模人員可以利用這些職責(zé)來定義參與者與系統(tǒng)間的交互,以及參與者在各種交互中所充當(dāng)?shù)慕巧⑴c者在系統(tǒng)中的角色主要包括:
□ 系統(tǒng)的啟動者。
□ 系統(tǒng)的服務(wù)者。
□ 系統(tǒng)服務(wù)的接收者。
參與者在系統(tǒng)中所扮演的第一種角色是系統(tǒng)的啟動者。啟動者是系統(tǒng)的外部實體,它們是為了完成某項事務(wù)而啟動系統(tǒng)的。一個啟動者可以請求某種服務(wù)或者觸發(fā)一個事件。例如,一個使用自動提款機提款的用戶就是該系統(tǒng)的一個啟動者。
參與者所能承擔(dān)的第二種角色就是系統(tǒng)服務(wù)者,服務(wù)者也是系統(tǒng)的外部實體,它們響應(yīng)系統(tǒng)的請求,為系統(tǒng)提供某種服務(wù)。例如,在自動提款機的提款事件中,自動提款機系統(tǒng)需要銀行的內(nèi)部系統(tǒng)提供用戶的存款信息。這個銀行內(nèi)部系統(tǒng)就是一個為系統(tǒng)提供服務(wù)的參與者。
系統(tǒng)服務(wù)接收者的主要職責(zé)是接收來自系統(tǒng)的信息。例如,使用自動提款機的用戶就是自動提款機系統(tǒng)服務(wù)的接收者。從這個示例可以看出,一個人可以在系統(tǒng)中扮演不同的參與者。
參與者的分類方式很多,最終目的就是全面不遺漏地找出參與者。在對參與者建模的過程中,開發(fā)人員必須牢記以下幾點。
□ 參與者對于系統(tǒng)而言總是外部的,因此它們可以處于人的控制之外。
□ 參與者可以直接或間接地同系統(tǒng)交互,或使用系統(tǒng)提供的服務(wù)以完成某件事務(wù)。
□ 參與者表示人和事物與系統(tǒng)發(fā)生交互時所扮演的角色,而不是特定的人或特定的事物。
□ 一個人或事物在與系統(tǒng)發(fā)生交互時,可以同時或不同時扮演多個角色。
□ 每一個參與者需要具有一個與業(yè)務(wù)一樣的名字,在建模中不推薦使用類似于“NewActor”或“新參與者”的名字。
□ 每一個參與者必須有簡短的描述,從業(yè)務(wù)角度描述參與者是什么。
□ 和類一樣,參與者可以具有表示參與者的屬性和可以接受的事件,但使用得不頻繁。
□ 多個參與者之間可以具有與類之間相同的關(guān)系。
在完成參與者的識別工作后,建模人員就可以從參與者的角度出發(fā),考慮參與者需要系統(tǒng)完成什么樣的功能,從而建立參與者所需要的用例。
3.1.4 用例
用例可以是一組連續(xù)的操作,也可以是一個特定功能的模塊。系統(tǒng)由一個或多個用例構(gòu)成,參與者與系統(tǒng)的關(guān)系主要表現(xiàn)在參與者與系統(tǒng)用例的關(guān)系。用例是一個敘述型的文檔,用來描述參與者使用系統(tǒng)完成的事件。
1.用例的概念
用例是用戶期望系統(tǒng)具備的功能,它定義了系統(tǒng)的行為特征。用例的目標(biāo)是要定義系統(tǒng)(包括一個子系統(tǒng)或整個系統(tǒng))的一個行為,但并不顯示系統(tǒng)的內(nèi)部結(jié)構(gòu)。每個用例說明一個系統(tǒng)提供給它的使用者的一種服務(wù),即一種對外部可見的使用系統(tǒng)的特定方式。它以用戶的觀點描述用戶和系統(tǒng)間交互的完整順序,以及由系統(tǒng)執(zhí)行的響應(yīng)。這里的交互只包括系統(tǒng)與參與者之間的通信,而其內(nèi)部行為和實現(xiàn)是隱藏的。一個系統(tǒng)的全部用例分割和覆蓋它的行為,每個用例代表一部分量化了的、有深刻意義的和對用戶可用的功能。
命名用例與命名參與者同樣重要。用例名可以是帶有數(shù)字、字母和除保留符號——冒號以外的任何標(biāo)點符號的任意字符串。一般情況下,命名一個用例時要盡量使用動詞加可以描述系統(tǒng)功能的名詞。例如,提取貨款、驗證身份等用例,其側(cè)重點是目標(biāo),而不是處理過程。
在UML中,用例用一個橢圓來表示,用例的名稱可以寫在橢圓的內(nèi)部,也可以寫在橢圓的外部,但通常情況下是將其名稱寫在橢圓內(nèi)部,如下圖所示。

需要注意,一定不要在一個用例圖中使用兩種命名方法,即將用例名寫在橢圓之外和橢圓之內(nèi)。因為這很容易會讓模型的讀者產(chǎn)生混淆。
一個系統(tǒng)完整的用例描述了該系統(tǒng)的所有行為,這可能導(dǎo)致用例圖中的用例非常龐大。為了組織建模信息,UML提供了包的概念,它的功能和目錄相似。為了便于使用,可以把一些相關(guān)的用例放在一個包中。這樣包就變成了包括相關(guān)功能的系統(tǒng)的子集。可以通過在用例前面加上包名和兩個冒號來確定該用例是屬于哪個包的,如下圖所示。

注意
用例只會指出系統(tǒng)應(yīng)該做什么,即系統(tǒng)的需求,而不是確切地說明系統(tǒng)不必做什么,即系統(tǒng)的非功能需求。
2.識別用例
系統(tǒng)分析者必須分析系統(tǒng)的參與者和用例,它們分別描述了“誰來做”和“做什么”這兩個問題。
識別用例最好的方法就是從分析系統(tǒng)的參與者開始,對于已經(jīng)識別的參與者,通過考慮每個參與者是如何使用系統(tǒng)的,以及系統(tǒng)對事件的響應(yīng)來識別用例。使用這種策略的過程可能會發(fā)現(xiàn)新的參與者,這對完善整個系統(tǒng)的模型是有很大幫助的。用例模型的建立是一個迭代過程。
在識別用例的過程中,通過詢問下列問題就可以發(fā)現(xiàn)用例。
□ 參與者需要從系統(tǒng)中獲取哪種功能,即參與者要系統(tǒng)“做什么”?
□ 參與者是否需要讀取、產(chǎn)生、刪除、修改或存儲系統(tǒng)中的某種信息?
□ 系統(tǒng)的狀態(tài)改變時,是否通知參與者?
□ 是否存在影響系統(tǒng)的外部事件?
□ 系統(tǒng)需要什么樣的輸入/輸出信息?
在用例識別中需要注意以下問題。
□ 用例圖中每個用例都必須有一個唯一的名字以區(qū)別于其他用例。
□ 每個用例的執(zhí)行都獨立于其他用例。
□ 用例表示系統(tǒng)中所有對外部用戶可見的行為。
□ 用例不同于操作,用例可以在執(zhí)行過程中持續(xù)接受或持續(xù)輸出與參與者交互的信息。
用例的識別也可以通過查找事件的方式來確定,即找出參與者使用系統(tǒng)時的所有操作及獲取信息,列為事件表,再根據(jù)事件表確定系統(tǒng)用例。
用例圖有以下4種標(biāo)準(zhǔn)關(guān)系。
□ 泛化關(guān)系 參與者間或用例間的關(guān)系,類似于繼承關(guān)系,可以重載。
□ 關(guān)聯(lián)關(guān)系 參與者與用例間的關(guān)系。
□ 包含關(guān)系 用例與用例的關(guān)系,將復(fù)雜的用例分解成小的步驟用例。
□ 擴展關(guān)系 用例間的關(guān)系。
3.1.5 關(guān)系
這里講的關(guān)系是參與者與用例間的關(guān)系,即關(guān)聯(lián)關(guān)系。用例圖就是描述系統(tǒng)和參與者關(guān)系的,而用例和參與者都是獨立的事物,關(guān)系就是它們之間的關(guān)聯(lián)或通信。這種通信是雙向的,參與者肯定要與某個或多個用例交互,用例也肯定會有參與者與之交互,否則參與者或用例將會成為多余。
使用一條實線連接參與者與用例,即可表明它們的關(guān)系,如下圖表示了一個用例圖中的關(guān)系。

這個簡單的示例只顯示了參與者與用例之間的一條通信關(guān)聯(lián)。
不同的參與者可以訪問相同的用例,一般來說它們和該用例的交互是不一樣的。如果一樣的話,那么參與者可能要重新定義。如果兩種交互的目的也相同,說明它們的參與者是相同的,可以將它們合并。
用例描述系統(tǒng)滿足需求的方式。當(dāng)細化描述用例操作步驟時,就可以發(fā)現(xiàn)有些用例以幾種不同的模式或特例在運行,而有些用例在整個執(zhí)行期間會出現(xiàn)多重流程。如果將用例中重要的可選性操作流程從用例中分隔出來,以形成一個新的用例,這對整個系統(tǒng)的好處是顯而易見的。
當(dāng)分離可重復(fù)使用的用例后,用例之間就存在著某種特殊關(guān)系。包含和擴展是兩個用例緊密相關(guān)時關(guān)聯(lián)用例的兩種方法。包含關(guān)系用于表示用例執(zhí)行其功能時需要從其他用例引入功能。類似地,擴展關(guān)系則表示用例的功能可以通過其他用例的功能得到擴充。
除此之外,用例與用例之間也可以有繼承關(guān)系,這種關(guān)系在用例圖中稱作泛化關(guān)系。在泛化關(guān)系中,子用例從父用例處繼承行為和屬性,還可以添加、覆蓋或改變繼承的行為,這對后期的開發(fā)很有用。
- ASP.NET Core:Cloud-ready,Enterprise Web Application Development
- Moodle Administration Essentials
- Mastering RabbitMQ
- Visual Basic程序開發(fā)(學(xué)習(xí)筆記)
- CentOS 7 Server Deployment Cookbook
- Django Design Patterns and Best Practices
- The Computer Vision Workshop
- MariaDB High Performance
- Learn WebAssembly
- Node.js Design Patterns
- HTML5 APP開發(fā)從入門到精通(微課精編版)
- 深度學(xué)習(xí):Java語言實現(xiàn)
- 深入實踐Kotlin元編程
- Laravel Application Development Blueprints
- JavaScript程序設(shè)計:基礎(chǔ)·PHP·XML