Object Oriented Analysis and Design
Thursday, 14 May 2015
Object Oriented Testing
Find
the greatest possible number of errors with a manageable amount of effort
applied over a realistic time span.
·
The
nature of OO programs changes both testing strategy and testing tactics.
·
Do we need less effort for testing because of
greater reuse of design patterns?
·
Answer
is no! Binder argues that more testing is needed to obtain high reliability in
OO systems, since each reuse is a new context of usage. Testing
Object-Oriented Applications: Why is it Different?
·
No sequential procedural executions
·
No structure charts to design integration testing
·
Iterative O-O development and its impact on testing and integration
strategies
·
In OO testing begins by evaluating the OOA and OOD models
·
What is Unit?
·
Encapsulation, Inheritance, Polymorphism.
Criteria for Completion of Testing
·
When are we done testing?
·
_ How to answer this question is
still a research question
1.
One view: testing is never done… the burden simply shifts from the
developer to the customer
2.
Or: testing is done when you run out of time or money
3.
Or use a statistical model:
− Assume that errors decay logarithmically with
testing time
− Measure the number of errors in a unit period
− Fit these measurements to a logarithmic curve
− Can then say: “with our experimentally valid
statistical model we have done sufficient testing to say that with 95%
confidence the probability of 1000 CPU hours of failure free operation is at
least 0.995”.
Testing OO Code
The Structured Testing Pyramid
The OO Testing Pyramid Testing OOA and OOD Models
The review of OO analysis and
design models is especially useful because the same semantic constructs (e.g.,
classes, attributes, operations, messages) appear at the analysis, design, and
code
level.
Analysis and design models cannot
be tested in the conventional sense, because they cannot be
executed.
Testing O
OOA and OOD Models
Formal technical review can be used to examine the
correctness and consistency of both analysis and design models.
ü Correctness:
o
Syntax: Each model is reviewed to ensure that proper modeling conventions
have been maintained.
o
Semantic: Must be judged based on the model’s conformance to the real
world problem domain by domain experts.
ü Consistency:
o
May be judged by considering the relationship among entities in the model.
o
Each class and its connections to other classes should be examined.
o
The Class-responsibility-collaboration model can be used.
ü Completeness
Model
Testing Approaches
ü Testing by comparison
compares each model to its predecessor or to
previous forms of the model
ü Testing by inspection
uses checklists to make sure that the model meets
certain criteria
ü Testing by verification
follows certain steps to assure completeness and consistency
of one part of the model with another.
Examples of Analysis
and Design Models to be Tested ü CRC cards
ü Class specifications
ü Use cases
ü State-Transition Models (State
Diagram)
ü State transition diagrams for
classes, clusters, and subsystems
ü Sequence Diagrams.
Testing the
Class Model
CRC Cards: Check that all collaborations
are properly represented.
− Example: in a point of sale system.
− A read credit card responsibility of
a credit sale class is accomplished
if satisfied by a credit card collaborator
ü Have you tested your analysis and
design?
If not, who will do it?
These steps are applied iteratively to
each class and through each evolution of the OOA model.
Unit Test
ü What is a unit?
A
single, cohesive function?
A
function whose code fits on one page?
The
amount of code that can be written in 4 to 40 hours?
Code
that is assigned to one person?
ü We can no longer test a single
operation in isolation but rather as part of a class.
ü In object-oriented programs, a
unit is a method within a class.
ü Smallest testable unit is the
encapsulated class.
Methods for
Generating Test Cases For Unit Testing
ü Statement coverage
ü _ Graph based
ü Condition coverage
ü Path coverage
_
All unit testing
methods are also applicable to testing methods within a class.
Class Test
Case Design
1.
Identify each test case uniquely
- Associate test case explicitly
with the class and/or method to be tested
2.
State the purpose of the test
3.
Each test case should contain:
a. list of specified states for
the object that is to be tested
b. A list of messages and
operations that will be exercised as a consequence of the test
c. A list of external conditions
for setup (i.e., changes in the environment external to the software that must
exist in order to properly conduct the test)
d. Supplementary information that
will aid in understanding or implementing the test
−
Automated unit testing tools facilitate these requirements.
Challenges
of Class Testing OO
class is the target for test case design.
Encapsulation:−
Difficult to obtain a snapshot of a class without building extra methods which
display the classes’ state
Inheritance and polymorphism:−
Each new context of use (subclass) requires re-testing because a method may be
implemented differently (polymorphism).
−
Other unaltered methods within the subclass may use the redefined method and
need to be tested
White box tests:−
Basis path, condition and loop tests can all apply to individual methods, but
don’t test interactions between methods
Integration
Testing
OO does not have a hierarchical control structure so
conventional top-down and bottom-up integration tests have little meaning
Integrating operations one at a time into a class is
often impossible because of the direct and indirect interactions of the
components that make up the class.
_
Integration applied
three different incremental strategies:
−
Thread-based testing: integrates
classes required to respond to one input or event
−
Use-based testing: integrates classes
required by one use case
−
Cluster testing: integrates classes
required to demonstrate one collaboration
Types of
Errors Found During Integration TestingMessaging errors:ü Failure to meet a requirement, i.e., no method to send or receive a message
ü Incompatible method and message
in sender and receiver
ü Incorrect instantiation or
destruction of objects
System Testing Software
may be part of a larger system. This often leads to “finger pointing” by other
system dev teams
ü
Finger pointing defense:
1.
Design error-handling paths that test external information
2.
Conduct a series of tests that simulate bad data
3.
Record the results of tests to use as evidence
_
Types of System Testing:
−
Recovery testing: how well and quickly does the system recover from faults
−
Security testing: verify that protection mechanisms built into the system will
protect from unauthorized access (hackers, disgruntled employees, fraudsters)
−
Stress testing: place abnormal load on the system
−
Performance testing: investigate the run-time performance within the context of
an integrated system
All
rules and methods of traditional systems
testing
are also applicable applicable to object-oriented.
_
Use cases provide a more precise mechanism for writing test cases.
Automated
Testing
ü Junit at
Junit.org
ü CPPUnit on
SourceForge.net,
ü NUnit for
.Net
ü Rational
Robot.
OO Testing
Methodology Stages of
Test [RUP]_
Developer Testing
_
Unit Test
_
Integration Test
_
System Test
_
Acceptance Test
Test
Planning [RUP]
ü What iteration you are in?
ü What stage of test (unit test,
integration test, system test) you are performing?
ü Types of test (functional,
stress, volume, performance, usability, distribution, and so on).
ü Evaluation criteria used
(code-based test coverage, requirements-based test coverage, number of defects,
mean time between failure, and so on.)
ü Testing techniques used (manual and
automated).
Completion
Criteria [RUP]
object model
Elements of
the Object Model
There are five main
kinds of programming styles, listed here with the kinds of abstractions they
employ:
1. Procedure-oriented Algorithms
2. Object-oriented Classes
and objects
3. Logic-oriented Goals,
often expressed in a predicate calculus
4. Rule-oriented If–then
rules
5. Constraint-oriented Invariant relationships
There is no single
programming style that is best for all kinds of applications. For example,
rule-oriented programming would be best suited for the design of a knowledge
base, and procedure-oriented programming would be best for the design of
computation-intense operations.
Each
of these styles of programming is based on its own conceptual framework. Each
requires a different mindset, a different way of thinking about the problem. For
all things object-oriented, the conceptual framework is the object model. There
are four major elements of this model:
1. Abstraction
2. Encapsulation
3. Modularity
4. Hierarchy
There
are three minor elements of the object model:
1.
Typing
2.
Concurrency
3.
Persistence
By minor,
we mean that each of these elements is a useful, but not essential, part of the
object model.
The
Meaning of Abstraction
An
abstraction denotes the essential characteristics of an object that distinguish
it from all other kinds of objects and thus provide crisply defined conceptual boundaries,
relative to the perspective of the viewer.
·
Entity abstraction An object that represents a
useful model of a problem domain or solution domain entity
·
Action abstraction An object that provides a
generalized set of operations, all of which perform the same kind of function
·
Virtual machine abstraction An object that
groups operations that are all used by some superior level of control, or operations
that all use some junior-level set of operations
·
Coincidental abstraction An object that packages
a set of operations that have no relation to each other
Abstraction of a Temperature Sensor
OBJECT-ORIENTED PROGRAMMING PARADIGMS
OBJECT-ORIENTED PROGRAMMING
PARADIGMS
The
object-oriented approach to programming is an easy way to master the management
and complexity in developing software systems that take advantage of the
strengths of data abstraction. Data-driven methods of programming provide a
disciplined approach to the problems of data abstraction, resulting in the development
of object-based languages that support only data abstraction. These
object-based languages do not support the features of the object-oriented paradigm,
such as inheritance or polymorphism. Depending on the object features
supported, there are two categories of object languages:
1.
Object-Based Programming Languages
2.
Object-Oriented Programming Languages
Object-based
programming languages support encapsulation and object identity (unique
property
to
differentiate it from other objects) without supporting important features of
OOP languages such as polymorphism, inheritance, and message based
communication, although these features may be emulated to some extent. Ada, C,
and Haskell are three examples of typical object-based programming languages.
Object-based
language = Encapsulation + Object Identity
Object-oriented
languages incorporate all the features of object-based programming languages, along
with inheritance and polymorphism (discussed later in this chapter). Therefore,
an object-oriented programming language is defined by the following statement:
Object-oriented
language = Object-based features + Inheritance + Polymorphism
Object-oriented
programming languages for projects of any size use modules to represent
the physical building blocks of these languages. A module is a logical grouping
of related declarations, such as objects or procedures, and replaces the
traditional concept of subprograms that existed in earlier languages.
The following are important features in
object-oriented programming and design:
1. Improvement over the structured programming
paradigm.
2.
Emphasis on data rather than algorithms.
3.
Procedural abstraction is complemented by data abstraction.
4.
Data and associated operations are unified, grouping objects with common
attributes, operations, and semantics. Programs are designed around the data on
which it is being operated, rather than the operations themselves. Decomposition,
rather than being algorithmic, is data-centric. Clear understanding of classes and
objects are essential for learning object-oriented development. The concepts of
classes and objects help in the understanding of object model and realizing its
importance in solving complex problems. Object-oriented technology is built
upon object models. An Object is anything having crisply defined conceptual
boundaries. Book, pen, train, employee, student, machine, etc., are examples of
objects. But the entities that do not have crisply defined boundaries are not
objects. Beauty, river, sky, etc., are not objects.
Model
is the description of a specific view of a real-world problem domain showing
those aspects, which are considered to be important to the observer (user) of
the problem domain. Object-oriented programming language directly influences
the way in which we view the world. It uses the programming paradigm to address
the problems in everyday life. It addresses the solution closer to the problem
domain.
Object
model is defined by means of classes and objects. The development of
programs using object model is known as object-oriented development. To learn
object-oriented programming concepts, it is very important to view the problem
from the user’s perspective and model the solution using object model.
ABSTRACTION
ABSTRACTION
The essential features of an entity are known as abstraction.
A feature may be either an attribute reflecting a property (or state or data)
or an operation reflecting a method (or behavior or function). The features
such as things in the trunk of a car, the medical history of the manager
traveling in the car, and the working mechanism of the car engine are not
necessary for the driver. The essential features of an entity in the
perspective of the user define abstraction. A good abstraction is achieved by
having:
·
meaningful
name such as driver reflecting the function
·
minimum
and at the same time complete features
·
coherent
features
Abstraction specifies necessary and
sufficient descriptions rather than implementation details. It results in separation
of interface and implementation.
COMPARISON OF NATURAL AND CONVENTIONAL PROGRAMMING METHODS
In
conventional programming, structured or procedural languages are used. In the
structured programming approach, functions are defined according to the algorithm
to solve the problem. Here, function abstractions are concentrated. A function
is applied to some data to perform the actions on data. This approach may be called
a data-driven approach, which involves operator/operand concept. It
depends on the solution domain because the algorithm (solution) is closer to
the coding of the program. The relationship between the programmer and the
program is emphasized in the data-driven approach. The solution is
solution-domain specific. Conventional programming follows the following
principles:
·
operator-operand concept
·
function abstraction
·
separation of data and functions
The
development of the algorithm is given prime importance in conventional
programming. The
importance
of data is not considered and hence, sometimes critical data having global
access may result in miserable output. The abstraction followed is function
abstraction and not data abstraction. Data and functionalities are considered
as two separate parts.
But,
in the natural way of solving real-world problems, the responsibility is
delegated to an agent. The solution is proposed instead of developing an
algorithm. The problem is solved by having a number of agents (interfaces). The
interface part is the user’s viewpoint, and hence the solution is not closer to
the coding of the program. The real-world problem is solved using a
responsibility-driven approach. In this approach, the relationship between the
user and the programmer is emphasized. Here, the solution is problem
domain-specific. The natural way of problem solving follows the following basic
principles:
·
message passing
·
abstraction
·
encapsulation
The
importance of data is realized through object-oriented technology, which
follows the natural way of solving problems. Data abstraction and data encapsulation
help to make the abstract view of the solution
with
information hiding. Data is given the proper importance and action is initiated
by message passing. Data and functionalities are put together resulting in
objects and a collection of interacting objects are used to solve the problem.
Object-oriented programming languages are developed based on object-oriented technology.
MODULARITY
The
complexity of a program can be reduced by partitioning the program into
individual modules. In object-oriented programming languages, classes and
objects form the logical structure of a system. Modules serve as the physical
containers in which the classes and objects are declared. Modularity is the
property of a system that has been decomposed into a set of cohesive and
loosely coupled modules. A module is an indivisible unit of software that can
be reused. The boundaries of modules are established to minimize the interfaces
among different parts of the development organization. Modules are frequently
used as an implementation technique for abstract data type. Abstract data type
is a theoretical concept and module is an implementation technique. Each class
is considered to be a module in OOP.
The
responsibilities of classes are defined by means of their attributes and
behavior. But a single object alone is not very useful. Higher order
functionality and complex behavior are achieved through interaction of objects
in different modules. Hence, interaction of objects is very important. Software
objects interact and communicate with each other by sending messages to each
other. The activities are initiated by the transmission of a message to an
object responsible for the action. The message encodes the request and the
information is passed along with the message as parameters. There are three
components to comprise a message:
·
The
receiver objects to whom the message is addressed.
·
The
name of the function performing the action.
·
The
parameters required by the function.
Interaction between objects is
possible with the help of message passing. In the case of distributed applications,
objects in different machines can also send and receive messages.
HOW
TO DESIGN A CLASS?
A
class is designed with a specific goal. Its purpose must be clear to the users.
An entity in solving a problem is categorized as a class if there is a need for
more than one instance of this class. Also, it is very important to entrust a
responsibility to an object. Presenting simply the behaviors such as reading
data and displaying data in a class is a poor design of a class. To perform
complex tasks, one class must jointly work with the other classes to perform
the task. This approach is known as collaboration among classes. The class must
be designed with essential attributes and behavior to reflect an idea in the
real world.
The
terms class and object are very important in object-oriented programming. A
class is a prototype or blueprint or model that defines the variables and
functions in it. The variables defined in a class represent the data, or
states, or properties, or attributes of a visible thing of
a certain type. Classes are user-defined data types. It is possible to create a
lot of objects of a class. The important advantages of classes are:
·
Modularity
·
Information hiding
·
Reusability
DESIGN
STRATEGIES IN OOP
Object-oriented
programming includes a number of powerful design strategies based on software
engineering
principles. Design strategies allow the programmers to develop complex systems
in a manageable form. They have been evolved out of decades of software
engineering experience. The basic design strategies embedded in object-oriented
programming are:
i.
Abstraction
ii.
Composition
iii.
Generalization
The
existing object-oriented programming languages support most of these features.
Composition
A
complex system is organized using a number of simpler systems. An organized
collection of smaller components interacting to achieve a coherent and common
behavior is known as composition. There are two types of composition:
1.
Association
2. Aggregation
Aggregation
considers the composed part as a single unit whereas association considers each
part of composition as a separate unit. For example, a computer is an
association of CPU, keyboard, and monitor. Each part is visible and manipulated
by the user. CPU is an aggregation of processor memory and control unit. The
individual parts are not visible and they cannot be manipulated by the user.
Both types of composition are useful. Aggregation provides greater security
because its structure is defined in advance and cannot be altered at runtime.
Association offers greater flexibility because the relationships among the visible
units can be redefined at run time. It adapts to changing conditions in its
execution environment by replacing one or more of its components. The two types
of composition are frequently used together. A computer is an example for
combination of both association and aggregation.
Generalization
Generalization
identifies the common properties and behaviors of abstractions. It is different
from abstraction. Abstraction is aimed at simplifying the description of an
entity, whereas generalization identifies commonalities among a set of
abstractions. Generalizations are important since they are like “laws” or
“theorems”, which lay the foundation for many things. Generalization helps to
develop software capturing the idea of similarity.
object orientation
What
is object orientation?
The term object orientation (OO) means
that we organize software as a collection of discrete objects that incorporate
both data structure and behavior.
There is some dispute about exactly what
characteristics are required by an OO approach, but they generally include four
aspects:
1.
identity,
2.
classification,
3.
inheritance,
4.
Polymorphism.
Identity means that data
is quantized into discrete, distinguishable entities called objects. Workstation
and the white queen in a chess game are examples of objects.
Classification means that
objects with the same data structure (attributes)
and behavior (operations) are
grouped into a class. Paragraph, Monitor, and Chess Piece are examples of
classes.
A Class is an abstraction that
describes properties important to an application and ignores the rest. Any
choice of classes is arbitrary and depends on the application.
Each class describes a possibly infinite
set of individual objects. Each object is said to be an instance of its class. An object has its own value of each
attribute but shares the attribute names and operations with other instances of
the class.
Inheritance is a kind of attributes and operations (features) among classes based on a
hierarchical relationship. A super class
has general information that
subclasses refine and elaborate.
Each subclass incorporates, or inherits; all the features of its super class
and adds its own unique features. Subclasses need not repeat the features of
the super class. For example, scrolling Window and fixed window are subclasses
of window. Both subclasses inherit the features of window, such as visible
region on the screen. Scrolling Window adds a scroll bar and an offset. The
ability to factor out common features of several classes into a super class can
greatly reduce repetition within design and programs and is one of the main
advantages of OO technology.
(or)
Inheritance
allows the extension and reuse of existing code, without having to repeat or
rewrite the code from scratch. Inheritance involves the creation of new
classes, also called derived classes, from existing classes (base classes).
Allowing the creation of new classes enables the existence of a hierarchy of
classes that simulates the class and subclass concept of the real world. The
new derived class inherits the members of the base class and also adds its own.
For example, a banking system would expect to have customers, of which we keep
information such as name, address, etc. A subclass of customer could be
customers who are students, where not only we keep their name and address, but
we also track the educational institution they are enrolled in.
Inheritance is
mostly useful for two programming strategies: extension and specialization.
Extension uses inheritance to develop new classes from existing ones by adding
new features. Specialization makes use of inheritance to refine the behavior of
a general class.
Polymorphism means that the same operation may behave
differently for different classes. The move
operation, for example, behaves differently for a pawn than for the in a chess
game. An operation is a procedure or
transformation that an object performs or is subject to. Right Justify, display, and move
are examples of operations. An implementation of an operation by a specific
class is called a method. Because an
OO operator is polymorphic, it may have more than one method implementing it,
each for a different class of object.
(or)
Polymorphism
allows an object to be processed differently by data types and/or data classes.
More precisely, it is the ability for different objects to respond to the same
message in different ways. It allows a single name or operator to be associated
with different operations, depending on the type of data it has passed, and
gives the ability to redefine a method within a derived class.
For example, given the student and business subclasses of customer
in a banking system, a programmer would be able to defi ne different getInterestRate()
methods in student and business to override the default
interest getInterestRate() that is held in the customer class.
While Java supports method overloading, it does not support operator overloading.
Encapsulation
The process, or
mechanism, by which you combine code and the data it manipulates into a single
unit, is commonly referred to as encapsulation. Encapsulation provides a layer
of security around manipulated data, protecting it from external interference
and misuse. In Java, this is supported by classes and objects.
Data Abstraction
Real-world
objects are very complex and it is very difficult to capture the complete
details. Hence, OOP uses the concepts of abstraction and encapsulation.
Abstraction is a design technique that focuses on the essential attributes and
behavior. It is a named collection of essential attributes and behavior
relevant to programming a given entity for a specific problem domain, relative
to the perspective of the user.
Unit-I COMPLEXITY
Object
Oriented Analysis and Design
MECS-602
COMPLEXITY OF
SOFTWARE
Prior
to 1990, simple problems were solved using computers during the initial
evolution phases of computing technologies. These days, computers are utilized
in solving many mission-critical problems and they are playing a vital role in
the fields of space, defense, research, engineering, medicine, industry, business,
and even in music and painting.
Large
projects involve many highly qualified persons in the software development
process. Software industries face a lot of problems in the process of software
development. The following factors influence the complexity of software
development, as shown in Figure. 1.
1. Improper
understanding of the problem The users of a software system express their needs
to the software professionals. The requirement specification is not precisely
conveyed by the users in a form understandable by the software professionals.
This is known as impedance mismatch between the users and software
professionals.
2. Change
of rules during development During the software development process, because of
some government policy or any other industrial constraints realized, the users
may request the developer to change certain rules of the problem already
stated.
Figure 1: Factors influencing
software complexity
3. Preservation of existing so_ ware In reality,
the existing software is modified or extended to suit the current requirement.
If a system had been partially automated, the remaining automation process is
done by considering the existing one. It is expensive to preserve the existing
software because of the non availability of experts in that field all the time.
Also, it results in complexity while integrating newly developed software with
the existing one.
4. Management
of development process Since the size of the software becomes larger and larger
in the course of time it is difficult to manage, coordinate, and integrate the
modules of the software.
5. Flexibility
due to lack of standards There is no single approach to develop software for
solving a problem. Only standards can bring out uniformity. Since only a few
standards exist in the software industries, software development is a laborious
task resulting in complexity.
6. Behavior
of discrete systems the behavior of a continuous system can be predicted by
using the existing laws and theorems. For example, the landing of a satellite
can be predicted exactly using some theory even though it is a complex system.
But, computers have systems with discrete states during execution of the
software. The behavior of the software may not be predicted exactly because of
its discrete nature. Even though the software is divided into smaller parts,
the phase transition cannot be modeled to predict the output. Sometimes an
external event may corrupt the whole system. Such events make the software
extremely complex.
7. Software
testing the number of variables, control structures, and functions used in the
software are enormous. The discrete nature of the software execution modifies a
variable and it may be unnoticed. This may result in unpredictable output.
Hence, vigorous testing is essential. It is impossible to test each and every
aspect of the software in a complex software system. So only important aspects
are subjected to testing and the user must be satisfied with this. The
reliability of the software depends on rigorous testing. But testing processes
make software development more and more complex.
SOFTWARE CRISIS
The
complexity involved in the software development process led to the software crisis.
Late completion, exceeding the budget, low quality, software not satisfying
the stated demand, and lack of reliability are the symptoms of software crisis.
Software crisis has been the result of a missing methodology in software
development. The lack of structured and organized approach to software
development—not conceived as a process—led to late completion, exceeding the
budget in the case of large and complex projects. The OO paradigm arose as a
consequence of a software crisis, where the relative cost of software
has increased substantially at a rate where software maintenance and software
development cost has far outstripped that of hardware costs.
OBJECT-ORIENTED MODEL: EVOLUTION OF A NEW
PARADIGM
The complexity of
software required a change in the style of programming. It was aimed to:
1. produce
reliable software
2. reduce
production cost
3. develop
reusable software modules
4. reduce
maintenance cost
5. quicken
the completion time of software development
The Object-oriented
model was evolved for solving complex problems. It resulted in object-oriented
programming paradigms. Object-oriented software development started in the
1980s. Object-oriented programming (OOP) seems to be effective in solving the
complex problems faced by software industries.
The
end-users as well as the software professionals are benefited by OOP. OOP
provides a consistent means of communication among analysts, designers,
programmers, and end-users. Object-oriented programming paradigm suggests new
ways of thinking for finding a solution to a
Problem.
Hence, the programmers should keep their minds tuned in such a manner that they
are not to be blocked by their preconceptions experienced in other programming
languages, such as structured programming. Proficiency in object-oriented
programming requires talent, creativity, intelligence, logical thinking, and
the ability to build and use abstractions and experience.
If
procedures or functions are considered as verbs and data items are considered
as nouns, a procedure oriented program is organized around verbs, while an
object-oriented program is organized around nouns.
object-oriented
design uses a notation and process for constructing complex software systems
and offers a rich set of models with which we may reason about different
aspects of the system under consideration.
CLASSES AND OBJECTS
The
concepts of object-oriented technology must be represented in object-oriented
programming languages. Only then, complex problems can be solved in the same
manner as they are solved in real-world situations. OOP languages use classes
and objects for representing the concepts of abstraction and encapsulation. The
mapping of abstraction to a program is shown in Fig. 1.2.
Fig. 1.2 Mapping real world entity to object oriented programming
The software
structure that supports data abstraction is known as class. A
class is a data type capturing the essence of an abstraction. It is
characterized by a number of features. The class is a prototype or blue
print or model that defines different features. A feature may be a
data or an operation. Data are represented by instance variables or data
variables in a class. The operations are also known as behaviors, or
methods, or functions. They are represented by member functions of a class in
C++ and methods in Java and C#.
A
class is a data type and hence it cannot be directly manipulated. It describes
a set of objects. For example,
apple
is a fruit
implies
that apple is an example of fruit. The term “fruit” is a type of food and apple
is an instance of fruit. Likewise, a class is a type of data (data type) and
object is an instance of class.
Similarly
car represents a class (a model of vehicle) and there are a
number of instances of car. Each instance of car is an object and the class car
does not physically mean a car. An object is also known as class variable because
it is created by the class data type. Actually, each object in an
object-oriented system corresponds to a real-world thing, which may be a
person, or a product, or an entity. The differences between class and object
are given in Table 1.1.
Table 1.1 Comparisons of Class
and Object
Class
|
Object
|
Class is a data type.
|
Object is an instance of class data type.
|
It generates object.
|
It gives life to a class.
|
It is the prototype or model.
|
It is a container for storing its features
|
Does not occupy memory location.
|
It occupies memory location.
|
It cannot be manipulated because it is not available in
the memory.
|
It can be manipulated.
|
Instantiation
of an object is defined as the process of creating an object of a particular
class.
An
object has:
·
states or properties
·
operations
·
identity
Properties
maintain the internal state of an object. Operations provide the appropriate
functionality to the object. Identity differentiates one object from the other.
Object name is used to identify the object. Hence, object name itself is an
identity. Sometimes, the object name is mixed with a property to differentiate
two objects. For example, differentiation of two similar types of cars, say
MARUTI 800 may be differentiated by colors. If colors are also same, the
registration number is used. Unique identity is important and hence the
property reflecting unique identity must be used in an object.
The
properties of an object are important because the outcome of the functions
depends on these
properties.
The functions control the properties of an object. They act and react to
messages. The message may cause a change in the property of an object. Thus,
the behavior of an object depends on the properties. For example, assume a
property called brake condition for the class car. If the brake is not in
working condition, guess the behavior of car. The outcome may be unexpected. Similarly,
in a student mark statement, the result() behavior depends on the data called
marks. The property of resultStatus may be modified based on the marks.
Subscribe to:
Comments (Atom)







