Domain Object Diagram

Definition

A domain object diagram is a bottom-level requirement diagram work product that primarily documents classes and types (interfaces) of business objects and the referential relationships between them.

Objectives

The typical objectives of a domain object diagram is to:

• Document the essential classes and types (interfaces) of business objects.

Benefits

The typical benefits of a domain object diagram are to:

• It provides a more formal definition to the business terms defined in the glossary.

Contents

The typical contents of a domain object diagram are:

• Classes of business objects.
• Types of business objects.
• Optionally their attributes and operations.
• Referential relationships between them.
• Definitional relationships between them.

Stakeholders

The typical stakeholders of a domain object diagram are:

• Producers:
  • Requirements Team
• Evaluators:
  • Project Manager
  • Technical Leader
• Approvers:
  • Project Manager
  • Technical Leader
  • Customer Representative
• Maintainers:
  • Requirements Team
• Users:
  • Architecture Team

Phases

• Business Strategy: Completed
• Business Optimization: Not Applicable
• Initiation: Completed
• Construction: Maintained
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

Domain object diagrams can typially be started if the following preconditions hold:

• The business strategy phase or initiation phase has started.
• The requirements team is adequately staffed and trained in requirements analysis.

Inputs

The typical inputs to a domain object diagram include:

• Work Products:
  • Application Vision Statement
  • Context Diagram
• Stakeholders:
  • TBD

Guidelines

• TBD

Conventions

Domain object diagrams are typically constrained by the following conventions:

• Work Flow
• Content and Format Standard
• Inspection Checklist

Examples

The following domain object diagram documents the logical classes of a digital thermostat.

Example Digital Thermostat Domain Object Diagram

Compare this diagram with the corresponding context diagram to see how the direction of referential (i.e., dependency and control flow) reverses at the software hardware boundary. Also compair this diagram with the corresponding class diagram to see how this diagram shows fewer classes and less detailed information about these classes (e.g., responsibilities rather than operations and attributes).