最近在开发的过程当中，对于已有的代码，想将相关类绘制成UML类图，虽然现在有很多UML类图的优秀软件，比如ProcessOn（可视化编辑）、draw.io（可视化编辑）、PlantUML(代码生成)，其实看到这里我就想IDEA中有没有像PlantUML一样的自动生成的插件，本着怀疑的态度百度了一下，果然IDEA还是很强大的，这个插件都是自带的，接下稍微讲述如何利用IDEA生成UML类图的教程。
 
说之前先说一下Diagram这个单词，意思是图表; 示意图; 图解; [数] 线图的意思。
 
打开设置 File->Setting或windows下按Ctrl+Alt+S
在搜索框中输入Diagram，如下图：
 
如上所示，我们主要关心的只有Java Class Diagrams下面的几个单选框，分别对应红字部分，一般的UML类图只需要知道成员变量、构造器和方法（前面三个），其他的随意，设置好了之后我们就来演示一下，
 
选择需要的类文件，在编辑器中打开它
按Ctrl + Shift + Alt + U或Ctrl + Alt + U或右键选择，生成类Uml关联图，如下图：

 
 
上面的是类的UML图，下面的support包的UML图：
 
 
局限性：虽然这个很是方便，但是也有他自己的局限性，首先这个功能只能是根据类来自动生成的，所以对于设计类的时候就不行了，还是需要正规的UML图软件，还有就是对于专业的UML软件来说，这种自动生成的东西可能表达并不是非常的准确直观，特别是对于UML图有严格要求的人来说，显得格外重要。

UML中文FAQ 
 

V1.0 
张恂 
2003年10月29日 
 
编者按： 
 
一直很难找到中文的、适合国人看的UML FAQ，而英文的UML FAQ往往散落于各处不易收集和消化，导致很多看似简单却很基本、很关键的问题在网络论坛、BBS上被反复地提出，既浪费了提问者、解答者不少的时间和精力，也给大家学习总结、进一步提高带来了困难。于是，结合自己的所学所想试着编写了一个UML中文FAQ供各位参考。众人拾柴火焰高，有什么不足之处，欢迎大家多多提出宝贵意见，不断补充，一起来完善！ 
联系邮箱：zhangxun2001@hotmail.com 
 

什么是UML？ 
UML有哪些特点？ 
UML有什么用？ 
UML不能做什么？ 
为什么要学习和掌握UML？ 
什么情况下不需要或不适合用UML？ 
什么情况下应该用UML？ 
促进UML普及和应用对于加强我国软件业的实力有什么重要意义？ 
UML的统一性表现在哪些方面？ 
UML是如何诞生的？ 
UML是一家之言，或少数派的观点吗？ 
UML之父是谁？ 
UML标准有哪些最新进展？ 
初学者如何开始学习UML？ 
世界上有哪些著名的公司、组织参与了UML标准的制订？
 
什么是UML？ 
 
Unified Modeling Language（统一建模语言）是国际对象管理组织OMG制定的一个通用的、可视化建模语言标准，可以用来描述（specify）、可视化（visualize）、构造（construct）和记载（document）软件密集型系统的各种工件（artifacts，又译制品）。 
 

UML有哪些特点？ 
UML的“通用性”主要是指不仅仅可以用它来描述软件，而且还可以用它来描述一般企业或组织的业务流程以及由软、硬件共同组成、以软件为主的复杂系统（即所谓的软件密集型系统），甚至还包括非软件系统。 
 
UML的“可视性”是指可以通过UML一系列的图形符号，组成多种视图（view）来直观、清晰地表达系统分析设计中方方面面的、许多复杂的概念。UML主要是为了人的阅读和使用而设计的，所以它采用了半形式化的，易于人们理解、交流的形式。 
 
UML是一种分析设计专用的建模语言，它本身不是编程（programming）语言，不能直接用来生成可执行的软件。UML是一种抽象层次比C、C++、Java、VB、Delphi等文本高级语言更高的图形语言，通过它我们可以抽象地表示用高级编程语言编写的文本程序的逻辑结构和行为。相比传统的高级编程语言，UML能够更加高效、准确地反映软件设计的方案和思路，是真正用来“设计程序”（design programs）的语言。从这个意义上看，不妨称UML为“甚高级”程序设计语言。 
 
UML基本上不能算作全新的发明，它并非学者教授、科研机构的研究成果，而是直接来自于产业界、工程界的实践总结，是在归纳基础上进行理论升华的产物，其核心内容反映了30多年来全球软件工业的领导者在软件设计构造领域的最佳实践和成功经验，因而具有很高的实用价值。 
 
实践证明，OO分析设计(OOAD)方法比传统方法能更加准确、全面地描述现实世界。UML是用来表述OO概念的一种语言工具，而很奇妙，它本身作为一件产品同样也是用OO方法来设计的，这使得UML具有传统建模语言所不具备的很强的语义表达能力和非常灵活的可扩展性。
UML有什么用？ 
 
UML的用途非常广泛，可以概括为“描述、可视化、构造、记载”4种基本功能，在业务建模、需求分析、系统设计、实现和测试、数据建模、项目管理等阶段任务中均可根据需要采用。 
 
UML建模是建立软件开发文档的一个有效手段，通过UML可视化地描述系统需求，记载软件构成，能够显著地提高文档的质量和可读性,减少编写文档的工作量。 
 
UML实质上是一种系统分析设计专用语言，通过可视化的图形符号结合文字说明或标记可以帮助业务/系统分析员、软件架构师/设计师、程序员等各种建模者有效地描述复杂软件（或业务）的静态结构和动态行为，包括工作流（数据流和控制流）、功能需求、结构元素及关系、架构组成、设计模式、对象协作、事件响应和状态变化等等。 
 

UML不能做什么？ 
 
UML不是高度形式化的语言，一般不能用于定理证明。 
 
UML是基于OO方法的通用建模语言，不适合用户图形界面设计、超大规模集成电路（VLSI）设计、基于规则的人工智能等专业领域。 
 
UML是一种离散型建模语言，适合对由软件、固件或数字逻辑构成的离散系统建模，不适合对工程和物理学领域中的连续系统建模。 
 
本身作为语言，UML仅仅是一种表达形式，不是建模方法，在实际的软件项目开发中仅仅掌握一套标准的图形符号是远远不够的。用好UML首先需要掌握OOAD的基本原则和方法，并在一定的软件开发过程（如UP/RUP、XP等）的指导下进行有取舍的运用。
为什么要学习和掌握UML？ 
 
首先，UML对于当前大多数希望进一步改进质量的软件开发团队来说是必不可少或必须的。为什么这样说呢？因为，C++、Java等源码并不能直观、方便地反映复杂程序的设计：如内部逻辑结构、各种隐含的依赖关系、运行时的状态改变和特殊行为等等。写好的代码仅仅是一种实现方式，很难反映出现象背后的真实本质——设计，因此对于大多数稍稍复杂点的项目来说，仅有代码是不够的。 
 
可视化建模历来是一种成功的工程实践做法，并非软件行业所特有。软件的设计方案在用C++、Java实现之前通常隐藏在人们的头脑当中，而设计正确与否是决定软件质量好坏的要害，一个前提是必须用适当的方式把它表达出来。通过程序代码来表达、讨论、评估和选择复杂软件的设计往往是很笨拙的，这一表达 
 
方式的空欠唯有通过类似UML的建模语言来填补。 
 
其次，OO方法是当代主流的软件开发技术。世界先进的软件团队和个人早已摆脱了对如何使用具体的平台API、个别编程语言特性的纠缠，而把更多的精力放在了需求、架构、设计机制和模式等对软件质量有重大影响的核心要素——分析与设计上。UML作为OO建模语言的事实上标准和主要的表达媒介，在这些场合能发挥关键的作用。所以，熟练地掌握并运用好UML是当今系统分析员、架构师/设计师以及程序员等软件工程师所必备的一项基本技能。 
 

什么情况下不需要或不适合用UML？ 
 
对于一个特定的软件公司或开发团队，在下列情况下建议不采用UML： 
1）传统的做法已完全适用，对OOAD的要求也不高，项目非常成功，无任何改进的必要; 
2）开发的系统比较简单，直接用源码配上少量的文字就能解决问题，软件开发文档也无需添加图形来辅助说明； 
3）开发人员更习惯于直接阅读源码，用源码交流，这样做不影响工作效率和质量； 
4）开发的系统本身不属于OO方法、UML适用范围。 
 

什么情况下应该用UML？ 
 
对于一个特定的软件公司或开发团队，在下列情况下建议采用UML： 
1）OO方法是项目决定采用的方法论，是整个项目或产品成功的关键； 
2）开发人员感觉用源码说明不了真正的问题，希望利用可视化建模语言简化文档，提高交流的效率，准确抓住问题的本质； 
3）系统的规模和设计都比较复杂，需要用图形抽象地表达复杂的概念，增强设计的灵活性、可读性和可理解性，以便暴露深层次的设计问题，降低开发风险； 
4）公司希望记录已成功项目、产品的公共设计方案，在开发新项目时可以参考、重用过去的设计，节省投入，提高成功率。
 
促进UML普及和应用对于加强我国软件业的实力有什么重要意义？ 
 
OO方法自上世纪80年代以来已经成为软件开发的主流技术，标准OO建模语言UML的问世说明OO技术的发展达到了一个新的高峰。推广普及UML的应用可以使我国软件开发人员、软件企业和客户乃至整个行业都从中获益： 
1）个人 
UML相关知识体系蕴含了非常丰富的当代软件工程先进知识。软件开发人员通过学习和掌握UML概念、表示法及相关的软件过程、软件工程技术，能够加深对OOAD原则、方法的理解，提高抽象思维能力，从而站在更高的层次上分析问题、解决问题，这是一条快速提高个人软件设计能力的有效途径。 
2）企业 
对软件企业内部，用好UML，不但能直接提升企业的软件设计开发能力，而且由于UML能形象直观地记录软件设计的核心思想，可以使软件开发管理透明 
化，促进企业知识资产的保护和增值，促进软件重用和整体效益的提升。对外，由于UML是通行的软件行业国际标准，企业在业务交往中有效运用UML，无论对于开拓国内外产品市场还是保障工程承接、项目外包等业务的顺利开展都大有裨益。 
3）行业 
积极采用国际通行的软件描述和设计语言UML，一方面能增加信息透明度，显著降低软件企业之间、客户与开发商之间的沟通成本，减少项目失败的风险，另一方面能促进行业市场的规范化和标准化，增进国际技术交流，整体提高我国软件业的技术水平和参与国际市场竞争的能力。据悉，与UML有关的国家级标准目前正在考虑制定过程当中。 
 

UML的统一性表现在哪些方面？ 
 
UML的统一性至少表现在以下几个方面： 
1）随着OO技术的蓬勃发展，到上世纪90年代初OO方法已经多达50余种，它们之间既有很多共通之处也存在许多没有必要的细节差异，这妨碍了技术进步，不利于产业的发展。UML统一了多种互补的、最具代表性、最受业界欢迎的主流OO方法，这既是历史的必然，也OO方法成熟的一个重要标志。UML及与其配套的OO统一过程（RUP）在实现“合并同类项”的基础上又向前迈出了一大步，不愧为当代OO建模方法的集大成者。 
2）UML适用于各个行业的信息化工程，包括电信、银行、保险、税务、办公自动化、电力、电子、国防、航天航空、制造、工业自动化、医疗、交通、商业、电子商务等诸多领域的业务建模和软件分析设计，尤其适合对大中型、复杂、分布式应用系统或软件产品建模，在这些广泛的领域中都可以统一使用一套标准的建模语言。 
3）作为一种独立于具体实现的、抽象的表述方式，UML广泛地适用于各种现代程序设计语言、数据库和开发平台。 
4）有了UML标准，面向各种不同的软件开发方法和过程（如重载/轻载，瀑布式/迭代递增式），在软件开发生命周期各个阶段的工作（如业务建模、需求分析、设计、实现、测试）中，都可以采用一套统一的概念和表示法，避免了语言转换的麻烦。 
5）UML明确定义了一套公共的内部概念，建立了统一的关于建模语言的元模型，反映了在软件和信息建模技术领域的最新成果。 
 

UML是如何诞生的？ 
 
识时务者为俊杰。为了突破上世纪90年代初OO方法论混战的局面，1994年杰出的Rational公司OO大师Grady Booch邀请通用电气公司著名OO大师James Rumbaugh博士加盟Rational，启动了OO方法的统一历程。他们于1995年发表了“统一方法0.8”。与此同时，另一位超一流OO大师、爱立信公司的Ivar Jacobson博士也在该年加入了二人的行列。 
 
1996年，3人正式把他们的统一成果命名为“统一建模语言”，UML于此诞生。同时，他们还做出了一个非常重要的决定——把UML提交到非赢利性的OMG进行标准化，让全世界的软件开发人员都可以自由地分享这一软件史上的重大成果。 
 
于是，在全球软件界具有广泛影响力的国际对象管理组织OMG从此开展了一系列OO建模语言的标准化工作。1997年11月，UML 1.1经OMG各成员投票被正式采纳为行业标准。 
 

UML是一家之言，或少数派的观点吗？ 
 
否，UML是全球工业界和学术界的领导者协同努力的成果。自从进入OMG程序后，UML就不再由Rational一家公司所有或由少数人控制，而成为凝结了百家之长的公共知识结晶。具有丰富企业信息系统和信息工程经验的OO大师、Martin/Odell方法的领军人物James Odell为此曾表明放弃自己的方法，并直接参与领导了UML 1.x系列标准的制订工作。另一位OO大师Coad/Yourdon方法的创始人之一Peter Coad，虽然没有直接参与UML制订，但却独具慧眼创办了TogetherSoft公司（已被Borland收购），开发了著名的UML集成开发环境Together ControlCenter，成为Rational Rose的有力竞争者。事实说明，UML的确促进了各种OO方法和流派的大融合，在OO建模语言领域具有不可替代的地位。 
 

UML之父是谁？ 
 
UML之父有三位:他们是Grady Booch（Booch方法），James Rumbaugh（OMT方法）和Ivar Jacobson（OOSE方法）。人们亲切地称他们为“3 amigos”（即“三高”，类似于大家给予合作举办世纪音乐会的，世界上3位顶尖男高音歌唱家的称谓）。 
 

UML标准有哪些最新进展？ 
 
UML 1.x系列的最新版本是于2003年3月发布的1.5版本（www.uml.org）。 
OMG（www.omg.org）从2000年起启动了UML 2.0标准的制定工作。U2P组织（UML2 Partners Consortium，www.u2-partners.org）在UML 2.0标准的制定过程中发挥了主导作用。目前UML 2.0的上层结构（Superstructure）规范已经在2003年6月12日获得通过。 
OMG已经与国际标准化组织ISO开展了合作，预示着UML将来有望成为ISO标准，值得关注。
 
初学者如何开始学习UML？ 
 
无外乎几种方式：读书、上网、实践、培训。 
 
最近几年国内一窝蜂地出版了不少与UML有关的中英文书籍，但说实话，有点良莠不齐。初学者不管自学还是参加培训，选择合适的UML教材/读物是很重要的。 
 
Craig Larman的《UML和模式应用》是一本非常好的内容丰富、真正实用的入门教材，在国际上也是用得最多的一本，无出其右者。纵观全书，以实案为中心，脉络清晰，组织老到，深浅适当，循循善诱，非常适合UML、UP、设计模式的初学者和一直对OOAD、UML的价值存有疑虑的结构化人士一读。对于熟悉OO的人来说，阅读此书也是再一次享受梳理知识、进行系统性训练的美妙体验。本人尤其推荐第2版（内容更新了不少，听说正在引进翻译，值得期待）。 
 
如果希望与大师对话，全面深入地掌握UML的基本要领，通过领悟UML设计者的思想和意图来达到在实战中得心应手运用OO建模技术的目的，建议一定要阅读UML之父Grady Booch亲自撰写的《UML用户指南》。本书相当全面，偏重理论分析和概念阐释，这些内容和抽象技术对于真正理解UML是非常基本、必不可少的，所以它适合喜欢认真探究一切的读者。 
 
用好UML离不开有好的过程作指导。RUP极其丰富的内容令人生畏，Ivar Jacobson大师在《统一软件开发过程》一书中从管理者和系统架构师的角度，通过实例分析系统地讲解了将UML用于分析设计实践的完整过程，深入浅出，言简意赅，可以说此书正是RUP的精华所在。带领自己的团队用好UML，得此书足矣。 
 
此外，IT之源（www.iturls.com）、UMLChina（www.umlchina.com）等网站提供了非常丰富的学习资料和参考文章。 
 
UML规范、《UML参考手册》内容深、篇幅大，主要面向UML工具开发者、专家和研究人员，不适合初学者阅读。 
 

世界上有哪些著名的公司、组织参与了UML标准的制订？ 
 
历年来，参与UML标准制订的一些核心公司和组织包括（1.x、2.0）： 
全能型IT公司：HP, IBM, Unisys 
大型软件公司：CA, Microsoft, Oracle 
CASE厂商：I-Logix, Rational（已被IBM收购）, Telelogic 
电信供应商：Alcatel，Ericsson，Fujitsu，Motorola 
行业组织：OMG 
IT系统集成商：EDS 
等等 
 
UML在业界的影响力和地位由此可见一斑。 
 

感谢您阅读此文！纸质媒体如需转载请与作者联系；本文版权所有者为张恂，保留所有权利；您可以从IT之源上获得本文的最新版本和相关资料；以上言论仅代表作者本人观点，与作者服务的公司无关；欢迎转载本文电子版，转载时请注明出处并保留所有原始信息。
 

1.1 UML基础知识扫盲
 
UML这三个字母的全称是Unified Modeling Language，直接翻译就是统一建模语言，简单地说就是一种有特殊用途的语言。
 
你可能会问：这明明是一种图形，为什么说是语言呢?伟大的汉字还不是从图形(象形文字)开始的吗?语言是包括文字和图形的!其实有很多内容文字是无法表达的，你见过建筑设计图纸吗?里面还不是很多图形，光用文字能表达清楚建筑设计吗?在建筑界，有一套标准来描述设计，同样道理，在软件开发界，我们也需要一套标准来帮助我们做好软件开发的工作。UML就是其中的一种标准，注意这可不是唯一标准，只是UML是大家比较推崇的一种标准而已，说不定以后有一个更好的标准可能会取代她呢!UML并不是强制性标准，没有法律规定你在软件开发中一定要用UML，不能用其它的，我们的目标是善用包括UML在内的各种标准，来提高我们软件开发的水平。
 
UML由1.0版发展到1.1、1.2、...，到现在的2.0、2.x，本书将会以2.x版本为基础开展讨论。网络上、书籍、还有各种UML工具软件，各自基于的UML版本可能会不一样，大家在学习过程中可能会有一些困惑，不过没关系，本课程在某些关键地方会描述1.x与2.x的差异。
 
UML有什么用?
 
有很多人认为，UML的主要用途就是软件设计!也有人认为，如果你不是开发人员，是难以理解UML的。
 
然而我第一次在实际工作中应用UML的却不是软件设计，而是软件需求分析!当时我们和客户面对面沟通调研需求的时候，直接用类图、顺序图、活动图、用例图等UML。我们并没有因此和客户无法沟通，反而是沟通得更加顺畅。客户在我们的引导下，很快就会读懂这些UML图，因为UML图，让我们和客户的沟通效率和效果更好!你可能觉得很神奇，在后续章节中，我将会为你逐一揭开神奇背后的“秘密”。
 
UML可帮助我们做软件需求分析和软件设计的工作，在我工作中大概各占了50%的比例，当然在你的实际工作中不一定是这样的比例。UML会让你的需求分析或者软件设计工作更上一层楼，本书将会介绍UML在需求分析方面的最佳实践。
 
告诉你一个秘密，UML应用于软件需求分析时，其学习门槛将会大大降低!语法复杂度会降低，而且你基本不需要掌握软件开发的知识。只要你对软件需求分析感兴趣，认真学习和应用UML，就很有机会成为软件需求分析高手。
 
UML的分类
 
结构型的图(Structure Diagram)
 
类图(Class Diagram)
 
对象图(Object Diagram)
 
构件图(Component Diagram)
 
部署图(Deployment Diagram)
 
包图(Package Diagram)
 
行为型的图(Behavior Diagram)
 
活动图(Activity Diagram)
 
状态机图(State Machine Diagram)
 
顺序图(Sequence Diagram)
 
通信图(Communication Diagram)
 
用例图(Use Case Diagram)  
 
时序图(Timing Diagram)
 
本书所描述的UML的各种图的名字，以上述的为准。
 
UML各种图的中文译名，因为翻译的原因可能会有所不一样，如：Sequence Diagram和Timing Diagram有时候都会被译成“时序图”，这是最让人困扰的地方!Sequence Diagram 除了被译为顺序图，还有序列图的译法。
 
中国软件行业协会(CSIA)与日本UML建模推进协会(UMTP)共同在中国推动的UML专家认证，两个协会共同颁发认证证书、两国互认，CSIA与UMTP共同推出了UML中文术语标准，该标准全称为：CSIA-UMTP UML中文术语标准v1.0(本书后文将会简称为UML中文术语标准)。本书将会遵循UML中文术语标准，并且我们会同时给出中文译名和英文原名，大家要留意看英文名字噢，这样能帮助你不会被众多的中文译名混淆。
 
UML图为什么会分为结构型和行为型两种呢?
 
顾名思义，结构型的图描述的是某种结构，这种结构在某段时间内应该是稳定的，“静态”的;而结构型的图描述的是某种行为，是“动态”的。
 
分析系统需求时，我们会面对很多业务概念，它们之间会有某些关系，这些内容可以看成是“静态”的，我们可以利用UML的结构性的图来分析。同时，业务会涉及大量的流程、过程等，这些内容是“动态”的，我们可以用行为型的UML图来分析。
 
在我们软件设计时，我们需要考虑需要那些类、哪些构件、系统最后怎样部署等，这些内容可以看成是“静态”的，我们可以利用UML的结构型的图来设计。同时，我们也需要考虑软件如何和用户交互，类、构件、模块之间如何联系等“动态”内容，我们可以利用行为型的图来设计。
 
所谓“静态”和“动态”不是绝对的，下文我们将会进一步介绍结构型的UML和行为型的UML。通过下面的学习，你将会初步认识UML的各种图，你可能还会有很多问题，本章的主要目的是让你对UML有一个宏观的认识，带着你的问题继续阅读后面的章节吧!
 
1.2 结构型的UML(Structure Diagram)
 
类图(Class Diagram)
 
请看下面这个类图：
 
 
图 1.1 某模具系统类图
 
此图截取自某模具管理系统的业务概念分析图，图中一个一个的矩形就是类，这些类之间有各种线条连接，这些线条表示类之间的关系。类图是分析业务概念的首选，类图可能是使用率最高的UML图。
 
再看下面这个Person类图，这时软件设计时用到的一个图：
 
 
图 1.2 Person类图
 
该Person类有以下属性(Attribute)：Name(姓名),Sex(性别),Department(部门)等，有以下操作(Operation)：Work(工作)等。类有属性和操作，但用类图分析业务模型时，往往不需要使用操作，如图1.1中的类就只有属性。
 
Attribute有特性、特征等译法，Operation也称作方法，但本书遵循UML中文术语标准，即Attribute为属性，Operation为操作。
 
对象图(Object Diagram)
 
一般情况下只有在软件开发中才会使用到对象图，下面的内容以开发的角度来说明对象图，如果你没有开发经验，阅读起来可能有一点难度。
 
图1.2中的Person类，用代码实例化如下：
 
Person person = new Person();
 
……
 
类(Class)实例化后就是对象(Object)，对象person是类Person的实例，上述代码可以用对象图表示如下：
 
 
图 1.3 Person类的对象图
 
对象图和类图的样子很相似，对象是类的实例化，“person : Person”表示对象person是类Person的实例。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象，该图只画了一个对象，其目的是尽量简化以便读者的理解什么是对象图。
 
在需求分析工作中基本上不需要使用对象图，从严谨的角度来看某些情况下应该使用对象图，但我往往还是会用类图来处理，这样更加简便而且容易理解。我们将在类图一章再次讲解对象图。
 
构件图(Component Diagram)
 
构件图也叫组件图，两个名字均符合UML中文术语标准。
 
一辆汽车由轮子、发动机等物理部件组成，一个软件往往也是由很多“物理部件”(如：控件、重用构件等)组成的，构件图就是用来描述软件内部物理组成的一种图。下图是某权限构件设计图：
 
 
图 1.4 某权限构件设计图
 
图1.4右上方有这样标志 的矩形表示一个构件，构件可以再包含构件。
 
软件需求分析工作中，需要用到构件图的情况不是很多，以下情况除外：
 
1. 待开发的系统需要与第三方的系统、原有系统、某些老系统等交互，这时可用构件图描述交互要求。
 
2. 客户对软件设计有某些特殊要求，这时可用构件图来描述要求。
 
构件图有时不会单独使用，还会和部署图一起结合使用。
 
部署图(Deployment Diagram)
 
部署图是用来描述系统如何部署、本系统与其他系统是怎样的关系的一种图，如下图：
 
 
图 1.5 某24小时便利店的管理系统部署图
 
图中一个个立体的矩形是部署图的“节点”，一个节点表示一个物理的设备，节点之间的线条表示节点间的物理连接关系。
 
大部分客户都会具备一定的IT基础环境(如具备局域网、一些服务器、某些软件平台等)，软件系统需要基于当前的IT基础环境来规划，这时我们可以使用部署图来做这个规划。
 
分析系统的需求，不能忽略系统架构、部署、IT架构等方面的要求，我们要基于客户当前的IT基础环境，做一个最符合客户利益的规划。
 
要活用构件图、部署图来分析需求，需要具备一定的IT基础架构知识和软件设计知识，如果你还不具备相关知识，那么可以考虑抓紧补充相关知识。不过需求分析工作更多的还是分析业务，提炼功能性需求，这部分工作能做好是相当不容易的事情。对于技术方面的非功能性需求分析，可交由有技术背景的专业人士负责。
 
包图(Package Diagram)
 
Package有“打包”的意思，包图的主要用途是“打包”类图。用类图描述业务概念时，很多时候会因为业务类太多，而导致类图非常庞大，不利于阅读，这时可以将某些类放入“包”中，通过包图来组织业务概念图。
 
下图是包图的一个示例：
 
 
图 1.6 包图
 
图中好像文件夹样子的就是一个“包”，包之间的线条表示包之间的关系。
 
1.3 行为型的UML(Behavior Diagram)
 
活动图、状态机图、顺序图处于三种不同的角度来描述流程，是分析业务流程的三种不同利器，下面将会逐一说明。
 
活动图(Activity Diagram)
 
我们将起床到出门上班这个过程画成活动图，可能是这样的：
 
 
图 1.7 起床到出门上班的活动图
 
活动图中的一个圆边框框表示一个“活动”，多个活动之间的带箭头线条表示活动的先后顺序，该图只是表达了一个顺序流程，活动图还可以表达分支结构。如果你以前曾学过流程图的话，你会发现活动图和流程图很相似。活动图可能是三种能表示流程的UML图中最接近我们思维习惯的一种，下面来学习另外两种能表达流程的图。
 
状态机图(State Machine Diagram)
 
状态机图又叫状态图，但状态图这个译名并没有译出Machine的意思。
 
状态机图从某个物品的状态是如何变化的角度来展示流程，下图某请假条审批流程：
 
 
图 1.8 请假处理流程
 
整个请假审批流程是围绕“请假条”这个物体进行的，随着不同的审批阶段，请假条具备不同的状态。我们分析业务流程时会发现很多流程其实是围绕某个物品进行的，这时可考虑使用状态机图。
 
顺序图(Sequence Diagram)
 
你去餐厅吃饭，向服务员点餐到服务员送菜上来，这个过程用顺序图可表示如下：
 
 
图 1.9 点菜的顺序图
 
该图有三个“小人”，每个“小人”下面的文字说明(如：顾客)表示其代表的角色。角色与角色之间有一些线条链接，表示角色之间是如何交互的。该图表示的意思是：顾客向服务员点菜后，服务员将点菜信息传递给厨师，然后厨师做菜，最后再由服务员送菜给你。
 
点菜过程涉及几个环节，每个环节均由不同的角色来负责，如果遇到类似的情况，你可以考虑使用顺序图来分析。用顺序图来分析的好处是能清晰表达整个过程所参与的角色，角色与角色之间的关系，各角色是如何被卷入这个过程当中的。
 
通信图(Communication Diagram)
 
UML1.1时，该图英文名为Collaboration Diagram;UML2.x时，英文名为Communication Diagram。将英文名字直接翻译，原来的英文名字可译为协作图，而新的英文名字译为通信图。
 
通信图是顺序图的另外一种画法，点菜的顺序图，如果用通信图来画可表示如下：
 
 
图 1.10 点菜的通信图
 
三个“小人”分表表示三种角色：顾客、服务员、厨师;角色之间有直线联系表示他们之间有关系;带序号的文字和箭头，表示角色之间传递的信息。
 
顺序图更强调先后顺序，通信图更强调相互之间的关系。我觉得顺序图实用性更好一点，比通信图能表达更多的信息，更容易读懂，在需求分析工作中我基本不会使用通信图。
 
用例图(Use Case Diagram)
 
下图是用例图的示意图：
 
 
图 1.11 用例图
 
用例图表达的是什么角色通过软件系统能做什么事情，我们可以使用用例图系统地表达软件系统的绝大部分需求。
 
时序图(Timing Diagram)
 
时序图也叫时间图，时序图是UML中文术语标准的说法，而时间图不是标准的说法。
 
时序图是表示某东西的状态随时间变化而变化的一种图，参见下图：
 
 
图 1.12 灯的开关状态随时间变化图
 
此图表示在0秒到30秒，灯的状态是关的，30-60秒灯的状态为开，60秒后状态为关。
 
在实际工作中我基本上没有试用过时间图。
 
下面通过这个表格来总结一下我在需求分析工作中应用各种UML图的情况：
 
 
表 1.1 各种UML图实际应用情况
 
上表是根据我的工作经验总结的，相信会适用于很多情况。但每个人的工作经历、情况、环境等不太一样，上表仅作参考。
 
1.4 如何学好UML?
 
UML的认识误区
 
误区一：认为UML主要用于软件设计。
 
前面的文章你可以看到，UML除了用于软件设计，还能用于需求分析，而本书就是专门来说明如何在需求分析工作中活用UML的。
 
误区二：客户无法理解UML，在需求分析中应用UML实际意义不大。
 
我还不熟悉UML时，确实也有这样的怀疑，而实际工作中发现UML恰恰成为与客户沟通的良好桥梁!UML其实不难读懂，只要稍加解释客户马上就能读懂。我在所有的项目需求分析工作中，都直接使用UML图与客户沟通，并且给客户签署的需求规格说明书中含有大量的UML图。
 
UML能直观、形象、严谨地描述出业务概念、业务流程、客户的期望和需求，只要稍加引导客户，客户将会很容易读懂UML，甚至会主动使用UML与项目组交流。我曾经遇到过客户向我们索要画UML图的工具，客户见识过UML的威力后，也想在自己实际工作中使用。
 
误区三：认为UML语法繁杂，难以学习和应用。
 
某些UML资料和书籍可能将UML说得过于复杂了，官方的UML标准资料也确实是枯燥难懂、人见人晕。我刚开始学习UML时，也看过一些UML书籍，觉得UML的语法太多、太复杂、太容易混淆了!
 
在实际工作中，其实经常需要用到的UML语法并不多，而且很容易掌握。当我们在需求分析方面应用UML时，需要掌握的语法更少(在软件设计方面应用UML时需要掌握稍多一点的语法)。“二八原则”在这里完全适用，我们经常用到的UML语法，其实只占全部语法的20%，而本书将会重点介绍实用性强的UML语法。
 
误区四：UML用途不大。
 
很多人推崇UML，但也有不少人士不太认可UML。不认可的原因主要是因为一些人士学习UML后，发现在实际工作中发挥的作用并不是很大，有时候不用UML效果更好。
 
我不敢说UML能帮助我们解决所有问题，至少从我的多年使用经验上来说，UML对于提升我的需求分析能力帮助还是很大的。有人之所以感觉UML不太好用，我觉得原因还是只掌握了UML的形而没有领会UML的神。UML的常用语法可能几天就能学会了，而要真正做到“thinking in UML”却没有这么容易，需要长期的锻炼。
 
我的学习经历
 
我读大学时没有听说过UML，出来工作两三年后才开始接触UML，当时的感觉就好像找到了新大陆，很想好好发掘一番!而我当时的运气还是相当不错的，我的上司是UML达人，他带领我参加了项目的需求分析工作。我很快就见识了UML威力，在他的言传身教之下，迅速掌握了UML。
 
在那个项目以后，我便独立担当了多个项目管理及需求分析工作，没有一个项目不应用UML，而且我毫不保留地传授UML知识给项目组的其他成员。多年的工作进一步磨练了自己，对UML在实际工作中的应用有了更深刻的认识，形成自己的一套方法。
 
我的UML知识绝大部分来自于工作实践，期间虽然也看过一些书籍，但对我的帮助很少。当然我最大的得益还是来自我的UML启蒙老师，他在实际工作中教会了我UML，帮助我踏上自我成长的道路。
 
我的UML学习最大体会就是：实践太重要了!如果有名师指导则会让你事半功倍!希望本书能成为你在实际工作中学习和应用UML的好帮手!
 
UML学习难点
 
学UML之难，不在于学习语法，关键是要改变思维习惯。UML是一种新的工具，但同时也是代表了一种新的先进的思考方法，如果不能掌握这样的方法，只能学到了UML的形，而没有掌握其神髓。
 
要用好UML，你需要在平时多多培养下面的能力：
 
1. 书面表达能力。
 
2. 归纳总结能力。
 
3. “面向对象”的思维能力和抽象能力。
 
平时你可以利用各种机会来提升第1和第2种能力，如多写写项目文档、写写日记或博客等，多思考和总结平时自己的工作得失等。
 
第3种能力说起来有点虚，大家在大学中可能也学过相关知识。训练这种能力的最好方法就是多应用类图，我们将会在类图的章节再重点介绍，通过实例来体会什么才叫“面向对象”!
 
本书将会重点培养你的这三种能力，只要你有进步之心，多练习、多实践、多思考、多总结，一定会取得长足进步!
 
1.5 小结
 
本章的主要目标是让你不需要阅读全书的情况下，就可以了解到UML的全貌，大概知道UML各种图的用途，同时给你说明学习UML的难点，为最终活用UML做好准备。下面我们一起来复习一下本章的主要内容：
 
UML是Unified Modeling Language的简称，是软件开发界的一套标准，UML不仅可用于软件设计，也可以用于软件需求分析。但UML并不是强制标准，我们应该善用包括UML在内的各种标准来提高我们的水平。
 
UML可分为两类：结构型、行为型，结构性的UML有：类图、对象图、构件图、部署图、包图，行为型的图有活动图、状态机图、顺序图、通信图、用例图、时间图。
 
类图是业务概念模型分析的有利武器，也是面向对象分析能力的强有力训练工具。
 
对象图在需求分析工作中并不常用。
 
构件图、部署图是分析IT基础架构、软件架构等方面需求的有利分析工具，但需要你具备IT基础架构、软件设计方面的知识和经验。
 
包图可用来组织类图，在需求分析工作中应用的机会不是很大。
 
活动图、状态机图、顺序图是分析业务流程的强力武器。活动图的表达思路与流程图很类似，很容易掌握，而且大部分情况下都可以使用活动图来分析业务流程;某流程如果是围绕某个物品进行，该物品在流程中转换多种状态，那么使用状态机图来分析是首选;用顺序图来分析的好处是能清晰表达整个过程所参与的角色，角色与角色之间的关系，各角色是如何被卷入这个过程当中的。
 
通信图可以看作是顺序图的另外一种表达形式，顺序图更强调先后顺序，通信图更强调相互之间的关系。而从我的工作经验看，顺序图更加实用一点。
 
有人会将用例图称作“公仔图”，用例图表达的是什么角色通过软件系统能做什么事情，我们可以使用用例图系统地表达软件系统的绝大部分需求。
 
时间图是表示某东西的状态随时间变化而变化的一种图，我在实际工作中很少有机会能用到这种图。
 
学UML之难，不在于学习语法，避免陷入UML的认识误区，多练习、多实践，培养良好的“think in UML”思想，锻炼面向对象分析的能力，成为活用UML的需求分析高手不远矣!
 
用例图实践：https://edu.csdn.net/course/play/2086/32567
 
活动图实践：https://edu.csdn.net/course/play/2086/32569
 
状态图实践：https://edu.csdn.net/course/play/2086/195362
 
软件工程实践者的研究方法视频教程： https://edu.csdn.net/course/detail/2086

来源：绘制UML各种图详解_私房菜-CSDN博客_uml图
 
 
 
一、前言
 
在软件开发过程中会经常整理文档，不是所有的信息都可以通过文字来表达，而换成图之后会更加的直观、有效，其中频繁使用的就是UML图。结合自己实践总结一下，希望对大家都能有所帮助。
 
 
本文中的UML图都是用visio 绘制，source code展示是Java 语言。
 
 
 
二、UML简介
 
Unified Modeling Language (UML)又称统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。 面向对象的分析与设计(OOA&D，OOAD)方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。
 
 
UML图包括两个范畴：结构图和行为图。
 
结构图的目的是显示建模系统的静态结构。它包括类、组件和对象。例如UML静态结构图。
 
行为图的目的是显示系统中对象的动态行为。它包括对象的方法、协作和活动之类的内容。例如UML示例图、UML活动图、UML序列图。
 
 
 
 
三、UML类图
 
通过UML类图可以将类之间的所有关系（泛化、实现、关联、聚合、组合、依赖）都能具体的体现出来。
 
1、类图的表示
 
类的 UML 表示是一个长方形，垂直地分为三个区，如下图所示。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
 
 
顶端是类名，中间列出的是类的属性。底部列出的是类的操作。在绘制类图的时候，顶端部分是必须的，其他两个部分可选。
 
类名：如果是抽象类，采用斜体。
 
类属性列表：可见性 + 属性名 + 冒号 + 属性类型 + （等号 + 默认值）
 
属性的可见性下面会说明；属性的类型看属性而定，可以是int，可以是boolean；有的属性可能会有默认值，在类型之后加等号和默认值。
 
类方法列表：可见性 + 函数名 + (参数列表) + 冒号 + 返回值类型
 
可见性：
 
 
标志
可见性类型
+
public
-
private
#
protected
~
package
 
2、继承的表示
 
 
为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的单键头（或三角形）的实线指向超类。
 
 
ViewGroup 和 方法onLayout 用的是斜体，说明ViewGroup 是抽象类，方法onLayout 是抽象的。
 
 
3、接口的表示
 
一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”。
 
 
对于接口，如果用<< 和 >>将字符串interface包起来，表示这是个接口类。并且用虚线带三角形的箭头从实现类指向Interface 类。
 
 
4、关联的表示
 
（1）双向关联
 
在两个类之间用实线连接，表示两个类彼此都知道它们之间的联系。
 
 
在实线的上端写上关联关系，例如 has；在实线的下端写上可能的多重值，多重值表示如下：
 
 
表示
含义
0..1
0个或者1个
1
只能1个
0..*
0个或者多个
*
0个或者多个
1..*
1个或者多个
3
只能3个
0..3
0至3个
3..13
3至13个
（2）单向关联
 
单向关联是用一个实线带一个开放的箭头，表示一端知道箭头指向的另一端。
 
 
上图中View 中包含Canvas 类，而Canvas 中不需要包含View。
 
 
5、聚合的表示
 
聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。用一个带空心的菱形的实线表示，菱形指向的是整体的类。
 
例如，汽车和轮子的关系：
 
 
聚合与单向关联的区别在于：单项的关联可能只是一个简单的“包含、引用”关系，关联和被关联类之间在逻辑概念上不一定有紧密的联系，而聚合则不同，它表示的是一种内在关系紧密，相互依存，相互包含的概念，其中的一部分是构成另外一部分的不可或缺的成分。
 
 
6、组合的表示
 
组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。
 
用一个带实心的菱形的实线表示，菱形指向的是整体的类。
 
组合跟聚合有很大的不同，聚合的部分的生命周期独立于整体，整体结束那不影响部分。而组合是部分的生命周期依赖与整体，整体结束，部分没有必要存在。就想公司和部分，公司都不存在了，那部门就没有存在的必要了，解散了算。
 
同样用View 为例：
 
 
其中的DeclaredOnclickListener 类是View的一部分，而且是依赖View的生命周期。
 
 
7、依赖的表示
 
依赖（Dependency）关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系，大多数情况下依赖关系体现在某个类的方法使用另一个类的对象作为参数。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。
 
 
依赖关系通常通过三种方式来实现：
 
将一个类的对象作为另一个类中方法的参数
在一个类的方法中将另一个类的对象作为其对象的局部变量
在一个类的方法中调用另一个类的静态方法
 
 
关联关系、聚合、组合之间的区别：
 
关联关系跟突出的是has，只是has的关系，可以通过这一层关系调用到另一个对象中的某个方法。
 
聚合、组合更突出“整体-部分”的关系，不单单是“拥有”，部分类是构成整体类的一部分。
 
对于聚合、组合，区别就在于部分类的生命周期如何，如果部分类还可以独立存在，那属于聚合关系；如果部分类不能独立存在，那属于组合的关系。
 
 
 
 
 
 后话：
 
今天看到@fix_bugs 朋友的热心留言，还是很有感触了，技术是没有界限的，大家只有将好的东西分享出来，我们效率才会更高，技术才能更强大，祖国才会更强大。 因为viso license 的问题，我目前大部分用drawio，Flowchart Maker & Online Diagram Softwarehttps://app.diagrams.net/ 推荐大家使用！！ 大家有什么好的，也请不吝分享出来，感谢！！