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.

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:

Concepts (Objects)
Attributes of Objects - Attributes must be simple attributes such as numbers. They cannot be objects, dimensioned numbers, or keys to part of a database.
Association between objects
Multiplicity
Optional direction of relationship arrow
Optional role of object

Associations

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

A is a part of B
line item of
Contained inside
Is a member of
Is a policy of
Is next to
Uses
Communicates with
A relates to B due to a transaction

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.