作者 内容
 pixie32   菜鸟提问：当一个用况的逻辑需要另一个比较复杂功能的支持才能实现时，是否需要把那个复杂的功能作为一个新的用况？
　

最初的这个用况功能比较简单，就是某一个事件触发以后（用户运行了程序），按照用户给定的流程一个一个的往下做。但是这个流程有分支，其中有一个判断需要知道用户是第几次运行这个程序才知道下一步该做什么，这就需要一个统计的功能，我要提的问题就是这个统计功能是作为一个新的用况存在，还是合并在原来的用况当中？还请各位大虾不吝赐教。谢谢
 03/10/28 10:57 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 god2000   回复: 菜鸟提问：当一个用况的逻辑需要另一个比较复杂功能的支持才能实现时，是否需要把那个复杂的功能作为一个新的用况？
　

关键考虑这个问题：统计事件流是否独立，是否可以被其他用况复用
我觉得这个统计很简单，作为一个动作问题也不大呀，复杂在什么地方呢
实在感到复杂可以作为一个新用况，与原用况使用include关系，这样减少复杂性了吗，可能没有

 03/10/28 12:33 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  这个不用体现在用况中，你在作需求捕捉和分析工作，不是在作设计。
　
 03/10/30 23:56 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  这个不用体现在用况中，你在作需求捕捉和分析工作，不是在作设计。
　
 03/10/30 23:56 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 god2000   回复:j2ee说的有道理，将这个需求纳入用例好像不合适
　

1、问题在于这也是需求的一部分，用什么方式表达。作为用例找不着角色，作为登陆用例的可选流如何
2、在框架设计和设计模式研究时,app当作角色好像很有价值

 03/10/31 09:03 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 savagearts  回复: 这个不用体现在用况中，你在作需求捕捉和分析工作，不是在作设计。
　

说得好。当系统的边界界定好以后，基本上用例就是比较准确唯一的。不存在层次之分。在这个系统里边，每个用例之间都是同等的关系。
 03/10/31 13:55 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 xuf0000  回复: 这个不用体现在用况中，你在作需求捕捉和分析工作，不是在作设计。
　

这也不是绝对的.use-case也有可能详细设计的过程中做一点调整.这具体也要看各人对use-case的用法了,有的就是高层的,反映和外界的一次交互,一个动作序列,得一个结果;这对明确用户的需求是非常好的,也是用例本身的根本目的;也有的在这后面会稍微进一步,对系统内部也会产生一些use-case来支持.就是说,use-case也可以有一个层次之分.具体就看需要了.当然,我们使用用例,还是应该依据其本质行事.
 03/10/31 14:30 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  恢复
　

1. 用例是部分需求的很好的表达方式，但是不是所有的需求都可以在用例中表达。

2. 对用例的细化关注系统的边界，系统内部的处理方式不包含在内。

3. 对其他需求的建模，可以采用状态图，活动图的方式刻画。比如公文流转的过程。

4. 用例在需求阶段应只包含“做什么”，而不要把“怎么做”牵扯进去。在后续阶段可以补充些细节。在设计阶段应关注于"用例实现"
 03/10/31 22:21 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  用例只是刻画某些需求的适宜方式。
　
 03/10/31 22:22 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首