Enter the role names at the end of the lines if the modeler defines roles for both partners.

 

 

You can use role names at the end of the association lines to describe the relationships between the classes involved. In the figure, a person could appear in the role of an employee or in the role of a company director.

 

In the recursive association shown in the figure, the roles of child and parent are defined using role names. Two instances of the LCL_PERSON class have a relationship with each other and represent two roles.

 

 

If the association is used to link two classes, then a special class can represent this relationship.

 

The characteristics of the relationship are described using the attributes of the association class. A dotted line connects this class to the association line.

 

Aggregation and Composition

Aggregation and composition are specializations of association. Aggregation and composition show that an object can contain other objects. The relationship can be described using the phrases “consists of” or “is a part of”. For example, a car consists of wheels and an engine, among other things.

 

Aggregation and composition appear as a line between two classes. They are labeled using a small rhombus. The rhombus indicates aggregation or composition. Otherwise, the notation conventions are the same used for associations.

 

The composition is a specialization of aggregation. Composition means that the contained object cannot exist without the aggregation (for example, a car reservation cannot exist without the car rental agency). Therefore, the cardinality of this kind of aggregate is at least one. The lifetime of the individual parts is linked to the lifetime of the aggregate. This means that parts are created either at the same time as the aggregate or after the aggregate, and are destroyed, either at the same time as the aggregate or before the aggregate. In UML notation, a filled-in rhombus denotes composition.

 

 

Generalization and Specialization

Generalization and specialization relationships are always bidirectional. For example, class lcl_truck can be generalized as a special class of lcl_vehicle. Generalization and specialization relationships are denoted by a triangular arrow. This arrow always points from the specialized class to the generalized class. The level of generalization increases in the direction of the arrow. Trees can be built up using these relationships.

 

 

The Delegation Principle

In delegation, two objects are involved in handling a request. The recipient of the request assigns the execution of the request to a delegate. In this example, the driver (object driver) sends the message get_fuel_level ( ) to the vehicle (object car). When the message is received, the car sends a message to the tank (object tank) to find out what the tank contains. In other words, the car delegates the task to the tank. If necessary, the car formats the information containing the current value of the contents of the tank before passing it back to the driver.