Apply association classes, qualified and reflexive Associations
Apply Association Classes: 1)Qualified and 2) Reflexive Associations
Apply association classes, qualified associations, and reflexive associations. The reflexive association is used when objects in the same class can be associated. The entire association notation remains the same, except that the association line is drawn to and from the same class. Both examples below are equivalent expressions; one uses roles, whereas the other uses an association name.
This image illustrates reflexive associations in object-oriented modeling, specifically when an object is associated with itself,
here using the example of an `Employee`.
There are two ways shown:
Using Roles (left side):
Each Employee can act in two roles:
As a supervisor (supervising 0 or more subordinates).
As a subordinate (being supervised by 0 or 1 supervisor).
Multiplicity:
A supervisor has 0..* (zero or many) subordinates.
A subordinate reports to 0..1 (zero or one) supervisor.
This emphasizes the role names (supervisor and subordinate) to clarify the relationship.
Using Association Name (right side):
The relationship itself is given a name: Supervises.
The two ends are still Employees:
One employee supervises 0..* employees.
One employee is supervised by 0..1 other employee.
Instead of role names, the association itself (Supervises) describes the nature of the relationship.
Summary
Reflexive association happens when a class is related to itself.
by roles at the ends of the association (supervisor/subordinate)
by an association name (Supervises) with appropriate multiplicities.
Association Class
Association classes are used to identify information about an association. The information is placed in a class attached to the association that it describes by a dashed line.
Association class
Be on the lookout for association classes when you see a multiplicity of more than one used on both ends of the association.
The following series of images examines modeling many to many associations.
Modeling Advanced Associations 1) Examine many to many associations. Ask 'Is there information that we need about the links in this association?' 2) Identify the information that you need to track. Sometimes it will be a single attribute.
Sometimes it could be attributes and operations.
3) Place the information in a class definition
4) Attach the new class to the association using a dashed line. This method shows how you arrived at the need for a new class. It encapsulates everything you need to know about the relationship between objects in the association.
5) To implement the class you might later need to promote it to the status of a regular class. To do so, replace the original association and dashed lines with two new associations. Draw one association from the association class to one of the original class.
6) Name and redefine the multiplicity of the new association.
7) Repeat the process for the association between the association class and the other original class.
8) Delete the original association that has now been completely replaced.
Realization Semantics
A specification describes the behavior or structure of something without determining how the behavior will be implemented. An implementation provides the details about how to implement behavior in an effectively computable way. The relationship between an element that specifies behavior and one that provides an implementation is called realization. In general, there are many ways to realize a specification. Similarly, an element can realize more than one specification. Realization[1] is therefore a many-to-many relationship among elements.of structure or implementation.
The meaning of realization is that the client element must support all the behavior of the supplier element but need not match its structure or implementation. A client classifier, for example, must support the operations of the supplier classifier, and it must support all state machines that specify external behavior of the supplier. But any attributes, associations, methods, or state machines of the supplier that specify implementation are irrelevant to the client. Note that the client does not actually inherit the operations from the supplier. It must declare them itself or inherit them from an ancestor so that all the operations of the supplier are covered. In other words, the supplier in a realization indicates which operations must be present in the client, but the client is responsible for providing them. In the most general sense of realization, the names of the operations need not match, only their total behavior.
Certain kinds of elements, such as interfaces and use cases, are intended for specifying behavior, and they contain no implementation information. Other kinds of elements, such as classes, are intended for implementing behavior. They contain implementation information, but they can also be used in a more abstract way as specifiers. Usually, realization relates a specification element, such as a use case or an interface, to an implementation element, such as a collaboration or a class. It is possible to use an implementation element, such as a class, for specification. It can be placed on the specification side of a realization relationship. In this case, only the specification parts of the supplier class affect the client. The implementation parts are irrelevant for the realization relationship. More precisely, then, realization is a relationship between two elements in which the external behavior
specification parts of one constrain the implementation of the other. It might be thought of as inheritance of behavior specification without inheritance.
Qualified associations provide the same functionality as indexes. The notation has a bit of a twist, so pay attention.
To indicate that a customer can look up an order using the order's ordernumber attribute, the ordernumber attribute name is placed in a rectangular box on the Customer end of the association. All the other association notation remains intact but is pushed out to the edge of the rectangle. Because the qualifier is an attribute, it may include a data type.
Qualified association 1) Without the qualifier 2) With the qualifier
Use qualifiers to reduce the multiplicity in the same way you would use indexes in a database.
Note in the example how the multiplicity for Order changed from 0..* to 1 because the qualifier provided a unique key for Order.
1) Start with the class diagram of Customer and Order. The association shows one customer places zero or more orders.
2) To look up a customer's orders individually, identify a field that will uniquely identify the order. The attributes reveal the order number to be a unique identifier.
3) Place the qualifier box next to the class that will use it. The customer objects need to look up unique orders by ordernumber, so place the qualifier box next to the customer class.
4) Next copy the order number attribute name and data type and place them in the qualifier box.
5) Reduce the multiplicity to show that the ordernumber qualifier allows us to reference exactly one order at a time. The multiplicity is reduced to 1 because the qualifier is a unique value. If the qualifier is not unique, then it remains zero or more (*), but the actual number of objects decreases.
