在面向对象的软件分析及设计中,UML是一种产品、架构、开发、测试之间高效、可视化的沟通工具。UML的体系庞大,部分图形的学习曲线较为陡峭,导致在实际使用中容易出现各式各样的问题。本文将选取UML体系中常见的几种图形进行介绍,并总结一些可行的实践方式。


定义

UML是统一建模语言(Unified Modeling Language)的缩写,它是一种标准的,可视化的建模语言,被广泛应用于面向对象的分析和设计(OOA/D)。

分类

UML可以大致分为结构图和行为图两类,(也有人称之为静态图和动态图)。结构图主要包含类图、对象图、包图、组合结构图、组件图、部署图等等,行为图主要包含用例图、活动图、状态图、时序图、通信图等等。

结构图主要描述了被分析的系统中,各个组成部分的概念,以及这些概念之间的关系。

而行为图则描述了一些列会随时间变化的系统对象的动态行为。

UML 2.5 Diagrams Taxonomy.

优势

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这款工具。

参考链接:


本文会经常更新,请阅读原文: https://xinyuehtx.github.io/post/UML%E5%9F%BA%E7%A1%80.html ,以避免陈旧错误知识的误导,同时有更好的阅读体验。

知识共享许可协议 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布,但务必保留文章署名黄腾霄(包含链接: https://xinyuehtx.github.io ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请 与我联系