Domain Modeling: Concepts and Activities
A domain model captures the concepts and activities of some enterprise.
We can think of the enterprise as the business environment of the system to be developed.
Often the domain model will translate directly into the domain layer of the Three-Layered Architecture that will be discussed later.
In this lecture we use class diagrams to model domain concepts. In the next lecture we will use activity diagrams to model domain activities.
UML class diagram as a conceptual model
A conceptual model captures the important concepts and relationships in some domain. Concepts are represented by classes, while relationships are represented by associations. Packages represent groups of related classes, and objects represent specific instances of classes.
For example a business might organize its concepts and relationships into three packages:
In the hr package we might find the Position and Person classes. Typical attributes of persons and positions can be listed in the attributes compartments of the respective class icons. The types of these attributes may not be specified at this stage of development. Similarly, operations performed by persons and positions may not yet appear.
The relationship "Position X is filled by person Y" can be represented by an association connecting Position and Person. Note the multiplicities that indicate that one position may be filled by zero or more persons:
Specific persons and positions can be represented using objects. Specific instances of the filledBy relationship can be represented by links connecting the participating objects:
Stereotypes
Similar concepts may appear under different names in diverse domains. The more general concept that a class fills can be indicated by a stereotype.
For example, Peter Coad classifies business concepts into four stereotypes:
<<entity>>
<<description>>
<<role>>
<<event>>
Here's an example of using stereotypes from the marketing package:
Aggregation and Composition
Use the aggregation arrow to model the relationship between a group and its members. Use the composition relationship to model the relationship between an assembly and its components:
Note that members can freely come and go without affecting the group. Similarly, the group can disband without affecting the members. However, components play a functional role in an assembly.
Generalization
Another special relationship is the relationship between a subclass and a superclass. This relationship is shown with the generalization arrow. In the following diagram we say that A generalizes B which generalizes C and D:
Java terminology is better. We say that C and D extend B which extends A.
The transitive closure of the generalization relationship is the subclass relationship. X is a subclass of Y, written Y <: X, if X is connected to Y by a chain of zero or more generalization arrows. It's easy to see the subclass relationship is transitive and reflexive:
X <: X
X <: Y <: Z => X <: Z
Semantically, X is a subclass of Y means that every instance of X is an instance of Y, but with perhaps a few additional features.
More formally, X is a subclass of Y means that instances of X can be substituted for instances of Y in most contexts.
This means that any operation an instance of Y can perform can also be performed by an instance of X (although perhaps using a different algorithm.) This is another way of saying that a subclass inherits the attributes and operations of all of its superclasses.
Here's an example of an inheritance hierarchy. Note that inheritance implies the operations and attributes of Calculator do not need to be repeated in the subclasses:
When translating a domain description into a class diagram, look for the phrase "is a" or closely related terms. These often indicate the need for a generalization arrow.