UML的常见用法

根据我的经验，大多数体系结构文档充其量都是临时的，除了更结构化的死树类型的写作之外，我还没有看到正式的UML在实际使用中，我与很少的开发人员合作过，如果有开发人员能够清楚或正确地构建UML图的话——它似乎更多地被用作一种“图形伪代码”

鉴于此，我很好奇是否有人有在内部文档和团队成员之间交流系统功能时使用UML的经验。这是人们在日常生活中真正使用的沟通工具/方式吗？它是否有用，是否过度指定？您是否曾在精确的UML非常重要或有用的环境中工作过？

UML（统一建模语言）是灵活的。没有必要一直使用“完整”UML

是的，我使用UML来传达设计。我将域、类、活动、用例、序列和部署图用于各种目的

---

其中一些目的超出了图表的“明显”用途。例如，我使用部署图来记录虚拟机的集合。因为节点元素是一个UML“分类器”，所以它可以与继承一起使用。我用它来说明基本虚拟机是如何专门化的。例如，基础只是Windows Server 2008，但安装了SQL Server的一个专门化，而该专门化正被用作数据库服务器。

在我的工作场所中，我们在编写大型企业级web应用程序时广泛使用了UML类图。在某些情况下，我们使用序列图。但是，我们决不会使用完整的UML图表套件，甚至不会接近。UML只有通过咀嚼肉和吐出骨头才能有效。它是一个很好的通信工具，但是使用太多的功能会让人困惑。

根据我的经验，我发现UML序列图对于试图理解系统或系统的特定过程的人来说是最有用的

---

最有可能的原因是，它显示了各个组成部分是如何合作的，并间接显示了每个组成部分的责任。垂直维度显示时间，图表非常直观易懂，即使对于不了解UML的人来说也是如此。

我见过UML类图用于自动代码生成的用法。流是这样的，用于从类图生成XML模式。然后，该模式被用作生成Java类的输入，这些Java类提供对UML模型中表示的数据的编程访问。

我发现UML类图比实体关系图更有助于创建逻辑数据模型或域模型。它更具表现力，具有泛化（即继承）和特定的n对n关系。尝试在ER图中对此进行建模：）

---

UML图对于捕获和传达需求以及确保系统满足这些需求非常有用。它们可以在计划、设计、开发和测试的各个阶段反复使用

主题：在开发过程中使用模型

模型可以帮助您可视化系统工作的世界，明确用户的需求，定义 系统架构，分析代码，并确保代码满足要求

如果不想从头开始创建UML图，可以从代码创建序列图、依赖关系图和层图，并使用层验证来确保代码中的更改不会与指定的设计冲突。我在下面的帖子中对此进行了更详细的描述：

---

如何学习“优秀的软件设计/架构”在

+1提及企业架构师-一个伟大的工具，尽管它具有“独特的界面”。