每个用例的序列图是用UML表示的，还是我们通常为系统绘制的？

我和我的朋友讨论了我们的项目，我们正在以某种方式绘制序列图（UML2）。 他告诉我序列图是由用例绘制的。这意味着对于每个用例，我们应该绘制一个序列图。 对吗？

---

谢谢你的建议。

好吧，作为教条，这是不正确的。序列图（SD）显示了对象在交换消息时的行为（如果需要，还包括它们的生存期和一些次要的附加信息）。您“还可以”使用序列图来描述用例中的场景。但简单地说，SD更面向技术（类设计/程序员），而不是业务（业务设计/涉众）。为了可视化用例场景，最好使用活动图（AD）。如果你深入BPMN（它将广告带到了一个新的水平），那就更好了

但是，可以将广告转换为SDs，反之亦然，而不会丢失信息（如果您忘记了上述内容）

---

现在还有一点：对于每个用例，您不一定需要一个图表。我发现用例通常更容易（甚至更清楚）用文本的方式描述（参见Cockburn或Bittner/Spence），而不是用图表。特别是如果你有UC场景，它们的单个动作非常线性。因此，你可以省去这些广告，只需回到简单的文字。您应该进一步避免以两种方式（即文本和图表）描述UC场景，因为这会引入不必要的冗余（意味着您需要在发生更改时始终保持这两种方式；而且更改经常发生；人们都很懒惰->那么，哪一种情况是正确的：文本还是图表？）。

通常，正如Thomas指出的，用例细节在活动图中列出。正如他还提到的，用例场景将在必要时使用序列图。用例场景是通过用例的单一路径

序列图不擅长绘制多个同时的行为和多个决策点，用例通常在其行为中同时具有这两个特性。活动图可以很好地完成这些事情。根据定义，通过用例的单一路径没有同时的行为和决策点，因此序列图更合适

---

谷歌搜索“用例场景序列图”提供了大量链接，详细解释了用例场景序列图的使用，例如。

用例是系统与系统参与者协作（交互）执行的系统行为（服务或有用行为）声明。 UML中定义的任何类型的图都可以用来描述任何抽象级别上的行为。所有的图表也可以用来描述系统的业务或技术方面。 用例是行为的声明，它意味着用例根本不定义行为。UML不定义用例的场景，场景通常是在方法论中定义的，而不是在UML中定义的。 若你们需要在用例的上下文中描述系统的行为，你们可以使用UML中为每个用例定义的一些行为图