Specialization and Generalization

A useful aspect of OO technology that can be used in BOM and scripting is Specialization and Generalization. For example, consider the following terms: Animal, Fish, Mammal, Goldfish, Cat, and Dog. Looking at these terms you can see that we can link some of them with the phrase "is-a" (or "is-an").

For example:

  • A Goldfish is-a Fish.
  • A Fish is-an Animal. (Also, a Goldfish is-an Animal).
  • A Cat is-a Mammal.
  • A Mammal is-an Animal. (Also, a Cat is-an Animal and a Dog is-an Animal).
  • A Dog is-a Mammal.

In the Business Object Modeler, these relationships would be represented like this:

In OO terms, this means that a Mammal is a specialization of an Animal, and a Cat is a specialization of a Mammal, and so on.

If someone wants a pet, and they specify that they want a Mammal, a supplier can give them a Cat or a Dog because they both satisfy the "is-a" Mammal requirement, or they can even be given a Hamster, as a hamster "is-a" Mammal. However, providing a Goldfish does not satisfy the "is-a" Mammal requirement.

While building up the model of what objects a business deals with, you may discover that some classes have some things in common. For example, there might be a Customer and an Employee class, both classes representing a person. When modeling this, you can create a Person class that holds the common attributes of Customer and Employee (for example, name, email, and telephone). The Customer class can then specialize the Person class, adding the extra attributes that only a customer has (for example, customerNumber). Similarly, the Employee class can specialize the Person class, by adding any attributes that only the Employee had (for example, department, manager and so on).

Generalization is the reverse of specialization (looking at the same relationship from the opposite direction). We can say that the Person class is a generalization of the Customer and Employee classes. Alternatively, we can say that the Customer and Employee classes are specializations of the Person class. Having done this, it is possible in a process to create a list of all the Customers and Employees that have been involved in a particular Order by creating a list of Person instances (each instance of which could either be a Customer or an Employee). The relationship between these classes can be represented in the BOM as shown below:

Assigning a Subtype to a Super Type

It is always acceptable to assign a subtype to a super type.

Using the diagram above as an example, if you had a Customer business object, as its BOM class is a subtype of the Person class, you can assign the Customer business object to a business object attribute of type Person (because you can say that the Customer "is-a" Person).

Assigning a Super Type to a Subtype

Assigning a super type to a subtype is acceptable when the super type actually refers to an instance of the subtype (or one of its subtypes). In other words, it passes the "is-a" test.

For example, if you have a Business Object Attribute of the Customer subtype that you want to assign from another attribute of the Person type, it will only work if the Person attribute is actually referring to an instance of the Customer BOM class. If the Person attribute is referring to a Business Object of the generic Person, or the Employee BOM classes then it will not work, as they do not satisfy the "is-a Customer" requirement.