北京-FireSpider 男 9:08:49
老师您好。
我看您的书里,需求工程中有一个例子,描述一个“合同付款管理”的用例。
青润 9:09:30
您好。
北京-FireSpider 男 9:09:49
这个用例好像是系统用例,而不是业务用例?
因为涉及了用户和系统两个概念,对吧?
青润 9:10:19
系统用例和业务用例的区别在于,用户是否直接使用。
如果是系统管理员使用或者为了配合业务用例而产生的后台管理用例,就是系统用例。
而与用户业务相关的用例,都是业务用例。
北京-FireSpider 男 9:11:28
哦,哪也就是说孙然涉及了用户和系统两个概念,但是是用户用于执行业务的,也是业务用例?
青润 9:11:41
对。
合同付款,必然是商务和财务两方面的人都要经手的业务
所以,肯定是业务用例,而不是系统用例。
北京-FireSpider 男 9:12:10
哦,原来如此。我原来以为业务建模阶段不可以涉及计算机的概念,就是对客户现实业务的描述呢。
青润 9:12:21
呵呵。
北京-FireSpider 男 9:13:51
另外,这个“合同付款管理”的用例,包含很多子用例,如:创建、修改、查询、删除。这些子用例是不是也可以单独描述?
北京-FireSpider 男 9:15:04
我看您这里是在“合同付款管理”的用例理将这些统一描述出来了。这个确实一目了然。
安全提示:如果聊天中有涉及财产的操作,请一定先核实好友身份。发送验证问题或点击举报
青润 9:15:29
这个问题,我给你看一下最近的一条微博讨论。
北京-FireSpider 男 9:15:49
谢谢
青润 9:16:23
关于这个问题我有些顾虑。右边用例划分太细,如果业务系统用例这样划分,用例数量就会非常庞大。因此我认为右边的四个用例其实是一个用例的四个子流,或者称之为元用例。通过这样的方式,可以更好的度量用例大小。否则,在一个大业务系统中用例间关系绘制出来就会吓死人。或者说,这个例子举得不太合适
◆◆
@UM****
从业务序列图应该得到右边的四个用例,但有的开发人员会动起心思:这些实现起来不都是针对“缺陷”表来“Select ××× from 缺陷 where ×××”吗,合并成一个用例“检索缺陷”多好!于是得到左边的结果。实际上,右边这四个用例面对的执行者不同,背后的涉众利益也有差别。
收起|查看大图|向左转|向右转
下面是**说的,但是,我认为他错了。
吴穹adam:认同青润的观点 (11月14日 16:42)
吴穹也认同我的观点,认为**在这个问题上说错了。
北京-FireSpider 男 9:18:28
都是牛人啊,呵呵。我再仔细看看。
青润 9:18:42
嗯。