【原】各家各路对用例的看法

这篇文章主要是摘抄自网上各大程序社区对用例的描述，当然用例这个概念已经是脱离程序语言了，纯粹的软件领域知识，涵盖到所有程序。以下描述主要来源Cnblogs,CSDN,JavaEye等国内知名开发社区，当然还包含一些程序论坛，对于以下评论，根据我的经验和知识相应做了一些修补和更改，希望作者看见可以谅解。为了尊重描述者，我会尽量加上ID。



1)CSDN社区

Vinep:

   我认为业务用例比系统用例粒度要更大些，用来描述业务。然后可以用活动图来描述事件流程。而系统用例描述系统要做的事情，粒度会更细，活动图中的每个活   动都有可能成为系统用例。

 

我：

他的观点简化可以这样描述：业务用例->活动图->系统用例

 

qingrun:

用例不是用来描述业务流程的，是用来描述业务或者说是用来描述需求的。流程只能用活动图/状态图或者泳道图来描述。

 

我：

他的观点是，业务流或者说事件流用活动图、状态图来描述

 

happyjun2000:

通过用例的实现，即通过活动图来转化用例，应该理解为通过分析探索用例的实现，可以使用活动图，也可以使用时序图，意在分析用例场景，寻找对象。但真正完整的用例实现，应该是在设计模型中进行描述的，因为那个时候的对象一般都是设计确定的，那样才能真正的描述系统的对象交互，甚至可以作为以后的测试用例来使用。

 

我：

 主要意思是，用例的实现能通过活动图或者时序图来分析得出。

 

ozzzzzz:

Use Case是一种简单的技术，当你要去确定它们的include,extend,generalize关系的时候，实际上就是已经过于关注细节了。当然UML和很多Use Case建模的书上都大量而详细的讨论了Use Case之间的这些关系。可是你看看它们有一本把这个问题完美的解决来吗？问题其实很简单，根本就不是什么关系的问题，而是Use Case粒度的问题。当你要确定这些关系的时候，往往就是你粒度过于小的时候。这个问题要讨论会耗费很多时间，你记住我的结论就可以了。不要去和那些所谓的UML专家纠缠这个问题，它们使用Use Case的时间太短，根本就不知道什么是Use Case.或者他们为了突出自己的成就而去扩展Use Case的使用，但那些只是一些人的做法。实际上Use Case广泛存在于商业分析领域，我们最好保持它的简单。Use Case不要去涉及系统内部的流程，那不是它善长的领域。

 

我：

作业认为用例应该尽量简单，不涉及细节关系。而引申的观点是粒细度可以通过活动图来描述。

 

2)CnBlogs社区

 

3)JavaEye社区

 

4)其他社区