譚老師,你好.

我是<大象><wbr>的讀者,看了您的書收獲良多.在使用本書知識進行業務建模時,<wbr>遇到了讓我有些困惑的問題。描述如下：</wbr></wbr>

以我目前分析的餐飲管理系統為例，該系統的一項業務是，<wbr>處理顧客對餐臺的要求，包括轉臺和并臺，<wbr>轉臺就是我們所說的更換餐桌，<wbr>并臺可以理解為將多個餐桌的服務及費用和并到一個餐桌。<wbr>兩種情況因為都發生在客戶下單之后，<wbr>所以系統要及時更改服務信息，如上菜的地點等。<wbr>類似特征的業務還有很多。分析時我以“處理顧客要求”<wbr>的業務目標作為邊界，因此獲取了很多業務用例。建模時，<wbr>業務用例視圖中有很多用例，整個視圖顯得很零亂。<wbr>因此我想到了對用例“分類”，如上述例子，將“處理并臺要求”<wbr>和“處理轉臺要求”和并為“處理餐臺要求”，用來表示“<wbr>處理客戶對餐臺提出要求”。目前，我用extend關系來表示“<wbr>處理餐臺要求”與“處理并臺要求”或“處理轉臺要求”<wbr>之間的關系。但總覺得不妥，因為“extend”表示的是“<wbr>可選”關系，但實際上我想表達的是一旦客戶對餐臺提出要求，<wbr>不是并臺要求就是轉臺要求，是“必選”其中之一。因此“<wbr>處理餐臺要求”這個用例起到的作用似乎僅僅是“歸納”，<wbr>我覺得這個里有些不妥，但又不知道如何處理上述這種情況。（<wbr>不知道realize關系是否更確切）</wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr>

我本人使用UML建模時間不長，因此對一些概念的理解不深，<wbr>希望您能給予指點。</wbr>

這是個挺好的例子。先 提個小意見， “處理并臺要求”和“處理轉臺要求”業務用例的 命名不太合適。這些業務用例是為顧客服務的，顧客是業務主角。所以如果加上業務主角，連起來念成“顧客處理轉臺要求”就不通了，“餐館處理轉臺要求”才說得通。但顯然餐館并不是業務主角，只是業務工人而已。所以，業務用例命名為“要求轉臺”和“要求并臺”比較合適。

書歸正轉，我們說 業務用例必須要是明確的、完整的、獨立的表達業務主角的業務目標，例如“ 要求 并臺 ”和 “要求 轉臺 ”就是完整的、明確的目標，但你后來合并出來的“ 處理餐臺要求 ”就不是明確的（什么要求？）和獨立的（包含很多目標），它不符合業務用例的規則，所以導致你后面的困惑。

你遇到的問題是用例視圖比較零亂，其實這個并不是用例識別的問題，而是信息組織的問題。當你把多個邊界的用例都放在一起，這些用例的信息之間沒有相關性，就會顯得 零亂。所以第一，只把同一個邊界內的業務用例放在一個視圖里，或者，把每個邊界定義成一個包，相關的用例和用例視圖都放在一起；

如果同一個邊界內也有很多業務用例，并且之間也出現信息相關度不高的情況呢？這種情況一般只會發生在同一個邊界有多個業務主角的情況，多個業務主角各有各有抽象角度，即業務目標，這些抽象角度或業務目標彼此有可能是完全無關的，因此也會導致信息零亂。所以第二，在第一條的基礎上，為每個業務主角建立一個業務用例視圖，只把該業務主角的業務用例顯示在該視圖里；

如果同一個業務主角有許多的業務目標，這些業務目標明顯的分屬于不同的業務領域或可以明顯的分類，那么第三，在第一條的基礎上，為信息做分類，為每個分類建立一個用例視圖，把與該分類相關的業務用例顯示在上面。

根據上面的指導原則，你的問題就可以歸結為：1. 以“處理顧客請求”為邊界，所有與顧客請求有關的業務用例都放在這個邊界包里；2.如果有的請求是顧客提出的，有的是由服務人員代顧客提出的，或者顧客也分好幾類，那么可以為每類業務主角建立一個用例視圖，如“顧客請求視圖”，“服務人員代提請求視圖”；3.如果顧客請求分為很多類，比如并臺類的、轉臺類的，那么你可以為每個信息類別再建立用例視圖，例如“轉臺類請求用例視圖”和“并臺類請求用例視圖”。

請思考，用例視圖是用例的展示工具，每個視圖都表達了對同樣一組業務用例的不同角度的表達。所以只要需要，你就可以建立相應的視圖去展示用例。同一個用例完全有可能出現在多個視圖上。例如“要求轉臺”業務用例就既會出現在“轉臺類請求視圖”里，又會出現在“顧客請求視圖”里。 相信這樣做以后就能解決你的問題了。

留給Leo及各位網友的問題：

接下來再深入一點討論。 正如Leo所說，不管是并臺還是轉臺，甚至其它更多用例都會涉及更新上菜地點等信息。那我們怎么表達這一信息呢？可不可以建立一個命名為“ 更新 上菜地點類業務視圖”的用例視圖，然后把所有會涉及到更新上菜地點的用例都展示在該視圖里呢？ 為什么？