假设我正在建模一个涉及两个参与者之间对话或者交流的过程。对于此示例，我将使用一些易于理解的内容：

• 供应商创建价目表，
• 买方选择要购买的一些物品并发送采购订单，
• 供应商收到采购订单并发送货物。
• 供应商发送发票
• 买方收到发票并付款

当然，这些步骤中的每个步骤本身都可能很快变得很复杂。我们将如何在需求文档中将其分解为用例？

如果将此过程视为一个单独的用例，则可以填满一本书。

或者，在上述每个步骤中使用一个案例，将隐藏一些应捕获的基本交互和流程。有一个用例始于"已收到采购订单"，以"发送发票"结束，然后另一个以"收据"开始，并终止于"付款"的用例是否有意义？

有什么建议吗？

解决方案

是的，这里有很多可能性。在上面的示例中，如果买方多次支付部分费用来支付帐单，则情况可能更加复杂。

我们可能需要创建完整的工作流用例。将上述每个步骤拆分为各自的用例可能并不有用，因为其中一些步骤将具有前后条件。

我正在研究QuickBooks源代码，并且事务可以流经系统的方式之多令人生畏。对于我们的质量检查人员来说，几乎不可能测试每种组合。

我通常处理此类任务的方式是开始为流程创建UML用例和高级活动图。不要为细节而烦恼，只需尽力而为即可。

有了草稿后，我们几乎会立即从中看到如何进行改进。然后，我们可以继续对其进行重构，以缩小用例，构造大型的Activity等。或者，如果它们太小，则可以将几个用例放在一起。

在不知道项目细节的情况下，我将继续进行并将每个步骤设为一个单独的用例，它们似乎都是独立的，可以在没有任何交叉引用的情况下进行描述。如果这样做，我们会发现任何依赖关系，那么我们总是可以重新考虑该方法。

还可以考虑对日志记录，安全性等常见元素使用" extend"和" include"块。