当你记录一个系统的不同部分以及这些部分之间相互作用的各种方式时，时序图/序列图( sequence diagram)才会真正发挥其作用。
时序图/序列图描述了系统内的操作，并映射出消息的发送内容和时间。
在其最简单的形式中，序列图可以模拟用户和银行之间的信息和流程，因为他们登录到银行应用程序。在更复杂的形式中，序列图可以包括备选方案、选项和循环，以模拟有条件的和不同的流程，例如，如果一个登录过程还包括安全、验证和其他用户操作。
如果你没有广泛地使用它们，你可能已经在两种情况下听说过它们：其一，孤立的，作为一种有用的图表类型，在编写文档时考虑；其二，作为20世纪90年代末的统一建模语言（UML）的一个工件，现在已经很少使用了。
在这篇文章中，我将简要地挖掘UML的历史，这样我们就可以看到，尽管UML的大部分内容都被丢进了软件历史的垃圾堆，但序列图是如何以及为什么会幸存下来的。然后，我将展示为什么序列图仍然有价值，以及你如何能够最好地利用它们。
UML的兴衰
UML最初于1997年问世，正如Martin Fowler在前几年所写的那样，其主要目的是 "消除在面向对象的世界中笼罩着图形建模语言的混乱局面。"基本的问题--在软件的历史上多次重复的问题--是存在混乱和混淆，并真正希望引入一个能提供清晰的标准。
Rational软件公司在1994年开始开发UML；对象管理小组（OMG）在1997年接受它为标准；国际标准化组织（ISO）在2005年将它作为一个公认的标准。
在此后的几年里，人们抱怨：UML变得太复杂了（例如，UML 2.2的文档有1000多页，UML变得与繁重的、经常是浪费的前期工作相关。)
我们可以把序列图的生存能力追溯到UML的起源。在UML的全盛时期，Martin Fowler确定了UML的三个用例：草图、蓝图和编程。
根据Hillell Wayne的说法，编程用例已经死亡，因为 "即使是UML的大多数支持者也认为这是一个糟糕的想法"。
蓝图用例实际上是最强大的用例，但也消亡了，因为该用例与Rational Software和CASE工具联系在一起--这两个工具都消亡了，也带走了UML。
第一个用例--草图--幸存了下来，但它 "漂移到了多种互不理解的方言中"，事后看来，UML在2000年达到了它的顶峰，"作为一种软件草图的媒介"。
序列图从灰烬中走出来
序列图之所以能够存活下来，不仅仅是因为它们是一群人中的佼佼者，而且还因为它们真的很有用。正如我在上面写的，序列图图的要点是你可以用它们来轻松地映射和可视化整个系统的动态消息流。
消息流可以变得非常复杂，但序列图提供了两个主要的组成部分，创建了图表的骨干：
- 生命线，代表对象和它们之间的过程。
- 消息，表示随着时间的推移所交换的信息。
基础组件必须是简单的，因为序列图图是为了表示一个正在运行的系统，这意味着所表示的组件将同时、按顺序、平行地运行。一个好的序列图显示了流程、对象之间交换的信息以及在生命线 "死亡 "之前执行的功能。
序列图图的主要用例是：
- 在建立一个系统之前，勾画和设计该系统的工作方式。
- 记录一个新系统的需求。
- 分解和理解一个现有的（通常是遗留的）系统。
序列图图不能（也不应该）捕获整个系统，所以在这些用例中，最好的方法是用它们来可视化系统的使用，描绘特定过程的逻辑流程，或绘制出服务的功能。
当你记录一个系统的不同部分以及这些部分之间相互作用的各种方式时，序列图图才会真正发挥其作用。当你试图，例如，在一个特定的系统中对一个算法进行建模时，序列图图就不那么好用了。如果你变得太细化和太详细，序列图图就会变得太麻烦而不值得。但是，当你用它们来绘制不同的 "黑盒子"，并显示它们是如何相互对话的，它们就会非常有用。
但是，像其他图表一样，序列图的成功与你的制作水平成正比。然而，它们的质量并不取决于纯粹的努力，而是需要一个仔细、周到的方法，基于从核心流程开始，向外扩展到边缘案例。
从快乐的道路开始，努力解决边缘问题
当您坐下来创建序列图时，可能很想从边缘案例开始，因为边缘案例通常是最复杂且最需要澄清的。
通常，边缘案例的可能性（如果您正在创建一个序列图来支持架构设计）或一个已经存在的、已经很麻烦的边缘案例（如果您正在创建一个序列图以更好地理解遗留软件）激发了创建序列设计。但是，即使您的主要目标是澄清那些边缘情况，如果您首先从快乐路径开始，您也会创建一个更好的序列图。
当你开始时，确定快乐的路径——消息从头到尾的理想方式。绘制此核心序列后，您可以向外处理其他路由和更不频繁的消息流。
例如，使用银行应用程序登录示例，最好从愉快的路径开始——客户请求访问权限，银行授予该访问权限。从这个核心流程开始，确保在您思考和记录不同的流程和边缘案例时，快乐的道路仍然是您的锚点。
从那里，您可以将更多的复杂性分层到快乐的道路上。
从快乐路径开始提供清晰度，确保当您转向边缘情况时，您知道序列应该如何运行并且知道为什么用户可能会遇到边缘情况。从快乐路径中构建和退出也是避免最终图表过于复杂的最佳方法。
可理解性 > 全面性
序列图最常见的故障模式是过于复杂。
此处最好提及的人物之一是 Martin Fowler，他（大约 20 年前）写道，绘制图表的主要价值在于交流。“有效的沟通，”
UML 本身的消亡部分是因为它增加了复杂性而不是提供了清晰性。今天记住这一点很有用，因为——就像 UML 消亡一样——如果任何给定的序列图变得过于复杂，它也会失败。
大图 > 详情
如果前一个问题是过于全面和过于宽泛的结果，那么下一个问题就是过于详细和过于狭窄的结果。
在 Alex Bell 关于 UML Fever 的文章中，他描述的众多“问题”之一是“Gnat's eyebrow fever”，它是最有可能影响序列图的问题之一。他将这种狂热描述为“创建极其详细的 UML 图的强烈愿望”，并认为这是源于这样一种信念，即绘制精细的细节图“增加了生成的代码更正确的可能性”。
例如，如果您正在构建序列图来传达文档中的流程，那么可视化大图对读者来说比深入挖掘细节更有用。并不是说细节不重要，而是太多的细节会削弱看大图序列的能力
同样的原则适用于分析和记录遗留代码——细节在代码本身中，因此序列图只有在您使用它来可视化大图时才有用。
使用时序图拥抱架构思维
这篇文章的重点并不是出于对历史的好奇而去看顺序图。序列图不仅是UML的产物，而且是强调严格设计和规划的软件设计思想的产物。
Fowler解释说，图表和 "重量级 "流程之间的联系是图表制作不力的结果--而不是图表制作本身的结果。本文的建议是为了帮助你创建更好的序列图，但在这个过程中，希望能帮助你更好地看到在你的设计和文档库中拥有图表技能所带来的可能性。
最好的工作来自于设计和编码之间的循环--创建一个前期设计，根据设计进行编码，并将你从编码工作中学到的东西反馈给设计。