唐僧、QA MM与工作流任务数据形式

唐僧与 QA MM

在一个典型的项目团队里，包括了以下几种角色（帽子）： PM（项目经理）、 BA（业务分析师）、 DEV（程序开发者）和 QA（质量保证人员），整个团队的目标是向客户交付价值。

那么，有一天， QA MM来找我，我是开发人员。 MM说，一张图片没有正常显示，我想知道原因，同时想知道你能否修复。我的第一想法是，这不可能，一定是环境的原因。我说，好的，稍等。接下来，我张大嘴巴看到了 MM给我重现的 BUG：本该显示图片的位置一片空白，就像此时我合不上的嘴。这怎么可能呢？我想，这个功能完成的如此之得意，以至于测试用例里的数据都是以我的名字命名的。

几分钟后，或者更长，我叫来 MM，说，找到原因了。

我打开编辑器，光标在源程序的某一行闪烁，我说，最根本的原因在这里。我看到 MM的眼中闪过一丝迷茫。接下来，我却换到另外一个源文件，光标继续闪烁，我说，这里的程序因此受到影响。看得出， MM有点发晕。终于，当我打开第 N个源文件并试图继续讲解时， MM昏过去了。

当 MM苏醒过来时，我在她清澈的双眼中看到了一只清晰的唐僧。

MM肯定感到了不好意思，因为我的讲解中包含了比喻、类推、排比等我力所能及的各种语文知识，看得出，我很努力，我的语文老师也很努力，所以她委婉地说，能不能简单一点？

我想了想，说，测试驱动时测试数据不全导致程序少考虑一种情况。

MM说，能修复吗？

我说，可以。于是故事结束。

就 是这样，当我们执行一项任务时，围绕这项任务必然会产生许许多多的信息，这些信息对于该任务的执行者是必须的，但是对于其他人则不是，有效的沟通往往来自 于简练的表达即只表达对方需要和可以理解的内容，浩瀚的细节只会将真正想表达的内容淹没。其实这里还有这样一层意思：我之所以用这么多的细节信息来淹没 QA，实际上是不太情愿承认程序里有 BUG。 QA想要的结果很简单，是否是程序 BUG，能否修复。而开发人员则往往把自己的程序与自己关联在了一起，认为程序是自己的扩展，程序有 BUG则意味着自己有缺陷。这一关系明显是矛盾的，可是一些团队里开发人员和 QA能够和平相处，而有些团队却势如水火。

那么，对于单个任务而言，需要定义自己的变量，这些变量数据只与该任务相关，只在该任务里可见。典型的工作流应用于任务执行期间的中间数据存储。在文档处理中，一个重要的功能就是需要提供版本管理，在单个任务实例里，办理者能够管理自己处理过的文档版本。

描述

任务能够定义变量，在一个流程实例里，该变量只能被其任务实例所使用。

图 6-2任务级别的数据可见性

如图 6-2所示，我们在任务 B上定义了一个变量 M，此时，在一个流程实例里，只有任务 B的实例才能使用该变量。

实现

存在两种实现方式，一种是如图 6-1所示的，在任务节点定义中声明变量，运行期初始化任务实例的同时初始化该变量并使用； 另一种是在流程定义级别统一声明变量，但是各个任务实例都独立初始化并存储该变量。第二种实现方式在各个任务都需要使用同一语义的变量时很常见，例如各个任务实例都会有参与者，我们在流程定义时声明一个名为 userid的变量，在流程实际执行时，各个任务实例都会独自保存有自己的 userid数据。

6 楼 ronghao 2010-03-13  

comsci 写道

qiandongbo 写道

是不是 就是 工作流之间节点与节点的交流也通过 一些POJO来传递?
比如 我现在 currentActiveInstance——nextActiveInstances,
现在 当前活动实例到下一个(组)工作实例之间所需要交流的参数封装成
ActiveParams,同时 由于可能会流转到下多个工作流实例，为保证相互
之间的数据不受影响,可以设置成 ActiveParamsCopy,获得每一份参数的拷贝，然后分支流转，最后汇聚~

节点与节点之间的数据交换， 我觉得直接用数据库的表格方式直接传递比较简单，当然如果传递的数据格式比较复杂，中间就需要增加变量了。。。

持久化还是在数据库里呢