在UML中创建图表的顺序应该是什么？

Question

我们知道UML包含13种类型的图表（结构和行为）

在开始软件开发之前，我们处于需求和设计阶段，因此应该创建哪个图表以及何时？在需求和设计阶段，UML中的图表创建顺序应该是什么？

事实上，如果没有严格的序列，那么首先我们需要严格地创建结构图，但像Activity这样的行为可能会根据用户体验而改变？

我们是否可以仅将部署图和组件图创建为一个？

Answer 1

关于这些图表的顺序，绝对没有规则。

有时，当数据的结构和域模型的行为很容易定义或记录良好时，创建类图首先允许更清晰的抽象，这有助于创建有意义的序列图。

在其他情况下，当域模型的性质未知或不清楚时，首先创建序列图更有意义，然后从中收集类。

我确信这些图的修订将彼此同时发生（例如，序列图可能会揭示在类图中未考虑的内容，反之亦然）。

同样，在开始软件开发之后，这些图表可能会再次发生变化，因为更直观或更易于维护的抽象和设计可以通过单元测试或用户体验测试等方式展示自己。

永远不要迷恋这些图表在任何方面都是僵化的想法，因此需要创造一个序列 - 相信我，他们不会。如果你把它们视为僵硬和绝对正确的话，你就会在自己的脚下拍摄并在你的软件开发工作中将一只手臂绑在身后。

更新正如评论中所反映的那样，如果您真的迷失了首先使用的图表，那么用例图在需求收集阶段就非常重要。

除此之外，我上面写的内容适用。

Answer 2

我同意Jon和Pete的意见，但是请注意，UML是什么以及如何变化。 有像OOA和OOD（OOAD）这样的过程描述了UML的方法和内容。维基文章很有帮助，但它更像是这样。开发的许多RUP流程也涉及UML的方法。

用户参与项目的一组标准订单（再次使用您需要的订单）： 1.用例（专注于用户/系统交互。 2.钻入用例的活动/序列。 3.如果要连接系统，请参见组件/接口图。 4.如果您正在进行大型OO构建，则打包/类。 5.部署以显示基础架构中的位置。

上面列出的模型/图表元素没什么神奇之处，但这似乎是常见的集合。

Answer 3

  

事实上，如果没有严格的序列，那么首先我们需要严格地创建结构图，但像Activity这样的行为可能会根据用户体验而改变吗？

表单遵循功能。如果您需要更改行为，则很有可能需要更改出现该行为的结构。

Answer 4

用例分析是从需求中捕获目标的有效方法。使用用例描述来标识域对象并生成域模型。我觉得CRC在这个阶段很有用，即使它不是官方的UML。一旦我生成了我的域模型，我就为每个用例生成一个Sequence Diagram。虽然活动图也是一种有用的替代方案。我将Domain模型解析为更详细的类模型。在此阶段，可以直接生成部署模型。