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