用例的理解

         用例是一种把现实世界的需求捕获下来的方法，需求里包含客户对这个系统的各种各样的愿望。我们要描述一个系统的功能性需求，就是要找到对这个系统有愿望的人，让他们来说明他们想要在这个系统里做的事，想要的结果。如果所有对系统有愿望的人要做的事情都找全了，也就是问题领域的抽象角度都找出来了，那么系统的功能性需求就确定了。接下来的工作就是实现用例，一旦用例都实现了，那么问题领域也就解决了，这就是用例驱动开发的原理。其他的分析，设计，测试等都是由用例来驱动的，一个用例就是一个开发单元，设计单元，测试单元。和用例紧密相连的是参与者和边界，这3者的关系非常紧密；另外用例粒度的把握也非常重要。我个人认为建模同样是用例驱动的，因为寻找用例的过程，就是确定参与者的过程，同时绘制出用例实现的活动图，确定用例规则。那么现实世界就可以映射到业务模型中来了。因为不管是任何行业，无论什么业务，其本质无非是由人，事，物，规则组成的。人是中心，人要做事，做事产生物，做事要遵守规则。人驱动系统，事体现过程，物记录结果，规则是控制。建立模型就是要弄明白有什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物，规则之间的关系定义出来，模型也就出来了。UML采用参与者对应现实世界的人，用例对应参与者的业务目标，业务场景对应规则，业务对象对应物。人，事，物，规则就这样在描述用例的过程中被模型化了，于是现实世界就转化成了业务模型，这也是面向对象分析方法的第一步--现实世界映射到了对象世界。

       UML中最重要的是什么图呢？毫无疑问应该是用例图,用例是后期时序图和实际开发的重要依据。
       首先用例产生在需求分析阶段,这这个阶段系统分析人员对用户对系统要求的理解，也就是用户的愿望的描述。有时候我们习惯把用例说成系统的功能。 但是用例一定是系统的功能，但是功能不一定是系统的用例。比如系统要求我在断电的时候要把数据保存起来，但是这个能写在用例里面吗?当然不能。这只不过是系统的一个限制，不能算是一个完整的愿望。接着说明一下用例的特点。然后根据特点来说明用例的建立过程。
用例特点：
一、用例是相对独立完整的
     一个用例不需要其他用例来完成和它进行交互。也就是说我在实现这个用例的过程中，不能出现做完用例1,然后才能做用例2。
     比如我们去买菜。显然给钱不是一个用例，给钱只是买菜的一部分，不能单独成为一个用例。
二、用例的执行结果对于参与者来说是可见的有意义的
      这句话的意思就是说，一个用例必须有一个确定的结果，这个结果是有意思的。比如到银行取钱。显然输入密码不是一个用例。因为输入密码以后到底是什么结果，密码正确，还是错误？这些结果都是未知的，一个结果未知的过程不能算做一个用例。
三、一个用例必须是由一个参与者发起，不存在没有角色的用例，用例也不该自动启动
       我们要首先确定用例边界，我们在哪个范围之外去寻找用例。不同的范围会产生不同的用例。比如我们要以系统为边界去确定用例。那么角色就应该是系统之外的东西不应该是系统。比如ATM取钱，显然ATM不是一个角色,我们设计的用例也不应该包括ATM出钱这个用例。ATM是我们系统的一个部分，他最终出现在部署图上。
四、用例一定是动宾短语
       比如：喝水、取钱、 买菜、 做饭等。因为这样才能构成一个完整的事件。角色是主语，动宾短语是动作和动作的受体。这样主谓宾都有了，才是一个完整的事件。
五、一个用例是一个需求单元、分析单元、设计单元、开发单元、测试单元
       设计完一个用例，我们接下来的工作都要以单个用例为主线去开发，测试。这样就印证了开篇的那句话。用例对于开发来说是相当重要的。
那么用例是如何确定的呢?
1、确定系统的边界。
2、确定业务主角。
       这个是最重要的,也是常常困扰我们的地方。业务主角是与系统交互的人和事物。让我们常常困惑的是有些业务人员他明明参加了业务，但是他却是被动参加的。不好说明他有什么目的，但是又确实是在系统中做了事情。这样的业务人员，我们把它叫做业务工人，不是业务主角。
区别他的办法就是回答下面三个问题。
1、他是主动向系统发出请求的吗?
2、他是完整的业务目标吗?
3、系统为他服务吗?
六、参与者到角色的过渡
       参与者是一个具体的概念，角色是一个抽象的概念。从众多的参与者当中,抽象出相同的一部分。就形成一个角色。比如：教授、副教授都可以讲课 ,把它们抽象出来，做出老师讲课。最后检查是否找到了所有的参与者。
通过下面这些问题来做出测试
1、是否对系统中的所有角色都进行了建模和说明
2、每个参与者是否至少涉及到一个用例
3、你是否列出至少两名可以作为特定参与者的人员
4、是否有两个参与者担任与用力相关的角色
5、参与者是否有直观的描述性名称
      最后将参与者和他们的愿望结合起来。就形成了用例图。记得最后形成的一定是一个完整的事情。由参与者做主语，用例做谓语和宾语。用例图只是一些符号，抽象程度较高。一百个人看了也不一定结果相同。所以用例要附加相关的用例文档加以说明。用例形成映射基本就是用户界面(UI)。这一点大家要清楚。不要做了用例再回头重新找界面。