业务实体



业务实体

业务实体代表业务角色处理或使用的“事物”。

主题
  • 解释
  • 属性
  • 使用属性还是实体
  • 操作
  • 好的业务实体的特征

解释

业务实体代表业务角色执行业务用例时所处理或使用的“事物”。一个业务实体经常代表某个对多个业务用例或用例实例有价值的事物，因此，业务实体对象的生存期相当长。一般而言，一个好的业务实体不包含关于其使用主体和使用方法的信息。

通常，业务实体代表产品的文档或重要组成部分。有时候，业务实体也代表一些非实体的对象，如关于市场或客户的重要信息。例如，饭店中的业务实体有菜单和饮料；而在机场，机票和登机牌是重要的业务实体。

您只需将业务对象模型中其他类必须引用的那些现象建模为业务实体。而其他“事物”可以建模为相关类的属性，或只在这些类中进行文字描述。

属性

类属性是类对象保存的有关该对象自身的一条信息。每个属性都有自己的属性类型。
每个属性和属性类型都有各自的名称。

对象通常保留有描述其某些特征的各种不同的信息。这些信息可以通过对象的类的文字说明隐含地给出，也可以作为类的属性进行明确地建模。

属性总属于某个类型。属性有自己的名称，这个名称最好可以描述属性相对于类的角色。属性类型则相对简单，以一个简单的数字或字符串开始。不同的类可以拥有相同结构的属性。这些属性共享一个描述，即它们属于同一个属性类型。

注意：建立属性的唯一目的是使类更易于理解！


使用属性还是实体

有时很难决定是将概念描述为类的属性，还是单独的业务实体类。

一般说来，将现象作为属性建模的条件是：只有一个对象需要直接使用该属性，或者只能通过该对象才能访问该属性。否则，应该对该概念单独建模，自成一类。

在机场登记处用例中，机票是一个重要元素。每张机票上都印有旅客姓名和航班。所以我们将姓名 (Name) 和航班 (Flight) 确定为属性。航班比姓名要复杂，它包含了航线、目的地、起飞和到达的时间。

航班对乘坐同一班机的所有旅客都相同。多个航班可能会飞同一条航线。所以，一个更好的办法是将航班和航线建模为类。

一旦您觉得一个概念在用例中很重要并决定对它建模后，它将被建模为单独的类还是类的属性就不再由现实中的重要性来决定了。这些将由访问它的业务需要来决定。这意味着某些概念针对不同的业务将进行不同的建模。

考虑一个示例：对于空中交通规划用例中的雇员来说，航班是主要问题。必须确定每次航班的起飞时间、航线和目的地。在这种情况下，您可能会使用一个类“航班”(Flight)，并赋予它起飞时间、航线和目的地等属性。

航班对于工作在机场空中交通规划业务用例中的雇员来说是主要问题。

而对于旅行社的雇员来说，情况又不同了。他们仍然需要考虑起飞时间、航线和目的地。此外他们还需要其他信息。对他们来说最重要的是要找到飞往特定目的地的航班，所以在这种情况下，应该将目的地 (Destination) 建模为一个单独的类。当然，Flight 类和 Destination 类必须相互一致。这是通过双向关联关系实现的。

对工作在旅行社用例中的雇员来说，航班起飞时间和目的地同样重要。

理论上，所有事物都可以建模为类。但是，适当地使用属性可以减少需要维护的类的数量，同时可以使对象模型更加易于理解。

操作

操作确定了操作一个业务实体所使用的工具。一条消息发出访问请求。可用于操作业务实体对象的工具被表示为该业务实体类的一个操作，操作有名称和参数（可选）。对业务实体单元的访问显示为一条发往业务实体对象的消息。

为了完成其职责，作为业务角色的人员使用一个或多个工具来操作业务实体。您可以对这些工具进行一般定义，也可以使用操作和消息进行明确定义，其中操作和消息分别代表所使用的工具和所进行的访问。

为每个操作指定一个名称，此名称给出操作的目的和参数数目（可选）。这些参数指定了类的对象希望从请求支持或进行访问的对象那里得到什么，执行操作中对象应该提供什么。例如，您可以指定参数来反映在角色操作中业务角色应该在何时进行操作，或者角色应该在何时启动一个业务实体的操作来访问某个业务实体。参数还可以代表某些被移交的实物。

可以非正式地定义操作，或者对其进行详细定义，这都取决于其在用例中的重要性和需要的详细程度。一个“更详细”的说明可以描述一个行为序列，它指出在行为序列的执行中处理了哪些属性和关系、其他类的对象如何联系以及如何终止行为序列。

好的业务实体的特征

  • 其名称和描述明确易懂。
  • 业务实体关系不互相依赖。
  • 每个关系都用在至少一个业务用例的工作流程中。
  • 业务中的所有“对象”（例如产品、文档、合同等）都作为业务实体进行建模。
  • 实体参与了至少一个业务用例。
  • 存在实体所有者，即一个负责此业务实体的业务角色或业务主角。