Here are a few hints that I’ve put together for creating domain models and using a class diagram to express the model.

Domain models describe the business. We use a UML class diagram (static) to describe our domain model. The domain model helps us to understand the business before we dive into requirements and acts as a sort of glossary of terms, eventually leading to a system model which describes the software.

  • Nouns are either classes or attributes. Classes and attributes are NOT verbs.
  • Attributes have a value that is either a word or a number, classes have a value that is compound.
  • An attribute has a value and a class has an instance.
  • Multiplicity only works on compose and aggregate, never on generalization.
  • Don’t overuse multiplicity.
  • Generalization arrow points to the more general.
  • Containment diamond (aggregate or compose) is on the end of the line next to the class that does the containing.
  • Attributes are generally private (-) while methods are generally public (+).
  • Association is the least important relationship and means “knows about or does”.
  • Aggregation (open diamond) normally means “contains or has a”.
  • Composition (black diamond) normally means “is made up of”.
  • If you’re not sure of aggregation or compose, just start with aggregation.
  • Generalization normally means “is a type of” (usually).
  • Generalization is only used when a class has a different structure or behavior – example a blue truck and a red truck are not subclasses of truck – they differ only on value but a semi is a type of truck with different behavior and characteristics.
  • When determining relationships, aim for 90% of generalization, 80% of containment, 10% of associations.
  • Containment (aggregation and composition) on a parent class is typically inherited by the child.
  • Keep the focus on the business, not the software when developing domain models.
Advertisement