最初由 backlove 发布 [B]偶的顺序是先确定系统边界，再找系统执行者，再找用例。有些细节，比如信息表中的内容在用例图是做不了的。 [/B]
使用道具 举报
image002.gif (3.16 KB, 下载次数: 34)
下载附件
2006-9-27 12:20 上传
最初由 newzqs 发布 [B]我做的是这样 [/B]
最初由 newzqs 发布 [B] 以这些需求来讨论是不是应该用包含不太恰当,赞成单独画一个用例 如果从执行者角度来说,选择必修课和选择修补课都是完成选课这个目标，可以算做一个用例，也可以降低目标把选必修课和选候补课算作两个用例，这要看用例描述时才能决定。但是把选必修课和迁候补课包含再选课中不妥，这样做是把包含关系当层次关系使了。 完成登记和通知计费不能算做单独的用例，只能算做用例中的一个步骤。 [/B]
最初由 lodge 发布 [B] 完成登记作为单独的用例是因为需求中对该状态有特别的描述. 偶认为实际的情况是, 在完成登记之前学生反复修改课程表, 这是课程登记的一部分可以用若干天来完成, 而完成登记则是正式向学校提出申请, 学校考察了各种条件之后, 给予许可, 并通知计费. 可见完成登记是非常重要的用例, 在它之前课程表只是草稿, 而在它之后就是正式的合约一样的文档了. 通知计费之所以做为单独的用例是因为它关系到了一个独立的执行者. [/B]
最初由 lodge 发布 [B] 你做演绎了, 修改课程表并没有说要重新计费的. [/B]
最初由 newzqs 发布 [B] 有些时候演绎也是必须的,如果不做这种演绎就将漏掉很重要的需求. 通常我遇到这种情况的时候,总是尽可能多的考虑相关的问题,然后拿到用户处验证.如果用户说没用,去掉就好了.但你不说,用户会想当然的认为是那样的,而这时你就丢掉了这个需求. [/B]
最初由 newzqs 发布 [B] 如果这样说,那么完成登记为什么又包含在选择课程的用例中呢? 如果有这种包含关系,那么说明选择课程用例如果没有完成登记,那么选择课程这个用例是不完整的. 这和你说的完成登记作为单独用例又是矛盾的. 通知计费不能成为一个单独的用例,一是因为它没有主动执行者.二是因为通知计费只是选择课程这个用例成功完成的所必须的一个步骤.其价值包含在选择课程中了. [/B]
最初由 lodge 发布 [B] 需求的描述就是这样说的. 每门课程人数不得多余10人或少余3人。一旦学生完成登记过程，登记系统将信息传入记费系统以便计算学生在本学期的学费数额 [/COLOR] 很明显这个步骤是由学生执行同时又涉及到外部其他的执行者. 偶那么画是很自然的. 画USE CASE不应该加入任何自己的观点, 人家怎么说这里就怎么画, 至于合不合理, 要等到分析之后, 重新整理USE CASE, 现在要做的就是一点不走样地把用户的需求画出来. [/B]
最初由 lodge 发布 [B] 这种演绎要到分析USE CASE的阶段才能做, 在做USE CASE模型的时候, 最基本的原则就是要和需求一模一样地做, 这样才能保证分析对象的准确性. [/B]
本版积分规则 发表回复 回帖后跳转到最后一页
楼主: 前夕的泪
IP卡
狗仔卡
发表于 2006-9-27 12:14
显身卡
发表于 2006-9-27 12:57