需求用例分析之六:业务用例之科伯恩系
作者:張克強??? 作者微博:張克強-敏捷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公司使用業務用例的正面例子,但可以看出那是少數派。
總結
以上是生活随笔為你收集整理的需求用例分析之六:业务用例之科伯恩系的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Use Cases in an Agil
- 下一篇: 需求用例分析之八:用例颗粒度