所在位置:答疑 - 内容   
A通过网络向B 注册,B返回注册成功,然后B向A发送一个C的列表
 

2006-6-23  14:34:25  钦旋:  上次是一个电子会议的项目。硬件厂商为卖设备需要一套软件.主要是会议签到使用非接触式卡,但是子系统比较多. 
2006-6-23  14:37:19  潘:  子系统比较多--?? 
2006-6-23  14:37:42  钦旋:  比如,与会人员资料必须事先录入,在此,录入资料是否可以认为是一个用例(或者是资料管理) 
2006-6-23  14:40:39  钦旋:  子系统:1,签到时需要显示人员信息的子系统.2,提供手工签到的子系统,3,提供个人,单位,会议资料录入,排座位等功能的子系统4,还有控制音频视频的子系统 等 
2006-6-23  14:42:03  潘:  子系统不是这么分的。系统就是系统,这些只能叫做需求分包 
2006-6-23  14:43:32  潘:  你尝试用我们课上教授的业务序列图把这个开会的过程画出来?
 
2006-6-23  14:49:27  钦旋:  签到的流程比较好确定,但是会议中的流程不好定,因为这部分需求不太确定.在这种情况下应该如何处理呢 
2006-6-23  14:50:32  潘:  因为这部分需求不太确定--是画你这个系统没上马之前的流程,然后结合愿景,推敲出新系统的职责,这样才能严谨的得到需求 
2006-6-23  14:55:33  钦旋:  如果硬件厂商自己已经有想法,而且想法和我们推敲的流程不太吻合,是否应该以硬件厂商为准?  
2006-6-23  14:58:06  潘:  谁是老大以老大的想法为准 
2006-9-4  10:45:45  钦旋:  有一个用例,A 通过网络向B 注册,B 返回注册成功,然后B 向A 发送一个C 的列表, 然后A 逐个向C 注册.实际上C 有多个,B 起到C 的负载均衡的作用.这几个动作是否可以看作是一个用例? 
2006-9-4  10:49:33  潘:  首先你要说清楚的是:研究对象是谁--谁的用例?否则是没有意义的 
2006-9-4  10:50:14  钦旋:  B 和C 同属于一个系统,即我们的研究对象 
2006-9-4  10:50:28  潘:  研究对象是B+C 是吗?你开发的系统就是B+C? 
2006-9-4  10:51:15  钦旋:  还有其他,不过是内部的.可以认为是B+C 
2006-9-4  10:52:03  潘:  那么,B+C 首先就不是需求,系统对外界来说就是一个整体。以A 的观点来看,他就是向"系统"注册,至于系统里面是B+C,还是BBBBCCCC,不管他的事,他只要注册这个功能,加上一些性能要求。BBBBCCCC 那是设计人员为了满足非功能需求所构思的一种设计方案 
2006-9-4  10:55:39  钦旋:  用例是否仅用于表达原始需求?因为有时候会遇到,比如把整个系统作为研究对象, 则有一个"注册"的用例.然后我们通过分析认为需要B+多个C,当把B 作为研究对象是,需要(可以)对B 写用例吗? 
2006-9-4  10:59:58  潘:  认为需要B+多个C,当把B 作为研究对象是,需要(可以)对B 写用例吗?--用例本来就是为了反映涉众心里对这个系统的想法,如果认为设计上需要B+C,而涉众又无法验证和理解这一点,那么这种"用例"是没有意义的,为什么不说白了就是设计,何必套上用例的外衣?另外,B+C 到底是不是需求,这完全是实事求是的事情。如果项目是分包多方,一定要B+C,这个时候B+C 可能是涉众不允许改变的,那么,就可以以B 作为研究对象。而在这里,B+C 并不是涉众在意的,是设计人员的构思而已 
2006-9-4  11:01:12  潘:  "需求"是涉众不允许改变的东西,否则就不要写在用例文档里。这个不是"你" 怎么认为的问题,而是涉众怎么认为的问题 

2006-9-4  11:03:51  钦旋:  这样说我对于B 写用例本身是一个错误的概念.因为对于用户只有系统没有B 
2006-9-4  11:08:12  钦旋:  我们分析后决定分成B,C 两部分,然后各由不同的人来分析设计,这个时候,他们可能只关心各自的子系统以及相关的执行者 
2006-9-4  11:11:12  潘:  他们可能只关心各自的子系统以及相关的执行者--完全可以用类图、序列图、构件图解释,不需要用用例这种方式,用例图不适合表达这种东西