Association (UML)
An association (Engl. Association ) is a model element in the Unified Modeling Language (UML), a modeling language for software and other systems.
An association describes a relationship between two or more classifiers , in the most common case a connection between exactly two classes . Associations define a relationship at the type level. At the instance level, the specific characteristics of an association are called links .
In addition to classes, any other classifier (e.g. interfaces or use cases ) can be related to one another using associations.
The possibility of involving more than two types in an association is rarely used. In this case, the association is called the n-ary association and is represented by a diamond on which n lines leading to the objects are attached. The association in UML is comparable to the relationship type in the entity relationship model , although there are detailed differences that are not immediately recognizable at first glance, but are of great importance in practice (see Object-relational impedance mismatch ) . In principle, the representation with a diamond is permitted, although not common, for associations with only two association ends, which means that the appearance is similar to the Chen notation of entity relationship models.
An association is called reflexive when it connects a classifier with itself. The two ends of the association point to the same type here. In the figure on the right, the association “ Elternteil/Kind-Beziehung” is reflexive.
Association ends
An association is graphically represented by a line. The fact that the ends of an association are not simply graphic points, but independent model elements are omitted here. But in contrast to the UML 1.4 there is no model element association end ( association end ) more, for the end of an association is since UML2 with the model element property ( Property modeled).
The figure on the right shows an example that the repository model saves an association end as an instance of the property metaclass behind the class diagram . Association ends can therefore have all the characteristics of a property :
- They can have a multiplicity expressed by a lower and an upper limit in the shape
untereGrenze..obereGrenze. - You can have a name .
- You can declare a visibility .
- You can specify whether the association end sorted ( ordered ) and / or unique ( unique is).
An association forms a kind of bridge between two types: if you start at the instance of the one involved type, you can easily navigate via an object relationship to the instance of the second type . The other direction is not prohibited, but it could be a hassle. UML2 now allows you to restrict the navigability of association ends. There are three ways in which navigability can be defined:
- No statement about navigability . The model makes no statement about navigability. It is unspecified and should only be defined at a later point in time, for example during software design.
- Permitted navigation . The model allows navigation via the end of the association.
- Navigation not allowed . The model prohibits navigation via the end of the association.
Associations that can be navigated on both sides are called bidirectional associations , while associations that can only be navigated at one end are called unidirectional .
The example on the left shows two associations between the same types. Because they have different names Rechnungsadresse fürand Lieferadresse für, you can tell them apart. The two small triangles support the reader. They show the reading direction for the name of the association, here for example Adresse [ist] Rechnungsadresse für Bestellung. An order can have two different instances of Adresse, which are distinguished by their role. One instance has the role lieferadresse, the other, optional, the role rechnungsadresse.
Aggregation and composition
If you want to emphasize the end of an association or strengthen the bond of an association, aggregation and composition are available as means. These are special cases of association - there are associations that are neither aggregation nor composition.
In the graphical representation of an aggregation , an empty diamond indicates the end that is connected to the whole. In the special case of the composition it is a filled diamond.
Aggregation
An exact definition is not given in UML2, rather it is pointed out that an aggregation varies depending on the application and modeler. A specific benefit can be z. B. deduce by giving special emphasis to one end of an association.
Basically, it is difficult to differentiate between association and aggregation. A weak indicator for the sensible use of an aggregation seems to be the existence of transitivities between the modeled classes. That is, if there is a part-whole relationship between A and B and also between B and C, then A must also be part of C.
Another indication could be the cascading of behavior from the whole to the parts: An operation defined for the whole must be implemented in such a way that it calls the same operation on all its parts. The fact that one cannot specify which operation this should be is due to the aggregation's status as a non-binding declaration of intent.
Composition is a special type of aggregation.
composition
Composition ( composite aggregation or composition ) as a special case of aggregation also describes the relationship between a whole and its parts . The difference to aggregation is that an object that contains parts as a whole is responsible for the existence of the parts .
An object can only be part of exactly none or a whole (multiplicity 0 or 1). The relationship between a room software object and a building software object could be viewed as a composition: a room is at any point in time a part of exactly one building.
Responsibility for existence means that the whole determines the life cycle of the parts . If the whole thing is deleted, the objects that were part of it at that time also disappear. The cascading behavior that is still undefined during the aggregation is the deletion during the composition. If the building software object is deleted from the application, it can make sense to also delete the room software objects it contains. The composition gives the building object the responsibility to do just that.
Attention: In an application, it can make sense to keep the room software objects. In a tour management application, for example, the buildings of the last venue are deleted, but the various rooms for the diva (relaxation room before the concert, music room, cloakroom and suite) remain because they have to be reassigned to buildings in the next city. Then of course you shouldn't use a composition. It is therefore misleading if the composition is explained with examples from the real world, in which there is also no responsibility for existence. A real building is made of stones. These stones do not go away if the building is demolished. The fact that the real rooms are no longer there afterwards has the same reason as with the building: their existence requires a certain cohesion of the stones.
A composition describes an acyclic directed graph ( whole ← part ← subpart ). As a relation , it is asymmetric and transitive .
Warning: The often claimed "existence dependency of the parts" is a myth. The specification actually says:
"[AggregationKind composite:] Indicates that the property is aggregated compositely, ie, the composite object has responsibility for the existence and storage of the composed objects. (German: Indicates that the property is composed by composition, ie that the compound is responsible for the existence and storage of the objects it contains.) "
Differences to UML 1.4
UML2 introduced the notation for the navigability of association ends.
In UML 1.4 there was a special model element AssociationEnd , which was replaced by Property in UML2 .
See also
Individual evidence
- ↑ UML specification , website of the Object Management Group
- ↑ UML 2.5.1, page 112