前言：
之前已经说过如果是我我会选择第一张UML图是活动图，事实上，通过这种方式能够更好的帮助我们分析用例，因为用例涵盖过程和工作流分析，所以活动图能够成为用例的有用的辅助措施，对于复杂工作流的业务来说更是如此，所以笔者的机房合作就是把活动图的每一个活动作为一个用例的候选，下面可以看一下转换流程。
一、用例到底是什么
一个用例其实可以分成两种不同的意义：一个意义是从用户的角度出发；另一个意义则是从系统的角度去看。从用户角度出发，我们可以发现每一个用例所代表的都是用户对于系统的一个期待，一般来说，我们把这样的期待当成是用户进入系统的一个请求，用属于方式来说，就是一个用户目标。所以看一些比较老的电子书都会说每一个用力都是一个用户目标，这就是从用户观点去思考用例，从这个观点来说，用户通常都是非常明确的。但是从系统的角度，则又又有另外一个不同的想法，系统所看到的每一个用例，其实代表的是系统所提供的某种服务，这个服务是由系统内部的诸多程序（现在我们通常称为对象）通力协作共同提供的，所以基于系统会把重点放在服务本身上面，去在乎到底哪一个用户来使用这个服务。
事实上，笔者认为，这两个观点互为表里，只是很多书籍会有一些侧重，所以一个真正的软件设计者必须同时从“用户角度”及“系统角度”分别思考。
二、四个问题解决“用户角度”“系统思考”双重思考
我在最上面说过，每一个活动作为一个用例的候选，那如何从系统角度和用户角度从活动里面找出用例呢？
四个问题：
1.在这个活动中，谁是主要工人？
2.这个活动进行中，需要系统提供的服务么？
3.系统需要提供什么服务？
4.系统需要其他信息系统支持么？
笔者是自己列了一个表格，把自己的活动进行筛选。如下图：
上面的图只是我分析的一部分，但是大家可以清晰的看到，比如上交费用这个活动，系统是不提供服务的，这要我们就可以进行筛选我们的用例，根据系统需要的服务进行选择用例，用例图如下：
三、写用例描述
在用例图里面，画出用例图并不是意味着结束，用例描述也是十分重要，我之前说过，一个用例里面都隐含着一个流程，用例描述包括：简单描述，正常流，替代流。笔者只是选择使用占80%正常流做个例子：
查询余额
正常流：
1. 一般用户提供【卡号】给系统
2. 系统根据【BR1】查询【卡单】的余额
3. 系统将【卡单】的余额信息显示出来
·卡号：12位的整数
·余额表：卡号、余额、时间、备注
BR1:
For each卡号：
①找到卡号，查询卡号的余额字段
②若是没有找到卡号，则通知用户检查卡号
我先说明余额单不是我们的数据库的卡单，而是客户提供的对象实体，客户在实际业务流程时候必然也是有一个实体的卡单来记录一些关于卡的基本信息，以供查询翻阅。所以这个余额单并不是数据库里面的表，这个阶段没有进行数据库设计，所以卡单是一个具体的对象。
总结
光是一个小小的用例图已经有这样那样的学问，我觉得我的UML只是学了冰山一角，在以后的项目里面，好的UML图给我们节省了不只是一点点时间，在高效的今天，高效实用UML也是很重要。