UML分类
UML(unified Modeling Language)统一建模语言UML除了用于软件设计，还能用于需求分析，在实际工作中UML恰恰是沟通的良好桥梁。UML能直观、形象、描述出业务概念，业务流程，客户的期望和需求。UML官方资料是很枯燥，语法多，实际工作中用到的语法并不多，我本科软件工程，学校开了UML的课，当时并没有很好吸收，工作后重新回顾，我写的的这一系列主要用于需求分析方面。
我们要知道任何工具只是辅助工具，学习UML关键在于改变思维习惯，多锻炼面向对象分析能力。
- UML在实际中分为下面两种类别：
我们可以利用结构型的UML图对客户业务进行结构建模(静态)，利用行为型的UML图进行行为建模(动态)，这些建模活动将帮助我们更好地认识客户的业务和做好业务流程再造的工作。
类图
面向对象
- ”+“ 表示public - 表示private，软件分析不用理会全画成+ 就可以；
- 类图包含类名，属性，操作；
关联关系
如果觉得两个业务概念之间有关系但又不确定具体是什么就可以先画一条线连接起来，为了排版我们也可以用折线；
- x..y 意思x到y个,x < y
- 表示0到多个
- 如果A类有一个成员变量保存的是类B的引用，也就是说类A可以找到类B，需求分析角度来说就是业务概念A可以找到B
包含关系(聚合/组合关系)
空心菱形表示聚合关系，实心菱形表示组合关系，我们用的时候可以用“弱”“强”包含关系来记或者理解；
- “弱”包含指部门没了，员工也还在，或者员工可以有多个部门，”强“包含指部门没了，员工也不在，而且员工只能有一个部门；
- 同样*的用法和上面一样，如果没有表示1；
泛化关系(继承)
学生，老师都”继承“了员工的属性，同时也有自己的属性，可以理解为老师，学生是员工的一种。在实际的软件需求分析工作中，我们往往有两种认识事物的角度，我们以员工、学生、讲师的关系为例子来说明。
- 角度一:在培训现场，我们看到的是学生和讲师，后来你发现，原来讲师是内部员工来的!于是你可以从学生和讲师这两个类出发，发现学生和讲师其实都是员工!
- 角度二:作为这个公司的领导，希望公司形成一一种学习和进步的风气，促进公司的进步，于是领导希望员工之间能互相分享知识和经验。从这个角度看来，领导先想到的是员工，然后再进一步发现员工可以当学生也可以当讲师。
依赖关系
虚线箭头就是依赖（Dependency）关系，说明A依赖B，就像烟鬼依赖香烟。但依赖程度是相对而言，不一定是A没有B就不能“生存了”，具体业务逻辑中，对于某件事情得A需要B的协助才能完成也是一种依赖关系；
”递归“关系
描述文件夹与文件的关系可以如下图
如果是文件夹下的文件夹下还有文件夹呢？
无论是弱包含还是强包含，都可以“自包含”。除了“自包含”可以形成“递归”，其实直线关系同样是可以指向自己的，这个叫“自关联”，这样也形成了“递归”关系
这种“递归”结构，一旦展开就会形成一棵树型的结构。需求分析时如果发现树型的业务结构，你可以考虑使用“自包含”或者“自关联”来分析。其实“自包含”、“自关联”的说法是不严谨的，只是方便记忆和理解，实际上具体的一个文件夹是不会包含自己的。这里我们需要进一一步理解类图中的每-一个类所代表的意义，一个类并不是指具体的一个业务对象，一个类泛指属于这个类的任意一个业务对象。
”三角“关系
当列出公司，雇员至少3个属性，我们就会思考薪金是雇员的关键属性吗？岗位？合同期？公司与雇员在法律上是怎么确立的？那么会想到公司会和雇员签署劳务合同，那这三者是什么关系？
要识别出能表征两个类关系的关联类，难度是有点高，有这样的-些步骤:
- 如果觉得两个类有关系，则先拉上一条直线再说。
- 如果觉得两个类有关系，但怎样画都觉得这个关系不太合适，那么可以思考是不是漏了一个关联类。
- 分别列出这两个类的关键属性，思考这些属性的属性值是不是由该类本身就可以确定了。例如:如果我们最开始将薪金作为员工的属性，那么你可以思考薪金的具体数字，是不是员工自已本身可以确定的?你会发现薪金其实是由公司和员工商定后确定的，并不是员工自已本身可以决定。
-
通过对属性的思考，可能会发现这个属性应该是属于另外-一个类的，思考这个类是不是能表征原来两个类关系的关联类。
image
这个图可能最体现它们的“三角”关系了，关联类也可以表达成这样的方式。但我在实际工作还是以关联类的方式来表达，我觉得关联类的表达方式更加贴切和专业一点。在具体的需求分析工作中，如果发现三个类形成了类似该图的“三角”关系，你可以思考其中一个类是不是可能是关联类，但要注意并不是凡是出现了“三角”关系就一定会有关联类。
类图的最大魅力在于帮助你发掘和提炼业务模型，其他的非UML图可能是做不到的。
