討論中所用到UML2建模建模工具為trufun plato，可到www.trufun.net官方網站免費下載！歡迎大家加入trufun家園2qq：15851850交流群，有trufun支持現場解答相關UML應用問題
海東青(1) 10:37:13
海東青(1) 10:37:28
其它的動作是否可以呢
CK(2) 10:38:14
這么去想：你是銷售員，讓你平白無故去錄入銷售單，你愿意嗎
CK(2) 10:38:25
沒事在那輸單子
海東青(1) 10:38:45
可是這是工作啊，誰讓他賺這份錢了呢
CK(2) 10:38:57
至少不能夠作為第一層業務用例
CK(2) 10:39:05
第一層應該是銷售商品
海東青(1) 10:39:04
哦
trufun3 10:39:10
入庫管理，庫存盤點
海東青(1) 10:39:58
海東青(1) 10:40:23
對，銷售商品的概念要大多了
trufun3 10:40:36
我覺得是
海東青(1) 10:40:49
比如去庫房取貨等動作
trufun3 10:41:00
可以再分低級用例
海東青(1) 10:41:21
那么，就是這么說，這些用例圖是不能體現各種表單字樣的唄
trufun3 10:41:40
如銷售訂單管理，銷售退貨，銷售統計
海東青(1) 10:42:19
trufun3 10:41:40
如銷售訂單管理，銷售退貨，銷售統計
你說的這些應該是現低級用例唄
trufun3 10:43:06
對
trufun3 10:43:36
銷售管理是高級用例，相當于子系統
海東青(1) 10:44:54
trufun3 10:45:48
對
trufun3 10:46:07
但圖畫錯了
海東青(1) 10:46:34
差什么呢
trufun3 10:46:53
高級和低級用例之間不是單向關聯
trufun3 10:47:19
而是包含擴展關系
Edoox(4) 10:47:55
包含和擴展是兩個關系吧？
海東青(1) 10:48:07
Edoox(4) 10:48:15
高級和低級用例應該使用包含關系
海東青(1) 10:48:23
這是包含，包含和擴展是什么區分概念呢
trufun3 10:49:07
包含是必須做，擴展是可選做
海東青(1) 10:49:19
哦，明白
Edoox(4) 10:49:39
包含，比如使用入庫管理功能必須要登錄系統，
海東青(1) 10:50:13
那每個動作都有這個登錄系統的動作，不能集中到一個用例中去嗎？
trufun3 10:50:29
是的
海東青(1) 10:50:32
有些系統的查詢是不需要登錄系統的
trufun3 10:50:47
作為其他用例的包含用例
海東青(1) 10:51:08
如醫院住院費用查詢，只需要輸入住院號，查詢就可以了，還有網站，只有管理員才登錄
trufun3 10:52:10
對
海東青(1) 10:52:35
這個圖，默認都需要登錄，不可以嗎？
trufun3 10:53:18
不行
海東青(1) 10:53:32
比如，銷售商品部分，包含登錄系統
那入庫管理，也包含登錄系統，那我豈不是要action后面都要包含一個登錄系統的動作
trufun3 10:54:34
一般是單點登錄，做一個就可以了
Edoox(4) 10:55:11
建議按角色劃分下，一個角色所執行的用例都應該包含系統登錄用例
trufun3 10:55:28
如果是各個子系統都有自己登陸入口，當然要畫了
trufun3 10:56:09
畫業務用例圖
海東青(1) 10:57:47
海東青(1) 10:58:04
Edoox(4) 10:55:11
建議按角色劃分下，一個角色所執行的用例都應該包含系統登錄用例
是這樣的畫法嗎？：
trufun3 10:58:22
很好
Edoox(4) 11:01:58
good
trufun3 11:02:35
Edoox，你有問題嗎？
海東青(1) 11:03:15
，以我的示例，能幫助大家理解一下這個用例圖，是最好的啦，不行，直接畫到底，有時間大家就討論一下，直到類圖，呵呵，不知道大家能否幫忙到底啊
trufun3 11:03:42
下次討論類圖
Edoox(4) 11:03:45
一般，人員應該抽象為系統用戶，其他的人員都可以繼承這個系統用戶，凡是系統用戶都執行系統登錄用例。
trufun3 11:05:00
當然可以，設計沒有標準答案
trufun3 11:05:31
只要有道理就可以
trufun3 11:06:57
系統用戶不是抽象出來的
trufun3 11:07:32
而是一個實實在在的對象
trufun3 11:08:00
可以在實現系統外，也可以在實現系統內
Edoox(4) 11:09:26
恩，有道理
海東青(1) 11:10:32
有道理
trufun3 11:10:47
trufun3 11:12:27
用例圖是誰發明的？
海東青(1) 11:13:38
我又改了一下，感覺庫存盤點跟入庫單管理是一個層次的，大家再評評
海東青(1) 11:13:40
trufun3 11:14:22
進步很大
海東青(1) 11:14:30
海東青(1) 11:14:53
下午再細化一下，準備考慮詳細內容
trufun3 11:14:58
trufun3 11:15:19
好
海東青(1) 11:15:23
先工作一會兒啊，哈哈，受益匪淺啊
trufun3 11:15:44
好
trufun3 11:19:05
記住下次帶問題來
海東青(1) 11:19:42
好的
海東青(1) 11:19:52
肯定很多的問題
trufun3 11:20:09
888
海東青(1) 11:20:14
這個用例圖畫完了，下一個應該是什么圖呢，肯定不是直接到類圖了吧
trufun3 11:20:53
是的
海東青(1) 11:21:02
我想是不是序列圖呢
海東青(1) 11:21:14
部署圖是什么時候畫的呢
trufun3 11:21:40
按理論應該是活動圖
海東青(1) 11:22:08
好，謝謝了
CK(2) 11:27:15
個人感覺，訂貨單管理不屬于庫存管理，屬于采購管理。
另外你這個訂貨單是指你的用戶向你訂貨，還是你向供應商訂貨，有歧義
海東青(1) 11:28:01
是根據缺貨生成的訂貨單
海東青(1) 11:28:10
應該放店主那兒，對吧
CK(2) 11:40:29
根據缺貨生成的訂貨單，那屬于采購的業務
CK(2) 11:40:38
應該屬于采購員的職責
CK(2) 11:40:51
你少一個角色
trufun3 11:41:38
這里的角色是庫管
trufun3 11:42:13
也可以是銷售員
trufun3 11:42:55
銷售訂單可以轉化為采購訂單
trufun3 11:43:40
庫存要貨單也可轉化為采購訂單
trufun3 11:43:54
角色不是采購員
CK(2) 11:45:04
你的“訂貨單管理”，管理的是訂貨單，不是缺貨單
CK(2) 11:45:12
這2個是可以轉化，但是不是一個業務實體
CK(2) 11:45:30
你如果在這里沒分清，到后面抽出業務實體，定義系統對象的時候，就會模糊
CK(2) 11:46:13
庫管可以產生“原料需求清單”，也可以叫做“缺貨單”。這個單子可以作為產生“采購清單”的數據來源，但是不代表他們是一個東西
CK(2) 11:47:08
我認為還是分清楚點好。特別是做一些大的項目，看的更明顯。
比如貨物可能有替代性，你缺少A,不一定采購A,可能采購B,C代替之
trufun3 11:47:16
訂貨單里沒講清楚，是采購訂貨單，還是銷售訂貨單
Edoox(4) 14:43:04
CK的業務經驗很豐富，概念很清晰。
深藍醫生(45383850) 14:44:40
不錯，受教
==================歡迎加入UML交流群討論相關問題===================