目標： 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在細化階段創建，這有利于識別系統事件的細節以便明確系統必須被設計和處理的操作，有利于編寫系統操作契約，并且可能有利于對估算的支持。