我应该从哪个 UML 图开始？
假设您正在查看 6 种基本类型UML 图（来自 UML 2.0 风格的元素）
- 类图
- 用例图
- 状态机图
- 活动图
- 序列图
- 物理图
假装你疯了，你想为你的系统绘制所有 6 个图。
你会从哪一个开始？那你会去哪个呢？如果您非常清楚了解您希望系统做什么，那么访问每个图表的最佳顺序是什么？
我认为你应该从物理图开始，然后逐步绘制类图。自上而下，我总是说..？我错了吗？
Say you're looking at the 6 basic types of UML diagram (from this The Elements Of UML 2.0 Style)
- Class diagrams
- Use case diagrams
- State machine diagrams
- Activity diagram
- Sequence diagram
- Physical diagram
Pretend you're insane and you feel like drawing up all 6 diagrams for your system.
Which would you start with? Then which would you go to? What's the best order to visit each diagram if you have a pretty clear idea of what you want your system to do?
I think you should start with the physical diagram and work your way to class diagram. Top down, I always say..? Am I wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
用例是定义系统“做什么”的主要用例，后面可能是状态机和活动图（可以以任何方式查看 - 通常是活动图）更多的是关于“什么”，而状态机更多的是关于“如何”，但我已经看到了每个的反例）；类图和序列图，甚至组件图和部署图（统称为“物理”图），越来越多地涉及系统如何执行其功能。我肯定会从“什么”转向“如何”，因为相反的顺序没有什么意义——如果你没有定义“什么”，“如何”怎么可能有意义呢？
因此，粗略地总结一下：用例、活动、状态机、类、序列、组件、部署。这个顺序是有道理的，因为它更深入地涉及实现方面，而不是分析方面，因此，例如，有兴趣准确了解您将满足哪些用例以及您将应用哪些业务规则（活动图）的人可能会停止“阅读” “比需要了解部署策略的完整详细逻辑的人更早。
Use cases are the main ones that define "what" your system does, possibly followed by state machines and activity diagrams (which could be seen either way -- normally the activity diagrams are more about the "what" and the state machines more about the "how", but I've seen counterexamples to each); class and sequence diagrams, and even more so component and deployment ones (collectively the "physical"), are more and more about how your system does what it does. I'd definitely go from the "what" towards the "how" as the reverse sequence makes little sense -- how can "how" make sense if you haven't defined the "what"?
So, summarizing, roughly: use cases, activity, state machine, class, sequence, component, deployment. This order makes sense because it gets deeper towards the implementation aspects and away from the analysis aspects, so e.g. somebody interested in understanding exactly what use cases you'll cater to and what business rules you'll apply (activity diagrams) may stop "reading" earlier than somebody who needs to understand the full detailed logic of your deployment strategy.
类图、序列图和用例图占项目内通常创建的图的 90% 以上。类图本身有时比所有其他图代表更多的图。
最好的解决方案是保持简单并使建模适应团队的水平。
如果没有 UML 经验，那么只需创建类图来表示应用程序的骨架。
如果是初学者级别，则从用例、序列和类图开始。
如果是中等水平，则使用所有图表，因为每个图表涵盖另一个视图，而该视图并不总是可以用 Java 进行编码。我的意思是java只与类和序列图相关。
Class, sequence and usecase diagram represents over 90% of usually created diagram inside a project. Class diagram itself sometimes represents more diagram than all the other diagrams.
The best solution is to keep it simple and adapt the modeling to the level of the team.
If no UML experience then just create class diagram to represent the skeleton of your application.
If beginner level then start with an usecase, sequence and class diagram.
If medium level then use all the diagrams because each diagram cover another view which is not always possible to code with Java. I mean that java is only related to class and sequence diagram.
物理图可能是一个很好的起点。我发现活动图对于解决设计中的问题确实很有帮助，出于同样的原因，序列也很有用。我很少关心状态机图。
我认为实际上，无论如何，您都会想要重新审视您首先所做的任何设计（迭代设计，哇！），因此可能值得从能够为您的项目带来最清晰的内容开始。
Physical diagram is probably as good a place to start as any. I find activity diagrams really helpful in working out the kinks in a design, and sequences are good for much the same reason. I've rarely bothered with state machine diagrams.
I think realistically you're going to want to revisit whatever design you do first anyway (iterated design, woo!) so it's probably worth starting with whatever is going to bring the most clarity to your project.
UML 图是对设计的各种模型的描述。我不确定它们是否可以按照您描述的方式清晰地序列化。类图经常用于流程的分析和设计阶段。类似地，其他图表也用于多个阶段。
这取决于您在使用适当的图表“查看”设计模型的任何时间点对设计的哪个方面感兴趣。
我已经看到了“从类图开始”和“从用例模型开始”的建议。我逐渐意识到这真的不重要。
我认为您想从使用多个图表的系统的高级行为开始，然后逐渐使用同一组图表进行更详细的设计。
UML diagrams are depictions of various models of a design. I am not sure that they can be cleanly serialized the way you describe. Frequently a class diagram is used in both the analysis and design phases of a process. Similarly other diagrams are used in multiple phases.
It depends on which aspect of a design you are interested in at any point in time you use the appropriate diagram to "view" a model of the design.
I have seen both "start with class diagram" and "start with use case model" proposed. I have come to realize that it really does not matter.
I think you want to start with the high level behaviour of the system using several diagrams then gradually work your way down to more detailed design using the same set of diagrams.