绩效评定流程在每月所有员工绩效计划打分结束后，由系统自动按评定关系表（树状结构，父结点是子结点的评定人，各部门总监为最底层评定人）发起任务，将最底层评定人下属的信息组装为表插入审批表单中，平行的最底层评定人为并行的子任务。最后一个平行最底层评定人评定结束后，系统会自动将新建子任务给平行最底层评定人的评定关系上层，并将所有平行最底层评定人的评定信息汇总作为审批表单，由此迭代直至找到平台级最终评定关系为止，流程结束。由于该流程极其特殊，既不是普通的并行或串行，也不是普通的子任务或会签，除发起结点、结束结点外，只有一个评定结点，所有评定人的评定活动均被看作评定结点的子任务，jbpm认为所有子任务均是并行关系，在业务逻辑中使用评定关系表等基础信息标识不同子任务的层级关系。由于无法使用统一的流程流转，在设计好流程及表单后，单独设计引擎驱动该流程，并在流程运转过程中更新基础信息表并负责发送邮件。

  单独的流程引擎设置、员工绩效基础信息表更新及邮件的发送由不同程序员开发。其中流程引擎在驱动流程运转过程中，会根据需要通知相应逻辑更新表及发送邮件。在开发引擎时，我使用观察者模式对流程进行重构使更新员工绩效基础信息和邮件发送逻辑的开发均独立进行，使代码的耦合进一步降低。

    在系统中存在这样的情况：一个功能点触发的动作会引起相关一个或者多个功能点在业务上进行对应的数据处理。而到底有几个功能点要做出相应，要看客户实施了哪些需要作出响应的具体功能点。

      例如：A功能点的某项业务会触发B、C、D三功能点做出回应，而客户订阅了哪些功能点是个未知数，也许客户不需要C功能点，对A功能点业务操作作出响应的仅有B、D。

      根据上面的需求可以得出，设计上要尽量的松散耦合，保持各功能点的独立性。观察者模式责无旁贷的跳了出来。

       我们的系统在整体上采用Spring framework来进行Bean管理。利用Spring通过配置文件来加载具体的类的方式——相当于被包装了的工厂，使得代码更加灵活。同样，观察者模式的应用可以很好的借用Spring framework提供的平台，变得更加灵活。

        首先，我们定义一个抽象的观察者

  具体观察者：

   在观察者模式中，目标角色是被客户程序调用，通过目标角色来通知具体观察者角色。在传统观察者模式中，目标角色中维护有一个观察者角色的列表，列表中的观察者角色通过其它程序进行添加维护——这就注定了观察者列表的改变会引起代码的修改。而通过Spring framework的配置方式注册观察者角色则避免了这种情况。

  下面是Spring framework配置文件的一个片断——它应该出现在用到目标角色的具体客户程序对应的Spring配置文件中。它将具体观察者的别名存放在一个list里面，使用Spring为生成的目标角色注入。

  如下：