所有的actor和uc的关联箭头应该都是actor指向uc，同时涉及到系统边界，用例大小和状态活动图，以及uml如果用得不符合规范该怎么办？
对话内容如下：
墨池 8:46:34
青润2011/4/14 6:42:06
所有的actor和uc的关联箭头应该都是actor指向uc的，这个问题8年前在程序员上就有过一次讨论，涉及到系统边界，actor认定和数据库是否可以作为actor存在的事情。
你可以去搜索以下。
墨池 8:46:46
清润老师，关于这点我想向您提一个问题
墨池 8:47:38
如果两个actor共同完成一个uc，那么谁是启动者，谁是支持者，通过箭头的指向不是很好理解吗？
青润 8:48:43
两个actor完成一个uc，那么这个uc到底是谁启动的？
青润 8:48:56
肯定有一个是启动者，另一个是中间参与者。
墨池 8:49:03
恩，是的。
墨池 8:49:13
我现在是通过箭头的指向来区分的
青润 8:49:31
或者说，问题是，组成这个uc的多个元uc中，会有一个是那个中间参与者启动的。
墨池 8:49:37
支持者（参与者）指向uc
墨池 8:49:46
比如
青润 8:49:53
这个时候你需要考虑的问题是，你这个uc是否过大了，业务逻辑是否过于复杂无法让用户看明白。
青润 8:50:13
也包括后面进行分析设计的技术人员是否能看明白的问题。
墨池 8:50:55
青润 8:51:24
如果你认为这个足以让所有参与人员都看明白，那就两个actor都指向这个uc即可，如果不能描述清楚，那就必须分割成多个uc了。
墨池 8:51:33
这个的意思是：
理财专员是启动者，顾客是支持者。
青润 8:51:42
你这个取款业务中，如果是柜台操作，似乎你理解错了。
青润 8:52:02
如果账户所有人没有提出申请，银行理财专员是不能启动这个业务的。
青润 8:52:12
你的业务理解中出了问题
青润 8:52:26
或者你举的这个例子不恰当。
墨池 8:52:43
我们去银行柜台取钱，启动用例的应该是银行柜台人员
青润 8:52:59
不，还是帐户所有者，绝对不是柜台工作人员。
墨池 8:53:09
而取钱的人，需要输入自己的密码，作为支持完成用例
墨池 8:53:15
怎么说？
青润 8:53:45
是的，那只是其中一个环节而已。
一个uc的启动actor必须是没有其他任何actor参与的情况下就可以启动的。
青润 8:54:09
银行柜台工作人员不过做了一个自动ATM的业务罢了，你自己想想，应该能想明白。
墨池 8:54:48
这个？
青润 8:54:50
或者，你自己细化一下元uc，然后通过元uc组合，重新拼接一下你的这个业务uc或者uc，然后再考虑。和合。
墨池 8:55:48
青润 8:56:10
你这个图有问题。
青润 8:56:22
注意你的业务边界。
墨池 8:56:40
我不是很了解银行的业务，我认为谁亲手启动了用例，谁就是启动者。
墨池 8:57:35
银行柜台人员和ATM机，应该是有区别的。
青润 8:57:53
这个在业务调研的时候，必须弄清楚。
银行业务人员是不能自己启动给用户的任何资金操作的。
他们都只是中间的参与者。
另外，外部系统和数据库是不参与分析的。
墨池 8:59:02
我去银行取钱，我们把卡给柜台人员，这个是系统外的事情。真正执行系统的人是柜台人员
青润 8:59:28
不，启动uc的还是你，必须有你的口头或者授权指令，他们才能操作。
墨池 8:59:49
我的理解是：这个是在系统外部
墨池 9:00:15
如果用上语音识别系统，那么就可以这么说了。
青润 9:00:30
绝对不能这么理解，这样理解的结果，那就是银行人员可以随意取用户的钱，不受限制了，你的系统会面临后面的严重问题。尤其是权限系统设计的时候。
墨池 9:00:46
因为外部口令的识别是在人脑中进行的，不是在计算机中，。
青润 9:01:11
业务系统边界的定义，这个问题，你还没有理解清楚。
墨池 9:03:15
那清润老师觉得这个场景的用例该如何画？
青润 9:03:32
哪一个场景，你做好场景描述。
墨池 9:03:58
就是我们去银行柜台取钱的用例
墨池 9:04:21
（此图出错，无法显示）
青润 9:07:53
你要先描述业务流程。
元uc可以分割如下：
1、提出取钱请求
2、系统启动uc，服务人员输入用户要求，
3、用户输入密码
4、服务人员/系统确认密码正确
5、用户输入取款数额
6、系统验证数额有效性，有效，则取钱，无效，则拒绝
7、用户确认取出的钱数。
青润 9:07:57
你的图没看到。
青润 9:08:00
没收到
墨池 9:09:28
1、提出取钱请求
2、系统启动uc，服务人员输入用户要求，
第二点不是很明白，怎么会是系统启动的uc呢？
青润 9:10:38
这个系统你可以认定是服务人员。
在银行业务中，服务人员和系统，是一体的，如果需要了解你可以了解一下古代中国银柜的存取规则和国外银行的早期业务模型，都是从那里演化来的
墨池 9:12:16
1、客户提出取钱请求，提供身份识别证件，
2、服务人员启动uc，并输入用户要求，
青润 9:12:46
可以，这样补充是正确的，我前面忘记了。所以需求本身就是交互进行补充完整的。
墨池 9:13:16
恩。
墨池 9:14:46
ATM机，那么取钱这个uc的启动者就很清晰是客户了
青润 9:16:13
银行的取款业务中，操作人员其实就是atm中的一些自动行为的具体化。
所以，如果你要细分银行柜台取款业务，把柜台人员作为uc存在，那么你这个取款业务就最好划分出来用户操作的部分，或者在状态/活动图中描述清楚。
青润 9:16:35
必须有一个地方做出清晰的描述，如果你不使用状态活动图，那么你就必须把这个取款uc分拆成多个。
墨池 9:16:38
如果把服务人员也纳入到银行系统中，那各式各样的服务人员很多，似乎会是业务边界变得很模糊
墨池 9:18:03
比如，我们要申请银行账号，我们先填写申请书，然后真正打开系统去注册的是服务人员，我们在系统外完成的资料填写。
墨池 9:18:22
这个问题会折射出很多问题
青润 9:18:55
这里面的问题就是你必须在业务系统中明确，那些是需要计算机自动实现的，那些是需要人工完成的。
青润 9:19:22
如果要明确出来，那么前面柜台取款业务，就必须把密码输入这个部分单独提取出来作为独立uc存在。
墨池 9:19:38
做个极端比喻：我老婆叫我去银行取钱，我去了，服务人员受理了我的业务。
墨池 9:19:48
是不是我老婆是启动者？
青润 9:19:55
另外，讨论问题的时候，不要随意扩大业务范围，要就事论事。扩大后，就造成了中国常见的会议跑题事情。
青润 9:20:17
青润 9:18:55
这里面的问题就是你必须在业务系统中明确，那些是需要计算机自动实现的，那些是需要人工完成的。
青润 9:19:22
如果要明确出来，那么前面柜台取款业务，就必须把密码输入这个部分单独提取出来作为独立uc存在。
墨池 9:20:54
哦。
墨池 9:21:21
那输入密码这个用例，和取款用例 是什么关系？
青润 9:21:29
include
墨池 9:22:50
回到刚开始那个问题，我从实际工作中，经常用箭头指向UC，表示该actor是uc的启动者，用箭头指向actor的，表示该actor是uc支持者。
青润 9:23:18
如果你的团队普遍都认同了这种使用方式，那就用下去。
墨池 9:23:40
恩，我不怕用。
就怕带大家走错路
青润 9:23:45
虽然我从来没有这样用过。呵呵。不过，我不会僵化的说你这个就不行。
青润 9:23:55
关键是团队内部一定要统一认识。
墨池 9:23:55
因为我们的接口很多都是通过具体用例来表示的。
青润 9:24:27
uml就是为了方便大家沟通交流的，如果大家都不认同，那你就失败了。只要大家都认同了，都能理解，错误，也是正确的。因为你的目的达到了。
青润 9:24:36
开发效率提升了，就不怕别的
墨池 9:24:38
墨池 9:24:49
清润老师说的很有高度呀
青润 9:24:51
毕竟我们不是写书！不是制定规范给全世界用。
墨池 9:28:27
谢清润老师指点，以后有问题再向您请教
墨池 9:28:31
青润 9:28:34
不客气。
no1.JPG来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/257598/viewspace-692475/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/257598/viewspace-692475/
2180
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
