Chapter Two

4.1 The Structured Paradigm versus

the Object-Oriented Paradigm
• The structured paradigm is a development strategy
based on the concept that a system should be
separated into two parts:
• data (modeled using data/persistence model) and
• functionality (modeled using a process model).
• In short, using the structured approach, you develop
applications in which data is separated from
behavior in both the design model and in the system
implementation (that is, the program).
• Paradigm. (pronounced Para-dime)- An
overall strategy or viewpoint for doing things.
A paradigm is a specific mindset.
• On the other hand, as you see in Figure
below , the main concept behind the 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). While this
sounds similar to the structured paradigm, it really
isn't. 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 the
courses, drop courses, and pay tuition).
Professors also know things (the
courses they teach and their names)
and they do things (input marks and
schedule requests).
• From a systems perspective, rooms know
things the building they’re in 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).
• Class. A template from which objects are
created (instantiated). Although in the real
world Alemu, Worku, and Tom are all
“student objects,” we would model the class
“Student” instead.
• Object space. The memory space, including
all accessible permanent storage, in which
objects exist and interact with one another.
• Object. A person, place, thing, concept, event,
screen, or report. Objects both know things
(that is, they have data) and they do things
(that is, they have functionality).
• Object-oriented paradigm. A development
strategy based on the concept of building systems
from reusable components called objects.

• OO. An acronym used interchangeably for two

terms: Object-oriented and object orientation.

• For example, when we say OO programming, we

really mean object-oriented programming. When
we say this is a book that describes OO, we really
mean this it is a book that describes object
orientation .
 The Potential Benefits of the Object
Oriented
• OO offers the potential to solve ( at least
lessen) many of the problems currently faced
by the IT industry.
• OO was popularized by the corporate world in
the late 1980s
• It become the defacto development standard in
the mid- 1990s and has been grown ever since.
The following are the potential benefits of the
OO
 The following are the potential benefits of
the OO
1. Increased reusability
2. Increased extensibility
3. Improved quality
4. Financial benefits
5. Increased chance of project success
6. Reduced maintenance burden
7. Reduced application backlog
8. Managed complexity
 1. Increased reusability
• The OO paradigm provides opportunities for
reuse through the concepts of inheritance,
polymorphism, encapsulation, modularity,
coupling and cohesion.

• It provides more opportunities for reuse than

the structured paradigm.
 2. Increased extensibility
• Because classes have both data and
functionality ,when you add new features to the
system you need to make changes in one place,
the class;
• But this is different than the structured
paradigm,
• Example Suppose that you have four structured
programs that access the student data table in
the university database. Consequently you add
one attribute to the table.
• To support this change all four structured
paradigms need to be modified to work with
the new data. Now say that you are developing
the same systems using object technology.
• Instead of coding four different applications
to work with the student data, you instead code
one single class called “student," which works
with this data that encapsulates both the
functionality and the data appropriate to the
students.
• To add an attribute you merely have to modify
the definition and source code of the class
student in one place, not in four. Clearly this is
easier.
 Example2.
• You may need to modify your existing system to
keep track of university administrators. A university
administrator is just like a professor except that in
addition to teaching courses he/she schedules them.
• In structured application, you potentially need to add
a new data table for administrator to a new program
module to handle administrative functions.

• In the OO paradigm, data and functionality already

defined in professor are inherited to the administrator.
 3. Improved Quality
• Quality systems are on time, on budget and
meet or exceed the expectations of their users.
• Improved quality comes from increased
participation of users in systems development.
• OO systems development techniques provide
greater opportunity for users to participate in
the development process.
• In the next chapter CRC modeling and use case
modeling, techniques where users perform the bulk
of requirements gathering.

4. Financial benefits
• Reusability, extensibility, and improved quality are
all technical benefits.
• Object orientation enables you to build systems
better, faster and cheaper (BFC)

• The benefits OO are realized through out the entire

development life cycle, not just programming
 5. Increased Chance of Project
success
• A project is successful if it is on time, on
budget and meets the needs of the its users.
• Users are expert at business and they are the
only ones who can tell you what they need.

• You need to know the right question to ask,

know the business very well.
• You need models that communicate the
required information and that users
understand.
• You need to work closely with users

• Time invested in defining requirements and

modeling pays off in the long run.
• You can use a wide variety of artifacts
including code, model and components
 6. Reduce maintenance Burdon
• Software organizations currently spend significant
resources (80%) maintaining and operating software,
and because of the long waiting list of work to be
done, it takes significant time to get new projects
started. These two problems are respectively called
– the maintenance Burdon and
– The application backlog
• These are problems that object orientation can help
you to overcome
Maintenance Burdon -The fundamental need to
require software organizations to invest money
in the support, operation and enhancement of
the existing hardware.
Application backlog- The average amount of
time it takes for the systems department to
start the development of a system as measured
from the time that the idea is first conceived.
The maintenance Burdon
exists for several reasons:
1. Many systems that are developed in the past
are still used
2. System documentation is very poor if it exists
at all
3. Compared to the standards of today, legacy
systems are poorly built
 7. Reduced application backlog
• In many organizations a two –to-five years
“application backlog” in average currently
exists
Idea Project Project System
Proposed Begins Released

Application Backlog Development time

Total Implantation time

• Because OO techniques are more productive
than structured techniques, organizations are
able to free up resources sooner to tackle new
projects.
• In reality application backlogs never go away.
Every time you deliver new features to your
users, they ask for two more .
 8. Managed Complex
• Systems of today are more complex,
applications are on line and real time,
developed for client/server, peer-to -peer
• The computer hardware is built from reusable
components mounted on the mother board
(CPU,RAM, hard disk,…)
• It would be nice to build a software like the
hardware
• You can build complex software from well-
designed reusable components.
• Expect the software you build today will need
to be changed tomorrow.
• Well designed object oriented software
enables you to react quickly to changes in your
environment
 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 can not build a system that meets users
needs unless you know what those needs are(
you need to do requirements)
• You can not built a system unless you know
how it all fit together (you need to do
analysis and design)
 – But this fact is often ignored by many
developers
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. OO requires the development culture of
the IS dept to change
– The change in the mind set of individual
developers actually reflect an over all
change in the development culture.
– Do more analysis and design but (less
programming ) and working with users
5. OO is just more than programming
6. Many OO benefits are long term
– OO truly pays off when you extend and
enhance your system
7. OO demands up front investments in
training education and tools
– Organizations must train and educate their
development staff.
– Buy books, development tools and
magazines
8. OO techniques do not guarantee you will
build the right system

– While OO increases the probability of

project success ,it still depends on the
ability of individuals involved.
– developers, users, mangers must be
working together to have a good working
atmosphere .
9. OO necessitates increased testing
– OO is typically iterative in nature, and
probably developing complex system using
the objects, the end result is you need to
spend more time in testing.
10. OO is only part of the solution
– You still need CASE tools
– Need to perform quality assurance (QA)
– You still need usable interface so the users
can work with the systems effectively
• Quality Assurance (QA)- Responsible for
measuring the products of the development
process; generally directs system level testing
of all prototypes and production releases.
Object Standards
• OO orientation today becomes the
significant part of the software
development .
• Objects are the primary enabling
technology for components.
• It also stays in the future because of the
standard set by the OMG.
• Object management group (OMG) is an industry
recognized standards body. http://www.omg.org
• Responsible for standards such as
– CORBA( Common object request broker
architecture) – the standard architecture for
supporting distributed objects.
– CORBA is the world's leading middleware
solution enabling the exchange of information,
independent of hardware platforms, programming
languages, and operating systems.
• UML ( Unified modeling language)- the
standard modeling language for the object
oriented software.
– ANSI ( Americans National Standards Institute)-
Defined standards for C++. Http://www.ansi.org
– Sun Microsystems ,Http://www.sum.com
actively maintains, enhances and supports a de
facto standard definition for java and related
standards such as Enterprise Java Beans (EJB).
– The Object Database Management group
(ODMG)- Http://www.odmg.org actively
maintains, enhances and supports a standard
definition for object oriented databases and object
query language (OQL).
• Responsible for standards such as
– CORBA( Common object request broker
architecture) – the standard architecture for
supporting distributed objects.
– UML ( Unified modeling language)-the standard
modeling language for the object oriented
software.
Thank you!