指南:业务事件
业务事件代表在业务的日常任务中发生的重要事件。本指南说明如何对它们建模。
关系
相关元素
主要描述

说明

业务事件代表在业务的日常任务中发生的重要事件。当然,每天在业务中和业务周围发生着数以千计的事件。业务事件允许我们通过关注真正重要的因素来管理复杂性,从这个意义上来说,业务事件在体系结构上是非常重要的。业务事件有以下特征:

  • 它们代表具有重要性的事件,即,它们不是一般事件。
  • 事件的发生似乎是随机的,或者说至少是无法预计的。
  • 它们彼此独立发生。
  • 它们会导致业务立即进行某些操作。

未含有其中一种特征的业务事件是可疑的。

在业务事件进行交互以实现业务使用的同时,业务参与者、业务工作者和业务实体触发并接收业务事件。业务事件可:

  • 由业务参与者触发,以指明业务用例的开始或结束。例如,供应商交付货物时,“交互”业务事件将指明“交互货物”业务用例的开始。
  • 由业务实体触发,以指明状态的更改。例如,作为“招募员工”业务用例的一部分,“合格应征者”业务事件将指明潜在的员工的参考资料已经过检查。
  • 由业务工作者触发,以指明业务用例实现内的某个特定点。例如,一旦已发射火箭,“发射”业务事件将指明可开始对火箭轨线进行跟踪。
  • 随时间流逝而触发。例如,在病人离开手术室六小时后,“相关病人”业务事件将指明应派出护士为病人做检查。

对业务事件建模

业务事件可以包含提供更多关于事件所代表的发生的环境的信息。如图所示,将该信息作为业务事件类的属性进行建模。可通过考虑事件接收者为进行操作所需的信息内容,来确定业务事件的属性。 

用于附带文本的 UML 示例。

如图所示,代表业务实体状态的更改的业务事件应与其相关的业务实体有关联。这将允许业务事件的接收者访问可疑的业务实体并检索必要的信息。

用于附带文本的 UML 示例。

业务参与者、业务工作者和业务实体能同时触发和接收业务事件。触发业务事件的类被称为发布者,而接收业务事件的类被称为订户

如图所示,发布者到它将触发的业务事件需要有构造型为 <<send>> 的依赖关系。

用于附带文本的 UML 示例。

如图所示,订户需要一个以操作定型的 <<业务事件>>,并且该业务事件与上述业务事件同名并具有与上述业务事件的属性相匹配的参数。注意:操作特征符需要与业务事件名称和属性保持一致。

用于附带文本的 UML 示例。

一个备用的方法是创建从订户到业务事件的 <<接收>> 定型依赖关系(尽管这不是标准 UML)。操作特征符可从所有 <<接收>> 依赖关系中得出。图中显示了这种非标准方法的示例。

用于附带文本的 UML 示例。

在交互图或活动图中显示了业务事件的实际触发。在交互图中,发布者使用业务事件的名称向接收者发送一条异步消息。图中显示了相关示例。请注意消息是异步的。这表示,发布者在继续之前不会等待订户完成对业务事件的处理。相反,发布者将触发业务事件并直接继续进行先前的任何操作。而订户一接收到消息就开始处理业务事件。这比同步消息更贴切地反映现实情况。

用于附带文本的 UML 示例。

在活动图中显示发布者将触发业务事件。而在相同的图或另一图中显示接收者将接收业务事件。图中显示了相关示例。

用于附带文本的 UML 示例。

查找业务事件

业务参与者和业务用例之间的关联被命名后,可使用相应的业务事件在启动业务用例时发出信号,这将是业务的重要事件。

在时序图中分析业务工作者之间的交互。对于业务工作者之间的每条消息,考虑以下事项:

  • 位置 - 在不同位置的两个业务工作者间传递的消息是候选的业务事件。
  • 时间 - 关于触发和接收之间存在相当长的时间的消息是候选的业务事件。
  • 目的 - 导致与触发业务事件的操作有不同目的的操作的消息是候选的业务事件。
  • 职责 - 由承担不同职责的业务工作者执行的消息是候选的业务事件。

对业务系统的边界进行分析有助于确定在目的或职责方面的不同之处。

在活动图中,考虑是否需要就在每个任务之前或在任务之后立即执行某个操作,或者是否必须将某个决策点的结果告知某一方。

业务实体还为业务事件提供线索。业务实体的任何重要操作都是候选业务事件。业务实体的状态表图是非常有用的。由于状态转换可能代表业务状态的更改,所以它们表示潜在的业务事件。

确定业务事件时,可设想一间档案处理办公室,其中业务实体就是档案,职员阅读、更改这些档案并在收件箱和发件箱之间移动它们。一旦需要完整地复制档案的某部分,以送至不同的目的地,您就可能发现产生了一个业务事件(有多个收件人)。同样地,出于告知他人的目的,业务工作者在执行任务之后必须撰写通知,这也可作为一个业务事件。当然,档案不是整日散乱地堆放在办公桌上(它们已归档)。当有必要从档案柜中取出某个档案,或是将某个档案放回到档案柜中时,考虑是什么导致了档案的取出或放回操作。导致或触发取出或放回档案的事件可能是一个业务事件。

业务事件的泛化关系

通过定义较泛化的业务事件和较专门化的业务事件之间的泛化关系,可将业务事件分类或分组为多个“系列”的事件。这允许那些对业务事件的不同子类型不感兴趣的当事方用同样的方式来处理一种以上的业务事件。

用于附带文本的 UML 示例。

上图显示了“疾病”、“失踪”和“逝世”是更为专门化的员工缺勤理由。对超类型的缺勤进行定义,这允许将三种子类型中的任何一种看作是缺勤。在咨询公司,例如,不论员工因何种理由缺勤,客户经理都可能需要通知客户该名员工缺勤并安排他人代替其工作。因此,客户经理仅关注业务事件“缺勤”。另一方面,若某个员工生病,接待员就可能需要采取特定行动,例如给医生打电话或送花慰问。若员工逝世,接待员还可能需要通知人力资源经理和该员工的经理。

在该示例中,我们会发现:当不同的当事方需要采取不同的行动以适应不同的(特定的)环境时,业务事件的专门化就非常有用了。而当某些当事方需要在不考虑特定环境的情况下,以相同的方式对某些业务事件作出响应时,事件的泛化关系就非常有用了。

当然,实际上,可能将告知当事方真实的(专门化的)事件。若某个员工逝世,可以确定客户经理也将被告知该消息,但是采取的行动还是相同的。业务事件的层次结构对于创建更为简单的、更易于理解的业务分析模型确实有所帮助。

业务事件的自动化

使业务事件的定义、触发和传播自动化是有意义的,但这不是始终都实用的。有时,构建一个系统来完成这些操作要比向同事发送电子邮件花费得多。在计划业务事件的自动化时必须考虑的一些问题有:

  • 购买或实施和维护使事件管理全面自动化的系统的成本
  • 自动化解决方案的技术可行性
  • 非自动化备选方案的成本
  • 不触发或接收某些事件的影响
  • 未来某些事件可能超出业务边界的可能性
  • 当前可用的通知渠道

在面向服务的体系结构中,消息用于软件系统相互之间以及与物理位置之间的分离。异步消息也可用于在时间上分离软件系统。尽管当然不是所有的消息都有相关的业务事件,但是在这些类型的软件系统中,将业务事件作为消息来实施。一个非常有用的业务事件应用程序出现在“企业应用程序集成”(EAI)中。在此,每个应用程序定义了若干其他应用程序可预定的业务事件。这允许应用程序可不通过直接交互而进行交互。

例如,考虑使用前台系统来管理客户交互、建议和合同的保险公司。它使用后台系统来管理产品和策略。当客户请求建议时,前台系统将收集关于客户和保险对象的必要信息。然后,产品管理系统将根据该信息计算保险费,并生成与建议相关的初步保单。一旦客户接受该建议,保单管理系统就必须完成该保单。在该示例中,存在两条在时间、位置和职责上断开的消息 - 计算保险费和完成保单。但是,由于只有“完成保单”在当前环境之外具有一定的意义,所以仅将它作为业务事件进行建模。