In the product, you can use several UML relationships to define the structure between model elements. Examples of relationships include associations, dependencies, generalizations, realizations, and transitions.
| Relationship | Description |
|---|---|
| Abstraction | An abstraction relationship is a dependency between model elements that represent the same concept at different levels of abstraction or from different viewpoints. You can add abstraction relationships to a model in several diagrams, including use-case, class, and component diagrams. |
| Aggregation | An aggregation relationship depicts a classifier as a part of, or as subordinate to, another classifier. |
| Association | An association relationship is a structural relationship between two model elements that shows that objects of one classifier (actor, use case, class, interface, node, or component) connect and can navigate to objects of another classifier. Even in bidirectional relationships, an association connects two classifiers, the primary (supplier) and secondary (client), |
| Binding | A binding relationship is a dependency relationship that assigns values to template parameters and generates a new model element from the template. |
| Communication path | A communication path is a type of association between nodes in a deployment diagram that shows how the nodes exchange messages and signals. |
| Composition | A composition relationship represents a whole–part relationship and is a type of aggregation. A composition relationship specifies that the lifetime of the part classifier is dependent on the lifetime of the whole classifier. |
| Control flow | A control flow is a type of activity edge that models the movement of control from one activity node to another. |
| Dependency | A dependency relationship indicates that changes to one model element (the supplier or independent model element) can cause changes in another model element (the client or dependent model element). The supplier model element is independent because a change in the client does not affect it. The client model element depends on the supplier because a change to the supplier affects the client. |
| Deploy | A deploy relationship shows the specific component that an instance of a single node uses. In a UML model, a deploy relationship typically appears in deployment diagrams. |
| Directed association | A directed association relationship is an association that is navigable in only one direction and in which the control flows from one classifier to another (for example, from an actor to a use case). Only one of the association ends specifies navigability. |
| Extend | An extend relationship between use cases indicates that one use case, the extended use case, can extend another use case, the base use case. An extend relationship has the option of using the extended use case. |
| Generalization | A generalization relationship indicates that a specialized (child) model element is based on a general (parent) model element. Although the parent model element can have one or more children, and any child model element can have one or more parents, typically a single parent has multiple children. In UML 2.0, several classes can constitute a generalization set of another class. Generalization relationships appear in class, component, and use-case diagrams. |
| Interface realization | An interface realization relationship is a specialized type of implementation relationship between a classifier and a provided interface. The interface realization relationship specifies that the realizing classifier must conform to the contract that the provided interface specifies. |
| Include | An include relationship between use cases specifies that an including (or base) use case requires the behavior from another use case (the included use case). In an include relationship, a use case must use the included use case. |
| Manifestation | A manifestation relationship shows which model elements, such as components or classes, are manifested in an artifact. The artifact manifests, or includes, a specific implementation for, the features of one or several physical software components. |
| Note attachment | A note attachment relationship connects a note or text box to a connector or shape. A note attachment indicates that the note or text box contains information that is relevant to the attached connector or shape. |
| Object flow | An object flow is a type of activity edge that models the flow of objects and data from one activity node to another. |
| Realization | A realization relationship exists between two model elements when one of them must realize, or implement, the behavior that the other specifies. The model element that specifies the behavior is the supplier, and the model element that implements the behavior is the client. In UML 2.0, this relationship is normally used to specify those elements that realize or implement the behavior of a component. |
| Usage | A usage relationship is a dependency relationship in which one model element requires the presence of another model element (or set of model elements) for its full implementation or operation. The model element that requires the presence of another model element is the client, and the model element whose presence is required is the supplier. Although a usage relationship indicates an ongoing requirement, it also indicates that the connection between the two model elements is not always meaningful or present. |