流程建模试验报告.docVIP

SOA实验2：流程建模实验报告 实验内容 实验的主要内容是对员工差旅费用报销流程的SOA建模。根据协商分工我们小组的建模的内容是图1中描述的流程。实验运用的是IBM的建模工具。要求对流程中的处理流程，分支判断，角色，流程中的软件系统建模。在完成建模后对建模进行模拟，运行，分析执行结果。 在试验前，由组长谢丹完成对建模工具的汉化工作。对图中的名称直接用中文描述，避免了英文翻译理解不一致的问题。 图 1 员工出差报销 模型中主要的元素的说明 在通过实验进行建模后我们得到如下的整体模型图如图2 图 2 角色（role） 角色是每个任务（task）的参与者，或者可以理解成由谁来做这件事。在这个流程中要定义的角色有：申请人，部门负责人，财务管理部，员工费用部，行政支持组。在资源目录下新建这几个角色。为了在后面区分它们，将其定义为不同的颜色以标识与他们相关的任务。在图2中，可以看出在每个角色所在的泳道中，可以看出与他们相关的任务。在图中处于不同泳道上的任务的着色都不一样。这样很好的区分出来。 具体而言，每个角色的相关的任务有： 角色 相关任务 申请人 填写申请，检查申请，检查超额 部门负责人 审批报销申请 财务管理部 检查报销单据 员工费用部 审核报销申请，核定报销 行政支持组 处理超标 表 1 各个角色相关任务 定义任务（task） 任务，是原来流程中的处理过程。是建模中的主体。在建模过程是： 1.选择任务（task）图标 2 .更改任务名称 3.在任务的资源属性中指定任务的角色 4指定持续时间（duration）等属性 其中第3向指定角色是必须的，不然系统会报错。任务的图标是图中的圆角矩形。 定义分支（decision） Decision是模型中的分支。它标识一个处理到另一个处理的决策。决策的图标是菱形。在分支决策结点中的要注意的一个地方时：各个分支要指明该分支路径的百分比。并且各个分支的百分比之和要等于100%。在模型中共有5个决策分支。要注意的一点是：二分支中，Yes分支在上，No在下。图2为一个二分支，图3为模型中的一个三分支 图2 二分决策 图 3 三分决策 定义合并结点（merge） Merger结点是一个理解的难点。在模型中任务只有一个进入分支，一个出口。但是例如在任务1 可以进入任务2即有填写报销申请进入审核报销申请。也可以由任务3进入任务2即在任务2中不批准后进入3检查后重新进入任务2审核申请。也就是任务2有2个入口。这时就要引入merger结点。如下图： 图4 merger实例 Merger结点的作用是为进入一个任务提供一个统一的入口。而Join结点的是将进入该任务的条件汇集齐后执行。 实验步骤： 建立模型中的角色。在第二部分中指出在共有5种角色。定义这五种角色。 新建任务1：填写报销申请。并建立边界到任务1 的连接。指定该任务的资源角色。 新建merger结点，任务2，指定任务2的资源角色.连接任务1到一个merger结点。新建决策结点是否批准。新建任务3检查报销申请。这一步完成了填写报销申请到审核报销申请，是否批注分支的否定分支到任务3检查报销申请，这样一个完整的过程。 图 5 新建merger结点。新建任务4检查报销单据，任务5审核报销申请。判断结点是否有问题。将判断结点是否批准的Yes分支连接到任务4前的merger结点。连接任务4，5.任务5进入是否有问题判断结点。由其中的一个分支进入任务4 前的merger结点。此时处理流程再次进入任务4.如图6 图 6 完成是否有问题的第二个分支：超额处理.新建任务6检查超标超额。新建判断结点是否继续申请。这分支的含义是如果报销超额后申请人要进行超额检查。如果修改额度则进入任务7审核报销额度。如果不修改则进入到任务8处理超标 新建5中涉及到的任务7，任务8.判断结点是否处理成功。如图7 新建任务9SAP记账，任务9前的merger结点，任务10报销支付。连接是否有问题的第三分支到任务9前的merger，任务7到任务9，任务8判断份子的Yes分支到任务9。如图8 图 7 图 8 按泳道布局模型。见图9 对业务模型进行模拟。选择流程，右键选择模拟功能，生成模拟文件。设置token为5运行模拟文件。结果如图10，11 图 9 小组成员分工 我们组的几位同学在试验中各自完成了各自的