Building a UML Domain Model - Part 1

by Gary K. Evans

This is the first of a brief series of articles on how to develop a domain model using the Unified Modeling Language (UML). I will begin by constructing the initial domain class diagram (CLD) for a simple business domain. Then I will develop a sequence diagram to illustrate how our domain classes might interact to accomplish the goal of a use case. My purpose in this series is to describe with examples a very simple process to follow as you transform your project's requirements into a visual representation of your project's domain.

A UML class diagram is a visual presentation of those classes that represent a software system. A domain class diagram is populated with the business abstractions (i.e., business concepts) of the business domain you are modeling. The value of a domain CLD is that it allows a project team to visually describe the business context for the solution they will implement.

The domain CLD can be produced by business analysts, subject matter experts, or developers. The issue of which job role, or which organizational department, develops the domain CLD is insignificant. What is important is that whoever develops this diagram knows how to think in a modeling perspective, and has a proper process to follow. When you finish this series of articles you will understand both this perspective and a very useful process.

The defining modeling criterion is that design constructs are not allowed in a domain model. When a project has a solid and accurate domain CLD, the project has a much higher probability of producing a design, then an implementation that aligns well with the business goals of the organization.

The process I will follow for producing a domain class diagram is:

1. Identify the domain classes in your project
2. Identify which of these classes have knowledge of, or relationship with, any of the other domain classes
3. Identify the semantics (e.g., association, aggregation, etc.) of the relationships between these classes that know about each other
4. For non-inheritance relationships, identify the multiplicity on these relationships

To motivate this discussion I will introduce a very simple domain with which everyone is probably familiar: a hotel reservation system for a very small hotel. Here are the total business requirements for this example (I want to keep it very simple to keep this understandable):

• Guests talk to a hotel clerk, either in-person or on telephone, to place a reservation for a room at the hotel.
• Guests pay for the room only with a credit card.
• We want to maintain long-lived information about any guest who makes a reservation.
• We want each reservation to identify which clerk made the reservation for the guest.

We have to start our discovery process with Step 1: Identify the Domain Classes. This is just one step, but we have to expend quite a bit of effort to accomplish its goal.

Step 1. Identify the domain classes in your project

We need a source for identifying the classes. On a project you would use business requirements, feature lists, the project glossary, use cases, etc. I am going to use a single, very simple use case as my requirements starting point. While use cases are normally categorized as behavioral - or user - requirements, they also capture many business requirements. Since many projects incorporate use cases already, I will follow that practice in this discussion.

Here is a very simple use case for making a reservation.

Use Case: Make a Reservation
Primary actor (i.e., end user): Hotel Clerk
Use Case Scope: user-level

Main Success Scenario:

1. Clerk requests a reservation and enters guest's arrival date and duration of stay.
2. System presents available bedrooms.
3. Clerk selects a bedroom and enters guest information.
4. Clerk enters credit card information.
5. System applies a payment reserve to the credit card.
6. System presents a reservation confirmation number.

Before we can identify our "real" domain classes we have to perform two subtasks:

Step 1a. Produce a list of "candidate" classes, then

Step 1b. Challenge these candidates to eliminate those that are just simple attributes, synonyms, meaningless terms, etc. - that is, weed-out anything that does not merit "classhood".

Step 1a. Produce a list of "candidate" classes

To create the list of candidate classes, I will apply a technique called grammatical dissection to the Make a Reservation use case. Grammatical dissection is often criticized as too crude, too simplistic, too inelegant, etc. All of this is quite true, but I am only interested in rapid progress toward real results, and grammatical dissection is faster than any other technique I have used or read about.

To apply this technique to find the candidate classes, we simply underline all of the nouns, or adjective-noun pairs, in the use case. This is a completely mechanical process, and require no higher cerebral activity than understanding what a noun is. Here is the use case with the nouns/noun-pairs underlined:

1. Clerk requests a reservation and enters guest's arrival date and duration of stay.
2. System presents available bedrooms.
3. Clerk selects a bedroom and enters guest information.
4. Clerk enters credit card information.
5. System applies a payment reserve to the credit card.
6. System presents a reservation confirmation number.

Note that I have underlined every occurrence of repeated nouns so I do not make any premature judgments.

We now gather together all of the distinct underlined words to produce a list of the candidate classes, using only singular (not plural) representations:

Clerk
reservation
arrival date
duration of stay
System
available bedroom
bedroom
guest information
credit card information
payment reserve
credit card
confirmation number

This list of candidate classes is our raw material to work with. In next month's newsletter we will see how to challenge these candidates to discover the "real" classes in our domain case-study.

    Gary K. Evans