use case的困惑.txt

一些关于UML的经典讨论

USE CASE的困惑

--------------------------------------------------------------------------------


这里借用了以前woodysteven提出问题（好象没得到很好的解答），但这个问题对初学者来说，可能普遍存在，请高手指点。 

在需求分析阶段，分析人员用use case来描述用户需求。在解决问题阶段，开发人员需要从use case中的interaction图中找出对象及其属性、操作出来。 

假设有这样需求：学生档案管理中，用户经常需要做三件事：增加一条学生记录、修改一条学生记录，删除一条学生记录。 

请问要如果要画出use case图？以下2种方法是否正确，哪种更合适。 

方法1：只画一个管理学生记录的use case图，分成3个情节，分别画3个交互图： 
情节1 添加学生记录 
情节2 删除学生记录 
情节3 编辑学生记录 

方法2：画3个use case，分别为添加记录、删除记录、修改记录。放在一个学生记录管理的package中。每个use case画一个交互图。 

=====
原文(Ms.OO于2001/03/30 08:52粘贴) 
建议：方法一 
--------------------------------------------------------------------------------

只需一个Use case，但其下画三个顺序图。Use case是系统功能的外在表述，无须太细。“添加记录、删除记录、修改记录”在划分Subsystem时不可能不在一起，所以一个Use case就够了。至于拾Use case下面画几个SD，看需要了，反正能把问题说清楚就好。 

“我只要高兴就好！” 
===
可以这样做，把增加、删除，修改 作为use 对应的class 的行为方法，这样一来程序编写是很方便的 - <0b> 独步江湖 2001/03/30 10:41 (14次点击) 
===
原文(drugplus于2001/03/30 16:32粘贴) 
回复: 谢谢大家！ 
--------------------------------------------------------------------------------

今天看了一个example(fids)，用的也是方法一。 
独步江湖，我觉得你的方法不错，但如果碰到复杂的情况，增加、删除、修改要和不同的类交互，或发送不同的消息，就会很乱，你觉得呢？ 

====
原文(arfayr于2001/03/30 09:54粘贴) 

--------------------------------------------------------------------------------

偶倒认为关键是系统的规模，如果仅仅是这么一个小的东东，画三个UseCase也能很清晰的说明问题。也就是说，如果这么小，这三个小的可以合一的功能也就没有必要合了，相对大了。当然如果系统大，比如学生成绩管理系统，涉及面大，可以合为一个，而作为一个需求，就是 学生纪录的维护。