用例圖會不會

l  簡介

 

 

n  用例圖比較官方定義是這么說的：

 

 

用例圖就是由主角、用例以及它們之間的關系構成的圖。該圖說明了用例模型中的關系。

 

n  可以從兩個方面來理解用例圖的重要性：

 

 

u 對客戶來說用例圖是他們業務領域的邏輯化表達；

 

 

u 對建設單位來說，用例圖是系統藍圖和開發的依據。

 

 

也就是說只有畫好了用例圖才能更好的了解系統的功能性需求，才能比較准確的做出客戶希望的系統。

 

 

l  遇到的問題

 

 

相信畫過用例圖的朋友一定有這么一個體會，要么滿篇一個小人幾個圓圈幾根連線——空盪盪；要么N多小人M多圓圈滿篇連線——蜘蛛網。這些都是我們所不希望的，這樣的用例圖可以說沒有存在的意義。因為失敗的用例圖不能准確的表達這個系統具備什么功能，如下面得“用電業務”用例圖（其中只畫出邊界和涉眾，未畫出各個用例，相信如果畫出各個用例將是一片蜘蛛網）。可以說失敗的用例圖使閱讀者看起來就頭大，更別說搞懂整個系統的功能需求了！

 

 

l  解決方案

 

 

造成上述問題的原因是沒有准確的找到系統邊界，進而沒有找到真正的主角（actor）！也就是說如果把一個用例的所有涉眾都畫出來，那么這個用例圖肯定是一塌糊塗的。

 

 

我們畫圖的宗旨：先找系統的邊界然后再確定對應的主角，最后才能畫出清晰明了的用例圖。

 

 

n  怎樣確定比較合理的邊界？

 

 

通過業務目標（還以上圖為例，業務目標是辦理業務和交費）可以得到相應比較合理的邊界，例如上圖的“用電客戶服務邊界”可以這么確定（如下圖）

可以清楚的看到，有了一個准確的業務目標后就可以輕松的找到這個業務的邊界。

 

 

具體的方法：只要是關於“辦理業務和交費”的操作統統屬於這個用例之內，而這個目標的受益者是“銀行”和“用電客戶”，其他的涉眾只能算是配合完成業務目標。於是自然而然的涉眾被我們划分成了內外兩部分。其中外部的涉眾（“用電客戶”和“銀行”）很可能成為業務主角，內部的涉眾（其他涉眾）很可能成為業務工人。

 

 

n  確定主角

 

 

在上面的一個步驟中我們知道了可能成為業務工人或業務主角的涉眾。

 

 

這里為什么說是可能呢？

 

 

主角一定是對系統有着希望並且直接對系統進行操作的人。

 

 

注意：在系統邊界之外的人固然可能對系統有希望，但他們不一定直接對系統進行操縱。

 

 

這也就是說需要一個代理者來行使操作這個系統的動作，而這個代理者正是我們千辛萬苦要尋找的業務主角！（如下圖）

就像上圖那樣，業務主角找到了用例自然而然就清晰鳥~

 

 

l  確定最終用例圖

 

 

以上僅僅是畫用例圖前期准備工作，真正我們最終要的用例圖才剛剛開始。

 

 

首先說明我們平時口中說的用例實際上是指系統用例，是從系統的視角來看待整個需求的。而上面我們分析了大半天的那些個用例只能叫做業務用例，是從客戶業務視角來分析需求和功能的。如果您還不是很清楚的話，以上圖中的“申請永久用電”這個業務用例為例可以推導出對應的系統用例（如下圖）

也就是說系統用例是將業務用例“具體”、“細化”，即加上要完成這項業務需要的那些其他操作，把這些小項聚集到一起就是我們最重要的也是我們苦苦追求的系統用例！

 

 

到此為止用例圖就告一段落，當然用例圖只是UML建模的開始，后面系統細化、編碼、其他圖的繪制等軟件開發的每一項都需要用例進行驅動。那些都是后話，咱以后再說……

文中用到的例子及圖片引用自《大象》，感謝原書作者提供這么好的案例