DCIT 201

PROGRAMMING I

Session 1 – Fundamental Concepts of OOD and OOP

Lecturer: Mr. Paul Ammah, CSD

Contact Information: [email protected]

Department of Computer Science

School of Physical and Mathematical Sciences
2023/2024
 Session Overview
• To explain how a software design may be
represented as a set of interacting objects that
manage their own state and operations
• To describe the activities in the object-oriented
design process
• To introduce various models that describe an object-
oriented design
• To show how the UML may be used to represent
these models

Slide 2
 Session Outline
The key topics to be covered in the session are as
follows:
• Objects and object classes
• An object-oriented design process
• Unified Modeling Language

Slide 3
 Object-oriented development
• Object-oriented analysis, design and programming are
related but distinct
• OOA is concerned with developing an object model of
the application domain
• OOD is concerned with developing an object-oriented
system model to implement requirements
• OOP is concerned with realising an OOD using an OO
programming language such as Java or C++

Slide 4
 Objects and object classes
• Objects are entities in a software system which
represent instances of real-world and system entities
• Object classes are templates for objects.
• They may be used to create objects
• Object classes may inherit attributes and services
from other object classes

Slide 5
 Object-Oriented Programming
• So far we structure our programs by decomposing tasks
into methods.
• This is an excellent practice, but it is difficult to understand
and update a program that consists of a large collection of
methods.
• To overcome this problem, computer scientists invented
object-oriented programming, a programming style in
which tasks are solved by collaborating objects.
• Each object has its own set of data, together with a set of
methods that act upon the data.

Slide 6
 Object-Oriented Programming
• When you develop an object-oriented program, you create
your own objects that describe what is important in your
application.
• For example, in a student database you might work with
Student and Course objects.
• These objects then must be supplied with methods.
• In Java for example, a programmer does not implement a
single object.
• Instead, the programmer provides a class.

Slide 7
 Class
• A class describes a set of objects with the same behavior.
• For example, the String class describes the behavior of all
strings.
• The class specifies how a string stores its characters, which
methods can be used with strings, and how the methods
are implemented.
• The set of all methods provided by a class, together with a
description of their behavior, is called the public interface
of the class.

Slide 8
 Abstraction
• Abstraction refers to using simplified classes, rather than
complex implementation code, to access objects.
• Often, it's easier to design a program when you can
separate the interface of a class from its implementation.
• In OOP, you can abstract the implementation details of a
class and present a clean, easy-to-use interface through the
class member functions.
• Abstraction helps isolate the impact of changes made to
the code so if an error occurs, the change only affects the
implementation details of a class and not the outside code.

Slide 9
 Encapsulation
• The process of providing a public interface, while hiding the
implementation details, is called encapsulation.
• You will specify a set of public methods and hide the
implementation details.
• Other programmers on your team can then use your classes
without having to know their implementations, just as you
are able to make use of the String class.

Slide 10
 Inheritance
• In object-oriented design, inheritance is a relationship
between a more general class (called the superclass) and a
more specialized class (called the subclass).
• The subclass inherits data and behavior from the
superclass.
• Example:
– Every car is a vehicle.
– Cars have the ability to transport people from one place to
another.
– The class Car inherits from the class Vehicle. In this relationship, the
Vehicle class is the superclass and the Car class is the subclass.

Slide 11
Inheritance cont’d

Slide 12
 Inheritance cont’d
• Inheritance allows designer to reuse code from superclass
to subclass.

Slide 13
 Polymorphism
• Polymorphism refers to the creation of items that have
similar behaviour.
• For example, objects may override common parent
behaviours with particular child behaviours through
inheritance.
• Method overriding and method overloading are two ways
that polymorphism enables the same method to perform
various actions. 

Slide 14
 Objects
• An object is an entity which has a state and a defined set of
operations which operate on that state.
• The state is represented as a set of object attributes.
• The operations associated with the object provide services to
other objects (clients) which request these services when some
computation is required.
• Objects are created according to some object class definition.
• An object class definition serves as a template for objects.
• It includes declarations of all the attributes and services which
should be associated with an object of that class.
 Objects
• An object is an instance (member) of a class.
• The beauty is we can create multiple instances of the same
object to do the same kind of work with different
circumstances (variable setting).
• The instance will keep track of its own stack of variables
independent of other instances of the same class.
• An object may be, a graphic, a person, a device, a
magazine, a book, a tape, a video clip, a sound clip, or some
other data value, depending upon the class of which it is a
member.

Dr. JAMAL-DEEN ADBULAI, CSCD Slide 16

 OOP Design
• Designing object-oriented applications requires somewhat
different tools and problem solving strategies.
• Modules become part of object; called methods and
interactivity, also part of an object, become the events that
drive the actions of the application.
• To describe these object and their interactions new tools
need to be explored.

Slide 17
 Benefits of OOP
• Modularity. Encapsulation enables objects to be self-contained, making
troubleshooting and collaborative development easier.
• Reusability. Code can be reused through inheritance, meaning a team
does not have to write the same code multiple times.
• Productivity. Programmers can construct new programs quicker through
the use of multiple libraries and reusable code.
• Easily upgradable and scalable. Programmers can implement system
functionalities independently.
• Interface descriptions. Descriptions of external systems are simple, due
to message passing techniques that are used for objects communication.
• Security. Using encapsulation and abstraction, complex code is hidden,
software maintenance is easier and internet protocols are protected.
• Flexibility. Polymorphism enables a single function to adapt to the class it
is placed in. Different objects can also pass through the same interface.
Slide 18
 Using UML as a Design Tool
• Unified Modeling Language (UML) is a relatively new way of
model an object-oriented system.
• UML was created at Rational Software by Grady Booch, Ivar
Jacobson, and Jim Rumbaugh with other leading
methodologists, software vendors, and users.
• Like pseudocode, flowcharts, and hierarchy charts are used
to describe linear programming structures and processes,
UML is used to describe object-oriented processes.
• There are three types of UML diagramming classifications:
behavioral, interaction and structural

Slide 19
 UML classifications: Behavioral
• Behavioral describe the behavior of a process.
– Use Case diagram: describes the functionality of a system using
actors and their process scenarios.
– Activity diagram: describes the flow of control within a process or
system.
– UML State Machine diagram: describes the states within a system
and the transitions states.

Slide 20
 UML classifications: Interaction
• Interaction diagrams describe the interactions between
objects.
– Sequence diagram: describe the object communication sequences.
– Timing diagram: describe an object interaction that has critical
temporal components.
– Communication diagram: describes object communication
messaging.
– Interaction overview diagram: Describes an overview of
interactions in a system.

Slide 21
 UML classifications: Structural
• Structural diagrams refer to those components that are
structural and not temporal.
– Deployment diagram: Describes the components used for the
implementation phase of a project.
– Object diagram: Describes a view of the structure of a modeled
system with a temporal component.
– Class diagram: Describes the structure of a system with its classes,
attributes and class relationships.
– Component diagram: Describes how the application may be
broken up into different components and the relationship between
each component.

Slide 22
UML classifications: Structural cont’d
– Composite Structure diagram: Describes the internal structure
of a class.
– Packaging diagram: Describes how the system is split into
different related groupings.
– Profile diagram: Describes an application or process specifically
for a particular business model or programming language.

Slide 23
 Use Case Diagrams
• Use case diagrams describe how a system functions from the
user’s standpoint.
• They present who may use what part of the system.
• There are basically two parts of a use case diagram: the actor
and the use case.
• The actor represents the users of the system, including human
and nonhuman entities.
• The use case describes the services required by the actor.

Slide 24
 Use Case Diagrams cont’d
• The use case is represented by an oval with the service or
function written inside.
• Lines connecting the actor and the use case indicate
communication.
• The series of use cases required for this part of the solution
are encased in a rectangle with the name of the system in
the top part of the rectangle.

Slide 25
Use Case Diagrams cont’d

Slide 26
 Class Diagrams
• Class diagrams graphically describe how a class functions.
• They describe the class, their attributes, and their methods.
• The diagram is divided into three sections;
– the topmost contains the name of the class.
– The middle section contains a list of attributes (variables) and
– the bottom section contains a list of methods used by the class.

Slide 27
Class Diagrams cont’d

Slide 28
 Sequence Diagrams
• Sequencing diagrams graphically present the interactivity
between objects.
• The interactions are represented as messages in the
diagram.
• The diagram shows the actions by the user and the
subsequent actions that result between objects.

Slide 29
Sequence Diagrams cont’d

Slide 30
 Activity Diagram
• An activity diagram describes the flow of activities.
• This type of diagram is similar to a data flow chart. It
specifies what happens and when. The major difference is
in the symbols used.
• Because general activities are represented and not specific
instructions, all activities use a flattened ellipse.
• It can contain decision structures as necessary.
• The flow may be from top down or may be from left to
right.

Slide 31
Activity Diagram cont’d

Slide 32
 Communication Diagram
• Communication diagrams are used to show the messaging
between objects in the object-oriented design.
• It also shows the role of the object in the interaction with
other object as well as the relationship between objects.
• Communication diagrams are typically a combination of
object taken from Class, Sequence, and Use Case diagrams.

Slide 33
Communication Diagram cont’d

Slide 34
 References
• Big Java Late Objects (Horstmann, 2012)
• Problem Solving And Programming Concepts (Sprankle,
2012)
• Class diagram https://www.youtube.com/watch?v=UI6lqHOVHic
• Sequence Diagrams https://www.youtube.com/watch?v=pCK6prSq8aw
• Use case Diagrams: https://www.youtube.com/watch?v=zid-MVo7M-E

Slide 35