There's absoultely no rule regarding the sequence of such diagrams.
Sometimes, when the structure of the data and the behavior of your domain model is easily defined or well documented, creating the class diagrams first allow for clearer abstractions that aid in creating a sequence diagram that makes sense.
In other cases, when the nature of the domain model is unknown or unclear, it will make more sense to create a sequence diagram first, and then glean classes from that.
What I am sure of is that revisions of these diagrams will become concurrent with each other (e.g., sequence diagrams may reveal something that wasn't taken into account for in the class diagrams, and vice versa).
Likewise, after starting software development these diagrams may change yet again, as more intuitive, or more maintainable abstractions and designs reveal themselves whether via unit tests or user-experience testing and so on and so forth.
Never get enamoured with the idea that these diagrams are rigid in any way and thus requires a sequence in creation -- trust me, they won't be. If you treat them as rigid and infallible, you're shooting yourself in the foot AND tying one arm behind you in your software development effort.
UPDATE As reflected in the comments, if you're really lost as to what diagram to go first with, the Use Case Diagram would be very important as early as the requirements gathering phase.
I agree with Jon and Pete, but respectfully add that UML is the what and the how varies. There are processes like OOA and OOD (OOAD) which describe the how and what is UML. The wiki articles helpful, but it works more like this. Many RUP processes developed also involve the how of UML.
A standard set of orders for a user involved project (again use what you need): 1. Use Case (Focused on User/System Interaction. 2. Activity/Sequence that drills into the Use Cases. 3. Component/Interface diagram if you are connecting systems. 4. Package/Class if you are doing a large OO build. 5. Deployment to show what goes where in the infrastructure.
Nothing magical about the model/diagram elements I listed above but this seems to be the common set.
In fact if there is no rigid sequence then first we need to create structural diagram rigidly but the behaviour like Activity diagram may change according to user experience?
Form follows function. If you need to change the behaviour, there's a good chance you need to change the structure from which that behaviour emerges.
Usecase analysis is an effective way to capture the goals from the requirements. Use the usecase descriptions to identify your domain objects and produce a domain model. I find CRC useful at this stage even though it not official UML. Once I have produced my domain model I produce a Sequence Diagram for each usecase. Though Activity diagrams are also a useful alternative. I resolved the Domain model into a more detail class model. At this stage it is straightforward to produce a deployment model.
发布评论
评论（4）
关于这些图的顺序绝对没有规则。
有时，当数据结构和域模型的行为很容易定义或有详细记录时，首先创建类图可以实现更清晰的抽象，这有助于创建有意义的序列图。
在其他情况下，当领域模型的性质未知或不清楚时，首先创建序列图，然后从中收集类会更有意义。
我确信的是，这些图的修订将彼此并发（例如，序列图可能会揭示类图中未考虑到的某些内容，反之亦然）。
同样，在开始软件开发之后，这些图表可能会再次发生变化，因为无论是通过单元测试还是用户体验测试等，更直观或更可维护的抽象和设计都会显现出来。
永远不要迷恋这些图表在任何方面都是僵化的，因此需要按顺序创建的想法——相信我，它们不会的。如果您将它们视为僵化且绝对正确的，那么您就是搬起石头砸自己的脚，并在软件开发工作中把一只手臂绑在了身后。
更新 正如评论中所反映的，如果您真的不知道首先使用哪个图，那么早在需求收集阶段用例图就非常重要。
除此之外，我上面写的内容也适用。
There's absoultely no rule regarding the sequence of such diagrams.
Sometimes, when the structure of the data and the behavior of your domain model is easily defined or well documented, creating the class diagrams first allow for clearer abstractions that aid in creating a sequence diagram that makes sense.
In other cases, when the nature of the domain model is unknown or unclear, it will make more sense to create a sequence diagram first, and then glean classes from that.
What I am sure of is that revisions of these diagrams will become concurrent with each other (e.g., sequence diagrams may reveal something that wasn't taken into account for in the class diagrams, and vice versa).
Likewise, after starting software development these diagrams may change yet again, as more intuitive, or more maintainable abstractions and designs reveal themselves whether via unit tests or user-experience testing and so on and so forth.
Never get enamoured with the idea that these diagrams are rigid in any way and thus requires a sequence in creation -- trust me, they won't be. If you treat them as rigid and infallible, you're shooting yourself in the foot AND tying one arm behind you in your software development effort.
UPDATE As reflected in the comments, if you're really lost as to what diagram to go first with, the Use Case Diagram would be very important as early as the requirements gathering phase.
Beyond that, what I wrote above applies.
我同意 Jon 和 Pete 的观点，但恭敬地补充说，UML 是变化的内容和方式。
有像 OOA 和 OOD (OOAD) 这样的过程描述了 UML 的方式和内容。维基文章很有帮助，但它的工作方式更像是这样。许多开发的 RUP 流程也涉及 UML 的方法。
用户涉及的项目的一组标准订单（再次使用您需要的）：
1.用例（专注于用户/系统交互。
2. 深入用例的活动/序列。
3. 组件/接口图（如果要连接系统）。
4. 包/类（如果您正在进行大型面向对象构建）。
5. 部署以显示基础设施中的内容。
我上面列出的模型/图表元素没有什么神奇之处，但这似乎是通用的集合。
I agree with Jon and Pete, but respectfully add that UML is the what and the how varies.
There are processes like OOA and OOD (OOAD) which describe the how and what is UML. The wiki articles helpful, but it works more like this. Many RUP processes developed also involve the how of UML.
A standard set of orders for a user involved project (again use what you need):
1. Use Case (Focused on User/System Interaction.
2. Activity/Sequence that drills into the Use Cases.
3. Component/Interface diagram if you are connecting systems.
4. Package/Class if you are doing a large OO build.
5. Deployment to show what goes where in the infrastructure.
Nothing magical about the model/diagram elements I listed above but this seems to be the common set.
形式服从功能。如果您需要改变行为，那么您很可能需要改变产生该行为的结构。
Form follows function. If you need to change the behaviour, there's a good chance you need to change the structure from which that behaviour emerges.
用例分析是从需求中捕获目标的有效方法。使用用例描述来识别域对象并生成域模型。我发现 CRC 在现阶段很有用，尽管它不是官方的 UML。一旦我生成了域模型，我就会为每个用例生成一个序列图。尽管活动图也是一个有用的替代方案。我将域模型解析为更详细的类模型。在此阶段，可以直接生成部署模型。
Usecase analysis is an effective way to capture the goals from the requirements. Use the usecase descriptions to identify your domain objects and produce a domain model. I find CRC useful at this stage even though it not official UML. Once I have produced my domain model I produce a Sequence Diagram for each usecase. Though Activity diagrams are also a useful alternative. I resolved the Domain model into a more detail class model. At this stage it is straightforward to produce a deployment model.