Building a UML Domain Model - Part 3

by Gary K. Evans

In this series we have been following a simple process for building the domain model of our small hotel reservation domain:

1. Identify the domain classes in your project.
2. Identify which of these classes have relationships with each other.
3. Identify the semantics of these relationships.
4. For non-inheritance relationships, identify the multiplicity on these relationships.

We have almost completed Step 1, and we have identified the following "real" classes:

Reservation
Guest
Bedroom
CreditCardPayment

We need to perform one more sub-step before moving to Steps 2 through 4, which will let us actually build our domain class diagram, presenting our classes and their relationships.

Step 1c. Describe Your Class Responsibilities

Whenever I discover a "real" class - that is, a class that has passed the four challenge questions (in Part 2 of this series) - I focus immediately on identifying the class's responsibilities.

A class's responsibilities are its job description, its mission statement, its reason for existing as a concept within your business domain, and as a class in your system definition. Here is how I layout my classes and their responsibilities:

The second column in this table describes the business concept that the class represents in the business domain. This description is an entry from, or for, your business glossary. The third column states the responsibilities of the class: i.e., what it knows, and what it does. In your modeling your classes should never have overlapping, or identical, responsibilities. Each class's responsibilities should be totally disjoint so you are never confronted with two or more classes that know or do the same things.

Now that we have identified our classes and characterized their responsibilities, we can move on to building our class diagram.

Step 2: Identify which of these classes have knowledge of, or relationship with, any of the other domain classes

Which classes in our domain should know about each other?

The first pair that might come to mind are: Customer "places" Reservation. But the Customer class is not the human customer, and the Customer class does not place a reservation. The Customer class represents the information about a human customer. But there is a relationship between Customer and Reservation, and I will express that as: Reservation "is for" Customer. Note that this relationship becomes apparent when you start with the classname Reservation, rather than starting with Customer. Sometimes thinking "backwards" is a very powerful modeling practice.

There is certainly a relationship between CreditCardPayment and the Customer class, and we can represent this as: Customer "is responsible for" CreditCardPayment, since this represents the legal status of responsibility between the Customer (representing the human) and the payment which will be obtained for the reservation.

Between CreditCardPayment and Reservation we can identify: CreditCardPayment "pays for" Reservation, since the CreditCardPayment has the responsibility of obtaining the payment from the credit card provider.

We can also identify that Bedroom has a relationship to Reservation, since Bedroom is responsible for knowing its reservations, and the definition of a reservation is to reserve a bedroom. So, Reservation "reserves" Bedroom

Note what I am trying to achieve with my "captions" on these relationships. I am trying to use words that have meaning from the business domain, not the casual phrases that might first occur to us.

Also note that I have not pursued relationships between Customer and Bedroom (since this is mediated by the Reservation), or between CreditCardPayment and Bedroom (since their responsibilities do not align directly, but only indirectly through the Reservation class).

Step 3: Identify the semantics (e.g., association, aggregation, etc.) of the relationships between those classes that know about each other

UML defines four basic relationships that can be used on a class diagram: association, aggregation, composition, and inheritance (generalization). Association is a peer-to-peer relationship between two classes. Aggregation and composition are both whole-part relationships, where the whole owns, or manages, its parts. Composition extends the semantics of aggregation by adding lifetime-linkage between a whole and its parts. Inheritance is the "is-a-kind-of" relationship that involves superclasses and subclasses. More details on these relationships can be found in the very detailed UML Specifications at www.uml.org, or in a book on UML.

In the simple hotel reservation domain we have no inheritance, and no whole-part relationships, either. All of the relationships are association, where a class knows about and uses the services of another class in a peer-to-peer manner. In your business domain you will certainly find a majority of associations, and probably one or more of the other three relationships as well.

Step 4: For non-inheritance relationships, identify the multiplicity on these relationships

In our simple example we do not have any inheritance relationships. Discussing the subtleties of modeling inheritance will be part of another newsletter. But we must place multiplicity on all of the association relationships.

UML multiplicity identifies "How many objects of that class are related to one object of this class?"

UML defines five multiplicities:

1: which means "one and only one"
0..1: which means "zero or one (only)"
0..*: which means "zero or more", and
1..*: which means "one or more".

The fifth form of multiplicity is called numerically specified and allows you to specify formulas (e.g., 2n, n=1,2,...) or discontiguous values (e.g., 1,4..5,12).

Now we can put all of these decisions together to build the domain class diagram for our example:

Note that our diagram does not contain attributes (data members) or operations (methods) for the classes. Discovering those requires that we explore UML behavioral diagrams such as the Sequence diagram, or State Machine diagram. That may be a topic in a future newsletter.

Concluding

I hope this series has given you some ideas about how to build a UML class diagram for your business domain. I have not attempted to be exhaustive, but whether your domain has only four classes, or forty, this same, simple process can help you attain this goal effectively and efficiently.

    Gary K. Evans