用例实在是个很让人难以理解的东西，不同的书有不同的说法，看的越多就越糊涂，现在已经记不清是从哪本书里看到的概念了，就是用例是一系列没有明显时间中断的连续发生的事情，刚看到这个概念的时候那真是如获至宝，所以后来相当长的一段时间内，做需求写用例都是奔着这个目标去的，但慢慢问题就出来了，如果按着这个定义来，稍小的项目还可以，稍大一点的，光画用例图就够受的了，就不讲那一堆密密麻麻的用例，客户是否真的能看的清楚明白了。回过头来想想，当时对于这个概念的接受，说白了还是源于过重的程序员思维，因为这样的用例更容易映射到设计中去(主要是方便画顺序图)。一个没有明显时间中断的动集不就是一次人机交互嘛，执行者输入了什么，机器怎么处理的，返回给了执行者什么东西。按着这个思维写出这个用例的详细步骤，然后在设计阶段把这个详细步骤直接拿过来，结合一下领域模型大致提取一下对象，再给他们分配一下职责，再理一下关系，然后再把这些串起来，OK，一张初步的顺序图就出来了，这多方便啊。
当然话虽如此说，但并不代表着我就否定了上面的这种定义。上面的这种定义本身没有错，只是相对于某些项目来说，尤其是中型以上的，粒度过细了。经常有人把用例及其之后的业务建模比作是客户和设计之间的一座桥梁，我觉得这个比喻并不恰当，用例及业务建模并不能象桥梁那样把两端进行无缝的连接，充其量他只能算是立在两岸之间的一个木桩，他和两端都存在着一定的距离，于是问题就出现了，那就是这个木桩应该是靠客户更近些呢还是靠设计更近一些。这个问题我给不出准确的答案，但个人认为，应该更偏向于客户一方，因为，用例以及业务建模的主要目的还是获取更准确的需求，而要想获取更准确的需求，至少你的用例以及模型得让客户更容易理解，所以用例粒度以建业务模型主要依据还是客户的需要，而非设计人员或者程序人员的需要。故而用例的粒度并非必须达到“一系列没有明显时间中断的动作集”这样的细粒度，那么粒度究竟多大为宜呢,这我也说不准，不仅说不准，实际操作中也很拿捏的准，这和客户的理解能力，客户的配合度，个人的交流能力以及项目经理给你分配的需求调研的时间都是息息相关的。所以用例的粒度怎么界定这东西实在是让人很头痛的一件事，看书也是废的，最终还得实际情况实际对待
本来这篇文字的名字叫关于用例的理解的，但写完后，再回头看一遍后发现竟然和原来看用例方面的书一样，越看越迷茫了。于是乎将名字改为关于用例的废话了
短短的这一点字，竟然写了我一个多小时了，这也太废时间了，突然发觉那些写文章共享的人的实在是太伟大了。