jBPM4.3用户指南

---

     摘要: Spring Security-3.x新近发布，整体的项目结构和包名都出现了天翻地覆的变化，与此同时，Spring Security-3.x中也提供了session-management和SpEL的多种强大功能，family168第一时间提供官方文档的翻译版 本，希望同大家一起领略Spring Security-3.x的最新时髦风尚。 介于Spring Security官方文档本身倾向于技术...  阅读全文

你在做软件开发吗？

在启动项目前是否做好技术选型了呢？
在设计前是否已经理顺大体需求了呢？
在编码前是否已经反复思索过对应的设计呢？
在测试前是否已经准备好测试用例呢？
在部署交付前是否已经计划好具体的功能列表呢？

考虑过项目的性质吗？互联网应用，还是内部网应用。
弄清了项目规模大小吗？3人月可以搞定的小项目，还是需要几十人月的长期奋战？
确定团队的实力了吗？是全员光头新人，还是在某牛带领下的小马集团，还是经验丰富的水路两栖冲锋队？
如何与客户协同合作？瀑布式一次理清所有需求，还是需要分阶段迭代，或者直接进驻客户公司面对面开发？

是否要使用框架呢？还是选择最基本的jsp, jdbc应用。
编码与项目如何管理，使用版本控制工具？还是用U盘copy过来，copy过去？
如果选择版本控制工具，究竟哪一款才适合自己的情况？
系统如何划分层次？五层？三层？其他方式？
模块如何划分，按功能？按业务？混合分块？
开发如何分工，横向分工，各层之间接口对接？竖向划分每个人负责从前到后一整块。

如何测试？手工点点，还是使用自动化测试工具。
测试用例如何确定，如何提高测试的有效性。
测试的结果如何反馈给开发过程，需要使用excel还是issue跟踪系统？
测试过程中可以暴露并发，事务等隐性问题吗？
性能测试如何进行，压力指数应该保证到多少？

后期维护的方式的选择。
如何维护数据库表结构？每次exp整个数据库，到客户公司imp，还是找一个员工手工比对所有表结构，还是直接实现数据库版本化管理？
如何为系统打补丁？视图层的补丁，服务层的补丁，依赖库的补丁。如何管理，如何实施，如何测试？
系统是否拥有动态部署的能力？在系统升级的过程中是否可以减小出错的可能？

。。。。。。

还有很多，还有很多。有些问题可以通过技术解决，有些问题需要根据具体条件进行分析，有些需要尽力规避，有些需要硬着头皮强顶硬撑。

在考虑清楚这些问题可能带来的各种问题之前，让软件开发慢下来，至少慢一点点也是好的，进行下一步骤之前先了解如果出现了问题该如何应对，如何解决。

原文地址：http://www.infoq.com/news/2009/12/spring30

同志们，Spring框架的3.0版本终于在今天发布啦。InfoQ特别对话了Spring框架项目的技术头领Juergen Hoeller，从他口中了解到不少关于这次发布对Spring集团带来的改变。

Hoeller详细罗列了Spring 3.0中的各项新特性：

* 基于Java 5 - 目前核心API已经使用了Java 5的特性，诸如泛型、注解等等，因此现在Spring 3.0必须使用Java 5和以后版本才能跑起来。

* Spring表达式语言（SpEL） - 这个和JSF中的统一EL类似，我们可以很容易在Spring 3.0中使用复杂表达式了。

* 提升对基于注解组件的支持 - Spring JavaConfig其中的一些功能已经被迁移到核心框架中，比如@Configuration，@Bean和@DependsOn。

* 可以使用约束注解声明对模型的校验方式 - 提供了对JSR 303的支持，我们可以使用注解为bean添加诸如@NotNull和@Max(23)的校验规则。

* Spring MVC中提供对REST的综合支持 - 添加了在服务器端和客户端使用RESTful应用的功能。

* 提供对Java EE 6的支持 - 支持了许多Java EE 6中的功能，比如JPA 2.0和JSF 2.0，让它们可以运行在非EE 6的容器下，比如Tomcat和J2EE 1.4应用服务器。

* 提供对JSR 330的支持 - 现在Spring已经支持了JSR 330中介绍的javax.inject注解。

* 基于注解进行格式化 - bean的属性可以使用注解来自动进行格式化和类型转换，比如@DateFimeFormat(iso=ISO.DATE)和@NumberFormat(style=Style.CURRENCY)。

Spring还提供了完整的修改日志和参考文档。（译者注：文档方面Spring做的确实太好了，也再次感谢满江红团队的辛勤劳动。）

Hoeller在提到SpEL时，多说了那么几句：

SpEL是一种功能强大的表达式语言，语法基于统一表达式（Unified EL），实际上它与JSF中使用的表达式非常类似。我们特别为SpEL开发了自己的表达式解析器以提供特定的功能，无论是在使用bean定义配置还是使用 Spring Integration这类项目时都可以带来不少好处。其实在Spring核心中已经有很多地方都应用了像"#{...}"这样的表达式，可以在XML的 bean定义中看到许多这样的例子。还有@Value这个注解，它可以通过名称动态引用其他的bean，并且可以非常简单就获取这些bean的属性。

举个例子，下面这段XML配置（来自3.0参考文档）使用了SpEL来配置bean的属性，属性值来自于JVM系统参数：

Hoeller也着重介绍了Spring 3.0中对REST的支持：

我们面对的挑战是在Spring MVC的世界中加入对REST的支持，把这种强大的新功能交到MVC用户的手中。我们决定从底层为MVC支持路径变量的提取 - 这部分内容协商的方向是正确的 - 考虑到Spring MVC的实力，并把它们拉升到另一种层次，同时又不会破坏基本架构。工作进展的非常顺利，可以在已有的Spring MVC应用中使用REST的特性。

我们的重点聚焦在web用户接口在REST下的转换方式上。下一步呢，在Spring MVC的基础上实现基于REST的网络服务（Web Service）也是很有意思的一件事情，特别是OXM（Object/XML Mapping）现在已经成为了Spring核心模块之一，OXM可以和Spring MVC联合应用。最后，我们提供了RestTemplate类，这是一个Spring式的模板类，它作为客户端提供了与面向REST终端服务器进行交互的 更易用的编程方式。

对于那些工作在Spring 2.5之上，并且已经在代码中使用了基于注解样式的同志们，这次升级的路线将是非常平滑的 - 新功能可以在升级到3.0之后任意选择使用，不需要对基础架构进行任何修改。对于那些还在使用老版本，比如继承了表单控制器，这些功能在3.0中还是可以 继续使用的，只是这些功能都已经被标记为“被废弃了”（deprecated）。如果想使用3.0中的新特性，就必须先使用基于注解的@MVC样式。对于 Spring 2.0用户，99%的代码依然可以正常运行，但是对一些老组件的支持，比如Apache Commons Attributes, WebLogic 8.1 和 WebSphere 5.1，都已经被删除了。

当提起Spring框架的未来计划时，Hoeller提到开发会受到Spring集团中的其他项目的很大影响，比如Spring Integration, Spring Web Flow, Spring Source dm Server和Spring Roo等 等。在3.1的发布的新特性就会被Spring Integration 2.0和Spring Web Flow所影响，比如计划中的第一类会话管理（first-class conversation management），扩充作用域（scope）和细化基于注解的组件模型。2010年中旬中的3.1发布之后，会进入3.2版本，对于3.2版本的具 体计划还没有最终完成。

     摘要: 上周六去Beijing OpenParty准备的话题，可惜自己能力有限，拉票没有进入前九名（实际上是倒数第一，只有十个人愿意听这个话题），无缘在活动的正式会议室讲这个话题了。

下来把PDF中存在的一些问题修改了一下，有兴趣的同志可以下载看一下。也再次感谢一下最后在小会议室听我讲这个话题的三个同志。  阅读全文

做企业开发，是业务重要还是技术重要？似乎大多数的声音都在朝向着同一个方面：“业务比技术重要”，“理解客户业务需求更加重要”，“我们要帮助客户梳理需求，项目做到一半的时候，我们已经比客户都懂业务了”。

作为一个搞技术的，我完全搞不清楚这种说法的起源，为什么作为本职工作的“技术”反而不如“业务”重要了呢？这里所说的“重要”是否是说我们只需要抓抓牢最重要的部分就可以解决一切问题了呢？既然所有人都认为业务比技术重要，那为什么公司不直接招聘几个“精通业务的人员”过来培训几天技术就行了呢？为什么反而要招聘原本不重要的“技术人员”，再去临时培训如此重要的“业务”呢？或者说，既然业务比技术重要那么多，为什么我们还要做技术呢？所有人都去搞业务岂不是可以把所有力量都集中在最重要的部分，进而获得更大的效益呢？

听到这种说法，人们又开始议论纷纷：“你这样太极端了，怎么可能完全放弃技术呢？没有技术怎么行呢？”这种说法再正常不过，因为我们的本职工作就是“软件开发人员”，开发人员立足的根本就在于技术能力，所谓的业务问题如果不建立在技术基础之上，就是完全无用的空对空瞎吹而已。对于一个开发人员来说，技术能力是必不可少的，再多“业务”也是无法弥补“技术”上的鸿沟的。

可为什么大多数人还是认为“业务比技术重要的”，首先公司的行为在于盈利，公司只有通过交易行为才能实现盈利，如果我们制作的产品无法满足客户的需求，客户是绝对不会买账的。怎么才能满足客户需求的，首先就要熟悉客户的业务，因此公司就需要一些了解特定方面业务的开发者来实现这些功能，这些公司对技术没有太多要求，只要达到基本水平就可以，所以筛选员工的标准就变成了对业务的熟练程度。

换句话说，大多数公司所需的员工是：“技术水平达到基本要求，对某一行业业务越熟练越好。”所有人对此都不会抱有怀疑，只是在信息不断传递过程中，有意无意中人们隐去了前提部分，只剩下后面的“业务很重要”。

对于一个公司来说，需要的永远不是：“技术最强者。”最有用的人是那些可以使用一定程度的技术，最好满足本行业业务需求的人们。公司不可能为了个人技术方面的渴求去牺牲业务方面的钻研，这已经是生存问题了。双向选择上，如果一个人技术不达标，是没办法通过面试的，如果一个人业务不达标，有可能先进入公司熟悉业务。如果一个人技术太强了，公司留不住也只能放任员工去选择更适合的发展环境，如果业务太强了，结果应该也是一致的。

对于个人来说，如果是一个技术狂热者，也不应该在公司中被技术左右，明辨技术和业务两个方面，结合起来帮助公司创造更大效益的同时才能为自己提供一个有发展的环境。双向选择上，如果自身无法满足公司的要求，是很难进入公司的，如果感觉公司限制了自身发展，也可以考虑是否拥有更多的选择机会。

最后来研究一下技术和业务之间的融合问题，我们可以肯定一点，纯粹的技术是没办法存活的，公司行为必然要涉及到解决哪些问题，纯粹的业务也不是技术人员可以达到的，所以我们期望了解的就是业务和技术如何分配的问题，是五五吗？是三七吗？是六四吗？现在只能说这个问题很难讲清楚，根据不同行业需求的不同，毕竟大多数公司都停留在简单的增删查改阶段，只要开发人员会用jsp的公司也比比皆是，相比专业的软件公司，这些公司的入门门槛低，待遇也低，如果希望在这些公司走得更远，唯一的方法就是在技术之外开辟出新疆界来。你可以搞业务，搞管理，搞客户关系，等等等等。大多数人都是可以适应平滑转型的，但是也有期望在技术上更进一步的同志会进入其他对技术要求更高的公司中。这类公司业务和技术比重大致在7:3到5:5之间，基本属于平常不会遇到解决不了的问题，只要根据客户的需求进行实现即可，不过一但遇到技术上无法实现的功能，便无法自行解决，只能求助于更高级的软件公司。

在大部分公司都与最终用户进行交互时，还是存在着不少公司进行着产品化行为，一方面基于以往项目积累的经验抽象出可复用的组件，另一方面对市场的调研总结，设计出更易用，更成熟的体系结构，这些公司有实力，并且有需求在技术上更进一步。这时也会出现对技术和业务职责上的分化。因为产品化已经深入的某一个特定的行业，对业务的需求分析细化整理都已经十分完善，为了实现更精进的业务，也就需要更精进的技术来作为支持。这些公司需要专精某些技术的员工，可以基于整理后的需求完成业务，同时也需要更加专业的业务分析人员，在业务上进行细化分析，提供给后续论证实现。只不过对于这种业务分析人员，大多也是从原软件开发人员转移过来的，他们拥有十分丰富的项目经验，同时拥有强力的设计能力可以为下面的实现人员提供规划蓝图。归根结底，无论是开发人员或是需求分析人员都是以技术为基础的，没办法，毕竟我们的本职工作是开发。

最后的最后，到底是技术重要还是业务重要呢？我想作为一个技术人员的大家，应该心中有数了吧？

上周六去参加了OpenSourceCamp活动，玩了整整一天时间，感触颇丰啊。

首先是上午到达Intel，来到会议室先找了件合适尺寸的T恤装起来（感谢活动赠送的礼品，谢谢），人不是特别多，所以在中间找到了几个空位坐下。

活动开始前，大屏幕上一直在播放着OpenSource的宣传视频，英语原声中文字幕的，几个老外不断出来讲这个OpenSource到底是如何如何，看到了Linus，接下来又出现了GNU的创始人，讲到OpenSource的出现，它的意义等等，不过留下最深印象的还是，当其中提到了MicroSoft和Bill Gates时，视频的背景音乐突然变成了“鬼子进村”的那种气氛，然后就伴着这种感觉听了几分钟的bill Gates写给开源社区的公开信，信的内容主要是强调软件的知识产权。。。感觉OpenSource和MicroSoft的隔阂还是年代久远啊。

随着视频的戛然而止，活动进入正题，首先由活动的发起人Peter介绍了OpenSourceCamp的历史和未来的发展，然后依次是IBM谈标准规范，intalio对自身的介绍，天使投资人介绍通过开源如何开展商业活动，中间还有一个“中文马马虎虎”的芬兰女士介绍去芬兰留学的。

上午日程中记忆最深刻的是Xiao-Feng Li介绍的，如何在jvm中应用向量运算来提升性能。主要就是说，如果我们对一批数据进行相同操作，比如将10个数依次累加5这样的操作，如果使用循环就需要使用10次加法计算，而向量计算可以通过一个加法操作就实现对初始10个数的累加操作，这样就以内存的代价换取的操作效率的提升。

说真的，一开始还以为这是一个很偏门的技术，可是听到后来Xiao-Feng Li讲到将这一项技术应用于JVM的时候，并拿出了单线程下运行速度提升30%的测试数据时，我立刻就傻眼了。总是说理解业务最重要的同志们估计也没想到完全是在钻研技术也会产生这种意向不到的效果吧？业务应用遇到底层技术一般就是这种结果了，应用的反复研究造就了的结果是满足特定需求，而底层技术的推出直接在数量级层次发生了颠覆的作用，这种底层的研发阶段是枯燥的，而成果又是巨大的。借用演讲人的一句话：“你可以把它研究出来，然后卖给SUN,ORACLE这些公司嘛。”先不说这话是认真还是开玩笑，先回过头来考虑一下之前我们是否对技术进行过如此的钻研探究，也能够明白为何现在很多技术上的问题还是会成为我们前进道路上的瓶颈了。

再想想，为什么这种底层技术会直接出现在OpenSource中呢，更多时候它只会被公司内部作为机密控制起来，OpenSource不是商业行为，它仅仅是一种distribution和development的形态，开放式的开发形式，调动更多人的力量来催生创新的形成，反正个人从OpenSourceCamp上看到的OpenSource就是这样的了。

所以要放平心态，国内的技术积累尚未实现某种丰富的水平，所以建立在技术地基之上的OpenSource必定需要时间慢慢培养，如果真是要做开放开源，低下头做事情就对了。

谁应该用流程设计器

在业务的梳理和设计阶段都有可能用到流程设计器，这里提到的流程设计器是指有图形界面，可以通过拖拽图形设计流程图的设计器，而不是说一个开发者专用的XML编辑器。

既然涉及了图形化，就可以实现通过流程图与最终用户进行交互，对实际业务进行梳理和重组。图形比文字更容易让双方理解，这一点应该不会有什么反对意见吧？

下面就引出我们这次讨论的问题：“那么这个流程设计器到底是应该面向程序开发人员使用，还是面向最终用户使用呢？”

这个问题会衍生出多种不同的推断，讨论的焦点基本是围绕在：“是否要放权给客户进行设计工作呢？”

对 于这个问题大部分程序员都能及时给予否定的答案：“怎么能让不懂技术的人去负责设计工作呢？他们设计出来的东西要是用程序无法实现该怎么办？”社区中力挺 这种观点的人不在少数，比如OSWorkFlow就建议开发者通过直接编辑流程定义XML的方式设计流程，它们认为流程设计完全属于开发范畴，不需要也不 应该由最终用户介入。

但是，从最终客户方面又常常传来：“需要对业务进行定制调整”的声音，于是迫于市场和客户方面的压力，开发设计人员又开始研究如何让最终用户可以在应用层面对业务实现进行干预，于是出现了关于自动建表，定制表字段，自动生成表单等等相关的技术。

面对如此浪潮蜂拥，诸如MDA体系架构也开始蠢蠢欲动，想当初多少人怒吼着：“让开发人员失业，零编码实现业务系统。”那时的开发人员真是岌岌可危啊，总是担心害怕自己哪一天就被某个程序给替代了。可实际上过了这些年，也没看到开发人员集体失业的情况。

难 道是客户方面定制业务的需求减少了吗？好像不是因为这个原因，还是有很多客户抱怨市场瞬息万变，应用系统不好支持多边的市场风向。既然不是客户的需求减 少，而实际开发人员又没有被诸多的业务定制系统挤掉工作，那只能说明之前烽火连天的业务定制系统还无法完全满足客户的需求，客户依然需要通过开发人员才能 实现自身特定的业务需求。

现在我们依然需要面对的问题是：“客户需要随着市场的变动对业务作出调整和变化。”这个需求是现实存在的，既然市场提出了需求，势必会导致我们联想到是否可以将图形化的流程设计器直接提供给最终用户实现，以便用户对业务进行修改呢？

必须事先了解一点：“最终客户不是开发人员”， 他们不可能像程序开发设计人员那样信手拈来的编写代码，对业务模块进行调用，这一点就决定了我们最终提供给业务人员的设计器必定是功能受限的，不能把所有 功能都对其开发，而是应该限制他们的操作范围，让他们的操作保持在可控范围内，避免出现业务人员设计出一个完全不可能运行的流程图来，同时又要加强用户交 互的易用性，从这些方面来看，不论对设计和开发方面对我们提出了不小的挑战——如何帮助用户在不犯错的情况下，很容易设计出一个业务流程呢？

我们可以看到，如果要满足客户定制的需求，就需要提供两套流程设计器，开发版流程设计器需要提供各种接口方便开发扩展调试，最好还能和实际开发的环境集成。业务版流程设计器就要更加强调易用性，在功能方面进行限制，丰富校验和提示方面的信息。

数据建模与业务建模

无论是企业信息系统还是web网站，各种大小程序的原始功能都是对数据的操作，可以看做是某一群体对一些数据的各种需求造就了一个又一个的程序，或者说是软件系统。

回头想想，第一刻起我们就开始和数据打交道了，新项目开始的时候我们先要做什么呢？用第三方依赖搭个框架，设计目录结构吗？不对，这些都是技术储备，应该是在项目启动之前就完成的了。项目启动的一刻我们在做的工作总是对数据的分析。

我们要分析数据结构，理清数据关系，确定数据类型，还要兼顾数据量的大小，现在至少不用考虑数据的存储媒介了，因为十有八九都要用数据库，除了极少数情况应该不会有人选择自己编写文件系统进行数据的存储了吧？

上 面的这些步骤就叫做数据建模，搞程序的同志们肯定相当轻车熟路了，从拿到用户的第一个表单开始，在ER图中拖出第一个Table，我们就开始进行数据模型 的设计，设计好的数据模型将固化在某一种媒介中（基本都是数据库），应用系统的用途就是为用户提供一个界面，让他们对固化在媒介中（一般都是数据库）的数 据进行操作。

怎 么才算是良好的数据模型呢？首先它要满足数据固化的基本要求，所有必须的数据都必须能够保存在数据库里，其次这些数据的结构应该是容易被应用程序操作的， 无论是增删查改、数据校验、数据安全、搜索查询、统计汇总、数据导出等等功能都是可以实现的，而且效率不能太低。如果能够实现以上两条，基本就可以算是一 个良好的数据模型了，这样用户就可以借助应用程序对数据库中自己所需的数据进行管理、操作。

但 是还有一个问题，是否只要提供了这些功能就足以满足用户的要求了呢？从上面列出的功能中我们就可以了解到，无论是CRUD增删查改，还是查询统计，无非是 “更新（update）”，“查询（Read）”，“校验（Check）”三个基本操作的实现，这些操作都是基于静态数据的单步操作，应用程序只是在数据 外面简单包装了薄薄的一层，用户面对的和要操作管理的依然是后面整个数据模型。

这个问题可以归结到：我们解决了用户想要什么（What），但是并没有了解用户需要怎么做（How）。

数 据建模解决了数据如何存储，存储的格式，以及怎么获得已经存储的数据的问题，数据建模完成了数据固化和检索的任务，数据建模归根结底是对静态数据的建模， 给你一张ER图，你很容易就可以了解到数据的类型、数据的关系，但是你无法从这些数据格式数据关系中弄明白客户到底需要利用这些数据完成什么样的任务。不 清楚这些数据从何而来，到何处去，也就决定了你编写的应用系统只能包含一个录入界面，一个查询界面，无法再为最终用户提供更多的功能，因为你手中只有静止 不动的数据而已。

因此，为了让应用系统可以肩负起更多的功能，我们需要在业务模型的基础之上进行业务建模，比如一个文章发布系统中的表结构如下所示：

从 表结构中可以看到一个文章包含主键（ID），作者（author），内容（content），状态（status），创建时间（create_time） 和修改时间（update_time）。状态（status）字段类型为整形，可能的值为0, 1, 2, 3四种。单单从数值上来说，除了建表的人谁也搞不清楚这四个状态到底有什么作用，但是只要配合下面的流程图这个问题就可以迎刃而解了。

业 务建模的目标是在数据模型的基础上，让应用程序帮助最终用户解决实际业务中出现的问题，它所感兴趣的方面数据的流向和状态的变迁，从上面的流程图我们就可 以看到，虽然status拥有4个状态，但是这4个状态并不是可以随意转换的，“文章起草”（status=0）只能转变为“提交待审批” （status=1），而“审批完成”（status=2）作为一个终止状态是不能再发生改变的。这些功能需求都是数据建模阶段无法解决的，只有通过对业 务逻辑，业务流程的梳理分析才能在应用程序中为最终用户提供这些功能。

业务建模让数据模型变得有血有肉，结合了业务的数据不再是单薄的骨架，而是变成了鲜活的生灵。

我 们借助一个最简单的发文审批流程向大家介绍了数据建模与业务建模的关系，希望大家能够借此了解软件开发中业务流程与数据模型之间的关系，别小看文章表结构 中的status状态位，它已经初具了有限状态机（FSM, Finite State Machine）的雏形，很多简易的工作流引擎都是基于FSM来实现的，所以请切实体会一下实际开发中流程的作用，你可能没有使用工作流，但是我们所面对 的问题和解决的方式却是大同小异的。

我们为什么选择工作流。

一直感觉很难对那些从未接触过工作流的同学们解释清楚。

还记得有一个活动中，有人提问：“工作流到底是做什么的？”回答的同志希望根据具体的实例解释一下，就反问他：“你们公司的报销流程是怎么走的？”结果提问的同志直接说：“直接找财务啊。”引得下面一阵喧哗：“不用领导签字就可以随便报销啊。”

那个提供的同志心里一定感觉很无辜：“我也不知道公司的请假流程应该找谁啊，大家每次都直接给财务了。”其实对于小公司来说，里边工作的人本来不多，可能都是报销这种事情都是这样两步完成了，可实际上真实的流程应该是这样：

大家对图中的环节估计不会有什么异议，只是对于直接拿发票找财务报销的人来说，中间的核实部分变成了完美的黑盒，他不了解，也没有必要去了解报销的整个过程，站在当事人的角度，他只要最后知道这次报销能拿到多少钱就可以了。

对 于一个公司的内部事务来说，这样就最好的，员工没有必要去了解每个环节是如何进行的，但是在为这种公司进行软件开发时无疑要面临着掉进陷阱的危险。假设你 只对员工进行需求调研，他会只给你发票的单据，告诉你报销流程就是找财务。如果再去找财务进行需求调研，他会告诉你只要看一下没问题就可以报销了，最有可 能略过，也可能是最关键的特别情况需要经过老板审核的步骤，这个步骤可能是5000元以上必须经老板过目，也可能是特殊事项需要老板签字，但是因为公司日 常不会出现很多这种情况而被人们无意识的忽略掉，有可能到程序开发到中段时才突然想起来，然后就需要把流程重改。

说到这里，那么使用了工作流就可以避免出现这类需求变更问题吗？

答 案是否定的，软件开发时的需求变更常常是因为客户对本身业务要求和业务流程的不熟悉所导致的，软件开发的过程常常伴随着流程的梳理和细化，这也是为什么很 多程序员都说：“这个项目做完了，我比他们公司里的人都懂业务了。”其实不是你比他们还懂业务，真正办公的时候你还是会被各种情况冲的头昏脑胀，但是因为 你在软件开发的过程中对各个部门之间的依赖和关联进行了完全的梳理，所以对各个部门之间的数据流和业务流了解的更为通透。

话 说回来，工作流虽然不能解决因为客户对本身业务的深化而造成的需求变更问题，但是它确实可以把这个风险提前，我们知道，风险总是越早解决越有利，因为当我 们一张张单据化为流程图时，客户也能够更好的参与到流程的解读中来，通过流程图可以加快业务的深化，提早暴露出之前没有考虑到的问题，便于我们尽快的尽早 的解决。

那么我们直接用visio不就可以了？何必使用工作流呢？

答案是 visio也可以，只要可以限制图形中的语义，不要让客户任意发挥，就完全可以实现工作流的效果。为什么要限制语义呢？因为只有流程图可以直接映射为开发 完成的程序，对流程图的细化才是真正有意义的，否则客户画了一张完全无法用程序实现的图形，我们该怎么办呢？工作流一般都提供了自己定义的一套语义，大多 都是以XML格式保存的，只要以此为基础画出的流程图都是可以转换为实际程序的，再加上与客户的沟通，让客户和程序员对流程中每个环节的理解保持一致，就 可以尽量避免理解上的偏差，减少修改和返工现象。

但是工作流的学习曲线太高了，原本程序中我只需要设置几个状态位就可以解决问题，值得兴师动众的配上工作流吗？

对 这个问题的回答还需要对实际情况进行分析，小型系统中，你只需要制作一个CMS，不同的管理员负责不同版块内容的审批，这种逻辑简单，流程固定的需求确实 没有必要使用工作流，使用了工作流反而会加大开发和维护的复杂度，使用状态位模拟FSM有限状态机也完全可以实现。但是在复杂的业务情况中可能存在着同步 并行，多路决策，循环遍历等情况，这种情况下使用状态位就无法满足客户的业务需求，因此随着业务需求复杂度的上升，我们必然需要选择功能更强大的武器来解 决这一系列的问题。