Relationships

When we are modeling the system first of all we start is identifying things. These things will not stay alone. They collaborate with each other means they are connected with others in some way. These connections between the things are known as relationships.

 

In object-oriented modeling, there are three main relationships between the things: 1) Dependency, 2) Associations and 3) Generalization.

 

 

Dependency

 

A dependency is a using relationship. In this relationship one thing depends on the other thing. The change in independent thing will affect the dependent thing. Dependency is graphically represented as a dashed directed line. The arrow head points towards the independent thing.

 

 

Generalization

 

The generalization relationship also known as the is-a relationship is between two things where one thing is general (superclass) and the other is specific thing (subclass) of the general thing.

 

Graphically, generalization is represented as a solid line with a hollow arrow head pointing towards the general thing.

 

A class with no parents and having one or more child classes is called root class. A class with no child’s is called a leaf class. A class with exactly one parent is known as single inheritance and a class having multiple parents is known as multiple inheritance.

 

 

Association

 

An association is a structural relationship which connects one thing with another. Given an association between two things, we can navigate from one thing to the other thing and vice versa. It is also common for a thing to have a self association.

 

An association which connects exactly two classes is known as binary association. An association which connects n number of classes is known as n-nary association.

 

Graphically association is represented as a solid line. Apart from this basic representation, an association has four adornments:

 

Name: An association can have a name which let’s you represent the meaning of the association. The name is written on top of the association. We can also represent the direction in which the name is read.

 

 

Role: A thing participating in an association will have a specific role. This role can be represented by writing it outside, near to the thing and below or above the association.

 

 

Multiplicity: When connecting things with association, we are concerned about how many objects of one class can connect across an instance of the association. This “how many” is known as multiplicity of an association’s role and is written as an expression.

 

 

Aggregation: In some cases we might come across “whole-part” relationships between two things, in which one thing is a part of another thing. Such relationship is known as an aggregation or also known as “has-a” relationship.

 

Aggregation is a special case of the association relationship. Aggregation is represented as a solid line with a hollow diamond head towards the whole thing.

 

 

Common Modeling Techniques

 

Modeling Simple Dependencies

 

To model this using relationship:

• Create a dependency pointing from the class with the operation to the class used as a parameter in the operation.

 

 

Modeling Single Inheritance

 

To model inheritance relationships:

• Given a set of classes, look for responsibilities, attributes, and operations that are common to two or more classes.
• Elevate these common responsibilities, attributes, and operations to a more general class. If necessary, create a new class to which you can assign these elements (but be careful about introducing too many levels).
• Specify that the more-specific classes inherit from the more-general class by placing a generalization relationship that is drawn from each specialized class to its more-general parent.

 

 

Modeling Structural Relationships

 

To model structural relationships:

• For each pair of classes, if you need to navigate from objects of one to objects of another, specify an association between the two. This is a data-driven view of associations.
• For each pair of classes, if objects of one class need to interact with objects of the other class other than as parameters to an operation, specify an association between the two. This is more of a behavior-driven view of associations.
• For each of these associations, specify a multiplicity (especially when the multiplicity is not *, which is the default), as well as role names (especially if it helps to explain the model).
• If one of the classes in an association is structurally or organizationally a whole compared with the classes at the other end that look like parts, mark this as an aggregation by adorning the association at the end near the whole.