The diagrams in this document use established UML (Unified Markup Language) notation. You will see the following symbols. It is important to understand what they mean. Consult the following illustrations to help you understand and interpret the domain models in this document.
A class is a logical abstraction. In strict UML terms, a class represents a class of objects. In context of this document, a class represents an entity in the domain being modeled.
A class may have attributes. Attributes appear in a compartment within the class. In the example above, attribute1 and attribute2 are attributes of the second class. If no attribute compartment appears, that does not necessarily mean that the class has no attributes.
A class may have a stereotype, which is a type that provides the class with certain properties. A stereotype appears in brackets, such as <<Process>> in the third class above. In this document, a steretype typically indicates that the class is a process class, meaning that it has an associated process workflow defined in the process model section.
A package is a container that groups related classes and their relationships. Classes within a package may have relationships to classes in other packages, resulting in dependencies between the packages.
A line between two classes is an association. Associated classes have a relationship with each other. In this example, a manager has a relationship with a worker.
One or both sides of a relationship may have a symbol indicating multiplicity, or the number of relationships that one class may have with the other. An optional role name can further specify the role that the class plays in the relationship. In this example, a manager may have relationships to multiple workers, but a worker may only have a relationship with a single manager. The manager’s role is boss, and the worker’s role is employee.
Common multiplicity values include:
|
If no multiplicity value is specified, it is assumed to be 0..1. In the above example, if no value was set for a boss, the implication is that some workers can exist without a relationship to a manager.
An association class describes the relationship between two classes. This is typically used to model attributes on the relationship itself. In the above example, a worker may have multiple jobs over time. A job is just one of many different roles that a company has. Assignment is the association class in this example. It represents the relationship between worker and job as the assignment of a specific worker to a specific job. It captures the start and end dates for the assignment.
A dependency, denoted by a dashed line with an arrow, is the weakest form of relationship between classes. An association typically represents a stated or informational dependency between classes, a dependency indicates a behavioral interaction but no informational dependency. The name displayed on the relationship describes the nature of the interaction. In this example, a customer discusses business needs with a business analyst. There is no state or data link between the customer and business analyst.
A sub-type, or inheritance, relationship describes a class that is a more specialized type of another class. A sub-type relationship is indicated by a line with a triangular arrow on it. The arrow points to the more general class. In this example, a developer and a business analyst are specialized types of workers. They are assumed to inherit all of the attributes and behaviors of a worker, but may also have additional specialized attributes and behaviors.
A line with an open diamond terminator represents an aggregation relationship. This means that one class (the class to which the diamond is connected) is logically composed of the other class. In the above example, a department is logically composed of many workers.
A line with a filled diamond terminator represents a composition relationship. This is typically a physical rather than logical composition. In other terms, the parts cannot exist without the whole. In this example, the offices cannot exist without the building. This is distinct from an aggregation relationship, where the related classes may be able to exist without each other.