來自「太初有產」
乙個用例到底因該多大呢？這個問題恐怕很難說得清楚。按照我們對用例的定義來說，用例就是使用者(外部系統)和系統的一次典型互動。但是有可能這個互動特別複雜。我們來看gis系統中的乙個很普通的互動：新增圖層。對於新增圖層這個用例使用者的要求顯然是系統能夠記住這個圖層並在系統中其它地方使用，還有乙個直觀的要求就是圖層要被顯示出來。
下面是和這個用例有關的系統需求的原始文字描述:
系統需要支援新增圖層的功能。圖層的資料來源要求支援shapefile,arcsde featureclass，arcgis personal geodatabase featureclass,cad dwg檔案,jpeg影像檔案，tiff影像檔案。新增圖層後要求立即在當前螢幕範圍內顯示圖層。新增圖層後系統其它地方可以使用這個圖層來做相關的操作。
這段需求一共有四句話，第一句說明這個需求的功能，第二句規定需要支援的格式，第
三、四句說明要達到的效果。
下面我們使用前面的方法來表達這個用例:
用例編號: u-carto-001(表示和製圖有關的第001號用例)
用例名稱：新增圖層
相關需求: r-carto-001(表示和製圖有關的第001號需求)
語境目標: 新增新圖層到系統中。
前提條件：1.系統處於正常執行模式
2.使用者所指定的資料來源有效
成功結束狀態:
圖層新增到系統中，並向使用者顯示出來
失敗結束狀態:
新增圖層的要求被拒絕。
主要參與者: 使用者
次要參與者:
觸發器:
使用者要求新增新圖層
包含案例:
u-datasource-001(檢查資料有效性),u-carto-002(顯示資料)
主要流程:
步驟 動作
1. 使用者要求新增新圖層
2. 使用者選擇資料來源型別
3. 系統檢查資料有效性(執行u-datasource-001）
4. 系統構造圖層並新增到圖層列表中
5. 系統將當前顯示區域設定為圖層的資料範圍，
並重新整理(執行u-carto-002)
6. 用例結束
擴充套件步驟:
2.1
使用者取消了操作(由於沒有找到它所期望的型別，例如mapinfo的tab檔案格式)
2.2
用例結束
3.1 資料來源無效(例如 arcsde 服務連線不上，shapefile已經被破壞)
3.2
提示使用者資料來源不可用
3.3 用例結束
通過這種描述方式，尤其在熟悉了其中的包含用例和主要流程之後，我們可以很快發現這個乙個粗粒度的用例。因為它包括了其它的用例。更因為熟悉gis系統的人知道，它所包含的
資料有效性檢查和
顯示資料
這兩個用例本身就都是很龐大的。它們自身就還包含有非常多的更小的用例。
那麼，通過這個例子。我們能夠學習到什麼呢？
實際上，在我開始使用用例的時候，用例的粒度問題就一直在困擾著我。因為我一直以為用例都是比較簡短的和明確的。這樣就導致一直問題，我一開始就把系統分解的過細，到了最後系統各個用例之間一片混亂。因為我可能每天都在變化我的想法。
在仔細研究後，我幾乎可以得出這樣的結論。那就是用例是有層次性的。這種層次性由用例的《include》和《extend》關係來表達。而且通過用例的層次關係，也可以更好的對系統建模。使得用例圖更加有利於用來在系統架構這個過程中作為參考依據。
UML 用例粒度
剛剛接觸uml的時候，這個粒度搞的我一臉懵逼，但是經過系統的學習，還是將其解決了！這塊的知識屬於uml用例圖中的知識，所以在解釋名詞的時候都是以uml為根據的！以前在學軟體工程的時候有乙個名詞叫做測試用例，那個用例指的是為了測試系統的正確性提前準備的例子。在uml中的用例主要是對系統的使用者需求 主...
用例的型別與粒度
用例型別有的翻譯為版型 英文為stereotype。用例型別一般分為 普通用例 usecase 和業務用例 business usecase 業務建模的目標是通過用例模型的建立來描述使用者需求，需求規格說明書通常在這個階段產生。這個階段通常使用業務用例型別 用例分析是系統分析員採用 oo 方法來分析...
UML 理解用例
uml中用例圖的作用是從客戶的角度分析系統的需求，分析系統要達到什麼樣的目的。這些天參考了一本叫做 大象think in uml 的書，書中提到 用例驅動 那怎麼理解呢。首先來說用例，在需求中什麼是用例呢，用例是與參業者互動，並且給參與者提供可觀測的有意義的一系列活動的集合。也就是用例是參與者利用系...