Guideline: How to Create a Domain Model? - UML

Bounded by the current iteration requirements under design:

  1. Find the conceptual classes (see a following guideline).
  2. Draw them as classes in a UML class diagram.
  3. Add associations and attributes.

Guideline: How to Find Conceptual Classes?

Since a domain model shows conceptual classes, a central question is: How do I find them?

What are Three Strategies to Find Conceptual Classes?

  1. Reuse or modify existing models. This is the first, best, and usually easiest approach, and where I will start if I can. There are published, well - crafted domain models and data models (which can be modified into domain models) for many common domains, such as inventory, finance, health, and so forth. Example books that I'll turn to include Analysis Patterns by Martin Fowler, Data Model Patterns by David Hay, and the Data Model Resource Booh (volumes 1 and 2) by Len Silverston.
  2. Use a category list.
  3. Identify noun phrases.

Reusing existing models is excellent, but outside our scope. The second method, using a category list, is also useful.

Method 2: Use a Category List

We can kick - start the creation of a domain model by making a list of candidate conceptual classes. Table contains many common categories that are usually worth considering, with an emphasis on business information system needs. The guidelines also suggest some priorities in the analysis. Examples are drawn from the

  1. POS,
  2. Monopoly,
  3. airline reservation domains.

Table Conceptual Class Category List

Table Conceptual Class Category List


Method 3: Finding Conceptual Classes with Noun Phrase Identification

Another useful technique (because of its simplicity) suggested in [Abbot83] is linguistic analysis: Identify the nouns and noun phrases in textual descriptions of a domain, and consider them as candidate conceptual classes or attributes.

Nevertheless, linguistic analysis is another source of inspiration. The fully dressed use cases are an excellent description to draw from for this analysis. For example, the current scenario of the Process Sale use case can be used.

Main Success Scenario (or Basic Flow):

  • Customer arrives at a POS checkout with goods and / or services to purchase.
  • Cashier starts a new sale.
  • Cashier entersitem identifier.
  • System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules.

Cashier repeats steps 2 - 3 until indicates done.

  • System presents total with taxes calculated.
  • Cashier tells Customer the total, and asks for payment.
  • Customer pays and System handles payment.
  • System logs the completed sale and sends sale and payment information to the external Accounting (for accounting and commissions) and Inventory systems (to update inventory).
  • System presents receipt.
  • Customer leaves with receipt and goods (if any).

Extensions (or Alternative Flows):

Paying by cash:

  • Cashier enters the cash amount tendered.
  • System presents thebalance due, and releases the cash drawer.
  • Cashier deposits cash tendered and returns balance in cash to Customer.
  • System records the cash payment.

The domain model is a visualization of noteworthy domain concepts and vocabulary. Where are those terms found? Some are in the use cases. Others are in other documents, or the minds of experts. In any event, use cases are one rich source to mine for noun phrase identification.

Some of these noun phrases are candidate conceptual classes, some may refer to conceptual classes that are ignored in this iteration (for example, "Accounting" and "commissions"), and some may be simply attributes of conceptual classes. See for advice on distinguishing between the two.

A weakness of this approach is the imprecision of natural language; different noun phrases may represent the same conceptual class or attribute, among other ambiguities. Nevertheless, it is recommended in combination with the Conceptual Class Category List technique.

Example: Find and Draw Conceptual Classes

Case Study: POS Domain

From the category list and noun phrase analysis, a list is generated of candidate conceptual classes for the domain. Since this is a business information system, I'll focus first on the category list guidelines that emphasize business transactions and their relationship with other things. The list is constrained to the requirements and simplifications currently under consideration for iteration - 1, the basic cash - only scenario of Process Sale.

Case Study: POS Domain

There is no such thing as a "correct" list. It is a somewhat arbitrary collection of abstractions and domain vocabulary that the modelers consider noteworthy. Nevertheless, by following the identification strategies, different modelers will produce similar lists.

In practice, I don't create a text list first, but immediately draw a UML class diagram of the conceptual classes as we uncover them. See Figure.

Initial POS domain model

Initial POS domain model

Adding the associations and attributes is covered in later sections.

Case Study: Monopoly Domain

From the Category List and noun phrase analysis, I generate a list of candidate conceptual classes for the iteration - 1 simplified scenario of Play a MonopolyGame . Since this is a simulation, I emphasize the noteworthy tangible, physical objects in the domain.

Initial Monopoly domain model

Initial Monopoly domain model

Guideline: Agile Modeling - Sketching a Class Diagram

Notice the sketching style in the UML class diagram of Figure - keeping the bottom and right sides of the class boxes open. This makes it easier to grow the classes as we discover new elements. And although I've grouped the class boxes for compactness in this book diagram, on a whiteboard I'll spread them out.

Guideline: Agile Modeling - Maintain the Model in a Tool?

It's normal to miss significant conceptual classes during early domain modeling, and to discover them later during design sketching or programming. If you are taking an agile modeling approach, the purpose of creating a domain model is to quickly understand and communicate a rough approximation of the key concepts. Perfection is not the goal, and agile models are usually discarded shortly after creation (although if you've used a whiteboard, I recommend taking a digital snapshot).

From this viewpoint, there is no motivation to maintain or update the model. But that doesn't mean it's wrong to update the model. If someone wants the model maintained and updated with new discoveries, that's a good reason to redraw the whiteboard sketch within a UML CASE tool, or to originally do the drawing with a tool and a computer projector (for others to see the diagram easily). But, ask yourself: Who is going to use the updated model, and why? If there isn't a practical reason, don't bother. Often, the evolving domain layer of the software hints at most of the noteworthy terms, and a long - life 00 analysis domain model doesn't add value.

Guideline: Report Objects Include 'Receipt' in the Model?

Receipt is a noteworthy term in the POS domain. But perhaps it's only a report of a sale and payment, and thus duplicate information. Should it be in the domain model?

Here are some factors to consider:

  • In general, showing a report of other information in a domain model is not useful since all its information is derived or duplicated from other sources. This is a reason to exclude it.
  • On the other hand, it has a special role in terms of the business rules: It usually confers the right to the bearer of the (paper) receipt to return bought items. This is a reason to show it in the model.

Since item returns are not being considered in this iteration, Receipt will be excluded. During the iteration that tackles the Handle Returns use case, we would be justified to include it.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

UML Topics