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