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