我想知道系统序列图（SSD）是属于设计部分还是分析部分？
【问题讨论】：
标签： uml modeling sequence-diagram ooad
System Sequence Diagram (SSD) 是UML sequence diagram 的一种特殊类型，旨在为一个特定用例记录所考虑的系统与外部参与者之间的交换顺序。
它不是标准的 UML 图，而是建立在这样的图之上。 《变化世界中的系统分析与设计》一书似乎普及了这种方法，但我可以找到可以追溯到 2000 年初的文章（如 this 或 this）。
上述书籍将SSD置于分析活动中。原因是analysis 是关于理解需求，通常从用例开始。 SSD 就是对这种分析的微调。
但是，有人可能会争辩说，这是设计活动的一部分，因为用例就是需求，但是如何通过一系列交换来满足这些需求已经是解决方案design 的开始，正如当您开始绘制 UI 时：多个 SSD 可以满足需求并且您可以选择。
因此，答案取决于您使用该模型的目的。
我自己的观点是你已经在起草一个解决方案，所以它应该是设计的，除非你对现有应用程序进行一些逆向工程，或者你的客户有非常详细的要求
【讨论】：
详细阐述 Christophe 的回答：
我要补充一点，分析和设计是两个高度交织在一起的活动，因此您可能会在这两种情况下看到这些 SSD，而且它完全可以接受。用例，即涉及系统的用例，必然是设计工件（它们是系统与外部参与者相关的的设计），尽管您当然可以将相同的东西视为纯 analysis 输出（告诉您系统需要做什么）。这些东西很难分开。这一点可能看起来很哲学（它有点），但用这些术语来思考是有用的。
当您看到人们创建“登录”用例时，您可以打赌他们已经进入了纯设计，换句话说：功能分解。在分析术语中，用户登录的状态是对用例的约束，而不是用例本身。因此，拥有一个名为 Login 的用例仅代表一种设计选择（顺便说一下，如果您在执行分析和设计的人员之间存在职责分工的情况下看到这一点，那么您最好将其视为分析失败：分析师本质上是在设计系统，这不是他们的职责）。分析师有时使用用例对仅与业务流程相关的需求层进行建模，通常称为“业务用例”，它们本身不涉及任何系统。但 20 多年前的用例起源于系统领域。
【讨论】：