#用例问题.txt

一些关于UML的经典讨论

http://www.umlchina.com/best/g35/u1153738.htm
--------------------------------------------------------------------------------
 
作者 内容 
 zhangzib  "用例"问题
　
--------------------------------------------------------------------------------
 
一本书中有这一句话”每个用例(use case)都必须至少有一个角色(actors)与之关联,否则要么是新增加一个合适的角色与之关联,要么就删除该用例”. 这种说法对么?
 
 04/01/28 11:04 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 话话话   回复: "用例"问题
　
--------------------------------------------------------------------------------
 
对 
每个用例就是一个方法 
而角色就是一个对象 
没有对象那来的方法 
就象一个动作必需有个人去做
 
 04/01/28 15:53 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 flyinnights  回复: "用例"问题
　
--------------------------------------------------------------------------------
 
同意楼上的意见
 
 04/01/29 17:38 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 yqt   回复: "用例"问题
　
--------------------------------------------------------------------------------
 
因为每个用例都需要角色启动
 
 04/01/29 21:05 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 话话话   回复: "用例"问题
　
--------------------------------------------------------------------------------
 
精辟 
 
 04/01/29 22:35 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  为什么每个用例都需要一个主角(Actor)?不同的理由
　
--------------------------------------------------------------------------------
 
首先要明白什么是用例?用例模型是做什么用的? 
用例是从系统外表述在系统边界上发生的一系列主角和系统的交互行为的集合; 
用例是系统提供给主角的服务项目; 
用例是系统服务项目的外观包装; 
主角是系统服务的享受者; 
主角一般是因为要享受系统的服务而需要和系统交互; 
主角不是在系统内工作而提供服务的角色(Worker),系统内设计的类才是角色; 
主角不是系统内的类,主角在系统外在系统边界上与系统进行交互; 
类在系统内响应在系统边界上发生的主角的交互指令(事件),运用自己和同伴的方法满足服务的要求; 
为什么每个用例都需要一个主角? 
因为没有主角的用例是不会有人享受的服务. 
要么你找到享受这个服务的消费者,要么你取消这个服务. 

我正在开展免费UML实战训练指导,欢迎提供实战案例.
 
 04/01/30 23:31 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 zhangzib  回复: "用例"问题
　
--------------------------------------------------------------------------------
 

那么按这种观点, 有的用例是被其它的包含或扩展的没有角色与之相连,就应删掉,是这样么? 

　
 
 04/01/31 09:22 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 longsansan   回复: "用例"问题
　
--------------------------------------------------------------------------------
 
我认为不是这样子的。这时这些被包含（或扩展）用例的主角就是包含用例（或被扩展用例）的主角，用例是不会没有主角的。没有主角的用例就是无用用例，应该删除。
 
 04/01/31 14:32 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 longsansan   补充。
　
--------------------------------------------------------------------------------
 
摘自RUP->核心工作流程->需求->指南概述->用例模型 

用例是否始终和主角有关？ 
每个用例的执行都包含与一个或多个主角的交流。用例实例始终通过主角要求系统执行某些任务来启动。这意味着每个用例需要与主角建立通信关联关系。此规则的理由是强迫系统只提供用户需要的功能，而不提供任何其他的东西。如果存在无人请求的用例，则表明在该用例模型或需求中存在错误。 

然而，此规则也有一些例外情况： 

如果用例是抽象的（不是可独立实例化的），则其行为可能不包括与主角的交互。这种情况下，将不存在任何从该抽象用例到主角的通信关联关系。 
如果父用例说明了所有的主角通信，则泛化关系中的子用例不需要与主角相关联。 
如果包含用例说明了所有的主角通信，则包含关系中的基本用例不需要与主角相关联。 
一个用例可能按照时间表（例如，一星期一次或一天一次）来启动，这意味着系统时钟即为启动程序。由于用例不是由主角而是由内部系统事件启动的，因此系统时钟对于该系统而言是内在的。如果在该用例中没有发生其他的主角交互，则它与主角之间不存在任何关联关系。然而，为了清楚起见，您可以在用例图中使用一个虚构的主角“时间”来显示该用例是如何启动的。 
 
 04/01/31 15:59 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 j2ee   请教一个问题
　
--------------------------------------------------------------------------------
 
泛化关系所联系的两个用例哪一个应当与actor发生关联。 

如付款用例，用现金付款和用信用卡付款存在一下泛化关系 
用现金付款 ---|>“付款” 
用信用卡付款 ---|>“付款” 

那么应该是： 
顾客---付款 

还是： 

顾客--用现金付款？ 


多谢指教
 
 04/02/07 16:01 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  应该好好理解泛化的含义
　
--------------------------------------------------------------------------------
 
对于待研究的系统来说,应该是"收款用例" 
顾客-收款 
如此泛化即可: 
付现金顾客-现金收款 
付支票顾客-支票收款
 
 04/02/10 21:02 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 qingrun   刚刚看了所有人的答复。这里我有一点个人看法。
　
--------------------------------------------------------------------------------
 
我觉得不一定非要设定一个actor与use case相关联。 
对于一些提取出来的use case，比如usecase3被usecase1和usecase2所包含。而这个用例又比较复杂。 
她可能直接是被usecase1和usecase2所驱动的，而不一定非要关联上某个actor。这里不能过于形而上学的要求必须如何如何。在一些情况下，用例的一部分功能可能会起到类似actor的作用对其他用例起触发作用。 
所以，有些时候，用例不一定非要关联上actor。
 
 04/02/11 12:42 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 j2ee  是不是有点罗嗦了
　
--------------------------------------------------------------------------------
 
在这里，收款用例应当是一个抽象用例，所以顾客--收款关系可以不用刻画。对么？
 
 04/02/11 16:42 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  使用泛化要尽量"保持一致的抽象层次"
　
--------------------------------------------------------------------------------
 
用例抽象层次和主角抽象层次一致.并不是抽象的用例或具体的用例之一就不需要主角,即使你不必表达出来,含义上的主角依然存在. 
 
 04/02/12 21:54 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 j2ee  再请教一个问题
　
--------------------------------------------------------------------------------
 
泛化用例需要文字描述么， 怎么通过文字刻画泛化用例。 比如说“执行事务”用例
 
 04/02/13 17:36 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  只要是用例,就应该有事件流,就可以用文字来描述
　
--------------------------------------------------------------------------------
 
抽象的用例可以有抽象的事件流,就可以用抽象的描述文字进行刻画. 
比如:执行事务用例,可以有如下事件流: 
1.用户提交事务; 
2.系统解释执行; 
3.系统返回执行结果; 
例外流: 
3.事务执行失败; 
4.系统滚回执行前状态; 
5.系统返回失败信息.
 
 04/02/15 20:26 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  "用例被用例驱动",其中存在容易混淆的情况
　
--------------------------------------------------------------------------------
 
如果存在一个用例B被另一个用例A驱动的情况,那A又是怎么驱动B的呢? 
1.B被A外面的主角驱动; 
2.B被A里面的角色驱动; 
如果是1,那么,B的主角就是A的主角,只是省略表达,并非B没有主角; 
如果是2,那么, 
1.要么B用例是描述A用例的内部活动,本应该用对象模型表达,B是误用例; 
2.要么A用例是业务用例,而B用例是系统用例,二者属于不同的范畴,A用例中的角色就是B用例的主角,这种表达混淆了业务用例和系统用例的范畴. 

如果我们承认用例只是对发生在系统(软件系统或业务系统)边界("外壳")上的事件进行描述的话,我们就不必在开发用例模型的时候深入到用例的内部去探究用例内部的实现,因为那是开发对象模型的任务. 
如果我们承认用例只是对发生在系统(软件系统或业务系统)边界("外壳")上的事件进行描述的话,如果没有外部的启动者,就看不到任何表面的事件发生,如果表面有事件发生,这些事件一定对外部的某主体有意义,如果此事对任何外部主体没有意义,它也就不必在我们关注的视野中出现. 

所以,用例必有主角,没有主角的用例是误用例.
 
 04/02/15 20:49 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 qingrun  我同意你的说法。但是，这里有一个需要说明的地方。
　
--------------------------------------------------------------------------------
 
我所说的是：“我觉得不一定非要设定一个actor与use case相关联。” 
而其他人认为：“每个用例(use case)都必须至少有一个角色(actors)与之关联,否则要么是新增加一个合适的角色与之关联,要么就删除该用例”。 
注意关联和由主角驱动两者的差异。
 
 04/02/17 16:37 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 leo-leo-leo  回复: "用例"问题
　
--------------------------------------------------------------------------------
 
同意qingrun的看法。 复杂的usecase关系， 或者经细化的use case， 绝对又可能需要没有actor的usecase.
 
 04/02/17 23:02 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 eddiewang  请问对实战案例有何要求？
　
--------------------------------------------------------------------------------
 
请问对实战案例有何要求？
 
 04/02/18 12:30 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  回复: 请问对实战案例有何要求？
　
--------------------------------------------------------------------------------
 
只要是在实际开发或曾经开发过的项目就行.
 
 04/02/18 20:50 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  感觉你的说明有些偏颇
　
--------------------------------------------------------------------------------
 
我所说的是：“我觉得不一定非要设定一个actor与use case相关联。”