1.3.2.

Relationships among Classes

Classes can have different types of relationships among them. These relationships can be categorised
into following types.

 Associations
 Generalization
 Dependency

1.3.2.1. Association

Association is a design time relationship between classes that specifies that, at run time, instances of
those classes may have a link (navigable relationship between objects through which services may be
invoked). It is again of 3 types:

 Association
 Aggregation
 Composition

1.3.2.1.1. Association

Associations can be implemented as:

 A synchronous method call

 Or an asynchronous event signal

It is represented as a straight line between the two classes in UML.

Fig 1.3.2.1 shows an example of association relationship between two classes of an elevator system,
namely ‘MainController’ and ‘CarController’. MainController‘ class might contain a pointer named
‘CarController’, that would dereferenced at run-time.
 Fig 1.3.2.1. Association relationship between classes

Following C++ code snippet shows the same relationship between the two classes mentioned in the
example.

Association can be binary or unary.

In ‘Binary Association’, both classes know about each other. It is indicated by a straight line in UML.

In ‘Unary Association’ only one class know about the other, other doesn’t. It is indicated in UML by
an arrow starting from the class that has knowledge about the other class and pointing to the class
that doesn’t have knowledge about the previous class. Fig 1.3.2.2 shows the examples of unary and
binary associations.

Fig 1.3.2.2. Unary and Binary Associations

In UML diagrams, multiplicity of the relations can be shown. For example, if there is one HR Manager
class containing multiple Swipe Card objects, then in the unary relationship shown in Fig.1.3.2.2, we
can put ‘1’ at the ‘HR Manager’ side and ‘*’ at the side of ‘Swipe Card’. Followings are different types
of multiplicity used.

Symbol Meaning
1 One and only one
0..1 Zero or one
M..N From M to N
* Or 0..* From zero to any positive integer
1..* From one to any positive integer

Fig 1.3.2.3 shows examples of multiplicity in association relationship.

 Fig 1.3.2.3. Multiplicity in Associations

1.3.2.1.2. Aggregation

Aggregation is a specialized kind of association. Here one object contains other objects as part of it.

In UML, it is indicated by an empty diamond connected with a straight line, with the empty diamond
at the end of the object containing the parts and a straight line terminating at the parts.

There is no dependency between the composite and the parts with respect to the lifecycle i.e.

 The composite is not responsible for creating and destroying the parts.
 The parts may exist when the composite doesn’t exist.

Indeed, aggregation is normally treated in design and implementation identically to association i.e.
aggregation is implemented exactly in the same way as association.

Hence if confused, just pick one and implement accordingly.

Fig 1.3.2.4 shows aggregation relationship.

 Fig 1.3.2.3. Aggregation relationship

Following C++ code snippet illustrates the same. The code in blue indicates the aggregation
relationship.

Class CarController

private FloorController *pFloorController[5];

public void init();

public void addFloorController(FloorController *pFloorCtrl);

public void CarController :: addFloorController(FloorController *pFloorCtrl)

if(! pFloorCtrl)

// TODO: Do error handling

int floorNo = pFloorCtrl ->getFloorNo();

if(floorNo >= 5)

// TODO: Do error handling

pFloorController[floorNo] = pFloorCtrl;

1.3.2.1.3. Composition
Composition is a special case of aggregation, where creation and destruction of the parts are the
responsibility of the composite.

Generally the parts are created in the constructor (if the multiplicity is fixed) of the composite and
destroyed in the destructor of the composite.

For non-fixed multiplicity (e.g. ‘*’), the parts may be created dynamically (need not be in the
constructor).

Because of this lifecycle requirement, the composite has to exist prior to all of its parts come to
existence and will be destroyed only after all of its parts are destroyed.

Because of the creation and destruction responsibility of the composite, an object can have only one
composition owner (but, it can have multiple aggregation owners).

Fig 1.3.2.5 shows the composition relationship.

Fig 1.3.2.4. Composition relationship

Following C++ code snippet illustrates the same. The code in blue indicates the composition
relationship.
Class MainController {

private FloorController mFloorController[5];

private CarController mCarController[2];

MainController();

}
MainController :: MainController() {

// Instantiate Floor Controllers

for(int i = 0; i < 5; i++)

mFloorController[i] = FloorController();

// Instantiate Car Controllers

for(int j = 0; j < 2; j++)

mCarController[j] = CarController();

1.3.2.2. Generalization

Generalization means ‘Inheritance’ & ‘Substitutability’.

Inheritance means that the subclass (or the derived class) have same attributes, methods and
relations as the superclass (or base class) has. It can have its own attributes, methods and relations
as well.

A class can be derived from multiple base classes as well – it is called ‘multiple inheritance’.

Subclass can specialize the operations of the superclass. It means, it can re-implement the inherited
methods. This is called polymorphism.

Substitutability means that the instance of a subclass is freely substitutable wherever there is an
instance of the superclass.

Generalization relationship indicated by an empty triangle at the end of a straight line, with the
triangle pointing at the base class.

Following C++ code snippet shows the generalization relationship. Please note that ‘protected’
visibility is used here.

// Base class

class Shape {

public:

void setWidth(int w) {

width = w;

void setHeight(int h) {

height = h;

protected:
 int width;

int height;

};

// Derived class

class Rect: public Shape {

public:

int getArea() {

return (width * height);

};

void draw(Shape& shape)

void main(void) {

Rect rect;

Shape *pShape;

Rect *pRect;

rect.setWidth(5);

rect.setHeight(7);

pShape = &rect; // Substitution

pRect = (Rect*)(pShape); // Substitution

draw(rect); // Substitution

Fig 1.3.2.6 shows the same generalization relationship in UML.

 Fig 1.3.2.5. Generalization relationship

1.3.2.3. Dependency

A dependency can be used when a class has no direct relation to another class, but depends on it in
some way.

It is represented by a dashed arrowhead with dependency stereotype (<<>>) over it. Followings are
some of the important dependencies.

 One class may depend on another to build an executable from code with a <<usage>>
dependency
 <<bind>> dependency binds a set of actual parameters to a formal parameter list, as in C++
Templates.
 <<friend>> dependency enables the friend class to access all the parameters and methods of
the other class regardless of their visibility (private, public or protected).

There are other such dependencies as well.

Fig 1.3.2.7 shows the discussed dependency relationships in UML.

Fig 1.3.2.6. Different dependency relationships