1|P ag e

CHAPTER ONE

OBJECT ORIENTATION THE NEW SOFTWARE PARADIGM

INTRODUCTION

1.1. Structured paradigm versus Object Oriented Paradigm

Information systems are an outgrowth of a process of organizational problem solving. An information system is
built as a solution to some type of problem or set of problems the organization perceives it is facing.
Systems development refers to all the activities that go into producing an information systems solution to an
organization problem or opportunity. There are traditional and modern approaches to systems development.
The structured paradigm is a development strategy based on the concept that a systm 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).

On the other hand, as you see in Figure 1-1, 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).

Figure 1-1 comparing the structured and object-oriented paradigms

Object-Oriented (OO) systems development is a way to develop software by building self-contained modules that can
be more easily Replaced, Modified and Reused. In an object-oriented environment:-
 Software is a collection of discrete objects that encapsulate their data as well as the functionality to model
real-world "objects."
 An object orientation yields important benefits to the practice of software construction
2|P ag e

 Each object has attributes (data) and methods (functions).

 Objects are grouped into classes; in object-oriented terms, we discover and describe the classes involved
in the problem domain.
 Everything is an object and each object is responsible for itself.
Object-oriented methods enable us to create sets of objects that works together synergistically to produce
software that better model their problem domains than similar systems produced by traditional techniques. The
systems are easier to adapt to changing requirements, easier to maintain, more robust, and promote greater de-
sign and code reuse. Object-oriented development allows us to create modules of functionality. Once objects are
defined, it can be taken for granted that they will perform their desired functions and you can seal them off in
your mind like black boxes. Your attention as a programmer shifts to what they do rather than how they do it.
Here are some reasons why object orientation works.
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 name, addresses, birth dates, telephone numbers and so on) and they do thing
(enroll in courses, drop courses and pay tuition). Professors also know things (the course they teach and their
names) and they do things (input markes and make schedule requests). From system percpective, room know
thing (the building they are in and their room number) and should be abel to do things, too (such as tell you when
they are avilable and enable you to reserve them for a certain period of time). Course 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). To impliment this system, we would define a collection of classes (a class is a generic
representation of similar object) that interact with each other. For example, we would have “Course”, “Student”,
“Professor” and “Room” classes. The collection of these classes would make up our application, which would
include both the functionality (the program) and the data.
1.2. The Potential Benefits of Object Orientation
 Reducing Realization Costs: One of the main attractions of object-oriented methodologies is the
promise of reduced realization costs. This is facilitated by:
 Improved communication between role players,
 Complexity reduction for complex domains, and
3|P ag e

 Contract and component based approach to service providers.

 Improved Communication between Role Players: Because OOAD languages (e.g. UML)
 aim to remain close to the problem domain
 allow for direct mapping onto various programming languages, particularly onto OO
programming languages

They provide an ideal communication medium between the various role players in the system analysis
and development process, from domain expert to analysts, designer, implementer and maintainer.

Graphical languages like the Unified Modeling Language (UML) allow for diagrammatic designs which
provide selective views, focusing only on those elements which are relevant to those points one currently
wants to illustrate.

 Communication with Domain Experts: Particular importance is the communication with domain
experts who are in the best position to understand the system requirements. A domain expert is one who
is an expert of the problem domain. Typically domain experts are found within the client company. They
should be included formally or informally in the development team, at least during the requirements
analysis stage. Good object-oriented models are usually easily accessible to domain experts and they
facilitate communication between domain experts, system analysts and developers.
 Reducing Risk of Project Failures: Traditionally a large proportion of system development projects
simply failed. They did not deliver what the client really needed, were often error prone and hugely over
budget. The focus on communication with domain experts in order to understand the system requirements
together with the component-based approach of assembling systems from tested components should
significantly reduce the risk of failure.

The biggest risk is perhaps that of building the wrong system. This can be due to not understanding what
the clients requested. It is, however, not uncommon that the client themselves do not understand what they
actually need. OOAD can help to prevent both problems. It facilitates communication with clients and
domain experts and it can help clients to understand their own needs.

 Availability of Analysis and Design Tools: object orientation lends itself to developing powerful analysis
and design tools. Many of these support the full software development cycle, including analysis, design,
implementation, documentation generation and verification. They often support automatic code
generation from designs and automatic design generation from code. Some of these support round-trip
engineering which allows the user to make changes either on the code or on the design with the rest of the
4|P ag e

system being automatically updated. This ensures that design and code are always on the same
maintenance level.
 Increased Extensibility: Because classes have both data and functionality when you add new features to
the system, you only need to make changes in one place: the applicable class. Structured – change in single
business rule could affect many programs. Objects encapsulate both functionality and data, making it
easier to maintain your software. Inheritance enables you to reuse existing behaviors, making it easier to
enhance your software
 Higher level of abstraction: - The object-oriented approach supports abstraction at the object level. Since
objects encapsulate both data (attributes) and functions (methods), they work at a higher level of
abstraction. The development can proceed at the object level and ignore the rest of the system for as long
as necessary. This makes designing, coding, testing, and maintaining the system much simpler.
 Encouragement of good programming techniques: - A class in an object-oriented system carefully
delineates between its interfaces the routines and attributes within a class are held together tightly. In a
properly designed system, the classes will be grouped into subsystems but remain independent; therefore,
changing one class has no impact on other classes, and so, the impact is minimized. However, the object-
oriented approach is not a panacea; nothing is magical here that will promote perfect design or perfect
code.
 Promotion of reusability: -Objects are reusable because they are modeled directly out of a real-world
problem domain. Each object stands by itself or within a small circle of peers (other objects). Within this
framework, the class does not concern itself with the rest of the system or how it is going to be used within
a particular system.
1.3. The potential Drawbacks of Object Orientation
 Requires a greater concentration on requirement analysis which is often ignored in reality
 Developers must work closely with users
 Requires a complete change in mindset on the part of individuals
 It is more than just programming, not easy and not that quick

1.4. Unified Modeling Language (UML)

The unified modeling language defines the industry standard notation and semantics for properly applying that
notation for software built using object-oriented (OO) or component-based technology (Object Management
Group 2003). The UML is currently in release 2.0.
5|P ag e

The UML is an object-oriented modeling language used to describe information systems. It provides a common
vocabulary of object-oriented terms and a set of diagramming techniques that are rich enough to model any
systems development project from analysis through implementation. Today most object-oriented systems
analysis and design approaches use the UML to depict an evolving system. The UML uses a set of different
diagrams to portray the various views of the evolving system.

1.5. Object Oriented Software Process

Software Process

“The Software Engineering process is the total set of Software Engineering activities needed to transform
requirements into software”. A software process is a set of project phases, stages, methods, techniques and
practices that people employ to develop and maintain software and its associated artifacts. Software process
enables organizations to increase productivity when developing software.

A process defines who is doing what, when and how to reach a certain goal. A process to build a software product
or to enhance an existing one is called a software development process.

The object-oriented (OO) software development approach follows an iterative and incremental approach to
system development. The system development life cycle is viewed as consisting of several increment or phase:
inception, elaboration, construction, and transition (5). In each increment or phase, the developers move through
the activities of gathering requirements, analyzing the requirements, designing the system, implementing the
design, and testing the system. See Figure 1.2. Thus the phases of the traditional system development approach
do not match with those of the OO life cycle; but in each increment, all phases of the traditional life cycle
(requirement analysis. Design, implementation, testing) are visited iteratively until the developers are satisfied.
However, there are times when one activity predominates over the other four- causing the systems development
effort to move from the inception to elaboration, then elaboration to construction, and from construction to
transition.

The object-oriented approach used a set of diagraming techniques known as the Unified Modeling Language or
UML. It focuses on the three architectural views of a system: functional, static, and dynamic. The functional view
describe the external view of the system from the perspective of the user. Use cases and use-case diagram are
used to depict the functional view. The static view is describe in terms of attributes, methods, classes, relationship,
and messages. Class-responsibility-collaboration (CRC) cards, class diagram, and object diagram used to portray
the static view. The dynamic view is represented by sequence diagram, collaboration diagram, and state charts.
6|P ag e

All diagram are refined iteratively until the requirements of the information system in fully understood. Finally,
the information system is developed through a combination of traditional relational data base and object-oriented
programing rather than true object-oriented methodology for both programming and database

Figure 1.2 itrative and incrimental model of SDLC

1. Systems Requirements and Analysis
 To develop a model of the way the current system works
 the existing system provides a good guide as to what is required of a new system
 Analysis summaries and models key elements in the system to facilitate understanding of the system and to
help with the System Design stage.
 What is to be done in order to satisfy the requirements of a new system
 Facts gathered during the Feasibility Study about the existing system and about the requirements for the new
system are used to model the system.
 The analyst will need to gather more detailed facts about the existing system and about the requirements for
the new system than is available from the Feasibility Study.
 To do this, s/he can use the same fact-finding techniques as used Feasibility Study.
 consists of a detailed investigation (using the usual fact-finding techniques)
 The analyst must become familiar with:
o what the system is supposed to do
o Whether or not, under current conditions, it actually does it.
o What constraints the system operates under.
7|P ag e

o What type of data is processed?

o Exception circumstances.
o Problems with present working conditions.
 should result in
o detailed models of what the existing system does (if there is one)
o Models of what the new system will do.
o list of requirements for the new system--a requirements specification
2. Systems Design
 Using the facts and models from the Feasibility Study and Analysis stages, a design for the new system is
developed.
 At this stage, the models from analysis are amended to incorporate any new requirements (for the new system)
and any inefficiencies or mention of physical aspects are removed.
 Both of these are legacies of having used an existing physical system as the basis for analysis.
 The result is that the design for the new system should eliminate the problems of the old system.
 Systems Design shows how the new system will be implemented (i.e. a design for the new system is
produced).
3. Implementation
In this stage

 individual system components are built

 programs are written
 The database is created etc.
 System components are tested individually and then linked and tested
 The user interfaces, i.e. the screens which link the user with the system are developed.
 Users are introduced to the system and encouraged to voice their opinions on it.
 The hardware specified in Systems Design is acquired and installed.
 Targeted training and education are provided for staff.
4. Testing (and Review)
 This stage is ongoing throughout the useful life of the system
 involves correcting faults which are not detected during testing
 Making enhancements to the system in order to satisfy new requirements.
8|P ag e

 This is the most expensive part of the life cycle and, in order to minimize costs, every effort should be
made during earlier stages to get the requirements right first time and to trap as many errors during testing
as is possible.