机房收费系统--活动图

         活动图（Activity Diagram），用来描述系统的动态行为。描述系统动态行为的还有状态图，顺序图（时序图），合作图（协作图）。

        活动图阐明了业务用例的工作流程，所以它是根据用例图来画的，每个用例画个活动图。但是活动图适合描述在没有外部事件触发的情况下的系统内部的逻辑执行过程；否则，状态图更容易描述。而且活动图适合描述多线程，并行活动。

       对了，想起来，在UML9图种，加上包图共10种图中，比较重要、常用的是用例图，类图，顺序图和包图。其他图只要求会画。活动图是在需求分析阶段画的，概要设计阶段细化。

       这是一个基本的活动图。

        分析一下：从上到下，重要的说，重复的不说。包含起始状态Start State（只能有一个），活动状态Action States，，判定（分支，合并）decisions，同步条（分支，联接）synchronization bar(同步条要成对出现)，终止状态End State（可以有多个）。还有就是带箭头的实线，状态之间的转移transitions。

         活动图还有一种画法是用泳道。泳道可以将活动图中的活动进行分组，描述对象之间的合作关系。所以画泳道的时候要知道什么角色完成什么活动。

 

            下面介绍我画的活动图。 由于分析的时候没有分析清楚，我的活动图不是针对用例画的，而是对象化的。也就是每个类都实例化了一个对象，然后每个对象画了一张活动图。我抽出来的类是Student，User，Form和Table。 

       这个是Form类的实例查看学生余额窗体，正好也是我的一个用例。

            其他的就不贴了，然后我还画了一幅带泳道的活动图。是根据这幅改的。

       画的时候对这些活动应该属于哪个角色我不是很清楚。我也是不很清楚，上面的分组到底是根据角色还是类。

       然后查了查，发现，UML动态建模中活动图告诉你发生了什么,但没有告诉你该项活动由谁来完成。在程序设计中，这意味着活动图没有描述出各个活动由哪个类来完成。泳道解决了这一问题。它将活动图的逻辑描述与顺序图、合作图的责任描述结合起来。泳道用矩形框来表示，属于某个泳道的活动放在该矩形框内，将某个特定的类的类名放在矩形框的顶部，表示泳道中的活动由该类负责。
       所以活动图的泳道是根据类来分组的。然后下面的系统就是表示Form，用户是User，学生是Student。

       尽管注册和充值都算是学生的行为，但是是由系统的注册和充值功能来完成的，而且学生不能使用这个系统，是由学生告诉教师信息，然后教师负责注册，充值的。不过上机和下机到底是不是学生完成的，我就联系了咱学生的图书馆上机，上机和下机都是自己的行为。所以把上机，下机归到学生行为中。

       活动图就是上面的这些了！后面会分析活动图，状态图，顺序图和协作图的区别!