面向业务开发应用.docVIP

面向业务开发应用 返回到普知杰首页 自从计算机出现后，快速便捷的从太平洋一样的文海中找到水滴大小的资料真正成为了可能，而能够帮助人们实现这一愿望的程序员就像中世纪的航海家一样用神秘的代码程序指引着计算机一步一步实现的需求。而他们所用的被称之为“程序”的序列组合，在一般人眼中，有如天书般难读难懂。 即使对于程序员来说，实现复杂的业务需求也不是一件容易的事情，这很大程度上归咎于现有的软件设计模式并不科学。在《探索流程的奥秘之三， 如何梳理业务流程》中，我们了解到用户关注的是结果（交付物）及结果的状态，而软件设计关注的是操作，而很不幸的是，程序员也是人，这种错位的思考模式很难让人轻易理解。 面向业务开发应用的方式修正了这种情况，它的主要出发点如下： 所有的应用都是由若干业务流程组成 人们在使用应用时，会对所操作的业务流程产生出业务数据来，如每次请假时会产生请假申请信息及执行信息。 业务流程的产生业务数据是分步骤生成的，且根据步骤的执行情况会生成不同的数据，如请假申请只有批准后才会有执行信息。 一个业务流程的业务数据会被另一个流程使用，是因为业务流程之间存在步骤流转，比如启动报销流程是因为有了出差业务，且出差业务中发生了消费。 业务间的关联在数据关系上体现的是A业务记录中包含B业务记录中某项数据的集合，如出差活动的出差人集合。 有时业务之间的关联是由我们并不注意的中间业务担当的。 下面我们以差旅应用为例，来看一看面向业务设计软件的过程： 图一 差旅应用业务流程关系图 人们在日常出差时，最直观的感受到出差、借款及报销这几项业务，各公司针对其均有相应的审批流程及办事流程，但这三个业务流程间的关系如何呢？从图一可以看出： 这三项业务都与人员有关 借款是直接挂在每个员工上的，但每次出差可能不止一个人出行，因此就需要增加D02员工的出差活动这个隐含意义的业务流程。 每次借款和报销的发生实际上是通过D02员工的出差活动发起的。 很多公司在报销时往往要求填写报销明细，虽然每项报销明细并没有独立的审批过程，但其体现了集合关系，因此可以将报销明细看作特殊的没有审批步骤的业务流程。 确定了业务流程的关系后，我们就探究一下每项业务流程的特性。 图二 出差业务简单流程图 图二是一个简单的出差业务管理流程图，与一般的框图不同，这张图反映了更多的我们传统软件开发模式下未考虑的细节： 步骤的执行可以造成其他步骤跳转的失效，比如我们允许即使提交了申请，在未审批情况也可以修改申请时，修改申请的操作会造成原先提交申请跳转自动失效。 步骤的操作人可能来自于业务流程自身，（我们称其为动态步骤操作人），比如取消出差活动的操作人为出差申请的申请人或审批人。 任何步骤执行后都有可能产生多个跳转，也可能不产生任何跳转。 如果跳转到交互步骤（需要操作人介入的步骤），则操作人有执行业务步骤的选择权，如果跳转定义了通知操作人，则被通知人的待处理队列中应该出现该步骤。 如果跳转到自动执行步骤，计算机应该自动执行该步骤，并进行后续跳转，直到没有后续的自动执行步骤或遇到结束节点。 业务记录的数据是在各个步骤中渐次获取的，可能多个步骤都对同一个数据操作，如创建申请、修改申请、调整出差活动都可修改出差期限。 对于每个步骤的执行，除了传统的赋值计算操作，还会包括特定操作，比如通过审批处理时会针对出差人清单自动创建“出差人活动”业务记录，用于后续的借款、报销处理。 利用普知杰的协同应用系统平台，可以轻松的实现面向业务的应用构建，比如步骤跳转的操作如下： 图三： 流程设置时步骤跳转设置案例 对于使用者，只需要找到对应的业务记录后右键，即可进行相应的操作，如图： 图四： 业务记录的步骤操作举例 特别要提及的是，经过此方式整理出来的业务记录数据，相互间是有关联关系的，如从员工可以查出其所有的出差、报销、借款记录来。这样就有利于我们快速的查询我们需要的任何信息。普知杰的协同应用系统通过自定义视图的设置，可以快速的实现这种需求。 面向业务开发应用还有很多有意思的特性，利用这些特性可以找到软件设计的通用规律，进而实现自动化的应用系统开发，让我们远离繁复的代码编程，我们后续会推出一个系列文章，欢迎大家指正。有兴趣的人也可以到普知杰网站下载评估版软件进行试用。 返回到普知杰首页