Uml 应该先画哪一个，类图还是序列图？

我和我的大学教授讨论过UML图。 他认为在绘制类图之前应该先绘制序列图，但我认为恰恰相反。我认为在完成用例图之后，下一个图应该是类图，然后我们应该进入序列图。 RationalRose要求我们使用序列图中的类，它们已经在类图中了

---

有人能帮我吗？

我想你们都错了。它们应该同时绘制。在绘制序列图时，毫无疑问，您将获得跟踪状态所需的属性，或者如果在真空中绘制类图，您没有想到的属性

---

当然，这是非常主观和个人化的，但多年的实际经验（与学术理论相反）教会了我同时处理这两个问题。可能从类图开始，但当您开始处理流程流时，类图总是会发生变化。

这在很大程度上取决于您计划如何做事情。我认为这是一个主观问题。如果你更愿意解释为你的用例执行的操作，并且在完成之后，根据你需要执行的序列编写课程，你的教授是对的

但是，如果您更愿意确定类的结构，然后调整动作序列以适应它，那么您可以先做类图，然后再做序列

---

以我的经验，我同时做这些事。我将基本属性放在类图中，但不放在动作中，在做序列图的同时，我将需要的方法和属性添加到类图中

我认为创建图表没有顺序，因为它们都是系统的两个不同视图：类图结构（静态）和顺序行为（动态）。我将从序列图开始，因为在遍历序列时，您将发现更多要创建的类。做任何当时对你有意义的事。如果你做更多的面向对象编程，我会考虑在排序之前做类。

< P>没有一个标准答案。有几种观点、方法和途径。在统一过程中，我相信您首先确定用例，然后对它们进行实现，例如序列图。在用例中，有参与者和系统和/或其部分在序列中交互。实际上，这种交互应该可以帮助您分解设计并进入类。一旦在分析级别上有了类，就可以进一步进行无类设计和设计交互。然而，在一个图中绘制这些内容非常多，大多数情况下，代码是这个级别上最好的文档，即使生成的图太大，比代码本身更难理解。

除了最简单的系统之外，所有系统的结构和行为模型都是自然地同时迭代创建的，随着时间的推移，两者都在不断完善

您可能有一些“对象发现”方法，例如CRC卡，它将生成一组初始类，带有协作（它们与之交互的类）和责任，通知它们将需要的方法和内部行为/状态/活动

然后，您可能希望使用序列图或通信图来探索用例和场景，这将公开所需对象通信的细节，从而通知生成公共方法和关系，以优化类图，同时探索可能产生更多对象和类的系统行为

您可能还想探索类的内部行为，特别是当它们有状态和/或活动行为时；活动和状态机图对此很有用

---

不管怎样，我怀疑RationalRose的使用是否真的是图表创建顺序的决定因素。Rational可能要求序列图上的类存在，但我认为它们实际上不需要出现在类图上；它们可能同样可以在序列图上创建，然后放在类图上，甚至可以在ProjectExplorer或该工具中的任何等效工具中创建。即使创建类的唯一方法是将其放在类图上，也不需要在探索序列图上的交互之前优化和完成类或其关系。

您需要购买一些衣服，如何继续。你先选择衣服，还是先决定去哪里？同时，如果你想买衬衫，你会去鞋店吗

---

所以两者都是迭代的，但第一步肯定是非常高（组件）级别的序列，然后深入到类级别的序列

要准备序列图，您需要的是类，而不是类图 您可以在准备序列图的过程中动态地准备空类。。。。 标识类对象是准备序列的一部分，或者您可以尝试在准备之前标识您的对象。。。。

---

序列是逻辑过程，而类图是最终输出

您应该首先确定应用程序流程，这意味着您应该首先绘制序列图。它将显示应用程序的流程，在此之后，您应该使用类图。

序列图描述对象/组件如何相互通信以执行流程。这可能会对班级成员产生一些影响。就个人而言，我同意你的教授，但我有兴趣在这里看到答案…+1。它们同时进化，相互通知，相互验证。首先做类图，您将错过行为建模将突出显示的结构（关系、类、属性）。首先做行为，你会错过结构元素。谢谢david，看来你的程序是基于