需求用例分析之六：業務用例之科伯恩系
作者：張克強 作者微博：張克強-敏捷307
來自於科伯恩《編寫有效用例》對業務用例的說明
在《使用 UML 進行業務建模：理解業務用例與系統用例的相似和不同之處》中分析科伯恩編寫有效用比例如以下：
Cockburn 的 Writing Effective Use Cases 給業務和系統用例使用了同樣的用例說明模版。
業務用例與系統用例說明使用這個模版的差別是設計範圍，而不是模版。
Cockburn 想通過目標層次對用例進行分類。如表格1所看到的。
|
圖1： Alistair Cockburn 對業務和系統用例的分類 |
|
|
高層概要 |
|
|
概要 |
|
|
用戶目標 |
|
|
子功能 |
|
|
最低層 |
|
Cockburn 編寫 Writing Effective Use Cases 的最初目標是系統用例。但他在業務用例上也花了非常多精力。
他利用目標層次來區分業務與系統用例。而不是使用不同的模版類型。
那麽這些圖標和目標層次又意味著什麽呢？
這些圖標本身代表著一個簡單的系統，它是依據用例與“海平面”（用戶的實際層次）的相對高低來確定的。系統用例的最佳點是用戶目標，通過海平面圖標來表明。有時候須要將復雜的系統用例分解成其他有子功能目標、通過魚圖標表明的用例。可是您應該盡量避免將海平面系統用例分解成蛤或者最低層系統用例。
或許您會推測到。概要或者蛤用例應該是業務用例。雲或者高層概要也可能是業務用例。
Cockburn 的方法是將這些用例看作是一個光譜。從一個組織的最高層次業務目標。到為實現這些業務目標而運行的軟件解決方式的需求具體資料。
這樣的方法將系統用例看作是一個業務用例的分解。這個用例分解方法能夠用來幫助您從這個業務模型驅動系統用例模型。
業務用例在編寫有效用例的位置
編寫有效用例的章節安排是一開始就直接講用例，第一部分的標題用例體部分，沒有提到業務用例。是到第二部分的第15章才提到業務過程建模和業務用例，第15章總共的篇幅6頁。第2部分的標題是常常討論的主題，第12章是第二部分的第1章，標題是什麽時候才算完畢。第13章標題是擴展到多個用例；第14章標題是CRUD和參數化用例。
關於業務用例的兩個壞消息
他在第15章最後說到：
業務用例與系統用例具有同樣的特征，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。
這形成了系統用例和用戶用例之間的合作。但這樣帶來了兩個壞消息。
第一：編寫者和讀者常常把二者弄混，可能把系統行為放入業務用例中。也可能把業務操作歸於系統用例。假設可以商議著去做將會有所幫助。但通常編寫者和讀者不會認識到這樣做的重要性。使用系統用例的讀者批評業務用例所處層次太高，但卻沒有認識到提供系統具體的行為細節不是業務用例應該做的；業務用例編寫者偶爾把系統行為細節寫入當中，結果導致業務主管對這類有具體細節行為的文檔失去了興趣。
第二：全然且正確的連接系統和用戶用例不太值得。
通常，業務用例編寫者應對業務過程到系統使用（通常沒有描寫敘述）進行描寫敘述。而在描寫敘述日常生活中客戶怎樣使用新系統之前，用例編寫者已經花光時間、財力、精力以及熱情。
而系統用例編寫者有時為了保持一致，會在業務過程中加一兩句。可是他們通常不願意重寫一個包括新系統功能的業務用例。這樣就在系統用例和業務用例之間形成了空隙，即系統用例和業務用例之間的不一致。
盡管科伯恩在後面附了來自於FirePond公司使用業務用例的正面樣例，但能夠看出那是少數派。
需求用例分析之六：業務用例之科伯恩系