有图有真相，UML2用例图建模探讨

讨论中所用到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
不错，受教