学习完UML的九种图之后，将其总结出来，首先来一张总图：
以上是视频中介绍的层次结构图，根据我自己的理解，设计了下图：
一、用例图：用户角度描述功能，强调功能执行者，系统为执行者完成那些功能
开始我按照自己的思考，将所有的用户、所有的用例都画在了一起，真心的很大、很乱，再加上刚开始画图就有一种抵触的冲动了，就让旁边的师傅给我说了说，她建议我将这些分开，并且理解每一个图的用意......
带着师傅给的思绪，我又开始了我的画图之旅，如上图，我的部分用例图，这样清楚多了，还有，另一个师傅验收的时候告诉我，其实管理员在工作的时候联系到的一般用户和操作员没有必要画上去，如果画上去在修改的时候需要都修改。
我的理解是，要是画上去了更能体现用例联系的用户。
二、包图：把语义上相近的可能一起变更的模型元素组织在同一个包中，便于理解复杂的结构关系
由定义可知包图的作用，上图是我根据自己的理解画的包图，对于包图理解一下定义就知道它有什么作用了，另外对于包图，我下面的类图中也有涉及到。
三、类图（定义系统的类，描述类的内部结构和类之间的关系）
画类图的时候主要有两个困难点1.对于事物的抽象2.对于粒度的把控（关于粒度，我搜到了九期师哥，周响的CSDN：http://blog.csdn.net/leimengyuanlian/article/details/8581191）。
开始我画的类图只有用户类（管理员、操作员、一般用户、学生）和卡类，粒度太大，对于事物的抽象不明确，方向不准。
师傅给我讲解：对于机房收费系统可以分为三类：1.每个窗体都是一个类，窗体宽、高为属性，执行的功能为方法；2.数据库中每一表为一个类，每个字段是属性；3.具有整体关系的模块为一个类，如查询。
师傅给讲解之后感觉明白了许多，但是还是要在实践中去加深自己对于知识的理解。
四、对象图（类图的实例，系统具体时间的对象以及关系）
这个很好理解的，将上面的类图对应的每一个类实例化，赋予一个特定的值之后就成了对象图了。
五、构件图：代码构件物理结构，各部件之间的依赖关系
这个也很好理解的，我开始的时候也是不知道要画点什么，于是就在网上搜，同时也看了书中的介绍，终于茅塞顿开，构件图用一句话概括就是：“将与系统有关系的内部或者外部控件、文档和系统关联在一起就构成了构件图”，怎么样，是不是很容易理解？
六、部署图：硬件的物理体系结构，实际硬件之间的联系
部署图，就是将所有用到的硬件设备与系统产生的联系画出来。
七、状态图：类的对象所有可能的状态以及事件发生时状态的转移条件
画这个图的时候首先考虑一下有哪几种可能的情况，将所有可能的情况按照顺序把对应的状态描述出来，再加上关联符。
八、活动图：描述满足用例要求所要进行的活动以及活动间的约束关系
其实这个就和当时写文档的时候那个逻辑流程图一样，只不过多了一个开始和结束，这个需要强调的是一定要将所有可能发生的情况都画在图上，比如：输入账号的时候只能输入三次。
九、顺序图：交互顺序，消息传递时间顺序，发送顺序，交互过程
这个图需要注意的是流出信息必须对应一个返回信息，还有就是，如果需要重复输出类似的数据时只需要些一个就可以了，比如：登陆窗体，输入账号的时候，只写一个输出判断就可以了。
十、协同图：对象合作关系，消息的传递
这个只需要写完顺序图的时候轻轻按下F5即可实现此图，需要注意的是，用这个图可以判断是否输出了相同类型的数据，如果卡号和充值金额输出了两次，它们就会在同一个方向上叠加到一起！
总结：
在学习UML过程中，遇到了很多问题！
1.有了问题不可怕，先自己去总结，自己去查相关的书籍以及内容，一定要有一些自己的见解。
2.然后再带着自己的疑问去问同学或者师傅、对于一些问题有必要多问几个人，形成一个统一的观点，在问的过程中一定要细细品味对方是如何考虑的，是从哪方面入手的，这样以来可以让自己以后再思考问题的时候可以多个思路。
3.最后自己将那些知识点和思考方式进行总结，形成自己可以接受的熟悉的生活习惯，然后坚持下去。
个人感觉：学到一点知识不太重要，关键是学习到思考这点知识的方式，以及遇到一些陌生或者熟悉的知识我们如何运用以前旧有的知识将它串联起来，形成很多的关联点，这才是学习知识的真谛吧?
