一本书中有这一句话”每个用例(use case)都必须至少有一个角色(actors)与之关联,否则要么是新增加一个合适的角色与之关联,要么就删除该用例”. 这种说法对么?

 回复: "用例"问题
　

---

对
每个用例就是一个方法
而角色就是一个对象
没有对象那来的方法
就象一个动作必需有个人去做

同意楼上的意见

 回复: "用例"问题
　

---

因为每个用例都需要角色启动

 回复: "用例"问题
　

---

精辟

首先要明白什么是用例?用例模型是做什么用的?
用例是从系统外表述在系统边界上发生的一系列主角和系统的交互行为的集合;
用例是系统提供给主角的服务项目;
用例是系统服务项目的外观包装;
主角是系统服务的享受者;
主角一般是因为要享受系统的服务而需要和系统交互;
主角不是在系统内工作而提供服务的角色(Worker),系统内设计的类才是角色;
主角不是系统内的类,主角在系统外在系统边界上与系统进行交互;
类在系统内响应在系统边界上发生的主角的交互指令(事件),运用自己和同伴的方法满足服务的要求;
为什么每个用例都需要一个主角?
因为没有主角的用例是不会有人享受的服务.
要么你找到享受这个服务的消费者,要么你取消这个服务.

我正在开展免费UML实战训练指导,欢迎提供实战案例.

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

　

 回复: "用例"问题
　

---

我认为不是这样子的。这时这些被包含（或扩展）用例的主角就是包含用例（或被扩展用例）的主角，用例是不会没有主角的。没有主角的用例就是无用用例，应该删除。

 补充。
　

---

摘自RUP->核心工作流程->需求->指南概述->用例模型

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

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

如果用例是抽象的（不是可独立实例化的），则其行为可能不包括与主角的交互。这种情况下，将不存在任何从该抽象用例到主角的通信关联关系。
如果父用例说明了所有的主角通信，则泛化关系中的子用例不需要与主角相关联。
如果包含用例说明了所有的主角通信，则包含关系中的基本用例不需要与主角相关联。
一个用例可能按照时间表（例如，一星期一次或一天一次）来启动，这意味着系统时钟即为启动程序。由于用例不是由主角而是由内部系统事件启动的，因此系统时钟对于该系统而言是内在的。如果在该用例中没有发生其他的主角交互，则它与主角之间不存在任何关联关系。然而，为了清楚起见，您可以在用例图中使用一个虚构的主角“时间”来显示该用例是如何启动的。

 请教一个问题
　

---

泛化关系所联系的两个用例哪一个应当与actor发生关联。

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

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

还是：

顾客--用现金付款？


多谢指教

对于待研究的系统来说,应该是"收款用例"
顾客-收款
如此泛化即可:
付现金顾客-现金收款
付支票顾客-支票收款

 刚刚看了所有人的答复。这里我有一点个人看法。
　

---

我觉得不一定非要设定一个actor与use case相关联。
对于一些提取出来的use case，比如usecase3被usecase1和usecase2所包含。而这个用例又比较复杂。
她可能直接是被usecase1和usecase2所驱动的，而不一定非要关联上某个actor。这里不能过于形而上学的要求必须如何如何。在一些情况下，用例的一部分功能可能会起到类似actor的作用对其他用例起触发作用。
所以，有些时候，用例不一定非要关联上actor。

在这里，收款用例应当是一个抽象用例，所以顾客--收款关系可以不用刻画。对么？

用例抽象层次和主角抽象层次一致.并不是抽象的用例或具体的用例之一就不需要主角,即使你不必表达出来,含义上的主角依然存在.

泛化用例需要文字描述么， 怎么通过文字刻画泛化用例。 比如说“执行事务”用例

抽象的用例可以有抽象的事件流,就可以用抽象的描述文字进行刻画.
比如:执行事务用例,可以有如下事件流:
1.用户提交事务;
2.系统解释执行;
3.系统返回执行结果;
例外流:
3.事务执行失败;
4.系统滚回执行前状态;
5.系统返回失败信息.

如果存在一个用例B被另一个用例A驱动的情况,那A又是怎么驱动B的呢?
1.B被A外面的主角驱动;
2.B被A里面的角色驱动;
如果是1,那么,B的主角就是A的主角,只是省略表达,并非B没有主角;
如果是2,那么,
1.要么B用例是描述A用例的内部活动,本应该用对象模型表达,B是误用例;
2.要么A用例是业务用例,而B用例是系统用例,二者属于不同的范畴,A用例中的角色就是B用例的主角,这种表达混淆了业务用例和系统用例的范畴.

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

所以,用例必有主角,没有主角的用例是误用例.

我所说的是：“我觉得不一定非要设定一个actor与use case相关联。”
而其他人认为：“每个用例(use case)都必须至少有一个角色(actors)与之关联,否则要么是新增加一个合适的角色与之关联,要么就删除该用例”。
注意关联和由主角驱动两者的差异。

同意qingrun的看法。 复杂的usecase关系， 或者经细化的use case， 绝对又可能需要没有actor的usecase.

请问对实战案例有何要求？

只要是在实际开发或曾经开发过的项目就行.

我所说的是：“我觉得不一定非要设定一个actor与use case相关联。”
而其他人认为：“每个用例(use case)都必须至少有一个角色(actors)与之关联,否则要么是新增加一个合适的角色与之关联,要么就删除该用例”。
注意关联和由主角驱动两者的差异。

你提醒大家注意"关联和由主角驱动两者的差异",你的意思是说关联只是一个表达,用例虽然必须由主角驱动,但不一定要表达出来,是吗?
而你却没有注意"关联和由主角驱动两者的共同点",他们说的同一个事物:主角和用例的关系.

你觉得说：“每个用例(use case)都必须至少有一个角色(actors)与之关联,否则要么是新增加一个合适的角色与之关联,要么就删除该用例”这个话的人的"关联"的含义难道不是强调两者的共同点吗?

即使是他忽略了二者的差异,你所纠正的只是用词不当而已.而对深刻理解UML方面,显然,你的驳斥已经证明你已经不及你的被驳斥者.因为你甚至会因为为了满足对用词的追究而去忽视对UML的深刻内涵的理解.

我现在正在开发一个考试系统,可同时支持1000人在线考试.如何给你提供需求?

 回复: 用例=需求=功能=服务=使用说明书=接口(interface)=合同=user story
　

---

这个世界上所有的联系都可以用三个基本要素构成：客户，服务和服务提供者。大家对用例不能很好的理解，根源在于对use case 这个概念的翻译；就像佛教的禅，圣人说的就是东东，大家理解的不一样，就产生了很多的经书来说明，说来说去，反而今人没有人能理解。我的理解：禅就是我当下状态。

use case 也一样。我用上述公式从不同侧面来描述这个概念，希望对大家有所帮助。这些概念或者不能等同，但是大家如果从本质上理解了，就知道所有这些概念其实都不同侧面讲述了一个东西。

从文字入手，但不要执著于文字。

中国程序员真不容易，洋人的好东西倒了我们这里就变了味道。就像object概念一样，台湾人翻译为物件，多好！oop翻译为物件导向，多好。

而我们翻译为对象，面向对象，真是差劲，误导了多少子弟。

对于use case 这个概念，国人翻译为用例，也是非常差。反倒不如user story 来的好。

　

请:
给这些"人种"下个定义;
给每种人找一个代表人物,虚拟出他(她)的姓名.

教务处（李教务）：出题（包含答案）、汇总、排名
带课老师（张老师）：阅卷、排名
学生（赵学生）：考试
题型：支持大部分应用题型（选择、填空、判断、问答、计算、作文）
阅卷标准：关键字、智能判断及人工（当前不支持错别字处理）
分数分配：支持同一题目多种判分标准
时间限制：可对同一题型进行时间限制。超时可扣分或终止答卷两种操作方式。
举例：
李教务出题，语文科目：题型包括：填空（2分/题）、选择（2分/题）、判断（单选：2分/题，多选：3分/题）、问答（10分/题）、作文（30分），总时间为120分钟，对题型不进行时间限制，可提前交卷（开考后30分钟）。
张老师组织考试并阅卷（阅卷时隐含学生姓名，阅卷顺序为随机）：提前十分钟发卷（与服务器同步时间），可支持迟到考生答卷。
学生答卷，提前十分钟接卷（题面隐藏），正点答卷，计算机计时。
填空，答对加分，遇到错别字不给分。
单选：答对加分
多选：答对一个按相应比例加分
问答：关键字给分，（支持关键字顺序判别）
作文：人工判分

分数保留小数点后一位；超时禁止作答，五分钟后自动提交试题答案。

 呵呵，多谢提醒指教。不过，
　

---

不过，在学问研究中，你又如何证明他仅仅是用词的不当，他仅仅是忽略了二者的差异，而不是理解的错误呢？
你又如何证明我已经不及我的驳斥者呢？
你又如何证明我会因为为了满足对用词的追究而去忽视对UML的深刻内涵的理解呢？
中国的语言文学博大精深，但还不至于说中国人连关键性的词用错都仍然认为自己是正确的地步。
也许你老兄的确比我水平深，的确深入理解了Uml的深刻内涵，的确高于我这个驳斥者，甚至比我的驳斥者还要高明。但是，你上面的话并不能证明这些，也只能证明你和我最多是个同类而已。

 对于每个用例都需要一个主角的疑问
　

---

比如有一个后台进程、它不停的检查当前时间，然后把数据存进数据库里面来达到对系统的影响。
比如一个定时备份进程。
请问这个能不能算是一个用例？如果是用例的话，那么它所对应的Actor是什么？
如果它不是用例的话，那么应该把它建模成什么？

使用用例模型有一个前提:就是用例模型只描述发生在系统边界上的与主角的交互行为.
一个获得系统时间并保存到数据库中的进程,如果把数据库看做是系统边界以内的对象的话,可以看成完全是系统内部的操作,不是用例.如果数据库是包含在另外一个系统的边界内的.本系统包含了对那个系统提供系统时间的服务项目,那么,这个进程就是本系统的一个用例,另外的系统是这个用例的主角.
一个定时备份数据的进程是否用例,要看对备份的数据的使用是否包含本系统之内.如果在系统之内,则不是用例,如果在系统之外,比如,只是自动拷贝一系列文件到资源管理器的备份目录,然后有用户手工或其他程序去处理这些备份文件,那么,这个定时备份数据的进程就是用例,它的主角至少可以是"资源管理器"程序.
"系统的边界"在许多人看来很模糊,得不到精准的表达,其实就是因为他们对用例模型的作用之一:表达系统的边界理解不足.
对于系统边界内的"用例",如何表达呢?
1.划分子系统,在子系统之间互为主角和用例.
2.用对象模型,表达为某个类的职责.
就不举例了,留给大家做作业吧.


　

 回复: 关于后台进程是否用例?主角为谁?
　

---

受教了，谢谢

简单的说，如果一个用例没有输入也没有输出，存在有什么意义。

只有三种人会用到待开发的考试系统:
1.教务人员：负责出试题的人，如李教务
2.科任老师：负责阅卷的人，如语文张老师
3.学生：负责答题的人，如学生小赵

以上信息是否准确?

 回复: 关于后台进程是否用例?主角为谁?
　

---

系统定时备份数据的用例的主角是系统时间（system timer），因为这是由系统时间触发的，我做的上一个项目就是这么定义的。system timer也算是系统角色之一，但容易被人忽视。

主角:站在用例外部和系统进行交互的对象.
如果我们承认以上的定义是应该遵循的,那么,把系统时间作为定时备份进程所对应的用例的主角,就有些说不过去.
非要把它作为主角的唯一理由是:它是这个进程的启动者.似乎这个理由已经足够充分了.
我理解:之所以用例的启动执行者经常被定义为用例的主角,是因为用例的启动执行者往往有着启动执行的目的,他(她/它)一定对用例的执行结果出于自身利益的要求有所期待。也就是说,主角,首先是需求者,离开这个前提,我们就离开了开发用例模型的初衷:挖掘需求。
任何一个用例，一般同时会有外部的启动者和内部启动者，内部启动者因为接到外部启动者的启动指令而启动内部的动作。而软件，只为外部启动者而开发，所以，在确立主角的时候，尤其在不是同时有外部的启动者和内部启动者的时候，最需要辨别的是：它是内部的启动者还是外部的启动者。内部启动者，应该建模到对象模型而不是用例模型。
如果外部需求者不是用例的外部启动者，我们要么把内部启动者强制理解为在系统的外部进行启动从而建模为用例的主角，要么直接把外部需求者建模为主角，而不管他是否用例的直接启动者。如果是我面对这种情况，我会选择后一种建模策略，因为，我可以把“启动”一词理解为“需要启动”。

 回复: 以系统时间为主角的理由是什么呢?
　

---

主角:站在用例外部和系统进行交互的对象.

这个概念并不是很确切的，应该说比较抽象，这个概念应该在详细的定义为，站在用例外部直接和系统进行交互的对象。这不是闭门造车，是我在项目中总结的一点经验吧，如果谁有不同的见解，请指点。

如果我们承认以上的定义是应该遵循的,那么,把系统时间作为定时备份进程所对应的用例的主角,就有些说不过去.
非要把它作为主角的唯一理由是:它是这个进程的启动者.似乎这个理由已经足够充分了.

至于这点，我想您可能误会我的意思了，不是系统时间，应该说是system timer，在系统中，system timer也可以说是主角，它是用例的直接驱动者，由它来直接驱动用例来实现用例的功能，它的背后可能是系统中具体的某个角色，比如说，某个batch的使用者，使用部门等等。

我理解:之所以用例的启动执行者经常被定义为用例的主角,是因为用例的启动执行者往往有着启动执行的目的,他(她/它)一定对用例的执行结果出于自身利益的要求有所期待。也就是说,主角,首先是需求者,离开这个前提,我们就离开了开发用例模型的初衷:挖掘需求。

这个说法和我的用例的具体实现并不不矛盾。挖掘需求过程中会遇到很多具体的问题，我想应该具体问题具体分析。

任何一个用例，一般同时会有外部的启动者和内部启动者，内部启动者因为接到外部启动者的启动指令而启动内部的动作。而软件，只为外部启动者而开发，所以，在确立主角的时候，尤其在不是同时有外部的启动者和内部启动者的时候，最需要辨别的是：它是内部的启动者还是外部的启动者。内部启动者，应该建模到对象模型而不是用例模型。
如果外部需求者不是用例的外部启动者，我们要么把内部启动者强制理解为在系统的外部进行启动从而建模为用例的主角，要么直接把外部需求者建模为主角，而不管他是否用例的直接启动者。如果是我面对这种情况，我会选择后一种建模策略，因为，我可以把“启动”一词理解为“需要启动”。

这个说法我也赞同，老兄对概念理解到这种程度，我实在是很佩服。
windows schedule应该理解为系统的外部使用者，我们用它来和我们的业务系统进行交互，来实现特定的功能。这和对象之间的消息传递可是两个概念。

如果理解有错，请指正！

如果我手头有你的用例模型,就不致于转变了讨论对象我们都不知道.显然,你的例子和楼主的不太一样.
我对你的例子也同样感兴趣,只是这样空对空讲抽象的大道理很难得到理解,很容易得到误解而已.

是我最开始的描述有些问题，让你误解了

我发了一个帖子，是关于WEB SERVICE 和.NET 的企业级应用的，如果你感兴趣，可以去看看，也希望能看到你的观点