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

讨论中所用到UML2建模建模工具为trufun plato,可到www.trufun.net官方网站免费下载!欢迎大家加入trufun家园2qq:15851850交流群,有trufun支持现场解答相关UML应用问题


海东青(1)  10:37:13
有图有真相,UML2用例图建模探讨_第1张图片
 海东青(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
有图有真相,UML2用例图建模探讨_第2张图片
 海东青(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
有图有真相,UML2用例图建模探讨_第3张图片
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
有图有真相,UML2用例图建模探讨_第4张图片
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交流群讨论相关问题===================

你可能感兴趣的:(工作,活动,扩展,action,工具,UML)