过去几天我一直在看几个 UML 教程，但我很难理解 UML 序列图。快速浏览并浏览指南，这一切似乎都相当简单，但是当我查看提供的示例时，它很快就会变得令人困惑。
我目前正在尝试为我的 PHP 网站系统准备序列图，该系统具有登录、注册和私人消息传递等功能。这些中的每一个本质上都是用例，这意味着每个都需要自己的序列图，对吗？还是序列图应该在一张图中显示整个系统？我发现的许多示例似乎一口气涵盖了整个系统，尽管功能如此之多，我不知道如何在一张图中完成。
到目前为止，我已经准备了2个简单的登录和注册：
用例 1
用例 2
【问题讨论】：
每个 UML 图都强调系统方面（内容和形式）并抽象出其他方面。您应该学习这一点，以便决定在哪种情况下使用哪个图表，使用多少以及如何使用。系统建模的一个伟大的、创造性的部分。
在时序图的情况下，它是一个行为图，显示具体、直接的场景，强调协作对象和消息他们在场景的实施过程中进行交换。
虽然序列可以显示条件流程和决策（例如在您的示例中，用户和通过检查），但它并不是它的优势，因为它打破了它的自然直线事件时间线。
因此，理论上每个用例都会有多个序列图，每个场景一个。但是，如果每个序列都有意义，你应该好好考虑，因为它们中的大多数都是微不足道的。你应该专注于有意义的、有趣的、能给某人带来价值的场景。
最后，我建议你也看看活动图，因为它很好地补充了序列。也是行为，但侧重于任务序列、决策（序列的弱点）、并行任务、责任和数据流。
从另一个角度来看，一个活动可以涵盖多个序列。这些对于非技术人员（客户、用户）来说更清楚，而对开发人员、架构师等来说，顺序更有用。
大多数情况下，几个图表的组合会产生最好的结果。序列自然需要一个结构化的“伴侣”来定义参与场景的对象：组件、域类或类似的。
【讨论】：
序列图旨在向其他人传达某事的运作方式，因此优先级应该是让它们易于理解。在具有用户交互的系统中，您可以使用序列图来解释复杂的用例。整个系统的图表没有多大意义，因为流程完全取决于用户的操作。为简洁起见，您可以一起描述两个相关的用例，前提是一个用例在哪里结束，另一个从哪里开始，例如注册、登录和注销。如果系统没有用户交互，则可以使用单个序列图来描述其一般工作方式。
【讨论】：