An Introduction To Object Technology: The Traditional Approach

+
0
)
2
6 An Introduction
-
4
to Object
Technology

1.1 THE TRADITIONAL APPROACH
1.1.1 The Software Crisis
The traditional focus of computer systems had been on the hard-

ware. Since the early 1950s, computer hardware was quite expen-
sive. At the same time, there were no desktops or personal computers.
The Internet
has made the
All computer processing was based on large mainframe or mini com-
flow of puters, which were very expensive and difficult to maintain. How-
information ever, this pattern started changing towards the 1980s with the
even more
introduction of the personal computer. It has changed so dramati-
Copyright © 2004. Tata McGraw-Hill. All rights reserved.
dynamic.
cally from that point onwards that in the last few years, almost all
concerns regarding the hardware have been nullified, and the chief
concern of all the concerned parties in a software project is the
software itself.
All modern organizations and corporations have become informa-
tion-centric. They have quite a few areas where information con-
stantly keeps coming in, or going out. For instance, in a typical
organization, there are a number of departments, such as sales and
marketing, research and development, customer service, and so on,
Kahate, Atul. Object Oriented Analysis & Design, Tata McGraw-Hill, 2004. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/inflibnet-ebooks/detail.action?docID=5121208.
Created from inflibnet-ebooks on 2020-10-19 23:20:41.
2 Object Oriented Analysis and Design
each of which receives some information, or has to give it out. This informa-
tion can be qualitative (e.g. our product has made good inroads in the Japa-
nese market) or quantitative (e.g. we have sold 1000 units of our product in
England). Regardless, the organization must keep track of all this information,
whether it is current or of the past, and it must be able to access it as and when
required with a very short notice. The result is that information systems play
perhaps the most critical role in the day-to-day running of any modern
business.
The biggest problem faced by the organizations is trying to keep up with
this voluminous data, which seems to keep growing all the time. As we have
mentioned, the hardware is no more an issue. New hardware can be bought, or
It is common the existing hardware can be upgraded with minimum fuss. However, the key
to talk about
Giga-bytes, now is software. Writing and maintaining complex software has proved to be
something quite a challenge. There are many aspects of this, as follows.
unthinkable
even a few
1. Race between Hardware and Software The biggest problem here is that
years ago. hardware is upgraded quite frequently to fast processors, more memory and
reliable server infrastructures. However, the software has to be constantly on
its toes to keep up, and make use of this modern, better hardware. By the time
the software seems to have matched the hardware, the hardware takes another
leap: it becomes even better! How do we tackle this situation without impact-
ing any of the areas in a software project? How do we ensure that this race
between hardware and software is not won by the hardware all the time? This
race is shown in Fig. 1.1.
New Hardware is Write New Software to

FIG. 1.1 Available Take Its Advantage
Race between
Hardware
and Software
2. Complexity of the Software Projects The second major issue related to

modern information systems is the complexity of the software projects. Large
corporations require dependable, large-scale software. However, history shows
Software that it is very rare to complete a software product in quick time that works as
projects are
becoming
expected, and that does not have any defects, either. The schedules and bud-
more and gets are almost always crossed, and worse yet, the resulting software is many
more complex times riddled with defects. To make matters worse, generally the software is
all the time. organized (written) in such a manner that it is very difficult to make alterations
to the software in order to deal with defects. Changes made to handle one
defect cause the effect of impacting other portions of the software. Thus,
removing one defect leads to the birth of one or more new defects (testing and
removing such new defects is a process called as regression testing, in techni-
cal terms). To summarize, the typical challenges faced by major software
projects are illustrated in Fig. 1.2.
An Introduction to Object Technology 3
Budget
Defects
FIG. 1.2
Challenges Modern Software

Faced by Projects
Major
Software
Projects Schedule Complexity
3. Changes in Business Environment Apart from the technical issues just

discussed, the business environment itself has become extremely dynamic and
volatile. This is more significant to big corporations. The software is either
The Unified
Process
obsolete or is on the verge of becoming outdated, by the time it is delivered.
Model is one Business requirements, demands and competition are changing so fast that the
possible way software projects must be equipped to handle changes right through their
of dealing with lifetime. That is, a software project team cannot refuse changes to the user
the changes
in user requirements, as change has almost become an inevitable aspect of modern
requirements. software projects. Therefore, the challenge here is to ensure that the software
can handle changes easily today, and that it has the power to easily evolve
tomorrow. This is shown in Fig. 1.3.
Start of a Lifetime of
Software a Software
Project Project
Create/Update
Create Customer Create Customer
Customer
Update Customer Update Customer
Create Salesperson
Delete Customer Delete Customer ll
Print Invoice
Print Invoice Print Invoice
FIG. 1.3 Weekly Report Monthly Report
Flexible Report
Web Enabling
Constantly
Changing
User Initial Requirements Requirements
Requirements Requirements Changed Changed
Many experts call this situation as a software crisis. How do we deal with
such issues, and deliver quality software on time within the budget, at least on
most occasions, if not every time? In order to understand this, we must first
examine the traditional approach for constructing software.
1.1.2 Software Construction
Ä The Earliest Approach

We shall begin with the earliest perspective to software construction, and
quickly take a look at the way this technique has changed, over the years.
A computer program is a series of steps that carry out the desired function-
ality. These steps are written in the form of instructions in a programming
language, which a computer can understand and execute. Usually, one person
writes one program. Such a program is called as a procedure. This works fine
as long as the size of the procedure is manageable (small). The same person is
responsible for handling changes to the procedures, and taking design deci-
sions, so as to freely move portions of the procedure’s code from one area to
the other, and so on. This is shown in Fig. 1.4.
When a Program is
FIG. 1.4 Small, It is Usually
Program Procedure
Written as a Single
Program and Procedure
Procedure
However, when the size of the overall computer application starts increas-
ing, it is no longer viable for a single programmer to write the entire applica-
tion. Many persons get together to create the program now. If we continue
Examples of
procedural
using the same approach of creating one single procedure for the entire pro-
programming gram, it usually leads to trouble. This is because, different persons write dif-
languages are ferent portions of code within the same procedure. Therefore, there is a lot of
COBOL and inter-dependency in terms of program code among the various developers of a
Pascal.
team. When one developer changes her code even in the slightest manner, it
can have a rippling effect on the rest of the code. Usually, most of the time is
spent in communicating changes, handling their effects on the other portions
of the code, and ensuring that no new errors are introduced by someone else’s
change. As the software project gathers pace, it not only becomes cumber-
some, but also so disconcerting that the project team starts spending most of
their time in issue resolution, rather than actual coding!
Ä Modular Programming
In order to deal with the issues just discussed, it will become apparent that the
one program = one procedure approach is not going to work. The simple
solution to this problem seems to be, split one program into smaller, manage-
Structured
and modular able modules/procedures. These smaller modules should be fairly independent
programming of each other. Different persons should be able to code them independently,
are different and then finally integrate them together to form a single application program.
concepts,
although
Such a strategy is called as modular programming.
people often In the 1960s, the idea of modular programming started picking up. This
confuse them. thought process led to the concept of a subroutine. A subroutine is carved out
of the main program by physically taking out some instructions from the main
program, and placing them inside a subroutine. The main program no longer
contains these instructions. Instead, they are in the subroutine. Whenever the
main program wants to execute these instructions, it simply calls the subrou-
tine by its name. For instance, in a payroll application, a subroutine Calculate-
Some
languages salary can be carved out of the main program. The main program can call it as
use functions and when required. This is shown in Fig. 1.5. Here, the main program calls the
in the place of subroutine twice.
subroutines.
Main Payroll Program
Calculate-Salary Calculate-Salary
Subroutine
FIG. 1.5 Calculate-Salary
Use of
Subroutines
The use of subroutines helps. This approach means that different persons
can write different subroutines, and then can assemble them all to form a single
working program. Therefore, instead of writing one program as a single proce-
dure, many subroutines can constitute a program as shown in Fig. 1.6.
Subroutine A
When a Program is Big, It Subroutine B

Program
FIG. 1.6 Consists of Many
Subroutines
Subroutine C
Big Program
Consisting
of Many Subroutine D
Subroutines
Although this approach sounds a lot better, and has indeed solved many of
the problems that we had noticed earlier, it has its own issues and concerns, as
we shall see. For the moment, however, let us see how we can further enhance
Structure
charts are this approach. In order to further improve the modular programming model, we
prepared to can think about multi-level modules. That is, we need not restrict ourselves to
show the a single level of subroutines—we can expand this to multiple levels, as shown
hierarchy of
modules.
with the help of a simple example in Fig. 1.7.
As we can see, the approach here is top-down, wherein the bigger problem
statement is first divided into first level modules. We then examine to see if
any of the first level modules can be further divided into second level modules,
and so on. We stop when we reach the level of the individual subroutines.
Different programmers can write these subroutines, which are then assembled
to form a single main program.
Main
Read Data Main Menu Write Data
FIG.1.7
Modules at Inquiry Update Delete

Multiple
Levels
The modular approach works fine as long as the number and levels of
modules is not very high. However, as these numbers increase, as well as the
number of times that they need to be changed increases, this approach also
Figure 1.7 is a
structure
suffers from the drawback of maintenance overheads. The problem is that it is
chart. very difficult, if not impossible, to initially comprehend the complete scope of
an application, and therefore, the number and levels of modules. Consequently,
it often turns out that the initial division of the main program into smaller
modules is not done the right way, and amending that causes significant
overheads later on. The bigger the application, more is the number of times we
must perform the design rework, which means changes to the whole applica-
tion.
Let us now understand why this approach suffers from these drawbacks.
Ä Data Management
All along, we have been talking about only the operations, or procedures in a
program. But a program always has two aspects: operations and data, as shown
in Fig. 1.8.
Operations
Program
= +
FIG. 1.8
A Program
Consists of Data
Operations
and Data
Interestingly, the idea of keeping the instructions (code) and the data sepa-
rate seems to have originated from hardware. In hardware, we always used to
have separate physical areas in the memory for storing instructions and data—
For example,
in most
they were never mixed. In fact, even today, that is the case in most computer
Assembly architectures, and the compilers also expect things to be that way. Software
language simply seems to have borrowed this concept from hardware!
programs, the
We have rarely spoken about data so far. That, in fact, is one of the major
instructions
are in an area causes why the traditional approaches suffer from a number of drawbacks.
of memory Imagine that there is a computer-based Sales tracking application, which tracks
called as code customers, salespeople and the sales data. At a very broad level, the applica-
segment, and
all the data tion consists of three major operations: Customer details maintenance, Sales
items are in a people details maintenance and Sales details maintenance. All the three opera-
separate area tions need some scratch pad areas to store their temporary data, such as
called as data
segment.
intermediate totals or summary reports before printing them, etc. The tradi-
tional approach would have been to allocate a common pool of data area,
called as global variables, to these three operations, and allow them to freely
use this pool of data the way they wanted. This is shown in Fig. 1.9.
Sales Tracking Application
FIG. 1.9
Traditional Customer Details Sales People Details Sales Details

Approach for
Data Usage:
All
Applications
Share a
Common Pool
of Data Common Pool of Data (Global Variables)
As shown in Fig. 1.10, the common pool of data is available to all the
operations, or programs, in the traditional approach of computer applications.
This approach works fine if the number of programs as well as the number of
data elements is small. However, this approach has serious implications, if it is

used in big applications where there are hundreds, if not thousands of pro-
grams and a large number of data items to deal with. This is because every
data element is available to every program. To understand this, suppose that
two programs A and B execute one after the other. So, if program A modifies
the value of a data element X from 10 to 20, program B gets the modified value
of that data element X (i.e. 20), whether or not it expects and wants it that way.
This is shown in Fig. 1.10.
Program A
Before Program A executes
… X = 10
…
Add 10 to X
…
After Program A executes
Execute B X = 20
FIG. 1.10
Program B
Changes to a
…
Data Item by … Program B gets X = 20
One Program Add X to Y X = 20
can have …
Impacts on …
all Others
Even worse, suppose that program A is changed tomorrow, so that instead of

adding 10 to X, it adds 20. Unless program B knows about it, this change can
have serious consequences (e.g. the calculation of Y in program B would now
produce a different result). Since it is almost always true that programs A and
B would be developed by two different programmers, unless this fact is com-
municated by the programmer who wrote program A to the programmer who
wrote program B, this may have serious impacts on the way program B be-
haves. Now imagine such implications in the case of hundreds of such pro-
grams, using thousands of such data elements. It is needless to say that this can
cause real damage.
Realizing this fact, the modular approach of software development was ex-
tended to provide individual modules with their own data elements. Thus, a
module would have access to its own data elements only. These data elements
The C owned by a specific module were called as local variables. No module could
programming
language access, and therefore modify, another module’s data. This approach is shown
made local in Fig. 1.11, in the context of our earlier example of Sales tracking applica-
variables a tion.
popular idea.
Of course, there would also be a need for some common pool of data
elements that would be shared across all the modules. Such common data
elements (i.e. global variables) would be identified after a lot of scrutiny, and
an attempt used to be made to keep the number of such commonly shared data
elements to a minimum, so as to alleviate the problems caused by shared data,
which were described earlier. For simplicity, we have not shown the global
variables here.
We will realize from our discussion so far that two concepts have now
become crucial:
l Carving out smaller modules out of a bigger high level application (Modu-
lar programming)
l Allocating local data elements to each of the modules (Local variables)
These two concepts form the basis of object technology.
Sales Tracking Application
FIG. 1.11
Customer Details Sales People Details Sales Details
Individual
Modules
Having their
Own Local
Data
Elements
(Local
Variables) Local Variables Local Variables Local Variables
1.2 OBJECT TECHNOLOGY BASICS
1.2.1 Introduction
We have discussed the various problems associated with the traditional model
of procedural programming. Now is the time to examine how object technol-
ogy differs from this model. Many people have an apprehension about object
In general, the
more jargon
technology for a strange reason. This technology comes with such a big list of
you can throw terminology, buzzwords, jargon and vocabulary that it is actually quite normal
at others, the to get frightened! Therefore, our objective would be to simplify and clearly
more ‘expert’
demystify all these terms in a very simple manner.
you are
considered. The fundamental principle in object technology is an object. At the simplest
level, everything that we see, feel, touch, or smell is an object. For instance,
the book that you are holding and reading now is an object, each page in the
book is also an object, and you and me are also objects! Actually, this is a
fairly informal definition of the term object. So, let us be somewhat more
technical, and understand what an object means, soon.
The origins of object technology can be found in the 1960’s with reference
to a programming language called as Simula. The name Simula was an abbre-

viation of the term Simulation language. This language first introduced the
principles of object technology. Simula’s purpose was quite clear. This lan-
guage was designed to build accurate models of complex and huge physical
systems (e.g. big buildings, aircrafts, machines, etc.). These systems could
consist of thousands of components. In Simula, models were created as ob-
jects. For instance, a floor in a building could be an object, which could be
accessed by another object called as elevator, and so on.
An object is a self-sufficient entity. It hosts operations as well as data. We
will quickly notice that this is remarkably different from what we have been
observing so far. In the procedural world, the emphasis is on operations. Data

comes at the very end. We have discussed that operations and data are separate
aspects of a program. In the context of object technology, we are considering
operations and data as two portions of a single an object. Data is no longer
considered separately—it is tightly coupled with the operations on an object.
This concept is illustrated in Fig. 1.12.
Data
Object
FIG. 1.12
Object = Operations
Data +
Operations
We should state one more observation. Here, we have not talked about the
term program. Instead, we are discussing about objects. We need to note that
Object oriented
this is also a big change from our discussion so far. But it also means that we
programming need to know how objects relate to a program. In object technology, a program
literally means is simply a collection of well-designed objects. We do not think of a program
programming
as a group of data items and operations. Rather, we think of it as a group of
objects.
objects, as shown in Fig. 1.13.
Data Data Data
Object Object Object

Operations Operations Operations

FIG. 1.13
Program in
Object Program
Technology
As an illustration, in a payroll application, the objects could be employee,

department, manager, salary, etc. All these objects would interact with each
other on a needs basis, to create one or more application programs. In an electri-
cal application, the various objects could be wire, voltage, appliance, etc.
Let us examine a few more important terms now.

l In object technology, operations are called as methods. Note that these are
also called as functions or procedures in traditional systems.
l Data items or variables are called as attributes.
As an example, if we consider a horse as an object, the cat’s eyes, ears, nose,
etc. are all its attributes. Some of these are shown in Fig. 1.14. Also, eating,
running, standing still etc. are the horse object’s methods.
Ear
Eye
FIG. 1.14
Nose
Horse Object
and its
Attributes
Remarkably, this nature of objects makes them self-sufficient. For instance,

as soon as we imagine a horse, we can describe everything about it. These are
the attributes and methods of that object. There is nothing extra, which is
This simple
concept has missing here. This principle of object technology is quite interesting and use-
significant ful. As far as a designer is concerned, this means that an object no longer
impacts, as depends on other objects for its own features and characteristics. When this
we shall
discuss when leads to the development stage, a programmer can look at an object as a black
we study box. It is a self-contained unit, which can be protected from the outside world.
Modeling.
This also means that one object cannot, intentionally or otherwise, affect the
internals of another object. As we shall study later, this has far-reaching conse-
quences in the area of software development.
One interesting question emerges at this juncture. We know that objects are
self-sufficient. But then how do we interact with it? For instance, we know
that a horse can run. But how can we instruct a horse to run? If we are not able
to do so, the horse object would be quite useless to the rest of the world. This
means that we have be able to instruct the horse to perform the desired action,
such as asking it to run. Of course, object technology takes care of this aspect
by providing messages. We can pass a message to an object, requesting it to
perform a specific task. For example, we can send a message to the horse
object, asking it to run.
We can imagine that in the real computing world, objects need to interact
with each other in a number of ways, and for a variety of reasons. In order to
make this possible, one object can send a message to another object. This
message requests the called object to execute one of its methods. This concept
is illustrated in Fig. 1.15, where we can send a message to another object
called as dog, which results into it invoking its run method.
Johnny, run!!!
FIG. 1.15
Sending a
Message to
the Dog
Object to
Invoke its
Run Method
Note that we could have sent the same message to the horse object as well.
That would cause the horse to run, instead of the dog running. In effect,
different objects can have the same method and can receive the same message
from the external world. Their responses would also be quite similar to each
other. What would differ, though, is the precise execution of these methods.
However, this discussion raises another question. How do we know in the
first place that a dog or a horse can run? (In real life, we would actually know
this!) But consider another object called as employee. Let us imagine that we
Many times,
the list of
are interested in finding out the salary of the employee. What message do we
methods of an need to send to the employee object, so that it can provide us with this infor-
object is mation? We cannot take for granted or hope that the employee object contains
called as the a method for this purpose. As a result, every object must inform the external
interface of
the object. world which methods it provides. In the absence of this, it is not possible for
other objects in the system to send it any messages. The idea to achieve this
objective is actually quite straightforward. Every object must publish a list of
methods that it supports. This enables other objects to consult this list, and
send it appropriate messages. This concept is shown in Fig. 1.16.
I Can Hear you

I Can Smell
I Can Bark
FIG. 1.16
List of
Methods
Published by
the Dog
Object I Can Run
If we consider two objects X and Y, we can imagine that object X can send a
message to object Y. This can be for requesting it to execute one of its meth-
ods. Similarly, object Y can invoke any method of object X by sending it a
message, as shown in Fig. 1.17.
Object X
Data Data Data
Method 1 Method 2
FIG. 1.17
Method 1 Method 2
Objects Send
Messages to
Each Other to Data Data Data Data
Call Each
Object Y
Other’s
Methods
The diagram also illustrates a very critical concept. Objects can call the
methods of other objects by sending messages to each other. However, an
object does not have any direct access to the data portion of another object. An
object protects or hides its data from the outside world. On the other hand, it
publishes data to the entire world. In the real world, there are minor variations
of this concept. For the time being, it is safe to imagine that an object protects
its data, and does not allow another object to access it. However, it exposes its
methods to everyone else so that they can call any of those methods.
We have been discussing the significant effects of global data in the proce-
Access dural technology. Providing for common data access to more than one program
specifiers almost always leads to some sort of problems. Object technology makes the
such as
private,
boundaries between different objects quite crisp and explicit in relation to the
protected, and data items. Since objects are supposed to be self-sufficient entities, it is very
public are important that their internal details are protected from other objects. Other-
used for this; wise, this self-sufficient nature of objects may be in danger. It is, therefore,
as we shall
study later. quite essential to protect the internal details of objects from other objects.
1.2.2 Object Orientation
We hear the term object orientation quite often in the context of object
technology. Object orientation is used for modeling a system. This can be
applied to various aspects of a computer system, such as analysis and design
models, programs, test cases, databases, architecture, etc. Object orientation is
a completely different and novel way of thinking about a system as compared
to the traditional systems.
The point to be stressed here is that we talk of objects, and how they interact
with each other. The computer system that we want to ultimately build would
be based on these objects and their interaction with each other. Thus, objects
would consider other objects as self-contained entities, which can receive mes-
sages and perform appropriate actions. This idea is shown in Fig. 1.18.
We will note that the big advantage of this scheme is the least differences in
the way we imagine the various objects (e.g. students, teacher, books, school)
and the way they can actually be modeled by using a computer-based system.
We now think of computer objects in the same way as real-world objects. This
is really revolutionary. Recall that otherwise the analysts and designers are
generally forced to think in terms of computer-based entities, such as net-
works, databases, programs, etc. right from the inception of a software project.
Here, they can think of real-world objects as, well, objects! The gap between
what we perceive and how we model it is called as the semantic gap between
the two. As we can see, the semantic gap in the case of traditional procedure-
based systems is quite high, but it is remarkably small in the case of object
technology.
This is shown in Fig. 1.19.
Students Meena and Seema ask their teacher Ana about their doubts
FIG. 1.18
Interaction
between
Real-World They also read books and study in the same school
Objects
Outside World
Outside World
Semantic Gap Semantic Gap
Actual Implementation
Actual Implementation
FIG. 1.19
Procedural systems: The semantic Object-oritented systems: The
Semantic Gap gap is quite big semantic gap is quite small
The smaller the semantic gap, the better. This is because a smaller semantic
gap means that there is a small difference between the way we perceive a
computer system and how it is actually built.
There are two main advantages of a making the semantic gap small.
1. It makes understanding the system’s requirements and modeling easy,
and
2. It makes the process of alterations to software easy.
The second point is key, because a smaller semantic gap means that objects
are as much self-contained as possible, and therefore, changes to one object do
not greatly affect other objects in the system.
1.2.5 Practical Example of an Object
Based on our discussion so far, let us think of an object in real life. So far, we
have talked of objects that are abstract in nature, and have no real significance
in computer-based systems. It is now time that we put this discussion to some
Modeling is
quite similar
practical use.
to finding We have mentioned that an object is a self-contained unit. It contains at-
answers to tributes and methods. The attributes of an object are private to that object, and
such are closely guarded from other objects. That is, other objects cannot access or
questions.
modify the attributes of this object. However, the methods of an object are
publicly available to other objects for execution requests.
Let us put these theories to the use of creating an employee object. This
object needs to store information about the employees in an organization, and
also to allow other objects to manipulate its contents by calling its methods.
What are the typical pieces of information that we want to store about an
employee? These would form the attributes of the employee object. Quite
clearly, these attributes are employee number, name, department, manager,
salary, and address.
Next, we need the other objects to be able to access and manipulate the
details of this employee object. This means that we need to provide a few
methods that the employee object uses as its interface with the external world.
These methods need to create a bridge between the employee object and the
other objects in the system. As a very simple example, these methods should
provide the other objects the details about the attributes of the employee ob-
ject, such as the employee number, name, address, department, etc. as and
when needed.
Thus, our set of attributes and methods of the employee object is now
complete. They are listed as shown in Fig. 1.20.
Employee Object
Attributes Methods
l Number l getName
l Name l getSalary
l Salary l getDepartment
FIG. 1.20 l Department l getAddress
l Address
Employee
Object
This object should give us a fairly good idea regarding the look-and-feel of
real-life objects. In fact, the code written to declare an employee object in an
object-oriented language, such as Java or C++ is actually not dramatically
different from the way we have written it here!
1.2.4 Classes
Thus far, we have discussed the idea of objects. Objects are specific in nature.
However, they can be generalized, too. When objects are generalized, they
make up a class. A class is generic in nature, whereas objects are specific
Classes are
generic,
instances of a class. For example, circle, rectangle, square, are all geometric
objects are diagrams. These are objects, whereas figure can be a generic class. Similarly,
specific. Ram, Sham, Ana, Jui, Harsh, are all specific objects, whereas person is a
generic class. Yet another example of specific objects are train, airplane, truck,
car, scooter, etc. The generic class for these objects is vehicle.
Thus, objects are specific instances of class, which is a generic template for
those objects.
This idea is shown in Fig. 1.21 with the example of a diagram class that has
geometric objects as specific instances.
Diagram
Class
Rectangle Octagon
Object Object Circle
Right Object
Triangle
Object
Trapezoid
FIG. 1.21 Object
Isosceles
Class and Triangle
Object
Objects
Declaring classes and objects in a programming language such as C++ or

Java is pretty simple and intuitive. To understand this, we need to simply think
how we declare variables of basic data types such as integers and floating
point numbers. For instance, to declare an integer i and a floating-point num-
ber f, we use the following declarations.
int i;
float f;
What do these declarations convey to the compiler? They signify that i is to
be used as a number, which is an integer, and f is a floating point number. We
can use these basic concepts for declaring classes and objects as well. Just
imagine for a moment that int and float are classes, and i and f are objects of
these two classes, respectively. Extending this idea further, can we declare an
object (say triangle) for the diagram class? The following statement in Java or
C# should achieve it.vehicle car;
diagram triangle;
Thus, we have understood a very important concept, as shown in Fig. 1.22.
Class Object
FIG. 1.22 int i
float f
Classes and diagram triangle
Objects
This idea should help us understand the relationship between classes and
objects very clearly. Just as integers, floating-point numbers, etc. are generic
templates (i.e. classes), so can be other types, such as vehicle, student, person, etc.
For each such class, we can declare one or more specific instances (i.e. objects).
This description does not end our story here. It goes further and tells us a lot
more about classes and objects. A class has general properties, which all of its
objects automatically absorb and inherit. For example, when we think about an
Data types
such as int, we immediately think of it to be a number that cannot have fractional part,
integers, or a value exceeding a maximum number, etc. Therefore, when we declare any
characters, number (say i) as an integer, it obeys all these restrictions by default. Extend-
strings etc.
are called as
ing this concept further, when we declare an employee class and jui as an
primitive or object of this employee class, jui automatically picks up all the default charac-
basic data teristics of the employee class, such as number, name, department, etc.
types.
1.2.5 Declaring Classes and Objects
Let us now revisit the question of how to declare classes and objects in a
programming language, such as Java or C#. For that, let us consider the same
example of declaring a floating-point number. We know that declaring a float-

ing-point number f takes the following simple form.
float f;
We know that float is the class here, and f is its object. In other words, here
we simply declare f as belonging to the category of floating-point numbers. It
automatically knows that it can store fractions, values up to a certain range, and
so on. In a similar fashion, we should be able to declare jui as an employee, and
jui should automatically pick up all the characteristics of an employee. These
characteristics would be those applied to the employee class, i.e. number, name,
department, etc. Therefore, it should be sufficient to make the following

declaration:
employee jui;
However, things do not work this way. This is quite understandable as well.
Programming languages define certain classes as standard or default, which
means that the compilers of these programming languages know how to work
with these classes. All the basic data types are examples of this, such as
integers and floating point numbers. In other words, whenever we declare i as
of type int, the compiler establishes all the characteristics of integers with
reference to i. On the other hand, when we declare jui to be of type employee,
the compiler has absolutely no clue as to what an employee means, and there-
fore, what jui means. Therefore, the declaration of jui as an employee would
fail. This means that we must first inform the compiler what an employee
means. Only when we tell the compiler what characteristics an employee has,
we can create instances or objects of it.
A data type, such as employee is thus made up of many basic data types like
integers, strings, floating point numbers, etc. as shown in Fig. 1.23.
Basic Data Types
string int float …
FIG. 1.23
string int float …
Class
contains
many basic Class
data types
The declaration of an employee class in Java is shown in Fig. 1.24. It is not

a problem if we do not completely understand the syntactical details. Concen-
trate only on the idea.

Once we provide this class declaration, the compiler knows what is the
meaning of an employee. It now treats an object of this employee class in a
manner that is not completely different from an integer variable. Thus, it
simply considers employee as an extended data type. This is also why the
following statement makes sense to the compiler:
employee jui;
It now knows that jui can have a number, name, department, etc. and that
another object can send a message to her to obtain her name, department,
manager, etc.
public class employee {

private int Number;
private String Name;
private int Department; ¨ Attributes
private String Manager;
private String DateOfBirth;
public int getName ( );
public int getDepartment ( );
FIG. 1.24 public int getManager ( ); ¨ Methods
Declaration of
public int getDateOfBirth ( );
Student Class }
1.3 ABSTRACTION
The concept of abstraction is very important in object technology. Abstrac-

tion is indeed quite a fundamental concept in this area. If we think of it,
abstraction is an extremely useful concept in our daily lives, too. As an ex-
Abstraction is
like a vision
ample, we generally do not consider a computer to be made up of many spare
statement. parts and electronic circuits, or a scooter to be made up of 100 different parts.
If we do that, it is difficult to think about them. Instead, we think of all these
things as sub-parts of a computer or a scooter object, respectively. It is need-
less to say that inside these objects there is a set of attributes (spare parts,
devices) and behaviors (can be turned on, can be opened). By doing this, we
are able to think about these objects in an abstract fashion. Thus, we can use a
computer and drive a scooter easily. We are not worried about their technical
details. We think about objects as a whole.
In the world of technology, abstraction is actually not restricted only to
object technology. All programming languages support abstraction at various
levels. Let us understand this.
l A third generation high-level language provides the programmer with high-
level syntaxes, variables, functions, etc. As an illustration, a high-level
language would contain instructions such as ADD, COPY, MOVE, etc. (or
Always their equivalents). Let us consider the example of an instruction MOVE B
remember TO A, which means copy the contents of the variable B to the variable A.
that ultimately l The assembly language is at a lower level in the sense that one instruction
the computer
hardware can in a high-level language maps to one or more assembly language instruc-
only execute tions. For instance, a MOVE instruction in a high-level language could
machine result into multiple assembly language instructions, such as LOAD and
language
instructions.
STORE.
l Next, each assembly language instruction is translated to its corresponding
machine language code. This is the language of zeroes and ones.
lIn the end, the machine language abstracts the voltages and current pulses
inside a computer, and provides a language of zeroes and ones to the
programmer.
This concept is shown in Fig. 1.25.
High Level Language Level MOVE B TO A
LOAD R3
Assembly Language Level
STORE R1
10101111010
FIG. 1.25 Machine Language Level 10010010010
Abstraction in
Programming Hardware Level … Language of Currents and Voltages …
Languages
On the other hand, the idea of abstraction in object technology is more to do

with the abstraction of objects themselves.
Many people confuse object technology merely with object oriented pro-
gramming. These two are not the same concepts. Object technology is an
overall idea. Object oriented programming is just one aspect of object technol-
ogy. Besides object oriented programming, object technology also deals with
object oriented analysis, object oriented design, object oriented testing, etc.
Object oriented programming is just the way of programming objects.
An analyst has to identify different objects, their attributes and methods,
how they are going to interact with each other (messages) to achieve various
functionalities, produce reports and create queries for the application. Then the
designer has to write specifications for the methods of the different objects.
The programmer can then write programs. It is at this stage that object-ori-
ented languages such as Java or C# can be used for coding. These languages
allow us to define and manipulate objects. The ordinary languages such as C
or COBOL do not allow definition of objects (although Enterprise COBOL

that supports object technology features is evolving). Thus, these languages
cannot be used for object-oriented systems. Similarly, we can perform the
analysis in a traditional, structured way, which was process-oriented (where no
objects were identified) and still use object-oriented languages such as C++ or
Java. Here, we will not get the real benefit of object technology in this case.
For getting real benefit, the whole approach from the beginning to the end has
to be object-oriented.
Abstraction is a feature that allows an analyst to concentrate only on the

essential aspects of objects in a system. The analyst can ignore the non-key
aspects of objects. This also allows leaving of many decisions to as late a date
One of the
major mistakes
as possible. Further, it means that the analyst does not need to make commit-
in a software ments regarding the design or implementation of objects. As a result, the
project is to analyst can focus only on the actual problem at hand (i.e. analyzing a system
think about
and its requirements), rather than worrying about the implementation details.
programming
before analysis In other words, abstraction allows an analyst to think about what needs to be
and design. done, rather than how to achieve it. Since this analysis model is at a high level,
it can be extended in the later stages of a software project, such as design
coding, testing and implementation.
Let us consider another example of abstraction. We normally stand in a
queue when we visit a post office, a movie theater, bank ATM, and so on. In a
similar way, the finished products in a factory also move in series to form a
queue. Let us consider that we need to represent these ideas in a computer
program based on object technology. We can use the principles of abstraction
here. That is, we can abstract the two ideas, and think only about the concept
of a (generic) queue. We can apply the same principle in both the examples,
using a single abstraction. The idea is shown in Fig. 1.26.
Window of the
Cashiner
People Waiting Outside the Cashier’s Office in a movie theater

Finished Goods being Moved to the Factory Vehicle

FIG. 1.26
Abstraction
In Out
can be Used
to Generalize
Similar Ideas Generic Mechanism of Representing these as a Queue
1.4 ENCAPSULATION
The technique of encapsulation allows objects to protect their internal details

from an unauthorized access or even alteration from other objects in the sys-
tem. It essentially protects the data in an object. We know that methods of an
Interfaces is a
key OO
object can be used for manipulating the data inside that object. We have to use
concept. one of these methods to update or even view the data. Because of encapsula-
tion, one object cannot interfere with the data of another object except through
the execution of certain methods of that object. We know that this is accom-
plished by means of exchanging messages between objects.
We can take a simple example to further understand the practical usage of
encapsulation. In order to relate this to our daily life, when we start our car, it
(hopefully!) starts. We are not worried about its internal details, such as whether
the battery is charged, there is sufficient engine oil, etc. The car provides us
with a single interface to work with, which is the car’s ignition. We simply
interact with the ignition. However, what happens internally to the car as a
result of our action does not really bother us. We cannot change the state of
the car without the ignition. Of course, the technicians of the car can do that,
but not without playing around with some circuitry of the car. For us, the ignition
is the only interface available for use. Similarly, a television set or a washing
machine has its own interface; only through which we can manipulate it.
As an important aide, opening the door of a fridge does not cause a different
Note object (e.g. the television set) to be affected in any manner. That is, an action on
one object does not cause any change to another object, except through structured
messaging. Every object responds only to its own interface and nothing else.
Encapsulation is a very key aspect of object-oriented technology. Once an
object is ready, all one needs to know is its methods or interfaces. How they
are implemented internally (i.e. the program code of the methods) is not of any
interest. An object is expected to perform a specific, pre-defined task without
worrying about any side effects. To ask an object to do a specific pre-defined
task, its methods are called. Suppose there are two methods in an employee
object for creating a new employee record and updating some of the fields.
This can be as shown in Fig. 1.27.
As the Fig 1.28 shows, a student object gives the view of a black box. It
tells the outside world that its interface is made up of two methods: new and
modify. How they work internally is not known. In fact, hardly anything else is
Messaging
facilitates known about the employee object apart from these two method names. To
inter-object update the mark details of a student, for instance, the modify method must be
communication. called. To that method, the new address should be passed. That is the whole
idea. Other objects need not know anything about the internal structure of the
New Modify
Student
FIG. 1.27
Encapsulation
FIG. 1.28
Pay
Encapsulation
Enables Cardholder Merchant
Message Receipt
Exchanges
between
Objects
student object. That way, the internal structure of the student object can be
changed without affecting other objects.
This concept is shown in Fig. 1.28 with another example. Here, a credit card
object sends a message pay to the card object. This will cause the transfer of
funds from the card account to the merchant account. The cardholder object
does not know how the merchant object works internally. However, the
cardholder object performs the action (i.e. transfer of funds) successfully and
returns an acknowledgement in the form of a receipt to the cardholder object.
This is precisely what the cardholder object expects, anyway!
Thus, the main idea of encapsulation is hiding of internal details of an
object. Essentially, we keep the internal details of an object clearly distinct
from its external view. This also means that the changes to the internal details
of one object do not cause many rippling changes to other objects in the
system. These changes to an object could be due to many reasons, such as

business reasons, change in requirements, defect fixing, performance improve-
ment, etc.
By using the idea of encapsulation, objects become largely self-sufficient
and fairly independent of each other. One object need not depend on, or inter-
fere with, other objects in the system. At the same time, since each object
knows how it can interact with any other object (by calling its methods), this
does not impose any limitations on the interaction between objects.
An interesting way to depict encapsulation is shown in Fig. 1.29. Here, we
show an object that has certain attributes, and it possesses certain methods.
The attributes portion is completely hidden from the outside world. This is
indicated by mentioning the attributes that are hidden (which is what the out-
side world sees). However, the object has a border consisting of methods,
which allow other objects to interact with it, by sending messages.
Message
Method Method
Method
Attributes
Message Hidden Message
Inside
Method
FIG. 1.29
Message
Another Way
to Depict
Abstraction
1.5 OOAD METHODS
The term Object Oriented Analysis and Design (OOAD) was coined in order
to differentiate it from the classical analysis and design techniques, such as
OOAD is a Structured System Analysis and Design (SSAD) and the Jackson Methodol-
concept, but it ogy. OOAD has attracted a lot of interest in the last few years, and in fact, it
can be has almost become the de facto standard for majority of newly undertaken
applied in
different ways. software projects.

The structure and organization of OOAD is actually not significantly differ-
ent from the earlier techniques, such as SSAD. Both the techniques involve a
similar series of steps (called as phases), namely: Analysis, Design, Develop-
ment, Testing and Implementation, as shown in Fig. 1.30. However, where
OOAD differs from SSAD (or other equivalent models) is in terms of what is
done in these phases. The approach and the mindset that the analyst/designer is
expected to have in OOAD is quite different from the one she is expected to
exhibit in the case of SSAD.
Requirements
Analysis
Design
Development
Testing
FIG. 1.30
Phases in a
Software Implementation
Project
OOAD has evolved over several years. There have been many methodolo-
gies that have been proposed. OOAD as it stands today is actually a mixture of
these methodologies. We shall discuss some of the main OOAD methodologies
One of the
biggest
in brief. This will provide us a good background in terms of understanding
problems with how and why OOAD is the way it is today. Of the people who have done solid
the different groundwork in the area of OOAD are Grady Booch, Evor Jacobson, and James
methodologies
Rumbaugh. Their methodologies are still studied separately to gain an insight
is that they
use different into their work. However, more often, a combination of these methods is now
symbols to studied and applied, as it combines the best features of all of them.
depict the Our focus would be to present a brief yet crisp overview of these method-
same thing.
ologies, and in the later chapters, show how these converge to a single method
called as Rational Unified Process (RUP).
1.5.1 Booch Method
The Booch The Booch method is a well-known OO method,

methoddefines which helps us in designing a system using objects.
different models to It covers the analysis and design aspects of an OO
describe a com- system.

puter system. Booch has defined many symbols to document pos-
sibly every design decision. The main aspect of the
Booch method is that the method is descriptive. In other words, Booch ex-
plains what we can do in terms of system definition, but he does not provide us
any guidelines regarding what we should do so as to come up with a better
analysis and design model of the system.
The Booch method begins with class and object diagrams in the analysis
phase. That is, we first try and find out all the possible classes and objects in a
given system. We draw diagrams to document them. Later on, we refine these
diagrams through various steps, by means of an evolutionary approach. Only

when the code is about to be written, we add the design symbols. In other
words, the design symbols depict the very final implementation decisions.
Thus, in the Booch method, it is possible to fully document the OO code.
Booch defines different models to describe an OO system. These models are:
Physical Model The physical model describes the various processes and
modules that the system will have at a later stage.
Logical Model The logical model describes the classes and objects in the
The central system. In other words, it describes the problem domain. It discusses the classes
theme of
and objects in a system.
another OOAD
methodology, Static Model The static model describes how the classes and objects in a
that of
system are related to each other.
Rambaugh,
is modeling. Dynamic Model This model shows how the classes, objects, and other aspects
of a system work together to produce the desired results. It talks of the various
scenarios that a system would depict, and how these would be depicted.
As mentioned earlier, Booch makes extensive use of diagrams. The designer
of a system can use a variety of symbols and diagrams to depict the underlying
design. The examples of such diagrams are:
l The Class Diagram
l The Object Diagram
l The Module Diagram
The Unified
l The State Diagram
Modeling
Language l The Interaction Diagram
(UML) provides l The Process Diagram
a set of all The designer supports these with specifications that—describe the symbols
such
standardized in the diagrams. However, we should realize that there may not be an exact
diagrams. one-to-one relationship between a model and a particular view of that model.
Some diagrams and/or textual descriptions can contain information from sev-
eral models. On the other hand, some models can incorporate details that are
captured across several diagrams. Each model component and their relation-
ships can appear in zero, one, or several models diagrams.
Booch uses a cloud symbol to depict a class. An example of this is shown in

Fig. 1.31.
The interaction between classes is shown with the help of a connector line
that joins the two classes. This connection is based on calling a particular
method of the classes. For example, let us assume that we have two classes
named A and B. Let us suppose furthermore that class A wants to get in touch
with class B, by calling the method M of class B. Then we show an arrow from
A and B, indicating the direction of the processing.
Let us now describe the essence of the Booch method. The Booch method-
ology focuses on some key areas of object technology, as follows.
Class name
Attributes
Operations ( )
{Constraints}
FIG. 1.31
Class Symbol
Ä Abstraction
Abstraction denotes the essential characteristics of an object that distinguish it
from all other kinds of objects. Furthermore, it provides crispy defined concep-
All OOAD
tual boundaries, relative to the perspective of the viewer. Booch recommends
methodologies that the designer identify these boundaries as soon as possible, and that the
talk about programming languages that transform this design into actual code should also
these general respect these boundaries, and implement them. For this purpose, it is important
concepts, and
hence we need to identify four important artifacts of a system:
not repeat the (a) Instance methods These methods are accessible to any object (i.e. any
discussion for
all of them. instance) of a class.
(b) Instance attributes These attributes are accessible to any object (i.e.
any instance) of a class.
(c) Class attributes These attributes are accessible to all the objects (i.e. all
the instances) of a class, but all the instances share the same value of a
given attribute.
(d) Class methods These methods are accessible to all the objects (i.e. all
the instances) of a class, but they all can be used independently of any object.
Ä Modularity
Modularity is the property of a system that has been decomposed into a set of
cohesive and loosely coupled modules. In other words, the programming imple-
mentation of an object-oriented design should provide for the classification of
related classes and objects into packages or files. This helps in terms of a
better organization and logical referencing of classes.
Ä Encapsulation
Encapsulation is the process of hiding all the details of an object that do not
contribute to its essential characteristics. That is, the designer should classify
the attributes and methods of a class into various categories:
(a) Private Those attributes and methods that should belong only to the
class and no other class should even know about their existence.
(b) Protected Those attributes and methods that also belong to a class and
should only be known to that class, but with one exception. When the class
is inherited by another class, the child class can also access these attributes
This will be
clear when we
and methods.
discuss (c) Public Those attributes and methods that are declared in a class, but are
inheritance.
globally accessible to all the other classes in the system.
Ä Hierarchy
Hierarchy builds an order or a rank of the various abstractions. This is mainly
implemented in the form of inheritance relationships, which can go down to
multiple levels.
Ä Typing
Typing is the enforcement of a class of an object in such a way that objects of
different type may not be swapped. At the most, they might be swapped in
very restricted manners.
Ä Concurrency
Concurrency distinguishes one object that is active from an inactive object.
Ä Persistence
Persistence is the characteristic of an object through which it always exists.
Persistence
means storing That is, even when the creator of an object no longer exists, the object contin-
on the disk. ues to exist.
1.5.2 Jacobson Method
A use case is an The Jacobson model concentrates primarily on the

operation, or a concept of use cases. A use case is an operation, or
transaction per- a transaction performed in a system. For example,
formed in a Prepare pays-slips can be considered a use case in a
system. payroll application. The Jacobson method begins by

identifying the users (called as the actors) of the
system. It then goes on to find out their responsibilities. The next step in this
method to build a model of the users’ requirements. For this purpose, the
following steps are performed:
l Define the actors and their responsibilities
l Identify use cases for each actor
l Prepare initial view of system objects and relationships
l Review model using use cases as scenarios to determine validity
Thus, we begin by identifying the users of the system, here called as actors.
These actors can be human or non-human. For example, a person preparing
pay-slips is a human actor. On the other hand, a scanner digitizing a document
is an example of a non-human actor. Having identified the actors, we then
identify what tasks each of these actors would perform (i.e. the use cases).
Then we create a relationship between the actors and the use cases. Finally, we
create scenarios to validate these relationships. Thus, we can summarize:
l Identify interface objects by using information about actors and their inter-
actions
l Create structural views of the interface objects
l Represent object behaviour (i.e. methods)
l Isolate subsystems and models for all of them
l Review the model by using use cases as scenarios to determine validity
1.5.3 Rumbaugh Method
The Rumbaugh method is perhaps the simplest of the three to understand. As

such, we shall use this method as the basis for our further explanations. This
method talks about three models depicting a system:
1. Object Model Here, we identify the classes, objects, and attributes in a
system. Next, we define the interrelationships between them. We also identify
inheritance relationships here. This is a graphic representation that describes
Modeling is
the process of
the structure of objects within the system, i.e. their identities, relationships to
performing other objects, attributes and operations. It provides the context within which
these actions the other two models are placed.
together.
2. Dynamic Model This model is used to develop scenarios. These scenarios
are then linked to the various events that happen inside a system. Diagrams
depicting the flow of events and the transition from one state of the system to
another are prepared. The dynamic model is thus ready, and it is then vali-
dated. This model shows the behavior of the system over time. That is, it
shows how the system changes state in response to various events. State dia-
grams are used to describe the sequence of events. The focus is not how these
events occur, but it is on when they occur.

3. Functional Model Here, we talk about the inputs that the system receives
from the external world, and the outputs that it provides back. Data flow
diagrams are used to depict the flow of data from one point of the system to
another. Finally, specifications are prepared for all the processes defined in the
diagram. Thus, it looks at how values change and transform.
1.5.4 Rational Unified Process (RUP) Method
The Rational Unified Process (RUO) model is essentially a combination of

the above three methods (and also of a few more methods less well known). The
RUP method talks about four distinct steps of a software project, as follows:
Ä Inception
This step deals with the initial high-level planning of the project. We deter-
We shall mine the scope of the project here. We also discuss some of the business
discuss this in decisions and their impacts. Other factors such as costing, estimation, and
a separate
chapter.
projected revenue also come into picture.
Ä Elaboration
This step primarily deals with the requirements gathering, analysis, and design
phases of a project. We also develop an outline for the construction phase of
the project here. The risks pertaining to the project are also identified and a
risk mitigation plan prepared. The risks can be of various natures, such as
technological, business-related, political, skills-related, requirements-related,
etc. The resulting artifacts of the elaboration phase are use cases, the domain
and technology models, and the risk mitigation plan.
Ä Construction
In this phase, the use cases are transformed into actual program code. It is
quite possible that the analysis and design steps get refined here, as more
clarity is needed in order to perform the actual construction activities. Soft-
ware testing also plays a crucial role. The product should be tested as much
and as early as possible.
Ä Transition
This is the phase just before the main release of a software product. Here,
things like scalability, optimization, performance etc. are primarily addressed.
The steps necessary to transform the product from a piece of software to

something that users can actually use and feel are carried out in this phase.
1.5.5 The Fountain Model
The fountain model depicts the essence of OOAD. It is a diagram that re-
minds us about the fact that although some life cycle activities cannot start
before others (e.g. we cannot start coding before we have started designing),
there is a considerable overlap and combining of activities across the full
software life cycle.
As we know, in a fountain, water rises up a certain level and then falls

down, either to the pool below or it reenters at an intermediate level. Similarly,
in an object-oriented software development where the general flow from analysis
through design to implementation is iterative. These iterations or cycles hap-
pen across two (or all the three) of these broad phases, i.e. analysis, design and
construction. The pool here is the repository of classes.
Figure 1.32 outlines the general characteristics of the fountain model. It
shows that there is a high degree of merging in the analysis, design, implemen-
tation and unit testing phases.
Evolution
Maintenance
Program
Use
System
Testing
Unit Testing
Coding
Component
Design
Conceptual
Design
Analysis
Requirements and
Feasibility Study
FIG. 1.32
Software Pool
Fountain
model
CHAPTER SUMMARY
n Traditionally, focus was on hardware. Over the last few years, it has changed to
software.
n Software projects have become extremely complex and costly. Hence, older
methodologies are no longer advisable.
n The earliest software approach was on the basis of procedural programming.
n Modular programming came later, where the programs were divided into smaller,
more manageable modules.
n Object technology is a newer method of designing and developing software.
n Object technology introduces the concept of an object. An object contains both
data (called as the attributes of an object) and its functionalities (called as meth-
ods).
n Objects interact with each other by passing messages.
n Generic form of objects, i.e. a template for similar kinds of objects is called as
class.
n Abstraction is an important concept in object technology. It allows the designer
to focus on the significant concepts and ignore unimportant details.
n Encapsulation protects the data in an object.
n The term Object Oriented Analysis and Design (OOAD) was coined in order to
differentiate it from the classical analysis and design techniques, such as Struc-
tured System Analysis and Design (SSAD) and the Jackson Methodology.
n OOAD has evolved over several years.
n The early efforts in OOAD can be attributed to Grady Booch, Ivar Jacobson, and
James Rumbaugh.
n Of late, a combination of these methodologies has become popular, called as the
Rational Unified Proecss (RUP) model.
n The fountain model provides some insights into the working of OOAD.
KEY TERMS AND CONCEPTS

Abstract Functional model

Abstraction Jacobson method
Attribute Logical model
Booch method Message
Class Method
Dynamic model Modular programming
Encapsulation Model
Fountain model Object
Object Oriented Analysis Semantic gap

and Design (OOAD) Static model
Physical model Structured System Analysis
Procedure and Design (SSAD)
Rumbaugh method Subroutine
Rational Unified Process (RUP) Use case
PRACTICE EXERCISES
True/False Questions
1. Software has always been more important than hardware.
2. Modular programming came after procedural programming.
3. An attribute has no consequence in the object technology world.
4. A method is similar to a function.
5. Class is a generic template for objects.
6. Abstraction is the same as inheritance.
7. An object contains only attributes.
8. Modeling is important to the object world.
9. RUP is a combination of the best of all OOAD methods.
10. The fountain model helps depict the OOAD process.
Multiple Choice Questions

1. In , any program can call any other program.
(a) modular (b) object (c) procedural (d) component
2. An object contains .
(a) attributes and methods (b) only attributes
(c) only methods (d) neither attributes nor methods
3. A is a generic template for objects.
(a) program (b) class (c) procedure (d) method
4. In abstraction, we concentrate on .
(a) minor details (b) procedures

(c) processes (d) important details
5. helps us in protecting privacy of objects.
(a) Encapsulation (b) Abstraction
(c) Inheritance (d) Polymorphism
6. A method of an object cannot be accessed by other objects.
(a) protected (b) private (c) public (d) general
7. The Rumbaugh model describes models.
(a) 5 (b) 4 (c) 3 (d) 2
8. The model concentrates on use cases.

(a) Booch (b) Jacobson (c) Jackson (d) Rumbaugh
9. The combination of the major OOAD methodologies is called as .
(a) Objectivity (b) OOSE (c) RUP (d) SSAD
10. The model depicts RUP.
(a) structured (b) dynamic (c) object (d) fountain
Detailed Questions
1. What is the software crisis?
2. What is the problem with traditional software development?
3. Define procedural programming.
4. What is modular programming?
5. Discuss the concept of an object.
6. What is a class?
7. Explain the idea of abstraction.
8. What is encapsulation?
9. Discuss any of the OOAD approaches.
10. What is RUP?

An Introduction To Object Technology: The Traditional Approach

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

An Introduction To Object Technology: The Traditional Approach

Uploaded by

Copyright:

Available Formats

+

1.1.1 The Software Crisis

The traditional focus of computer systems had been on the hard-

New Hardware is Write New Software to

2. Complexity of the Software Projects The second major issue related to

Challenges Modern Software

3. Changes in Business Environment Apart from the technical issues just

1.1.2 Software Construction

Ä The Earliest Approach

Main Payroll Program

FIG. 1.5 Calculate-Salary

When a Program is Big, It Subroutine B

Read Data Main Menu Write Data

Modules at Inquiry Update Delete

Sales Tracking Application

Traditional Customer Details Sales People Details Sales Details

data elements is small. However, this approach has serious implications, if it is

Even worse, suppose that program A is changed tomorrow, so that instead of

Sales Tracking Application

1.2 OBJECT TECHNOLOGY BASICS

to a programming language called as Simula. The name Simula was an abbre-

observing so far. In the procedural world, the emphasis is on operations. Data

Data Data Data

Object Object Object

Operations Operations Operations

As an illustration, in a payroll application, the objects could be employee,

Let us examine a few more important terms now.

Remarkably, this nature of objects makes them self-sufficient. For instance,

I Can Hear you

Data Data Data

1.2.2 Object Orientation

Semantic Gap Semantic Gap

Semantic Gap gap is quite big semantic gap is quite small

1.2.5 Practical Example of an Object

Declaring classes and objects in a programming language such as C++ or

1.2.5 Declaring Classes and Objects

example of declaring a floating-point number. We know that declaring a float-

department, etc. Therefore, it should be sufficient to make the following

Basic Data Types

string int float …

The declaration of an employee class in Java is shown in Fig. 1.24. It is not

trate only on the idea.

public class employee {

The concept of abstraction is very important in object technology. Abstrac-

High Level Language Level MOVE B TO A

On the other hand, the idea of abstraction in object technology is more to do

or COBOL do not allow definition of objects (although Enterprise COBOL

Abstraction is a feature that allows an analyst to concentrate only on the

People Waiting Outside the Cashier’s Office in a movie theater

Finished Goods being Moved to the Factory Vehicle

The technique of encapsulation allows objects to protect their internal details

system. These changes to an object could be due to many reasons, such as

1.5 OOAD METHODS

different ways. software projects.

1.5.1 Booch Method

The Booch The Booch method is a well-known OO method,

describe a com- system.

diagrams through various steps, by means of an evolutionary approach. Only

Booch uses a cloud symbol to depict a class. An example of this is shown in

1.5.2 Jacobson Method

A use case is an The Jacobson model concentrates primarily on the

system. payroll application. The Jacobson method begins by

1.5.3 Rumbaugh Method