指南:业务实体
业务实体代表业务工作者执行业务用例时处理或使用的“事物”。本指南显示如何对业务实体建模。
关系
主要描述

说明

业务实体代表业务工作者执行业务用例时处理或使用的“事物”。业务实体通常代表对若干业务用例或用例实例有价值的事物,因此,业务实体对象的寿命相当长。一般来说,若业务实体不含关于如何使用和被谁使用的信息,这样会比较好。

业务实体通常代表文档或产品的重要部分。有时,它代表不太有形的事物,例如关于市场或客户的重要知识。例如,餐厅的业务实体是“菜单”和“饮料”;在机场,“机票”和“登机牌”则是重要的业务实体。

在业务建模中,我们通常认为业务实体是重要(且持久)的信息,我们在工件描述中的确是这样描绘它们的。但一般而言,业务工作者处理或使用的“事物”可能是物理对象:如果业务工作者是由复杂物理系统(该系统的边界确实有物质流动)实现的,那么用业务实体来代表这些物理对象的 信息对等物是有用的,它们是业务工作者将其操作传递给业务的其他部分的方式。然后,当您将业务工作者作为独立的系统来处理时,就可以在业务建模环境之外处理业务工作者的物理问题。

您只需要对这些现象作为“业务实体”进行建模,而业务领域模型中的其他类都必须引用这些现象。可以将其他“事物”作为相关类的属性来建模,或仅在这些类中以文本形式对其进行描述。

属性

类的属性代表了对象所包含的关于该类的对象的一段信息。属性有属性类型。每个属性和属性类型各有一个名称。

对象通常包含描述该对象的某些特征的不同信息。既可在对象的类的文本描述中含蓄地描述这样的信息,也可将其作为类的属性进行明确地建模。

属性是有一定类型的。属性有一个名称,最好是一个描述与类相连的属性角色的名词。属性类型可能或多或少地比较原始,它由简单的数字或字符串开头。不同的类可以有相同结构的属性。这些属性应共享一个描述;即,它们应共享属性类型。

注意:只应为了使类更易于理解才对属性建模!

使用属性或实体

有时,要确定应将概念作为类的属性,还是作为单独的业务实体类来描述是很困难的。一般的规则如下:若不超过一个对象需直接访问现象,或者访问现象的唯一的自然方法是通过对象,则将该现象作为属性进行建模。否则,在其自身的类中,单独对概念进行建模。

附带文本中描述的图。

在机场办理登机手续的用例中,机票非常重要。每张机票都有乘客姓名和航班。在此,属性 Name 和 Flight 被指出来。后者更为复杂,由航线、目的地、起飞时间和到达时间组成。

附带文本中描述的图。

乘坐同一航班的所有乘客共同享有该航班。对若干航班而言,航线是相同的。因此,更好的备选方法是将航班和航线作为类进行建模。

一旦您已确定某个概念是否对用例非常重要而必须对其进行建模,那么决定应将该概念作为单独的类,还是仅作为类的属性进行建模的因素在现实生活中就不那么重要了。相反地,决定如何对其进行建模的因素是访问该概念的业务需求。这意味着针对不同的业务,应对某些概念进行不同地建模。

考虑这个示例:对在机场交通规划用例中工作的员工而言,航班是很重要的。必须为每个航班定义起飞时间、航线和目的地。在这种情况下,您可能使用类“Flight”,并给予它属性“起飞时间”、“航线”和“目的地”。

附带文本中描述的图。

对在机场交通规划业务用例中工作的员工而言,航班是很重要的。

另一方面,对在旅行社工作的员工而言,情况就不同了。尽管他们仍需要起飞时间、航线和目的地,他们还有额外的需求。对旅行社而言,最重要的是查找到特定目的地的航班,在这种情况下,适合为“目的地”创建一个单独的类。当然,“Flight”类和“Destination”类必须相互知晓。这是双向关联所允许的。

附带文本中描述的图。

对在旅行社用例中工作的员工而言,航班起飞和目的地是同等重要的。

从理论上讲,可将任何事物作为类进行建模。但是,在适当的时候使用属性将减少必须维护的类的数目,并使对象模型更易于理解。

操作

要执行业务工作者的职责,充当业务工作者的人员将使用一种或多种工具来操作业务实体。您可利用代表使用的工具和进行的访问的操作及信息,对这些工具进行一般地或明确地定义。操作定义了用于操作业务实体的工具。访问由消息启动。用于操作业务实体对象的工具被描述为业务实体类的 操作,且该操作有一个名称以及(可选)参数。业务实体单元的访问显示为发送到业务实体对象的消息

例如,对业务实体“机票”的操作“关联行李”将包括将行李标签贴在机票上。参数将包含行李标签。

每个操作都由一个名称定义,该名称应体现其目的以及(可选)一串参数。参数指定了类的对象应期望从正在请求支持或正在建立访问的对象中接收到什么,以及当操作执行完毕时对象将提供什么。作为示例,您可给出反映业务工作者何时应在角色操作中采取措施,或是业务工作者何时应启动业务实体的某个操作来访问一定的业务实体。参数也可代表被移交的、或多或少有形的事物。

根据用例中详细信息的重要性或必需的级别,可对操作进行非正式地或更详细地定义。“更详细”的描述可能会描述行为序列,该行为序列说明在行为的执行过程中要处理的属性和关系、如何联系其他类的对象以及如何终止行为。

优秀业务实体的特征

  • 实体名称和描述清晰易懂。
  • 业务实体的种种关系不相互依赖。
  • 每种关系用在至少一个业务用例的工作流程中。
  • 业务中的所有“事物”(例如产品、文档和合同等)都作为业务实体建模。
  • 每个业务实体至少参与一个业务用例。
  • 实体有所有者;即,负责业务实体的业务工作者或业务参与者。

业务事件

业务事件可用于通知有关的当事方(包括其他业务实体)关于业务实体状态的更改。业务实体的创建和销毁可能非常重要。若已经定义了状态机,则检查业务实体的状态。每次转换都是潜在的业务事件。还需检查业务实体的属性和操作。不频繁使用的重要操作可能与某个业务事件有关联。对重要属性作出更改可能会引发事件。业务流程模式和业务实体模式也可能让人了解有用的业务事件。例如,若进一步使用业务实体之前,该业务实体必须获得批准,那么 <某事物>获得批准这一业务事件可能对于告知其他当事方“该业务事件可使用”非常有用。关于查找业务事件的更多信息,请参阅指南:业务事件