India’s Mega Online Education Hub for Class 9-12 Students,

Engineers, Managers, Lawyers and Doctors.

Free Resources for Free Resources for Free Resources for Free Resources for Free Resources for
Class 9-12 Students Engineering Students MBA/BBA Students LLB/LLM Students MBBS/BDS Students

• Lecture Notes • Lecture Notes • Lecture Notes • Lecture Notes • Lecture Notes

• Project Reports • Project Reports • Project Reports • Project Reports • Project Reports

• Solved Papers • Solved Papers • Solved Papers • Solved Papers • Solved Papers

View More » View More » View More » View More » View More »

▼▼ Scroll Down to View your Downloaded File! ▼▼

Disclaimer

Please note none of the content or study material in this document or content in this file is prepared or
owned by Studynama.com. This content is shared by our student partners and we do not hold any
copyright on this content.

Please let us know if the content in this file infringes any of your copyright by writing to us at:
info@studynama.com and we will take appropriate action.
 UNIT – 1

Overview of Object Oriented concepts

Unit-01/Lecture-01

Introduction [RGPV/DEC-2008(10)]
Object-oriented programming is a method of implementation in which programs are
organized as cooperative collections of objects, each of which represents an instance of
some class, and whose classes are all members of a hierarchy of classes united via
inheritance relationships.
An object contains both data and methods that control the data. The data represents the
state of the object. A class describes an object and they also form hierarchy to model real
world system. The hierarchy is represented as inheritance and the classes can also be
associated in different manners as per the requirement.
The objects are the real world entities that exist around us and the basic concepts like

m
abstraction, encapsulation, inheritance, polymorphism all can be represented using UML.
So UML is powerful enough to represent all the concepts exists in object oriented analysis

o
and design. UML diagrams are representation of object oriented concepts only. So before

.c
learning UML, it becomes important to understand OO concepts in details.

a
Following are some fundamental concepts of object oriented world:
Objects: Objects represent an entity and the basic building block.

m
Class: Class is the blue print of an object.
Abstraction: Abstraction represents the behavior of a real world entity.

a
Encapsulation: Encapsulation is the mechanism of binding the data together and hiding

n
them from outside world.
Inheritance: Inheritance is the mechanism of making new classes from existing one.

y
Polymorphism: It defines the mechanism to exist in different forms.

d
Object-oriented analysis and design (OOAD) is a software engineering approach that models

u
a system as a group of interacting objects. Each object represents some entity of interest in

t
the system being modeled, and is characterised by its class, its state (data elements), and its
behavior. Various models can be created to show the static structure, dynamic behavior,
S
and run-time deployment of these collaborating objects. There are a number of different
notations for representing these models, such as the Unified Modeling Language (UML).
Object-oriented analysis (OOA) applies object-modelling techniques to analyze the
functional requirements for a system. Object-oriented design (OOD) elaborates the analysis
models to produce implementation specifications. OOA focuses on what the system does,
OOD on how the system does it.
Object-oriented systems
An object-oriented system is composed of objects. The behavior of the system results from
the collaboration of those objects. Collaboration between objects involves them sending
messages to each other. Sending a message differs from calling a function in that when a
target object receives a message, it itself decides what function to carry out to service that
message. The same message may be implemented by many different functions, the one
selected depending on the state of the target object.

The implementation of "message sending" varies depending on the architecture of the

system being modeled, and the location of the objects being communicated with.

Object-oriented analysis
Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a
conceptual model of the information that exists in the area being analyzed. Analysis models
do not consider any implementation constraints that might exist, such as concurrency,
distribution, persistence, or how the system is to be built. Implementation constraints are
dealt during object-oriented design (OOD). Analysis is done before the Design.

m
The sources for the analysis can be a written requirements statement, a formal vision

o
document, interviews with stakeholders or other interested parties. A system may be
divided into multiple domains, representing different business, technological, or other areas

.c
of interest, each of which are analyzed separately.
The result of object-oriented analysis is a description of what the system is functionally

a
required to do, in the form of a conceptual model. That will typically be presented as a set
of use cases, one or more UML class diagrams, and a number of interaction diagrams. It

m
may also include some kind of user interface mock-up. The purpose of object oriented

a
analysis is to develop a model that describes computer software as it works to satisfy a set
of customer defined requirements.

n
y
Object-oriented design
Object-oriented design (OOD) transforms the conceptual model produced in object-

d
oriented analysis to take account of the constraints imposed by the chosen architecture and
any non-functional – technological or environmental – constraints, such as transaction
u
throughput, response time, run-time platform, development environment, or programming
language.
t
S
The concepts in the analysis model are mapped onto implementation classes and interfaces.
The result is a model of the solution domain, a detailed description of how the system is to
be built.

What is UML?
Unified Modelling Language (UML) is the set of notations,models and diagrams used when
developing object-oriented (OO) systems.

UML is the industry standard OO visual modelling language. The latest version is UML 1.4
and was formed from the coming together of three leading software methodologists;
Booch, Jacobson and Rumbaugh.

UML allows the analyst ways of describing structure, behaviour of significant parts of system and
their relationships.
Studynama.com - #1 destination for free notes, eBooks, papers & projects.
Choose your course/study level below and start downloading:

CLASSES 6-10 CLASSES 11-12

 Class 6 CBSE NCERT Notes, Solutions
 Class 7 CBSE NCERT Notes, Solutions
 Class 8 CBSE NCERT Notes, Solutions
 Class 6, 7, 8 CBSE NCERT Projects
 Class 9 Notes, eBook CBSE PDF Download
 Class 10 Notes, eBooks CBSE
 Class 9 & 10 Projects, PPTs PDF Free
 Class 9, 10 Solved Board Papers
 Class 11 Science & Medical Notes, eBooks
 Class 12 Science & Medical Notes, eBooks
 Class 11/12 Science & Medical Projects
 Class 11/12 Science & Medical Solved Papers
 Class 11 Commerce Notes, PDF eBooks
 Class 12 Commerce Notes, PDF eBooks
 Class 11 Arts Notes, eBooks Free
 Class 12 Arts Notes, eBooks Free

ENGINEERING – BE / BTECH. STUDY MATERIAL

 First Year Engineering Notes, Projects
 Computer Sc. Engineering Notes, Projects
 Electronics Engineering Notes, Projects
 Electrical/EEE Engineering Notes, Projects
 Mechanical Engineering Notes, Projects
 Civil Engineering Notes, eBooks, Projects
 Production Engineering Notes, Projects
 Chemical Engineering Notes, Projects
 Aerospace Engineering Notes, Projects
 Metallurgical Engineering Notes, Projects
 CSE/IT Engineering Projects, Reports
 Electronics Engineering Projects, Reports
 Electrical/EE Engineering Projects, Reports
 Mechanical Engineering Projects, Reports
 Civil Engineering (CE) Projects, Reports

BBA / BBM MBA / PGDM

 BBA/BBM CORE Notes, Books, eBooks
 BBA/BBM Marketing Notes, Books, eBooks
 BBA/BBM Finance Notes, Books, eBooks
 BBA/BBM HR Notes, Books, eBooks
 BBA/BBM Operations Notes, Books, eBooks
 BBA & BBM Projects, Training Report
 MBA Core/General Notes, eBooks, Projects
 MBA Marketing Notes, eBooks, Projects
 MBA Finance Notes, eBooks, Projects, Reports
 MBA HR Notes, eBooks, Projects, Reports
 MBA Operations Notes, eBooks, Projects

SCROLL DOWN TO SEE SUBJECT NOTES

Unified Modeling Language (UML) is a standardized general-purpose modeling language in the
field of software engineering. The standard is managed, and was created by, the Object
Management Group. UML includes a set of graphic notation techniques to create visual
models of software-intensive systems.

The Unified Modeling Language is commonly used to visualize and construct systems which
are software intensive. Because software has become much more complex in recent years,
developers are finding it more challenging to build complex applications within short time
periods. Even when they do, these software applications are often filled with bugs, and it
can take programmers weeks to find and fix them. This is time that has been wasted, since
an approach could have been used which would have reduced the number of bugs before
the application was completed.

However, it should be emphasized that UML is not limited simply modeling software. It can
also be used to build models for system engineering, business processes, and organization
structures. A special language called Systems Modeling Language was designed to handle
systems which were defined within UML 2.0. The Unified Modeling Language is important
for a number of reasons. First, it has been used as a catalyst for the advancement of
technologies which are model driven, and some of these include Model Driven
Development and Model Driven Architecture.
m
o
Because an emphasis has been placed on the importance of graphics notation, UML is

.c
proficient in meeting this demand, and it can be used to represent behaviors, classes, and
aggregation. While software developers were forced to deal with more rudimentary issues

a
in the past, languages like UML have now allowed them to focus on the structure and
design of their software programs. It should also be noted that UML models can be

m
transformed into various other representations, often without a great deal of effort. One
example of this is the ability to transform UML models into Java representations.

a
This transformation can be accomplished through a transformation language that is similar
n
to QVT. Many of these languages may be supported by OMG. The Unified Modeling

y
Language has a number of features and characteristics which separate it from other
languages within the same category. Many of these attributes have allowed it to be useful
d
for developers. In this article, I intend to show you many of these attributes, and you will

u
then understand why the Unified Modeling Language is one of the most powerful

t
languages in existence today.

S
Objects and classes: [ RGPV/DEC-2010(10)]

Objects are composite data types. An object provides for the storage of multiple data
values in a single unit. Each value is assigned a name which may then be used to reference
it. Each element in an object is referred to as a property. Object properties can be
seen as an unordered list of name value pairs contained within the container object.

Object comes in two flavors. There are system defined objects, which are predefined
and come with the JavaScript parser or with the browser running the parser. And there
are user defined objects, which the programmer creates.

Class a definition, or description, of how the object is supposed to be created, what it

contains, and how it work
Studynama.com - #1 destination for free notes, eBooks, papers & projects.
Choose your course/study level below and start downloading:

LLB / LAW MEDICAL

 LLB Notes, eBooks FREE PDF Download  MBBS Notes, eBook, Project, Papers & Cases
 LLB Law First Year PDF Notes, Projects, Papers  BDS Notes, eBook, Project, Papers & Cases
 LLB Law 2nd Year PDF Notes, Projects, Papers  BHMS Notes, eBook, Project, Papers & Cases
 LLB Law 3rd Year PDF Notes, Projects, Papers  BPharma Notes, Projects, Papers & Cases

B.COM ENGINEERING / GATE ENTRANCE

 B.Com. General Notes, eBooks PDF Download
 B.Com. Honours (Hons.) Notes, eBooks
 B.Com. Finance Notes, eBooks PDF Download
 B.Com. Human Resources Notes, eBooks PDF
 B.Com. IT Notes, eBooks PDF Download
 B.Com. Accounting & Taxation Notes, eBooks
 B.Com. Marketing Notes, eBooks PDF Download
 B.Com. BFSI Notes, eBooks PDF Download
 IIT-JEE Mains 2019 Solved Papers, Notes, Cutoffs
 IITJEE Advanced 2019: Solved Papers, Notes
 BITSAT 2019 - Solved Papers, Notes, Cutoffs
 VITEEE/SRMEEE/MU-OET 2019: Papers, Notes
 UPTU/AKTU 2019 - Solved Papers, Notes, Cutoffs
 WBJEE 2019 - Solved Papers, Notes, Cutoffs
 MH-CET 2019: Solved Papers, Notes, Cutoffs
 EAMCET, COMEDK 2019: Solved Papers, Notes

BCA / MCA / B.SC. MEDICAL ENTRANCE

 BCA Notes, eBooks Download
 BCA Project Reports & PPTs
 MCA Notes, eBooks Download
 B.Sc. Notes, eBooks Download
 B.Sc.(IT) Notes, eBooks, Papers, Projects
 AIIMS Medical 2019 - Solved Papers, Notes
 NEET (AIPMT) 2019: Solved Papers, Notes
 AIPVT Medical 2019: Solved Papers, Notes
 AFMC Medical 2019: Solved Papers, Notes
 BHU-PMT, CMC Vellore 2019: Papers, Notes

GATE – ENTRANCE FOR MTECH & PSU

 GATE CSE/IT engineering Notes & Papers  GATE Electronics engineering Notes & Papers
 GATE Mechanical engineering Notes & Papers  GATE Civil Engg. Free PDF Notes & papers

SCROLL DOWN TO SEE SUBJECT NOTES

There are two important concepts to understand when talking about objects. These
are the ideas of class and instance.
Creating objects is a two step process. First you must define a class of objects, then you use
the object class by declaring instances of that class within the program. The object class is
a definition, or description, of how the object is supposed to be created, what it contains,
and how it works. The object instance is a composite data type, or object, created based
on the rules set forth in the class definition.

instance: a composite data type, or object, created based on the rules set forth in the class
definition

This break between class and instance is not new, it is just that before objects, all data
classes were hard coded into the parser and you could just make use of them while

m
creating variables that were instances of those classes. Someone, somewhere, had to write

o
the code to define the integer data type as being a numeric value with no fractional

.c
component. Whenever you declare an integer variable, you make use of this definition to
create, or instantiate, an integer. Fortunately for us, it all happens behind the scenes.

a
m
The point of object-based programming languages is that they give the user the ability to

a
define their own data types that can be specifically tailored to the needs of the application.

n
There are still system-defined data types and object classes, so you don't need to worry

y
about defining commonly used types of variables, but you now can go beyond them.

d
Since objects are composite data types, they can contain more than one piece of data. In

u
fact, the very point of the object is to bring together related data elements into a logical

t
grouping. This grouping can contain not only data values, but also rules for processing

S
those values. In an object, a data element is called a property, while the rules the object
contains for processing those values are called methods. This makes objects very powerful
because they can not only store data, but they can store the instructions on what to do
with that data.
public class Student {
}

According to the sample given below we can say that the student object, named
objectStudent, has created out of the Student class.
Student objectStudent = new Student();
Classes

m
o
.c
Terms and Concepts

A class is a description of a set of objects that share the same attributes, operations,
a
relationships, and semantics. Graphically, a class is rendered as a rectangle.

Names
m
a
A class name must be unique within its enclosing package,
n
Every class must have a name that distinguishes it from other classes. A name is a

y
textual string. That name alone is known as a simple name; a path name is the class
name prefixed by the name of the package in which that class lives. A class may be
d
drawn showing only its name,

u
t
Simple and Path Names

Note

A class name may be text consisting of any number of letters, numbers, and certain
punctuation marks (except for marks such as the colon, which is used to separate a
class name and the name of its enclosing package) and may continue over several lines.
In practice, class names are short nouns or noun phrases drawn from the vocabulary of
the system you are modeling. Typically, you capitalize the first letter of every word in a
class name, as in Customeror TemperatureSensor.

Attributes

Attributes are related to the semantics of aggregation.

An attribute is a named property of a class that describes a range of values that

instances of the property may hold. A class may have any number of attributes or no
attributes at all. An attribute represents some property of the thing you are modeling
that is shared by all objects of that class. For example, every wall has a height, width,

m
and thickness; you might model your customers in such a way that each has a name,

o
address, phone number, and date of birth. An attribute is therefore an abstraction of
the kind of data or state an object of the class might encompass. At a given moment,

.c
an object of a class will have specific values for every one of its class's attributes.
Graphically, attributes are listed in a compartment just below the class name. Attributes
may be drawn showing only their names.
a
Attributes
m
a
n
y
d
u
t
S
Note

An attribute name may be text, just like a class name. In practice, an attribute name is a
short noun or noun phrase that represents some property of its enclosing class.
Typically, you capitalize the first letter of every word in an attribute name except the
first letter, as in nameor loadBearing.
 m
o
.c
a
m
Attributes and Their Classes
a
n
y
d
u
t
S.NO RGPV QUESTIONS Year Marks
1. DESCRIBE THE MECHANISM OF ACCESING DATA Dec 2013 7
S
MEMBERS and member functions in the
following cases: a) inside the main program.
b)inside the member function of the same class.
c)inside a member function of another class.
2. What are different forms of inheritance? Give Dec 2013 7
examples of each.
3. In what order are the class constructors called Dec 2013 7
when a derived class objects are created.
4 How is polymorphism achieved at compile time Dec 2013 7
and run time.
5 What is object oriented analysis and design? Dec, 2008 10
6 What is object orientation in software Dec, 2010 10
development?
 Unit-01/Lecture-02

Operations [RGPV/JUNE-2006(10)]

An operation is the implementation of a service that can be requested from any

object of the class to affect behavior. In other words, an operation is an abstraction
of something you can do to an object and that is shared by all objects of that class.
A class may have any number of operations or no operations at all. For example, in
a windowing library such as the one found in Java's awt package, all objects of the
class Rectangle can be moved, resized, or queried for their properties. Often (but
not always), invoking an operation on an object changes the object's data or state.
Graphically, operations are listed in a compartment just below the class attributes.
Operations may be drawn showing only their names.

Operations

m
o
.c
a
m
a
n
y
Note
d
u
An operation name may be text, just like a class name. In practice, an operation
t
name is a short verb or verb phrase that represents some behavior of its enclosing

S
class. Typically, you capitalize the first letter of every word in an operation name
except the first letter, as in moveor isEmpty.

Operations and Their Signatures

Organizing Attributes and Operations

When drawing a class, you don't have to show every attribute and every operation
at once. In fact, in most cases, you can't (there are too many of them to put in one
figure) and you probably shouldn't (only a subset of these attributes and operations
are likely to be relevant to a specific view). For these reasons, you can elide a class,
meaning that you can choose to show only some or none of a class's attributes and
operations. An empty compartment doesn't necessarily mean there are no
attributes or operations, just that you didn't choose to show them. You can explicitly
specify that there are more attributes or properties than shown by ending each list
with an ellipsis ("...").

Stereotypes for Class Features

m
o
.c
a
m
a
Responsibilities n
y
d
A responsibility is a contract or an obligation of a class. When you create a class, you

u
are making a statement that all objects of that class have the same kind of state and

t
the same kind of behavior. At a more abstract level, these corresponding attributes
and operations are just the features by which the class's responsibilities are carried

S
out. A Wall class is responsible for knowing about height, width, and thickness; a
FraudAgent class, as you might find in a credit card application, is responsible for
processing orders and determining if they are legitimate, suspect, or fraudulent; a
TemperatureSensor class is responsible for measuring temperature and raising an
alarm if the temperature reaches a certain point.

When you model classes, a good starting point is to specify the responsibilities of
the things in your vocabulary. Techniques like CRC cards and use case-based analysis
are especially helpful here. A class may have any number of responsibilities,
although, in practice, every well-structured class has at least one responsibility and
at most just a handful. As you refine your models, you will translate these
responsibilities into a set of attributes and operations that best fulfill the class's
responsibilities.
 Responsibilities

m
Note

o
Responsibilities are just free-form text. In practice, a single responsibility is written as

.c
a phrase, a sentence, or (at most) a short paragraph.

S.NO
1.
RGPV QUESTIONS
Describe the method for identifying classesa Year
June, 2006
Marks
10
and objects
m
a
n
y
d
u
t
S
 Unit-01/Lecture-03

Abstraction [RGPV /DEC-2010(5)]

One job of an OO developer is to take a problem domain, and from it deduce which classes will be needed,
and what instance/variables go in each class.

• Generally easy to identify the lowest-level classes, but we often want to make use of inheritance!

Abstraction is the technique of deciding…

– What classes do we need?
– How do we organize our class hierarchy?

– Which variables/methods do we put in the superclasses, and which do we put in the subclasses?

m
Basic approach to abstraction

o
Take a collection of proposed classes
.c
a
m
a
Identify common attributes (instance variables) and behaviors (methods).

n
y
Remove the common attributes and behaviors, and put them in a new class

d
u
t New class is a base class which contains the common elements;

S derived classes contain what's left.

Generalization

generalization is a relationship between a general thing (called the superclass or parent)and

a more specific kind of that thing (called the subclass or child). Generalization is sometimes
called an "is-a-kind-of" relationship: one thing (like the class BayWindow) is-a-kind-of a more
general thing (for example, the class Window). Generalization means that objects of the child
may be used anywhere the parent may appear, but not the reverse. In other words,
generalization means that the child is substitutable for the parent. A child inherits the
properties of its parents, especially their attributes and operations. Often• but not always•
the child has attributes and operations in addition to those found in its parents. An operation
of a child that has the same signature as an operation in a parent overrides the operation of
the parent; this is known as polymorphism. Graphically, generalization is rendered as a solid
directed line with a large open arrowhead, pointing to the parent. Use generalizations when
you want to show parent/child relationships.
Generalization

m
o
.c
a
m
a
A class may have zero, one, or more parents. A class that has no parents and one or more

n
children is called a root class or a base class. A class that has no children is called a leaf class.

y
A class that has exactly one parent is said to use single inheritance; a class with more than
one parent is said to use multiple inheritance.

d
u
Most often, you will use generalizations among classes and interfaces to show inheritance
relationships. In the UML, you can also create generalizations among other things• most

t
notably, packages.

Note
S
A generalization can have a name, although names are rarely needed unless you have a model
with many generalizations and you need to refer to or discriminate among generalizations.

S.NO RGPV QUESTIONS Year Marks

1 What is data abstraction? How can we implement it in Dec,2010 5
object oriented languages
 Unit-01/Lecture-04

Inheritance [RGPV /DEC-2008(5)]

Inheritance is the property of object-oriented systems that allows objects to be

built from other objects. Inheritance allows explicitly taking advantage of the
commonality of objects when constructing new classes. Inheritance is a relationship
between classes where one class is the parent class of another (derived) class. The parent
class also is known as the base class or super class. Inheritance provides programming by
extension as opposed to programming by reinvention The real advantage of using this
technique is that we can build on what we already have and, more important, reuse what
we already have. Inheritance allows classes to share and reuse behaviors and attributes.
Where the behavior of a class instance is defined in that class's methods, a class also
inherits the behaviors and attributes of all of its super classes.
For example, the Car class defines the general behavior of cars. The Ford class
inherits the general behavior from the Car class and adds behavior specific to Fords. It is not
m
necessary to redefine the behavior of the car class; this is inherited. Another level down,

o
the Mustang class inherits the behavior of cars from the Car class and the even more
specific behavior of Fords from the Ford class. The Mustang class then adds behavior

.c
unique to Mustangs. Assume that all Fords use the same braking system. In that case, the
stop method would be defined in class Ford (and not in Mustang class), since it is a behavior

a
shared by all objects of class Ford. When you step on the brake pedal of a Mustang, you
send a stop message to the Mustang object. However, the stop method is not defined in

m
the Mustang class, so the hierarchy is searched until a stop method is found. The stop

a
method is found in the Ford class, a super class of the Mustang class, and it is invoked. In a
similar way, the Mustang class can inherit behaviors from the Car and the Vehicle classes.

n
y
d
u
t
S

INHERITANCE ALLOWS REUSABLITY

Inheritance for Specialization

One common reason to use inheritance is to create specializations of existing classes. In

specialization, the derived class has data or behavior aspects that are not part of the base
class. For example, Square is a Rectangle. Square class is specialization of Rectangle class.
Similarly, Circle is an Ellipse. Here also, Circle class is specialization of Ellipse class.
Another example, a BankAccount class might have data members such as
accountNumber, customerName and balance. An InterestBearingAccount class might
inherit
BankAccount and then add data member interestRate and interestAccrued along with
behavior for calculating interest earned.
Another form of specialization occurs when a base class specifies that it has a particular
behavior but does not actually implement the behavior. Each non- abstract, concrete class
which inherits from that abstract class must provide an implementation of that behavior.
This providing of actual behavior by a subclass is sometimes known as implementation or
reification.
For example, there is a class Shape having operation area(). The operation area() cannot be

m
implemented unless we have concrete class. So, Shape class is abstract class. Rectangle is
a Shape. Now, Rectangle is a concrete class, which can implement the operation area().

o
Inheritance for Generalization
.c
Vehicle a
m
a
n
y BUS

d
CAR
Truck

u
t
S
Generalization is reverse of specialization. For instance, a "fruit" is a generalization
of "apple", "orange", "mango" and many others. One can consider fruit to be an
abstraction of apple, orange, etc. Conversely, since apples are fruit (i.e., an apple is-a fruit),
apples may naturally inherit all the properties common to all fruit, such as being a fleshy
container for the seed of a plant. Another example: Vehicle is a generalization of Car, Truck, Bus
etc. as shown in Figure 2.18. Car, Truck, Bus etc. share some properties such as u ber of
wheels , speed, capacity etc. these common properties are abstracted out and put into
another class say Vehicle, which comes higher in the hierarchy.

2.2.6.3 Inheritance for Extension

In this case, inheritance extends the existing class functionalities by adding new operations
in the derived class. It can be distinguished from generalization that the later must
override at least one method from the base and the functionality is tied to that of the base
class. Extension simply adds new methods to those of the base class and functionality is less
strongly tied to the existing methods of the base class.
For example, StringSet class inherits from Set class, which specializes for holding
strinvalues. Such a class might provide additional methods for string related operations – for
instance - search by prefix, which returns a subset of all the elements of the set that
begin with a certain string value. These operations are meaningful to the derived class but
are not particularly relevant to the base class.

S.NO RGPV QUESTIONS Year Marks

1. What does inheritance means in object oriented Dec,2008 5
programming?

m
o
.c
a
m
a
n
y
d
u
t
S
 Unit-01/Lecture-05

Inheritance for Restriction [RGPV /DEC-2009(10)]

In this case, the derived class does not implement the functionality, which a base class has.
In other words, inheritance for restriction occurs when the behaviour of the derived class
is smaller or more restrictive than the behaviour of the base class.
For example, an existing class library provides a double-ended queue (deque).
Elements can be added or removed from either end of the deque, but the programmer
wishes to write a stack class, enforcing the property that elements can be added or removed
from only one end of the stack. Here, the programmer can make the Stack class a derived
class of the existing Deque class and can modify or override the undesired methods so that
they produce an error message if used.

2.2.6.5 Inheritance for Overriding

When a class replaces the implementation of a method that it has inherited is called
m
overriding. Overriding introduces a complication: which version of the method does an

o
instance of the inherited class use the one that is part of its own class, or the one from

.c
the parent (base) class. The answer varies between programming languages, and some
languages provide the ability to indicate that a particular behaviour is not to be overridden.

2.2.6.6. Constraints of inheritance-based design

a
m
When using inheritance extensively in designing a program, one should be aware of

a
c e r t a i n constraints that it imposes. For example, consider a class Person that contains a
person's name, address, phone number, age, gender, and race. We can define a subclass of

n
Person called Student that contains the person's grade point average and classes taken, and

y
another subclass of Person called Employee that contains the person's job title, employer,
and salary.

d
In defining this inheritance hierarchy we have already defined certain restrictions, not all of

u
which are desirable:

t
• Singleness: Using single inheritance, a subclass can inherit from only one super class.

S
Continuing the example given above, Person can be either a Student or an Employee,
but not both. Using multiple inheritance partially solves this problem, as a Student
Employee class can be defined that inherits from both Student and Employee.
However, it can still inherit from each super class only once; this scheme does not support
cases in which a student has two jobs or attends two institutions.
• Static: the inheritance hierarchy of an object is fixed at instantiation when the object's
type is selected and does not change with time. For example, the inheritance graph
does not allow a Student object to become a Employee object while retaining
the state of its Person super class.

(Although similar behaviour can be achieved with the decorator pattern.)

 Some have criticized inheritance, contending that it locks developers into
their original design standards.
• Visibility: whenever client code has access to an object, it generally has access to all
the object's superclass data. Even if the superclass has not been declared public, the
client can still cast the object to its superclass type. For example, there is no way to
give a function a pointer to a Student's grade point average and transcript
without also giving that function access to all of the personal data stored in the
student's Person superclass.

2.2.6.7 Roles and inheritance:

One consequence of separation of roles and super classes is that compile- time and run-
time aspects of the object system are cleanly separated. Inheritance is then clearly
a compile-time construct. Inheritance does influence the structure of many objects at
run-time, but the different kinds of structure that can be used are already fixed at compile-
time.
m
o
To model the example of Person as an employee with this method, the modelling

.c
ensures that a Person class can only contain operations or data that are common to every
Person instance regardless of where they are used. This would prevent use of a Job
member in a Person class, because every person does not have a job, or at least it is not

a
known that the Person class is only used to model Person instances that have a job. Instead,
object-oriented design would consider some subset of all person objects to be in

m
an "employee" role. The job information would be associated only to objects that have the

a
employee role. Object-oriented design would also model the "job" as a role, since a job can
be restricted in time, and therefore is not a stable basis for modelling a class. The

n
corresponding stable concept is either "Workplace" or just "Work" depending on which

y
concept is meant. Thus, from object- oriented design point of view, there would be
a "Person" class and a "Workplace" class, which are related by a many-to-many

d
association "works- in", such that an instance of a Person is in employee role, when he works-

u
in a job, where a job is a role of his work place in the situation when the employee works in it.

t
Note that in this approach, all classes that are produced by this design process are

S
part of the same domain, that is, they describe things clearly using just one terminology.
This is often not true for other approaches.

The difference between roles and classes is especially difficult to understand if referential
transparency is assumed, because roles are types of references and classes are types of the
referred-to objects.

In this example, a Student is a type of Person. Likewise, a Employee is a type of Person. Both
Student and Employee inherit all the attributes and methods of Person. Student has a locally
defined student ID attribute. Employee has a locally defined employee ID attribute.

So, if you would look at a Student object, you would see attributes of name, date of birth,
parents, children, and student ID.
Studynama’s BDS Community is one of India’s Largest Community of Dental Students. About
19,232 Indian Dental Course students are members of this community and share FREE study
material, cases, projects, exam papers etc. to enable each other to do well in their semester exams.

Links to Popular Study Material for BDS (Dental) students:

 Orthodontic Fixed Appliances - BDS Lecture Notes PDF Download
 Amalgam Restoration - BDS Lecture Notes PDF Download
 COMPLEX NON-SKELETAL PROBLEMS IN PREADOLESCENT CHILDREN - BDS Lecture Notes
 Anatomy of Scalp - BDS Lecture Notes PDF Download
 Cerebrospinal Fluid (CSF) - BDS Lecture Notes PDF Download
 Cementum - BDS Lecture Notes PDF Download
 Recent Advances in Instrumentation Techniques - BDS Lecture Notes PDF Download
 Ameloblastoma - BDS Lecture Notes PDF Download
 Prevention of Odontogenic Infection - Principles of Management - BDS Lecture Notes
 Therapeutic Dentistry Histology of Teeth Dental Charting - BDS Lecture Notes PDF Download
 Maxillofacial Trauma and Management - BDS Lecture Notes PDF
 Technical Endodontics - BDS Lecture Notes PDF Download
And 698 more free downloads for Dental Students.
Other Popular Links for Law Study Material:
 BDS Lecture Notes, eBooks, Guides, Projects and Case Papers FREE PDF Download
 BDS Lecture Notes, eBooks, Guides & Handouts FREE PDF Download
 BDS University Previous Year Exam Question Papers & Solutions FREE PDF Download
 m
o
.c
a
m
a
n
y
d
u
t
S.NO
1.
S RGPV QUESTIONS
What are the advantages of code reusability? What is
Year
Dec,2009 10
Marks

containership? How does it differ from inheritance

 UNIT 1/LECTURE 6

Types of Inheritance [RGPV /DEC-2008(8),DEC-2010(8)]

There are many ways a derived class inherits properties from the base class.
Following are the types of inheritance:

• Single Inheritance
• Multiple Inheritance
• Multilevel Inheritance
• Hierarchical Inheritance
• Multipath Inheritance
• Hybrid Inheritance
m
o
.c
Single Inheritance

Person
a
m
name address

a ………..

n
y getName()
getAddress() ….....
d
u
t
S Student

rollNo course
………..

getRollNo()
getCourse() ….....

When a (derived) class inherits properties (data and operations) from a single base class, it
is called as single inheritance. For example, Student class inherits properties from Person
class.
Studynama’s Engineering Community is one of India’s Largest Community of BE & BTECH Students. About 79,182
Indian Engineering students are members of this community and share FREE study material, notes, eBooks, major
and minor projects, exam papers etc. to enable each other to do well in their semester exams.

Links to Popular Study Material for Engineering (BE/BTech) students:

CSE & IT Engineering Electronics Engineering Electrical Engineering Mechanical Engineering Civil Engineering

Computer Science Electronics Engineering BTech Civil/Structural

Electrical/EE Engineering Mechanical/Automobile/IP
(CSE/IT Engineering) (ECE/ET/EC) Engineering Second
Second/2nd Year Notes Engineering second year notes
Second/2nd Year Notes Second/2nd Year Notes Year Lecture Notes

CSE/IT Computer Electronics Engineering BTech Civil/Structural

Electrical/EE Engineering Mechanical/Automobile/IP
Science Engg. Final/4th (ECE/EC/ET) Third/3rd Engineering Fourth
Third/3rd Year notes Engineering fourth year notes
Year Notes Year Notes Year Lecture Notes

Computer Science Electronics (ECE/ET/EC) BTech Civil/Structural

Electrical/EE Engineering Mechanical/Automobile/IP
Engineering (CSE/IT) Engineering Final/Fourth Engineering Third Year
Fourth/4th Year Notes Engineering third year notes
Third/3rd Year Notes Year Notes Lecture Notes

Advanced Java Antenna & wave Electrical Machine-1 pdf Automobile engineering lecture
Surveying 1 - eBook
Programming eBook propagation eBook download notes

Web Technology - Network analysis & Electrical machines-II Engineering materials & SOM - strength of
eBook synthesis notes eBook metallurgy lecture notes materials - eBook

E-Commerce lecture VLSI engineering pdf Manufacturing Technology-1 Engineering Geology

EMI eBook
notes lecture notes lecture notes eBook

And 12998 more free downloads for BE & BTech Students.

Other Popular Links for Engineering Study Material:

• Engineering First Semester (Sem 1) Notes
• Engineering Second Semester (Sem 2) Notes
• Engineering chemistry pdf eBook
• Engineering Mechanics PDF Lecture Notes
• Electrical/EE Engineering notes
• Mechanical/Automobile/IP Engineering notes
• Powerplant Engineering Lecture Notes
• Engineering Mechanics lecture notes
 Multiple Inheritance
When a (derived) class inherits properties (data and operations) from more than one base
class, it is called as multiple inheritance. For example, BoatHouse class inherit
properties from both Boat class and House class.

BOAT HOUSE

BOATHOUSE m
o
.c
Multilevel Inheritance a
m
When a (derived) class inherits properties (data and operations) from another derived class, it

a
is called as multilevel inheritance. For example, Rectangle class inherits properties from
Shape class and Square inherits properties from Rectangle class.

n
y
SHAPE

d
u
t
S
RECTANGLE

SQUARE

Hierarchical Inheritance
When more than one (derived) class inherits properties (data and operations) from a single
base class, it is called as hierarchical inheritance. For example, Chair class, Table class and
Bed class all inherit properties from Furniture class.

FURNITURE

CHAIR TABLE BED

m
Multipath Inheritance o
.c
When more than one inheritance paths are available between two classes in the inheritance

a
hierarchy, it is called as multipath inheritance. For example, Carnivorous and Herbivorous
class inherit properties from Animal class. Omnivorous class inherits properties from

m
Carnivorous and Herbivorous classes. So, there are two alternative paths available from

a
Animal class to Omnivorous class.

nAnimal
y
d
u
t
S
Carnivorous Herbivorous

Omnivorous
Studynama’s Law Community is one of India’s Largest Community of Law Students. About
29,982 Indian Law students are members of this community and share FREE study material,
cases, projects, exam papers etc. to enable each other to do well in their semester exams.

Links to Popular Study Material for LAW (LLB & BA.LLB) students:
• Family law pdf lecture notes & eBook download for LLB students
• Jurisprudence Law lecture notes pdf & eBook download for LLB students
• Company Law lecture notes pdf & eBook download for LLB students
• Law of Evidence lecture notes pdf & eBook download for LLB students
• Contract Law lecture notes pdf & eBook download for LLB students
• Criminal law pdf lecture notes & eBook download for LLB students
• Taxation Law lecture notes pdf & eBook download for LLB students
• Law of torts pdf eBook & lecture notes for LLB students
• Constitutional law pdf lecture notes & eBook download
• Labour law lecture notes pdf & eBook download for LLB students
• Administrative law lecture notes pdf & eBook download for LLB students
• Constitutional Law - I q&a notes pdf & eBook download for LLB
And 1998 more free downloads for Law & LLB Students.

Other Popular Links for Law Study Material:

• LLB/LLM Lecture Notes, eBooks, Guides, Handouts FREE PDF Download
• LLB - Law third year notes, eBooks, handouts and study material - semester 5 & 6
• LLB - Law second year notes, eBooks, handouts and study material - semester 3 & 4
• LLB - Law first year notes, eBooks, handouts and study material - semester 1 & 2
 C Ook
OAK

C++ Java

m
o
C#

.c
Hybrid Inheritance
a
m
Mixture of single, multiple, hierarchical and multilevel inheritance forms hybrid inheritance

a
n
y
d
u
t
S
 S.NO RGPV QUESTION YEAR MARKS
1. What are the different forms of Dec 8
inheritance ? give an example for each 2010,Dec,2008
2 Dicuss in brief multiple inheritance Dec,2008 4
and disinheritance

UNIT 1/LECTURE 7

DYNAMIC INHERITANCE

Dynamic inheritance allows objects to change and evolve over time. Since base classes
provide properties and attributes for objects, changing base classes changes the properties
and attributes of a class. A previous example was a Windows object changing into an icon
and then back again, which involves changing a base class between a Windows class
and an Icon class. More specifically, dynamic inheritance refers to the ability to add, delete,
or change parents from objects (or classes) at run time.
In object-oriented programming languages, variables can be declared to hold or reference

m
objects of a particular class. For example, a variable declared to reference a motor vehicle is
capable of referencing a car or a truck or any subclass of motor vehicle.

o
.c
MULTIPLE INHERITANCE

a
Some object-oriented systems permit a class to inherit its state (attributes) and
behaviors from more than one super class. This kind of inheritance is referred to as

m
multiple inheritance. For example, a utility vehicle inherits attributes from both the Car and

a
Truck classes.
Multiple inheritance can pose some difficulties. For example, several distinct

n
parent classes can declare a member within a multiple inheritance hierarchy. This then can

y
become an issue of choice, particularly when several super classes define the same
method. It also is more difficult to understand programs written in multiple inheritance
systems.
d
u
One way of achieving the benefits of multiple inheritance in a language with
single inheritance is to inherit from the most appropriate class and then add an object of

t
another class as an attribute.

S
Encapsulation [RGPV /DEC-2010(5)]

Encapsulation is one of the loosely defined OOAD concepts. The term is known in software
development for many years but I can't find any reliable origin. Encapsulation was mentioned
in the article describing abstraction mechanisms in programming language CLU in the context
of hiding details of implementation.

CLU restricted access to the implementation by allowing using only (public) cluster operations,
i.e. public interface. It promoted design practices where abstractions are used to define and
simplify the connections between system modules and to encapsulate implementation
decisions that are likely to change.
If we look up the English word encapsulate in a dictionary, we will find two meanings: (1) to
encase or become enclosed in a capsule (2) to express in a brief summary, epitomise. Both of
these meanings of encapsulation seem appropriate in the context of OOAD.

Let's assume that the definition of encapsulation in OOAD is something like:

Encapsulation is a development technique which includes

 creating new data types (classes) by combining both information (structure) and
behaviors, and
 restricting access to implementation details.

Encapsulation is very close or similar to the abstraction concept. The difference is probably in
"direction" - encapsulation is more about hiding (encapsulating) implementation details while
abstraction is about finding and exposing public interfaces. The two concepts are supported by
access control.

m
Access control allows both to hide implementation (implementation hiding or information
hiding) and to expose public interface of a class.
o
Encapsulation in UML
.c
a
UML specifications provide no definition of encapsulation but use it loosely in several

m
contexts.

a
For example, in UML 1.4 object is defined as an entity with a well defined boundary and
identity that encapsulates state (attributes and relationships) and behavior (operations,
n
methods, and state machines). Elements in peer packages are encapsulated and are not a
priori visible to each other.
y
d
In UML 2.4 and 2.5 a component represents a modular part of a system that encapsulates its

u
contents and whose manifestation is replaceable within its environment, and also a

t
Component is encapsulated and ... as a result, Components and subsystems can be flexibly
reused and replaced by connecting ("wiring") them together.

S
Encapsulated classifier in UML 2.4 and 2.5 is a structured classifier isolated from its
environment (encapsulated ?) by using ports. Each port specifies a distinct interaction point
between classifier and its environment.
Studynama’s MBA Community is one of India’s Largest Community of MBA & PGDM Students. About 29,882 Indian
Management students are members of this community and share FREE study material, notes, eBooks, projects, case
studies exam papers etc. to enable each other to do well in their semester exams.

Links to Popular Study Material for Management (MBA/PGDM) students:

MBA General MBA Marketing MBA Finance MBA HR MBA Operations

MBA/PGDM first Enterprise resource Security analysis & Business environment MBA Operations
year notes planning (ERP) pdf portfolio Mgmt. Notes Notes

MBA/PGDM second Marketing International Fin. Human resource MIS pdf

year notes management pdf management eBook management pdf

Principles of International Advanced financial Compensation Industrial safety

management pdf marketing eBook management eBook management Notes eBook

Managerial Retail marketing Corporate taxation International human Import export

economics eBook eBook pdf eBook resource management pdf mgmt. lecture notes

Organizational Sales management Financial Human resource TQM eBook

behavior pdf eBook management eBook development eBook

Operation research Brand management Management Organization & Management

lecture notes pdf accounting notes management process pdf control systems

And 12,998 more free downloads for MBA & PGDM Students.

Other Popular Links for MBA Study Material:

• MBA/PGDM Core (General) Notes, eBooks, Projects, Cases & Reports FREE PDF Download
• MBA/PGDM Marketing Notes, eBooks, Projects, Cases & Reports FREE PDF Download
• MBA/PGDM Finance Notes, eBooks, Projects, Cases & Reports FREE PDF Download
• MBA/PGDM HR Notes, eBooks, Projects, Cases & Reports FREE PDF Download
• MBA/PGDM Operations Notes, eBooks, Projects, Cases & Reports FREE PDF Download
Library Services is classifier encapsulated through Search Port

UML 2.4 specification also used term completely encapsulated without providing any
explanation. It was removed in UML 2.5.

Aggregation [RGPV /JUNE-2008(10)]

A plain association between two classes represents a structural relationship between

peers, meaning that both classes are conceptually at the same level, no one more
important than the other. Sometimes, you will want to model a "whole/part" relationship,
in which one class represents a larger thing (the "whole"), which consists of smaller things
(the "parts"). This kind of relationship is called aggregation, which represents a "has-a"
relationship, meaning that an object of the whole has objects of the part. Aggregation is
really just a special kind of association and is specified by adorning a plain association with
an open diamond at the whole end.

m
o
.c
a
m
a
n
y
d
u
t
Note
The meaning of this simple form of aggregation is entirely conceptual. The open diamond

S
distinguishes the "whole" from the "part," no more, no less. This means that simple
aggregation does not change the meaning of navigation across the association between the
whole and its parts, nor does it link the lifetimes of the whole and its parts.

S.NO RGPV QUESTION YEAR MARKS

1. What is data encapsulation? How can Dec,2010 5
we implement in any object oriented
language
2. Discuss among June 2008 10
association,aggregation, inheritance
and relationship among
classes,quoting suitable examples
 UNIT 1/LECTURE 8
AGGREGATIONS AND OB.JECT CONTAINMENT

All objects, except the most basic ones, are composed of and may contain other
objects. For example, a spreadsheet is an object composed of cells, and cells are objects
that may contain text, mathematical formulas, video, and so forth. Breaking down objects
into the objects from which they are composed is decomposition. This is possible because an
object's attributes need not be simple data fields; attributes
can reference other objects. Since each object has an identity, one object can refer to
other objects. This is known as aggregation, where an attribute can be an object itself. For
instance, a car object is an aggregation of engine, seat, wheels, and other objects (see
Figure2.9).
A Car object is an aggregation of other objects such as engine, seat, and wheel objects.

Abstraction classes:
m
o
Classes with no instances are called abstract classes. An abstract class is written with
the expectation that its subclasses will add to its structure and behavior, usually by

.c
completing the implementation of its (typically) incomplete methods. In fact, in
Smalltalk a developer may force a subclass to redefine the method introduced in

a
an abstract class by using the method subclassResponsibility to implement a body for
the abstract class's method. If the subclass fails to redefine it, then invoking the

m
method results in an execution error. C++ similarly allows the developer to assert

a
that an abstract class's method cannot be involced direaly by initializing its
declaration to zero. Such a method is called a pure virtual function, and the language

n
prohibits the creation of instances whose class exports such functions.

y
Standard protocols are often represented by abstract classes.

d
u
An abstract class never has instances, only its subclasses have instances. The roots of class
hierarchies are usually abstract classes while the leaf classes are never abstract. Abstract

t
classes usually do not define any instance variables. However, they define methods in terms of

S
a few undefined methods that must be implemented by the subclasses. For example, class
Collection is abstract, and defines a number of methods, including select:,collect:, and
inject:into:, in terms of an iteration method, do:. Subclasses of Collection, such as Array,
Set, and Dictionary, define do: and are then able to use the methods that they inherited
from Collection. Thus, abstract classes can be used much like program skeletons, where the
user fills in certain options and reuses the code in the skeleton.

A class that is not abstract is concrete. In general, it is better to inherit from an abstract
class than from a concrete class. A concrete class must provide a definition for its data
representation, and some subclasses will need a different representation. Since an abstract
class does not have to provide a data representation, future subclasses can use any
representation without fear of conflicting with the one that they inherited.

Creating new abstract classes is very important, but is not easy. It is always easier to reuse a
nicely packaged abstraction than to invent it. However, the process of programming in
Smalltalk makes it easier to discover the important abstractions. A Smalltalk programmer
always tries to create new classes by making them be subclasses of existing ones, since
this is less work than creating a class from scratch. This often results in a class hierarchy
whose top-most class is concrete. The top of a large class hierarchy should almost always be an
abstract class, so the experienced programmer will then try to reorganize the class
hierarchy and find the abstract class hidden in the concrete class. The result will be a new
abstract class that can be reused many times in the future.

An example of a Smalltalk class that needs to be reorganized is View, which defines a user-
interface object that controls a region of the screen. View has 27 subclasses in the standard
image, but is concrete. A careful examination reveals a number of assumptions made in
View that most of its subclasses do not use. The most important is that each view will have
subviews. In fact, most subclasses of View implement views that can never have subviews.
Quite a bit of code in View deals with adding and positioning subviews, making it very
difficult for the beginning programmer to understand the key abstractions that View
represents. The solution is simple: split View into two classes, one (View) of which is the
abstract superclass and the other (ViewWithSubviews) of which is a concrete subclass that
implements the ability to have subviews. The result is much easier to understand and to reuse.

Inheritance vs. decomposition

m
o
Since inheritance is so powerful, it is often overused. Frequently a class is made a subclass

.c
of another when it should have had an instance variable of that class as a component.
For example, some object-oriented user-interface systems make windows be a subclass of

a
Rectangle, since they are rectangular in shape. However, it makes more sense to make the
rectangle be an instance variable of the window. Windows are not necessarily rectangular,

m
rectangles are better thought of as geometric values whose state cannot be changed, and
operations like moving make more sense on a window than on a rectangle.

a
n
Behavior can be easier to reuse as a component than by inheriting it. There are at
least two good examples of this in Smalltalk-80. The first is that a parser inherits the

y
behavior of the lexical analyzer instead of having it as a component. This caused problems

d
when we wanted to place a filter between the lexical analyzer and the parser without
changing the standard compiler. The second example is that scrolling is an inherited

u
characteristic, so it is difficult to convert a class with vertical scrolling into one with no

t
scrolling or with both horizontal and vertical scrolling. While multiple inheritance
might solve this problem, it has problems of its own. Moreover, this problem is easy to
S
solve by making scrollbars be components of objects that need to be scrolled.

Most object-oriented applications have many kinds of hierarchies. In addition to class

inheritance hierarchies, they usually have instance hierarchies made up of regular objects.
For example, a user-interface in Smalltalk consists of a tree of views, with each subview being
a child of its superview. Each component is an instance of a subclass of View, but the root of
the tree of views is an instance of StandardSystemView. As another example, the Smalltalk
compiler produces parse trees that are hierarchies of parse nodes. Although each node is
an instance of a subclass of ParseNode, the root of the parse tree is an instance of
MethodNode, which is a particular subclass. Thus, while View and ParseNode are the
abstract classes at the top of the class hierarchy, the objects at the top of the instance
hierarchy are instances of StandardSystemView and MethodNode.

This distinction seems to confuse many new Smalltalk programmers. There is

often a phase when a student tries to make the class of the node at the top of the instance
hierarchy be at the top of the class hierarchy. Once the disease is diagnosed, it can be easily
cured by explaining the differences between the instance and class hierarchies.

Polymorphism [RGPV /DEC-2013(10),DEC-2010(10)]

Poly means "many" and morph means "form." In the context of object-oriented systems, it
means objects that can take on or assume many different forms. Polymorphism
means that the same operation may behave differently on different classes. Booch defines
polymorphism as the relationship of objects of many different classes by some common
super class; thus, any of the objects designated by this name is able to respond to some
common set of operations in a different way. For example, consider how driving an automobile
with a manual transmission is different from driving a car with an automatic transmission.
The manual transmission requires you to operate the clutch and the shift, so in addition to
all other mechanical controls, you also need information on when to shift gears. Therefore,
although driving is a behavior we perform with all cars (and all motor vehicles), the specific
behavior can be different, and depending on the kind of car we are driving. A car with an

m
automatic transmission might implement its drive method to use information such as current

o
speed, engine RPM, and current gear.

.c
Polymorphism allows us to write generic, reusable code more easily, because we can specify
general instructions and delegate the implementation details to the objects involved. Since no

a
assumption is made about the class of an object that receives a message, fewer dependencies
are needed in the code and, therefore, maintenance is easier. For example, in a payroll system,

m
manager, office worker, and production worker objects all will respond to the compute payroll
message, but the actual operations performed by are object specific.
a
n
Operations are performed on objects by ``sending them a message'' (The object-
oriented programming community does not have a standardized vocabulary. While
y
``sending a message'' is the most common term, and is used in the Smalltalk and Lisp

d
communities, C++ programmers refer to this as ``calling a virtual function''.) Messages in a
language like Smalltalk should not be confused with those in distributed operating systems.
u
Smalltalk messages are just late-bound procedure calls. A message send is implemented

t
by finding the correct method (procedure) in the class of the receiver (the object to which

S
the message is sent), and invoking that method. Thus, the expression a + b will invoke different
methods depending upon the class of the object in variable a.

Message sending causes polymorphism. For example, a method that sums the elements in
an array will work correctly whenever all the elements of the array understand the addition
message, no matter what classes they are in. In fact, if array elements are accessed by
sending messages to the array, the procedure will work whenever it is given an argument
that understands the array accessing messages.

Polymorphism is more powerful than the use of generic procedures and packages
n Ada. A generic can be instantiated by macro substitution, and the resulting procedure
or package is not at all polymorphic. On the other hand, a Smalltalk object can access an
array in which each element is of a different class. As long as all the elements understand the
same set of messages, the object can interact with the elements of the array without
regard to their class. This is particularly useful in windowing systems, where the array
could hold a list of windows to be displayed. This could be simulated in Ada using variant
records and explicitly checking the tag of each window before displaying it, thus ensuring that
the correct display procedure was called. However, this kind of programming is dangerous,
because it is easy to forget a case. It leads to software that is hard to reuse, since minor
modifications are likely to add more cases. Since the tag checks will be widely
distributed through the program, adding a case will require wide-spread modifications before
the program can be reused

S.NO RGPV QUESTION YEAR MARKS

1. How is polymorphism achieved Dec,2013 10
at compile time and run time
2. What is polymorphism and Dec,2010 10
what are various types of it?

m
o
.c
a
m
a
n
y
d
u
t
S UNIT 1/LECTURE 9

link and association [RGPV /DEC-2009(10),DEC-2008(8)]

Association
Associations and dependencies (but not generalization relationships) may be reflective
An association is a structural relationship that specifies that objects of one thing are
connected to objects of another. Given an association connecting two classes, you can
navigate from an object of one class to an object of the other class, and vice versa. It's quite
legal to have both ends of an association circle back to the same class. This means that,
given an object of the class, you can link to other objects of the same class. An association
that connects exactly two classes is called a binary association. Although it's not as
common, you can have associations that connect more than two classes; these are called n-
ary associations. Graphically, an association is rendered as a solid line connecting the same
or different classes. Use associations when you want to show structural relationships.
Beyond this basic form, there are four adornments that apply to associations.

Name

An association can have a name, and you use that name to describe the nature of the
relationship. So that there is no ambiguity about its meaning, you can give a direction to
the name by providing a direction triangle that points in the direction you intend to read
the name,
Association Names

m
o
.c
a
Note
m
a
Although an association may have a name, you typically don't need to include one if you

n
explicitly provide role names for the association, or if you have a model with many
associations and you need to refer to or distinguish among associations. This is especially
y
true when you have more than one association connecting the same classes.

d
Roles are related to the semantics of interfaces Role

u
When a class participates in an association, it has a specific role that it plays in that

t
relationship; a role is just the face the class at the near end of the association presents to

S
the class at the other end of the association. You can explicitly name the role a class plays
in an association. a Personplaying the role of employeeis associated with a Companyplaying
the role of employer.

Roles
Note

The same class can play the same or different roles in other associations.
An instance of an association is called a link

Multiplicity

An association represents a structural relationship among objects. In many modeling

situations, it's important for you to state how many objects may be connected across an
instance of an association. This "how many" is called the multiplicity of an association's
role, and is written as an expression that evaluates to a range of values or an explicit value.
When you state a multiplicity at one end of an association, you are specifying that, for
each object of the class at the opposite end, there must be that many objects at the near
end. You can show a multiplicity of exactly one (1), zero or one (0..1), many (0..*), or one
or more (1..*). You can even state an exact number (for example, 3).

Multiplicity
m
o
Note
.c
a
You can specify more complex multiplicities by using a list, such as 0..1, 3..4, 6..*, which
would mean "any number of objects other than 2or 5."
m
ASSOCIATIONS
a
n
Association represents the relationships between objects and classes. For example, in

y
the statement "a pilot can fly planes" (Figure 2.7) the italicized term is an association.
Associations are bidirectional; that means they can be traversed in both directions,

d
perhaps with different connotations. The direction implied by the name is the forward

u
direction; the opposite direction is the inverse direction. For example, can fly connects a
pilot to certain airplanes. The inverse of can fly could be called is flown by.
t
S
An important issue in association is cardinality, which specifies how many
instances of one class may relate to a single instance of an associated class. Cardinality
constrains the number of related objects and often is described as being "one" or "many,"
Generally, the multiplicity value is a single interval, but it may be a set of disconnected
intervals. For example, the number of cylinders in an engine is four, six, or eight.
Consider a client-account relationship where one client can have one or more accounts
and vice versa (in case of joint accounts); here the cardinality of the client-account
association is many to many.

Consumer-Producer Association
A special form of association is a consumer-producer relationship, also known as a
client-server association or a use relationship. The consumer-producer relationship can be
viewed as one-way interaction: One object requests the service of another object. The object
that makes the request is the consumer or client, and the object that receives the request
and provides the service is the producer or server.

Association represents the relationship among objects, which is bidirectional.

m
o
.c
a
m
The consumer/producer association.
a
n
For example, we have a print object that prints the consumer object. The print producer
provides the ability to print other objects. Figure 2.8 depicts the consumer-producer
association
y
d
Need for object oriented approach

u
t
Object Oriented Methodology closely represents the problem domain. Because of this, it
is easier to produce and understand designs.
S
The objects in the system are immune to requirement changes. Therefore, allows changes
more easily.
Object Oriented Methodology designs encourage more re-use. New applications can use
the existing modules, thereby reduces the development cost and cycle time.
Object Oriented Methodology approach is more natural. It provides nice structures
for thinking and abstracting and leads to modular design
S.NO RGPV QUESTION YEAR MARKS
1 Explain links and association Dec,2009 10
with suitable example
2 Explain links and association Dec,2008 8
with example, also give the
importance of association

m
o
.c
a
m
a
n
y
d
u
t
S
 UNIT – 2
Object Modelling Technique

Unit-02/Lecture-01

System design life cycle [RGPV /DEC-2010(10)]

Goals
The software development process Building high-quality software
Object-oriented systems development Use-case driven systems development Prototyping
Rapid application development Component-based development
Continuous testing and reusability

Software Process
m
The essence of the software process is the transformation of
o
฀ Users needs to
฀ The application domain into .c
฀A software solution.
a
m
a
n
y
d
u
t
S

A software development process, also known as a software development life-cycle (SDLC), is a

structure imposed on the development of a software product. Similar terms include software
life cycle and software process. It is often considered a subset of systems development life
cycle. There are several models for such processes, each describing approaches to a variety of
tasks or activities that take place during the process. Some people consider a life-cycle model a
more general term and a software development process a more specific term. For example,
there are many specific software development processes that 'fit' the spiral life-cycle model.
Software development organizations implement process methodologies to ease the process of
development. Sometimes, contractors may require methodologies employed, an example is
the U.S. defense industry, which requires a rating based on process models to obtain contracts.
The international standard for describing the method of selecting, implementing and
monitoring the life cycle for software is ISO/IEC 12207.
A decades-long goal has been to find repeatable, predictable processes that improve
productivity and quality. Some try to systematize or formalize the seemingly unruly task of
designing software. Others apply project management techniques to designing software.
Without effective project management, software projects can easily be delivered late or over
budget. With large numbers of software projects not meeting their expectations in terms of
functionality, cost, or delivery schedule, it is effective project management that appears to be
lacking.
Traditional Waterfall Approach to Systems Development

What

How
Do It
m
Test
o
.c
Use

Software Quality
a
m
฀ There are two basic approaches to systems testing.
a
฀ We can test a system according to how it has been built.

n
฀ Alternatively, we can test the system with respect to what it should do.

Quality Measures
y
• d
Systems can be evaluated in terms of four quality measures:

u
–Correspondence
t
– Correctness

S
–Verification
–Validation

• Correspondence measures how well the delivered system corresponds to the needs of
the operational environment.

It cannot be determined until the system is in place.

Correspondence

• Correctness measures the consistency of the product requirements with respect to

the design specification.

Needs Requirements Design

Software

Correctness
m
o
.c
• Verification - "Am I building the product right?" a
• m
Validation - "Am I building the right product?"

a
n
yValidation

d Verification

u
t
S
Needs Requirements Design Software

 Verification is to predict the correctness.

 Validation is to predict the correspondence.
S.NO RGPV QUESTIONS Year Marks
How do you develop an object oriented system Dec 2014 7
development life cycle? Briefly discuss all the
phases related to object oriented approach with
an example.
1. How is object oriented software development DEC,2010 10
different from a functional SDLC?

m
o
.c
a
m
a
n
y
d
u
t
S
 Unit-02/Lecture-02

Object-Oriented Systems Development Approach [RGPV /DEC-2010(10)]

build use cases

Object analysis

Validate/test
O-O Analysis

m
o
Using TOOLS Design classes,
.c Build UI

a
CASE and/or User satisfaction define attributes Build object and prototype
OO programming Usability & QA and methods & dynamic
languages Test model

m
a User satisfaction test,
usability test

n
O-O Implementation O-O Design

y
d
Object-Oriented Systems Development activities

• u
Object-oriented analysis.
• t
Object-oriented design.
•
•
S
Prototyping.
Component-based development.
• Incremental testing.
Use-case driven systems development

Use Case, is a name for a scenario to describe the user–computer

system interaction.

USE CASE
MODEL/DOCUMENT

OOA: Identify Actors OOA: Use case Model

Testing: Usage Scenarios m

OBJECT DESIGN o
.c
INTERACTION CLASSE
DIAGRAM S UI

a
Dynamic model
m
OOA: Object Model OOD: Dynamic model

a
n
y
d
u
Object-Oriented Analysis [RGPV /June-2008(5)]

t
S
OO analysis concerns with determining the system requirements and identifying
classes and their relationships that make up an application.

Object-Oriented Design
•The goal of object-oriented design (OOD) is to design
•The classes identified during the analysis phase,
•The user interface and Data access

OOD activities include:

 Design and refine classes.
 Design and refine attributes.
 Design and refine methods.
 Design and refine structures.
 Design and refine associations.
o Design User Interface or View layer classes.
 o Design data Access Layer classes.

Prototyping
o A Prototype enables you to fully understand how easy or difficult it will be to
implement some of the features of the system.
o It can also give users a chance to comment on the usability and usefulness of the
design.

Types of Prototypes
o A horizontal prototype is a simulation of the interface.
o A vertical prototype is a subset of the system features with complete functionality. o
An analysis prototype is an aid for exploring the problem domain.
o A domain prototype is an aid for the incremental development of the ultimate
software solution.

Component-based development (CBD)

• CBD is an industrialized approach to the software development process.

m
o
• Application development moves from custom development to assembly of pre-built,

.c
pre-tested, reusable software components that operate with each other.

a
m
Componentwrapper Component wrapper

a
n
Legacy programs Legacy data

y
Open Connectivity

d
Component wrapper Component wrapper

u
t
S
Legacy screens Legacy software packages
Rapid Application Development (RAD)

• RAD is a set of tools and techniques that can be used to build an application
faster than typically possible with traditional methods.

• RAD does not replace SDLC but complements it, since it focuses more on
process description and can be combined perfectly with the object-oriented
approach.
Incremental Testing

• Software development and all of its activities including testing are an

iterative process.
• If you wait until after development to test an application for bugs
and performance, you could be wasting thousands of dollars and hours of
time.

m
o
.c
a
Reusability m
a
n
A major benefit of object-oriented systems development is reusability, and this is the
most difficult promise to deliver on.
y
d
Reuse strategy

•
u
Information hiding (encapsulation). • Conformance to naming standards.

t
• Creation and administration of an object repository.
•
S
Encouragement by strategic management of reuse as opposed to
constant redevelopment.
• Establishing targets for a percentage of the objects in the project to be
reused (i.e., 50 percent reuse of objects).

The essence of the software process is the transformation of users needs into a
software solution. The O-O SDLC is an iterative process and is divided into
analysis, design, prototyping/ implementation, and testing.

S.NO RGPV QUESTIONS Year Marks

1. Differentiate between analysis and design? June 2008 5
 m
o
.c
a
m
a
n
y
d
u
t
S
 Unit-02/Lecture-03

Object Oriented Analysis [RGPV /DEC-2009(10)]

Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a
conceptual model of the information that exists in the area being analyzed. Analysis models do
not consider any implementation constraints that might exist, such as concurrency, distribution,
persistence, or how the system is to be built. Implementation constraints are dealt during
object-oriented design (OOD). Analysis is done before the Design[citation needed].
The sources for the analysis can be a written requirements statement, a formal vision
document, interviews with stakeholders or other interested parties. A system may be divided
into multiple domains, representing different business, technological, or other areas of interest,
each of which are analyzed separately.
The result of object-oriented analysis is a description of what the system is functionally required
to do, in the form of a conceptual model. That will typically be presented as a set of use cases,
one or more UML class diagrams, and a number of interaction diagrams. It may also include

m
some kind of user interface mock-up. The purpose of object oriented analysis is to develop a
model that describes computer software as it works to satisfy a set of customer defined
requirements.
o
Object Oriented Analysis
.c
1) a discovery process a
m
2) clarifies and documents the requirements of a system

a
3) focuses on understanding the problem domain

n
4) discovers and documents the key problem domain classes
y
d
5) concerned with developing an object-oriented model of the problem domain

u
6) identified objects reflect the entities that are associated with the problem to be solved

OOA Definition
t
Definition
S
Object Oriented Analysis (OOA) is concerned with developing requirements and specifications
expressed as an object model (population of interacting objects) of a system, as opposed to the
traditional data or functional views.

Benefits
1) maintainability: simplified mapping to the real world a) less analysis effort
b) less complexity in system design c) easier verification by the user

2) reusability: reuse of the artifacts that are independent of the analysis method or
programming language

3) productivity: direct mapping to the features implemented in Object Oriented

Programming Languages
Object Modeling Technique (OMT): [RGPV /June-2006(10)]

OMT (Rumbaugh et al., 1991) was developed as an approach to software development. A

fundamental assumption of OMT is that object-oriented thinking represents a more natural and
intuitive way for people to reason about reality (ibid.:21), although this claim has been severely
questioned, e.g. by Høydalsvik and Sindre, 1993; and Hanseth and Monteiro, 1994.

OMT is included here because Rumbaugh (1993:18) discusses enterprise modeling explicitly using
OMT. OMT is also a widely popular and comprehensive approach that exemplifies the vast
number of object-oriented approaches to modeling.

The purposes of modeling according to Rumbaugh et al. (1991:15) are

 testing physical entities before building them (simulation),

 communication with customers,
 visualization (alternative presentation of information), and
 reduction of complexity.
m
o
Hence, understanding and simulation is at the core. As a general modeling approach, OMT may

.c
be used to model all types of work. OMT proposes three main types of models:

a
 Object model

m
The object model represents the static and most stable phenomena in the modeled domain
(Rumbaugh et al.,1991:21). Main concepts are classes and associations, with attributes and

a
operations. Aggregation and generalization (with multiple inheritance) are predefined

n
relationships.

 Dynamic model
y
d
The dynamic model represents a state/transition view on the model. Main concepts are states,

u
transitions between states, and events to trigger transitions. Actions can be modeled as occurring

t
within states. Generalization and aggregation (concur-rency) are predefined relationships.


S
Functional model

The functional model handles the process perspective of the model, corresponding roughly to
data flow diagrams. Main concepts are process, data store, data flow, and actors.

The entire OMT software development process has four phases: Analysis, system design, object
design, and implementation of the software. Most of the modeling is performed in the analysis
phase. The recommended method incorporates the following activities (Rumbaugh et al.,
1991:261ff):

1. Develop a Problem Statement.

2. Build an Object Model:
1. Identify object classes.
2. Develop a data dictionary for classes, attributes, and associations.
3. Add associations between classes.
 4. Add attributes for objects and links.
5. Organize and simplify object classes using inheritance.
6. Test access paths using scenarios and iterate the above steps as necessary.
7. Group classes into modules, based on close coupling and related function.
3. Build a Dynamic Model:
1. Prepare scenarios of typical interaction sequences.
2. Identify events between objects and prepare an event trace for each scenario.
3. Prepare an event flow diagram for the system.
4. Develop a state diagram for each class that has important dynamic behavior.
5. Check for consistency and completeness of events shared among the state
diagrams.
4. Build a Functional Model:
1. Identify input and output values.
2. Use data flow diagrams as needed to show functional dependencies.
3. Describe what each function does.
4. Identify constraints.
5. Specify optimization criteria.
5. Verify, iterate, and refine the three models:
1. Add most important operations to the object model.

m
2. Verify that classes, associations, attributes and operations are consistent and

o
complete, check with problem statement.
3. Iterate steps to complete the analysis.

.c
a
S.NO RGPV QUESTIONS
m Year Marks

a
1. How will you define the object oriented analysis Dec,2009 10
(OOA)approach? What are the different OOA Methods?
2.
METHODOLOGY n
Describe object modelling techniques(OMT) JUNE,2006 10

y
d
u
t
S
 Unit-02/Lecture-04

object model [RGPV /DEC-2008(10),JUNE-2009(10)]

The object model describes the structure of objects in a system: their identity, relationships
to other objects, attributes, and operations. The object model is represented graphically with
an object diagram (see Fig ). The object diagram contains classes interconnected by
association lines. Each class represents a set of individual objects. The association lines
establish relationships among the classes. Each association line represents a set of links
from the objects of one class to the objects of another class.

DYNAMIC MODEL
OMT provides a detailed and comprehensive dynamic model, in addition to letting you depict
states, transitions, events, and actions. The OMT state transition diagram is a network of states
and events (see Fig). Each state receives one or more events, at which time it makes the
transition to the next state. The next state depends on the current state as well as the events.

m
o
.c
a
m
a
n
y
d
u
t
S

The OMT object model of a bank system. The boxes represent classes and the filled
triangle represents specialization. Association between Account and transaction is one too
many; since one account can have many transactions, the filled circle represents many (zero
or more). The relationship between Client and Account classes is one to one: A client can
have only one account and account can belong to only one person (in this model joint
function model,

The OMT data flow diagram (DFD) shows the flow of data between different processes in
a business. An OMT DFD provides a simple and intuitive method for describing business
processes without focusing on the details of computer systems.

Data flow diagrams use four primary symbols:

1. The process is any function being performed; for example, verify Password or PIN in the
ATM system (see Fig ).
2. The data flow shows the direction of data element movement; for example, PIN code. 3.
The data store is a location where data are stored; for example, account is a data store in the
ATM example.
4. An external entity is a source or destination of a data element; for example, the ATM card
reader.

Overall, the Rumbaugh et al. OMT methodology provides one of the strongest tool sets for
the analysis and design of object-oriented systems
m
State transition diagram for the bank application user interface. The round boxes
represent states and the arrows represent transitions.
o
.c
a
m
a
n
y
d
u
t
S

relationship among models,

 m
o
.c
a
m
S.NO RGPV QUESTIONS Year Marks
1. Explain the following: object model, dynamic model, Dec.2008 10

a
functional model, relationship between different

n
model.
2. What is dynamic model? Illustrate with the help of June,2009 10

y
state transition diagram?

d
u
t
S
 Unit-02/Lecture-05
object diagrams [RGPV /DEC-2013(7),JUNE-2006(5)]

Object Diagrams:
1) show a set of objects and their relationships
2) static snapshots of element instances found in class diagrams

Object Diagram

1) models the instances of classes contained in class diagrams

2) shows a set of objects and their relationships at one time

3) modelling object structures involves taking a snapshot of a system at a given moment

in time

4) is an instance of a class diagram or the static part of an interaction diagram

5) it contains objects and links

m
o
Object Diagram Usage

.c
Object diagrams are used to:

1) visualize
2) specify a
3) construct
m
4) document
a
n
The existence of certain instances in a system, together with their relationships.
Creating an Object Diagram
y
d
1) identify the function/behaviour of interest that results from interaction of classes,

u
interfaces and other artifacts

t
2) for each function/behaviour, identify the artifacts that participate in the collaboration

S
as well as their relationships

3) consider one scenario that invokes the function/behaviour, freeze the scenario and
render each participating object

4) expose the state and attribute values of each object, as necessary to understand the
scenario

5) expose the links among these objects

Object Diagram Example

The following diagram is an example of an object diagram. It represents the Order

management system which we have discussed in Class Diagram. The following diagram is an
instance of the system at a particular time of purchase. It has the following object
  Customer
 Order
 SpecialOrder
 NormalOrder

Now the customer object (C) is associated with three order objects (O1, O2 and O3). These
order objects are associated with special order and normal order objects (S1, S2 and N1). The
customer is having the following three orders with different numbers (12, 32 and 40) for the
particular time considered.

Now the customer can increase number of orders in future and in that scenario the object
diagram will reflect that. If order, special order and normal order objects are observed then we
you will find that they are having some values.

For orders the values are 12, 32, and 40 which implies that the objects are having these values
for the particular moment (here the particular time when the purchase is made is considered
as the moment) when the instance is captured.

The same is for special order and normal order objects which are having number of orders as

m
20, 30 and 60. If a different time of purchase is considered then these values will change
accordingly.
o
.c
So the following object diagram has been drawn considering all the points mentioned above

a
m
a
n
y
d
u
t
S.NO
1.
S RGPV QUESTIONS
What is object diagram?
Year
Dec,2013 7
Marks

2. Draw and explain the notation of object diagram June,2006 5

 UNIT 2/LECTURE 6

State diagrams [RGPV /DEC-2009(5)]

State diagrams are used to describe the behavior of a system. State diagrams describe all of
the possible states of an object as events occur. Each diagram usually represents objects of a
single class and track the different states of its objects through the system.

When to Use: State Diagrams

Use state diagrams to demonstrate the behavior of an object through many use cases of the
system. Only use state diagrams for classes where it is necessary to understand the behavior
of the object through the entire system. Not all classes will require a state diagram and state
diagrams are not useful for describing the collaboration of all objects in a use case. State
diagrams are other combined with other diagrams such as interaction diagrams and activity
diagrams.

How to Draw: State Diagrams

State diagrams have very few elements. The basic elements are rounded boxes representing
the state of the object and arrows indicting the transition to the next state. The activity

m
section of the state symbol depicts what activities the object will be doing while it is in that
state.
o
.c
a
m
a
n
y
d
All state diagrams being with an initial state of the object. This is the state of the object
when it is created. After the initial state the object begins changing states. Conditions

u
based on the activities can determine what the next state the object transitions to.

t
S
Below is an example of a state diagram might look like for an Order object. When the object
enters the Checking state it performs the activity "check items." After the activity is
completed the object transitions to the next state based on the conditions [all items
available] or [an item is not available]. If an item is not available the order is canceled. If all
items are available then the order is dispatched. When the object transitions to the
Dispatching state the activity "initiate delivery" is performed. After this activity is complete
the object transitions again to the Delivered state

m
o
.c
a
m
a
n
State diagrams can also show a super-state for the object. A super-state is used when many
transitions lead to the a certain state. Instead of showing all of the transitions from each state
y
to the redundant state a super-state can be used to show that all of the states inside of

d
the super-state can transition to the redundant state. This helps make the state diagram
easier to read.

u
t
The diagram below shows a super-state. Both the Checking and Dispatching states can
transition into the Canceled state, so a transition is shown from a super-state named Active to
S
the state Cancel. By contrast, the state Dispatching can only transition to the Delivered
state, so we show an arrow only from the Dispatching state to the Delivered state.
 m
S.NO RGPV QUESTION YEAR
o MARKS

.c
1. Explain state diagram with suitable Dec,2009 5
example

a
m
a
n
y
d
u
t
S
 UNIT 2/LECTURE 7

Data flow diagrams [RGPV /DEC-2010(10)]

Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.

m
o
.c
Data Flow Diagram Notations a
m
You can use two different types of notations on your data flow diagrams: Yourdon & Coad or
Gane & Sarson.
a
Process Notations n
y
Process
d
u
t
A process transforms incoming data flow into outgoing data flow.

Yourdon and Coad Process Notations

Gane and Sarson Process Notation

 Datastore Notations

DataStore

Datastores are repositories of data in the system. They are sometimes also referred to as files.

Yourdon and Coad Datastore Notations

Gane and Sarson Datastore Notations

m
Dataflow Notations o
.c
a
Dataflow

m
Dataflows are pipelines through which packets of information flow. Label the arrows with the
name of the data that moves through it.

a
n
y
d
u
t
S
External Entity Notations

External Entity

External entities are objects outside the system, with which the system communicates.
External entities are sources and destinations of the system's inputs and outputs.
 Data Flow Diagram Layers

Draw data flow diagrams in several nested layers. A single process node on a high level
diagram can be expanded to show a more detailed data flow diagram. Draw the context
diagram first, followed by various layers of data flow diagrams.

m
o
.c
a
m
a
The nesting of data flow layers

n
y
Context Diagrams

d
A context diagram is a top level (also known as Level 0) data flow diagram. It only contains one
process node (process 0) that generalizes the function of the entire system in relationship to
external entities.
u
t
S
 DFD levels
The first level DFD shows the main processes within the system. Each of these processes can
be broken into further processes until you reach pseudocode.

m
o
.c
a
m
a
n
y
d
u
t
S
S.NO RGPV QUESTION YEAR MARKS
1. Write a short note on DFD. Explain Dec,2010 10
with an example of bank account
creation and access of the account by a
customer or by the bank
 UNIT 2/LECTURE 8

object oriented S/W development process model [RGPV /DEC-2010(10)]

Requirement
Specification

System
Analysis

System
Design

Implementation
m
o
.c
Testing

a
Deployment

m Maintenance

a
n
Software Development Process y
d
Requirement
u
t
Specification

System

S
Analysis

System
Design

Implementation

Testing

Deployment

Maintenance
A formal process that seeks to understand the problem and document in detail what the
software system needs to do. This phase involves close interaction between users and
designers.
Most of the examples in this book are simple, and their requirements are clearly stated. In the
real world, however, problems are not well defined. You need to study a problem carefully to
identify its requirements.

System Analysis

Requirement
Specification

System
Analysis

System
m
o
Design

.c
Implementation

a
Testing

m Deployment

a Maintenance

n
y
Seeks to a alyze the usi ess pro ess i ter s of data flo , a d to ide tify the syste s i put

d
and output.
Part of the a alysis e tails odeli g the syste s eha ior. The odel is i te ded to apture
u
the essential elements of the system and to define services to the system.

t
S
Implementation
Requirement
Specification

System
Analysis

System
Design

Implementation

Testing

Deployment

Maintenance
The process of translating the system design into programs. Separate programs are written for
each component and put to work together.
This phase requires the use of a programming language like Java. The implementation involves
coding, testing, and debugging.

Testing

Requirement
Specification

System
Analysis

System

m
Design

Implementation
o
Testing
.c
a Deployment

m
a
Maintenance

n
Ensures that the code meets the requirements specification and weeds out bugs.
y
An independent team of software engineers not involved in the design and implementation of

d
the project usually conducts such testing.

u
Deployment
t
S
Requirement
Specification

System
Analysis

System
Design

Implementation

Testing

Deployment

Maintenance
Deployment makes the project available for use.

For a Java applet, this means installing it on a Web server; for a Java application, installing it on
the client's computer.

Maintenance

Requirement
Specification

System
Analysis

System
Design

Implementation

m
o
Testing

.c
Deployment

a Maintenance

m
a
n
Maintenance is concerned with changing and improving the product.

y
A software product must continue to perform and improve in a changing environment. This

d
requires periodic upgrades of the product to fix newly discovered bugs and incorporate
changes
u
t
S.NO
1.
S
RGPV QUESTION
What is object-orientation in
YEAR
Dec,2010
MARKS
10
software development and why
it is needed?
 UNIT 2/LECTURE 9

Analysis [RGPV /Dec-2009(10),June-2008(5)]

In academic environments software often seems to grow, without a clear plan or explicit
intention of fulfilling some need or purpose, except perhaps as a vehicle for research. In
contrast, industrial and business software projects are usually undertaken to meet some
explicit goal or to satisfy some need. One of the main problems in such situations, from the
point of view of the developers of the software, is to extract the needs from the future users of
the system and later to negotiate the solutions proposed by the team. The problem is primarily
a problem of communication, of bridging the gap between two worlds, the world of domain
expertise on the one hand and that of expertise in the craft of software development on the
other. In a number of publications object-oriented analysis has been proposed as providing a

m
solution to this problem of communication. object-oriented techniques allow us to capture the

o
system requirements in a model that directly corresponds with a conceptual model of the
problem domain

.c
Object-Oriented Analysis
a
 analysis = extracting the needs
m
a
Another claim made by proponents of OOP is that an object-oriented approach enables a more

n
seamless transition between the respective phases of the software life-cycle. If this claim is
really met, this would mean that changing user requirements could be more easily discussed in

y
terms of the consequences of these changes for the system, and if accepted could in principle

d
be more easily propagated to the successive phases of development.

u
One of the basic ideas underlying object-oriented analysis is that the abstractions arrived at in

t
developing a conceptual model of the problem domain will remain stable over time. Hence,

S
rather than focusing on specific functional requirements, attention should be given to
modeling the problem domain by means of high level abstractions. Due to the stability of these
abstractions, the results of analysis are likely candidates for reuse.

The reality to be modeled in analysis is usually very complex. mention a number of principles
or mechanisms with which to manage complexity. These show a great similarity to the
abstraction mechanisms mentioned earlier.

Analysis methods
The phases of analysis and design differ primarily in orientation: during analysis the focus is on
aspects of the problem domain and the goal is to arrive at a description of that domain to
which the user and system requirements can be related. On the other hand, the design phase
must result in an architectural model of the system, for which we can demonstrate that it
fulfills the user needs and the additional requirements expressed as the result of analysis.
Analysis methods

 Functional Decomposition = Functions + Interfaces

 Data Flow Approach = Data Flow + Bubbles
 Information Modelling = Entities + Attributes + Relationships
 Object-Oriented = Objects + Inheritance + Message passing

Discuss a number of methods that are commonly used in analysis . The choice of a particular
method will often depend upon circumstances of a more sociological nature. For instance, the
experience of a team with a particular method is often a crucial factor for success.

For this reason, perhaps, an eclectic method combining the various approaches may be
preferable (see, for instance, Rumbaugh {\it et al.}, 1991). However, it is doubtful whether such
an approach will have the same benefits as a purely object-oriented approach.

The method of Functional Decomposition aims at characterizing the steps that must be taken
to reach a particular goal. These steps may be represented by functions that may take

m
arguments in order to deal with data that is shared between the successive steps of the
computation.
o
.c
In general, one can say that this method is not very good for data hiding. Another problem is
that non-expert users may not be familiar with viewing their problem in terms of computation

a
steps. Also, the method does not result in descriptions that are easily amenable to change.

m
The method indicated as the Data Flow Approach aims at depicting the information flow in a
particular domain by means of arrows that represent data and bubbles that represent
processes acting on these data.
a
n
Information Modelling is a method that has become popular primarily for developing

y
information systems and applications involving databases. As a method, it aims at modelling

d
the application domain in terms of entities that may have attributes, and relations between
entities.

u
t
An object-oriented approach to analysis is very similar in nature to the information modelling
approach, at least with respect to its aim of developing a conceptual model of the application
S
domain. However, in terms of their means, both methods differ significantly.

The most important distinction between objects, in the sense of OOP, and entities, as used in
information modelling, to my mind lies in the capacity of objects to embody actual behavior,
whereas entities are of a more passive nature.

Concluding this brief exploration of the analysis phase, I think we may safely set as the goal for
every method of analysis to aim at stable abstractions that is a conceptual model which is
robust with respect to evolving user requirements. Also, we may state a preference for
methods which result in models that have a close correspondence to the concepts and notions
used by the experts operating in the application domain.
 S.NO RGPV QUESTION YEAR MARKS
1. Differentiate between analysis June,2008 5
and design.
2. How will you define the object Dec,2009 10
oriented analysis approach?

m
o
.c
a
m
a
n
y
d
u
t
S
 1

UNIT – 3
Object oriented Design
Unit-03/Lecture-01

Overview of object design [RGPV /DEC-2012(10),June-2012(10)]

 Object-oriented analysis, design and programming are related but distinct.

 OOA is concerned with developing an object model of the application domain.
 OOD is concerned with developing an object-oriented system model to
implement requirements.
 OOP is concerned with realising an OOD using an OO programming language
such as Java or C++.
m
Characteristics of OOD
o
 Objects are abstractions of real-world or system entities and manage

.c
themselves.
 Objects are independent and encapsulate state and representation information.
a
 System functionality is expressed in terms of object services.
 Shared data areas are eliminated.
 Objects communicate by message passing.
m
a
 Objects may be distributed and may execute sequentially or in parallel.

Advantages of OOD
n
y
 Easier maintenance. Objects may be understood as stand-alone entities.
 Objects are potentially reusable components.
d
 For some systems, there may be an obvious mapping from real world entities to
system objects.
u
Object Design t
S
The object design phase determines the full definitions of the classes and associations
used in the implementation, as well as the interfaces and algorithms of the methods
used to implement operations. The object design phase adds internal objects for
implementation and optimizes data structures and algorithms.

Overview of Object Design

During object design, the designer carries out the strategy chosen during the system
design and fleshes out the details. There is a shift in emphasis from application
domain concepts toward computer concepts. The objects discovered during analysis
serve as the skeleton of the design, but the object designer must choose among
different ways to implement them with an eye toward minimizing execution time,
memory and other measures of cost. The operations identified during the analysis
must be expressed as algorithms, with complex operations decomposed into simpler
internal operations.
 2

The classes, attributes and associations from analysis must be implemented as

specific data structures. New object classes must be introduced to store
intermediate results during program execution and to avoid the need for
recomputation. Optimization of the design should not be carried to excess, as ease of
implementation, maintainability, and extensibility are also important concerns.

Steps of Design:
During object design, the designer must perform the following steps:
1. Combining the three models to obtain operations on classes.
2. Design algorithms to implement operations.
3. Optimize access paths to data.
4. Implement control for external interactions
5. Adjust class structure to increase inheritance. 6. Design associations. m
7. Determine object representation. o
8. Package classes and associations into modules.
.c
a
m
Combining the three models to obtain operations on classes.

a
After analysis, we have object, dynamic and functional model, but the object model is

n
the main framework around which the design is constructed. The object model from
analysis may not show operations. The designer must convert the actions and

y
activities of the dynamic model and the processes of the functional model into

d
operations attached to classes in the object model. Each state diagram describes the
life history of an object. A transition is a change of state of the object and maps into

u
an operation on the object.

t
We can associate an operation with each event received by an object. In the state
diagram, the action performed by a transition depends on both the event and the
S
state of the object. Therefore, the algorithm implementing an operation depends
on the state of the object. If the same event can be received by more than one
state of an object, then the code implementing the algorithm must contain a case
statement dependent on the state. An event sent by an object may represent an
operation on another object.
Events often occur in pairs, with the first event triggering an action and the second
event returning the result on indicating the completion of the action. In this case, the
event pair can be mapped into an operation performing the action and returning the
control provided that the events are on a single thread. An action or activity
initiated by a transition in a state diagram may expand into an entire dfd in the
functional model .The network of processes within the dfd represents the body of an
operation.
The flows in the diagram are intermediate values in operation. The designer convert
the graphic structure of the diagram into linear sequence of steps in the
 3

not necessarily all may be operations on the original target object or on other
objects. Determine the target object of a sub operation as follows:

* If a process extracts a value from input flow then input flow is the target.
* Process has input flow or output flow of the same type, input output flow is the
target.
* Process constructs output value from several input flows, then the operation is a
class operation on output class.
* If a process has input or an output to data store or actor, data store or actor is the
target.

S.NO RGPV QUESTIONS Year Marks

1. What is object design? Explain the idea behind
designing the object
RGPV, Dec.
2012 m
10

2. What are various steps involved in object

o
RPPV, JUNE 10

.c
oriented design? Explain in brief 2012

a
m
a
n
y
d
u
t
S
 4

UNIT-03
TOPIC: DESIGNING ALGORITHMS
UNIT-03/LECTURE-02
Designing algorithms [RGPV /DEC-2012(10),DEC-2011(10)]
Each operation specified in the functional model must be formulated as an algorithm.
The analysis specification tells what the operation does from the view point of its
clients, but the algorithm shows how it is done. The analysis specification tells what
the operation does from the view point of its clients, but the algorithm shows how it is
done. An algorithm may be subdivided into calls on simpler operations, and so on

m
recursively, until the lowest-level operations are simple enough to implement directly

o
without refinement .The algorithm designer must decide on the following:
i) Choosing algorithms
.c
a
Many operations are simple enough that the specification in the functional model
already constitutes a satisfactory algorithm because the description of what is done
m
also shows how it is done. Many operations simply traverse paths in the object link

a
network or retrieve or change attributes or links.

n
Non trivial algorithm is needed for two reasons:

y
 To implement functions for which no procedural specification

d
To optimize functions for which a simple but inefficient algorithm serves as
a definition.
u
t
Some functions are specified as declarative constraints without any procedural

S
definition. In such cases, you must use your knowledge of the situation to invent an
algorithm. The essence of most geometry problems is the discovery of appropriate
algorithms and the proof that they are correct. Most functions have simple
mathematical or procedural definitions. Often the simple definition is also the best
algorithm for computing the function or else is also so close to any other algorithm
that any loss in efficiency is the worth the gain in clarity. In other cases, the simple
definition of an operation would be hopelessly inefficient and must be implemented
with a more efficient algorithm.
For example, let us consider the algorithm for search operation .A search can be done in
 5

two ways like binary search (which performs log n comparisons on an average) and a
linear search (which performs n/2 comparisons on an average).Suppose our search
algorithm is implemented using linear search , which needs more comparisons. It
would be better to implement the search with a much efficient algorithm like binary
search.
Considerations in choosing among alternative algorithm include:

a) Computational Complexity:
It is essential to think about complexity i.e. how the execution time (memory) grows
with the number of input values.
For example: For a bubble sort algorithm, ti e ∞ n2
Most other algorithms, time ∞ log n
b) Ease of implementation and understand ability:

m
It is worth giving up some performance on non critical operations if they can be
implemented quickly with a simple algorithm. o
c) Flexibility:
.c
a
Most programs will be extended sooner or later. A highly optimized algorithm often
sacrifices readability and ease of change. One possibility is to provide two

m
Implementations of critical applications, a simple but inefficient algorithm that can be

a
implemented, quickly and used to validate the system, and a complicated but efficient

n
algorithm whose correct implementation can be checked against the simple one.
d) Fine Timing the Object Model: y
d
We have to think, whether there would be any alternatives, if the object model were
structured differently. u
t
S
ii) Choosing Data Structures
Choosing algorithms involves choosing the data structures they work on. We must
choose the form of data structures that will permit efficient algorithms. The data
structures do not add information to the analysis model, but they organize it in a form
convenient for the algorithms that use it.

iii) Defining Internal Classes and Operations

During the expansion of algorithms, new classes of objects may be needed to hold
intermediate results. New, low level operations may be invented during the
decomposition of high level operations. A complex operation can be defined in terms of
 6

lower level operations on simpler objects. These lower level operations must be
defined during object design because most of them are not externally visible. Some of
these operations were found from shopping –list . There is a need to add new
internal operations as we expand high –level functions. When you reach this point
during the design phase, you may have to add new classes that were not mentioned
directly in the client’s description of the problem. These low-level classes are the
implementation elements out of which the application classes are built.

iv) Assigning Responsibility for Operations

Many operations have obvious target objects, but some operations can be performed
at several places in an algorithm, by one of the several places, as long as they
eventually get done. Such operations are often part of a complex high-level operation
with many consequences. Assigning responsibility for such operations can be m
o
easy to overlook in laying out object classes because they are not an inherent part of

.c
one class. When a class is meaningful in the real world, then the operations on it are

a
usually clear. During implementation, internal classes are introduced.

m
How do you decide what class owns an operation?

a
When only one object is involved in the operation, tell the object to perform the

n
operation. When more than one object is involved, the designer must decide which

y
object plays the lead role in the operation. For that, ask the following questions:

d
Is one object acted on while the other object performs the action? It is best to

u
associate the operation with the target of the operation, rather than the

t
initiator.

S
Is one object modified by the operation, while other objects are only queried for the
information they contain? The object that is changed is the target. Looking at the
classes and associations that are involved in the operation, which class is the most
centrally-located in this sub network of the object model? If the classes and
associations form a star about a single central class, it is the target of the operation.
If the objects were not software, but the real world objects represented
internally, what real world objects would you push, move, activate or
manipulate to initiate operation?
Assigning an operation within a generalization hierarchy can be difficult. Since the
definitions of the subclasses within the hierarchy are often fluid and can be adjusted
 7

during design as convenient. It is common to move an operation up and down in the

hierarchy during design, as its scope is adjusted

S.NO RGPV QUESTIONS Year Marks

1. What do you understand by algorithm RGPV, Dec. 10
designing? 2012
2. Discuss in detail the process of designing RGPV, Dec. 10
algorithms in object oriented design 2011

m
o
.c
a
m
a
n
y
d
u
t
S
 8

UNIT-03
TOPIC: DESIGN OPTIMIZATION
UNIT-03/LECTURE-03

Design Optimization [RGPV /DEC-2010(10),DEC-2011(10)]

The basic design model uses the analysis model as the framework for implementation.
The analysis model captures the logical information about the system, while the design
model must add details to support efficient information access. The inefficient but semantically
correct analysis model can be optimized to make the implementation more efficient,
but an optimized system is more obscure and less likely to be reusable in another context.
The designer must strike an appropriate balance between efficiency and clarity. During
design optimization, the designer must

m
Add Redundant Associations for Efficient Access During analysis, it is undesirable to have
redundancy in association network because redundant associations do not add any information.
o
During design, however we evaluate the structure of the object model for an implementation.

.c
For that, we have to answer the following questions:

a
* Is there a specific arrangement of the network that would optimize critical aspects of the
completed system?

m
* Should the network be restructured by adding new associations? * Can existing associations be
omitted?

a
The associations that were useful during analysis may not form the most efficient network

n
when the access patterns and relative frequencies of different kinds of access are
considered. In cases where the number of hits from a query is low because only a fraction of

y
objects satisfy the test, we can build an index to improve access to objects that must be

d
frequently retrieved.

i)
u
Analyze the use of paths in the association network as follows:

t
Examine each operation and see what associations it must traverse to obtain its information.
Note which associations are traversed in both directions, and which are traversed in a single
S
direction only, the latter can be implemented efficiently with one way pointers.

For each operation note the following items:

How often is the operation called? How costly is to perform?

What is the fan-out along a path through the network? Estimate the average count of each
any association encountered along the path. Multiply the individual fan-outs to obtain
the fan-out of the entire path; which represents the number of accesses on the last class in
the path. Note that o e links do not increase the fan-out, although they increase the cost
of each operation slightly, don’t worry about such small effects.
What is the fraction of hits on the final class, that is, objects that meet selection criteria
(if any ) and is operated on? If most objects are rejected during the traversal for some reason,
then a simple nested loop may be inefficient at finding target objects. Provide indexes for
 9

frequent, costly operations with a low hit ratio because such operations are inefficient to
implement using nested loops to traverse a path in the network.

ii) Rearranging Execution Order for Efficiency

After adjusting the structure of the object model to optimize frequent traversal, the next thing
to optimize is the algorithm itself. Algorithms and data structures are directly related to each
other, but we find that usually the data structure should be considered first. One key to
algorithm optimization is to eliminate dead paths as early as possible. Sometimes the
execution order of a loop must be inverted.

iii) Saving Derived Attributes to Avoid Re computation:

Data that is redundant because it can be derived from other data can be ached or store in its
computed form to avoid the overhead of re computing it. The class that contains the cached
data must be updated if any of the objects that it depends on are changed.
Derived attributes must be updated when base values change. There are 3 ways to recognize
when an update is needed:
m
o
Explicit update: Each attribute is defined in terms of one or more fundamental base

.c
objects. The designer determines which derived attributes are affected by each change
to a fundamental attribute and inserts code into the update operation on the base object

a
to explicitly update the derived attributes that depend on it.

m
Periodic Re computation: Base values are updated in bunches. Re compute all derived attributes
periodically without re computing derived attributes after each base value is changed. Re

a
computation of all derived attributes can be more efficient than incremental update because

n
some derived attributes may depend on several base attributes and might be updated more
than once by incremental approach. Periodic re computation is simpler than explicit update

y
and less prone to bugs. On the other hand, if the data set changes incrementally a few

d
objects at a time, periodic re computation is not practical because too many derived
attributes must be recomputed when only a few are affected.

u
t
Active values: An active value is a value that has dependent values. Each dependent value

S
registers itself with the active value, which contains a set of dependent values and update
operations. An operation to update the base value triggers updates all dependent values, but
the calling code need not explicitly invoke the updates. It provides modularity

S.NO RGPV QUESTIONS Year Marks

1. What do ou u dersta d Desig Opti izatio RGPV, Dec. 10
2010
2. Explain what you understand by Desig Opti izatio RGPV, Dec. 10
with the help of suitable examples. 2011
 10

UNIT-03
TOPIC:IMPLEMENTATION OF CONTROL
UNIT-03/LECTURE-04
Implementation of Control [RGPV /June-2005(10)]

The designer must refine the strategy for implementing the state – event models present
in the dynamic model. As part of system design, you will have chosen a basic strategy for
realizing dynamic model, during object design flesh out this strategy.
There are three basic approaches to implementing the dynamic model:
m
i) State as Location within a Program:
o
.c
This is the traditional approach to representing control within a program. The location of

a
control within a program implicitly defines the program state. Any finite state machine can be
implemented as a program. Each state transition corresponds to an input statement. After

m
input is read, the program branches depending on the input event received. Each input

a
statement need to handle any input value that could be received at that point. In highly

n
nested procedural code, low –level procedures must accept inputs that they may know

y
nothing about and pass them up through many levels of procedure calls until some

d
procedure is prepared to handle them. One technique of converting state diagram to code is
as follows:
u
t
1. Identify the main control path. Beginning with the initial state, identify a path through

S
the diagram that corresponds to the normally expected sequence of events. Write the
name of states along this path as a linear sequence of events. Write the names of states
along this path as a linear sequence .This becomes a sequence of statements in the program.
2. Identify alternate paths that branch off the main path and rejoin it later. These become
conditional statements in the program.
3. Identify backward paths that branch off the main loop and rejoin it earlier .These
become loops in program. If multiple backward paths that do not cross, they become nested
loops. Backward paths that cross do not nest and can be implemented with goto if all else
fails, but these are rare.
4. The status and transitions that remain correspond to exception conditions. They can be
 11

handled using error subroutines , exception handling supported by the language , or

setting and testing of status flags. In the case of exception handling, use goto
statements.
ii) State machine engine
The most direct approach to control is to have some way of explicitly representing and
executing state machine. For example, state machine engine class helps execute state
machine represented by a table of transitions and actions provided by the
application.
Each object instance would contain its own independent state variables but would call
on the state engine to determine next state and action.
This approach allows you to quickly progress from analysis model to skeleton prototype of
the system by defining classes from object model state machine and from dynamic model
and creating stubs of action routines. m
o
A stub is a minimal definition of function /subroutine without any internal code. Thus if each

.c
stub prints out its name, technique allows you to execute skeleton application to verify that

a
basic flow of control is correct. This technique is not so difficult.

iii) Control as Concurrent Tasks m

a
An object can be implemented as task in programming language /operating system. It

n
preserves inherent concurrency of real objects.

y
Events are implemented as inter task calls using facilities of language/operating

d
system. Concurrent C++/Concurrent Pascal support concurrency. Major Object Oriented

u
languages do not support concurrency.

t
State-event model is a model which shows the sequence of events happening on an

S
object, and due to which there are changes in the state of an object .
In the state-event model, the events may occur concurrently and control resides directly in
several independent objects. As the object designer you have to apply a strategy for
implementing the state event model.
There are three basic approaches to implementing system design in dynamic models. These
approaches are given below:
• Using the location within the program to hold state (procedure-driven system).
• Direct implementation of a state machine mechanism (event-driven system).
• Using concurrent tasks.
 12

Control as State within Program

1. The term control literally means to check the effect of input within a program. For
example, in Figure1, after the ATM card is inserted (as input) the control of the program is
transferred to the next state (i.e., to request password state).
2. This is the traditional approach to represent control within a program. The location
of control within a program implicitly defines the program state. Each state transition
corresponds to an input statement.
After input is read, the program branches depending on the input event produce some
result.
Each input statement handles any input value that could be received at that point. In case
of highly nested procedural code, low-level procedures must accept inputs that may be
passed to upper level procedures.
m
o
After receiving input they pass them up through many levels of procedure calls. There must

.c
be some procedure prepared to handle these lower level calls. The technique of converting
a state diagram to code is given as under:
a
m
a) Identify all the main control paths. Start from the initial state; choose a path

a
through the diagram that corresponds to the normally expected sequence of events.

n
Write the names of states along the selected path as a linear sequence. This will be a

y
sequence of statements in the program.

d
b) Choose alternate paths that branch off the main path of the program and rejoin it

u
later. These could be conditional statements in the program.

t
c) Identify all backward paths that branch off the main loop of the program and rejoin

S
it earlier. This could be the loop in the program. All non-intersecting backward paths
become nested loops in the program.
d) The states and transitions that remain unchecked correspond to exception
conditions. These can be handled by applying several techniques, like error subroutines,
exception handling supported by the language, or setting and testing of status flags.

To understand control as a state within a program, let us take the state model for the ATM
class showing the state model of the ATM class and the pseudo code derived from it.
In this process first, we choose the main path of control, this corresponds to the reading of
a card querying the user for transaction information, processing the transaction, printing a
receipt, and ejecting the card.
 13

If the customer wants to process for some alternates control that should be provided. For
example, if the password entered by the customer is bad, then the customer is asked to try
again.

m
o
.c
a
m
a
n
y
d
u
t
S
 14

m
o
.c
a
m
a
n
y
d
u
t
S

Control of states and events in ATM

 15

Pseudocode of ATM control. The pseudocode for the ATM is given as under:

m
o
.c
a
m
a
n
y
d
These lines are the pseudocode for the ATM control loop, which is another form of

u
representation of Figure 1. Furthermore, you can add cancel event to the flow of control,

t
which could be implemented as goto exception handling code. Now, let us discuss controls
as a state machine engine.
S
Control as a State Machine Engine
First let us define state machine: the state machine is an object but not an application
object. It is a part of the language substrate to support the syntax of application object .
The common approach to implement control is to have some way of explicitly representing
and executing state machines. For example, a general state machine engine class could
provide the capability to execute a state machine represented by a table of transitions and
actions provided by the application. As you know, each object contains its own
independent state variable and could call on the state engine to determine the next state
and action.
 16

Control as Concurrent Tasks

The term control as concurrent task means applying control for those events of the object
that can occur simultaneously. An object can be implemented as a task in the programming
language or operating system. This is the most general approach of concurrency controls.
With this you can preserve the inherent concurrency of real objects. You can implement
events as inter-task calls using the facilities of the language, or operating system.

As far as OO programming languages are concerned, there are some languages, such as
Concurrent Pascal or Concurrent C++, which support concurrency, but the application of
such languages in production environments is still limited. Ada language supports
concurrency, provided an object is equated with an Ada task, although the run-time cost is
very high. The major object oriented languages do not yet support concurrency.

m
S.NO RGPV QUESTIONS Year Marks
1. What are the important issues in implementing object- RGPV, June 10
oriented systems?
o
2005

.c
a
m
a
n
y
d
u
t
S
 17

UNIT-03
TOPIC: DESIGN OF AASSOCIATIONS
UNIT-03/LECTURE-05

Design of Associations [RGPV /DEC-2003(10),DEC-2007(10)]

During object design phase, we must formulate a strategy for implementing all associations

m
in the object model. We can either choose a global strategy for implementing all
associations uniformly, o
or a particular technique for each association.

i) Analyzing Association Traversal .c

a
Associations are inherently bidirectional. If association in your application is traversed

m
in one direction, their implementation can be simplified. The requirements on your

a
application may change , you may need to add a new operation later that needs to

n
traverse the association in reverse direction. For prototype work, use bidirectional

y
association so that we can add new behaviour and expand /modify. In the case of optimization

d
work, optimize some associations.

u
t
ii) One-way association

S
* If an association is only traversed in one direction it may be implemented as pointer.
* If multiplicity is „many‟ then it is implemented as a set of pointers. * If the many is
ordered, use list instead of set .
* A qualified association with multiplicity one is implemented as a dictionary object(A
dictionary is a set of value pairs that maps selector values into target values. * Qualified
association with multiplicity any are rare.(it is implemented as dictionary set of
objects).

iii) Two-way associations

 18

Many associations are traversed in both directions, although not usually with equal
frequency. There are three approaches to their implementation:
Implement as an attribute in one direction only and perform a search when a backward
traversal is required. This approach is useful only if there is great disparity in traversal
frequency and minimizing both the storage cost and update cost are important.

Implement as attributes in both directions. It permits fast access, but if either attribute is
updated then the other attribute must also be updated to keep the link consistent .This
approach is useful if accesses outnumber updates

m
o
.c
a
m
a
n
y
d
u
t
S

Implement as a distinct association object independent of either class. An association

object is a set of pairs of associated objects stored in a single variable size object. An
association object can be implemented using two dictionary object one for forward
direction and other for reverse direction.
 19

iv) Link Attributes

Its implementation depends on multiplicity.

m

o
If it is a one-one association, link attribute is stored in any one of the classes involved.

.c
a
 If it is a many-one association, the link attribute can be stored as attributes of many
object, since ea h a o ject appears only once in the association.

 m
If it is a many-many association, the link attribute can‟t be associated with either
a
object; implement association as distinct class where each instance is one link and its

n
attributes.

y
d
u
t
S.NO
1. S
RGPV QUESTIONS
Write Short note on design of associations
Year
RGPV, Dec.
Marks
10
2003
2. Write explanatory short note on design of association RGPV, Dec. 10
2007
 20

UNIT-03
TOPIC: INHERITANCE ADJUSMENT
UNIT-03/LECTURE-06

INHERITANCE ADJUSTMENT [RGPV /DEC-2011(10)]

As you know in object oriented analysis and design the terms inheritance defines a
relationship among classes, wherein one class shares the structure or behavior defined in
one or more classes. As object design progresses, the definitions of classes and operations

m
can often be adjusted to increase the amount of inheritance. In this case, the designer
should:
o
.c
 Rearrange and adjust classes and operations to increase inheritance
 Abstract common behaviour out of groups of classes
 a
Use delegation to share behaviour when inheritance is semantically invited.

m
Rearrange Classes and Operations
a
n
Sometimes, the same operation is defined across several classes and can easily be inherited

y
from a common ancestor, but more often operations in different classes are similar, but not

d
identical. By slightly modifying the definitions of the operations or the classes, the

u
operations can often be made to match so that they can be covered by a single inherited

t
operation. The following kinds of adjustments can be used to increase the chance of
inheritance S
You will find that some operations may have fewer arguments than others. The missing
arguments can be added but ignored. For example, a draw operation on a monochromatic
display does not need a colour parameter, but the parameter can be accepted and ignored
for consistency with colour displays.
Some operations may have fewer arguments because they are special cases of more
general arguments. In this case, you may implement the special operations by calling the
general operation with appropriate parameter values. For example, appending an element
to a list is a special case of inserting an element into list; here the insert point simply
follows the last element.
 21

Similar attributes in different classes may have different names. Give the attributes the
same name and move them to a common ancestor class. Then operations that access the
attributes will match better. Also, watch for similar operations with different names. You
should note that a consistent naming strategy is important to avoid hiding similarities.

An operation may be defined on several different classes in a group, but be undefined on

the other classes. Define it on the common ancestor class and declare it as a no-op on the
classes that do not care about it. For example, in OMTool the begin-edit operation places
some figures, such as class boxes, in a special draw mode to permit rapid resizing while the
text in them is being edited. Other figures have no special draw mode, so the begin-edit
operation on these classes has no effect.

Making Common Behaviour Abstract

m
o
Let us describe abstraction Abstraction means to focus on the essential, inherent aspects

.c
of an entity and ignoring its accidental properties . In other words, if a set of operations
and/or attributes seem to be repeated in two classes. There is a scope of applying

a
inheritance. It is possible that the two classes are really specialised variations of the
something when viewed at a higher level of abstraction.

m
When common behaviour has been recognised, a common super class can be created that
implements the shared features, leaving only the specialised features in the subclasses.
a
This transformation of the object model is called abstracting out a common super class or

n
common behaviour. Usually, the resulting super class is abstract, meaning that there are no
direct instances of it, but the behaviour it defines belongs to all instances of its subclasses.

y
For example, again we take a draw operation of a geometric figure on a display screen

d
requires setup and rendering of the geometry.
The rendering varies among different figures, such as circles, lines, and spines, but the

u
setup, such as setting the colour, line thickness, and other parameters, can be inherited by

t
all figure classes from abstract class figure.

S
The creation of abstract super classes also improves the extensibility of a software product,
by keeping space for further extension on base of abstract class.

Use Delegation to Share Implementation

As we now know, inheritance means the sharing of to the behaviour of a super class by its
subclass. Let us see how delegation could be used for this purpose. Before we use
delegation, let us try to understand that what actually delegation can do.

The term delegation Delegation consists of catching an operation on one object and
sending it to another object that is part, or related to the first object. In this process, only
meaningful operations are delegated to the second object, and meaningless operations can
be prevented from being inherited accidentally . It is true that Inheritance is a mechanism
for implementing generalization, in which the behaviour of super class is shared by all its
 22

subclasses. But, sharing of behaviour is justifiable only when a true generalization

relationship occurs, that is, only when it can be said that the subclass is a form of the super
class.

Let us take the example of implementation of inheritance. Suppose that you are about to
implement a Stack class, and you already have a List class available. You may be tempted to
make Stack inherit from List. Pushing an element onto the stack can be achieved by adding
an element to the end of the list and popping an element from a stack corresponds to
removing an element from the end of the list. But, we are also inheriting unwanted list
operations that add or remove elements from arbitrary positions in the list.

Often, when you are tempted to use inheritance as an implementation technique, you
could achieve the same goal in a safer way by making one class an attribute or associate of
the other class. In this way, one object can selectively invoke the desired functions of
another class, by using delegation rather than applying inheritance.

A safer implementation of Stack would delegate to the List class. Every instance of Stack
contains a private instance of List. The Stack :: push operation delegates to the list by
m
calling its last and add operations to add an element at the end of the list, and the pop

o
operation has a similar implementation using the last and remove operations. The ability to

.c
corrupt the stack by adding or removing arbitrary elements is hidden from the client of the
Stack class.

a
m
a
n
y
d
u
t
S

Alternative implementations of a Stack using inheritance (left) and delegation (right)

it is obvious that we should discourage the use of inheritance to share the operations
between two related classes. Instead, we should use delegation so that one class can
selectively invoke the desired functions of another class. Now, you are aware of the
concept of inheritance and its adjustment. In the next section, we will discuss association
design and different types of associations.
 23

S.NO RGPV QUESTIONS Year Marks

1. Explain the adjustment of inheritance in classes and RGPV, 10
operations Dec.
2011

m
o
.c
a
m
a
n
y
d
u
t
S
 24

UNIT-03
TOPIC:OBJECT REPRESENTATION
UNIT 3/LECTURE 7

Object Representation [RGPV /DEC-2012(10)]

Implementing objects is mostly straight forward, but the designer must choose when to use
primitive types in representing objects and when to combine groups of related objects.
Classes can be defined in terms of other classes, but eventually everything must be
implemented in terms of built-in-primitive data types, such as integer strings, and enumerated
types. For example, consider the implementation of a social security number within an
employee object. It can be implemented as an attribute or a separate class.
m
o
Defining a new class is more flexible but often introduces unnecessary indirection. In a similar

.c
vein, the designer must often choose whether to combine groups of related objects The

a
object designer has to choose when to use primitive types in representing the objects or
when to combine the groups of objects. A class can be defined in terms of other classes but

m
ultimately all data members have to be defined in terms of built- in data types supported by a

a
programming language. For example, roll no. can be implemented as integer or string. In

n
another example, a two dimensional can be represented as one class or it can be

y
implemented as two classes – Line class and Point class.

d
The ter u
o je t represe tatio ea s to represe t o je t usi g o je ts odel s ols .
t
Implementing objects is very simple. The object designer decides the use of primitive types or
S
to combine groups of related objects in their representation. We can define a class in terms of
other class. The classes must be implemented in terms of built-in primitive data types, such as
integers, strings, and enumerated types. For example, consider the implementation of a social
security number within an employee object which is shown in Figure 6. The social security
number attribute can be implemented as an integer or a string, or as an association to a social
security number object, which itself can contain either an integer or a string. Defining a new
class is more flexible, but often introduces unnecessary indirection. It is suggested that new
classes should not be defined unless there is a definite need it.
 25

m
o
.c
a
S.NO RGPV QUESTION m YEAR MARKS
1.
a
How objects are represented? Explain RGPV, Dec. 10

n
use-case driven approach. 2012

y
d
u
t
S
 26

UNIT-03
TOPIC: PHYSICAL PACKAGING
UNIT 3/LECTURE 8

Physical Packaging [RGPV /June-2011(10),June-2012(10)]

Programs are made of discrete physical units that can be edited, compiled, imported, or
otherwise manipulated. In C and Fortran the units are source files; In Ada, it is packages. In
object oriented languages, there are various degrees of packaging. In any large project, careful

m
partitioning of an implementation into packages is important to permit different persons to
cooperatively work on a program.
o
Packaging involves the following issues: .c
i) Hiding internal information from outside view. a
m
O e desig goal is to treat lasses as „ la k o es‟ , whose external interface is public but

a
whose internal details are hidden from view. Hiding internal information permits

n
implementation of a class to be changed without requiring any clients of the class to modify

y
code. Additions and changes to the class are surrou ded fire walls that li it the effe ts of

d
any change so that changes can be understood clearly. Trade off between information hiding

u
and optimization activities. During analysis, we are concerned with information hiding. During

t
design, the public interface of each class must be defined carefully. The designer must decide

S
which attributes should be accessible from outside the class. These decisions should be
recorded in the object model by adding the annotation {private} after attributes that are to be
hidden, or by separating the list of attributes into 2 parts. Taken to an extreme a method on a
class could traverse all the associations of the object model to locate and access another object
in the system .This is appropriate during analysis, but methods that know too much about the
entire model are fragile because any change in representation invalidates them. During design
we try to limit the scope of any one method. We need top define the bounds of visibility that
each method requires.
 27

Specifying what other classes a method can see defines the dependencies between classes.
Each operation should have a limited knowledge of the entire model, including the structure of
Classes, associations and operations. The fewer things that an operation knows about, the less
likely it will be affected by any changes. The fewer operations know about details of a class, the
easier the class can be changed if needed.
The following design principles help to limit the scope of knowledge of any operation:
 Allocate to each class the responsibility of performing operations and providing
information that pertains to it.
 Call an operation to access attributes belonging to an object of another class Avoid
traversing associations that are not connected to the current class. Define interfaces at
as high a level of abstraction as possible.

m
Hide external objects at the system boundary by defining abstract interface classes, that

o
is, classes that mediate between the system and the raw external objects.


.c
Avoid applying a method to the result of another method, unless the result class is
already a supplier of methods to the caller. Instead consider writing a method to
combine the two operations.
a
ii) Coherence of entities.
m
a
One important design principle is coherence of entities. An entity, such as a class, an operation,

n
or a module, is coherent if it is organized on a consistent plan and all its parts fit together

y
toward a common goal. It shouldn’t be a collection of unrelated parts. A method should do one

d
thing well .a single method should not contain both policy and implementation.

u
A poli is the aki g of o te t depe de t de isio s. I ple e tatio is the e e utio of

t
full spe ified algorith s.

S
Policy involves making decisions, gathering global information, interacting with outside world
and interpreting special cases. Policy methods contain input output statements, conditionals
and accesses data stores. It doesn’t contain complicated algorithms but instead calls various
implementation methods. An implementation method does exactly one operation without
making any decisions, assumptions, defaults or deviations .All information is supplied as
arguments (list is long). Separating policy and implementation increase reusability. Therefore
implementation methods don’t contain any context dependency. So they are likely to be
reusable Policy method need to be rewritten in an application , they are simple and consists of
high level decisions and calls on low-level methods. A class shouldn’t serve too many purposes.
 28

iii) Constructing physical modules.

During analysis and system design phases we partitioned the object model into modules.
* The initial organization may not be suitable for final packaging of system implementation
New classes added to existing module or layer or separate module.

Modules should be defined so that interfaces are minimal and well defined. Connectivity of
object model can be used as a guide for partitioning modules. Classes that are closely
connected by associations should be in the same module. Loosely connected classes should be
grouped in separate modules. Classes in a module should represent similar kinds of things in
the application or should be components of the same composite object.
Try to encapsulate strong coupling within a module. Coupling is measured by number of
different operations that traverse a given association. The number expresses the number of
different ways the association is used, not the frequency. m
o
.c
Packaging of Classes and Associations into Modules

a
Modularity is the property of a system that has been decomposed into a set of cohesive
and loosely coupled modules. Modules serve as the physical containers in which we declare

m
the classes and objects of our logical designs. A module can be edited, compiled or

a
imported separately. Different object-oriented programming languages support the packing
in different ways. For example, Java supports in the form of package, C++ in the form of
header files etc.
n
y
Modules are program units that manage the visibility and accessibility of names. Following

d
purposes can be solved by modularity.

u
A module typically groups a set of class definitions and objects to implement some
t
service or abstraction.
 S
A module is frequently a unit of division of responsibility within a
programming team. A module provides an independent naming
environment that is separate from other modules within the program.
 Modules support team engineering by providing isolated name spaces.

Packaging involves the following three issues:

 Information Hiding
 Coherence of Entities
 Constructing Physical Modules
 29

Information Hiding: During analysis phase we are not concerned with information hiding. So,
visibilities of class members are not specified during analysis phase. It is done during object
design phase. In a class, data members and internal operations should be hidden, so, they
should be specified as private. External operations form the interface so they should be
specified as public.

The following design principles can be used to design classes:

 A class should be given the responsibilities of performing the operations and

proving information contained in it to other classes.
 Calling a method of that class should access attributes of other class.
 Avoid traversing associations that are not connected to this class.
 Define interfaces at the highest level possible.

m
External objects should be hidden. Defining interface classes could do this.

o
Avoid applying a method to the result of another class unless the result class is

.c
already a supplier of methods to the caller class.

a
Coherence of Entities: Module, class, method etc. are entities. An entity is said to coherent, if

m
it is organized on a consistent plan and all its parts fit together toward a common goal.

a
Policy is the making of context-dependent decisions while implementation is the

n
execution of fully specified algorithms. Policy involves making decisions, gathering global

y
information and interacting with the external agents. Policy and implementation
should be separated in different methods i.e. both should not be combined into a single

d
method.A policy method does not have complex algorithms rather invokes various
implementation methods. It can contain I/O statements, conditional statements and can
access data stores.
u
t
An implementation method does exactly one operation, without making any decision,

S
assumption, default or deviation. All its information is supplied by arguments. These methods
do not contain any context-dependent decision so they are likely to be reusable.

Constructing Physical Modules: Modules of analysis phase have changed as more classes
and associations have been added during object design phase. Now, the object designer has
to create modules with well-defined and minimal interfaces. The classes in a module should
have similar kinds of things in the system. There should be cohesiveness or unity of the
purpose in a module. So the classes, which are strongly associated, should be put into a single
module.
 30

S.NO RGPV QUESTION YEAR MARKS

1. Describe the various issues involved in RGPV, June 10
packaging in programs. 2011
2. Discuss the issues involved in RGPV, June. 10
packaging 2012

m
o
.c
a
m
a
n
y
d
u
t
S
 31

UNIT 3
TOPIC:DOCUMENTING DESIGN DECISIONS
UNIT 3/LECTURE 9

Documenting Design Decisions [RGPV /DEC-2011(10),DEC-2012(10)]

The above design decisions must be documented when they are made, or you will become
confused. This is especially true if you are working with other developers. It is impossible to
remember design details for any non trivial software system, and documentation is the best
way of transmitting the design to others and recording it for reference during maintenance.
The design document is an extension of the Requirements Analysis Document.
-> The design document includes revised and much more detailed description of the object
m
model-both graphical and textual. Additional notation is appropriate for showing
o
.c
implementation decisions, such as arrows showing the traversal direction of associations and
pointers from attributes to other objects.

a
-> Functional model will also be extended. It specifies all operation interfaces by giving their

m
arguments, results, input-output mappings and side effects.

a
-> Dynamic model – if it is implemented using explicit state control or concurrent tasks then

n
the analysis model or its extension is adequate. If it is implemented by location within program

y
code, then structured pseudocode for algorithms is needed.

d
Keep the design document different from analysis document .The design document includes

u
many optimizations and implementation artefacts. It helps in validation of software and for

t
reference during maintenance. Traceability from an element in analysis to element in design

S
document should be straightforward. Therefore the design document is an evolution of
analysis model and retains same names.
The Design Document will include a revised and much more detailed description of the
Object Model in both graphical form (object model diagrams) and textual form (class
descriptions). You can use additional notation to show implementation decisions, such as
arrows showing the traversal direction of associations and pointers from attributes to other
objects.
The Functional Model can also be extended during the design phase, and it must be kept
current. It is a seamless process because object design uses the same notation as analysis,
but with more detail and specifics. It is good idea to specify all operation interfaces by
 32

giving their arguments, results, input-output mappings, and side effects.

Despite the seamless conversion from analysis to design, it is probably a good idea to keep
the Design Document distinct from the Analysis Document. Because of the shift in
viewpoint from an external user’s view to an internal implementer’s view, the design
document includes many optimizations and implementation artefacts. It is important to
retain a clear, user-oriented description of the system for use in validation of the completed
software, and also for reference during the maintenance phase of the object modelling

S.NO RGPV QUESTION YEAR MARKS

1. Discuss the documentation of RGPV, Dec. 2011 10
design decisions
2. Explain physical packaging and RGPV, Dec. 2012 10
documenting design decision

m
o
.c
a
m
a
n
y
d
u
t
S
 Millions of University Lecture Notes, Book Solutions,
Summary, Assignments and Projects are available for FREE.