欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

我们应当怎样做需求分析:行动图和状态图

程序员文章站 2022-05-19 08:57:40
...
前面,我们耗费了大量的篇幅来讨论用例分析及用例图。用例图,无疑是功能分析、角色分析,以及流程分析的利器,它将我们要开发的系统,清晰而详尽地描述出来。但是,正如任何事物都有两面性,用例图也不例外,也有自己不利的一面。在我看来,这集中体现在两个方面:只见树木不见森林、不生动形象。

什么叫“只见树木不见森林”呢?就是说,用例说明中对业务流程的描述,过早地将系统的整体流程,分散到了各个用例中了,丢失了对业务流程的整体描述。不生动形象,则是说用例说明中对流程的描述都是用枯燥无味的文字来表述的,缺乏生动形象的图形表示。针对这些不足,UML的另外两种视图,可以有效地弥补用例图的缺陷。它们就是行动图与状态图。

行动图(Active Diagram),比较类似于我们过去绘制的流程图,是UML中描述流程与分支的视图。在行动图中,往往是从一个实心圆的起始节点开始的。最频繁使用的则是活动节点了,它表示的是业务流程中的一项活动。活动节点可以表述为一个活动短语(如下订单),可以表述为一个表达式(如len=a.length+x),还可以表述为一个消息(如send(msg))。同时,将各个活动节点连接起来的一个个实线箭头,表明了各种活动之间的流转顺序。

我们应当怎样做需求分析:行动图和状态图
            
    
    博客分类: 需求分析 需求分析流程分析行动图状态图 

在各种业务流程中,毫无疑问会有许多的分支。在行动图中,分支用一个菱形来表示。一个指向菱形的箭头,表示流程进入分支,另外两个或多个从菱形伸出的箭头,则表示不同条件下的分支流。而菱形本身,则表示为一个条件判断语句。

另外,业务中的各个流程还会分岔与汇合的情况。分岔,表示在某个时间点上,同时开始两个业务流程,这两个业务流程是同步进行的。分岔用一个入箭头,一根横杠,与两个出箭头表示。汇合,则表示,只有在两个流程都完成的情况下,才会进入下一流程,否则只能等待。
汇合则用两个入箭头,一根横杠,与一个出箭头表示。

最后,用一个或多个带环的实心圆,表示的是活动图的终止节点,代表了业务流程的终结。以上这些元素,就组成了一个基本的活动图。然而,基本的活动图还不能完整的反映我们的业务流程,因此我们还需要在基本活动图的基础上增加元素。现在我们来看看泳道与业务对象流。

我们应当怎样做需求分析:行动图和状态图
            
    
    博客分类: 需求分析 需求分析流程分析行动图状态图 

如图就是一个带泳道的活动图,图中每个泳道代表一个参与者的业务操作,而整个图形表述了多个参与者间的协作过程。起初我比较爱绘制这样的活动图,但后来常常感到绘制泳道是一件比较繁琐的事情。既然如此,我们就改改吧。

我们应当怎样做需求分析:行动图和状态图
            
    
    博客分类: 需求分析 需求分析流程分析行动图状态图 

这张图才是我最爱使用的行动图。图中,将参与者由繁琐的泳道改为了用例图中的小人。同时,在这张图中还增加了对象流与对象。图中,自动考核结果、申辩申请单、调整后考核结果,都是数据对象,是该流程中相关环节操作的结果。从活动节点指向对象的虚线箭头,则表示了一个对象流,如“申辩申请”活动指向“申辩申请单”的虚线箭头,表示了申辩申请活动的最终结果是产生申辩申请单;从“调整后考核结果”指向“过错追究”的虚线箭头,表示过错追究活动读取了调整后考核结果。

当然,活动图还有其它的元素,但我个人认为其实并不实用,使用以上元素就足以表述我们的业务流程了。活动图打破了子系统与子系统的壁垒、用例与用例的壁垒,使我们能够从整体上了解整个系统的流程,因此常常使用在对整个系统的概述、对整个子系统的概述,以及对整个功能模块的概述中。同时,与其它视图一样,活动图也应当有它的文字说明,以便对图中的每个活动节点、分支进行描述。但对于一些流程相对简单,甚至没有什么流程的查询报表类功能模块,绘制它们的活动图则显得有些牵强附会,因此我们要灵活掌握。

除了活动图,我们似乎对需求的描述还缺少点儿什么,那就是对关键对象中流程中状态变化的描述,在这种情况下,我们的状态图就上场了。

在使用状态图时,一个非常关键的概念就是,一定是对某个关键对象的状态变化的描述,而这些状态变化一定是在某个业务流程的大背景下进行的。下图是一个疑点数据整个生命周期的状态变化图。图中,与行动图一样,一个实心圆点代表的是流程的开始,圆边的方框代表的是对象生命周期中的各个状态,状态节点间的实线箭头代表的是状态的切换,箭头的文字描述是触发状态切换的事件。与行动图一样,状态图可以有分支、分岔、汇合,并最后以一个或多个带环的实心圆结束,代表对象生命周期的终结。

我们应当怎样做需求分析:行动图和状态图
            
    
    博客分类: 需求分析 需求分析流程分析行动图状态图 

在需求分析中,状态图并不是必须的,它仅仅出现在你认为需要对某个对象的状态进行说明的时候。

我们应当怎样做需求分析
我们应当怎样做需求调研:初识
我们应当怎样做需求调研:拜访
我们应当怎样做需求调研:研讨会
我们应当怎样做需求调研:需求研讨
我们应当怎样做需求调研:迭代
我们应当怎样做需求调研:需求捕获(上)
我们应当怎样做需求调研:需求捕获(下)
我们应当怎样做需求分析:功能角色分析与用例图
我们应当怎样做需求分析:业务流程分析(上)
我们应当怎样做需求分析:业务流程分析(下)
我们应当怎样做需求分析:用例说明
我们应当怎样做需求分析:查询报表分析
我们应当怎样做需求分析:子用例与扩展用例
我们应当怎样做需求分析:行动图和状态图
我们应当怎样做需求分析:业务领域分析
我们应当怎样做需求分析:原文分析法
我们应当怎样做需求分析:领域驱动设计
我们应当怎样做需求分析:非功能需求
我们应当怎样做需求确认:需求列表
我们应当怎样做需求确认:一个需求列表的实例
我们应当怎样做需求确认:快速原型法
我们应当怎样做需求确认:需求规格说明书
我们应当怎样做需求确认:评审与签字确认会

(续)