UML中的图表创建顺序应该是什么?[关闭]

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

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

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

我敢肯定的是,这些图表的修订将彼此同时进行(例如,序列图可能会显示类图中未考虑的内容,反之亦然)。

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

永远不要沉迷于这样的想法:这些图表在任何方面都是僵化的,因此在创建过程中需要一个序列——相信我,它们不会是僵化的。如果你把它们当作死板的和无可指摘的东西来对待,那么你就是在用脚射自己,然后在你的软件开发工作中把一只手臂绑在身后。

更新 正如注释中所反映的那样,如果您真的对首先使用什么图感到迷茫,那么用例图在需求收集阶段就非常重要。

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

我同意乔恩和皮特的观点,但恭敬地补充说,UML是变化的内容和方式。 有一些过程像OOA和OOAD(OOAD)描述了UML的方式和内容。维基文章很有用,但它的工作方式更像这样。许多开发的RUP过程也涉及到UML的方法。

用户参与的项目的标准订单集(再次使用您需要的内容): 1.用例(关注用户/系统交互。 2.第2条。钻取用例的活动/序列。 三。组件/接口图(如果您正在连接系统)。 4。如果您正在进行大型OO构建,则打包/类。 5。部署以显示基础结构中的位置。

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

事实上,如果没有严格的顺序,那么首先我们需要严格地创建结构图,但是活动图之类的行为可能会根据用户体验而改变?

形式跟随功能。如果你需要改变行为,很有可能你需要改变行为出现的结构。

用例分析是从需求中获取目标的有效方法。使用用例描述来标识域对象并生成域模型。我发现CRC在这个阶段很有用,即使它不是官方的UML。一旦我生成了我的域模型,我就为每个用例生成一个序列图。尽管活动图也是一种有用的选择。我将域模型解析为更详细的类模型。在这个阶段,很容易生成部署模型。