1.认识
用例图第一次遇到它的时候印象就是一个个的小人，很好看但是有什么卵用，可以用功能描述为什么要画“小人”(用例)，只要配置了相应的权限，系统的任何角色都可以使用任何一个功能点，为什么需求要写成什么角色对应什么用例这种模式。或者要给千千万万的用户分成什么角色。
其实用例图还需要和其他UML图配合使用，才能发挥更大的威力。当然也发现用例图并不是在任何情况下都是作用巨大的，用例图和其他UML图一-样，只是我们可以利用的一种工具。
用例图简单说就是描述系统需求的一种方法，描述什么角色通过什么系统能做什么事情，关注的是系统的外在表现，系统与人的交互，系统与其他系统的交互。概括下就是回答：
- 这个系统有谁在用？
- 这些人通过这个系统能做什么事情？
2.简单语法
- 小人(Actor):
执行者，执行者也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某执行者就行了，对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。图中的小人就是角色，它给了我们一一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
我们在做一个考勤系统时，不会列出好多功能，比较好的方式是先思考什么角色用，思考不同角色对系统有什么需求。
圈圈(Use Case item):
圈圈里会有一段动宾结构的文字，也就是“动词+名词”的方式，这个圈圈里面的文字就是用例，这些用例表明了系统能做什么事情，比如“打卡”，“查看考勤情况”System:
外面的大框框是系统边界，框框上部注明系统名字，系统要发挥作用，靠执行者“穿越”系统边界来使用本系统用例，可以很清晰表达出系统的范围，不过系统范围不好确定。线条(关联)
这条线是角色与用例之间的线条，有箭头的表示执行者与系统交互过程中数据的流向，如果指向用例，说明执行者需要向系统输入数据，指向执行者说明系统要向执行者输出数据。没箭头说明某某执行者能执行什么用例。
描述系统需求喜欢用什么功能、什么模块之类的表达，描述需求会不自觉地用到很多技术用语，这其实是很多技术人员做需求分析工作的通病。要分析好一个系统的需求，首先要搞清楚本系统的目标，然后思考什么角色会用这个系统，这些角色希望通过这个系统完成什么事情，由粗到细地理出细致的需求。用例图语法不复杂,其实用好用例图的关键在于改变需求分析的旧有习惯,要学会从角色入手，从用户的角度来思考他们需要什么，用他们能看懂的语言来表达需求。
进阶
进阶部分不继续写了，就是综合类图到用例中
