demogorgon   use case 圖是否可以分層次畫？
　
http://www.umlchina.com/best/g34/u1151169.htm
--------------------------------------------------------------------------------
 
比如有一個use case圖包含了“信用管理”這樣一個用例，可是“信用管理”有 
可能有很多內容，如果把所有的用例都分解很細可能會使圖太復雜，難以理解。 
那么有沒有可能分層次畫出？ 畫用例圖時有需要注意說不能畫成功能分解，那么應該怎么樣做才是比較正確的？
 
 03/09/27 13:50 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 wyhacker  回復: use case 圖是否可以分層次畫？
　
--------------------------------------------------------------------------------
 
　　Use Case 是過程抽象，不是概念抽象。是把過程相似的活動組織在一起，而不是把與某一類事物相關的業務放到一起。 
　　Use Case 有層次，如Business Use Case、System Use Case。但是這種層次與數據流程圖中的層次決不一樣。比如說，統一過程中，一個好的System Use Case在開發過程中將一直保持穩定，從而驅動系統開發向推進。如果說，你的Use Case過于復雜，那不是對Use Case理解有誤，就是Use Case粒度沒有選好。
 
 03/09/27 14:33 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 mengyuetao  不如把它分為不同的用例文件！
　
--------------------------------------------------------------------------------
 
 03/09/27 14:53 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 chenhuijun   回復: use case 圖是否可以分層次畫？
　
--------------------------------------------------------------------------------
 
我也有同樣的困惑，看過一些資料，都說明了一個意思：用例是表達一個有意義的用戶業務過程。但是，這些有意義的業務過程是由一些具體的步驟組成，也就是很多人經常認為的“子用例”。這些具體的步驟可以作為用例場景中的具體路徑進行描述。這也就說明單憑用例圖是不能清楚地描述真正的用例的，還要借助于詳細的文檔。有的人說常用的操作CRUD是不能作為用例存在的，因為他沒有真正的意義，我也同意。不過今天我看了RoseTutorial中的例子，為什么在它的用力圖中所謂的“Create New Order”“Edit Order”等等可以作為用例呢？請高手指點。是不是只要將業務描述清楚就可以了，不必拘泥于所謂的規則，是吧？
 
 03/09/27 15:57 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 wyhacker  回復: use case 圖是否可以分層次畫？
　
--------------------------------------------------------------------------------
 
　　不管什么時候，用例的粒度可能都是一個困擾人的問題。我個人認為用例的粒度分為兩個維度。一是橫向，一是縱向。橫向就是過程的抽象程度。縱向就是過程的總體長度。 
　　用例常常是幾個相似過程的抽象，換句話說用例描述的可能是幾個業務過程，而不一定就是一個業務過程，但前題是他們相似、相關。至于以“Create New Order”、“Edit Order”作為用例，我認為是很正常的。對于“Edit Order”用例，很可能包括修改、查看、添加項（Item）、刪除項等相實際過程。畫出他們的活動圖，看一下，他們的過程應該是很相似的。 
　　另一方面，在縱向維度上，其大小應該以易于應用為原則。畢竟，用例是用來驅動整個開發的。如果在用例中，用戶與系統的交互序列很長，那么，將來你在需求時做活動圖，分析和設計時做順序圖，打印文檔時，可能就需要特別的打印機或打印紙了。當然不僅于此，它還會為你的后續活動帶來很多麻煩，原因很簡單，就是因為他太復雜，超出我們的管理能力。不過用例太小也不行。若用例太小，維護用例之間的關系就要花很多精力。總之縱向維度上，用例的大小是在用例本身的復雜性和用例之間的復雜性上的一種選擇。
 
 03/09/28 10:22 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 jmisp19  回復: use case 圖是否可以分層次畫？
　
--------------------------------------------------------------------------------
 
這個問題很好，用例圖是可以分層，而且必須是分層的。 
一個簡單證明： 
用例圖是用來交互的，對于架構工程師和程序員應該有不同層次的圖，對吧？ 

以前我也很困惑，后來聯系RUP才最終想明白，層次的完美的體現了面向對象的思想。有一本《面向對象的軟件工程》現在好像只有影印本，建議兄臺一讀。
 
 03/10/02 14:13 酷帖！    臭帖！    回復   
酷帖評價：           臭帖評價： 
返回頁首 
 
 sealw  可以分層的，但分解出“信用管理”似乎有些不妥
　
--------------------------------------------------------------------------------
 
一般來說，分成業務級用例，系統級用例和實現級用例。 

業務級用例針對的一般是客戶實現的價值。比如說“貸款”，其中一個步驟是“檢查客戶信用額度”。對客戶來說，可能的結果就是貸款成功或失敗。這個級別的用例實際上可能涉及組織內多部門和員工的工作才能完成。 

系統級用例針對的是系統的最終用戶，即操作系統的人。 

實現級用例是不同系統級用例共同的一些功能。 

所以獨立出“信用管理”并不適合放在以上的三個層次。如果放在最上一層，它不為客戶提供明確的價值。雖說客戶也很關心自己信用額度，但客戶不是“信用管理”的Actor。如果放在第二層，它又沒有明確的最終用戶作為Actor，信用的管理是通過多次貸款還款以及其它信息來實現的吧。也不適合放在第三層。 

獨立出“信用管理”似乎是系統功能分解的做法。銀行系統包括信用管理子系統。我個人認為，這種思考方式與用例的方式是相違的。 

建議您閱讀《有效用例模式》一書。