UML之用例的发掘

首先用例的定义就是由参与者（actor）驱动的，并且给参与者提供可观察的有意义的结果的一系列活动的集合，用例的来源就是参与者对系统的期望。所以发现用例的前提就是发现参与者；而确定参与者的同时就确定了系统边界。我们这里提到的参与者就是业务主角（主要区别于业务工人）这样能够更容易理解用例的过程；在开始捕获用例之前，在强调你已经能够清楚地理解了下面几个问题：

1. 主角位于系统边界之外
2. 主角对系统有着明确的期望和明确的回报要求
3. 主角的期望和回报要求在系统边界之内

接下来我们可以对主角即业务代表进行访谈。访谈时请不要试图让业务代表为你描述整个业务流程，也不要涉及表单填写一类的业务细节，甚至你可以不关心业务规则，更不要试图让业务代表理解将来计算机系统会如何工作。你只需要让业务代表从他自己的本职工作出发来谈谈他的期望，并时时提醒和引导那些喜欢一讲什么事情就能深入到细节当中去的客户。

可以通过下面几个问题来引导业务代表：

1. 您对系统有什么期望？
2. 您打算在这个系统里做些什么事情？
3. 您做这件事的目的是什么？
4. 您做完这件事希望有一个什么样的结果？

简单用纸和笔记录下业务代表的访谈结果，从结果中找到用例。不要希望客户和你一样对什么都了如指掌，也不要希望客户能够有条理分层次地把系统的期望表达出来。从客户也许语无伦次，也许杂乱无章的谈话中找出主角期望的真实和有效目标是你的工作。

你应当清楚，主角想做的和要做的不一定能是他的真实目标，也许只是他做事情的一个步骤。比如客户会说首先做……，然后做……，最后做……，你需要从冗长的谈话中为客户总结出他的真实目标来。另外，主角对系统的期望也不一定是一个有效地事件，也许只是一个愿望，比如客户会说我希望界面能漂亮一些，你需要告诉客户他的期望将是一件可以做的事情，而不仅仅是一个主观愿望。

还有不同主角的目标可能会相互重叠，呈现出一种交集的状态。你要小心求证，是否这些主角所谈的都只是某个完整目标的一部分？如果这样，应当合并成一个用例，并假定这两个主角在这个用例中只是担任业务工人的角色。或者这些主角所谈的是有交叉的部分，单的确是两个不同的目标，如果这样就用两个用例。至于交集的部分，需要在概念模型中去提取公共的业务单元。总之你应当保证：

1. 一个明确的有效地目标才是一个用例的来源。
2. 一个真实的目标应当完备地表达主角的期望。
3. 一个有效地目标应当在系统边界内，有主角发动，并具有明确的后果。

经常地，头一两次的访谈可能没有那么顺利。基于客户不熟悉这种访谈形式以及需求采集人员不熟悉客户业务的原因，开始时采集到的信息可能并不足以得出用例。或者已经获得了用例，在这些用例来建立业务模型的时候总会遇到矛盾和困难，发现有些业务总是说不清楚，那么应当考虑从新进行访谈，应该考虑一下策略：

1. 调整系统边界和主角
2. 扩大和缩小系统边界。
3. 变更主角
4. 然后，重新开始

经过几次调整之后，系统边界内应该已经充满了主角的愿望，将每一个有效地期望用用例绘制出来，并给一个合适的名字就完成了用例的获取工作。

下面是一个ATM取钱的示例：

客户代表（主角）说： 我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是还钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以缴纳水费、电费、电话费等；为了安全起见，ATM上应当有警示小心骗子的提示条，还有摄像头；如果输入3次密码错误，卡片应当被自动吞没。

假设我们现在是ATM设备的软件提供商，你们我们应该如何识别客户的真实目标呢？

首先来判断以下哪些是用例？

支持跨行业务？

插入卡片？

输入密码？

选择服务？

取钱？

存钱？

挂失卡片？

缴纳费用？

警示骗子？

3次输入密码错误吞没卡片？

参考答案：

支持跨行业务？	X	错，这是一个业务规则，限定业务的范围。
插入卡片？	X	错，这是一个过程步骤，不是完整目标。
输入密码？	X	错，这是一个过程步骤，不是完整目标。
选择服务？	X	错，这是一个过程步骤，不是完整目标。
取钱？	√	对，这是一个有效地完整的目标。
存钱？	√	对，这是一个有效地完整的目标。
挂失卡片？	√	对，这是一个有效地完整的目标。
缴纳费用？	√	对，这是一个有效地完整的目标。
警示骗子？	X	错，已经超出了边界范围。
3次输入密码错误吞没卡片？	X	错，这是一个业务规则，限定业务的条件。