不知道大家有没和我类似的感觉，是在做开发的时候，经常看到需求文档里的用例2字，或者听到关于用例的谈话，或者测试用例之类的，一般的感觉是用例是一个需求功能点，也没去太在意，这里我想自己做个对于用例的总结。

　　我不想过于刻板的去讨论用例的概念，这里先从一个例子入手，比如我问你：请在30秒内说出尽可能多的筷子，勺子和盘子的相同点与不同点。

　　不知道大家是否有种感觉，是脑子里似乎都知道，但是要一下子通盘考虑的说出来，却一时间不知如何下手？其实这个问题没有标准答案，看似简单的问题反映了我们是否习惯以抽象的方法去看待和理解事物，这里的每一个相同点和不同点都可以来自一个抽象角度。例如：从用途的角度去抽象时，它们的相同点可能是3者都是餐具，不同点是筷子是用于夹的，勺子是用于舀的，盘子是用于盛的；从使用方法的角度去抽象时，它们的相同点可能是3者都是需要用手拿的，不同点是拿的方式不同；还可以从其它抽象角度得出不同的结果。

　　在软件项目中，当我们自己试图去分析需求，面对大量的需求资料时，是否觉得无从下手呢？这时与其说是分析能力不足，不如说是自己还没有找到明确的抽象角度！面向对象和面向过程的不同是面向过程希望你通盘考虑，这时人脑需要考虑的信息量变得很大，使得自己大脑发晕或一时反映不过来，问题变得复杂化；而面向对象希望你通过抽象从而以不同的角度来把问题分解成小块，从而使得问题简单化，回想下刚刚的筷子，勺子和盘子的例子知道啦。

　　具体来说，在做需求分析的时候，首要目标不是通盘考虑，不是要弄清楚业务是如何一步一步完成的，而是要明确有多少个参与者？每个参与者的目标是什么？参与者的目标是我们的抽象角度，与分析一个个复杂的业务流程相比，单独分析参与者的一个个目标要简单的多，参与者的目标是一个用例，这也是为什么用例会成为建模的方法的原因之一。

　　用例是一种把现实世界的需求捕获下来的方法，需求里包含客户对这个系统的各种各样的愿望。我们要描述一个系统的功能性需求，是要找到对这个系统有愿望的人，让他们来说明他们想要在这个系统里做的事，想要的结果。如果所有对系统有愿望的人要做的事情都找全了，也是问题领域的抽象角度都找出来了，那么系统的功能性需求确定了。接下来的工作是实现用例，一旦用例都实现了，那么问题领域也解决了，这是用例驱动开发的原理。其他的分析，设计，测试等都是由用例来驱动的，一个用例是一个开发单元，设计单元，测试单元。

　　和用例紧密相连的是参与者和边界，这3者的关系非常紧密；另外用例粒度的把握也非常重要，这些方面的讨论可以参考我的上一篇文章《面向对象案例分析实战》，这里不展开细说了。

　　我个人认为建模同样是用例驱动的，因为寻找用例的过程，是确定参与者的过程，同时绘制出用例实现的活动图，确定用例规则。那么现实世界可以映射到业务模型中来了。因为不管是任何行业，无论什么业务，其本质无非是由人，事，物，规则组成的。人是中心，人要做事，做事产生物，做事要遵守规则。人驱动系统，事体现过程，物记录结果，规则是控制。建立模型是要弄明白有什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物，规则之间的关系定义出来，模型也出来了。

　　UML采用参与者对应现实世界的人，用例对应参与者的业务目标，业务场景对应规则，业务对象对应物。人，事，物，规则这样在描述用例的过程中被模型化了，于是现实世界转化成了业务模型，这也是面向对象分析方法的第一步--现实世界映射到了对象世界。