为什么要费心识别用例，而不直接跳转到流程中去呢？
无论是记录业务流程还是系统流程，用例和流程都可以成为有价值的工具。
用例描述以文本方式描述了流程的主要成功方案以及主要的备选方案和异常方案。流程图以图形的形式做同样的事情。流程图记录主要成功方案的逐步活动，决策点（通常显示为菱形）显示主方案分支到替代方案中的位置。
正如用例可以“包括”其他用例（要么降低复杂性，要么显示对更小功能块的重用），流程流可以通过记录子流程并将折叠的子流程显示为流程流中的单个活动来显示类似的分解。
那么，为什么还要费心创建用例模型呢？
首先，用例模型通过应用某些准则来标识用例。其中一个指导原则是用例应描述为业务人员或系统用户提供价值的流程。它明确关注业务人员或系统用户。
除了强调参与者之外，用例模型还为用例的细分创建了一个高级框架。更高级别的用例可以分解成较低级别的用例。同样，这通常是为了减少复杂性或显示某些流程的重用。这种分解可以继续下去，直到进一步分解它们不再增加价值。
考虑一下分析师，他开始按照业务提到的顺序识别流程，目的是生成流程流。每个流程的大小和范围肯定会有所不同，而且对于如何将每个流程组合在一起也没有明确的组织。确定一个流程应该结束，而另一个流程应该开始变得困难。然而，更重要的是，这会导致自下而上的方法，这使得检测不同流程之间的共性更加困难。
总之，用例模型将重点放在业务或系统的客户端上，同时提供所有关键流程的结构化视图以及它们如何相互关联，就像路线图一样。
流程是动态，用例图是划分边界上下文。