我在一家中型公司担任高级开发人员，负责开发规模相当大的项目（至少 1 年以上）。这里的大多数架构师都认为创建 UML 图并不能证明所涉及的时间是合理的（尽管我们总是为所有项目提供 ERD 和一些非正式的流程图）
我希望至少为我从事的项目创建 UML 图。根据我的快速研究，似乎有以下几点：
问题：
【问题讨论】：
#1 您在公司中创建了哪些 UML 图？
我们使用由 UML 定义的整套图表。我们特别大量使用用例图、类图、序列图和状态机图。
#2 MS Visio 是否有能力创建以上所有图表？
确实如此，但我们通常不为此使用 Visio，因为那里有许多工具更适合这项工作。就个人而言，我更喜欢那些让我能够非常快速地创建图表的工具，而不需要太多的麻烦和大惊小怪。强制遵守 UML 规范的工具（或者，更糟糕的是，工具供应商对规范的解释）让我很恼火。我发现特别有用的工具之一是 Pacestar 的UML Diagrammer。
#3 是否根据正在开发的应用程序类型选择 UML 图？
UML 可用于描述任何应用程序的各个方面。但是，应用程序的性质会影响您选择使用的图表的类型和数量。
这里的大多数架构师认为创建 UML 图并不能证明所涉及的时间是合理的
UML 图不需要花费太多时间来创建。关键是通过开发“刚刚好”以满足您的需求的模型来避免收益递减。正如我上面所暗示的，我的建模工作集中在捕获系统的显着方面，而不是严格遵守 UML 规范。此外，如果这样做可以更好地传达感兴趣的系统方面，我会毫不犹豫地使用非 UML 图（或简单的文本）来对系统的各个方面进行建模。
【讨论】：
自从 90 年代发明 UML 以来，我就一直在使用它，并且已经在大大小小的公司中使用它来实现各种目的。我使用 UML 有两个基本目的：作为 思考的便笺簿（有时我不知道自己在想什么，直到我看到我画的东西；）以及作为一种记录和交流的方式设计。以下是我的使用方法以及我的一些经验法则。
当其他工具不足以进行可视化/建模时，我会使用 UML。因此，如果您使用的是 SQLServer 数据库，您可以使用内置的设计图并将它们打印并粘贴到您的文档中。这里不需要 UML。
在思考设计问题时，我通常从墙到墙的白板开始，一旦设计具体化，我就会转向 UML 图（或在显示器之间来回移动）。
JavaScript 和 Ajax 开发。工具和可视化支持很弱。我使用 UML 来思考和展示复杂 JavaScript 应用程序的高级设计。 （如果您正在开发 Java 应用程序，则可以使用大多数 Java IDE 中内置的工具来可视化您的代码。另一方面，如果您正在开发 JavaScript 应用程序或工具很差，则很难做到这一点，因此 UML 可以填补空白。）
基于网络的应用程序的信息架构和导航。我使用 UML 来显示网页、它们的关系以及网页上的信息组件。这同样适用于任何类型的 GUI 中的屏幕（它曾经被称为用户体验模型）。我在基于 Web 的应用程序中使用 REST url。所以我注释我的页面对象以显示实际的 REST URL。这样，我在布置页面时同时考虑了 REST 部分。根据我的经验，这是最有用和未充分利用的图表类型之一——也许是因为它不是标准的。它捕获信息架构（您的域模型作为页面/屏幕的集合体验）和应用程序的概念作为一组可导航视图。这种最接近用户的模型与应用程序域模型或数据库模型之间经常存在不匹配。能够有这个模型充实了这个问题。我参与过每个人都有自己的应用程序模型要构建的项目：可用性人员、开发人员、数据库人员、企业架构师。但是没有人有正确的模型，用户体验模型充实了他们没有看到的东西。
基于代码的模型。我使用 Java 并对代码库进行逆向工程，并创建图表来记录设计。但是，由于 Java 工具非常成熟，我很少需要逆向工程来理解代码。我正在使用 Enterprise Architect，它价格低廉，允许您对新代码进行逆向工程并将其与基于旧代码的 UML 图同步。
我将所有这些不同的图表放在一个项目中，它将系统的总体设计描述为一组视图。我还将我的 UML 项目导出为 XML 并将它们存储在我的版本控制系统中。图表在 Intranet 上发布并插入到文档中。
组件图，永远不会。如果我想描述组件，我只需使用类图并用原型注释它：页面、视图、表格——以表示我的对象类型'米描绘。这对我来说很简单。我大量使用刻板印象。它们让我基本上可以创建自己的图表类型，但主要还是坚持使用类图。
我很少使用顺序图和活动图，但它们有时可能不可或缺且功能强大。当您计算对象的交互时，设计阶段的序列图。交互越复杂，您就越需要序列图。 （当序列图过于复杂时，这一事实可能表明您需要简化设计。）我发现序列图在对我继承的新项目进行逆向工程时最有用，并且需要快速上手。我发现它们可以让我在理解系统方面获得竞争优势。
最后，我倾向于准物理模型。基于要编写的实际代码或实际系统的模型，但出于通信目的进行了一些抽象和调整。介于“架构宇航员”的抽象抽象和复杂的基于代码的模型之间，这些模型细节过多，价值低于 IDE 的大纲视图。
总结一下。当需要更好的可视化和其他工具不足时，我使用 UML 进行思考、记录和交流设计。
【讨论】：
前言
我认为 UML 用例图对于绘制应用程序的整体用户和功能区域非常有帮助。从技术上讲，这是业务分析师的工作，但是，如果不存在或不存在这种详细程度的细节，这是一项只需很少时间即可完成的练习，并且具有巨大的价值，可以让您全面了解解决方案。
序列图在 ASP.NET 开发中也非常有用。它使用例图中高级视图的组件易于分解和实现。
1.您在公司中创建了哪些 UML 图？
没有。 UML 不是 BA、开发团队等了解我目前工作的地方。然而，考虑到我们所做的开发类型，价值真的不存在：快速和中等规模的战术解决方案。
2.MS Visio 有能力创建以上所有图表吗？
是的。 http://softwarestencils.com/uml/index.html
我建议你考虑一个允许 UML 的工具 -> Code Gen http://www.visual-paradigm.com/
3.是否根据正在开发的应用程序类型选择UML图？
这是一个混合体。 UML 是一组工具，可以以适合用户的任何方式使用。不同的图表类型（行为、结构和交互）及其子类型具有不同的用途。经过多年处理 UML（自 90 年代后期以来），我几乎只看到类、用例和序列图的价值。除此之外，这只是语义超载，在我参与的项目中几乎没有价值。
【讨论】：
在对象模型图之后，我发现use case 图是最有用的。
【讨论】：