什么叫“只见树木不见森林”呢？就是说，用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失了对业务流程的整体描述。不生动形象，则是说用例说明中对流程的描述都是用枯燥无味的文字来表述的，缺乏生动形象的图形表示。针对这些不足，UML的另外两种视图，可以有效地弥补用例图的缺陷。它们就是行动图与状态图。
行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。在行动图中，往往是从一个实心圆的起始节点开始的。最频繁使用的则是活动节点了，它表示的是业务流程中的一项活动。活动节点可以表述为一个活动短语（如下订单），可以表述为一个表达式（如len=a.length+x），还可以表述为一个消息（如send(msg)）。同时，将各个活动节点连接起来的一个个实线箭头，表明了各种活动之间的流转顺序。
在各种业务流程中，毫无疑问会有许多的分支。在行动图中，分支用一个菱形来表示。一个指向菱形的箭头，表示流程进入分支，另外两个或多个从菱形伸出的箭头，则表示不同条件下的分支流。而菱形本身，则表示为一个条件判断语句。
另外，业务中的各个流程还会分岔与汇合的情况。分岔，表示在某个时间点上，同时开始两个业务流程，这两个业务流程是同步进行的。分岔用一个入箭头，一根横杠，与两个出箭头表示。汇合，则表示，只有在两个流程都完成的情况下，才会进入下一流程，否则只能等待。
汇合则用两个入箭头，一根横杠，与一个出箭头表示。
最后，用一个或多个带环的实心圆，表示的是活动图的终止节点，代表了业务流程的终结。以上这些元素，就组成了一个基本的活动图。然而，基本的活动图还不能完整的反映我们的业务流程，因此我们还需要在基本活动图的基础上增加元素。现在我们来看看泳道与业务对象流。
如图就是一个带泳道的活动图，图中每个泳道代表一个参与者的业务操作，而整个图形表述了多个参与者间的协作过程。起初我比较爱绘制这样的活动图，但后来常常感到绘制泳道是一件比较繁琐的事情。既然如此，我们就改改吧。
这张图才是我最爱使用的行动图。图中，将参与者由繁琐的泳道改为了用例图中的小人。同时，在这张图中还增加了对象流与对象。图中，自动考核结果、申辩申请单、调整后考核结果，都是数据对象，是该流程中相关环节操作的结果。从活动节点指向对象的虚线箭头，则表示了一个对象流，如“申辩申请”活动指向“申辩申请单”的虚线箭头，表示了申辩申请活动的最终结果是产生申辩申请单；从“调整后考核结果”指向“过错追究”的虚线箭头，表示过错追究活动读取了调整后考核结果。
当然，活动图还有其它的元素，但我个人认为其实并不实用，使用以上元素就足以表述我们的业务流程了。活动图打破了子系统与子系统的壁垒、用例与用例的壁垒，使我们能够从整体上了解整个系统的流程，因此常常使用在对整个系统的概述、对整个子系统的概述，以及对整个功能模块的概述中。同时，与其它视图一样，活动图也应当有它的文字说明，以便对图中的每个活动节点、分支进行描述。但对于一些流程相对简单，甚至没有什么流程的查询报表类功能模块，绘制它们的活动图则显得有些牵强附会，因此我们要灵活掌握。
除了活动图，我们似乎对需求的描述还缺少点儿什么，那就是对关键对象中流程中状态变化的描述，在这种情况下，我们的状态图就上场了。
在使用状态图时，一个非常关键的概念就是，一定是对某个关键对象的状态变化的描述，而这些状态变化一定是在某个业务流程的大背景下进行的。下图是一个疑点数据整个生命周期的状态变化图。图中，与行动图一样，一个实心圆点代表的是流程的开始，圆边的方框代表的是对象生命周期中的各个状态，状态节点间的实线箭头代表的是状态的切换，箭头的文字描述是触发状态切换的事件。与行动图一样，状态图可以有分支、分岔、汇合，并最后以一个或多个带环的实心圆结束，代表对象生命周期的终结。
在需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。
我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会
（续）