所在位置:答疑 - 内容   
主执行者发邮件,辅助执行者收邮件的用例
 

2009-4-2  17:00:30  liaoxiao:  系统用例的辅助执行者如果是人的话,怎么体现系统间消息在主执行者和辅助执行者之间的传递。如一个人主执行者发邮件,辅助执行者收邮件的用例,其用例规约中基本路径如下写可以么?
2009-4-2  17:00:58  liaoxiao:  1.主执行者提交发送邮件
2009-4-2  17:01:23  liaoxiao:  2.系统发送邮件到辅助执行者
2009-4-2  17:01:36  liaoxiao:  3.辅助执行者接受邮件
2009-4-2  17:02:10  liaoxiao:  还是2 应该是系统发送邮件
2009-4-2  17:02:12  liaoxiao:  ?
2009-4-2  17:04:13  潘:  首先要明确研究对象:邮件系统
2009-4-2  17:04:20  liaoxiao:  对的
2009-4-2  17:04:22  liaoxiao:  嗯
2009-4-2  17:04:49  潘:  发件人对邮件系统的期望是什么
2009-4-2  17:05:14  liaoxiao:  将邮件发送到收件人那
2009-4-2  17:05:43  潘:  要是收件人睡着了,或者玩去了,没有收邮件。发件人会不会骂邮件系统不称职
2009-4-2  17:05:43  liaoxiao:  主要疑问是感觉对系统在中间传递的过程用用例规约有点不太好表达
2009-4-2  17:05:58  潘:  跟这个没关系。
2009-4-2  17:06:05  liaoxiao:  那就是必须画两个用例
2009-4-2  17:06:12  liaoxiao:  一个用例的主执行者是时间?
2009-4-2  17:06:30  潘:  期望,契约和承诺
2009-4-2  17:06:41  liaoxiao:  嗯
2009-4-2  17:06:54  潘:  你就按系统能承诺的来
2009-4-2  17:07:25  潘:  收件人-->收邮件

2009-4-2  17:08:32  liaoxiao:  如果是要求邮件来了就自动收的呢 不是需要收件人去操作
2009-4-2  17:08:39  潘:  拿Outlook 来说,更准确的是:用户-->启动(更贴切更长的名字是:接收上一次关闭以来所有邮件);用户-->发新邮件;用户-->回复邮件;时间-->定时检查新邮件
2009-4-2  17:08:52  liaoxiao:  哦
2009-4-2  17:09:06  潘:  用户--》收邮件
2009-4-2  17:09:16  潘:  用户-->×××
2009-4-2  17:09:37  潘:  按照菜单上的来就是了

2009-4-2  17:10:03  liaoxiao:  如果需求要自动就是 时间-》定期检查 如果不要求自动就 收件人-》接受邮件
2009-4-2  17:10:08  liaoxiao:  这样理解不知道对不?
2009-4-2  17:11:00  潘:  要是去想"启动时收","用户命令收邮件","定时收邮件"里面有收邮件的步骤,就合用一个用例"收邮件"就错了
2009-4-2  17:11:17  潘:  一般这些用例都有的

2009-4-2  17:13:57  liaoxiao:  嗯 那这样处理 启动时收作为启动用例的一个包含用例 用户-》启动 -》 (include)启动接受邮件 用户--》主动接受邮件 时间--》定期检查邮件
2009-4-2  17:14:44  liaoxiao:  应该是extend 吧?有邮件时候才接受
2009-4-2  17:14:47  liaoxiao:  ?
2009-4-2  17:15:02  潘:  写文档,不要用关系!!!!
2009-4-2  17:15:06  liaoxiao:  哦
2009-4-2  17:15:33  潘:  好好讲故事,不要玩那些虚的
2009-4-2  17:16:03  liaoxiao:  可能有时候太扣细节了
2009-4-2  17:16:50  潘:  和细节没关系,要用"卖"的观点看,卖有卖的细节,做有做的细节
2009-4-2  17:18:51  liaoxiao:  嗯 越画越感觉系统用例太多了 
2009-4-2  17:19:11  潘:  多不好吗?
2009-4-2  17:20:52  liaoxiao:  太多了 设计人员看晕了 有时候很简单一件事 或者公司实现层次都是约定俗
成了 用卖的观点去分解的话感觉太细了
2009-4-2  17:21:42  潘:  其实很多时候并没有那么多,能卖钱的才算。很多时候都是自作多情找的麻烦,例如硬要include,extend 出一堆不能卖的东西,当然多了
2009-4-2  17:22:34  潘:  设计人员看晕了,关卖什么事。设计人员没那水平就得换掉啊。

2009-4-2  17:23:28  liaoxiao:  :)
2009-4-2  17:23:44  潘:  用例多不代表后面的类就多啊,你收邮件的类不都是那个吗
2009-4-2  17:24:33  liaoxiao:  那是不是用例其实有点吧用户需求细化,能卖的都算,尽量细些
2009-4-2  17:24:43  潘:  有本事用1 个类完成10 个可以卖的用例,设计人员应该觉得有成就才是,怎么反而觉得不高兴,晕了?
2009-4-2  17:25:45  潘:  差不多,需求时,心里想着"卖"字。设计时,再尽量考虑复用。

2009-4-2  17:25:59  liaoxiao:  还有一个 用户的需求,公司目前肯定技术实现不了的 写进还是不写进呢 这个用例文档ea 要和用户交流的。
2009-4-2  17:26:50  潘:  用"视图"和涉众交流,底线:涉众不需要了解UML 之类的东西
2009-4-2  17:27:25  liaoxiao:  嗯
2009-4-2  17:27:45  潘:  把需求变成涉众能接受的任何形式的和他交流,而且,焦点是"涉众利益",不是"需求"。需求是我们定的,不是某一个涉众有资格决定的。
2009-4-2  17:28:20  liaoxiao:  嗯 最关键的还是用例文本中的涉众利益
2009-4-2  17:28:31  潘:  局长要这样做,办公窗口"用户"不高兴又有什么关系
2009-4-2  17:30:01  liaoxiao:  嗯 上午传过去的ea 文档有大的问题么?
2009-4-2  17:30:25  潘:  我先下,晚上不用等我,我回邮件给你就行了:D