#用例问题.txt

一些关于UML的经典讨论

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

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

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

即使是他忽略了二者的差异,你所纠正的只是用词不当而已.而对深刻理解UML方面,显然,你的驳斥已经证明你已经不及你的被驳斥者.因为你甚至会因为为了满足对用词的追究而去忽视对UML的深刻内涵的理解.
 
 04/02/18 21:05 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 eddiewang  回复: 请问对实战案例有何要求？
　
--------------------------------------------------------------------------------
 
我现在正在开发一个考试系统,可同时支持1000人在线考试.如何给你提供需求?
 
 04/02/18 21:30 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 yj39867   回复: 用例=需求=功能=服务=使用说明书=接口(interface)=合同=user story
　
--------------------------------------------------------------------------------
 
这个世界上所有的联系都可以用三个基本要素构成：客户，服务和服务提供者。大家对用例不能很好的理解，根源在于对use case 这个概念的翻译；就像佛教的禅，圣人说的就是东东，大家理解的不一样，就产生了很多的经书来说明，说来说去，反而今人没有人能理解。我的理解：禅就是我当下状态。 

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

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

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

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

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

　
 
 04/02/18 21:48 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  现在开始,请问,有哪几种人会用到你的系统?
　
--------------------------------------------------------------------------------
 
请: 
给这些"人种"下个定义; 
给每种人找一个代表人物,虚拟出他(她)的姓名.
 
 04/02/20 13:31 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 eddiewang  简单描述
　
--------------------------------------------------------------------------------
 
教务处（李教务）：出题（包含答案）、汇总、排名 
带课老师（张老师）：阅卷、排名 
学生（赵学生）：考试 
题型：支持大部分应用题型（选择、填空、判断、问答、计算、作文） 
阅卷标准：关键字、智能判断及人工（当前不支持错别字处理） 
分数分配：支持同一题目多种判分标准 
时间限制：可对同一题型进行时间限制。超时可扣分或终止答卷两种操作方式。 
举例： 
李教务出题，语文科目：题型包括：填空（2分/题）、选择（2分/题）、判断（单选：2分/题，多选：3分/题）、问答（10分/题）、作文（30分），总时间为120分钟，对题型不进行时间限制，可提前交卷（开考后30分钟）。 
张老师组织考试并阅卷（阅卷时隐含学生姓名，阅卷顺序为随机）：提前十分钟发卷（与服务器同步时间），可支持迟到考生答卷。 
学生答卷，提前十分钟接卷（题面隐藏），正点答卷，计算机计时。 
填空，答对加分，遇到错别字不给分。 
单选：答对加分 
多选：答对一个按相应比例加分 
问答：关键字给分，（支持关键字顺序判别） 
作文：人工判分 

分数保留小数点后一位；超时禁止作答，五分钟后自动提交试题答案。 
 
 04/02/20 22:44 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 qingrun   呵呵，多谢提醒指教。不过，
　
--------------------------------------------------------------------------------
 
不过，在学问研究中，你又如何证明他仅仅是用词的不当，他仅仅是忽略了二者的差异，而不是理解的错误呢？ 
你又如何证明我已经不及我的驳斥者呢？ 
你又如何证明我会因为为了满足对用词的追究而去忽视对UML的深刻内涵的理解呢？ 
中国的语言文学博大精深，但还不至于说中国人连关键性的词用错都仍然认为自己是正确的地步。 
也许你老兄的确比我水平深，的确深入理解了Uml的深刻内涵，的确高于我这个驳斥者，甚至比我的驳斥者还要高明。但是，你上面的话并不能证明这些，也只能证明你和我最多是个同类而已。
 
 04/02/24 16:22 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 justfly_shi   对于每个用例都需要一个主角的疑问
　
--------------------------------------------------------------------------------
 
比如有一个后台进程、它不停的检查当前时间，然后把数据存进数据库里面来达到对系统的影响。 
比如一个定时备份进程。 
请问这个能不能算是一个用例？如果是用例的话，那么它所对应的Actor是什么？ 
如果它不是用例的话，那么应该把它建模成什么？
 
 04/02/26 13:11 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  关于后台进程是否用例?主角为谁?
　
--------------------------------------------------------------------------------
 
使用用例模型有一个前提:就是用例模型只描述发生在系统边界上的与主角的交互行为. 
一个获得系统时间并保存到数据库中的进程,如果把数据库看做是系统边界以内的对象的话,可以看成完全是系统内部的操作,不是用例.如果数据库是包含在另外一个系统的边界内的.本系统包含了对那个系统提供系统时间的服务项目,那么,这个进程就是本系统的一个用例,另外的系统是这个用例的主角. 
一个定时备份数据的进程是否用例,要看对备份的数据的使用是否包含本系统之内.如果在系统之内,则不是用例,如果在系统之外,比如,只是自动拷贝一系列文件到资源管理器的备份目录,然后有用户手工或其他程序去处理这些备份文件,那么,这个定时备份数据的进程就是用例,它的主角至少可以是"资源管理器"程序. 
"系统的边界"在许多人看来很模糊,得不到精准的表达,其实就是因为他们对用例模型的作用之一:表达系统的边界理解不足. 
对于系统边界内的"用例",如何表达呢? 
1.划分子系统,在子系统之间互为主角和用例. 
2.用对象模型,表达为某个类的职责. 
就不举例了,留给大家做作业吧. 


　
 
 04/02/26 13:31 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 smilemac  这个例子里，要备份的数据，或者说data provider是actor. 任何用例都必须至少有一个actor与之关联，否则就不应该作为用例表达。
　
--------------------------------------------------------------------------------
 
 04/02/26 13:32 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 justfly_shi   回复: 关于后台进程是否用例?主角为谁?
　
--------------------------------------------------------------------------------
 
受教了，谢谢
 
 04/02/26 13:33 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 smilemac  呵呵，原来楼下已经答了。
　
--------------------------------------------------------------------------------
 
 04/02/26 13:34 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 mhw  回复: "用例"问题
　
--------------------------------------------------------------------------------
 
简单的说，如果一个用例没有输入也没有输出，存在有什么意义。
 
 04/02/26 16:08 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  我只问到以下信息,没想到你给了那么多,不好意思,才回复
　
--------------------------------------------------------------------------------
 
只有三种人会用到待开发的考试系统: 
1.教务人员：负责出试题的人，如李教务 
2.科任老师：负责阅卷的人，如语文张老师 
3.学生：负责答题的人，如学生小赵 

以上信息是否准确?
 
 04/02/29 22:34 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 cybercoolguy   回复: 关于后台进程是否用例?主角为谁?
　
--------------------------------------------------------------------------------
 
系统定时备份数据的用例的主角是系统时间（system timer），因为这是由系统时间触发的，我做的上一个项目就是这么定义的。system timer也算是系统角色之一，但容易被人忽视。
 
 04/03/01 10:22 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 god2000   回复: 这个系统我自己做过，当时没有建模，需求跟这位老兄相似
　
--------------------------------------------------------------------------------
 
 04/03/01 12:56 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 eddiewang  你感觉有市场么？
　
--------------------------------------------------------------------------------
 
 04/03/01 17:59 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 eddiewang   没关系，我想信息多点更有利于实战培训么。如果还有需要，尽管说啊。
　
--------------------------------------------------------------------------------
 
 04/03/01 18:07 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  以系统时间为主角的理由是什么呢?
　
--------------------------------------------------------------------------------
 
主角:站在用例外部和系统进行交互的对象. 
如果我们承认以上的定义是应该遵循的,那么,把系统时间作为定时备份进程所对应的用例的主角,就有些说不过去. 
非要把它作为主角的唯一理由是:它是这个进程的启动者.似乎这个理由已经足够充分了. 
我理解:之所以用例的启动执行者经常被定义为用例的主角,是因为用例的启动执行者往往有着启动执行的目的,他(她/它)一定对用例的执行结果出于自身利益的要求有所期待。也就是说,主角,首先是需求者,离开这个前提,我们就离开了开发用例模型的初衷:挖掘需求。 
任何一个用例，一般同时会有外部的启动者和内部启动者，内部启动者因为接到外部启动者的启动指令而启动内部的动作。而软件，只为外部启动者而开发，所以，在确立主角的时候，尤其在不是同时有外部的启动者和内部启动者的时候，最需要辨别的是：它是内部的启动者还是外部的启动者。内部启动者，应该建模到对象模型而不是用例模型。 
如果外部需求者不是用例的外部启动者，我们要么把内部启动者强制理解为在系统的外部进行启动从而建模为用例的主角，要么直接把外部需求者建模为主角，而不管他是否用例的直接启动者。如果是我面对这种情况，我会选择后一种建模策略，因为，我可以把“启动”一词理解为“需要启动”。
 
 04/03/02 09:24 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 cybercoolguy   回复: 以系统时间为主角的理由是什么呢?
　
--------------------------------------------------------------------------------
 
主角:站在用例外部和系统进行交互的对象. 

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

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

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

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

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

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

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

如果理解有错，请指正！
 
 04/03/02 10:38 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  多交流
　
--------------------------------------------------------------------------------
 
如果我手头有你的用例模型,就不致于转变了讨论对象我们都不知道.显然,你的例子和楼主的不太一样. 
我对你的例子也同样感兴趣,只是这样空对空讲抽象的大道理很难得到理解,很容易得到误解而已.
 
 04/03/02 12:34 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 cybercoolguy  回复: 多交流
　
--------------------------------------------------------------------------------
 
是我最开始的描述有些问题，让你误解了
 
 04/03/02 12:56 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 cybercoolguy  回复: 多交流
　
--------------------------------------------------------------------------------
 
我发了一个帖子，是关于WEB SERVICE 和.NET 的企业级应用的，如果你感兴趣，可以去看看，也希望能看到你的观点