UML实用吗？
在大学里，我学过很多面向设计和 UML 的课程，并且我认识到可以使用 UML使软件项目受益，特别是用例映射，但它真的实用吗？ 我已经完成了一些合作工作术语，看来 UML 在业界并没有被大量使用。 在项目期间是否值得花时间创建 UML 图？ 另外，我发现类图通常没有用，因为查看类的头文件更快。 具体来说哪些图表最有用？
编辑：我的经验仅限于 10 人以下的小型开发项目。
编辑：许多好的答案，虽然不是最冗长的，但我相信所选的答案是最平衡的。
In college I've had numerous design and UML oriented courses, and I recognize that UML can be used to benefit a software project, especially use-case mapping, but is it really practical? I've done a few co-op work terms, and it appears that UML is not used heavily in the industry. Is it worth the time during a project to create UML diagrams? Also, I find that class diagrams are generally not useful, because it's just faster to look at the header file for a class. Specifically which diagrams are the most useful?
Edit: My experience is limited to small, under 10 developer projects.
Edit: Many good answers, and though not the most verbose, I belive the one selected is the most balanced.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（30）
UML只是人们内部交流的方法之一。
白板比较好。
UML is just one of methods for communication within people.
Whiteboard is better.
UML 有其一席之地。 随着项目规模的扩大，它变得越来越重要。 如果您有一个长期运行的项目，那么最好用 UML 记录所有内容。
UML has its place. It becomes increasingly important as the size of the project grows. If you have a long running project, then it is best to document everything in UML.
UML 似乎适合由大型团队组成的大型项目。 然而，我曾在沟通更好的小团队中工作过。
不过，使用 UML 式的图表很好，尤其是在规划阶段。 我倾向于用代码来思考，所以我发现编写大规格很困难。 我更喜欢写下输入和输出，然后让开发人员设计中间的部分。
UML seems to good for large projects with large teams of people. However I've worked in small teams where communication is better.
Using UML-esque diagrams is good though, especially in the planning stage. I tend to think in code, so I find writing large specs hard. I prefer to write down the inputs' and outputs' and leave the developers to design the bit in the middle.
我相信 UML 很有用，因为它让人们思考类之间的关系。 这是开始思考此类关系的一个很好的起点，但它绝对不是适合每个人的解决方案。
我相信 UML 的使用取决于开发团队的工作情况。
I believe UML is useful just for the fact that it gets people to think about the relationships between their classes. It is a good starting point to start thinking about such relationships, but it is definitely not a solution for everybody.
My belief is that the use of UML is subjective to the situation in which the development team is working.
根据我的经验：
创建和传达有意义的代码图的能力对于任何正在开发新代码或尝试理解现有代码的软件工程师来说都是一项必要技能。
了解 UML 的细节（何时使用虚线或圆端点）虽然不是很有必要，但仍然很好。
In my experience:
The ability to create and communicate meaningful code diagrams is a necessary skill for any software engineer who is developing new code, or attempting to understand existing code.
Knowing the specifics of UML - when to use a dashed line, or a circle endpoint - is not quite as necessary, but is still good to have.
UML 在两个方面很有用：
技术方面：很多人（经理和一些功能分析师）认为 UML 是一项奢侈功能，因为代码就是文档：在调试和修复之后开始编码。 UML 图与代码和分析的同步迫使您很好地理解客户的请求；
管理方面：UMl图是不准确的客户需求的镜子：如果你在没有UML的情况下编码，也许你会在工作很多小时后发现需求中的错误。 UML 图可以让您在编码之前找到可能的争议点并解决 => 帮助您进行规划。
一般来说，没有UML图的项目都是分析肤浅或者规模较小的。
如果您在 linkedin 群组系统工程师中，请参阅我以前的讨论。
UML is useful in two ways:
Technical side: a lot of people (manager and some functional analyst) think that UML is a luxury feature because The code is the documentation: you start coding, after you debug and fix. The sync of UML diagrams with code and analisys force you to understand well the requests of the customer;
Management side: the UMl diagrams are a mirror of the requires of the customer who is inaccurate: if you code without UML, maybe you can find a bug in requires after a lot of hours of work. The diagrams UML allow you to find the possible controversal points and to resolve before the coding =>help your planning.
Generally, all the projects without UML diagrams have a superficial analysis or they have short size.
if you're in linkedin group SYSTEMS ENGINEERS, see my old discussion.
UML 绝对有帮助，就像 junit 必不可少一样。 这完全取决于你如何推销这个想法。 您的程序无需 UML 即可运行，就像无需单元测试即可运行一样。 话虽如此，您应该创建 UML，因为它连接到您的代码，即当您更新 UML 图时它会更新您的代码，或者当您更新代码时它会自动生成 UML。 不要只是为了做而做。
UML is definitely helpful just as junit is essential. It all depends how you sell the idea. Your program will work without UML just as it would work without unit tests. Having said that, you should create do UML as along it is connected to your code, i.e when you update UML diagrams it updates your code, or when you update your code it auto generates the UML. Don't do just for the sake of doing it.
UML 无疑在业界占有一席之地。 想象一下，您正在为波音飞机或其他一些复杂系统构建软件。 UML 和 RUP 在这里会有很大的帮助。
UML definetly has its place in the industry. Imagine you are building software for Boing aircraft or some other complex system. UML and RUP would be great help here.
最终 UML 的存在只是因为 RUP。 我们需要 UML 或任何相关的东西才能使用 Java/.Net 吗？ 实际的答案是他们有自己的文档（javadoc 等），这足以让我们完成工作！
UML 不，谢谢。
In the end UML only exist because of RUP. Do we need UML or any of its related stuff to use Java/.Net ? The practical answer is they have their own documenation (javadoc etc) which is sufficient and lets us get our job done!
UML no thanx.
我在使用 UML 时遇到的问题之一是规范的可理解性。 当我尝试真正理解特定图表的语义时，我很快就会迷失在元模型和元元模型的迷宫中。 UML 的卖点之一是它比自然语言更明确。 然而，如果两个或更多工程师对图表的解释不同，那么它就无法达到目标。
另外，我尝试在几个 UML 论坛上以及向 OMG 本身的成员询问有关上层结构文档的具体问题，但收效甚微或根本没有。 我认为 UML 社区还不够成熟，无法支持自身。
One of the problems I have with UML is the understandability of the specification. When I try to really understand the semantics of a particular diagram I quickly get lost in the maze of meta-models and meta-meta-models. One of the selling points of UML is that it is less ambiguous than natural language. However, if two, or more, engineers interpret a diagram differently, it fails at the goal.
Also, I've tried asking specific questions about the super-structure document on several UML forums, and to members of the OMG itself, with little or no results. I don't think the UML community is mature enough yet to support itself.
作为一名学生，我发现 UML 没什么用处。 我觉得很讽刺的是，程序员还没有开发出一个程序来自动生成你所说的必要的东西。 在 Visual Studio 中设计一个功能将非常简单，该功能可以提取数据片段、寻找定义并提供足够的答案，以便任何人都可以查看它，无论大小，并理解该程序。 这也将使其保持最新，因为它将直接从代码中获取信息来生成信息。
Coming from a student, I find that UML has very little use. I find it ironic that PROGAMERS have yet to develop a program that will automatically generate the things that you have said are necessary. It would be extremely simple to design a feature into Visual Studio that could pull pieces of the data, seek for definitions, and product answers sufficent so that anyone could look at it, great or small, and understand the program. This would also keep it up to date because it would take the information directly from the code to produce the information.
当您用其字段和方法表示一个类时，就会使用 UML，尽管它只是一种 UML 图。
UML 的问题在于创始人的书太模糊了。
UML只是一种语言，它并不是真正的方法。
对于我来说，我真的很恼火开源项目缺少 UML 模式。 以 Wordpress 为例，您只有一个数据库架构，没有其他任何东西。 您必须浏览 Codex api 才能了解全局。
UML is used as soon as you represent a class with its fields and methods though it's just a kind of UML diagram.
The problem with UML is that the founders book is too vague.
UML is just a language, it's not really a method.
As for me, I really find annoying the lack of UML schema for Opensource Projects. Take something like Wordpress, you just have a database schema, nothing else. You have to wander around the codex api to try to get the big picture.
我来这个话题有点晚了，只是尝试澄清几个小问题。 询问 UML 是否有用，因为太广泛了。 大多数人似乎从典型/流行的 UML 作为绘图/通信工具的角度来回答这个问题。 注意：Martin Fowler 和其他 UML 书籍作者认为 UML 最好仅用于通信。 然而，UML 还有许多其他用途。 最重要的是，UML 是一种建模语言，具有映射到逻辑概念的符号和图表。 以下是 UML 的一些用途：
鉴于上面的用途列表，Pascal 发布的内容还不够，因为它仅涉及图表创建。 如果上述任何一个因素是关键的成功因素或者是需要标准化解决方案的问题领域，那么项目就可以从 UML 中受益。
讨论应该从 UML 如何过度杀伤或应用于小型项目展开讨论，讨论 UML 何时有意义或将真正改进产品/解决方案，因为此时应该使用 UML。 在某些情况下，一名开发人员也可以感知 UML，例如模式应用程序或代码生成。
I am coming to this topic a little late and will just try an clarify a couple minor points. Asking if UML is useful as far too broad. Most people seemed to answer the question from the typical/popular UML as a drawing/communication tool perspective. Note: Martin Fowler and other UML book authors feel UML is best used for communication only. However, there are many other uses for UML. Above all, UML is a modeling language that has notation and diagrams mapped to the logical concepts. Here are some uses for UML:
Given the uses list above the posting by Pascal is not sufficient as it only speaks to diagram creation. A project could benefit from UML if any of the above are critical success factors or are problem areas that need a standardized solution.
The discussion should expanded out from how UML can be over kill or applied to small projects to discuss when UML makes sense or will actually improve the product/solution as that is when UML should be used. There are situations where UML for one developer could sense as well, such as Pattern Application or Code Generation.
我在学校的最后两个学期共同教授了高级发展项目课程。 该项目旨在在生产环境中使用，当地非营利组织作为付费客户。 我们必须确保代码符合我们的预期，并且学生正在捕获满足客户需求所需的所有数据。
上课时间有限，课外时间也有限。 因此，我们必须在每次班会上进行代码审查，但由于注册了 25 名学生，个人审查时间非常短。 我们发现在这些审查会议中最有价值的工具是 ERD、类图和序列图。 ERD 和类图仅在 Visual Studio 中完成，因此创建它们所需的时间对于学生来说微不足道。
这些图表非常快速地传达了大量信息。 通过快速概览学生的设计，我们可以快速隔离他们代码中的问题区域，并当场进行更详细的审查。
如果不使用图表，我们就必须花时间去一一检查学生的代码文件来寻找问题。
I co-taught a senior-level development project course my last two semesters in school. The project was intended to be used in a production environment with local non-profits as paying clients. We had to be certain that code did what we expected it to and that the students were capturing all the data necessary to meet the clients' needs.
Class time was limited, as was my time outside of the classroom. As such, we had to perform code reviews at every class meeting, but with 25 students enrolled individual review time was very short. The tool we found most valuable in these review sessions were ERD's, class diagrams and sequence diagrams. ERD's and class diagrams were done only in Visual Studio, so the time required to create them was trivial for the students.
The diagrams communicated a great deal of information very quickly. By having a quick overview of the students' designs, we could quickly isolate problem areas in their code and perform a more detailed review on the spot.
Without using diagrams, we would have had to take the time to go one by one through the students' code files looking for problems.
仅在我看来扔掉。 UML 是交流思想的一个很好的工具，唯一的问题是当你存储和维护它时，因为你本质上是创建相同信息的两个副本，而这通常是它失败的地方。
在第一轮实现之后，大部分 UML 应该从源代码生成，否则它将很快过时或需要大量时间（带有手动错误）来保持最新状态。
Throw away only in my opinion. UML is a great tool for communicating ideas, the only issue is when you store and maintain it because you are essentially creating two copies of the same information and this is where it usually blows.
After the initial round of implementation most of the UML should be generated from the source code else it will go out of date very quickly or require a lot of time (with manual errors) to keep up to date.
UML 已经为我工作了很多年。 当我开始时，我读了福勒的UML Distilled 他说“做足够的建模/架构/等”。 只需使用您需要的即可！
UML has worked for me for years. When I started out I read Fowler's UML Distilled where he says "do enough modelling/architecture/etc.". Just use what you need!
我相信可能有一种方法可以利用 Cockburn 风格的 UML 鱼、风筝和海平面用例，正如 Fowler 在他的《UML Distilled》一书中所描述的那样。 我的想法是利用 Cockburn 用例来帮助提高代码可读性。
所以我做了一个实验，这里有一篇关于它的帖子，标签为“UML”或“FOWLER”。 对于 C# 来说，这是一个简单的想法。 找到一种方法将 Cockburn 用例嵌入到编程构造的命名空间中（例如类和内部类命名空间或使用枚举命名空间）。 我相信这可能是一种可行且简单的技术，但仍然存在疑问，需要其他人进行检查。 对于需要一种伪域特定语言的简单程序来说，它可能很有用，这种语言可以存在于 C# 代码中，而无需任何语言扩展。
如果您有兴趣，请查看该帖子。 转到此处。
I believe there may be a way to utilize Cockburn style UML fish,kite, and sea-level use cases as described by Fowler in his book "UML Distilled." My idea was to employ Cockburn use cases as an aid for code readability.
So I did an experiment and there is a post here about it with the Tag "UML" or "FOWLER." It was a simple idea for c#. Find a way to embed Cockburn use cases into the namespaces of programming constructs (such as the class and inner class namespaces or by making use of the namespaces for enumerations). I believe this could be a viable and simple technique but still have questions and need others to check it out. It could be good for simple programs that need a kind of pseudo-Domain Specific Language which can exist right in the midst of the c# code without any language extensions.
Please check out the post if you are interested. Go here.
从 QA 工程师的角度来看，UML 图指出了逻辑和思维中的潜在缺陷。 让我的工作更轻松:)
From a QA Engineer's perspective, UML diagrams point out potential flaws in logic and thought. Makes my job easier :)
尽管这个讨论长期以来一直不活跃，但我认为有一些重要的观点需要补充。
有缺陷的代码是一回事。 如果顺流而下，设计错误确实会变得非常臃肿和丑陋。 然而，UML 是自我验证的。 我的意思是，通过允许您在多个数学封闭且相互检查的维度中探索模型，它可以产生稳健的设计。
UML 还有另一个重要方面：它直接与我们最强的能力“对话”，即可视化能力。 例如，如果 ITIL V3（本质上足够简单）以 UML 图的形式进行传达，那么它可能会在几十张 A3 折页上发布。 相反，它以几本真正符合圣经的巨著问世，催生了整个行业，带来了惊人的成本和广泛的紧张性冲击。
Though this discussion has long been inactive, I have a couple of -to my mind important- points to add.
Buggy code is one thing. Left to drift downstream, design mistakes can get very bloated and ugly indeed. UML, however, is self-validating. By that I mean that in allowing you to explore your models in multiple, mathematically closed and mutually-checking dimensions, it engenders robust design.
UML has another important aspect: it "talks" directly to our strongest capability, that of visualisation. Had, for example, ITIL V3 (at heart simple enough) been communicated in the form of UML diagrams, it could have been published on a few dozen A3 foldouts. Instead, it came out in several tomes of truly biblical proportions, spawning an entire industry, breathtaking costs and widespread catatonic shock.
我发现序列图和活动图使用得相当频繁。 我做了很多与其他系统交互的“实时”和嵌入式系统的工作，序列图对于可视化所有交互非常有帮助。
我喜欢画用例图，但我还没有遇到太多认为它们有价值的人。
我经常想知道 Rational Rose 是否是从基于 UML 模型的设计中获得的应用程序类型的一个很好的例子。 它臃肿、有缺陷、缓慢、丑陋……
I see sequence diagrams and activity diagrams used fairly often. I do a lot of work with "real-time" and embedded systems that interact with other systems, and sequence diagrams are very helpful in visualizing all the interactions.
I like to do use-case diagrams, but I haven't met too many people who think they are valuable.
I've often wondered whether Rational Rose is a good example of the kinds of applications you get from UML-model-based design. It's bloated, buggy, slow, ugly, ...
使用 UML 就像走路时看着你的脚一样。 它使你通常可以无意识地做的事情变得有意识和明确。 初学者需要仔细思考他们在做什么，但专业程序员已经知道他们在做什么。 大多数时候，编写代码本身比编写代码更快、更有效，因为他们的编程直觉适合任务。
例外的是，为什么你发现自己晚上在树林里没有手电筒，而且天开始下雨了——那么你需要注意自己的脚，以免摔倒。 有时，您所承担的任务比您的直觉更复杂，您需要放慢速度并明确地说明程序的结构。 那么 UML 就是您可以使用的众多工具之一。 其他包括伪代码、高级架构图和奇怪的隐喻。
Using UML is like looking at your feet as you walk. It's making conscious and explicit something that you can usually do unconsciously. Beginners need to think carefully about what they're doing, but a professional programmer already knows what they're doing. Most of the time, writing the code itself is quicker and more effective than writing about the code, because their programming intuition is tuned to the task.
The exception is why you find yourself in the woods at night without a torch and it's started to rain - then you need to look at your feet to avoid falling down. There are times when the task you've taken on is more complicated than your intuition can handle, and you need to slow down and state the structure of your program explicitly. Then UML is one of many tools you can use. Others include pseudocode, high-level architecture diagrams and strange metaphors.
在一个足够复杂的系统中，有些
UML被认为是有用的。系统的有用图表因适用性而异。
但最广泛使用的是：
有许多企业对它们深信不疑，但也有许多企业彻底拒绝它们，认为它们完全浪费时间和精力。
最好不要太过分，思考什么最适合您正在进行的项目，并选择适用且有意义的内容。
In a sufficiently complex system there are some places where some
UMLis considered useful.The useful diagrams for a system, vary by applicability.
But the most widely used ones are:
There are many enterprises who swear by them and many who outright reject them as an utter waste of time and effort.
It's best not to go overboard and think what's best for the project you are on and pick the stuff that is applicable and makes sense.
但这不仅仅与你正在做的事情有关。 那么六个月后进来并需要跟上代码进度的新员工呢？ 五年后，当目前参与该项目的每个人都离开时会怎样？
为后来加入该项目的任何人提供一些基本的最新文档是非常有帮助的。 我不提倡使用方法名称和参数的完整 UML 图（太难维护），但我确实认为系统中组件的基本图及其关系和基本行为是非常宝贵的。 除非系统的设计发生巨大变化，否则即使调整实现，这些信息也不应该发生太大变化。
我发现文档的关键是适度。 没有人会在读完 50 页带有设计文档的完整 UML 图而读了几页后就睡着了。另一方面，大多数人希望获得 5-10 页的简单类图，其中包含一些关于如何设计的基本描述。系统放在一起。
我发现 UML 有用的另一种情况是高级开发人员负责设计组件，然后将设计交给初级开发人员来实现。
It's not just about what you're doing though. What about the new hire who comes in six months from now and needs to come up to speed on the code? What about five years from now when everyone currently working on the project is gone?
It's incredibly helpful to have some basic up to date documentation available for anyone who joins the project later. I don't advocate full blown UML diagrams with method names and parameters (WAY too difficult to maintain), but I do think that a basic diagram of the components in the system with their relationships and basic behavior is invaluable. Unless the design of the system changes drastically, this information shouldn't change a lot even as the implementation is tweaked.
I've found that the key to documentation is moderation. No one is going to read 50 pages of full blown UML diagrams with design documentation without falling asleep a few pages in. On the other hand, most people would love to get 5-10 pages of simple class diagrams with some basic descriptions of how the system is put together.
The other case where I've found UML to be useful is for when a senior developer is responsible for designing a component but then hands the design to a junior developer to implement.
通用工作流程和 DFD 对于复杂流程非常有用。 根据我的经验，所有其他图表（特别是 UML）无一例外都是对时间和精力的痛苦浪费。
Generic work-flow and DFDs can be very useful for complex processes. All other diagramming (ESPECIALLY UML) has, in my experience, without exception been a painful waste of time and effort.
我不得不不同意，UML 无处不在——设计 IT 项目的任何地方通常都会有 UML。
现在它是否被使用得好是另一回事了。
正如 Stu 所说，我发现从开发人员的角度来看，用例（以及用例描述）和活动图都是最有帮助的。
当尝试显示关系以及对象属性（例如持久性）时，类图非常有用。 当涉及到添加单个属性或属性时，它们通常是矫枉过正的，特别是因为一旦编写了代码，它们往往很快就会过时。
UML 的最大问题之一是一旦生成代码就需要大量的工作来使其保持最新，因为很少有工具可以从代码重新设计 UML，而且做得很好的工具也很少。
I'd have to disagree, UML is used all over the place - anywhere a IT project is being designed UML will usually be there.
Now whether it is being used well is another matter.
As Stu said, I find both Use Cases (along with the use case descriptions) and activity diagrams to be the most helpful from a developer point of view.
Class diagram can be very useful when trying to show relationships, as well as object attributes, such as persistence. When it comes to adding ever single attribute or property they are usually overkill, especially as they often become out of date quickly once code is written.
One of the biggest problems with UML is the amount of work required to keep it up to date once code is being generated, as there are few tools that can re-engineer UML from code, and few still that do it well.
我将通过提及我没有大型（类似 IBM）企业开发环境的经验来限定我的答案。
我看待 UML 和 Rational Unified Process 的方式是，它更会说话 关于你将要做什么而不是实际正在做你将要做什么。
（换句话说，这很大程度上是浪费时间）
I will qualify my answer by mentioning that I don't have experience in large (IBM-like) corporate development environments.
The way I view UML and the Rational Unified Process is that it's more TALKING about what you're going to do than actually DOING what you're going to do.
(In other words it's largely a waste of time)
UML 很有用，确实如此！ 我对它的主要用途是：
我只是不同意 Michael当他说对单个开发人员和/或一个简单的软件项目使用 UML 对他来说似乎有些过分时。 我已经在我的小型个人项目中使用了它，并且使用 UML 记录它们为我节省了很多时间，当我七个月后回到它们时，我完全忘记了我是如何构建和组合所有这些类的。
UML is useful, yes indeed! The main uses I've made of it were:
I only disagree with Michael when he says that using UML for a single developer and/or a simple software project seems overkill to him. I've used it on my small personal projects, and having them documented using UML saved me a lot of time when I came back to them seven months later and had completely forgotten how I had built and put together all those classes.
UML 图对于捕获和传达需求并确保系统满足这些需求非常有用。 它们可以在规划、设计、开发和测试的各个阶段迭代使用。
来自主题：在开发过程中使用模型，位于 http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx
您可能还想阅读我对以下帖子的回复：
如何学习“优秀的软件设计/架构”？，网址为 https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489
UML diagrams are useful for capturing and communicating requirements and ensuring that the system meets those requirements. They can be used iteratively and during various stages of planning, design, development, and testing.
From the topic: Using Models within the Development Process at http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx
You might also want to read my response to the following post:
How to learn “good software design/architecture”? at https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489
我认为 UML 很有用，我认为 2.0 规范使曾经明确的规范变得有些臃肿和麻烦。 我确实同意时序图等的版本，因为它们填补了空白......
学习有效地使用 UML 需要一些练习。 最重要的一点是清晰地沟通、在需要时进行建模以及作为一个团队进行建模。 白板是我发现的最好的工具。 我还没有看到任何“数字白板软件”能够实现实际白板的实用性。
话虽这么说，我确实喜欢以下 UML 工具：
Violet - 如果再简单一点，那就是一张纸
Altova UModel - 用于 Java 和 C# 建模的好工具
MagicDraw - 我最喜欢的商业建模工具
Poseidon - 体面的工具，物有所值
I think the UML is useful thought I think the 2.0 spec has made what was once a clear specification somewhat bloated and cumbersome. I do agree with the edition of timing diagrams etc since they filled a void...
Learning to use the UML effectively takes a bit of practice. The most important point is to communicate clearly, model when needed and model as a team. Whiteboards are the best tool that I've found. I have not seen any "digital whiteboard software" that has managed to capture the utility of an actual whiteboard.
That being said I do like the following UML tools:
Violet - If it were any more simple it would be a piece of paper
Altova UModel - Good tool for Java and C# Modeling
MagicDraw - My favorite commercial tool for Modeling
Poseidon - Decent tool with good bang for the buck
我发现 UML 对于非常小的项目来说并不是很有用，但非常适合较大的项目。
本质上，你使用什么并不重要，你只需要记住两件事：
所以 UML 是就是这样：关于如何规划项目的标准。 如果你雇用新人，他们更有可能知道任何现有的标准 - 无论是 UML、Flowchard、Nassi-Schneiderman 等等 - 而不是你现有的内部标准。
对单个开发人员和/或简单的软件项目使用 UML 对我来说似乎有些过分，但是当在更大的团队中工作时，我肯定需要一些规划软件的标准。
I found UML not really useful for very small projects, but really suitable for larger ones.
Essentially, it does not really matter what you use, you just have to keep two things in mind:
So UML is just that: A standard on how you plan your projects. If you hire new people, there are more likely to know any existing standard - be it UML, Flowchard, Nassi-Schneiderman, whatever - rather than your exising in-house stuff.
Using UML for a single developer and/or a simple software project seems overkill to me, but when working in a larger team, I would definitely want some standard for planning software.