面向业务开发应用范文

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