UML Relationship

UML Relationship

In UML, the relationship describes a connection between several things. This relationship is also known as link that represents how more than two things can associate with each other at the same time as the system’s implementation. It combined four types of relationships, like dependency, association, generalization, and realization.

• Dependency
• Association
• Generalization
• Realization

Dependency Relationship

Dependency is something that describes the intermediary dependency relationship between the elements. Thus it plays an essential role in the UML model. The use of a dotted arrow can display it. In the object-oriented world, dependency means what it does in the natural world. A dependency depicts a conceptual relationship between two elements or two sets of elements. It is represented by a dotted line pointing form the dependent to an independent component. We can also say that a class contained inside the other class is known as dependency. Dependency relationship is also called as a type of the unidirectional relationship. Two parties are dependent on each other in this relationship.

Dependency describes how things within a system are reliant on each other. In UML, a dependency relationship is the kind of relationship in which an item dependent on the other item.

In this type of relationship, when we make modifications to a specific component, it becomes feasible that the components will also get distressed through the change. As its name suggests, more than two elements are reliant to each other.

It is used in class diagrams, component diagrams, deployment diagrams, and use-case diagrams, which indicates that a change to the other item constrains a change to the client. An example is given below:

Stereotypes

<<access>> - Access stereotype mainly describes that the source package approaches the elements of the target package, which is also known as a private merging.

<<bind>> - It connects template arguments to template parameters to design model elements from template. Bind is a constraint, indicates that the source can initialize the arrangement at a target location.

<<become>> - It depicts that the destination is analogous to the source, which consists of different purposes and values.

<<call>> - It defines that the source can conjure a target object method.

<<copy>> - It determines that the target object is self-reliant and can be a copy of a source object.

<<derive>> - This dependency type shows that the region of a source object can be measured from the destination object.

<<extend>> - Demonstrates that the behavior of the source element can be broadened or extended by the target element.

<<friend>> - It states the unique singularity of the source components in the target object.

<<include>> - It helps you to depicts the source component, which includes the nature of the other component at a specific location, like C or C++ function call.

<<import>> - It illustrates that any destination can import the source package element just like they are interpreted inside the destination target, also known as public merging.

<<instanceOf>> - It indicates that a instance is the source object of the target classifier.

<<instantiate>> - This stereotype defines that instances of the target object can be created with the help of a source object.

<<parameter>> - The supplier can be defined as the parameter of the client’s activities.

<<permit>> - It depicts that the source component has the permission to access the supplier whatever the announced visibility of the supplier component.

<<refine>> - It defines that the source element has extraordinary abstraction than a target object.

<<send>> - In this dependency, the client performs as an operation, which transfers some undefined target to the supplier.

<<substitute>> - It tells that the client may be substituted at runtime for the supplier.

<<use>> - The use stereotype demonstrates that source package elements can be present inside the target package, used whenever packages are modeled in UML.

Goals of Dependency Relationship

This relationship can be added to models to implement the following objectives:

• The dependency relationship doesn't show that all the elements in the client package are dependent. Instead, it connects two packages to indicate that at least one element in the client package is dependent on an element of the supplier package.
• It connects two classes to show that the connection among them is at a broad level of abstraction than an association relationship. It also specifies that the client class performs some of the following functions:
  • It operates a supplier class which has global extension temporarily.
  • It uses a supplier class for its applications as the parametertemporarily.
  • It sends information to the supplier class.
  • It adopts the supplier class as a local variable for its application.
• It connects the components to interfaces to show that they use operations that the interface specifies or reliant on the other components at the time of compilation.

Difference between Dependency and Association Relationship

Types and Description of Dependency Relationship