UML之发现用例

用例是最简单的UML元素，用例图是最简单的UML图，但它也可能是UML中最有用的元素之一。尽管我们用包将工作分解为工作包、团队任务或单项任务，也就是说包是组织UML中的各种图及元素的工具。但是用例图可以帮助我们确定任务，以及应当如何将它们分组并确定工作范围。
每个用例都代表用户希望系统帮助实现的一个目的或目标。例如，对于银行ATM机，客户希望使用它来取款、存款、转账或者修改密码等，而银行则希望使用它可以获得存取款明细等。
要使系统具有实用性，它就必须为用户带来价值。例如银行ATM机，对于客户而言，可以省去或节约人工柜台排队等候的时间，对于银行而言可以降低人力资源成本。在用例的术语中，对于所有与系统产生交互的对象我们统称为“参与者（Actor）”。参与者涵盖了所有与系统产生交互的用户，例如客户、工作人员、管理人员、维护人员等。任何可以使用系统（主动或者被动）的人都可以被视为参与者。
对于图书馆系统，参与者包括读者、图书管理员、编目人员、出入库人员等；对于打车APP，参与者包含乘客、司机、管理人员、客服等；对于银行ATM，参与者包含客户、款箱管理员、运维人员等。
此外，与当前系统相关联的其他系统、设备、传感器等都可以视为参与者。
回到用例本身，用例必须为参与者提供价值。许多程序员对“用例为参与者提供价值”感到困惑，经常与函数或子程序返回一个值混淆。所谓提供价值意味着实现了某种期望的结果，它是比函数或子程序返回值更高层次的结果。例如对于银行ATM，“取款”是一个用例，它的价值在于实现了客户获得现金的目标，而为了实现这个目标，银行ATM识别卡片、客户输入密码及ATM判断密码是否正确等只是“取款”这个用例实现的步骤，它们都有返回值，但是这些并非客户的目标，它没有为客户带来价值或让客户受益，因此它们不是用例。
用例是行为模型的一部分。一个业务用例通常描述一个完整的业务，一个系统用例通常描述一个完整的系统功能。一个用例描述一个场景，它也可以表示一组具有相似目标的相关场景。通常使用结构化文本（用例规约）、故事板、序列图、状态机或活动图来详细描述这些场景。
在UML中使用椭圆表示用例，用例的名称写在椭圆内部，如下图所示。用例的名称表示参与者的目标。通常，用例名称应当使用“动宾”结构，例如存款、取款、修改密码等，而这个动宾结构的主语就是对应的参与者，即客户存款、客户取款、客户修改密码等。

关于用例命名，有一个简单实用的技巧，即在参与者目标前加上“系统，请帮我……”或类似的变体。例如：

• 系统，请帮我取款。
• 系统，请帮我修改密码。
• ……

遵循上述形式获得的用例名称通常是正确的，并且很容易理解。然而有些特殊的用例不适用这种命名的方法。例如，在系统或参与者具备自主能力的场景下，一个机器人系统会自行进入休眠状态，一个时钟会自动计时，此时没有具有传统目标的传统参与者。
用例图简单易懂，几乎不需要经过专业训练就可以阅读和开发，而用例图又是描述需求的手段，故而通常它由需求分析人员与参与者的代表共同开发，或者由需求分析人员开发后，与参与者讨论修改而成。最终形成的用例图还须交给各参与者代表进行审查。参与者代表审查用例图非常有必要且有价值，因为参与者可以明确知道用例图是否包含了他们自己所有的目标，或者是否存在跟他们不相关的目标。也正是基于此，在为用例命名时应当使用参与者的术语，而避免使用IT术语或者实现时的概念，同时力求简单、明确，确保每个人都能理解。
系统开发人员倾向于围绕用例来组织项目，因为这样可以使项目更易于相关各方理解。通常一个项目应当生成需求或设计文档，可以考虑先按参与者再按用例来组织文档结构（如下图所示），同时也可以通过创建相关用例的包来构建包结构。

本文简单讨论了用例的概念及如何发现用例，关于用例与参与者更深入的概念与知识，请参阅博客下UML合集中的其他相关文章。