Skip to main content

Domain modeling; attributes and associations guidelines

Short answer

Domain model is a visual representation of conceptual classes, attributes, and associations of the problem domain (no operations). Attributes: use simple data types, no foreign keys, model quantity with units, avoid derived values unless marked /. Associations: add only needed relationships, name association, show multiplicity, avoid redundant ones.

What do you mean by Domain Modeling? Present the guidelines to add attributes and associations in the domain model.

Domain modeling

A domain model (conceptual class model) is a visual representation of the conceptual classes or real-situation objects of the problem domain: the important concepts, their attributes and their relationships. It is the main artifact of OOA. It is drawn as a UML class diagram without operations, and it is a "visual dictionary" of the domain's vocabulary. It describes the real world, not software classes.

 +--------+ 1   * +--------+ 1   1..* +---------+
 | Member |-------| Loan   |----------| Book    |
 +--------+ makes +--------+  of      +---------+
 | name   |       | date   |          | title   |
 +--------+       +--------+          | isbn    |
                                       +---------+

Guidelines to add attributes

  1. Include attributes that the requirements suggest or imply a need to remember information (e.g. receipt needs date and time).
  2. Use simple data types (number, text, date, boolean) for attributes. Relate to other classes with associations, not attributes. (Do not make customerId in Sale; relate Sale to Customer.)
  3. Do not use attributes as foreign keys.
  4. Model quantities with their units, using a class (Quantity, Money) when needed.
  5. Keep data-type classes (address, phone) as attributes if they are simple; make them classes if they have structure or rules.
  6. Do not add attributes whose value can be calculated (derived), unless marked /.
  7. Keep the model small: add only attributes that matter for the current iteration.

Guidelines to add associations

  1. Add associations for relationships the system needs to remember for some time (need-to-know).
  2. Add associations from the Common Association List: A is a physical/logical part of B; A is a description of B; A is contained in B; A uses or manages B; A is owned by B; A is a member of B; A is transaction related to B (Customer-Payment); A is next to B; A is a transaction/event recorded in B.
  3. Name an association as ClassName-VerbPhrase-ClassName, readable in one direction.
  4. Show multiplicity at both ends.
  5. Avoid too many associations, and omit those that can be derived from others (redundant).
  6. Use role names where the same class takes part in different ways.

All Object Oriented Analysis and Design chapter 2 questions →