Uml 系统顺序图是分析还是设计的一部分？

我想知道系统序列图（SSD）是属于设计部分还是分析部分？

是一种特殊类型的，旨在记录一个特定用例中所考虑的系统和外部参与者之间的交换顺序

它不是一个标准的UML图，而是基于这样的图构建的。《变化世界中的系统分析和设计》一书似乎推广了这种方法，但我可以找到2000年初的文章（比如或）

上述书将SSD置于分析活动中。原因在于，这是关于理解需求的，通常从用例开始。然后，SSD将对此分析进行微调

然而，有人可能会说这是设计活动的一部分，因为用例就是需求，但是如何通过一系列交换来满足这些需求已经是解决方案的开始，就像您开始绘制UI时一样：多个SSD可以满足需求，您可以选择

所以答案取决于你使用模型的目的

我个人的观点是，你已经在起草一个解决方案，所以它应该是设计，除非你对现有的应用程序进行逆向工程，或者您的客户有非常详细的要求

A是一种特殊类型的，旨在为一个特定用例记录所考虑的系统与外部参与者之间的交换顺序

它不是一个标准的UML图，而是基于这样的图构建的。《变化世界中的系统分析和设计》一书似乎推广了这种方法，但我可以找到2000年初的文章（比如或）

上述书将SSD置于分析活动中。原因在于，这是关于理解需求的，通常从用例开始。然后，SSD将对此分析进行微调

然而，有人可能会说这是设计活动的一部分，因为用例就是需求，但是如何通过一系列交换来满足这些需求已经是解决方案的开始，就像您开始绘制UI时一样：多个SSD可以满足需求，您可以选择

所以答案取决于你使用模型的目的

---

我个人的观点是，您已经在起草解决方案，因此应该是设计，除非您对现有应用程序进行反向工程，或者您的客户对Christophe的答案有非常详细的要求：

我要补充的是，分析和设计是两个高度交织的活动，因此您可能会在这两种情况下看到这些SSD，这将是完美和可接受的。用例，那些涉及系统的用例，必然是一个设计人工制品（它们是系统相对于外部参与者所做的设计），尽管您当然可以将其视为纯粹的分析输出（告诉您系统需要做什么）。这些东西很难分开。这一点似乎很有哲理（有些道理），但用这些术语来思考是有益的

---

当你看到人们创建“登录”用例时，你可以打赌他们已经进入了纯设计阶段，换句话说：功能分解。在分析术语中，用户登录的状态是对用例的约束，而不是用例本身。因此，有一个名为Login的用例仅代表一个设计选择（顺便说一下，如果你在执行分析和设计的人之间有责任分工的情况下看到这一点，那么你最好考虑分析失败：分析员本质上是设计系统，而不是他们的角色）。分析师有时使用用例来建模只与业务流程相关的需求层，通常称为“业务用例”，不涉及任何系统本身。但是20多年前的用例起源于系统空间。

详细阐述了Christophe的答案：

我要补充的是，分析和设计是两个高度交织的活动，因此您可能会在这两种情况下看到这些SSD，这将是完美和可接受的。用例，那些涉及系统的用例，必然是一个设计人工制品（它们是系统相对于外部参与者所做的设计），尽管您当然可以将其视为纯粹的分析输出（告诉您系统需要做什么）。这些东西很难分开。这一点似乎很有哲理（有些道理），但用这些术语来思考是有益的

---

当你看到人们创建“登录”用例时，你可以打赌他们已经进入了纯设计阶段，换句话说：功能分解。在分析术语中，用户登录的状态是对用例的约束，而不是用例本身。因此，有一个名为Login的用例仅代表一个设计选择（顺便说一下，如果你在执行分析和设计的人之间有责任分工的情况下看到这一点，那么你最好考虑分析失败：分析员本质上是设计系统，而不是他们的角色）。分析师有时使用用例来建模只与业务流程相关的需求层，通常称为“业务用例”，不涉及任何系统本身。但是20多年前的用例起源于系统空间。

根据哪种方法或标准？UML本身并没有定义术语分析和设计。面向对象的软件开发面向对象只是关于编程，而不是关于分析或设计。你在哪里找到“系统序列图”这个术语？你能详细说明一下你的想法吗