系统序列图是分析或设计的一部分吗？

Question

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

Answer 1

System Sequence Diagram (SSD)是UML sequence diagram的一种特殊类型，它打算针对一个特定用例记录所考虑的系统与外部参与者之间的交换顺序。

它不是标准的UML图，而是建立在这些图的基础上。 《不断变化的世界中的系统分析和设计》一书似乎已经普及了这种方法，但是我可以找到追溯到2000年初的文章（例如this或this）。

上述书籍将SSD置于分析活动中。原因是analysis是关于理解需求的，通常是从用例开始的。然后，SSD可以微调此分析。

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

因此答案取决于您使用模型的目的。

我个人的观点是，除非您对现有应用程序进行了反向工程，或者您的客户有非常详细的要求，否则您应该已经在设计解决方案，因此应该是设计性的 < / p>

Answer 2

对克里斯托弗的答案进行一些阐述：

我还要补充说，分析和 design 是两个高度相互联系的活动，因此您可能会在两种情况下都看到这些固态硬盘，这是完全可以接受的。用例（涉及系统的用例）一定是设计人工制品（它们是系统相对于外部参与者的作法的设计），尽管您当然可以将同一情况视为纯< em>分析输出（告诉您需要要做的事情）。这些东西很难分开。这一点似乎是哲学性的（有点），但是用这些术语来思考很有用。

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