UML Domain Model

A UML domain model will relate objects in the system domain to each other. It will define concepts and terms. Objects in the domain model can be:

  • Physical objects
  • Abstract concepts

List Objects (Concepts)

To help the development of a domain model, it is important to identify nouns and noun phrases. Concepts that may not ultimately become objects may be listed for completeness and for discussion. The following types of concepts should be listed:

  • Actor roles
  • Events
  • Transactions
    • Transaction line items
  • Objects (physical)
    • Containers
      • Items (in container)
    • Other systems
    • Organizations
  • Specification concepts should be used when redundant information is reduced through their use or deleting instances of what the specification describes can result in information loss.

Nouns can be taken from the requirements definitions and use case drawings. This means at this point all your use case drawings should be done. Actors should not be emphasized in the domain model.

If information from an object is derived from another object, that is reason to exclude it. However, if the object is required or is important to the use case, it should be included.

Domain Model Syntax

After the list of concepts is complete a domain model should be made. Consider which simple items should be attributes of objects. The domain model is a static model. Time flow, with sequence of events or information flow are not shown in the domain model. Avoid showing procedural relationships. This model does not include software. The objects in the domain model are candidates for programming objects.

Syntax Of Domain Model

There can be multiple relationships between objects in the domain model. For instance an object may handle a single transaction, then make a record of all transactions it handles. In the domain model the following are shown:

Associations

Associations describe important relationships between concepts and may be bidirectional. Use an association to relate classes, not attributes. Some associations may be:

When creating associations, ask yourself, "Does one need to know about the other?". If the answer is yes, there should probably be an association. There may be more than one association between two objects.

Multiplicity

Describes how many instances of one concept can be associated with one instance of the related concept.

Some Guidelines

Domain Model Candidates

Unified Modeling Language Guide Contents Page