我们知道UML是统一的建模语言。那么它可以模拟任何类型的软件（如Linux内核，开放式办公室，任何Web应用程序等）吗？或者只能建模使用面向对象语言（Java，c ++等）的软件？
我认为建模是找出软件的好方法。如果我们不使用UML进行建模，我们可以使用哪些其他建模方法？
你知道什么样的建模方法用于大型开源项目（Linux内核，Openoffice.org，Firefox，Apache http，MySQL，Eclipse，VIM等），我们在哪里可以找到建模文档他们？
谢谢你的回答！
答案 0 :(得分：5)
UML首先是一个通信工具，它可以帮助您将想法传达给团队中的其他人（或将来三个月），因此，应该根据它是多么容易表达你的想法。
与语言无关，UML不能用于表达使用给定API或模块的预期的，惯用的方式，但这是设计的一个重要部分：忽略它往往最终会得到准确模拟底层的代码问题但需要几十行样板代码才能与之交互。
此外，UML无法轻松捕获算法所依赖的数据结构的某些特定属性。例如，红黑树更容易用小树状草图表示，“这是一个红黑树”或“这不是红黑树，因为”描述，而不是相应的UML类图。
最后，语言可能具有UML中没有优雅表示的功能 - 例如，Objective Caml模块仿函数或任何具有它们的语言的闭包。
答案 1 :(得分：4)
答案 2 :(得分：3)
UML与语言无关，因此您可以为支持对象和类的任何语言建模。例如，用汇编语言编写应用程序很难，因为这种语言不能在对象上运行。
不要严格遵守UML标准符号。 UML是为您创建的，而不是您创建的服从UML参考指南。它的目的是帮助你展示你的系统概念，所以如果你（和你的团队）接受不同的符号，那就没关系。
另一件事是，对于创建的每个应用程序（甚至是大型），都不需要UML。如此多的开源项目都没有它，因为不可能为大型社区开发的软件维护实际的UML图。
从敏捷的角度来看，你不应该创建庞大的UML文档，因为它很快就会成为负担，而不是帮助。明智地使用它，更喜欢在黑板上，只是为了向你的团队展示你的意思。您的目标是创建应用程序，因此不要浪费时间在不断更改代码的情况下同步图表。
答案 3 :(得分：1)
UML / OMT和其他建模语言旨在帮助您完成两件事 - 在实现之前对您的设计进行建模，然后将您的设计与其他开发人员进行沟通。首先，您可以使用您喜欢的任何符号，但UML为您提供了大多数开发人员几乎普遍理解的标准。与代码相同 - 糟糕，不必要的复杂代码需要大量的注释，对于结构糟糕的设计的UML图表看起来很糟糕，暴露了丑陋。
尽管有人说，尽可能坚持标准细节。例如，在静态类图上错误指定的基数可能看起来不是什么大问题，但这很重要，因为如果你在代码中犯了这样的错误，它根本就行不通。 UML图通常是出于错误的原因而在事后创建的 - 例如给你的经理留下深刻印象。在那种情况下，它通常是无用的运动。
我经常使用UML。我不使用任何UML编辑工具。在项目开始时，在创建任何新代码之前，我会拿一张大纸用于工程图并开始添加类或模块，从中心开始添加数据结构。将整个图表保持在相同的详细程度非常重要。我用铅笔和橡皮擦绘制整个图表。尽可能避免自己建模的编码设计 - 将其委托给其他开发人员并在必要时交换角色。如果实施者表现出误解和阻力，因为设计很难理解或实施 - 这是一个好的迹象，你必须改变你的设计 - 但首先要在纸上做所有的改变，与团队中的其他开发人员交谈并询问他们会改变什么实现该代码。 用序列图补充静态图 - 良好的做法是保持每张纸的一个交互顺序。添加数据流图，状态转换图等。 这种纸和铅笔方法有一些奇怪的效果，非常积极地影响你的设计。我认为这是因为它倾向于提出所有不完美之处并将它们放在平面视图中。 在某些时候，你将不得不重绘中心图，所以最好将它的稳定部分复制到UML编辑工具，以便可以打印它们而不是手工重绘它们。把你的“战争室”放在那张纸的中心，如果他们想要添加或更改某些内容，你会注意到每个人都来到那张桌子 - 你去了，你开始真正使用UML并从中获益。