《技术点滴》- UML与软件系统建模
1 为什么需要UML
网上有几种声音，一种是鼓吹UML万能，能用来建模、用来设计甚至可以自动生成代码。一种批判UML无用，标准冗余而复杂，语言设计繁琐而且有自相矛盾的地方。
但是，无可否认，图纸与大纲是我们整理纷乱头绪的有力工具，也是交流的利器。就像是谱曲需要五线谱，建房子需要蓝图，写小说也要画个人物关系图一样，图表可以起到化繁为简的作用。特别是当遇上要和别人交流时，复杂且庞大的内容对方是很难一下子通过言语或把内容全盘通读后再了解的，这时图表简洁明了的表现方式就体现出了其优势。
你可以从UML的全称 –Unified Modeling Language（统一建模语言）来看出其出来的宏伟的决心，是要统一程序员画图所使用的语言。当然，程序员编程本身就是使用各种语言，所以UML作为语言之上的语言，其定位来身就略显尴尬，导致其规范一再补充补充超级冗余，失去了其化繁为简的目的。
但是在系统架构、软件设计以及程序模块设计或具体的交互场景设计中，UML还是非常好的表示工具。个人觉得，在实际工作中，我们应该利用UML发展这么多年沉淀下来的成果，也就是它建立下来的一些基本上深入人心的用法与语法，然后有选择地避开其中晦涩冗余的部分。在这篇文章中，我将持续总结目前个人用的比较顺手的一些UML工具，一是以备自己后面画图时一时想不起语法，可以像api文档一样参考之；二来是后面丢图给别人时，若有疑问，就权当作是我的图的补充了；然后就是和大家一起学习，有什么不对的地方欢迎大家一起讨论。
2 系统功能描述之用例图、思维导图
在一个系统设计之前，对需求的描述一定是最先的。最简单的，做需求的负责人比如产品经理、项目经理做对项目使用自己的方法进行各方调研、评估、统计、研究、总结等等，然后制作一份需求文档。这份文档通常是用1、2、3章节文字这样描述，然后还有各种1.1、1.2.3.4这样的小节来补充描述，缺点就是不太一目了然。那我们要用图表来快速地让对方了解这个项目的需求、功能，就可以使用用例图、思维导图、结构图等。
注意，只有用例图是UML中的。但是现在思维导图慢慢的流行，我觉得它更简单更直观，是很好的工具。在实际工作中，你可以先使用思维导图在一边思考一边画，瞬间理清自己的逻辑。然后再使用用例图来加强和完善自身的逻辑。
2.1 思维导图、脑图、结构图
思维导图、脑图与结构图虽然名字不一样，作用细究起来好像也不一样，但其实TMD就是一个东西。它们都是一个树型的层级结构，只不过一般更工整更有层级感的我们称之为结构图，更发散的我们称之为导图或脑图。这个图用起来非常简单，现在有很多在线的工具如ProcessOn、百度脑图等，使用起来非常直观，根本无需要多说，比如下面我们用它来构建一个博客系统的模型：
可以看到，思维导图非常的简洁明了，思路清晰，现在很多场合都使用它代替以前各种纷繁复杂的工具了，比如测试的测试用例、描述某系统的架构组成、描述某些技术的分支等。
2.2 用例图(Use case diagrams)
用例图(Use case diagrams)描述了作为一个外部的观察者的视角对系统的印象。强调这个系统是什么而不是这个系统怎么工作, 帮助开发团队以一种可视化的方式理解系统的功能需求。
上面这句话比较具体地概括了用例图的作用了，我们细分下理解，重点在于下面几点：
1.角色(Actor），角色是用例图比较重要的部分，他是系统的真实参与者，也是用例的使用者，用来回答第一个问题：”我们的系统是供哪些人使用“；角色可以继承，派生出的角生拥有或可访问其父角色的功能。
2.用例(Use Case），用例图中的用例当然是重中之重无疑。用例描述的是系统对外提供的功能，这里所说的对外，主要是对角色提供的，而不是我们平常说的对外部客户和内部工作人员。
3. 角色与用例的关系。这个好理解，就是哪些角色可以使用哪些功能；
4. 附加约束。主要是include与extend。这两个的区别什么的你其实不需要太较真，总的来说就是对用例的附加说明，比如”用户”这个角色要使用”发博客”的功能，必须要先”登录”,那“登录”这个动作就是对“发博客”这个用例的附加约束了。
用例图较思维导图更好的是，他离系统的设计实现更近一步。更偏向与实现一点。比如在导图中，你知道你的系统要一个”发博客”功能即可，不需要清楚说明哪些人可以发博客，需不需要登录才能发等等。而用例图可以很好地描述这些系统边界。比如我们来细化上面导图中的博客系统设计。
通过与导图的对比，可以知道他寻系统的描述更细致，比如通过导图我们需要可以知道这是一个博客系统，但可能会误以为是像CSDN或QQ空间一样的博客系统。当我们在用例图中把角色画出来之后，就清楚了，哦~这是一个供博客主自己使用的个人博客系统。
要补充下的就是在UML中，对用例的定义会严谨或者说是苛刻一些，在实际设计当中老实说我觉得无需太较真，只要对你的设计起指导作用，全面不要遗漏，安排合理看起来顺眼则可。
3 类图
关于类图的作用与定义无需多说了，它是直接对面向对象编程的图形抽象。实际上我觉得类图这个东西即重要，但又不太可能做得完美。因为要为你的项目中所有类都画个类图老实说不太可能，而且一般项目需求是常变化的，太完美的类图终究会遭产品毒手改得面目全非。而虽然市面上虽然有些工具可以针对特殊的语言自动生成类图，但是我觉得大都不太实用。所以在实际工程中，我觉得类图最好还是要画，但不需要画得太细，主要需要可以描述出系统大致的构成以及关键的类和他们之间的关系。
3.1 类图的基本组成
类图主要由各种类及它们之间的关系组成，具体可以分下面几种：
各种类型
- 普通类
- 接口
- 抽象类
- 交互类
各种关系
- 继承
- 关联
- 实现
- 聚合
- 组合
下面是一个简单的以个人博客系统为例的类图图示，其中的逻辑可能不是太讲究，主要是出示下各种类图及关系的使用。其中在UML中，类和关系的定义是比较严谨的。我这里同样将之做得更宽松和简单了。比如UML中的组合关系要区分是组合还是聚合，分别使用空心的菱形和实心的菱形，但是老实说，我一直画图画到现在究竟是用空心菱形还是实心菱形都分不清。还有接口、抽象类与实现和继承，我个人觉得真没必要分得那么细，大家在各自的专业中都是有一部分共识的人看图其实稍作区分就可以了。
