Lecture 11-Week11 - Relationships in OOP

Object Oriented Programming
(CS1143)
Week 11
Department of Computer Science

Capital University of Science and Technology (CUST)
Outline
 Relationships in Object Oriented Programming

 Association
 Aggregation
 Composition
 Dependency
2
Association
3
Association
 Not all relationships between classes can be defined as inheritance.

 We encounter classes in object-oriented programming that have
other types of relationships with each other.
 For example, we can define a class named Person and another class
named Address. An object of the type Person may be related to an
object of type Address: A person lives in an address and the address
is occupied by a person.
 The Address class is not inherited from the Person class; neither the
other way.
 In other words, a person is not an address; an address is not a
person.
 We cannot define either class as a subclass of the other one.
4
Association Diagram
 A relationship of this type is shown in UML diagrams as a solid line

between two classes.
 An association diagram also shows the type of relationship between
the classes.
 This is shown by an arrow and text in the direction of the
corresponding class.
 Another piece of information represented in an association diagram
is multiplicity.
 Multiplicity defines the number of objects that take part in the
association.
 Multiplicity is shown at the end of the line next to the class.
 Figure on the next slide shows that one person can have only one
address, but one address can belong to any number of occupants.
5
6
7
Example
 We can define two classes: Course and Student.

 If we assume that at each semester a student can take up to five
courses, and a course can be taken by up to forty students, we can
depict these relationships in an association diagram, as shown next.
 This is a many-to-many relationship.
 An association representing a many-to-many relationship cannot be
implemented directly because it creates an infinite number of objects
in the program (circular relationship).
 Usually this type of association is implemented in a such a way that
this circular infinity is avoided.
 For example, a Student object can have a list of five course names
(not a complete Course object), and a Course object can have a list of
forty student names (not a complete Student object)
8
9
Aggregation
10
Aggregation
 Aggregation is a special kind of association in which the relationship

involves ownership. It models the “has-a” relationship.
 One class is called an aggregator and the other an aggregatee.
 An object of the aggregator class contains one or more objects of the
aggregatee class.
 The symbol for aggregation is a hollow diamond placed at the site of
the aggregator.
 The aggregation relationship is one-way.
 For example a Person can have a birth date (an object of the class
Date), but a Date object can be related to multiple events, not only
thebirth date of a person
11
Aggregation Contd.
 The life of an aggregatee is independent of the life of its aggregator.

 An aggregatee may be instantiated before the instantiation of the
aggregator and may live after it.
12
Example
 We create a Person class and a Date class.

 The Date class is independent and can be used to represent any
event.
 The Person class uses an object of the Date class to define the
birthday of a person.
13
14
15
16
17
18
19
Composition
20
Composition
 Composition is a special kind of aggregation in which the lifetime of

the containee depends on the lifetime of the container.
 For example, the relationship between a person and her name is an
example of composition.
 The name cannot exist without being the name of a person.
 The symbol for composition is a solid diamond placed at the side of
the composer.
 In the case of the relationship between the Employee and the Name,
the composer is the Employee.
21
Composition Contd.
 The distinction between aggregation and composition is normally

conceptual; it depends on how the designer thinks about the
relationship.
 For example, a designer may think that a name must always belong
to a person and cannot have a life of its own.
 Another designer may think that a name continues to exist even if
the person dies.
 The distinction also depends on the environment in which we are
designing our classes.
 For example, in a car factory, the relationship between a car and its
engine is composition; we cannot use the engine without installing it
in a car. In an engine factory, each engine has its own life cycle
22
Example
 We create an employee class in which an employee object has two

data members: salary and name.
 The name itself is an object of a class with three fields: first name,
initial, and last name.
23
24
25
26
27
28
Dependency
29
Dependency
 The third type of relationship that we can define between two classes
is dependency.
 Dependency is a weaker relationship than inheritance or association.
 Dependency models the “uses” relationship. Class A depends on class
B if class A somehow uses class B.
 It other words, class A depends on class B if A cannot perform its
complete task without knowing that class B exists.
 This happens when
 Class A uses an object of type B as a parameter in a member function.
 Class A has a member function that returns an object of type B.
 Class A has a member function that has a local variable of type B.
30
UML Class Diagram for Dependency
31
UML Sequence Diagram
 A sequence diagram shows the interaction between objects.

 The main function and each object have lifelines that show the
passing of time.
 The objects can be instantiated and their member function can be
called.
32
Example
 We have two classes, First and Second. Class First has a member function
called fun() that the user cannot call directly in the application.
 We want to use another function in the Second class called funny() to call
the function fun() in the First class.
 We must pass an instance of the First class inside funny() so the First class
can use it when it calls its fun() class
 The main function instantiates an object of the class First and an object of
the class Second.
 The main function calls the funny(. . .) member function of the class Second
and passes an object of the class First as a parameter.
 An object of the class Second can then call the fun() function of the class
First using the name of the object that received from main.
 The relationship between objects First and Second is dependency. Object
Second uses class First in its member function funny(. . .), and object Second
calls the member function of object First.
33
34
Example
 We use a comprehensive example to demonstrate the basics of

dependency relationships.
 Assume we want to create an invoice for the list of products sold. We
have a class named Invoice and a class named Product.
 The class Invoice uses instances of the class Product as a parameter
in one of its member functions (add).
35
Class Diagram
36
Sequence Diagram
 The main function must instantiate two objects of type Product and
one object of type Invoice.
 The main function then calls the add function in the Invoice class to
add the products to the invoice, but it must get the price of each
product from the corresponding object.
37
38
39
40
41
42
43
This is all for Week 11
44

Lecture 11-Week11 - Relationships in OOP

Uploaded by

Copyright:

Available Formats

Lecture 11-Week11 - Relationships in OOP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 11-Week11 - Relationships in OOP

Uploaded by

Copyright:

Available Formats

Object Oriented Programming

Department of Computer Science

 Relationships in Object Oriented Programming

 Not all relationships between classes can be defined as inheritance.

 A relationship of this type is shown in UML diagrams as a solid line

 We can define two classes: Course and Student.

 Aggregation is a special kind of association in which the relationship

 The life of an aggregatee is independent of the life of its aggregator.

 We create a Person class and a Date class.

 Composition is a special kind of aggregation in which the lifetime of

 The distinction between aggregation and composition is normally

 We create an employee class in which an employee object has two

 A sequence diagram shows the interaction between objects.

 We use a comprehensive example to demonstrate the basics of

You might also like