上一次写一点有关领域模型的东西，今天来写点系统顺序图的知识吧。。。
      Ready？GO！
      简介：系统顺序图是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品。它们是操作契约和对象设计的输入。
      顺序图示例：
       

系统顺序图（SSD）：用于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之内的事件。所有系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。
      准则：应为每个用例的主成功场景，以及频繁发生的或者复杂的替代场景绘制SSD
      为什么绘制SSD？
基本上，软件系统要对以下三种事件进行响应：
     1）来自于参与者的外部事件
     2）时间事件或异常
在对软件应用将如何工作进行详细设计之前，最好将其行为作为“黑盒”来调查和定义。系统行为描述的是系统做什么，而无需解释如何做。这种描述的一部分就是系统顺序图。
     SSD和用例的关系
SSD展示了用例中一个场景的系统事件，因此它是从对用例的考察中产生的，如图：

是否应该在SSD中显示用例文本？
通常不这么做。如果你为SSD适当地命名，可以指明对应的用例。例如，处理销售场景
   如何为系统事件和操作命名？
系统事件应该在意图的抽象级别而非物理的输入设备级别来表达
系统事件的名称以动词开始（增加。。。，输入。。。，结束。。。，产生。。。），可以提高清晰程度，因为这样可以强调这些事件是命令或请求
    如何为涉及其他外部系统的SSD建模？
SSD也同样可以用来阐述系统之际间的协作。
   迭代和进化式的SSD
UP中的SSD：SSD 是用例模型的一部分，将用例场景隐含的交互可视化。尽管UP的创建者们意识到并理解这些图的用途，但最初的UP描述中并没有直接提到SSD。
    UP阶段
初始阶段：通常不会在该阶段引入SSD，除非你要对涉及的技术进行粗略的估算，这种估算的基础是对系统操作的识别，例如，功能点或COCOMO2（参见www.ifpug.org）
细化阶段：大部分SSD在细化阶段创建，这有利于识别系统事件的细节以便明确系统必须被处理和理解的操作，有利于编写系统操作契约，并且可能有利于对估算的支持。

   以上就是在《UML和模式设计》书中提到的系统顺序图，以后希望还能和大家分享更多这本书中提到的UML知识。。