UML 图是软件建模的唯一方法吗
我经常在一张纸上画出数据流。就连我的小工具的规划也是在纸上完成的。
存在UML。 问题是——我不喜欢它。我使用过的所有工具（Visio 和许多在线编辑器）对我来说都不灵活。使用铅笔，您可以轻松绘制形状并将它们连接起来，描述它们。
为了以最快、最自然和最简单的方式创建数据流图、序列图等，除了在计算机上而不是在纸上之外，您有什么建议:)
****评论中发布的有用链接：** SO Link #1 SO Link #2
现在我对 2 件事很好奇，其中一件事在我的脑海中非常深刻很久以前：
1) 思维导图 - 我不久前尝试过，非常喜欢它，但放弃了。 Hoever 将再次尝试
2) 白板。这将是最简单、最自然的方法，只不过拍照并将其存储在计算机上的某个位置会使该过程重复且无聊。
还有其他有趣的想法吗？我真的很想听听其他人使用什么来设计他们的软件以及它的进展。
多谢！
I often draw a dataflow on a sheet of paper. Even the planning of my little tools is done on a paper.
There exists UML.
The problem is - I don't like it. All the tools I've used (Visio and a lot of online editors) are just not flexible for my hands. With a pencil you can easily draw shapes and connect them, describe them.
What could you suggest in order to create a diagram of data-flow, sequence diagram, etc. in the fastest, most natural and easiest way except on the computer not the paper :)
****Useful links as posted in comments:** SO Link #1 SO Link #2
Right now I am curious about 2 things and one of them was in my minds quite long ago:
1) Mindmap - I've tried a while ago, quite liked it but abandoned. Hoever will give it another try
2) Whiteboard. It would be the easiest and most natural method, except that taking a photo and storing it somewhere on a computer would make the process repetitive and boring.
Has anyone other interesting ideas? I would really like to hear what others are using to design their software and the progress of it.
Thanks a lot!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
无论是在纸上还是在计算机上，为什么要手绘 UML？
我同意你需要一个模型来代表设计。但即使在大约 500 个人月的大型项目中，我也观察到只有 3-4 个序列图真正重要，并且有机会在应用程序的整个生命周期中生存。这些 3-4 个序列图（以及表示其静态时间关系的类图）通常表示应用程序的高层设计。
或者，这样看：
任何像样的企业应用程序都不会有 20 个不同的调用流程。将存在一两个通用（或抽象）调用流，所有具体用例都实现它们。让我们看一个简单的 Struts/EJB 应用程序。通用流程类似于 - 操作类调用验证器，然后调用无状态会话 bean，无状态会话 bean 又调用域类，域类将调用 DAO。应用程序的所有用例都只是使用特定于该用例的具体类来实现此流程。
你同意？
如果您不这样做，我想了解一下具有 20 种不同调用流程并在首次发布后存活了 5 年的应用程序。
如果您同意我的观点，即使对于包含数千个类的大型企业应用程序，我们也会将其简化为 3-4 个类和序列图。为什么绘制和维护这 3-4 张图表很重要？
您可能会说您想要记录所有用例以用于培训或文档目的。在我过去 14 年的实际企业软件世界经验中，我不记得见过“维护良好”的 UML 文档。首先，好的文档很难产生，而且并不经常被发现。其次，它们大多数时候与代码不同步。我的大部分经验都是在大型银行、保险公司、汽车公司等公司工作。这些环境太繁忙，而且他们的资源有限（真的吗？我们是在谈论银行吗？是的，很难相信，但却是事实）“维持”良好的环境文档。
那么我是建议我们摆脱 UML 吗？
不，我们需要视觉模型来表示复杂的系统。人类大脑在处理视觉图像时似乎处于最佳状态。 视觉皮层负责处理视觉图像，是人类最大的系统脑。
那么有什么合理的解决方案可以轻松地生成和维护 UML 模型呢？
源代码是事实。
你能反驳这种说法吗？如果不是，为什么不从源代码本身生成模型呢？顺便说一句，我并不是建议进行往返工程。我只是建议从代码到模型的单程之旅。
然而，生成的 UML 有两个主要问题。
好的 UML 生成工具应该能够解决上述两个问题。 Java 领域有一些工具试图解决这些问题。检查以下讨论：
什么我应该使用工具来可视化代码结构
是否有用于检测架构和设计模式的工具在代码中？
我希望我回答了原来的问题：
我是运行时UML生成工具MaintainJ的作者，但我试图以客观的方式解决原始问题。欢迎您提出宝贵意见。
Why do you want to hand-draw the UML at all whether it's on paper or on the computer?
I agree that you need a model to represent the design. But even in large projects of about 500 man-months, I observed that only 3-4 sequence diagrams really matter and have a chance of surviving the entire lifecycle of the application. Those 3-4 sequence diagrams (and class diagrams that represent their static time relationships), usually represent the high level design of the application.
Or, look at it this way:
Any decent enterprise application will not have 20 different call flows. There will be one or two generic (or abstract) call flows, which all the concrete use cases implement. Let us take a simple Struts / EJB application. The generic flow will be something like - an action class calling a validator and then calling a stateless session bean, which in turn calls a domain class, which will call a DAO. All the use cases of the application just implement this flow with concrete classes that are specific to that use case.
Do you agree?
If you do not, I would like to hear about applications that have 20 different call flows and survived for 5 years after the first release.
If you agree with me, we are boiling down to 3-4 class and sequence diagrams even for large enterprise applications comprising several thousand classes. Why is it a big deal how you draw and maintain those 3-4 diagrams?
You might say that you want to document all the use cases for training or documentation purposes. During my last 14 years of experience in the real enterprise software world, I don’t remember seeing well 'maintained' UML documentation. First of all, good documents are difficult to produce and are not found that often. Secondly, they are out of sync with the code most of the time. Most of my experience is with large banks, insurance companies, Auto companies, etc. Those environments are just too hectic and their resources are limited (really? Are we talking banks? Yes, difficult to believe, but true) for 'maintaining' good documentation.
So am I suggesting that we get rid of UML?
No. We need visual models to represent complex systems. Human brains seem to be at their best when processing visuals. The visual cortex, which is responsible for processing the visual images, is the largest system in the human brain.
So what is a reasonable solution to easily produce and maintain UML models?
The source code is the truth.
Can you argue against that statement? If not, why not generate the models from the source code itself? I am not suggesting the round-trip engineering, by the way. I am just suggesting a one way trip - from code to models.
There are 2 main problems however with the generated UML.
Good UML generating tools should address both the above problems. There are a few tools in the Java domain that try to address these problems. Check the discussions below:
What tools should I use to visualize structure of my code
Are there any tools for detecting architectural and design patterns in code?
I hope I answered the original question:
I am the author of the runtime UML generating tool MaintainJ, but I tried to address the original question in an objective manner. Your comments are welcome.
有多种工具可让您根据文本输入创建图表。您需要先学习一些语法。不过，这并不难做到。一旦有了，创建图表就会非常快。有一些缺点；在大多数情况下，更改布局/样式的能力有限。其重要性取决于您是否喜欢他们的风格。
数量不断增加，以下是您可能需要查看的一些：
嗯。
There are various tools that allow you to create diagrams based on textual input. There's some up-front learning in that you need to learn the syntax. However it's not hard to do. Once you have, creating diagrams can be very fast. There are some downsides; in most cases there's limited ability to change the layout/style. Significance of that will depend on whether you like their style or not.
There's a growing number, here's a few you might want to look at:
hth.
我喜欢使用白板和相机。为了获得更大的灵活性，请在白板上使用便利贴。
我使用 ER 图（在白板上）对数据进行建模，并使用消息序列图（在白板上）对数据流进行建模。我还将在白板上快速制作 UI 页面的模型。
除此之外，我使用 Ruby/Rails 在服务器端进行编码，在客户端使用 HTML/CSS/jQuery/JS 进行编码。
I like using a whiteboard and a camera. For even more flexibility, use post-it notes on the whiteboard.
I use ER diagrams (on the whiteboard) to model my data, and message sequence charts (on the whiteboard) to model the data flow. I'll also do quick mockups of UI pages on the whiteboard.
Asides from that, I use Ruby/Rails to code server side and HTML/CSS/jQuery/JS on the client.
如果 Visio 还不够灵活，我建议使用数字白板或带有白板软件的触摸屏。经过一番调整后，您可能还可以使用简单的平板电脑（不带显示屏）——它们真的很便宜。
关于纯软件：我们正在尝试用UML Lab实现“笔式”输入法，但它目前仅支持类图......
If even Visio is not flexible enough, I'd suggest a digital whiteboard or touchscreen with a whiteboard software. After some accommodation you could probably use a simple tablet (without display) as well - they are really cheap.
Regarding pure software: we are trying to achieve a "pen-like" input method with UML Lab, but it currently supports Class Diagrams only...
我认为应该使用类图来混合 UML 和代码。您使用类图（例如包、类等...）对您的架构进行建模，然后对您的业务进行编码，最后在代码和模型之间进行多次迭代。
我认为UML应该更多地面向代码而不是专注于文本输入。
I think that the UML and code should be mixed using a class diagram. You model your architecture with the class diagram (e.g package, classes etc....) then you code your business finally multiple iterations between code and model.
I think that UML should more be oriented to code but not to focus on textual input.
标准语言（例如 UML）的问题在于您必须投入大量精力来学习该语言和建模工具。这些语言由专家联盟（例如 OMG）定义，该联盟提出了适合特定领域中设计问题最大重叠的语言规范。
为什么不定义完全适合您的需求和具体问题的您自己的语言呢？此类语言称为域特定语言 (DSL)。您无需投资于学习复杂的语言，而是投资于完全适合您需求的语言的定义。
有许多方法支持 DSL 的定义。最广泛使用的是通用 Eclipse 建模系统 (GEMS)。就我个人而言，我在 GrGen 方面获得了很好的体验，因为它的多功能性和可能性使用图形转换自动化工作步骤。
The problem with standard languages, such as UML, is that you have to invest a considerable effort to learn the language and the modeling tools. These languages are defined by an expert consortium, e.g. OMG, that proposes a language specification suited to the biggest overlap of design problems in a certain domain.
Why not defining your own language that fits exactly to your needs and your specific problem? Such languages are termed Domain-Specific Languages (DSL). Instead of investing into learning a language that's complex, you invest into the definition of a languages that exactly suits your needs.
There are numerous approaches that support the definition of DSLs. The most widespread is the Generic Eclipse Modeling System (GEMS). Personally, I made great experience with GrGen due to its versatility and the possibility to automate working steps using graph transformation.
不，还有其他各种方法。 UML只是一个选择。
笔和纸原型设计也是一个不错的选择，它不必遵循 UML。
思维导图是另一个好方法。
对于更具适应性的软件流程，鼓励尽可能少地使用 UML。例如，实践敏捷或 XP 的团队往往较少使用 UML，他们宁愿更多地依赖非正式手段来概念化软件。在结构严格的公司中，可以严格遵循UML。
No. There are various other ways. UML is just an option.
Pen and Paper Prototyping is a great option too, it doesn't have to follow UML.
Mind Map is another great way.
For more adaptive software processes, UML use is encouraged to be as minimum as possible. Such as, teams that practice Agile or XP tend to use UML less and they would rather rely more on informal means to conceptualize the software. In a rigid structured company, UML can be rigorously followed.