UML之发现用例

遵循上述形式获得的用例名称通常是正确的，并且很容易理解。然而有些特殊的用例不适用这种命名的方法。例如，在系统或参与者具备自主能力的场景下，一个机器人系统会自行进入休眠状态，一个时钟会自动计时，此时没有具有传统目标的传统参与者。

用例图简单易懂，几乎不需要经过专业训练就可以阅读和开发，而用例图又是描述需求的手段，故而通常它由需求分析人员与参与者的代表共同开发，或者由需求分析人员开发后，与参与者讨论修改而成。最终形成的用例图还须交给各参与者代表进行审查。参与者代表审查用例图非常有必要且有价值，因为参与者可以明确知道用例图是否包含了他们自己所有的目标，或者是否存在跟他们不相关的目标。也正是基于此，在为用例命名时应当使用参与者的术语，而避免使用IT术语或者实现时的概念，同时力求简单、明确，确保每个人都能理解。

系统开发人员倾向于围绕用例来组织项目，因为这样可以使项目更易于相关各方理解。通常一个项目应当生成需求或设计文档，可以考虑先按参与者再按用例来组织文档结构（如下图所示），同时也可以通过创建相关用例的包来构建包结构。




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