系统顺序图
系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输出事件而夸苏、简单地创建的制品。它们是操作锲约和对象设计的输入。
用力文本及其所示的系统事件是创建SSD的输入。SSD中的操作可以在操作锲约中进行分析，在词汇表中被详细描述，并且（最重要的是）作为设计协作对象的起点。
示例：NextGen SSD
对于用例中的一系列特定事件，SSD展示了直接与系统交互的外部参与者、系统以及由参与者发起的系统事件。在途中，时间顺序是自上而下的，并且事件的顺序应该遵循其在常见中的顺序。
什么时系统顺序图
用例描述外部参与者是如何与我们所希望创建的系统进行交互的。在交互中，参与者对系统发起系统事件，通常需要某些系统操作对这些事件加以处理。该事件引发了系统之上的操作。用例文本暗示了事件，而SSD将其变得具体和明确。
UML 包含了顺序图作为表示法，一边能够阐述参与者的教育及参与者引发的操作。
系统顺序图表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之内的事件。所有系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。
应为每个用例的主成功场景，以及频繁发生的或者复杂的替代场景绘制SSD。
动机：为什么绘制SSD
软件设计中一个有趣而且有用的问题是：我们的系统中会发生什么事件？为什么？因为我们必须为处理和响应这些事件来设计软件。基本上，软件系统要对以下三种事件进行响应：
- 来自于参与者的外部事件。
- 时间事件。
- 错误或异常。 因此，需要准确地指导，什么是外部输入事件，及系统事件。这些事件是系统行为分析的主要部分。
你可能对如何识别进入软件对象的消息非常熟悉。而这种概念同样适用于更高阶的构件，包括把整个系统视为一个事物或对象。
在对软件应用将如何工作进行详细设计之前，最好将其行为作为“黑盒”来调查和定义。系统行为描述的是系统做什么，而不许解释如何做。这种描述的一部分就是系统顺序图。
其他部分包括用例和系统操作锲约。
应用UML：顺序图
UML没有定义所谓的“系统”顺序图，而只是定义了“顺序图”。这一限定强调将系统的应用视为黑盒。之后，我们会在另一个语境下使用顺序图，阐述完成工作的交互软件对象的设计。
SSD和用例之间的关系
SSD展示了用例中一个场景的系统事件，因此它是从对用例的考察中产生的。
如何为系统事件和操作明明
系统事件应该在意图的抽象级别而非物理的输入设备级别来表达。
系统事件的名称以动词开始，可以提交清晰程度，因为这样可以强调这些事件是命令或请求。
如何为涉及其他外部系统的SSD建模
SSD也同样可以用来阐述系统之间的协作。
SSD的哪些信息要放入词汇表中
SSD中所示的元素（操作名称、参数、返回的数据）是简洁的。需要对这些元素加以适当的揭示一边在设计时能够明确地直达输入了什么，输出流什么。词汇表示强袭描述这些元素的最佳选择。
对大多数制品来说，一般在词汇表中描述其细节。
示例：Monopoly SSD
过程：迭代和进化式SSD
不用为所有场景创建SSD，出发你在使用需要识别所有系统操作的预算技术。相反，只需为下次迭代所用的场景绘制SSD，同时，不应该花费太长事件来绘制SSD，用几分钟或半小时来绘制即可。
当需要了解现有系统的接口和协作时，或者将其架构记录在文档中时，SSD也是十分有效的。
UP 中的SSD
SSD 时用例模型的一部分，将用例场景隐含的交互可视化。经过UP的创建者们意识到并理解这些图的用途，但自处的UP描述中并没有直接提到SSD。由大量可能有用和广泛使用的分析和设计制品或活动并没有在UP或RUP文档中提及，SSD就是其中之一。但是UP十分灵活，提倡引入任何能够增加价值的制品和实践。
UP 阶段
- 初始：通常不会在该阶段引入SSD，出发你要对涉及的技术进行粗略的估算，这种估算的基础时对系统操作的识别，例如功能的或COCOMO2.
- 细化：大部分SSD在细化阶段创建，这有利于识别系统事件的细节以便明确系统必须被涉及和处理的操作，有利于编写系统操作契约，并且可能有利于对估算的支持。