在面向对象的软件分析及设计中，UML是一种产品、架构、开发、测试之间高效、可视化的沟通工具。UML的体系庞大，部分图形的学习曲线较为陡峭，导致在实际使用中容易出现各式各样的问题。本文将选取UML体系中常见的几种图形进行介绍，并总结一些可行的实践方式。
定义
UML是统一建模语言(Unified Modeling Language)的缩写，它是一种标准的，可视化的建模语言，被广泛应用于面向对象的分析和设计(OOA/D)。
分类
UML可以大致分为结构图和行为图两类，（也有人称之为静态图和动态图）。结构图主要包含类图、对象图、包图、组合结构图、组件图、部署图等等，行为图主要包含用例图、活动图、状态图、时序图、通信图等等。
结构图主要描述了被分析的系统中，各个组成部分的概念，以及这些概念之间的关系。
而行为图则描述了一些列会随时间变化的系统对象的动态行为。
优势
UML为产品、架构、开发、测试提供了一种可视化的统一沟通方式。试想一下，如果你作为一个开发人员，每天面对纯文字的需求稿和符号不统一的架构设计方案。你的大部分的精力都会浪费在无尽的沟通成本上。而UML的辅助使用，可以提供直观、高效、准确的信息传递，会大大降低这部分沟通成本。
此外，UML不仅仅是一种面向软件分析、架构设计的工具，其对现实世界的概括建模能力，为业务需求和软件设计提供了连接的桥梁。确保了，代码不会在需求层面产生偏移。
劣势
UML也存在一定的劣势，其体系庞大，部分图形的学习曲线较为陡峭。许多同学在一知半解的情况下，容易产生误用、滥用等情况。
另外，UML也常常成为项目失败的背锅侠。例如，开发和架构在项目初期，花费大量精力使用UML制作了极其细致的设计方案。但是开发阶段的需求变更，或者是发现实现的技术难点导致更改方案时，这部分UML图就需要推翻重来。此时的UML就容易成为无用、低效评价的主要承担者。
实践
首先强调一点，UML不是OOA/D的银弹，它只是用于提升建模表达效果的工具之一。UML的能够达到是上限，是准确，充分的表达你在软件设计上思想。因此在学习使用UML的同时，你仍需要提升软件设计的能力。
下面是我总结的一些UML学习和使用的经验实践：
- 28原则。UML的体系庞大，但是对于软件开发者、架构师来说，只需要选取其中的一个子集，就能应付大量的日常使用场景。下面是我选取的一个子集：
- 类图
- 用例图
- 活动图
- 时序图
- 迭代原则。从敏捷开发等实践来看，任何设计方案都不是一次到位的，我们需要在后续的项目迭代过程中不断完善、调整、变化。UML也是一样，不要想着UML能够一次到位。
- Less is More。这个和迭代原则相辅相成，对于使用UML图来描绘一个软件系统，你可以具体到每一个类的方法属性，可以抽象到模块或者业务。而在这两者之间平衡的原则就是Less is More——只对必要的内容进行描述。如果你只关注系统某些抽象概念之间的特定业务联系，那么与该业务无关的内容以及概念的具体实现方案，就不应该出现在这个UML图中
最后希望强调的是，UML在方案推导时，作为草图设计，或者在项目展示时，作为可视化方案，仍是主要工具选择之一。希望大家能够学习好、使用好UML这款工具。
参考链接：
- Unified Modeling Language (UML) description
- 统一建模语言 - 维基百科，自由的百科全书
本文会经常更新，请阅读原文： https://xinyuehtx.github.io/post/UML基础.html ，以避免陈旧错误知识的误导，同时有更好的阅读体验。
本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布，但务必保留文章署名黄腾霄（包含链接： https://xinyuehtx.github.io ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请 与我联系 。
