Definition of relationships in UML

There are six kinds of relationships in UML definitions: dependency, generic, association, implementation, aggregation, and combination. The definition and presentation methods are described below.

Dependency (Dependency): The change in element a affects element B, but the opposite is not true, then the relationship between B and A is dependent, B relies on A; the generic and implementation relationships are semantically dependent, but are described separately for their more specific purposes. UML uses dotted lines with arrows to represent dependency relationships, and arrows to dependent elements.

Genus (generalization): Usually referred to as the Inheritance (special individual is kind of the general individual) relationship, do not have to explain more. UML uses a solid line with a hollow arrow to represent the generalization relationship, and the arrows point to the general individual.

Implementation (realize): element A defines a convention, and element B implements this convention, then the relationship between B and A is realize,b realize a. This relationship is most commonly used in interfaces. UML uses hollow hollow arrows and dashed lines to represent realize relationships, and arrows point to elements that define conventions.

Association (Association): the structured relationship between elements is a weak relationship, and the elements that are associated can often be considered independently of each other. In UML, a solid line is used to represent the dependency relationship, and the arrows point to the dependent element.

Aggregation (Aggregation): A special case of an association relationship that represents the relationship between a part and the whole (part A has). UML uses a solid line with a hollow diamond head to represent the aggregation relationship, and the Diamond Head points to the whole.

Combination (composition): A combination is a variant of the aggregation relationship that represents a stronger combinatorial relationship between elements. If it is a combinatorial relationship, if the whole is destroyed, the individual is bound to be destroyed, and the aggregated individual may be shared by more than one whole, not necessarily destroyed by the destruction of a whole. In UML, the solid line with the solid core diamond Head is used to represent the composition relationship, and the Diamond Head points to the whole. Relationship between

The following example will show the relationships independently for a specific purpose. Although the syntax is correct, these examples can be further refined to include more semantics within their valid range.

Dependence (Dependency)

A "use" relationship between entities implies a change in the specification of an entity and may affect other instances that depend on it ( figure D). More specifically, it can be converted to any type of reference to a class or object that is not in the scope of an instance. This includes a local variable, a reference to an object obtained through a method call (as shown in the following example), or a reference to a static method of a class (without an instance of that class). You can also use dependencies to represent the relationship between packages and packages. Because the package contains classes, you can indicate the relationship between packages and packages based on the relationships between the classes in those packages.

Figure D

Association (Association)

A structured relationship between entities indicates that objects are interconnected. The arrows are optional and are used to specify navigation capabilities. If there are no arrows, the hint is a two-way navigation capability. In Java, an association ( Figure E) is converted to a variable of an instance scope, just like the code shown in the "Java" area of Figure E. Additional modifiers can be attached to an association. The multiplicity (multiplicity) modifiers imply a relationship between instances. In the demo code, the employee can have 0 or more timecard objects. However, each timecard only belongs to a single Employee.

Figure E

Aggregation (Aggregation)

Aggregation ( figure F) is a form of association that represents a global/local relationship between two classes. Aggregation implies that the overall concept is at a higher level than the local one, and the association implies that two classes are conceptually at the same level. Aggregations are also converted to an instance scope variable in Java.

The difference between association and aggregation is purely conceptual and is strictly reflected in semantics. Aggregation also implies that there is no loop in the instance diagram. In other words, it can only be a one-way relationship.

Figure F

Synthesis (composition)

Synthesis ( fig. G) is a special form of aggregation, implying "local" within the "whole" life-cycle responsibility. Synthesis is also not shared. Therefore, while the part does not necessarily have to be destroyed with the destruction of the whole, the whole is either responsible for maintaining a partial survival state or for destroying it. Local cannot be shared with other whole. However, the whole can transfer ownership to another object, which then assumes the lifetime responsibility.

The relationship between employee and timecard may be more appropriate to be expressed as "compositing" rather than as "association."

Figure G

Generalization (generalization)

Generalization ( figure H) represents the relationship between a more generalized element and a more specific element. Generalization is a UML element that is used to model inheritance. In Java, this relationship is represented directly by the extends keyword.

Figure h

Implementation (Realization)

Instance ( figure I) A relationship specifies a contract between two entities. In other words, one entity defines a contract and the other entity guarantees the fulfilment of the contract. When modeling a Java application, the implementation relationship can be represented directly by the Implements keyword.

Figure I