Defining Domain Relationships

Domain relationships represent the different ways domain classes are related in the domain model. There are two basic kinds of domain relationships, embedding and reference.

• An embedding relationship occurs when the instances of a domain class are contained in another domain class. An embedding relationship resembles a tree structure.

• A reference relationship occurs when instances of a domain class have links that refer to instances of another domain class.

Structure of Domain Relationships

Every embedding relationship and reference relationship contains a name and a role for each domain class to which it is connected. Inheritance domain relationships do not have names or roles.

Roles and Multiplicities

A role defines how one domain class is related to another domain class. In the following picture, the Model domain class has an embedding relationship with the Component domain class. Every role has a property name and a multiplicity, which together define how source code is generated for the domain class to which it is connected. The property name of the role that is connected to Model is Components, and the property name of the role that is connected to Component is Model. The source code that is generated from this relationship is a Model property on the Component class and a Components property on the Model class.

The multiplicity of a role specifies how many instances of the connected class can have the specified relationship. For example, in the picture, the multiplicity of the Model role that is connected to Component is 1..1. A 1..1 multiplicity means that an instance of Component can be contained in one, and only one, instance of Model. The multiplicity of the Components role that is connected to ExampleModel is 0..*, which means that an instance of Model can contain indefinitely many instances, or no instances, of Component.

Adding Embedding Relationships

To add an embedding relationship, in the Toolbox, select the Embedding Relationship tool, and in the diagram, click the parent domain class and then click the child domain class.

Restrictions on Multiplicities in Embedding Relationships

The following built-in constraints on multiplicities in embedding relationships help ensure that your domain model is well-formed:

• The multiplicity of the target role must be either 0..1 or 1..1. A model element can be contained by only one element.

• If a domain class can be a target in more than one embedding relationship, then the multiplicity of the target role on all those embedding relationships must be 0..1 because an instance of an element cannot be contained by more than one element.

• Every domain class except the root must be the target of at least one embedding relationship. In other words, every domain class in the model must be contained by the model, or by another domain class that is contained by the root, either directly or by inheritance.

Adding Reference Relationships

Roles in reference relationships also have multiplicities, but they are not constrained. Reference relationships can signify any kind of relationship between domain classes, except containment and inheritance. For example, reference relationships can signify family relationships (such as the Family Tree model), possession relationships (such as a LibraryHasBook relationship), transitions from one state to another state, and so on. You can specify any allowable multiplicity (0..1, 0..*, 1..1, 1..*) on either role of a reference relationship.

In the following picture, the Comment domain class has a reference relationship to the Component class. Notice the dotted line, which denotes a reference relationship. A straight line denotes an embedding relationship.

Presentation of Domain Relationships

Most domain relationships are displayed on the diagram as connectors. However, they can be displayed as shapes or compartments. You can add a connector shape to the diagram and map the relationship to the connector. For more information about how to map relationships to connectors, see Defining the Appearance of the Generated Language Designer.

See Also

Other Resources

Domain-Specific Language Tools Glossary

Change History

Date	History	Reason
July 2008	Rewrote and refactored project.	Content bug fix.