结合机房收费系统对UML的总结
前一段时间学习了软件工程，所以将UML建模和软工做了一个对比（这里没有画出构件图和部署图）：
分析图形：
用例图-----对系统进行需求分析
类图 对象图-----描述系统的静态结构
状态图 活动图 顺序图（又称时序图 序列图） 协作图------描述系统的动态行为
下面就通过机房收费系统具体介绍几种主要的图形
第一个：用例图
理解：
用例图是从用户的角度来看我们所开发的系统。用户关心系统能够提供的服务，也就是系统如何被使用。所以用例图让我们知道哪些参与者与系统发生交互，每一个参与者需要系统为它提供什么样的服务。，通俗一点就是系统能够为使用者完成什么工作，不理会怎么让这个系统完成这个工作（即内部设计）。
涉及的重点：
1. 确定用例：
用例表示系统提供的服务；定义系统是如何被参与者使用；描述参与者与系统之间的对话（对话的细节不再在用例图中表述出来）
确定用例可以从以下问题入手（针对每一个参与者）：
- 参与者为什么要使用该系统？
- 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？
- 参与者是否会将外部的某些事件通知给该系统？
- 系统是否会将内部的某些事件通知该参与者？
2. 寻找参与者：
- 系统开发完成之后，有哪些人会使用这个系统？
- 系统需要从哪些人或其他系统中获得数据？
- 系统会为哪些人或其他系统提供数据？
- 系统会与哪些其他系统相关联？
- 系统是由谁来维护和管理的？
3. 确定用例粒度：
最好将用例模型的规模控制在几十个用例左右，这样比较容易来管理用例模型的复杂度。在用例个数大致确定的条件下，我们很容易确定用例的粒度大小。
a) 对于较复杂的系统，我们需要控制用例模型一级的复杂度，所以可以将复杂度适当地移往每一个用例的内部，也就是让一个用例包含较多的需求信息量。
b) 对于比较简单的系统，我们则可以将复杂度适度地曝露在模型一级，也就是我们可以将较复杂的用例分解成为多个用例。
机房收费系统的一部分用例图：
这张用例图描述的是机房收费系统的账户管理的基本功能。
其中ManageAccount是一级用例，其他用例的就是对ManageAccount用例的进一步分解。
第二个：类图
系统的各个功能是通过对许多类的属性和方法的调用实现的。
所以通过用例图知道了系统的功能之后，就要从这些功能中抽象出类。不同的人会抽象出不同的类
为了减少类和类之间的关系，我采用的是通过功能来抽象类的方法；
抽象出表类来实现查询功能；再抽象出退卡类，注册类，登录类，上机类，下机类，充值类，结帐类，修改密码类来实现相对应的功能
上面是三张抽象出来的表类
上面分别是登录类和修改密码类
类图定义出了对象都具有哪些方法和属性，那么下面的四张图就是来解释这些对象和他们的方法和属性如何被使用以及何时被使用。
描述系统中的对象在执行期间不同的时间点是如何进行动态交互的（即系统的动态行为）
状态图------类图的补充
活动图------从用户角度描述用例
顺序图（时序图 序列图）------从计算机角度描述用例（对象间的交互）；强调时间
协作图------从计算机角度描述用例（对象间的交互）；强调空间
第一个状态图：
描述一个特定对象的所有可能状态，以及由于各种事件的发生引起的状态之间的转移；
描述一个对象在其生命周期的行为，主要强调外部动作的影响。
实际上并不需要为所有类画状态图，只需要为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图
第二个活动图：（由状态图扩展而来）
一种描述工作流的方式
一种描述对象采取何种动作，做什么，何时发生以及在何处发生。
主要强调对象本身状态的变化；描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动
以充值为例子画的活动图；
（交互：一组对象为了实现一些功能而进行通信称之为交互）
第三个时序图：
描述对象之间传送消息的时间顺序，强调对象传递的时间顺序
作用：
寻找类的操作
用对象间的交互来描述用例
以退卡为例子画的顺序图
第四个协作图：
描述协作对象间的交互和链接，强调对象结构相关信息
