在這一部分的 Java
建模中，Granville引領(lǐng)您進(jìn)入介于建模和方法之間的區(qū)域，同時(shí)看一下通過用例建模所收集的需求。他特別著重討論了用戶接口、系統(tǒng)接口和用例描述之
間的關(guān)系。盡管現(xiàn)在正試圖在用例中包括用戶接口邏輯，但這通常被認(rèn)為是不好的形式。接著，Grancille用序列圖和系統(tǒng)接口告訴您具體原因。請點(diǎn)擊文
章頂部或底部的 討論，參與討論論壇，與本文作者和其他讀者分享您對本文的想法。
需求收集是任何成功的軟件開發(fā)周期中不可缺少的一步。雖然有眾多的需求收集方法，但是最普通的方法是用例建模。在
先前的兩個(gè)專欄中，我們已經(jīng)完成了一部分將序列圖同用例建模關(guān)聯(lián)起來的工作。這次我將更多地談?wù)摲椒ㄖ蟮睦碚摚⑶乙苍黾右恍┠慕Ｔ~匯。
這次討論中，我更關(guān)心的是闡明用戶接口、系統(tǒng)接口和用例描述之間的關(guān)系。因?yàn)樗⒌拇蠖鄶?shù)系統(tǒng)將被設(shè)計(jì)成人機(jī)交互式的，所以將用例描述設(shè)計(jì)成以用戶接口
開始運(yùn)行是很誘人的。但是在用例中包括用戶接口邏輯通常被認(rèn)為是不好的形式。這種說法的一個(gè)簡單解釋是，用戶接口提供一個(gè)系統(tǒng)透視圖的系統(tǒng)概貌。用例總是
以參與者（或用戶）透視圖被描述。
為了真正理解為什么我們在用例描述中不包括 UI
邏輯，我想無論如何我們不得不采用親身實(shí)踐的方法。我們將使用我的
第一個(gè)專欄中的貸款申請的示例，并且您將看到用例是如何隨著尺寸的增大而變得復(fù)雜的。特別地，我們要注意在用例建模中透視圖的角色。隨著我們的深入，您將看到透視圖是怎樣被用來為您工作的，或者，如果被不正確地應(yīng)用，它是如何阻礙您工作的。
什么是用例模型？
一個(gè)用例模型由一張圖表和一組闡明該用例的描述組成。一個(gè)用例是在一個(gè)系統(tǒng)中的一組可能的交互，它的參與者朝著同一個(gè)被定義的目標(biāo)進(jìn)行。這些描述描述了系統(tǒng)中該用例的功能性；這張圖表提供了這些描述的可視化路標(biāo)。UML
規(guī)定了建立用例圖表的標(biāo)準(zhǔn)，但并不是為了編寫用例描述的。結(jié)果產(chǎn)生了許多編寫用例描述的方法，這些方法有時(shí)是互相競爭的。
最流行的編寫用例描述的方法體現(xiàn)著 Ivar Jacobson
（用例建模的發(fā)明者）的思想。Jacobson
的方法涉及一系列進(jìn)入和退出的準(zhǔn)則，分別被稱作
前置條件和
后置條件，和一個(gè)稱為
事件流的核心準(zhǔn)則。這個(gè)事件流描述了一系列參與者（用戶或外部系統(tǒng)）和被制定的系統(tǒng)之間的交互。這個(gè)事件流代表一個(gè)經(jīng)過系統(tǒng)的通向成功輸出的單一路徑
。這是用例描述的核心部分，但不是全部。
事件流的交替和例外
除描述中心事件流之外，用例描述必須說明那些發(fā)生在普通事件流之外的交互。例如錄像帶租用用例的主要事件流（在簡單情況下）可以如下表示：
- 錄像帶租賃店店員掃描顧客的會(huì)員卡。
-
系統(tǒng)取得會(huì)員名和他目前的租賃狀況。一個(gè)“允許租賃”狀態(tài)表示這個(gè)顧客可以租用錄像帶。
- 錄像帶租賃店店員掃描每盤被租借的錄像帶。
-
系統(tǒng)通過掃描每盤錄像帶，將可出租的錄像帶加入到用戶可見的列表中，并顯示當(dāng)前的可出租的錄像帶列表。
-
錄像帶租賃店店員輸入應(yīng)收取的錢的數(shù)量（如果是現(xiàn)金）或者掃描信用卡。
-
系統(tǒng)標(biāo)記這盤錄像帶為已在某段時(shí)間被出租并且打印這筆交易的收據(jù)。
但是如果顧客在上次租借中欠了逾期費(fèi)怎么辦？在她能再次租借她所選的錄像帶之前，她需付清所欠的逾期費(fèi)。逾期費(fèi)的交互表現(xiàn)為一個(gè)
交替流或
例外流。事件流的交替和例外是很正常的。在某些情況下，他們可以被糾正以重新開始正常的事件流，在其他情況下，他們則達(dá)不到目標(biāo)。在我們的示例中，如果顧客付了逾期費(fèi)和這次的租金，那她就達(dá)到了繼續(xù)租借錄像帶的目的了。
用例建模中的事務(wù)處理
伴隨著它的交替和例外，事件流是由一系列的事務(wù)處理組成。
事務(wù)處理是由參與者發(fā)起，并且當(dāng)系統(tǒng)等候來自參與者的觸發(fā)信號(hào)時(shí)完成的交互（注意完成事務(wù)處理的參與者不一定就是發(fā)起該事務(wù)處理的參與者）。事務(wù)處理允許我們把用例分割成更小的元素，并在每個(gè)決定點(diǎn)上將邏輯分組。
決定點(diǎn)是在描述中參與者必須作出決定或者提供額外信息的那個(gè)點(diǎn)。
所有的事務(wù)處理是由一個(gè)參與者和一個(gè)系統(tǒng)交互組成。您將極少需要計(jì)劃一個(gè)沒有啟動(dòng)的系統(tǒng)，即使這個(gè)啟動(dòng)僅僅以時(shí)間為基礎(chǔ)。當(dāng)建立用例模型的時(shí)候，您必須確保每個(gè)啟動(dòng)被某種類型的系統(tǒng)響應(yīng)訪問到。這個(gè)調(diào)用和響應(yīng)對于用例來說是完整的。
序列圖中的事務(wù)處理
事
務(wù)處理在序列圖中是很容易識(shí)別的。在我的第一個(gè)專欄中，我介紹了只有兩個(gè)事務(wù)處理的方案。當(dāng)申請者請求新的貸款申請時(shí)，第一個(gè)事務(wù)處理被啟動(dòng)。這個(gè)事務(wù)處
理以系統(tǒng)等待申請者填寫請求和提交請求為結(jié)束。當(dāng)申請者在線提交了貸款申請時(shí)，第二個(gè)事務(wù)處理被啟動(dòng)。它以系統(tǒng)請求商業(yè)資信咨詢機(jī)構(gòu)的信用報(bào)告為結(jié)束。
圖
1 讓我們再看一下建立用來描述這個(gè)方案的序列圖 --
提交貸款請求和它的兩個(gè)事務(wù)處理。這個(gè)圖表建立了從開始到結(jié)束的兩個(gè)事務(wù)處理的模型。您將會(huì)想起，這是一個(gè)一般的序列圖，它允許我們在以后添加更多的方案
（從而加入更多的事務(wù)處理）。至少就這個(gè)開發(fā)循環(huán)的分析階段而言，當(dāng)我們添加方案時(shí)，我們將完成這個(gè)用例。然而，當(dāng)我們轉(zhuǎn)向設(shè)計(jì)的時(shí)候，我們可能發(fā)現(xiàn)我們
需要添加更多的事務(wù)處理。例如，如果我們選擇作屏幕到屏幕的確認(rèn)（代替當(dāng)前在提交時(shí)的單一確認(rèn)），我們必須在每一步確認(rèn)時(shí)添加一個(gè)事務(wù)處理。
現(xiàn)
在看一下圖
1，仔細(xì)注意事務(wù)處理的描述。以識(shí)別信息的方向從參與者到出現(xiàn)在最接近頂部的一個(gè)類或者實(shí)例為開始。正如您在下面的圖表中看到，第一個(gè)事務(wù)處理通常是從左
邊開始。沿著箭頭的順序直到您到達(dá)了另外一個(gè)參與者或者順序結(jié)束。當(dāng)順序結(jié)束時(shí)，它返回到最初的參與者。這就是一個(gè)事務(wù)處理。在圖
1 中您應(yīng)該能看到兩個(gè)完整的事務(wù)處理。
圖 1.
一個(gè)提交貸款請求用例的部分序列圖
象其他大多數(shù)用例那樣，提交貸款請求用例使用多重的事務(wù)處理。迄今為止，我們只列出了其中的兩個(gè)圖表，但是一個(gè)普通的用例使用大約
3 到 15 個(gè)事務(wù)處理。
為了理解透視圖和事務(wù)處理的關(guān)系，我們可以看一下當(dāng)兩個(gè)系統(tǒng)通訊時(shí)事務(wù)處理是如何表現(xiàn)的。一些軟件系統(tǒng)實(shí)際上是一系列互連的較小系統(tǒng)。這些較小系統(tǒng)相互合
作提供整個(gè)系統(tǒng)的功能性。每個(gè)較小系統(tǒng)只提供整個(gè)系統(tǒng)功能的一個(gè)子集。他們通過一組協(xié)議和機(jī)器接口進(jìn)行通訊，這將把我們的用例模型提高一個(gè)全新的復(fù)雜程
度。
互連系統(tǒng)的系統(tǒng)建模
當(dāng)考慮到互連系統(tǒng)時(shí)，這對建立由較小互連系統(tǒng)組成的大系統(tǒng)有意義。您可以交換一個(gè)系統(tǒng)并且用其它的系統(tǒng)替換它。您也可以獨(dú)立地建立每一個(gè)系統(tǒng)。并且您可以用許多站點(diǎn)或廠商來完成整個(gè)系統(tǒng)。
這樣一個(gè)系統(tǒng)的最好示例是典型的電話網(wǎng)絡(luò)。電話網(wǎng)絡(luò)的一部分提供撥入通道，另一部分傳送聲音或數(shù)據(jù)，還有另一部分提供帳單服務(wù)，以及有許多其它部分開展象
呼叫轉(zhuǎn)移和語音郵件這樣的服務(wù)。電話網(wǎng)絡(luò)也許是由互連系統(tǒng)組成的系統(tǒng)的一個(gè)最大的示例，并且它的連續(xù)工作也證明了這種系統(tǒng)的有效性。同樣的，懂得如何構(gòu)思
和建立這樣的系統(tǒng)模型是十分重要的。
一個(gè)相似的示例
我
們將使用一個(gè)相似的貸款處理申請來建立一個(gè)由互連系統(tǒng)組成的系統(tǒng)的模型。到現(xiàn)在，我們已經(jīng)建立了提交貸款請求用例的模型，但是這個(gè)用例實(shí)際上只是一個(gè)較大
的貸款處理系統(tǒng)的一部分。貸款提交系統(tǒng)和其進(jìn)行交互的商業(yè)資信咨詢機(jī)構(gòu)是兩個(gè)必須合作以提供必要的數(shù)據(jù)來處理貸款請求的系統(tǒng)。在現(xiàn)實(shí)生活中，還會(huì)涉及額外
的系統(tǒng)。然而，我們的示例僅僅討論兩個(gè)系統(tǒng)。圖
2
顯示了兩個(gè)系統(tǒng)、貸款提交和商業(yè)資信咨詢機(jī)構(gòu)系統(tǒng)以及我們將在這個(gè)專欄的余下部分著重討論的交互。（注意，圖
2 不是一個(gè) UML
圖表；它是一個(gè)真實(shí)世界的圖表，目的是簡單地圖示這兩個(gè)系統(tǒng)和它們之間的交互。）
圖 2.
兩個(gè)系統(tǒng)之間的交互
正如我們前面圖表說明的那樣，圖 3
從貸款提交系統(tǒng)的透視圖中顯示了提交貸款請求用例的子集。這張圖說明了我們第二次事務(wù)處理的結(jié)束是在申請者提交貸款請求時(shí)開始，在貸款提交系統(tǒng)
(
CreditChecker ) 給代表商業(yè)資信咨詢機(jī)構(gòu)
(
CreditBureau ) 的參與者發(fā)出請求時(shí)結(jié)束。
圖 3.
一個(gè)提交貸款請求用例的系統(tǒng)部分的子集
現(xiàn)在，讓我們注意來自于商業(yè)資信咨詢機(jī)構(gòu)系統(tǒng)的透視圖的這個(gè)請求。我們將以代表請求一份信用報(bào)告的一個(gè)外部系統(tǒng)
(
CreditInstitution )
的參與者開始。從商業(yè)資信咨詢機(jī)構(gòu)的透視圖來看，當(dāng)參與者請求報(bào)告時(shí)事務(wù)處理開始并且在商業(yè)資信咨詢機(jī)構(gòu)系統(tǒng)
(
CreditReporter ) 返回這個(gè)報(bào)告時(shí)結(jié)束，就如圖 4
中的圖表所示。
圖 4.
商業(yè)資信咨詢機(jī)構(gòu)系統(tǒng)的一個(gè)序列圖
回到貸款提交系統(tǒng)，我們現(xiàn)在能擴(kuò)展提交貸款請求用例以包括報(bào)告的接收。當(dāng)
CreditReporter 返回報(bào)告時(shí)，一個(gè)新的事務(wù)處理開始，并且報(bào)告被加入到與申請相聯(lián)系的信息中。然后我們可以通知貸款官員（一個(gè)新的參與者）新的申請已到達(dá)。這將是我們的貸款提交方案中的第三個(gè)事務(wù)處理。為了創(chuàng)建整個(gè)用例，我們需要再加幾個(gè)事務(wù)處理，但是我們將那個(gè)練習(xí)留到以后來做。
逆向透視圖邏輯
上面的圖表說明了互連系統(tǒng)的系統(tǒng)建模中的兩個(gè)重要方面。第一，從信息順序透視圖我們可以容易地將貸款提交和商業(yè)資信咨詢機(jī)構(gòu)系統(tǒng)作為單一的系統(tǒng)來進(jìn)行建模。圖
5 顯示了這兩個(gè)系統(tǒng)是如何在一個(gè)單一的圖表中被建模成一個(gè)系統(tǒng)的。
圖 5.
一個(gè)單系統(tǒng)的信用報(bào)告功能視圖
這項(xiàng)技術(shù)在我們開發(fā)循環(huán)的分析階段中一直起作用。然而，當(dāng)我們進(jìn)入設(shè)計(jì)階段時(shí)，兩個(gè)系統(tǒng)中的通訊機(jī)制建模的必要性使得單一的圖表過于復(fù)雜。除非我們使用一種象
CORBA （請參閱
參考資料）這樣的通訊技術(shù)，否則我們一旦進(jìn)入設(shè)計(jì)階段，就必須分別為這兩個(gè)系統(tǒng)建模。要分離它們，我們將插入一些參與者（就如圖
3 和圖 4 中所示）來分別互相代表兩個(gè)系統(tǒng)。
第二個(gè)觀察更加微妙，也是我們這周討論的中心：我們能對這些服務(wù)形成一個(gè)概念上的理解，這些服務(wù)必須通過系統(tǒng)通過觀察其它系統(tǒng)的需要來提供的。換句話說，我們可以通過查看其它系統(tǒng)的用例中的事務(wù)處理信息的子集來為每個(gè)系統(tǒng)確定概念上的接口。
接著考慮貸款提交系統(tǒng)的第二和第三個(gè)事務(wù)處理。尤其得讓我們查看第二個(gè)事務(wù)處理的
系統(tǒng)部分和第三個(gè)事務(wù)處理的
參與者部分。如果從概念上研究我們的商業(yè)資信咨詢機(jī)構(gòu)，參與者部分
(
CreditReporter )
是貸款提交系統(tǒng)的系統(tǒng)部分的一個(gè)子集。也就是說，貸款提交系統(tǒng)用例表示“系統(tǒng)向商業(yè)資信咨詢機(jī)構(gòu)發(fā)送一個(gè)請求要求信用報(bào)告的一個(gè)副本。”
另一方面，商業(yè)資信咨詢機(jī)構(gòu)系統(tǒng)用例表示“這個(gè)信用機(jī)構(gòu)參與者請求信用報(bào)告的一個(gè)副本。”這樣，商業(yè)資信咨詢機(jī)構(gòu)事務(wù)處理的參與者部分是貸款提交系統(tǒng)的第
二個(gè)事務(wù)處理的系統(tǒng)部分的一個(gè)子集。這對于第三個(gè)事務(wù)處理也是一樣的，商業(yè)資信咨詢機(jī)構(gòu)事務(wù)處理的系統(tǒng)部分是第三個(gè)事務(wù)處理的參與者部分的一個(gè)子集。換句
話說，事務(wù)處理的部分可以在兩個(gè)系統(tǒng)間逆轉(zhuǎn)。
在兩個(gè)系統(tǒng)間概念上的逆轉(zhuǎn)事務(wù)處理提供了在兩個(gè)互連系統(tǒng)間的概念上的粘合。例如，我們知道我們需要一個(gè)進(jìn)入商業(yè)資信咨詢機(jī)構(gòu)的接口，以提供來自于貸款提交系統(tǒng)接口的信用報(bào)告，貸款提交系統(tǒng)接口同樣請求這些報(bào)告。
怎樣把這個(gè)應(yīng)用到用戶接口
我們并不是經(jīng)常建立互連系統(tǒng)。然而，我們確實(shí)為我們所建立的大多數(shù)系統(tǒng)創(chuàng)建用戶接口。我們通過逆轉(zhuǎn)它們的用例事務(wù)處理將兩個(gè)系統(tǒng)間的機(jī)器接口概念化。如果我們用一個(gè)用戶接口替換一個(gè)機(jī)器接口，這也是對的。
作為這篇文章的示例所顯示的那樣，我們?yōu)槲覀兊南到y(tǒng)所建立的用戶接口將成為我們從相應(yīng)的參與者透視圖得出的用例描述的逆轉(zhuǎn)。這就是為什么不能依靠用戶接口透視圖來編寫出我們的用例。這兒的邏輯是創(chuàng)建概念上的用戶接口，但是事務(wù)處理將不得不在應(yīng)用之前被逆轉(zhuǎn)。
也就是說，如果您已經(jīng)在編寫基于 UI
的用例并能夠以這種方法提供的話，那就堅(jiān)持下去。您的提供能力比那些制定標(biāo)準(zhǔn)的頭頭們制定的標(biāo)準(zhǔn)遠(yuǎn)遠(yuǎn)重要。然而，如果使用這種方法陷入混亂，那么，您現(xiàn)在知道為什么了。
下次我們將著眼于在靈活處理中捕獲請求的不同機(jī)制，以及何時(shí)和為什么您應(yīng)該使用那些特色、用戶經(jīng)歷和在一個(gè)開發(fā)項(xiàng)目中的用例。下次見！
參考資料
關(guān)于作者
 |
| Granville 加入面向?qū)ο笊鐓^(qū)已有 13
年了。他是
高級用例建模
(Advanced Use Case
Modeling)系列的合著者，并在全世界范圍的各種面向?qū)ο蠹夹g(shù)會(huì)議中介紹過教程。他的面向?qū)ο箝_發(fā)的實(shí)踐方法來自于他在多家公司供職的經(jīng)驗(yàn)，其中包括從處于創(chuàng)業(yè)階段的公司到相當(dāng)成熟的軟件業(yè)巨擘在內(nèi)的各種公司。
他目前正在教授有關(guān)靈活過程、方法和 Java
技術(shù)的研習(xí)班、教程和課程，同時(shí)還在輔導(dǎo)和幫助實(shí)現(xiàn)一些積極的項(xiàng)目。可以通過
rmiller@togethersoft.com
與 Granville 聯(lián)系。
|