为什么要建模/制图？
我正在考虑通用建模（图表）标准和工具，例如 BPMN、UML、数据建模等。
为什么我们需要建模？ 通常在哪个阶段建模对您来说至关重要？沟通？文件和报告？ 您如何在工作或日常生活中从它们中受益？
谢谢你！
I'm thinking about general modeling (diagramming) standards and tools such as BPMN, UML, data modeling, etc.
Why do we need modeling?
Usually on what phase is modeling essential for you? communication? document and report?
How can you benefit from them in work or daily life?
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您已经创造了最重要的词：沟通
不仅与他人沟通，还与未来的自己沟通。如果您现在编写一个应用程序，并在暂停几个月后返回它，那么将很难找到解决方法。当然，这取决于相关应用程序的大小和复杂性。但是拥有一些视觉表现总是有帮助的。
此外，在实际开发之前绘制应用程序图表是让您了解所有内容的好方法。通常，您会在最初的想法中发现一些在该阶段很容易解决的问题。如前所述，这些图表将来会变得很有帮助。
向其他人展示应用程序内部的工作原理同样重要。每个人处理问题的方式都不同。因此，对你来说直观的东西在别人眼中可能会显得很奇怪。这使得很难掌握其他人编写的应用程序的概念。
还要记住，我们中只有少数人（是任何人）能够编写完美的代码，并构建完美的架构。我们是人，我们都会犯错误。
举例来说，您听说过一种名为“装饰器”的漂亮设计模式，并且您想使用它。自然地，“装饰器”这个词会出现在你的代码中，阅读它的人会想：“嘿，我知道这个模式。不需要阅读血淋淋的细节。我只需将它作为黑盒处理并使用它”。但是，如果您误解了该模式并错误地实现了它，该怎么办？现在使用它作为黑匣子的人会遇到问题。这些问题可能包括小错误到非编译 API 调用。如果你有整个事情的图表，就更容易查明原因。
建模的最大问题是保持图表与代码同步。在项目生命周期中，您将做出更改。小的和大的。在完美的世界中，您将更新图表，思考它，让它深入您的大脑，然后然后实现它。但世界并不完美。因此，您最终可能会在绘制图表之前实现一些东西（如果实际上绘制了图表）。这整个过程很麻烦。可能是因为您使用的图表软件很糟糕，也可能只是因为时间限制。
就我个人而言，我喜欢创建一个初始图表。一旦我对此感到满意，我就会投入实施。我不会重新查看该图以进行微小的更改。是的，一段时间后代码会偏离图表，但大局仍然存在。如果我需要进行更大的架构更改，我肯定会重新审视该图。
然而，我将做的是保持代码内文档最新。大多数文档提取工具（例如
javadoc）使您可以使用标记，这对于使生成的文档可读和可用非常有用。特别是在使用超链接时。因此，回到您的一个观点，即您询问在日常开发人员生活中有什么好处，我认为较大的图表不会产生太大的影响。原因很简单，一旦您掌握了项目的概念，您在每天仔细阅读代码库时就不再需要图表了。不过，有用的是正确的代码文档字符串。主要是因为许多 IDE 在编码时会显示它们，或者至少可以轻松跳转到它们。对于图表来说，情况并非如此。
然而，图表对于快速开始项目很有用。
关于流程图/活动图的另一种思考：我发现这些几乎没有用。 除了复杂的算法，因为它可以帮助您可视化圈复杂度。但老实说，我从来不需要自己编写复杂的算法。我总是在标准库或第三方库中找到现成的实现。
最后一点：这个问题应该发布在 https://softwareengineering.stackexchange.com/ 上；）
You coined the most important word already: communication
Not only with others, but also with your future self. If you write an application now, and return to it after a few months pause, it will be hard to find your way around. Certainly, this depends on the size and complexity of the application in question. But having some visual representation will always be helpful.
Also, diagramming the application before actual development is a great way to wrap you head around everything. Normally, you will detect problems in you initial idea that are easy to fix at that stage. And as said, these diagrams will become helpful in the future.
Showing others how the application works internally is equally important. Everybody has a different way to approach problems. So something that is intuitive for you might seem weird in someone else's eyes. This makes it hard to grasp the concepts of an application someone else has written.
Also remember that only few of us (is any) write perfect code, and do a perfect architecture. We are human, we make errors.
Let's say for example that there is this nifty design pattern you heard of called "decorator", and you want to use it. Naturally, the word "decorator" will appear in your code, and people reading it will think: "Hey, I know this pattern. No need to read the gory details. I'll just handle it as a black-box and use it." But what if you misinterpreted the pattern and implemented it incorrectly. Now the person using it as a black-box will run into problems. These may range from small bugs to non-compiling API-calls. If you have a diagram of the whole thing, it will be much easier to pinpoint the cause.
The biggest problem with modelling is to keep the diagrams in-sync with your code. During the project life-time you will make changes. Small ones and big ones. In a perfect world, you would update the diagrams, think about it, let it sink into your brain, and then implement it. But the world's hardly perfect. So you may end up implementing something before diagramming it (if it's actually diagrammed at all). This whole process is cumbersome. Be it because the diagram software you use is crap or just simply because of time constraints.
Personally, I like to create an initial diagram. And once I'm happy with it, I dive into implementation. I won't revisit the diagram for small changes. Yes, after a while the code will deviate from the diagram, but the Big Picture is still there. If I need to make a bigger architectural change, I will revisit the diagram for sure.
What I will do however is keep the in-code documentation up-to-date. Most documentation extraction tools (like
javadoc) give you the possibility to use markup which is useful to make the generated docs readable and usable. Especially when using hyperlinks.So, coming back to one of your points, where you ask what the benefit is during the daily developer life, I think that the larger diagrams don't make that much of a difference there. Simply because once you grasped the concepts of the project, you will not need the diagram anymore as you peruse the codebase on a daily basis. What comes in handy though are proper code docstrings. Primarily because many IDEs display them while coding, or at least make it easy to jump to them. With diagrams, that's not so much the case.
Diagrams however are useful to get started quickly with a project.
One more thought about flow-charts/activity-diagrams: I find these mostly useless. except for complex algorithms, as it helps you visualize the cyclomatic complexity. But quite honestly, I have never needed to write a complex algorithm myself. I always found ready-to-use implementation in either the standard library or in a third-party library.
And one final note: This question should have been posted on https://softwareengineering.stackexchange.com/ ;)
我只能谈论状态机的流程图和图表，但答案可能也适用于此：如果你绘制某些东西，你就被迫考虑你的底层结构。通常，糟糕的结构往往更难/丑陋地绘制为图表。
I can only speak for flowcharts and diagrams for state machines, but the answer might apply also here: If you chart something, you are forced to think about your underlying stuctures. Usually bad structures tend to be more hard / ugly to draw as a diagram.