軟件工程uml課件體系結(jié)構(gòu)第17章

第十七章開發(fā)用例收集了系統(tǒng)的需求，下一步就該分析系統(tǒng)的每項需求了。這一章要學(xué)習(xí)的內(nèi)容有：●分析和描述用例?！裼美拿枋龈袷健⑶爸脳l件和后置條件?！衩枋鲇美龍?zhí)行步驟?！窭L制用例圖。第18章“收集系統(tǒng)需求”所得到的每個功能包中的用例說明了系統(tǒng)必須要做的事。開發(fā)組還必須分析和理解每個用例。開發(fā)組正在從理解領(lǐng)域逐步走向?qū)嶋H系統(tǒng)的理解。用例是兩者之間的橋梁。如果你已經(jīng)體會到系統(tǒng)開發(fā)項目是由用例驅(qū)動的，那么就能更好地理解整個開發(fā)過程。注意聯(lián)合應(yīng)用開發(fā)會議并沒有討論開發(fā)小組如何完成每個用例所涉及的活動。會議的主題僅僅是盡可能列出所有可能的用例。這一章要詳細分析上一章所列舉出的用例，并開始研究如何將WIN系統(tǒng)中的構(gòu)件具體化。開發(fā)過程進行到現(xiàn)在，要開發(fā)的具體系統(tǒng)才開始真正成為舞臺上的主角。我們將跟蹤開發(fā)組的工作，處理上一章列舉的部分用例。17.1分析和描述用例為了分析用例，還要再開一次聯(lián)合應(yīng)用開發(fā)會議，這個會議的議題是導(dǎo)出和分析每個用例。這里有一句告誡：用例聯(lián)合應(yīng)用開發(fā)會議可能是最困難的會議，因為它需要與會者(最終系統(tǒng)的可能用戶)成為系統(tǒng)分析員。在他們每個人各自的職責(zé)范圍內(nèi)，每人都是小的領(lǐng)域?qū)＜?，必須發(fā)揮出他們各自的專長。典型情況是，他們不習(xí)慣于或者不善于表達出或分析出他們所了解的業(yè)務(wù)知識。這可能是因為他們以前從沒有參與過系統(tǒng)的開發(fā)工作，缺乏經(jīng)驗?；蛘呤撬麄儾荒芎芮宄乇磉_出到底要讓系統(tǒng)為他們做什么事。為了解決或緩解這個問題，最好在組織聯(lián)合應(yīng)用開發(fā)會議時一次只請一組用戶參加(例如，一組服務(wù)員)。作為整體領(lǐng)域?qū)＜业牟宛^老板，也應(yīng)出席會議，幫助參加會議的一組服務(wù)員分析他們的用例。在處理Customer包中的用例時，包括多種用戶的混合用戶組應(yīng)當(dāng)一起參加會議。系統(tǒng)中的用例數(shù)目通常很大。為了簡化本章的內(nèi)容，我們只處理Server包中的前9個用例。學(xué)習(xí)完這些用例的處理過程后，你將能夠處理Server包中的其余用例，以及其他包中的用例。17.2用例分析回憶“用例圖”中的部分內(nèi)容：每個用例是一組場景的集合，每個場景又由一系列步驟組成。對于每個用例中的每個場景，需要說明的內(nèi)容有：●

場景的簡單陳述?！耜P(guān)于場景的假設(shè)條件?！駡鼍暗那爸脳l件?！?/p>

用例的發(fā)起參與者?！駡鼍爸信c系統(tǒng)相關(guān)的步驟序列?！駡鼍巴瓿珊蟮暮笾脳l件。●用例的受益參與者。除了上述內(nèi)容以外，還包括異常條件或可選的場景流程。本章做了適當(dāng)?shù)暮喕?。在設(shè)計文檔中(提交給客戶和程序員的用來指導(dǎo)開發(fā)的文檔)，每個用例應(yīng)當(dāng)單獨占一頁，這一頁最好包括一張用例圖，圖中畫出這個用例和用例的參與者。與系統(tǒng)相共的步驟序列在場景中極其重要。它說明了系統(tǒng)的預(yù)期工作方式。當(dāng)聯(lián)合應(yīng)用開發(fā)會議的參與者告訴分析員這些步驟序列時，也就意味著告訴了分析員系統(tǒng)最終如何工作。當(dāng)會議結(jié)束后，分析員就能得出系統(tǒng)中包括那些構(gòu)件。關(guān)于場景的假設(shè)也很重要。后面將會看到，根據(jù)這些假設(shè)清單，就可以列出設(shè)計中要注意的事項。以上說明了系統(tǒng)開發(fā)項目是由“用例驅(qū)功”的。用例是構(gòu)造系統(tǒng)的途徑。17.3Server包Server類要參與許多活動，因為Server類幾乎與其他每個類都有關(guān)聯(lián)。Server包中的用例有：17.3.1用例“Takeanorder”我們從用例“Takeanorder”開始。我們必須根據(jù)服務(wù)員提供的用例描述、假設(shè)條件、前置條件、步驟序列和后置條件來描述用例。功能包早已清楚地指明這個用例的發(fā)起參與者(Server)和受益參與者(Customer)。

對這個用例的一句話的敘述可以是“服務(wù)員將顧客的定單信息輸入到他的手提式個人計算機中并將定單信息傳遞到廚房?！奔僭O(shè)條件是顧客想就餐，顧客已經(jīng)閱讀了菜單并做出了選擇。另一個假設(shè)條件是服務(wù)員的手提式個人計算機已經(jīng)出現(xiàn)了“輸入定單”用戶界面。前置條件是顧客已經(jīng)就坐并閱讀了菜單，后置條件是定單被輸入進WIN系統(tǒng)中。用例的步驟序列是：1．服務(wù)員激活他的手提式個人計算機的“輸入定單”用戶界面。2．“輸入定單”用戶界面出現(xiàn)在顯示器屏幕上。3．服務(wù)員將顧客的菜單選項輸入到WIN系統(tǒng)中。4．系統(tǒng)將定單發(fā)送到廚房的桌面電腦。盡管我們假設(shè)“輸入定單”用戶界面的存在，但到目前為止我們根本不知道這個界面看起來是什么樣子，也沒有說明傳送定單的任何技術(shù)細節(jié)。這里的基本原則是當(dāng)我們闡述出系統(tǒng)的設(shè)計假設(shè)后，就開始考慮系統(tǒng)應(yīng)當(dāng)能夠做什么，并且要開始絞盡腦汁地思考怎樣讓系統(tǒng)做它應(yīng)當(dāng)做的事。用例的步驟序列迫使我們不得不思考組成系統(tǒng)的構(gòu)件有哪些。記住，用例分析的目標是描述出用戶所看到的系統(tǒng)。17.3.2用例“Transmittheordertothekitchen”這個用例至少應(yīng)被包含在(也就是被使用)兩個用例當(dāng)中——前一個用例和用例“Changeanorder”。

用例的敘述是：“將輸入到手提式個人計算機中的定單通過無線網(wǎng)絡(luò)傳送到廚房的桌面電腦。”假設(shè)條件是已經(jīng)具備了通信手段(通過無線網(wǎng)絡(luò))以及具備了“輸入定單”用戶界面。與其他用例的假設(shè)條件重復(fù)了的假設(shè)條件還要敘述出來嗎?是的。每個用例在設(shè)計文檔中都占單獨的頁。為了清晰起見，即使與其他用例的假設(shè)條件相同，每個用例的假設(shè)條件都應(yīng)該完整地被敘述出來。前置條件是定單信息已經(jīng)被錄入到手提式個人計算機中，后置條件是定單被正確傳遞到廚房的桌面電腦。受益參與者是Customer類。步驟序列如下：1．點擊“定單”用戶界面上的“sendtokitchen”按鈕。2．WIN系統(tǒng)將定單發(fā)送進入無線局域網(wǎng)。3．定單到達回房的桌面電腦。4．“輸入定單”用戶界面出現(xiàn)提示信息，提示定單已經(jīng)被正確傳遞到廚房的桌面電腦。很顯然，應(yīng)該修改Server包中的用例圖。必須在“Takeanorder”、“Changeanorder”這兩個用例與本用例之間添加《include》依賴關(guān)系。下圖是修改后的Server包中的用例圖。17.3.3用例“Changeanorder”下面分析用例“Changeanorder”。它的敘述是：修改一份已經(jīng)被錄入到WIN系統(tǒng)中的定單，假設(shè)條件是定單已經(jīng)被錄入并發(fā)到了廚房的桌面電腦中，但是顧客又想修改定單。進一步假設(shè)：WIN系統(tǒng)中有一個定單數(shù)據(jù)庫，服務(wù)員可以查詢該數(shù)據(jù)庫，了解到是誰輸入的定單；定單來自哪個餐桌；服務(wù)員可以通過自己的手提式個人計算機訪問數(shù)據(jù)庫；WIN系統(tǒng)可以在服務(wù)員的手提式個人計算機與廚房的桌面電腦之間雙向傳輸定單；服務(wù)員的手提式個人電腦上有“修改定單”用戶界面。

前置條件是定單已經(jīng)被傳給廚房的桌面電腦。后置條件是修改后的定單傳到廚房的桌面電腦。受益參與者是Customer。本用例的步驟序列是：1．服務(wù)員激活他的手提式個人計算機中的“修改定單”用戶界面。2．屏幕上出現(xiàn)了這名服務(wù)員已經(jīng)發(fā)送了的定單列表。3．服務(wù)員在菜單列表中選擇要修改的定單。4．服務(wù)員錄入要修改的定單的修改信息。

5．系統(tǒng)將修改后的定單發(fā)送到廚房的桌面電腦。步驟5包含了前面分析過的用例“Transmittheordertokitchen”。17.3.4用例“Trackorderstatus”

在最初的關(guān)于未來餐館的討論中涉及到確定一個顧客的定單何時完成，并從廚房傳遞出來。本用例描述的就是這項需求。在系統(tǒng)中實施這個用例對方便服務(wù)員的工作大有幫助。用例的敘述是：跟蹤已經(jīng)被輸入到WIN系統(tǒng)中的定單的狀態(tài)。假設(shè)條件有：定單已經(jīng)被發(fā)送到廚房；顧客想知道他們點的飯菜何時才能做好。此外還有兩個與前一個用例的假設(shè)條件相同的假設(shè)條件。還假設(shè)服務(wù)員的手提式個人計算機和廚房的桌面電腦中都有跟蹤定單狀態(tài)的用戶界面。前置條件是定單已被發(fā)送到廚房。后置條件是定單的狀態(tài)信息被傳送到服務(wù)員的手提式計算機中。受益參與者是Customer。步驟序列包括：1．服務(wù)員激活他的手提式個人計算機中的“跟蹤定單狀態(tài)”用戶界面。2．屏幕上出現(xiàn)這名服務(wù)員已經(jīng)發(fā)送了的定單列表。

3．服務(wù)員選擇欲跟蹤的定單。4．系統(tǒng)產(chǎn)生一個跟蹤消息到廚房的桌面電腦。5．廚房的桌面電腦收到了這條消息。6．在廚房的桌面電腦上廚師把要跟蹤定單的界面激活。7．廚師在用戶屏幕界面中輸入一個時間估計值。8．系統(tǒng)將廚師輸入的時間估計值傳給服務(wù)員的手提式個人計算機。17.3.5用例“Notifychefaboutpartystatus”

從這個用例開始，使用更小的子標題來描述用例分析的各個方面，使用黑色圓點來標記子標題下面的子標題——但有兩個例外：步驟序列的每一步前仍使用序號；用例敘述不用黑色圓點分隔。

用例敘述服務(wù)員通過無線網(wǎng)絡(luò)告訴廚師：顧客馬上就要吃完小菜。

假設(shè)條件●服務(wù)員呆在顧客所在的服務(wù)區(qū)。

●

服務(wù)員能夠端詳出顧客下一步要干什么?！裣到y(tǒng)提供了“顧客狀態(tài)”用戶屏幕界面。

●系統(tǒng)可以在服務(wù)員的手提式個人計算機和廚房的桌面電腦之間雙向傳遞信息。

前置條件●顧客幾乎就要吃完小菜。

后置條件

●

廚師做主菜的最后工序。

步驟序列1．服務(wù)員激活他的手提式個人計算機上的“顧客狀態(tài)”用戶界面。2用戶界面上出現(xiàn)了服務(wù)員所在的服務(wù)區(qū)中的餐桌列表。3．服務(wù)員在列表中選擇餐桌。4．服務(wù)員發(fā)送有關(guān)這個餐桌的一條“almostfinishedappitizer”消息給廚房的桌面電腦。5．廚房的桌面電腦接收到了這條消息。6．服務(wù)員收到了來自廚房桌面電腦的一個確認應(yīng)答消息。最后一步使用了Server包中的用例“Receiveacknowledegement”。下圖是說明這個用例及相關(guān)用例的用例圖。

受益參與者●Customer17.3.6用例“Totalupacheck”

用例敘述在定單中添加定單條目。

假設(shè)條件●系統(tǒng)中有一個能夠通過服務(wù)員手提式電腦訪問的定單數(shù)據(jù)庫?！穸▎沃械拿總€條目都有標價。

前置條件●一組顧客就餐完畢。

后置條件●計算出帳單的總價格。

步驟序列1．服務(wù)員激活有關(guān)的用戶界面，使一個活動的定單條目列表出現(xiàn)在他的手提式個人計算機的屏幕界面上。2．服務(wù)員選擇要結(jié)帳的定單。3．服務(wù)員點擊屏幕上的一個按鈕，計算帳單總價格。4．系統(tǒng)根據(jù)每個定單條目的價格計算出帳單總價，并顯示在屏幕上。

受益參與者●Customer17.3.7用例“Printacheck”盡管這個用例看起來不起眼，但在實際的交易中它是非常重要的一部分。

用例敘述打印已經(jīng)計算出總價的帳單。

假設(shè)條件●每個服務(wù)區(qū)都有一臺(無線)網(wǎng)絡(luò)打印機。

前置條件帳單總價格已被計算出。

后置條件●打印出一份帳單。

步驟序列1．服務(wù)員點擊一個按鈕。2．網(wǎng)絡(luò)打印機開始打印。3．服務(wù)員再點擊一個按鈕將這個帳單對應(yīng)的定單從活動定單列表中刪除。

受益參與者●Customer17.3.8用例“Summonanbusser”

用例敘述要求一名清潔師清理餐桌，迎接下一組顧客的到來。

假設(shè)條件●系統(tǒng)中允許兩名雇員之間進行無線通信?！裣到y(tǒng)提供了用于向一名清潔師發(fā)送消息的用戶界面。

前置條件●存在一個要被清理的餐桌。

后置條件●清潔師及時趕來，并清理和調(diào)整餐桌。

步驟序列1．服務(wù)員激活用來給清潔師發(fā)送消息的用戶界面，并給他發(fā)消息。2．服務(wù)員接收到來自清潔師的一個確認應(yīng)答消息。要包含用例“Notifychefaboutpartystatus”，最后一步也要使用“Receiveacknoelegement”用例。受益參與者●Busser17.4系統(tǒng)中的構(gòu)件用例分析的一個重要方向是揭示出組成系統(tǒng)的構(gòu)件。在本章結(jié)束之前，讓我們記錄一下在前而對Server包中的用例進行分析時都提到了系統(tǒng)中的那些構(gòu)件。在每個用例的“假設(shè)條件”段可以找到這些構(gòu)件。從軟件構(gòu)件來看，顯然要包括一組用戶界