UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
Chapter one
Understanding the basic object oriented concepts
System is group of interrelated procedures used for a business function, with an identifiable
boundary, working together for some purpose.

Is a collection of parts that work together to achieve a goal / task.

is an interrelated set of business procedures (or components) used within one business unit,
working together for some purpose.
Characteristics of Systems

Boundary – divides system from environment

Inputs – data from environment to system

Output – data from system to environment

Components – subparts of systems operating independently (objects)

Interrelationships – associations between components of a system

Interfaces – mechanism for interacting with a component
 Goal of system is to solve problem.
Systems Analysis: Systems Analysis is the study of a business problem domain for the purpose of
recommending improvements and specifying the business requirements for the solution.

Identifying the problem

What needs to be done

Determining system requirement
Systems Design: Systems Design is the specification or construction of a technical, computer
based solution for the business requirements identified during systems analysis.
Translating alternative solution generated by analysis phase into detailed logical and physical
system specifications.
–
Logical design: not tied to any hardware or software platform
–
Physical design: specific programming languages, databases, architectures
 Goal: identify how the task will be accomplished
Systems Analysis and Design (SAD): Information systems analysis and design is a method used
by companies to create and maintain information systems that perform basic business functions.
1
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
Main goal of SAD is to improve organizational systems through developing or acquiring
application software that can help employees accomplish key business tasks more easily and
efficiently.
System Development life cycle(SDLC)
1. Preliminary Investigation (Feasibility Study) : An important outcome of the preliminary
investigation is determining whether the system to be developed is feasible or not.
2. Requirement Analysis (Analysis) : Involves study of the current business system in detail
and to find out how it works and where the improvements have to be made.
3. Design of the System: The design phase states how a system will meet the requirements
identified during the systems analysis phase as mentioned in the Requirements
Specifications.
Identification of data entry forms, data elements, reports, outputs the new system should
produce, data elements and tables for database.
Sketch the form or display as expected to appear at the end of completion of the system.
Computation procedures explaining the process of deriving the output from given input.
4. Software Construction: Actual construction (coding) of the programs
5. System Testing

Actual software code construction

Unit Testing: White Box testing

After the programs are tested individually, the system as a whole needs to be tested.

All the software modules are integrated and tested to ensure that they do not fail i.e. it
will run according to specifications as mentioned in requirement specification
document and in the way the users expected it to.

Special test data is prepared as input for processing and the results are examined to find
out any deviations from the desired results.
6. System Implementation

Developed system is deployed at the user’s site for use

User personnel are trained

The data files needed by the system are constructed
7. System Maintenance
2
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS

Due to environmental changes, the software may turn obsolete and it may call for
modifications and enhancements for its effective use.

The activity of system maintenance may vary depending on the scale of modifications
and enhancements.
Two orthogonal view of software
Software: is a set of instruction that used to solve a specific problem.
Software Process: is a software engineering activity needed to transform requirement in to
software.
User needApplication DomainSoftware solution
A software development methodology is a series of processes that lead to the development of an
application.
Structured Paradigm Vs Object-Oriented Paradigm:
Paradigm: (pronounced para-dime): An overall strategy or viewpoint for doing things. A
paradigm is a specific mindset.
The structured paradigm is a development strategy based on the concept that a system should
be separated into two parts: data (modeled using a data/persistence model) and functionality
(modeled using a process model). In short, using the structured approach, you develop applications
in which data is separate from behavior in both the design model and in the system implementation
(that is, the program).
Structured paradigm aimed at improving the clarity, quality, and development time of a computer
program
object-oriented paradigm is that instead of defining systems as two separate parts (data and
functionality), you now define systems as a collection of interacting objects. Objects do things
(that is, they have functionality) and they know things (they have data).
Object-Oriented paradigm is based upon objects (having both data and methods) that aims to
incorporate the advantages of modularity and reusability. Objects, which are usually instances of
3
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
classes, are used to interact with one another to design applications and computer programs.
TRADITIONAL APPROACH
OBJECT
ORIENTED
SYSTEM
DEVELOPMENT
Collection of procedures(functions)
Combination of data and functionality
Focuses on function and procedures, Focuses on object, classes, modules that
different styles and methodologies for can be easily replaced, modified and
each step of process
reused.
Moving from one phase to another phase Moving from one phase to another phase
is complex.
is easier.
Increases duration of project
decreases duration of project
Increases complexity
Reduces complexity and redundancy
Consider the design of an information system for a university. Taking the structured approach,
you would define the layout of a database and the design of a program to access that data. In the
database would be information about students, professors, rooms, and courses. The program would
enable users to enroll students in courses, assign professors to teach courses, schedule courses in
certain rooms, and so on. The program would access and update the database, in effect supporting
the daily business of the school.
Now consider the university information system from an object-oriented perspective. In the real
world, there are students, professors, rooms, and courses. All of these things would be considered
objects. In the real world, students know things (they have names, addresses, birth dates, telephone
numbers, and so on) and they do things (enroll in courses, drop courses, and pay tuition). Professors
also know things (the courses they teach and their names) and they do things (input marks and
make schedule requests). From a systems perspective, rooms know things (the building they’re in
4
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
and their room number) and should be able to do things, too (such as tell you when they are
available and enable you to reserve them for a certain period of time). Courses also know things
(their title, description, and who is taking the course) and should be able to do things (such as
letting students enroll in them or drop them).
Object Oriented System Development Activity’s
1. Requirements elicitation: -The client and developers define the purpose of the system. The
result of this activity is a description of the system in terms of actors and use cases. Actors is
an entity that interact with the system. Users, Other systems, computers Use cases are general
sequences of events that describe all the possible actions between an actor and the system for
a given piece of functionality. During requirements elicitation, the client and developers also
agree on a set of nonfunctional requirements.
2. Analysis: During analysis, developers aim to produce a model of the system that is correct,
complete, consistent, unambiguous, realistic, and verifiable. Developers transform the use
cases produced during requirements elicitation into an object model that completely describes
the system. During this activity, developers discover ambiguities and inconsistencies in the
use case model that they resolve with the client. The result of analysis is an object model
annotated with attributes, operations, and associations
3. System design: During system design, developers define the design goals of the project and
decompose the system into smaller subsystems that can be realized by individual teams.
Developers also select strategies for building the system, such as the hardware/software
platform on which the system will run. The result of system design is a clear description of
each of these strategies, a subsystem decomposition, and a deployment diagram representing
the hardware/software mapping of the system.
4. 4. Object design developers define custom objects to bridge the gap between the analysis
model and the hardware/ software platform defined during system design. Include:
restructuring the object model to attain design goals. optimizing the object model for
performance. precisely describing object and subsystem interfaces. The result of the object
design activity is a detailed object model annotated with constraints and precise descriptions
for each element.
5
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
5.
Implementation: Developers translate the object model into includes implementing the
attributes and methods of each object and integrating all the objects such that they function as
a single system. source code.
6. Testing The goal of testing is to discover as many faults as possible. Developers find the
difference between the system and its model by executing the system or parts of it with simple
input data sets. The planning of test phase occurs in parallel to the other development activities.
Object-Oriented Analysis
Object–Oriented Analysis (OOA) is the procedure of identifying software engineering
requirements and developing software specifications in terms of a software system’s object model,
which comprises of interacting objects. The main difference between object-oriented analysis and
other forms of analysis is that in object-oriented approach, requirements are organized around
objects, which integrate both data and functions. They are modelled after real-world objects that
the system interacts with. In traditional analysis methodologies, the two aspects - functions and
data - are considered separately.
Grady Booch has defined OOA as, “Object-oriented analysis is a method of analysis that examines
requirements from the perspective of the classes and objects found in the vocabulary of the
problem domain”. The primary tasks in object-oriented analysis (OOA) are:

Identifying objects

Organizing the objects by creating object model diagram

Defining the internals of the objects, or object attributes

Defining the behavior of the objects, i.e., object actions

Describing how the objects interact
Object-Oriented Design
Object–Oriented Design (OOD) involves implementation of the conceptual model produced
during object-oriented analysis. In OOD, concepts in the analysis model, which are
technology−independent, are mapped onto implementing classes, constraints are identified and
interfaces are designed, resulting in a model for the solution domain, i.e., a detailed description of
how the system is to be built on concrete technologies. The implementation details generally
include:

Restructuring the class data (if necessary),

Implementation of methods, i.e., internal data structures and algorithms,
6
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS

Implementation of control, and

Implementation of associations.
Grady Booch has defined object-oriented design as “a method of design encompassing the process
of object-oriented decomposition and a notation for depicting both logical and physical as well as
static and dynamic models of the system under design”.

Class: a set of objects that share a common structure and a common behavior
–
Is a software abstraction of an object, effectively, a template from which objects are
created.
–
A class defines both data (attributes) and code (operations/methods).
–
a collection of method or function
–
Is a blue print of object.
–
Main role of a class is to define the properties and procedures (the state & behavior)
and applicability of its instances

Object: is anything, real or abstract, about which we store data and those methods that
manipulate the data.
–
Is a software construct that mirrors a concept in the real world e.g. a person, place,
thing, event, concept, screen, or report.
–
Conceptually, each object is responsible for itself.
–
In an object-oriented system, everything is an object: numbers, arrays, records, fields,
files, forms, an invoice, etc.
–
An object is an entity: - It knows things (has attributes), It does things (provides
services or has methods).
–
Is an instance of class.
–
If a class can be thought of as a table, an object can be thought of as a record
occurrence

Object space. The memory space, including all accessible permanent storage, in which
objects exist and interact with one another

Attribute: is equivalent to a data element in a record.
–
From a programming point of view, it is a local variable applicable only to a single
object.

Method: can be thought of as either a function or procedure.
7
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
–
Methods access and modify the attributes of an object.
Objects and Classes
•
The OO paradigm is based on building systems from items called objects.
•
An object is any person, place, thing, event, concept, screen, or report.
•
A class generalizes/represents a collection of similar objects and is effectively a template
from which to create objects.
Why Object Oriented?
To create sets of objects that work together concurrently to produce s/w that better, model their
problem domain that similarly system produced by traditional techniques.
– Possible to directly represent real world objects in the computer system.
It adapts to: 1. Changing requirements,
2. Easier to maintain,
3. More robust,
4. Promote greater design,
5. Code reuse
1.2. The Potential Benefits of Object Orientation:
Object Oriented Development (OOD) has been touted as the next great advance in software
engineering. It promises to reduce development time, reduce the time and resources required to
maintain existing applications, increase code reuse, and provide a competitive advantage to
organizations that use it. While the potential benefits and advantages of OOD are real, excessive
hype has led to unrealistic expectations among executives and managers. Even software developers
often miss the subtle but profound differences between OOD and classic software development.
Simplicity: software objects model real world objects, so the complexity is reduced and the
program structure is very clear.
Reusability: Reusability is a desired goal of all development and is based on the reluctance of
reinventing something when it has already been invented. Objects contain both data and functions
that act on data, objects can be thought of as self-contained "boxes" (encapsulation). This feature
makes it easy to reuse code in new systems. Messages provide a predefined interface to an object's
data and functionality. If you know this interface, you can make use on an object in any context
you want
8
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
Faster Development: OOD (Object oriented development) leads to faster development. Many of
the claims of potentially reduced development time are correct in principle.
Maintainable: OOP methods make code more maintainable. Objects can be maintained
separately, making locating and fixing problems easier. The principles of good OOP design
contribute to an application's maintainability.
Scalable: Object oriented applications are more scalable then structured approach. As an object's
interface provides for reusing the object in new software, it also provides all the information
needed to replace the object without affecting other code. This makes it easy to replace old and
aging code with faster algorithms and newer technology.
Modularity: Object-oriented systems have a natural structure for modular design: objects,
subsystems, framework, and so on. Thus, OOD systems are easier to modify. OOD systems can
be altered in fundamental ways without ever breaking up since changes are neatly encapsulated.
The Potential Drawbacks of OO
Nothing is perfect including OO. While many exiting benefits exist to OO, they come at a price:
1. OO requires greater concentration on requirements analysis and design
•
You cannot build a system that meets users’ needs unless you know what those
needs are (you need to do requirements)
•
You cannot built a system unless you know how it all fit together (you need to do
analysis and design
2. Developers must closely work with users
•
Users are the experts
•
But they have their own jobs to do (busy)
3. OO requires a complete change in the mindset on the part of individuals
•
they should understand the benefits of OO
4. Many OO benefits are long term
•
OO truly pays off when you extend and enhance your system
5. OO demands up front investments in training education and tools
•
Organizations must train and educate their development staff.
•
Buy books, development tools and magazines
Over view of unified approach
– Is a metedology for software development activity
9
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
– The Unified Approach (UA) specifies the tasks or steps to develop an application
– Is a popular iterative system development metedology
The UA consists of the following concepts:

Usecase driven approach

Utilizing the UML for modeling

Object oriented analysis

Object oriented design

Repositories of reusable classes and maximum reuse

The layered approach

Incremental development and prototyping

Continuous testing
Basic concept of object oriented
Inheritance
Inheritance is the mechanism that permits new classes to be created out of existing classes by
extending and refining its capabilities. The existing classes are called the base classes/parent
classes/super-classes, and the new classes are called the derived classes/child classes/subclasses.
The subclass can inherit or derive the attributes and methods of the super-class(es) provided that
the super-class allows so. Besides, the subclass may add its own attributes and methods and may
modify any of the super-class methods. Inheritance defines an “is – a” relationship.
Example from a class Mammal, a number of classes can be derived such as Human, Cat, Dog,
Cow, etc. Humans, cats, dogs, and cows all have the distinct characteristics of mammals. In
addition, each has its own particular characteristics. It can be said that a cow “is – a” mammal.
10
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
The diagram depicts the UML modeling notation for inheritance.
The way you would read the diagram is "B inherits from A." In other words, B is a direct subclass
of A and A is the direct superclass.
Types of Inheritance
– Single Inheritance: A subclass derives from a single super-class.
– Multiple Inheritance: A subclass derives from more than one super-classes.
–
Multilevel Inheritance: A subclass derives from a super-class which in turn is derived
from another class and so on.
– Hierarchical Inheritance: A class has a number of subclasses each of which may have
subsequent subclasses, continuing for a number of levels, so as to form a tree structure.
Association
Association depicts the relationship between objects of one or more classes.
Is a weak form of connection: the objects may be part of a group, or family, of objects but they’re
not completely dependent on each other.
•
Bidirectional association -An association that can be traversed in both directions.
•
Recursive association – an association in which the objects involved in it are instances of
the same class.
Degree of an Association
Degree of an association denotes the number of classes involved in a connection. Degree may be
unary, binary, or ternary.

A unary relationship connects objects of the same class.

A binary relationship connects objects of two classes.

A ternary relationship connects objects of three or more classes.
When you model associations in UML class diagrams, you show them as a thin line connecting
two classes.
Eg Pilot
Planes Can
Flown by
Planes
Aggregation
means putting objects together to make a bigger object. Manufactured items usually form
aggregations: for example, a microwave is made up of a cabinet, a door, an indicator panel, buttons,
a motor, a glass plate, a magnetron, and so on. Aggregations usually form a part–whole hierarchy.
11
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
Aggregation is a relationship among classes by which a class can be made up of any combination
of objects of other classes. It allows objects to be placed directly within the body of other classes.
Aggregation is referred as a “part–of” or “has– a” relationship, with the ability to navigate from
the whole to its parts. An aggregate object is an object that is composed of one or more other
objects.
All objects except the most basic ones, are composed of and may contain other objects.
Breaking down objects into the objects from which they are composed is decomposition.
Ex: a spreadsheet is an object composed of cells, and cells are objects that may contain text,
mathematical formulas, etc.,
When you model associations in UML class diagrams, you place a white diamond on the ‘whole’.
Composition
Composition is a strong form of aggregation in which the "whole" is completely responsible for
its parts and each "part" object is only associated to the one whole object.
For example, at any given time, an engine is part of one and only one airplane (otherwise, you
have a serious problem).
Furthermore, no object other than the airplane will directly collaborate with an engine object; for
example, passenger objects on the airplane cannot directly request that an engine increase its speed.
When you model associations in UML class diagrams, you place a black diamond on the ‘whole’.
Encapsulation
The grouping of related concepts into one item such as a class or a component
It deals with the issues of how you intended to modularize the features of a system. In the object
oriented world, you modularize, we modularize systems into classes, which intern are modularized
into methods and attributes.
Encapsulation is the process of binding both attributes and methods together within a class.
Through encapsulation, the internal details of a class can be hidden from outside. It permits the
elements of the class to be accessed from outside only through the interface provided by the class
Information hiding – the restriction of external access to the rest of the world. If one class wants
information about another class, it should have to ask for it instead of taking it.
Collaboration
Classes often need to work together to fulfill their responsibilities. Actually, it is typically the
objects and the instances of the classes that are working together.
12
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
Collaboration occurs between objects when one object asks another for information or to do
something. For example, an airplane collaborates with its engines to fly. For the plane to go faster,
the engines must go faster. When the plane needs to slow down, the engines must slow down. If
the airplane did not collaborate with its engines, it would be unable to fly.
Objects collaborate with one another by sending each other messages. A message is either a
request to do something or a request for information.
Persistence
Persistence focuses on the issue of how to save, retrieve, and delete objects to/from permanent
storage.
To make an object persistent, you must save the values of its attributes to permanent storage (such
as relational database or a file) as well as any information needed to maintain the relationships
(aggregation, inheritance and association) with which it is involved.
Coupling
Coupling is a measure of how much two items such as classes or methods are interrelated. when
one class depends on another class we say that they are coupled.
When one class interacts with another class, but does not know any of the implementation details
of the other class we say they are loosely coupled .
When one class directly accesses the data attributes of the other, we say they are highly/tightly
coupled.
•
Tips of coupling
–
Avoid high coupling if possible
–
Document high coupling thoroughly.
Cohesion
The degree of relatedness with in an encapsulated object (such as a class or a component .) A good
measure of cohesiveness of some thing is how long it takes to describe in one sentence. The longer
it takes the less cohesive it likely is.
A method is highly cohesive if it does one thing and one thing only.
Polymorphism
Is originally a Greek word:
Poly _” many”
Morph _ “form”
13
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
It means objects that can take on or assume many different forms. Polymorphism means that the
same operations may behave differently on different classes. Booch defines polymorphism as the
relationship of objects many different classes by some common super class. Polymorphism allows
us to write generic, reusable code more easily, because we can specify general instructions and
delegate the implementation detail to the objects involved.
Polymorphism- different objects can respond to the same message in different ways. Enables
objects to interact with one another without knowing their exact type.
Polymorphism enables objects to collaborate with other objects without knowing their type in
advance.
Let us consider two classes, Circle and Square, each with a method findArea(). Though the name
and purpose of the methods in the classes are same, the internal implementation, i.e., the procedure
of calculating area is different for each class. When an object of class Circle invokes its findArea()
method, the operation finds the area of the circle without any conflict with the findArea() method
of the Square class.
Patterns
A pattern is a solution to a common problem taking relevant forces into account, effectively
supporting the reuse of proven techniques and approaches of other developers.
Several flavors of patterns exist, including analysis patterns, design patterns, and process patterns.
Analysis patterns describe a solution to common problems found in the analysis/business domain
of an application
Design patterns describe a solution to common problems found in the design of systems, and
Process patterns address software process- related issues.
14
UNDERSTANDING BASIC OBJECT ORIENTED CONCEPTS
15