Oops

OBJECT ORIENTED PROGRAMMING AND SYSTEM DESIGN
UCS 4045 :
UNIT I
Limitations in structured programming-Characteristics of Object
Oriented Language data types loops pointers arrays structures
functions Classes Objects.
UNIT II
Operator overloading Inheritance Polymorphism Templates
Exception Handling class Hierarchies library organization and
containers Strings Stream Design and programming.
UNIT III
Object Orientation System development Review of objects inheritance - Object relationship Dynamic binding OOSD life cycle
Process Analysis Design prototyping Implementation TestingOverview of Methodologies.
UNIT IV
OMT Booch methodology, Jacobson methodology patterns Unified
approach UML Class diagram Dynamic modeling. Use case model
Creation of classes Noun phrase approach responsibilities
Collaborators Object relationships Super-Sub class Aggregation.
UNIT V
OO Design axioms Class visibility refining attributes Methods
Access layer OODBMS Table class mapping view layer. Quality
assurance testing - Inheritance and testing Test plan Usability testing
User satisfaction Testing.
Note: Unit I & II deals with C++
TEXT BOOKS
1.
2.
Bjarae Stroustrup, The C++ Programming Language, (3rd and

Special Edition) Addison Wesley, 2000
Ali Bahrami, Object Oriented System Development, McGraw-Hill
International Edition, 1999.
UNIT I
Limitations
in
structured
programming-
Characteristics of Object Oriented Language data

types loops pointers arrays structures
functions Classes Objects.
CHARACTERISTICS OF OBJECT ORIENTED PROGRAMMING

It has seven characteristics :
1.Objects
2.Classes
3.Data abstraction and encapsulation
4.Inheritance
5.Polymorphism
6.Dynamic binding
7.Message passing
OBJECTS
Objects are the basic run-time entities in an object-oriented system.

They may represent a person, a place, a bank account or any item that
the program has to handle. Any programming problem has to be
analyzed in terms of objects and the nature of communication between
them. Objects must be chosen such that they match closely with the
real-world objects.
The objects have two types of representation :
1.Explicit representation
2.Implicit/internal representation
EXPLICIT REPRESENTATION
Here data and member functions are declared or defined externally

or explicitly inside the class referred Explicit representation of object.
Object: STUDENT
DATA
Name
Date of
birth
Marks
..
FUNCTIONS
Total
Average
Display
.
IMPLICIT REPRESENTATION
Here data declaration and definition are hided .It has only what are the
functions that can be implemented.
CLASSES
Total
STUDENT
A class is a collection of objects of similar type. That is it is a collection of

variables of different datatypes and the functions that act on them into a
Average
single entity. Once a class has been defined we can create any number of
objects belonging to that class. And using these objects we can access
the class.
Display
The syntax for creation of objects is:

Class_name object;
For example, mango, apple and orange are the members of a class Fruit.
Now the object mango can be created as:
Fruit mango;
DATA ABSTRACTION AND ENCAPSULATION
Abstraction refers to the act of representing essential features

without including the background details. It deals with the attributes of
classes like size, length, height, width.
The wrapping up of data and functions into a single unit is known

as encapsulation. The data is not accessible to the outside world and
only those functions which are declared in the class can access it. This
hiding of data from outsiders is called data hiding.
INHERITANCE
Inheritance is the feature by which the objects of one class acquire

the properties of objects of another class. The concept of inheritance
provides the idea of reusability. That is a newly created class can use the
features of an existing class and in addition to this the new class can
have its own features.
Example program :
Class a
{
add();
//parent class
mul();
};
Class b : : public a
//derived class
{
add();
fact();
};
POLYMORPHISM
Polymorphism means the ability to take more than one form. An

operation may take different behavior depending on the type of data used
in the operation.
It has the objectives:
1. Function overloading
Using a single function name to perform different type of tasks
is called function overloading. Here many functions may have the same
name, but have different set of parameters.
Example:
void add(int , int);
float add(float, float);
double add(double, double);
2. Operator overloading
The operator can be made to exhibit different behaviors in
different instances. For example the + operator can be used to add
integer numbers and the same operator can be used to concatenate two
strings.
Example:
i.
2+5=7
ii.
over + loading= overloading
DYNAMIC BINDING
Binding refers to the linking of procedure call with the procedure to be

executed in response to the call. It is of two types:
i.
ii.
Static binding
Dynamic binding
Static binding refers to making a link/relationships statically thro

programs
Eg : When a function call is made it is linked to the function definition.
Dynamic binding means that the code associated with a procedure call is
not known until the time of call at runtime.It is associated with
polymorphism and inheritance.
Eg:While calling a polymorphic function the binding is done only at the

runtime.
MESSAGE PASSING
An object-oriented program consists of a set of objects that communicate

with each other. The process of programming in an object-oriented
language therefore involves the following steps:
i.
Creating class that define object and its behavior
ii.
Creating objects from class definitions
iii.
Establishing communication among them
Objects communicate with each other by sending or receiving messages.

A message for an object is the request for the execution of a procedure.
Message passing involves sending the name of the object, the name of
the function and the information to be sent.
E.g.:
Employee. Salary (name);
(object) (message)
(information)
DATA TYPES
Both C and C++ compilers support all the built-in data types.
C++ Data Types are classified as
1. User-defined type
i. Structure
ii. Union
iii. Class
iv. Enumeration
2. Built-in type
i. Integral type
a. int
b. char
ii. Void
iii. Floating type
a. float
b. double
3. Derived type
i. Array
ii. Function
iii. Pointer
iv. Reference
CONTROL STATEMENTS
Control statements are broadly classified into:
1. Conditional statements
if statement
if else statement
switch case statement
2. Loop statements
for loop
while loop
do while loop
3. Breaking control statements
break statement
continue statement
goto statement
CONDITIONAL STATEMENTS
The conditional expressions are mainly used for decision making.
SIMPLE IF:
The if statement is used to express conditional expressions.
Syntax:
if ( test expression )
{
statement block;
}
statement x;
If the given condition is true then it will execute the statement;

otherwise it will execute the optional statements.
Example:
.
if( category == sports )
{
marks = marks + bonus;
}
cout>>marks;
.
The program tests the type of category of the student. If the student
belongs to the sports category, then additional bonus are added to his
marks before they are printed.
IF ELSE STATEMENTS:
The if else statement is an extension of the simple if statement
Syntax:
if ( test expression )
{
true block statement(s);
}
else
{
false block statement(s);
}
statement x;
If the test expression is true, then the true_block statements

immediately following the if statements are executed; otherwise, the
false_block statements are executed. In either case, either true_block or
false_block will be executed, not both,
Example:
..
if ( code == 1)
boy = boy + 1;
else
girl = girl+ 1;
cout<<boy<<girl;
...
Here, if the code is equal to 1, the statement boy = boy + 1; is executed
and the control is transferred to cout, after skipping the else part. If the
code is not equal to 1, statement boy = boy + 1 is skipped and girl = girl +
1 is executed before the control reaches cout.
SWITCH STATEMENT:
The switch statement tests the value of a given variable (or
expression) against a list of case values and when a match is found, a
block of statements associated with that case is executed.
Syntax:
switch ( expression )
{
case value_1:
block_1
break;
case value_2:
block_2
break;
default:
default_ block
break;
}
statement x;
When the switch is executed, the value of the expression is

successfully compared against values value_1, value_2, .. If a case is
found whose value matches with the value of the expression, then the
block of statements that follow the case are executed.
The break statement at the end of each block signals the end of a
particular case and causes an exit from the switch statement,
transferring the control to the statement x following the switch.
The default is an optional case. When present, it will be executed if
the value of the value of the particular expression does not match with
any of the case.
Example:
..
..
index = marks/10;
switch (index)
{
case 10:
case 9:
case 8:
grade=HONOURS;
break;
case 7:
case 6:
grade=FIRST DIVISION;
break;
case 5:
grade=SECOND DIVISION;
break;
case 4:
grade=THIRD DIVISION;
break;
default:
grade=FAIL;
break;
}
cout<<grade;
We used a conversion statement index = mark/10; where, index is

defined as an integer. The variable index takes the following integer
values from 10 to 0. This statements illustrates two features. First, it
uses empty cases. The first three cases will execute the same statements
grade = HONOURS. Second, default condition is used for all other cases
where marks is less than 40.
LOOP STATEMENTS
They
are
essential
to
construct
systematic
block
styled
programming.
FOR LOOP:
The for loop is an entry controlled
loop that provides a more
concise loop control structure.

Syntax:
for ( initialization ; test condition ; increment / decrement )
{
Body of the loop
}
( i ) Initialization of the control variable is done first, using assignment

statements such as i=1 and count=0.
( ii )
The value of the control variable is tested using the test
condition. The test condition is a relational expression. If the condition

is true, the body of the loop is executed; otherwise the loop is terminated
and the execution continues out of the loop.
( iii ) when the body of the loop is executed, the control is transferred
back to the for statement after evaluation the last statement in the loop.
Now, the control variable is incremented / decremented using an
assignment statement and the new value of the control variable is again
tested to see whether it satisfies the loop condition. If the condition is
satisfied, the body of the loop is again executed. This process continues
till the value of the control variable fails to satisfy the test condition.
Example:
for( x=1; x<=10; x++)
{
cout<<x;
}
Initially, x value is 1and the condition is checked. As the condition is
true, the control enters the loop and prints the value of x ( i.e. 1 ). Now x
value is incremented by one and the condition is checked. Similarly the
loop is executed 10 times and finally the value of x reaches 11 and is
checked. As the condition fails the control comes out of the loop.
WHILE STATEMENT:
The simplest of all structures in C++ is the while statement.
Syntax:
while ( test condition )
{
Body of the loop
}
The test condition is executed and if the condition is true, then the body
of the loop is executed. After execution of the body, the test condition is
once again evaluated if it is true. This process of execution repeatedly
continues until the test condition becomes false and the control is
transferred out of the loop.
Example:
..
sum=0;
n=1;
while ( n<= 10 )
{
sum = sum + n * n;
n = n +1;
}
cout<<SUM= <<sum;
..
The body of the loop is executed ten times for n = 1, 2, . ,10 each time
adding the square of the value of n, which is incremented inside the loop.
n is called counter or counter variable.
DO WHILE STATEMENT:
On some occasions it might be necessary to executed the body of

the loop before the test is performed. Such situations can be handled
with the help of the do statements.
Syntax:
do
{
Body of the loop
}
while (test condition );
On reaching the do statement, the program proceeds to evaluate the

body of the loop first. At the end of the loop, the test condition in the
while statement is evaluated. If the condition is true, the program
continues to evaluate the body of the loop once again. This process
continues as long as the condition is true.
Example:
do
{
cout<<INPUT A NUMBER\n;
number = getnum();
}
while (number > 0);
This segment of program reads a number from the keyboard until a zero
or a negative number is keyed in, and assigned to the sentinel variable
number.
BREAKING CONTROL STATEMENTS:
BREAK STATEMENT:
When a break statement is encountered inside a loop, the loop is
immediately exited and the program continues with the statement
immediately following the loop. When the loops are nested, the break
would only exit from the loop containing it. That is, the loop will exit only
a single loop.
1.
while ( )
2.
do
{
.
..
if ( condition )
if( condition
break;
break;
3.
...
}while ( .. );
for ( . )
4.
for ( . )
{
.
if ( error )
for ( )
break;
if( condition
...
break;
.
}
.
}
GOTO STATEMENT:
Since a goto statement can transfer the control to any place in a
program, it is useful to provide branching within a loop. Another
important use of goto is to exit from deeply nested loops when an error
occurs. A simple break statement would not work here.
UNCONDITIONAL GOTO:
The unconditional goto is used to transfer the control from
one part of the program to the other part of the without checking any
condition.
Consider,
#include<iostream.h>
{
start:
cout<<MY NAME IS SWERISH\n;
goto start;
CONDITIONAL GOTO:
The conditional goto is used to transfer the control of the
execution from one part of the program to the other in conditional cases.
1.
while ( )
2.
for ( .. )
if ( error )
goto stop;
for ( )
if ( condition )
..
goto abc;
if ( error )
goto error;
abc:
..
stop:
error:
CONTINUE STATEMENT:
During the loop operation, it may be necessary to skip a part of the
body of the loop under certain conditions. However, unlike the break
which causes the loop to be terminated, the continue, as the name
implies, causes the loop to be continued with the next iteration after
skipping any statements in between continue statement and closing
braces.
1.
while ( test condition )

{
2.
do
{
if ( )
if ( .. )
continue;
continue;
}
while ( test condition );
3.
for ( . )
{
.
if ( .. )
continue;
.
}
CONTROL STRUCTURE
Two way branch
Multiple branch
Entry SELECTION
control
IF ELSE
Exit control
SEQUENCE
SWITCH
LOOP
DO-WHILE
WHILE, FOR
POINTERS
A pointer is a variable which holds the memory address of another
variable. In terms of pointer, only complex data type can be declared and
accessed easily.
ADVANTAGES
1. It
allows
passing
variables,
arrays,
functions,
strings
and
structures as function arguments.

2. A pointer allows returning structured variables from functions.
3. It provides functions which can modify their calling arguments.
4. It supports dynamic allocation and de allocation of memory
segment.
5. With the help of a pointer, variables can be swapped without
physically moving them.
6. It improves the efficiency of certain routines.
A pointer variable consists of two parts.
1. The pointer operator

2. The address operator
POINTER OPERATOR
It can be represented by a combination of * with a variable.
Eg: int *ptr;
ptr -> pointer variable which holds the address of an integer data type.
Format:
Data type *ptr variable;

where,
data type type of pointer variable such as integer, character and
floating point number variable.
Eg: float * fpointer;

Double *dpoint;
ADDRESS OPERATOR
An address operator can be represented by a combination of &

with a pointer variable.
& -> is a unary operator that returns the memory address of its operand.
A unary operator requires only one operand.
Eg:
m=&ptr;
m receives the address of ptr.
POINTER EXPRESSIONS
Pointer assignment:
A pointer is a variable datatype and hence the general rule to

assign its value to the pointer is same as that of any other variable
datatype.
Eg:
int x,y;
int *ptr1,*ptr2;
ptr1=&x;
y=*ptr1;
A PROGRAM TO ASSIGN A CHARACTER VARIBLE TO THE POINTER

AND TO DISPLAY ITS CONTENTS
void main()
{
char x,y;
char *ptr;
x=c;
ptr=&x;
y=*ptr;
cout<<x;
cout<<y;
}
POINTERS TO FUNCTIONS
C++ allows functions to be referenced by a pointer. A pointer to a

function must be declared to be a pointer to the datatype returned by the
functions like void,int,float and so on. In addition,the argument type of
the function must also be specified when the pointer is declared.
General syntax of a pointer to a function is ,
return_type (*variable) (list of parameters);

Eg:
void (*ptr) (float,float,int);
In the above declaration a pointer to a function returns void and takes

the formal arguments of two float and one int.
A PROGRAM TO FIND THE SUM OF THREE NUMBERS USING A

POINTER TO FUNCTION METHOD
void main()
{
float average(float,float,float); //function declaration
float a,b,c,avg;
float (*ptrf) (float,float,float); //pointer to function declaration
ptrf=&average;
cout<<enter three numbers;
cin>>a>>b>>c;
avg=(*ptrf) (a,b,c); //function calling using pointer
cout<<a= <<a;
cout<<endl<<b= <<b;
cout<<endl<<c= <<c;
}
float average (float x,float y,float z)
{
float temp;
temp=(x+y+z)/3.0;
return (temp);
}
PASSING FUNCTION AS ARGUMENTS
C++ allows a pointer to pass one function to another as an

argument.
Syntax:
return_type function_name(pointer_to_function (other arguments));
Eg: float calculation(float(*)(float,float),float,float);

where,
the function calculation returns a type float and takes the
formal arguments of a pointer to another function and two other float
types. As a pointer to function declaration itself is a pointer data,it
returns a type float and takes the formal argument of two floating point
values.
A PROGRAM TO DEMONSTRATE HOW A FUNCTION CAN BE PASSED

TO ANOTHER FUNCTION AS A FORMAL ARGUMENT
void main()
{
float add(float,float); //function declaration
float sub(float,float);
float action(float(*)(float,float), float,float);
float (*ptrf)(float,float);//pointer to function declaration
float a,b,value;
char ch;
cout<<Enter any two numbers;
cin>>a>>b;
cout<<a->addition;
cout<<s->subtraction;
cout<<Entet your option;
cin>>ch;
if(ch= =a)
ptrf=&add;
else
ptrf=⊂
cout<<a=<<a;
cout<<b=<<b;
value=action(ptrf,a,b);
cout<<answer=<<value;
}
float add(float x,float y)
{
float ans;
ans=x+y;
return(ans);
}
float sub(float x,float y)
{
float ans;
ans=x-y;
return(ans);
}
float action(float (*ptrf) (float,float),float x,float y);
{
float answer;
answer=(*ptrf)(x,y);
return(answer);
}
POINTERS AND ARRAYS
Pointers and one dimensional array:
In C++ pointers and one dimensional arrays have a close relationship.

Consider the following valid declaration:
datatype array_name[size];
datatype ptr_variable;
Eg:
int value[20];
int *ptr;
ptr=&value[0];
.
.
ptr=&value[n];
value[i]=*((value)+(i));
It can also be given as
value[i]=*(&(value)[10] + (i));
PROGRAM TO DISPLAY CONTENTS OF AN ARRAY USING POINTER

TECHNIQUE
void main()
{
int a[4]={11,12,13,14};
int i,n,temp;
n=4;
cout<<Contents of the array:;
for(i=0;i<n;i++)
{
temp=*((a)+(i));
cout<<Value=<<temp;
}
}
Pointer and multi-dimensional arrays:
A pointer to an array contains the address of the first element. In an

one dimensional array, the first element is &[0]. In a two dimensional
array it is,
&value[0][0]
It can be represented as follows:
int name[10][10];
int *ptr;
ptr=&name[0][0];
.
.
ptr=&name[10][10];
PROGRAM TO DISPLAY CONTENTS OF A TWO DIMENSIONAL ARRAY

USING POINTER TECHNIQUE
void main()
{
int a[2][3]={11,12,13,14,15,16};
int i,n,temp,j,m;
int *ptr;
n=2;
m=3;
cout<<Contents of the array:;
for(i=0;i<n;i++)
{
for(j=0;j<m;j++)
{
temp=*(*(a+i)+(j));
cout<<Value=<<temp;
}
}
}
POINTER AND STRINGS
Strings are one dimensional arrays of type char. It is terminated by

\0. They are written in double quotes.
Many string operations such as string length, string compare, string
copy, string concatenate are performed using pointer method.
Eg:
char a[4];
a=Good;
The output is Goo
Since in every string last character is a null character.
To get the string:

Syntax:
cin.get(a,4);
PROGRAM TO READ THE STRING FROM THE STDIN AND TO DISPLAY

IT IN THE MONITOR
#define MAX 50
void main()
{
char s[MAX];
void output(char *s);
cout<<Enter the string:;
cin.get(s,MAX);
cout<<OUTPUT;
output(s);
}
void output(char *ptr)
{
while(*ptr!=\0)
{
cout<<*ptr;
ptr++;
}
}
ARRAY OF POINTERS
Pointers may be array like any other datatype. The declaration for an
integer pointer array of size 10 is :
int *ptr[10];
makes
ptr[0],ptr[1]ptr[9]
PROGRAM TO DISPLAY THE CONTENTS OF POINTERS USING AN

ARRAY OF POINTERS
void main(void)
{
char *ptr[2];
ptr[0]=Rajiv;
ptr[1]=Arun;
cout<<Contents of pointer1=<<ptr[0];
cout<<Contents of pointer2=<<ptr[1];
}
POINTERS TO OBJECTS
Consider a class student. Let its object be s.

Eg:
student s;
student *ptr;
Here *ptr is the pointer to the object s.

If get() is a member function of this class, then it can be accessed by the
pointer.
(*ptr).get();
There is another case where the object is created as a pointer.
Eg:
student *s;
Now the member function, get() can be accessed by,

s -> get();
POINTER ARITHMETIC
Pointer arithmetic
ptr++
Description
ptr=ptr+size of datatype
Use original value of ptr and then ptr is incremented
++ptr
after statement execution.

ptr=ptr+size of datatype
Original pointer is incremented before execution of
ptr--
this statement.
ptr=ptr-size of datatype
Use
--ptr
original
value
of
ptr
and
then
ptr
is
decremented after statement execution.

ptr=ptr-size of datatype.
Original ptr is decremented before the execution of
*(ptr++)
the statement.
*(ptr++).
Retrieve the content of the location pointed to by the
*(++ptr)
pointer and then increment the pointer.

*(++ptr)
Increment the pointer and then retrieve the content
(*ptr)++
of the new location pointed to by the pointer.

(*ptr)++
Increment the content of the location pointed to by
the pointer. For pointer type content use pointer
++(*ptr)
arithmetic else standard arithmetic

++(*ptr)
Increment the content of the location pointed to by
--(*ptr)
the pointer depending on the type of the content.

--(*ptr)
Decrement content of the location pointed to by the
*(ptr--)
pointer depending on the type of the content

*(ptr--)
Retrieve the content of the location pointed by the
*(--ptr)
pointer and then decrement the pointer.

*(--ptr)
Decrement the pointer and then retrieve the content
(*ptr)--
of the new location pointed to by the pointer.

(*ptr)
Retrieve the content *ptr of the location pointed to
by the pointer, then decrement the content of that
location. Pointer is not changed.
ARRAYS
An array is a collection of identical data objects which are stored in

consecutive memory location under a common variable name.
ARRAY DECLARATION:
Syntax:
Datatype arrayname [size of the array];
Datatype specifies the type of data that the array can hold.
Arrayname can be any variable name. The size of the array specifies how
many data items the array can hold and it should be a constant or an
expression that evaluates to a constant.
E.g.: int a[100];
ARRAY INITIALIZATION:
The items in an array is known as array elements .Assigning

values to array elements is referred as array initialization.
SYNTAX:
Datatype arrayname [size] = { element 1,
Element 2.. element
n};
Eg:
int a[5] = { 1,4,7,10,12 };
a [0] = 1 , a [1] = 4 , a [2] = 7 , a [3] = 10 , a [4] = 12.
PROCESSING WITH ARRAY:
In processing an array consider a program to initialize a set of numbers

in the array ant to display it .
void main()
{
int a[7]= { 2,5,6,8,9,10,11 };
int i;
for(i=0;i<7;i++)
cout<<a[i];
}
ARRAYS AND FUNCTIONS:

The entire array can passed to functions.
An array name can be used as an argument in function declaration.
FUNCTION DECLARATION WITH ARRAY AS ARGUMENTS:
In function declaration,array arguments are represented by

the datatype and sizes of the array.
Eg : void sum(int a[ ], int n);
FUNCTION CALL WITH ARRAY AS ARGUMENTS:
When function is called only the array is used as an

arguments.
The size of the array should not be specified.
Eg: sum(a,n);
FUNCTION DEFINITION WITH ARRAY AS ARGUMENTS:
The array argument uses the datatype as name and the sizes
of the dimensions . All the array dimensions must be specified.
Eg : void sum(int x[ ],int max)
MULTI DIMENSIONAL ARRAY:

Array
with
more
than
one
subscripts are known as multi dimensional array.a two dimensional

array will require two pairs of subscript and three dimensional array will
have three pairs of subscripts.
Syntax:
datatype arrayname [subscript 1][subscript 2];
Eg: int a[10][10];

It holds 10 rows and 10 columns.
Multidimensional array initialization is similar to one dimensional array

initialization.
CHARACTRER ARRAY:
It is a group of characters or strings that can be
declared with array name.
Syntax :
Datatype arrayname [size of array ];
Eg: char name [10];

Here name is the user defined name or variable name and 10 is the size
of the array.
INITIALIZING THE CHARACTER ARRAY:

Arrays are initialized in the following way
Syntax: datatype array name[size]=strings;
Eg: char name[7]= hello ;

And always character of array is ended with null
character.
Consider the following example which explains how to initialize a set of

characters and to display them.
void main()
{
int i;
char name[6]={ h,e,l,l,o};
for(i=0;i<=5;i++)
cout<<Name<<name[i];
}
STRUCTURES
Its a collection of hetrogenous datatype that can be grouped to form a
structure.so the entire collection can be referred to by a structure name.
structure
can
be
graphically
represented
as
name
member 1
member 2
member 3
member n
given
SYNTAX:
struct username/structure name
{
member 1; --> variables
member 2;
member 3;
.
.
member n;
};
ASSIGNING VALUES TO A MEMBERS:
tagname.variable name=value;
eg. Today.day=10;
CREATING TAG NAME:

Structure name tagname;
Eg:student s1;
ACESS TO THE TAGNAME:

tagnam.variable
eg: a1.a=0;
For example now consider a program to assign some values to the

member of a structure and to display them
#include<conio.h>
void main()
{
struct sample
{
int x;
float y;
};
struct sample a;
a.x=10;
a.y=20.0;
cout<<a.x<<a.y;
}
INITIALIZATION OF A STRUCTURE:
Syntax:
structurename tagname= { values };
eg: school student = { 20, ram, ramu};
For example now consider a program to initialize the members of a

structure and to display the contents of the structure
void main()
{
struct name
{
int roll no;
int age;
char sex;
float weight;
};
school student={130,19,F,50};
cout<<Rollno:<<student.rollno;
cout<<Age<<student.sge;
cout<<sex:<<student.sex;
cout<<weight<<student.weight;
}
ARRAYS WITHIN A STRUCTURE:
It is used for fetching more than one detail.
Syntax:
Structure name tagname[size]={values};

Eg :
struct school
{
int age;
int salary:
};
school student [5] = { 10,10000,

20,15000,
30,20000,
40,25000,
50,30000};
here the c++ compiler will assign the values to its members of a structure
as
student[0].age=10;
student[0].salary=10000;
student[1].age=20;
student[1].salary=15000;
FUNCTIONS:
A complex problem may be decomposed into a small or easily
manageable parts or modules called functions. Functions are useful to
read, write, debug and modify complex programs.
ADVANTAGES OF FUNCTIONS:
1.Easy to write a correct small function .

2.Easy to read, write and debug a function.
3.Easier to maintain / modify such a function.
4.Small function tend to be self documenting and highly readable.

5.It can be called any number of times in any place with different
parameter.
It has 3 important objectives

1.Function declaration.
2.Function calling.
3.Function definition.
SYNTAX FOR FUNCTION DECLARATION;
Return_type function name(datatype with arg1, datatype with arg2);
e.g.
add(int a, int b);
SYNTAX FOR FUNCTION CALLING:
Function name ( argument/variables);
Eg:
add(a,b);
SYNTAX FOR FUNCTION DEFINITION:
return type function name(datatype with arg1,datatype with arg2)
Eg:
int add(int a,int b)
ACTUAL ARGUMENTS/ACTUAL PARAMETERS:
The values which can be passed from main to function is

called actual argument.
(ie) function name(argument)
eg:
add(a,b);
a and b are called actual arguments.
FORMAL ARGUMENTS / FORMAL PARAMETERS:
The values which can be accessed inside the function are

called formal parameters.
Eg:
void add( int a,int b)

{
c=a+b;
}
here a and b are called formal arguments.
LOCAL VARIABLES:
Identifier declared as label , constant , type , variables and

functions in a block are said to belong to a particular block or operation.
GLOBAL VARIABLES:
Global variables are variables defined outside the main function

block.these variables are referred by the same datatype and by name
through out the program in both the calling portion of a program and in
the function block.
RECURSIVE FUNCTION:
A function calls itself directly or indirectly again and again is

known as recursive function.
(1) THE MAIN FUNCTION:

IN C++ the main function always returns
a value
And hence return type should be specified.
The function have a return value should use the
return statement for termination.the main function in c++ is defined as
void main( )
{
-----------return( 0);
}
Most c++ compilers would generate an error or warning if there is no
return statement.
FUNCTION PROTOTYPING:
Function
prototype
is
declaration
statement
Syntax:
Datatype function name(argument list)
The prototype describes the function interface to the

compilers by giving details such as the number and types of arguments
and type of return values with function prototyping a template is always
used when declaring and defining a function.
When a function is called, the compiler uses the
template to ensure that proper arguments are passed and then return
value is treated correctly.any violation in matching the arguments on the
return types will be caught by compiler at the time of compilation itself.
Eg: float valume(int x,float y,float z)
CALL BY VALUE:
In the function call if we are using the name of
the variable then it is called as call by value method.
CALL BY REFERENCE:
When we pass arguments by reference ,
the formal arguments in the function called aliases to the actual
arguments in the calling function. This means that when the function is
working with is own arguments it is actually working on the original
data.
Consider the following example
void swap( int *a,int *b)

{
int t;
t=*a;
*a=*b;
*b=t;
}
RETURN BY REFERENCE:
A function can also return a reference
value. Consider the following example
int &max(int &x,int &y)

{
if ( x>y )
return x;
else
return y;
}
since the return tyoe of max() is int & , the function returns the reference
to x and y and not the values.
The function call such as max(a,b) will yield a reference to either a or b

depending on their values. This means that this function call can appear
on the left handside of an assingnment statement.
(ie) max(a,b)=-1;
INLINE FUNCTION:
An inline function are defined as follows
inline function header

{
function body
}
eg : inline double cube ( double a )

{
return ( a*a*a);
}
the above inline function can be invoked by statements like
c=cube ( 3.0 );
d= cube ( 2.5+1.5);
On the execution of these statements the values of c and d will be

27 and 64 respectively . if the arguments are expressions such as
2.5+1.5 the function passes the value of the expression 4 in this case.
It is very easy to make a function inline. All we need to do is to

prefix the keyword inline to the function definition .all inline function
should be defined before they are called.
Some of the situations where inline expansions
may not work are
1. For function returning values , if a loop ,a switch statement or a
goto statement exists.
2. if a function contain satic variable.
3. if inline functions are recursive.
NOTE:
when any of the constraint is violated then the compiler will
ignore the keyword inline and it will make the function as normal
function.
DEFAULT ARGUMENT:
Default values are specified where the
function is declared .
Eg: float awt ( float p,int period , float r=0.15 );
A default argument is checked for type at the time of

declaration and evaluated at the time of call . one important point is
only the trailing arguments can have default value. That is we must add
default from right to left . we
cannot provide a default value to a
particular argument in the middle of an argument list.
Eg
int mul ( int I, int j=5 , int k=10 ); // legal
int mul ( int i=5 , int j ) ; // illegal

int mul ( int i=0 , int j , int k =10); //illegal
Adavantages of providing the default arguments are
1. we can use default arguments to add new parameters to the

existing functions.
2. Default arguments can be used to combine similar function into
one.
FUNCTION OVERLOADING:
Overloading refers to the use of the same
thing for different purpose . c++ allows function overloading. This means
we can use same function name to create functions that perform
different tasks. This is known as function overloading.
Using this concept we can design a family
of function with one function name but with different argument list. The
function would perform different operations depending on the argument
list in the function call.
The function that is to be invoked is determined by checking the
number and types of arguments but not the function type. The function
selction involves the following steps.
1. The compiler first tries to find an exact match in which the types of
actual arguments are the same and use that function.
2. If an exact match is not found ,the compiler uses the integral

promotions to the actual arguments such as,
char to int
float to double
3.when either of them fails ,the
compiler tries to use the built in
conversion to the actual arguments and then uses the function whose
match is unique. If the conversion is possible to have multiple matches,
then the compiler will generate an error message. For example
long square ( long n )
double square ( double x )
when the function call is square(10);
It will cause an error because int argument can be converted to either
long or double , thereby creating an ambiguous situation as to which
version of square() should be used.
3. If all steps fails then user defined conversions is done and it is a
combination with integral promotions and built in conversions.
Eg :
Function declarations
int add ( int a, int b);
//prototype 1
int add ( int a, int b , int c );
//prototype 2
double
add
(double
x,double
);
//prototype 3
double add (int p,double q ); //prototype
4
Function calls
cout<<add(5,10)
1
//prototype
cout<<add(15,10.0);
//prototype 2
cout<<add(12.5,6.5);
cout<<add(5,10.1);
//prototype 3
//prototype4
FRIEND FUNCTION:
The main concepts of oop are data hiding and
data encapsulation. That is we are declaring variables in private part of a
class. So these members are restricted from accessing by non member
functions of the class. If any of the non member functions tries ti access
the members of the class , then a error messege is displayed .so for a non
member functions to have access to the members of the class they
should be declared in the public area which violates the data hiding and
encapsulation.
So the best way to access a private data member by a
non member functions is to declare a friend function to have access to
these data members.
Friend function:
It is a special mechanism of giving or granting
permission to non member functions to have access to private data.
A friend function may be either declared or defined

within the scope of a class definition. The keyword friend informs the
compiler that the function is not a member function of the clas
Syntax:
friend return type function name ( parameters );
NOTE:
1. friend function can be declared either in the private part or in the
public part of a class.
2.The keyword friend should be specified only in the function
declaration and it should not be specified in the function definition.
Ex:
Friend function disp() is declared in the public part
class first
{
private:
int x;
public:
void get();
friend void disp();
};
the friend function disp() is declared in the private part of the class.
class second
{
private:
int x;
friend void disp();

public:
void getdata();
};
1. Accessing private data by non member functions through friend:

The friend function is a special type of function which is used
to access the private data of any class.(ie) friend fuctions are non
member functions
With the abiliry to manipulate data members or the call functions
member functions that are not part of the public interface.
The friend function has the right to access all the members
of the class. Each time time when a friend function access the data , the
level of privacy of data encapsulation gets reduced. Only if it is necessary
to access the private data by non member functions then a class may
have a friend function otherwise it is not necessary.
Example:
class sample
{
private:
int x;
public:
void get();
friend void disp(class sample);
};
void sample :: get()
{
cout<Enter the value for x;
cin>>x;
}
void disp(class sample abc)
{
cout<Entered numbers are<<abc.x;
cout<<end l;
}
void main()
{
sample obj;
obj.get();
cout<<Accessing the private data by non member function;
}
2.Friend function with inline substitution:
A friend function may also be made up of inline function. If the

friend function is defined with the scope of class then there is noneed of
inline substitution. If the friend function is defined outside he class then
in the place of definition the keyword inline should precede in order to
make a inline substitution.
3.Granting friendship to another friend class:
A class can have friendship with another class.

Example:
Consider two classes first and second. If class first grants its friendship
to class econd then the privaye data members of class
First are permitted to be accessed by the public members of class
second. But the public members of class first cannot access private
members of class second.
class first
//Friend class
{
friend class econd;
private:
int x;
public:
void get();
};
class second
{
public:
void disp( first temp);
};
inline void first ::getdata()
{
cout<<Enter a number;
cin>>x;
}
inline void second :: disp( class first temp)
{
cout<<Entered numbers are :<<temp.x;
cout<<endl;
}
void main()
{
first objx;
second objy;
objx.get();
objy.disp(objx);
}
4.Tow classes having the same friend:

Friend function acting as a bridge:
A non member function may have
friendship with more the one class. When a function has declared to have
friendship with more than one class the friend class should have forward
declaration. This means that the friend function needs to access the
members of both the class.
Syntax for declaring friend function with more than one class:
class first
{
private:
-----------public:
friend return type fname (class first , class second);
};
class second
{
private:
-----------public:
};
CLASSES:
A class is a collection of objects of similar type. That is it is a
collection of variables of different datatypes and the functions that act on
them into a single entity. Once a class has been defined we can create
any number of objects belonging to that class. And using these objects
we can access the class.
The syntax for creation of objects is:

Class_name object;
For example, mango, apple and orange are the members of a class Fruit.
Now the object mango can be created as:
Fruit mango;
CLASSES:
*The most important feature of C++ is the class.
*They are similar to the structures used in C with some additional
features.
*It is a new way of creating and implanting a user_defined data type.
DEFINITION
*A class is a user defined data type,which holds both the data and
functions.
*The internal data of a class is called member data or data member.
*The functions are called member functions.
SPECIFYING A CLASS
*When defining a class, we are creating a new abstract data type ,that
can be treated
like any other any other built_in data type.
*A class specification has two parts,namely,
i)Class declaration
ii)Class function definition
CLASS DECLARATION
*It is better to declare,
*Members in private part.
*Member functions in public part.
*In classes variables that are declared, are by default private.
GENERAL FORM
Class class_name
{
Private:
Variable declarations;
Public:
Function declarations;
Protected:
Data_type operations;
Implementation operations;
};
PRIVATE
*The class members that have been declared private can be accessed
only from within the class.
*(ie)Only by the member functions and friend functions of the class.
*The private data member is not accessible to the outside class.
PUBLIC:
*The members which are declared in the public section can be accessed
by any function outside the class.
*The member functions can also be accessed outside the class.
*The public implemented operations are also be called as member
functions or methods or interfaces to out of the class.
*The public data members can always read and write outside the class.
PROTECTED
*The members which are declared in the protected part,can only be
accessed by the member functions and friend functions of the class.
*This is applicable only in inheritance situation.
EXAMPLE :For a class

Class student
{
Private:
int roll no;
char sex;
float height;
float weight;
public:
void getinfo(); //member function
void disinfo(); //member function
};
OBJECTS:
*It is an instance of class.
*It is similar to variables.
*We can declare variables in the same way as buil_in type.
DECLARING VARIABLES
*A variable can be declared as follows:
SYNTAX
class name/userdefined name object name
Eg:
Class student
{
.
.
.
.
};
Student s1,s2,s3;
*In this above example,student is a class,in which s1,s2,s3 are the
objects that are created.
ACCESSING CLASS MEMBERS

*The members can be accessed by using object and dot operator.
SYNTAX
Object_name.function_name()
Eg:
*Consider a class student,with a data member s1 and member function
add.
Then,we can access the class by,
S1.add();
*Members can be accessed by using,
i)getdata
ii)putdata
Eg:
*Consider a class student with an object s.
*The accessing can be done by,
s.getdata();
s.putdata();
*s.putdata() sends a message to the object s,requesting it to display its
contents.
EXAMPLE PROGRAM:(to assign data to data members)

*A program to assign data to data members of a class such as
day,month,year and to display the contents of the class.
void main()
{
class date
{
public:
int day;
int month;
int year;
};
class date today;
today.day=10;
today.month=1;
today.year=2007;
cout<<today.day<<today.month<<today.year;
}
MEMBER FUNCTION DEFINITION

*It can be done in two ways,namely,
i)outside class definition

ii)inside class definition
OUTSIDE CLASS DEFINITION
GENERAL FORM
return_ type class_name::function_name(actual arguments)
{
function_code;
}
*The symbol ::is referred as resolution operator or scope resolution
operator.
*The class name along with resolution operator((ie)class_name::) is
known as membership label.
*The
membership
label
tells
the
compiler
that
the
function_name belongs to the class class_name.

*(ie)The scope of the function is restricted to the class name.
EXAMPLE:
*A program to add two numbers using classes and objects.
#include<conio.h>
class addition
{
private:
int a,b,c;
public:
void add();
void display();
function
};
void addition::add()
{
cin>>a>>b;
c=a+b;
}
void additin::display()
{
cout<<c;
}
void main()
{
addition a1;
a1.add();
a1.display();
}
INSIDE CLASS DEFINITION

*When a function is defined inside a class,it is treated as an inline
function.
*Generally,only small functions are defined inside the class.
EXAMPLE
*A program to add two numbers.
#include<conio.h>
class addition
{
public:
int a,b,c;
void add()
{
cin>>a>>b;
c=a+b;
}
void display()
{
cout<<c;
}
};
void main()
{
addition a1;
a1.add();
a1.display();
}
NESTING OF MEMBER FUNCTION

*A member function can be called without using object and dot operator.
*(ie)A member function can be called by using its name inside another
member function of the same class.This is called nesting of member
functions.
EXAMPLE
class ABC
{
int n,m;
public:
largest();
get();
display();
};
get()
{
cin>>n>>m;
}
largest()
{
int large;
if(n>m)
large=n;
else
large=m;
cout<<largest<<large;
}
display()
{
largest();
}
main()
{
ABC a;
a.get();
a.display();
}
ARRAYS OF OBJECTS
*If there are many objects,then we can use arrays of objects.
*An array is an user defined data type,whose members are of the same
type and stored in continous memory locations.
SYNTAX
*The general form is,
class user_defined name
{
private:
//data members;
public:
//member functions();
};
class user_defined name object[max];
*In this example,MAX is a user_defined size of the array of classes
*The following are the various types of declaration of an array of objects
i)const int max=100
class employee
{
private:
public:
...
.
};
Class employee obj[max];
*In this example,the class employee has been declared as an object of
size 100.
ii)class library
{
private:
public:
..
..
}object[100];
*Here, we have declared the array of objects in the class definition itself.
iii)A classs can be declared without defining a user_defined name in the
class tag.
class
{
private:
.
public:
..
.
}library[100];
*Here library is an object of the class,without tag name ,whose size is

100.
E XAMPLE PROGRAM
*A
program
to
read
students
particulars
rollno,age,sex,height,weight and to display the contents.

#include<conio.h>
const int max=100;
class student
{
private:
long int rollno;
int age;
char sex;
float height;
float weight;
public:
void getinfo();
{
cin>>rollno;
cin>>age;
cin>>sex;
cin>>height;
cin>>weight;
}
void disinfo()
such
as
{
cout<<rollno;
cout<<age;
cout<<sex;
cout<<height;
cout<<weight;
}
};
void main()
{
student object[max]; //array of objects
int n;
cin>>n;
for(i=0;i<n;i++)
{
int j=i;
cout<<j+1;Object[i].getinfo();
}
cout<<contents of class;
for(i=0;i<n;i++)
{
object[i].disinfo();
}
}
POINTERS AND CLASSES
*A pointer is a variable which holds the address of another variable of

any basic data types such as int,float,etc.
Eg:
class sample
{
private:
int x;
float y;
char s;
public:
void getdata(();
void display();
};
sample *ptr;
*In this example,ptr is a pointer variablethat holds the address of the
class object sample.
*It consists of three data members such as int x,float y,char s and also
holds the member functions such as getdata() and display().
DECLARATIONS
*It can be done in two ways:
i)
class student
{
private:
public:
.
.
};
void main()
{
student *ptr;
.
.
(*ptr).data member;
(*ptr).member function();
}
ii)
class student
{
private:
.
public:
..
..
};
void main()
{
student *ptr;
ptr->data member;
ptr->member_function();
}
ACCESSING POINTERS
*The pointer to an object of a class will be accessed and processed in one
of the following ways:
i)(object name).member name=variable
*Here the parenthesis are essential,since,the member of class period (.)
has a higher precedence over the indirecton operator(*).
ii)object name->member name =variable;
EXAMPLE PROGRAM
*A program to assign some values to the member of claa objects using a
pointer operator,
->
#include<conio.h>
class student
{
private:
long int rollno;
int age;
char sex;
float height;
float weight;
public:
void getinfo();
void disinfo();
};
void student::getinfo()
{
cin>>rollno;
cin>>age;
cin>>sex;
cin>>height;
cin>weight;
}
void student::disinfo()
{
cout<<rollno;
cout<<age;
cout<<sex;
cout<<height;
cout<<weight;
}
void main()
{
student *ptr;
ptr->getinfo();
ptr->disinfo();
}
EXAMPLE PROGRAM
A program to assign values to member of class objects using an indirect

operator.
#include<conio.h>
class student
{
private:
long int rollno;
int age;
char sex;
float height;
float weight;
public:
void getinfo();
void disinfo();
};
void student::getinfo()
{
cin>>rollno>>age>>sex>>height>>weight;
}
void student::disinfo()
{
cout<<rollno<<age<<sex<<height<<weight;
}
void main()
{
student *ptr;
(*ptr).getinfo();
(*ptr).disinfo();
}
CLASSES WITHIN CLASSES

(Nested classes)
*A class declared as a member of another class is called as nested class
or a class within class.
*A class within a class is declared in the public part.
*The class which is inside is called is called inner class or enclosed class
or nested class.
*The outer class which contains the definition of another class is called
outer class or enclosing class
.
SYNTAX
class outerclass name
{
private:
//data
public:
//methods
class innerclass name
{
private:
//dataof inner class;
}; //end of inner class
}; //end of outer class
OBJECT FOR INNER AND OUTER CLASS

GENERAL FORM
Outer classname object1;
Outer classname::inner classname object2;
Eg:
class ABC
{
..
..
public:
ABC1();
ABC2();
class XYZ
{
.
.
public:
XYZ1();
XYZ2();
};
};
*In this example,

*ABC-outer class
*XYZ-inner class
*The class XYZ is within the scope of ABC.

*The XYZ1 member function is defined as,
Void ABC::XYZ::XYZ1()
EXAMPLE PROGRAM
*A program to define a nested class student,which contains data
members such as name,rollno,sex and consists of one more class
data,whose data members are day,month and year.
#include<string.h>
class student_info
{
private:
char name[20];
int rollno;
char sex;
public:
student_info(char *no,int rn,char sx);
void display();
class date
{
private:
int day;
int month;
int year;
public:
date(int dy,int mh,int yr);
void show_date();
}:
};
student info::student_info(char *no,int rn,char sx)

{
strcpy(name,no);
rollno=rn;
sex=sx;
}
student_info::data(int dy,int mh,int yr)
{
day=dy;
month=mh;
year=yr;
}
void student_info::display()
{
cout<<name;
cout<<rollno;
cout<<sex;
}
void student_info::date::show_date()
{
cout<<day<<month<<year;
}
void main()
{
student_info obj1(abc,1000,m);
student_info::date obj2(13,7,94);
obj1.display();
obj2.show_date();
}
CONSTRUCTORS:
A constructor is a special member function whose task is to
initialize the objects of its class. Whenever an object is created, the
constructor will be executed automatically. A constructor is different
from all the other member functions of a class because it is used to
initialize the objects of the class.
a constructor is special because its name is the same name as that

of the class.
The constructor is invoked whenever an object of its associated

class is created.
The constructor is given the name constructor because it is used

to conmstruct the values of the data members of the class.
Syntax:
The general syntax of a constructor in C++
class user_name
{
private :
..
..
protected:
..
..
public:
user_name(); //constructor declaration
};
user_name::user_name()
//constructor definition
{
..
.
..
}
Examples:
class employee
{
private:
char name[20];
int ecode;
char address[20];
public:
employee();
//constructor
void getdata();
void display();
};
employee::employee() //constructor definition
}
In the class employee, it contains a constructor. The name of the
constructor is the same as the name of the class, so the name of the
constructor here is also employee.
Now, if we create an object for the class employee, it will be
initialized automatically.
For example ,the declaration
employee e1; //object e1 is created.
This statement not only creates the object e1 of type employee but
also initializes the data members.
There is no need to invoke a constructor like other member
functions of the class.
Default constructor:
A constructor that accepts no parametersis called the
default constructor.
The default for this
class abc
The default constructor for this class is

abc::abc()
If such a constructor is not defined, then the compiler to create the
object a.
Some special characteristics of constructor functions:
1. a constructor should be declared in the public section of the class.

2. they are invoked automatically when the object is created.
3. they do not have return types not even void therefore cannot return
any values
4. they cannot be inherited, though a derived class can call the base
class constructor.
5. like
other
C++
functions,
constructor
can
have
default
arguments.
6. constructors cannot be virtual.
7. we cannot refer to their addresses.
8. an object with a constructor (destructor) cannot be used as a
member of a union.
9. they make implicit calls to the operators new and delete when
memory allocation is required.
Eg. for constructors

A program to display a series of Fibonacci numbers using the
constructor member function has been defined out of the class definition
using the scope resolution operator.
#include<conio.h>
class Fibonacci
{
private:
unsigned long int f0,f1,fib;
public:
Fibonacci();
//constructor
void increment();
void display();
};
Fibonacci::Fibonacci()
{
f0=f1;
f1=fib;
fib=f0+f1;
}
void fibonacci :: display()
{
cout<<fib<<\t;
}
void main()
{
fibonacci number;
for(int i=0;i<=15;i++)
{
number.display();
number.increment();
}
}
Parameterized constructor:
//constructor
Consider the example

class integer
{
int m,n
public:
integer (void);
//constructor declared
};
integer :: integer(void)
//constructor definition
{
m=0;n=0;
}
when objects are declared or created for the class integer, the
constructor initializes all the objects to zero.
Sometimes it may be necessary to initialize various data elements

of different values when they are created.
This can be achieved by passing arguments to the constructor
function when the objects are created. The constructors that can take
the arguments are called parameterized constructors.
Consider the example above, the integer example the constructor
integer () can be modified to take arguments as:
Class integer
{
int m,n;
public:
integer(int x, int y);
//parameterized
constructor
};
integer::integer(int x, int y)
{
m=x;
n=y;
}
Now the constructor integer (), is parameterized.
Now the object declaration,

Integer i1; -this will not work because, it
is necessary to pass initial values as arguments to the constructor
function when an object is declared.
This can be done in two ways:

1. by calling the constructor explicitly.
2. by calling the constructor implicitly.
Calling the constructor implicitly:

integer i1(0,100);
//implicit
call.
This method is used often.
When a constructor is parameterized, we must provide appropriate
arguments for the constructor.
//program to demonstrate the passing of arguments to constructor

functions.
class integer
{
int m,n;
public:
integer (int, int);
//constructor declared
void display()
{
cout<<m= <<m;
cout<<n= <<n;
}
};
integer :: integer (int x, int y)
//constructor defined
{
m=x;
n=y;
}
void main()
{
integer i1(0,100); //implicit call
integer i2=integer(25,75);
cout<<object;
i1.display();
cout<<object2;
//explicit call
i2.display();
}
Output of the program:

Object1
m=0
n=100
object2
m=25
n=75
*the constructor functions can also be defined as inline functions.
Eg.:In the above program, the constructor functions can be defined

within the class as inline function.
class integer
{
int m, n;
public:
integer(int x, int y)//inline constructor
{
m=x;
y=n;
}
};
Note:
1. in a parameterized constructor, the parameters can be of any type,
except the class, to which the constructor belongs.
Ex:
class a
{
..
..
public:
a(a);
};
this is illegal because, the class a is passed as argument.
2. a constructor can accept a reference to its own class as a
parameter.
3. ex:
class a
{
public:
a(a&);
};
this is valid.
constructor.
Such a constructor is called as copy
Multiple constructors in a class:

Multiple number of constructors can be declared in a class.
Let us consider the integer constructor example

Ex:
class integer
{
int m, n;
public:
integer ()
//constructor1
{
m=0;
n=0;
}
integer(int a, int b)
{
m=a;
//constructor2
n=b;
}
integer(integer &i)
{
m=i.m;
n=i.n;
}
};
//constructor3
The above programs declares three constructors for an integer object as

follows
1. integer() recieves no arguments.

2. integer (int a,int b)-receives two arguments
3. integer(integer &i)- receives one integer object as argument.
Now consider the declaration

1. integer i1; - this will automatically invoke the first constructor
and set both m and n of object i1 to zero.
2. integer i2(20,40); - this will call the second constructor, and it
initializes the data members m and n of i2to 20 and 40.
3. integer i3(i2); - this will call the third constructor, which will
copy the value of i2 into i3.
This means, it sets the value of every data element of i3 to the

value of the corresponding data element of i2.
Such
constructor
is
called
copy
constructor,
the
third
constructor here in this example is a copy constructor.
Constructor overloading:
In the above program, more than one constructor
function is defined in a class, the constructor is overloaded.
The
above
overloading.
The
program
is
constructor
an
example
function
for
integer(),
constructor
does
three
functions according to the argumentsit takes and there are three

definitions
for
the
constructor
here.
Hence
the
integer
()
constructor is overloaded.
Copy constructors:
Copy constructors are always used when the compiler
has to create a temporary object of the class.
The copy constructors are used in the following situations:
the initializations of an object by another object of the same class.
Return of objects as function value.
Stating the object as by value parameter of a function.
The general format of a copy construct is used to declare and initialize an

object from another object.
integer
t
(i1);
i2
Consider the statement
his will define the object i2 and at the same time
initialize it to the va,ues of i1.

Another form of this statement is:
integer
i2=i1;
The process of initialization through
a copy constructor is known as copy initialization.
a copy constructor takes a reference to an object of the same class

itself as an argument.
Copy constructor do not return function value as constructors

cannot return any functionvakues.
Example program for copy constructor :
class code
{
int id;
public:
code ();
//constructor
code(int a)
//constructor
{
id=a;
}
code(code &x)
{
id=x.id;
}
void display(void)
{
cout<<id;
//constructor
}
};
main()
{
code a(100);
//object a created and initialized
code b(a);
//copy constructor called, values in a
code c=a;
//copy constructor are called again, a values are
copied to the created object c

code d;
//d is created, not initialized
d=a;
//copy constructor is not called but values of a are
assigned to d
cout<<id of a:<<a.display();
cout <<id of b:<<b.display();
cout <<id of c:<<c.display();
cout <<id of d:<<d.display();
}
OUTPUT
Id of a:100
Id of b:100
Id of c:100
Id of d:100
In the declaration of the copy constructor
Copy (code &x)
Note, a reference variable has been used in the argument to the copy
constructor.
Constructors with default arguments:

It is possible to define the constructor with default
arguments.
Consider the declaration
integer(int x,int y);//constructor
This can be also declared as
integer (int x, int y=0);
- this means that the default
value of the argument y is 0 when any value is not given for y.

Now the statement
Integer i1(10);
Assigns 10 to x and 0 to y (by default).
The statement
Integer i1(10,20); - assigns 10 to x and 20 to y. this means
the actual parameter when specified, overrides the default value.
Note:
It is important to distinguish between default argument a::a() and
the default argument constructor a::a(int
=0). The default argument
constructor can be called with either one argument or no arguments.

When called with no arguments, it becomes a default constructor.
When both the forms are used in a class it causes ambiguity for a
statement such as
A a;
Now the ambiguity is whether to call A::A() or A::A(int =0);
DESTRUCTORS :
a destructor is a member function that is used to destroy the

objects that have been created by the constructor
name of the destructor is the same name as the class name, but it
is preceeded by a tilde(~).
For the class integer example, name of the constructor is

integer ();
Name of the destructor is
~ integer();
a destructor never takes any argument or does not return any

value.
A destructor is invoked implicitly by the compiler, when we reach

the exit of a block, function or program, to clean up the storage
that is no longer accessible.
So, finally to use destructors in a program is a good practice.
If new operator is used to allocate memory in the constructors,

then delete should be used for destroying the memory.
No return type should be specified for destructors.
//A program to explain the implementation of destructors
int count=0;
class alpha
{
public:
alpha()
{
count++;
cout<<No of objects created:<<count;
}
~ alpha()
{
cout<<no of objects destroyed:<<count;
}
};
void main()
{
cout<<enter main;
alpha A1,A2,A3,A4;
{
cout<<enter block1;
alpha A5;
}
{
cout<<enter block2;
alpha A6;
}
cout<<re-enter main;
}
Output of the program
Enter main
No of objects created:1
No of onjects created: 3
Enter block1:
No of objects destroyed:5
Enter block2:
No of objects destroyed:5
Re_enter main:
No of object destroyed:4
Here in the above program as the objects are created and destroyed, they
increase and decrease the count
First, 4 objects are created.
Then, entering block1, A5 is created and on exit from the block A5 is
destroyed.
Then, entering block2, A6 is created and on exit from the loop, A6 is

destroyed.
Then, re_entering into main finally, rest of the objects are destroyed.
* the objects are destroyed in the reversed order of creation.

* When closing brace of a scope is encountered the destructors for each
object in the scope are called.
FRIEND FUNCTION:
The main concepts of oop are data hiding and
data encapsulation. That is we are declaring variables in private part of a
class. So these members are restricted from accessing by non member
functions of the class. If any of the non member functions tries ti access
the members of the class , then a error messege is displayed .so for a non
member functions to have access to the members of the class they
should be declared in the public area which violates the data hiding and
encapsulation.
So the best way to access a private data member by a
non member functions is to declare a friend function to have access to
these data members.
Friend function:
It is a special mechanism of giving or granting

permission to non member functions to have access to private data.
A friend function may be either declared or defined
within the scope of a class definition. The keyword friend informs the
compiler that the function is not a member function of the clas
Syntax:
friend return type function name ( parameters );
NOTE:
2. friend function can be declared either in the private part or in the
public part of a class.
2.The keyword friend should be specified only in the function
declaration and it should not be specified in the function definition.
Ex:
Friend function disp() is declared in the public part
class first
{
private:
int x;
public:
void get();
friend void disp();
};
the friend function disp() is declared in the private part of the class.
class second
{
private:
int x;
friend void disp();
public:
void getdata();
};
2. Accessing private data by non member functions through friend:

The friend function is a special type of function which is used
to access the private data of any class.(ie) friend fuctions are non
member functions
With the abiliry to manipulate data members or the call functions
member functions that are not part of the public interface.
The friend function has the right to access all the members
of the class. Each time time when a friend function access the data , the
level of privacy of data encapsulation gets reduced. Only if it is necessary
to access the private data by non member functions then a class may
have a friend function otherwise it is not necessary.
Example:
class sample
{
private:
int x;
public:
void get();
friend void disp(class sample);
};
void sample :: get()
{
cout<Enter the value for x;
cin>>x;
}
void disp(class sample abc)
{
cout<Entered numbers are<<abc.x;
cout<<end l;
}
void main()
{
sample obj;
obj.get();
cout<<Accessing the private data by non member function;
}
2.Friend function with inline substitution:
A friend function may also be made up of inline function. If the

friend function is defined with the scope of class then there is noneed of
inline substitution. If the friend function is defined outside he class then
in the place of definition the keyword inline should precede in order to
make a inline substitution.
3.Granting friendship to another friend class:
A class can have friendship with another class.

Example:
Consider two classes first and second. If class first grants its friendship
to class econd then the privaye data members of class
First are permitted to be accessed by the public members of class
second. But the public members of class first cannot access private
members of class second.
class first
//Friend class
{
friend class econd;
private:
int x;
public:
void get();
};
class second
{
public:
void disp( first temp);
};
inline void first ::getdata()
{
cout<<Enter a number;
cin>>x;
}
inline void second :: disp( class first temp)
{
cout<<Entered numbers are :<<temp.x;
cout<<endl;
}
void main()
{
first objx;
second objy;
objx.get();
objy.disp(objx);
}
4.Tow classes having the same friend:

Friend function acting as a bridge:
A non member function may have
friendship with more the one class. When a function has declared to have
friendship with more than one class the friend class should have forward
declaration. This means that the friend function needs to access the
members of both the class.
Syntax for declaring friend function with more than one class:
class first
{
private:
-----------public:
};
class second
{
private:
-----------public:
};
UNIT II
Operator overloading Inheritance Polymorphism

Templates Exception Handling class Hierarchies
library organization and containers Strings Stream
Design and programming.
OPERATOR OVERLOADING
The ability of providing the operators with a special meaning for a

datatype is known as operator overloading. Operator overloading is done
with the help of a special function called Operator function which
describes the task of the operator.
The general form of an operator function is:
return-type classname::operator op(arglist)

{
function body
Return type is the type of value returned by the specified

operation. Op is the operator being overloaded. Operator op is the
function name. Operator functions an be either friend functions or
member functions. Operator functions can be declared in the class
using prototypes such as:
vector operator+(vector);
vector operator-();
int operator==(vec+);
friend int operator==(vector,vector);
friend vector operator+(vector,vector);
Steps for overloading are:

1. Create a class that defines the datatype to be used in the
overloading opweration.
2. Declare the operator function operator op() in the public part of the
class. It may be either a member function or a friend function.
3. Define the operator function to implement the required operations.
Ways of invoking the overloaded operator functions:

1. op x (or) x op - for unary operators.
2. x op y
- for binary operators.
OVERLOADING UNARY OPERATORS:
Consider the unary minus operator, this operator changes the sign
of an operand when applied to a basic data item.
Now let us overload this unary minus operator so that it can be
applied to objects in the same way as it can be applied to an int or float
variable.
This unary minus when applied to an object, it changes the sign of
each of the data items.
Example Program:
class space
{
int x;
int y;
int z;
public:
void getdata(int a, int b, int c);
void display(void);
void operator-();
};
void space::getdata(int a,int b,int c)
{
x=a;
y=b;
z=c;
}
void space::display(void)
{
cout<<x;
cout<<y;
cout<<z;
}
void space::operator-()
{
x=-x;
y=-y;
z=-z;
}
int main()
{
space s;
s.getdata(10,-20,30);
cout<<s:;
s.display();
-s;
cout<<S:;
s.display();
return ;
}
Output:
S:
10
-20
30
S:
-10
20
-30
OVERLOADING BINARY OPERATORS:
class complex
{
float x;
float y;
public:
complex();
complex(float real,float imag)
{
x=real;
y=imag;
}
complex operator+(complex);
void display();
};
complex complex::operator+(complex c)
{
complex temp;
temp.x=x+c.x;
temp.y=y+c.y;
return(temp);
}
void complex::display(void)
{
cout<<x<<+i<<y;
}
int main()
{
complex c1,c2,c3;
c1=complex(2.5,3.5);
c2=complex(1.6,2.7);
c3=c1+c2;
cout<<C1=;c1.display();
return 0;
}
Here the operator function +() receives one complex argument
explicity. One more argument for adding comes from the object that
invokes the operator function.
Thus the binary operator + is overloaded to add two complex numbers.
INHERITANCE
Inheritance is the process of creating new classes from an existing

class. The existing class is known as base class. The newly created
class is called as derived class. The derived class inherits all capabilities
of the existing class.
SYNTAX:
The general syntax for a derived class definition is:
Class derived-classname:visibility_mode base class-name

{
------}
A derived class is defined by specifying its relationship to the base

class in addition to its own details.
The general form of a derived class definition is:

Class derived-classname:visibility_mode base-classname
{
------}
* The colon indicates the derived-classname is derived from the baseclassname.

* Visibility_mode is optional ans it may be either public or private. The
default visibility_mode is private. The visibility_mode specifies whether
the features of the base class are privately defined or publicly derived.
EXAMPLE:
//Private derivation
Class ABC:private XYZ
{
Members of ABC;
};
//Public derivation
Class ABC:public XYZ
{
Members of ABC;
};
//private derivation by default
Class ABC:XYZ
{
Members of ABC;
}
When a class is privately inherited by a derived class, Public

members of the base class becomes private members in the derived
class.
When a class is publicly inherited by a derived class, then the
public members of the base class becomes public members of the derived
class.
In both the cases, the private part is not inherited. So while using
inheritance always declare the members in protected part and member
functions in public part. The visibility_mode, use always public.
TYPES OF INHERITANCE:
There are 5 types.
1. Single Inheritance.
2. Multilevel Inheritance.
3. Multiple Inheritance.
4. Hybrid Inheritance.
5. Heirarchial Inheritance.
SINGLE INHERITANCE:
A derived class with only one base class is called Single
Inheritance.
Single Inheritance
Single base class
Single derived class
//A program to read the derived class data members such as name, roll
no, height and weight from the keyboard and display the contents on the
screen using Single Inheritance.
#include<stdio.h>
#include<conio.h>
Class stud
{
protected:
char name[10];
int roll_no;
public:
void getdata();
void display();
};
Class stud1:public stud
{
Protected:
Float height,weight;
Public:
Void getdata();
Void display();
};
Void stud::getdata()
{
Cout<<Enter a name:;
Cin>>name;
Cout<<Enter the roll no:;

Cin>>roll_no;
}
Void stud::display()
{
Cout<<name:<<name;
Cout<<roll no:<<roll_no;
}
Void stud1::getdata()
{
Stud::getdata();
Cout<<Enter height and weight;
Cin>>height;
Cin>>weight;
}
Void stud1::display()
{
Stud::display();
Cout<<height:<<height;
Cout<<weight:<<weight;
}
Void main()
{
Stud1 s;
s.getdata();
s.display();
}
In the above program, stud1 is a derived class, stud is a base

class. Stud1 is derived from stud.
MULTILEVEL INHERITANCE:
The mechanism of deriving a class from another derived class is
called Multilevel Inheritance.
Baseclass
Derived class from A
Derived class from Derived B

Here A is the base class. B is the derived class from A. Class c is
derived from derived class B. so derived class B is acting as the base
class for class C. Such types of derived classes are called virtual base or
indirect base.
Here class A is the direct base. Class B is the indirect base or
virtual base or Intermediate base. ABCInheritance Path.
//A program to explain multilevel inheritance.

#include<conio.h>
Class student
{
Protected:
int rno;
public:
void getrno();
void putrno();
};
Class test:public student
{
Protected:
Int m1,m2,m3;
Public:
Void getmarks
{
Student::getrno();
Cout<<Enter the marks:;
Cin>>m1>>m2>>m3;
}
Void putmarks
{
Student::putrno();
Cout<<marks 1:<<m1;
Cout<<marks 2:<<m2;
Cout<<marks 3:<<m3;
}
};
Class result:public test
{
Protected:
Int total;
Float avg;
Public:
Void display()
{
Total=m1+m2+m3;
Avg=total/3;
Test::putmarks;
Cout<<Total:<<total;
Cout<<Average:<<avg;
}
};
Void student::getrno()
{
Cout<<enter the roll number of student;
Cin>>roll_no;
}
Void student::putrno()
{
Cout<<Roll No:<<roll_no;
}
Void main()
{
Result r;
R.getmarks();
r.display();
}
Here the result is derived from the text which is derived from student.
Using the object of result, we can call the member functions of student
and test.
MUTIPLE INHERITANCE:
A derived class can inherit the attributes of two or more classes.
This is called Multiple Inheritance. Using multiple inheritance we can
combine the features of existing classes as a starting point for defining
new classes.
The syntax of the Multiple Inheritance is:

Class D:visibility B1,visibility B2
{
------(body of D)
};
Where visibility may be either public or private. The base classes

are separated by commas.
//Program to explain Multiple Inheritance.

#include<conio.h>
Class M
{
Protected:
Int m;
Public:
Void get_m(int);
};
Class N
{
Protected:
Int n;
Public:
Void get_n(int);
};
Class P:public M,Public N

{
Public:
Void display(void);
};
Void M::get_m(in x)
{
M=x;
}
Void N::get_N(int y)
{
N=y;
}
Void P::display(void)
{
Cout<<m=<<m;
Cout<<n=<<n;
Cout<<m*n=<<m*n<<\n;
}
Int main()
{
P p;
p.get_n(10);
p.get_n(20);
p.display();
return 0;
}
Here class P is derived from class M and class N.
HIERARCHICAL INHERITANCE:
When properties of one class is inherited by more than one class,
then the inheritance is called as Hierarchical Inheritance.
Here, the features of one class are shared by many classes below
that level. (i.e.,) The Base Class includes all the properties that are
common to the subclasses. A subclass can be inherited by inheriting the
properties of the base class. A subclass can be a base class for the lower
lavel classes and so on.
EXAMPLE:
BIRD
FLYING
BIRD
ROBIN
SWALLOW
NON FLYING
BIRD
PENGUIN
KIWI
HYBRID INHERITANCE:
It is a combination of multiple and multilevel inheritance.
When a class is created or inherited from one derived class and

a base or a derived class then such type of inheritance is called
as Hybrid Inheritance.
POLYMORPHISM
poly many
morphism forms
In OOPs, polymorphism refers to identically named methods

(member functions) that have different behaviour depending on the type
of object they refer.
Definition:
Polymorphism is the process of defining a number of objects of
different classes into a group and call the methods to carry out the
operation of the objects using different function calls.
Polymorphism is implemented by means of virtual functions.
VIRTUAL FUNCTIONS:
A virtual function is one that does not really exist but it appears
real in some parts of a program. Polymorphism is implemented by
means of virtual functions.
To make a member function virtual, the keyword virtual is used
in the member functions while it is declared in the class definition, but
not in the definition of member function. The keyword virtual should
precede the return type of the function name in the member function
declaration. On seeing the keyword virtual the compiler understands
that the function declared is a virtual function and not a conventional
function.
SYNTAX:
Class class-name
{
private:
----public:
virtual returntype function_name(args);
----};
TEMPLATES
Template is a method for writing a single function or class for a

family of similar functions or classes in a genetic manner.
FUNCTION TEMPLATE:
When a single function is written for a family of similar functions,

it is called as function template. Consider function overloading, the
same name is used for all the functions, but the codes are repeated for
every function definition. (i.e) only the function names are same, but the
function definition and declaration are repeated.
In C++, a single function can be defined for a family of similar
functions. Such a function is called as function template. A function
template does not specify the actual datatypes of the arguments that a
function accepts but it uses a generic or parameterized datatype.
The general syntax for declaring a function template is:
Template<class template_name>
Template_name function_name
(template_name formal arguments)
{
return(template_name);
}
Here template and class are the keywords. (i.e) A function

template may be written in the following format.
Template<class T>
T function_name(T formal arguments)
{
return(T);
Here T is the template.
The return type of the function is never considered for the actual
parameterized datatypes to be processes. The actual datatype of the
function matches with the formal arguments of the function declaration
whenever parameterized arguments are inferred in the function template.
EXAMPLE:
A program to define a function temlate for summing an array of

integers and an array of floating point numbers.
template<class T>T sum(T a[10],int n)
{
T temp=0;
For(int i=0;i<=n-1;i++)
Temp=temp+a[i];
Return(temp);
}
int sum(int a[10],int n);
float sum(float b[10],int n);
void main()
{
int n=3,sum1;
float sum2;
static int a[3]={1,2,3};
static float b[3]={1.1,2.2,3.3};

sum1=sum(a,n);
cout<<sum of integers:<<sum1;
sum2=sum(b,n);
cout<<sum of floating point numbers:<<sum2;
}
OUTPUT:
Sum of integers: 6
Sum of floating point numbers: 6.6
Here function template sum () has been declared as a generic
function for adding an array of values of the size upto n elements where
the number of elements are passed by the function call from the calling
portion of the program.
The sum () function template is called twice, once to find the sum
of integer array and again to find the sum of floating point numbers.
EXCEPTION HANDLING
Exceptions refer to unusual conditions in a program. Exceptions

are errors that cause the programs to fail or certain conditions that leads
to errors.
When a program encounters an exception, it is important to deal
with it.
Exceptions are of 2 kinds:
Synchronous
Asynchronous
Synchronous Errors such as out-of-range index, over-flow that

occur in the program coding.
Asynchronous Errors such as keyboard interrupts that is caused
beyond the control of the program is called Asynchronous exception.
EXCEPTION HANDLING MECHANISMS:

The purpose of exception handling mechanism is to detect and
report an exceptional circumstance so that necessary actions can be
taken.
Steps here are:
1. Find the exception.
2. Inform (throw) that an exception has occurred.
3. Receive (catch) the information.
4. Take (handle) corrective actions.
Exception handling has got 2 segments:

1. To detect errors and to throw the exceptions called try block.
2. To catch the exceptions and to take appropriate actions called
catch block.
Three keywords here handle the exceptions: try, throw and catch.
TRY: It consists of a block of statements which may generate exceptions.
When any exception is found, it is thrown using a throw statement in
the try block.
CATCH: A catch block is defined by the catch keyword. It catches the

exception thrown by the throw statement and handles it in the way
defined.
Exception object
Try block
Detects and throws an
exception
Catch block
Catches and handles the
exception
Catch block should immediately follow the try block.
SYNTAX:
----------try
{
----------throw exception;
----------}
catch(type arg)
{
----------}
-----------
When the try block throws an exception, the program control

leaves the try block and enters the catch statement of the catch block.
Exceptions are thrown in the form of objects.
If the type of object thrown match the type of arg in the catch
statement, then the catch block is executed for handling the exception.
If object does not match with arg type of catch statement, then the
program is aborted by abort() function which is invoked default.
If exception is not found at the try block, then the catch block is
skipped and the execution control after leaving the try-block moves to the
statement following the catch-block.
EXAMPLE:
int main()
{
int a,b;
cout<<Enter values of a and b;
cin>>a>>b;
int x=a-b;
try
{
if(x!=0)
{
cout<<Result(a/x)=<<a/x;
}
else
{
throw(x);
}
}
catch(int i)
{
cout<<Exception caught:X=<<x;
}
cout<<end;
return 0;
}
OUTPUT:
First run:
Enter values of a and b
20 15
Result(a/x)=4
End.
Here no exception.
Second run:
Enter values of a and b
10 10
Exception caught:X=0
End.
Here the exception is division-by-zero problem.

GENERAL WORKING PROCEEDURE:
Throw exception
Invok
e function
Throw point
Function that causes
an exception
Try block
Invokes a function that
contains an exception
Catch block
Catches and handles
the exception
CLASS HIERARCHIES
One of the most important aspects of creating object-oriented programs

is the arrangement of classes into hierarchies. The simplest hierarchy is
called an association. Two classes are associated by a named
relationship. For example, consider a software system that tracks the
books that readers check out from a library. Two classes present in this
system could include a LibraryBook and a Reader. There is an
association between LibraryBook and Reader that could be called either
borrowing (readers borrow books from a library) or lending (a library
lends books to readers).
association An association is a relationship between two or more

classes. The association will indicate how objects of the different classes
relate to each other.
hierarchy An ordering of classes. The most common OO hierarchies are
inheritance and aggregation.
multiplicity An attribute that quantifies an association between objects.
The multiplicity is specified as a range of the number of objects that can
participate in the association, usually in the form n..m, where n is the
lower limit and m the upper limit. A * means an unlimited number, while
a single value can also be used. Common multiplicities include 1, 0..*,
1..*, and *.
aggregation A whole/part hierarchy. An aggregate object includes (has-a)

other objects, each of which is considered to be a part of (part-of) the
aggregate object.
composition A composition is a form of aggregation where the whole
cannot exist without having the parts.
has-a A way to state a whole/part relationship. The whole object has-a
part.
part-of The opposite of has-a. The component is a part-of the
whole.
whole/part A relationship between classes where one class will be made
up of or contain objects of another class.
default behaviors In an inheritance hierarchy, the class behaviors
defined by superclasses that will be used by default unless they are
overridden by some subclass.
derived In an inheritance hierarchy, a subclass is derived from a
superclass. The derived subclass inherits the attributes and methods of
the parent superclass.
generalization/specialization An inheritance hierarchy. Each subclass
is a specialization of a more generalized superclass.
implements In Java, a specification that the class will implement the
code required by an interface.
inheritance A mechanism that allows one class (subclass) to share the
attributes and behaviors of another class (superclass). Inheritance
defines an is-a relationship between
classes. The subclass or derived class inherits the attributes and

behaviors of the superclass, and will usually extend ormodify those
attributes and behaviors.
interface In Java, an interface is a specification of methods a class using
the interface must implement. An interface is a specification, and does
not define any code. It provides an alternative to multiple inheritance.
is-a A term used in inheritance hierarchies. In general, a subclass is-a
specialized kind of a more general superclass. modify those attributes
and behaviors.
interface In Java, an interface is a specification of methods a class using
the interface must implement. An interface is a specification, and does
not define any code. It provides an alternative to multiple inheritance.
is-a A term used in inheritance hierarchies. In general, a subclass is-a
specialized kind of a more general superclass. from an associated
superclass. A subclass is a specialization
of the generalized superclass.
superclass In an inheritance hierarchy, a superclass is a more
generalized class. A subclass will be derived from a superclass. (A
superclass is also known as a parent class or a base class.)
LIBRARY ORGANIZATION AND CONTAINERS

A container is a class, a data structure, or an abstract data type
(ADT) whose instances are collections of other objects. They are used to
store objects in an organized way following specific access rules.
Generally, container classes are expected to implement methods to do the

following:
* create a new empty container (constructor),

* report the number of objects it stores (size),
* delete all the objects in the container (clear),
* insert new objects into the container,
* remove objects from it,
* provide access to the stored objects.
There are two types of containers:

1. Value containers.
2. Reference containers.
Value based containers store copies of the objects. Accessing an object

also returns a copy of it. Modifying an external object after it has been
inserted in the container will not affect the content of the container.
Reference based containers only store pointers or references to the

objects. Accessing an object returns a reference to it. Modifying an
external object after it has been inserted in the container could result in
modifying the content of the container (or more precisely, the object
stored in the container).
Containers are sometimes implemented in conjunction with iterators.

Examples of containers:
Examples of container classes include
Array
Sets
Lists
Stacks
Queues
Table
Maps
Dictionary
Tree
Graph
STRINGS AND STREAM
STRINGS: A string is an ordered sequence of symbols. These symbols

are chosen from a predetermined set.
In programming, when stored in memory each symbol is
represented using a numeric value. A variable declared to have a string
datatype usually causes storage to be allocated in memory that is
capable of holding some predetermined number of symbols. When it
appears in source code a string is known as a string literal and has a
representation that denotes it as such. Sometimes the term binary string
is used to refer to an arbitrary sequence of bits.
String datatypes
A string datatype is a datatype modeled on the idea of a formal string.

Strings are such an important and useful datatype that they are
implemented in nearly every programming language. In some languages
they are available as primitive types and in others as composite types.
The syntax of most high-level programming languages allows for a string,
usually quoted in some way, to represent an instance of a string
datatype; such a meta-string is called a literal or string literal.
String length
Although formal strings can have an arbitrary (but finite) length, the
length of strings in real languages is often constrained to an artificial
maximum. In general, there are two types of string datatypes: fixed
length strings which have a fixed maximum length and which use the
same amount of memory whether this maximum is reached or not, and
variable length strings whose length is not arbitrarily fixed and which
use varying amounts of memory depending on their actual size. Most
strings in modern programming languages are variable length strings.
Despite the name, even variable length strings are limited in length;
although, generally, the limit depends only on the amount of memory
available..
Character encoding
Historically, string datatypes allocated one byte per character, and
although the exact character set varied by region, character encodings
were similar enough that programmers could generally get away with
ignoring this groups of character sets used by the same system in

different regions either had a character in the same place, or did not
have it at all. These character sets were typically based on ASCII or
EBCDIC.
Logographic languages such as Chinese, Japanese, and Korean (known

collectively as CJK) need far more than 256 characters (the limit of a onebyte-per-character encoding) for reasonable representation. The normal
solutions involved keeping single-byte representations for ASCII and
using two-byte representations for CJK ideographs. Use of these with
existing code led to problems with matching and cutting of strings, the
severity of which depended on how the character encoding was designed.
Some encodings such as the EUC family guarantee that a byte value in
the ASCII range will only represent that ASCII character, making the
encoding safe for systems that use those characters as field separators.
Other encodings such as ISO-2022 and Shift-JIS do not make such
guarantees, making matching on byte codes unsafe. Another issue is that
if the beginning of a string is deleted, important instructions for the
decoder or information on position in a multibyte sequence may be lost.
Another is that if strings are joined together (especially after having their
ends truncated by code not aware of the encoding), the first string may
not leave the encoder in a state suitable for dealing with the second
string.
Unicode has complicated the picture somewhat. Most languages have a

datatype for Unicode strings (usually UTF-16 as it was usually added
before Unicode supplemental planes were introduced). Converting
between Unicode and local encodings requires an understanding of the

local encoding, which may be problematic for existing systems where
strings of various encodings are being transmitted together with no real
marking as to what encoding they are in.
Implementations
Some languages like C++ implement strings as templates that can be
used with any primitive type, but this is the exception, not the rule.
If an object-oriented language represents strings as objects, they are

called mutable if the value can change at runtime and immutable if the
value is frozen after creation. For example, Ruby has mutable strings,
while Python's strings are immutable.
Other languages, most notably Prolog and Erlang, avoid implementing a

string datatype, instead adopting the convention of representing strings
as lists of character codes.
Representations
Representations of strings depend heavily on the choice of character
repertoire and the method of character encoding. Older string
implementations were designed to work with repertoire and encoding
defined by ASCII, or more recent extensions like the ISO 8859 series.
Modern implementations often use the extensive repertoire defined by
Unicode along with a variety of complex encodings such as UTF-8 and

UTF-16.
Most string implementations are very similar to variable-length arrays

with the entries storing the character codes of corresponding characters.
The principal difference is that, with certain encodings, a single logical
character may take up more than one entry in the array. This happens
for example with UTF-8, where single characters can take anywhere from
one to four bytes. In these cases, the logical length of the string differs
from the logical length of the array.
The length of a string can be stored implicitly by using a special

terminating character; often this is the null character having value zero,
a convention used and perpetuated by the popular C programming
language[1]. Hence, this representation is commonly referred to as C
string. The length of a string can also be stored explicitly, for example by
prefixing the string with byte value a convention used in Pascal;
consequently some people call it a P-string.
In terminated strings, the terminating code is not an allowable character

in any string.
Here is an example of a null-terminated string stored in a 10-byte buffer,

along with its ASCII representation:
F R A N
NUL k
46 52 41 4E 4B 00
6B 66 66 77
The length of a string in the above example is 5 characters, but it

occupies 6 bytes. Characters after the terminator do not form part of the
representation; they may be either part of another string or just garbage.
(Strings of this form are sometimes called ASCIZ strings, after the
original assembly language directive used to declare them.)
Here is the equivalent (old style) Pascal string stored in a 10-byte buffer,
along with its ASCII representation:
lengt
h
05
R A N
46 52 41 4E 4B 6B 66 66 77
While these representations are common, others are possible. Using

ropes makes certain string operations, such as insertions, deletions, and
concatenations more efficient.
DESIGN AND PROGRAMMING

Once the need for a class has been identified, these guidelines will help
to improve the design of an individual class, or a group of related classes.
A Class needs a Purpose
Every class needs responsibilities. If there are no clear responsibilities

and operations required by a class, then it likely should be a part of a
different class. If the class doesn't have a purpose, it should not exist.
Classes vs. Attributes
If a class has a well-defined set of attributes that have associated
operations that aren't really a part of the class, and that could potentially
be used independently by other classes, then those attributes and
operations are candidates for becoming an independent class. On the
other hand, if there is a class with no operations, then its attributes may
belong as simple attributes of another class. Because Java does not have
the equivalent of a simple C structure, there may be classes in Java that
really serve as structures, and thus may not require any operations, but
be used as a simple data structure.
Associations vs. Inheritance
Be careful when designing objectswith inheritance or aggregation.
Frequently, designs will use inheritance when simple association or
aggregation/composition is a better choice. Remember that all classes
in an inheritance hierarchy must pass the is-a test. Don't confuse is-a
with is-a-member-of. For example, A Circle is-a Shape, but it is -a
member-of a Drawing. Thus, a Shape should be a part of a Drawing,
but not inherit from it.
A Class can't do Everything

Don't make classes too big. The responsibilities of a class should be
just those that fit within that class, and should not be related to any
other classes. If a class is trying to do things that really don't relate to
its main responsibilities, then those behaviors likely belong in another

class.
NIT III
Object Orientation System development Review of

objects - inheritance - Object relationship Dynamic
binding OOSD life cycle Process Analysis Design
prototyping Implementation Testing- Overview of
Methodologies.
OBJECT ORIENTATION
There are several different object-oriented development

methodologies in use today. Each has its strengths and weaknesses.
The older, more traditional methodologies are often called "heavyweight"
methodologies, and are most useful for large software projects involving
tens or even hundreds of programmers over years of development effort.
The newer methodologies are called "lightweight" or "agile" ethodologies,
and are more appropriate for smaller projects. Many of these are quite
new and still being standardized as this book was being written.
Design and development methodologies have always needed a
graphical notation to express the designs. In the past, one of the major
problems has been that each major methodology has had its own
graphical notation. This has all changed with the emergence of the UML
(Unified Modeling Language) as the standard notation. Any of the current
design methodologies, heavyweight or agile, use or can benefit from the
UML.
The UML originated in the mid-1990's from the efforts of James
Rumbaugh, Ivar Jacobson, and Grady Booch (The Three Amigos). There
is a standard specification of the UML coordinated by the Object
Management Group (www.omg.org). OMG is an industry sponsored
organization devoted to supporting vendor-neutral standards for the
object-oriented development community. The UML has become the de
facto standard object-oriented notation.
The UML is designed for discussing object-oriented design. Its
ability to show objects and object relationships is especially useful, and
will be used in examples throughout this book. The various features of
the UML will be introduced as needed.
REVIEW OF OBJECTS
objects:
Object is a real-world entity, identifiably separate from its

surroundings.
The term object means a combination of data and logic that

represents some real world entity.
EXAMPLE:
A car
Consider a santro car.
santro can be represented in computer program as an object.
Datapart of this object cars name, color, number of doors, price and so
forth.
Logic part of the object is a collection of programs (show mileage,
change mileage, stop, go).
An object has a well defined set of attributes (properties) and a

well defined set of things you normally do with it (procedures or
methods).
Properties describe the state of an object and procedures

describe the behaviour of an object.
objects are grouped in classes:
Classes are used to differentiate one type of object from another.
A class is a set of objects that share a common structure and a

common behaviour.
An object is an instance of a class.
Classes are important mechanism for classifying objects. The

role of a class is to define the properties, procedures and
applicability of its instances.
EXAMPLE:
Employee class.
(i.e.) employees such as eno 1, eno 2, eno n are instances of the class
employee.
attributes (object state and properties):

Properties represent the state of an object. Each properties can be
represented in several ways in a programming language.
EXAMPLE:
Properties of a car are: color, manufacturer, cost.
object behaviour and methods:
A method is a function or procedure that is defined for a class

and it can access the internal state of the object to perform
some operation.
Behaviour denotes the collection of methods that abstractly

describes what an object is capable of doing.
objects respond to messages:
An object capabilities are determined by the methods defined for

it. Methods are function definitions used in procedural
languages.
Messages are non-specific function calls.
A message is different from a subroutine call, since different

objects can respond to the same message in different ways.
INHERITANCE
Inheritance is the process of creating new classes from an existing

class. The existing class is known as base class. The newly created
class is called as derived class. The derived class inherits all capabilities
of the existing class.
SYNTAX:
The general syntax for a derived class definition is:
Class derived-classname:visibility_mode base class-name

{
------}
A derived class is defined by specifying its relationship to the base

class in addition to its own details.
The general form of a derived class definition is:

Class derived-classname:visibility_mode base-classname
{
------}
* The colon indicates the derived-classname is derived from the baseclassname.

* Visibility_mode is optional ans it may be either public or private. The
default visibility_mode is private. The visibility_mode specifies whether
the features of the base class are privately defined or publicly derived.
EXAMPLE:
//Private derivation
Class ABC:private XYZ
{
Members of ABC;
};
//Public derivation
Class ABC:public XYZ
{
Members of ABC;
};
//private derivation by default
Class ABC:XYZ
{
Members of ABC;
}
When a class is privately inherited by a derived class, Public

members of the base class becomes private members in the derived
class.
When a class is publicly inherited by a derived class, then the
public members of the base class becomes public members of the derived
class.
In both the cases, the private part is not inherited. So while using
inheritance always declare the members in protected part and member
functions in public part. The visibility_mode, use always public.
OBJECT RELATIONSHIPS
Association represents the relationships between objects and

classes.
EXAMPLE:
A pilot can fly planes
Association represents the relationship among objects which is
bidirectional.
Can fly
flownPilot
by
Associators are bidirectional, that means they can be traversed in

both the directions with different connotations. The direction implied by
Planes
name is the forward direction, the opposite direction is the inverse

direction.
EXAMPLE:
can fly connects a pilot to certain airplanes.
The inverse of can fly could be called is flown by.
Cardinality:
It is the important issue of association. It specifies how many
instances of one class may relate to a single instance of an associated
class. It constrains the number of related objects and often is described
as being one or many.
EXAMPLE:
A client-account relationship.
One client can have one or more accounts and vice versa ( in case of joint
accounts). Here cardinality of the client account is many to many.
Consumer procedure Association:

A special form of association is a consumer-producer relationship,
also known as a client-server association or a use relationship.
Consumer-producer relationship is a one-way relationship: one
object requests the service of another object. The object which makes
the request is the consumer or client. The object that receives the
request and provides the service is the producer or server.
EXAMPLE:
Consumer/producer Association
Request
Print Server
Item
For printing
We have a print object that prints the consumer object. The print
producer provides the ability to print other objects.
DYNAMIC BINDING
The process of determining (dynamically) at runtime which

function to invoke is termed dynamic binding.
Making this determination earlier at compile time is called static
binding. Static binding optimizes the function calls. Dynamic binding
allows some method invocation decisions to be deferred until the
information is known. A runtime selection of methods often is desired
and is required in many applications. Applications are databases and
user interaction.
EXAMPLE:
A cut operation in edit submenu may pass the cut operation (along
with parameters) to any object in the desktop. Each object handles the
message in its own way.
OOSD LIFE CYCLE

It consists of
1. Software development process
2. Building high quality software
3. OOSD use-case driven approach
4. Incremental testing
5. Reusability
Software development process:
System development can be viewed as a process. (i.e.) The software
development is a process of change refinement, transformation or
addition to the existing product. Within a process, it is possible to
replace one subprocess with a new one, and the subprocess should have
the same interface to fit into the process. With this change, it is possible
to have a new process. (i.e.) Subprocesses changes the behaviour of the
parent process in a consistent way.
Each subprocess should have the following:
A description of how it works.
Specification of input required for the process.
Specification of the output produced by the process.
TRANSFORMATION 1 (ANALYSIS):
It translates the users needs into system requirements and
responsibilities. The way the users use the system provides the user
requirements.
TRANSFORMATION 2 (DESIGN):
Begins with a problem statement and ends with a detailed design
that can be transformed into an operational system. Most of the software
development activities such as definition of building a software, software
development and its testing takes place during this transformation.
TRANSFORMATION 3 (IMPLEMENTATION):
This refines the detailed design into system deployment which

will satisfy the users needs.
Equipments, procedures, people are taken into account here.
The software product is embedded into its operational

environment.
Software Process
Transformation 1
Users of the
system
Transformation 2 Transformation 3
Problem
ststement
analysis
Software development process example:

Waterfall approach:
Design
System software
implementation
Waterfall approach starts with decidingproduct
what is the problem.
detail
After the requirements are determined we must decide how to
accomplish them.
After decision we do it, whatever it has required to do.
Then we must test the result to see, whether we have satisfied

user requirements.
We then use the product.
WATERFALL SOFTWARE DEVELOPMENT PROCESS
Building
high quality software:
What
Four quality measures are:
How
1. Correspondence
2. Validation
3. Correctness
Do it
4. Verification
Test
Correspondence measures how well the delivered system
matches the needs of the operational environment as described
Use
in the original requirements statement.
Validation is the task of predicting correspondence.
Verification and validation are independent of each other.
OOSD Use-Case driven approach:

The object oriented software development life cycle (SDLC) consists
of three macro processes:
1. Object-Oriented Analysis
2. Object-Oriented Design
3. Object-Oriented Implementation
The use-case model is employed throughout most activities of
software development.
OOSD includes these activities:
1. Object-Oriented analysis Use case driven
2. O-O design
3. Prototyping
4. Component-based development
5. Incremental testing
Object Oriented design:
In this phase, we have to first build the object model based on
objects and their relationships, then iterate and refine the model:
Design and Refine classes
Design and Refine attributes
Design and Refine methods
Design and Refine structures
Design and Refine associators
Prototyping:
Categories of Prototypes are:
1. Horizontal prototype
2. Vertical prototype
3. Analysis prototype
4. Domain prototype
Implementation:
Component based development (CBD):
CBD is an industrialized approach to the software development

process.
Two ideas behind CBD are:

1. The application development can be improved
significantly if applications can be assembled quickly
from software components.
2. An large collection of components can be made available
to developers in both general and specialist catalogs.
Rapid application development (RAD):
RAD is a set of tools and techniques that can be used to build

an application faster then traditional method.
In RAD, incremental development of the software is dupported.
Incremental testing:
When we wait to perform a test until development, then we

could get thousands of bugs which results in waste of time and
memory.
It is better to test periodically in each phase of development.
OVERVIEW OF METHODOLOGY
A software development methodology is a series of processes,
that if followed can lead to the development of an application.
Systems development refers to all activities that go into
producing an information systems solution.
System development activities consists of systems analysis,

modeling, design, implementation, testing and maintenance.
UNIT IV
OMT Booch methodology, Jacobson methodology

patterns Unified approach UML Class diagram
Dynamic modeling. Use case model Creation of
classes Noun phrase approach responsibilities
Collaborators Object relationships Super-Sub class
Aggregation.
OBJECT MODELLING TECHNIQUE

The object-modeling technique (OMT) is an object modeling
language for software modeling and designing. It was developed circa
1991 by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen as a method
to develop object-oriented systems, and to support object-oriented
programming.
OMT is a predecessor of the Unified Modeling Language (UML). Many

OMT modeling elements are common to UML.
RUMBAUGH OMT:
Dr. James Rumbaugh is a computer scientist and object methodologist
who is best known for his work in creating the Object Modeling
Technique (OMT) and the Unified Modeling Language (UML).
Rumbaugh led the development of OMT while at General Electric

Research and Development Center, where he worked for over 25 years.
He joined Rational Software in 1994, and worked there with Ivar

Jacobson and Grady Booch ("the Three Amigos") to develop UML. Later
they merged their software development methologies, OMT, OOSE and
Booch into the Rational Unified Process (RUP). In 2003 he moved to IBM,
after its acquisition of Rational Software. He retired in 2006.
Jim has a B.S. in physics from MIT, an M.S. in astronomy from Caltech,
and a Ph.D. in computer science from MIT.
He has written a number of books about UML and RUP together with Ivar
Jacobson and Grady Booch.
BOOCH METHODOLOGY
The Booch method is a technique used in software engineering. It is an

object modeling language and methodology that was widely used in
object-oriented analysis and design. It was developed by Grady Booch
while at Rational Software (now part of IBM).
The notation aspect of the Booch method has now been superseded by
the Unified Modeling Language (UML), which features graphical elements
from the Booch method along with elements from the object-modeling
technique (OMT) and object-oriented software engineering (OOSE).
Methodological aspects of the Booch method have been incorporated into

several methodologies and processes, the primary such methodology
being the Rational Unified Process (RUP).
UNIFIED MODELING LANGUAGE
The Unified Modeling Language (UML) is a standardized

specification language for object modeling. UML is a general-purpose
modeling language that includes a graphical notation used to create an
abstract model of a system, referred to as a UML model.
Methods
UML is not a method by itself; however, it was designed to be compatible
with the leading object-oriented software development methods of its
time (for example OMT, Booch, Objectory). Since UML has evolved, some
of these methods have been recast to take advantage of the new notation
(for example OMT), and new methods have been created based on UML.
The best known is Rational Unified Process (RUP). There are many other
UML-based methods like Abstraction Method, Dynamic Systems
Development Method, and others, designed to provide more specific
solutions, or achieve different objectives.
Modeling
It is very important to distinguish between the UML model and the set of
diagrams of a system. A diagram is a partial graphical representation of a
system's model. The model also contains a "semantic backplane"
documentation such as written use cases that drive the model elements
and diagrams.
UML diagrams represent three different views of a system model:
Functional requirements view
Emphasizes the functional requirements of the system from the user's

point of view.
Includes use case diagrams.
Static structural view
Emphasizes the static structure of the system using objects, attributes,

operations, and relationships.
Includes class diagrams and composite structure diagrams.
Dynamic behavior view
Emphasizes the dynamic behavior of the system by showing

collaborations among objects and changes to the internal states of
objects.
Includes sequence diagrams, activity diagrams and state machine
diagrams.
UML models can be exchanged among UML tools by using the XMI
interchange format.
Diagrams
In UML 2.0 there are 13 types of diagrams. To understand them, it can

be useful to categorize them hierarchically, as shown in the hierarchy
chart below.
CLASS DIAGRAM
In the Unified Modeling Language (UML), a class diagram is a type of
static structure diagram that describes the structure of a system by
showing the system's classes, their attributes, and the relationships
between the classes.
Hierarchy of UML 2.0 Diagrams, shown as a class diagram
RELATIONSHIPS
A relationship is a general term covering the specific types of logical
connections found on class and object diagrams. UML shows the
following relationships:
Instance-Level Relationships
Link
A Link is the basic relationship among objects. It is represented as a line
connecting two or more object boxes. It can be shown on an object
diagram or class diagram. A link is an instance of an association.
Association
Class diagram example of association between two classesAn Association

represents a family of links. Binary associations (with two ends) are
normally represented as a line, with each end connected to a class box.
Higher order associations can be drawn with more than two ends. In
such cases, the ends are connected to a central diamond.
An association can be named, and the ends of an association can be

adorned with role names, ownership indicators, multiplicity, visibility,
and other properties. There are five different types of association. Bidirectional and uni-directional associations are the most common ones.
For instance, a flight class is associated with a plane class bidirectionally. Associations can only be shown on class diagrams.
Example: "department offers courses", is an association relationship.
Aggregation
Class diagram showing Aggregation between two classesAggregation is a

variant of the "has a" or association relationship; composition is more
specific than aggregation. As a type of association, an aggregation can be
named and have the same adornments that an association can. However,
an aggregation may not involve more than two classes.
Aggregation can occur when a class is a collection or container of other

classes, but where the contained classes do not have a strong life cycle
dependency on the container--essentially, if the container is destroyed,
its contents are not.
In UML, it is graphically represented as a clear diamond shape on the

containing class end of the tree of lines that connect contained class(es)
to the containing class.
Composition
Composition is a stronger variant of the "has a" or association
relationship; composition is more specific than aggregation.
Composition has a strong life cycle dependency between instances of the

container class and instances of the contained class(es): If the container
is destroyed, every instance that it contains is destroyed as well.
The UML graphical representation of a composition relationship is a filled

diamond shape on the containing class end of the tree of lines that
connect contained class(es) to the containing class.
CLASS LEVEL RELATIONSHIPS
Generalisation
Class diagram showing generalization between one superclass and two

subclassesThe generalisation relationship indicates that one of the two
related classes (the subtype) is considered to be a specialized form of the
other (the supertype) and supertype is considered as GENERALISATION
of subtype. In practice, this means that any instance of the subtype is
also an instance of the supertype (An exemplary tree of generalisations of
this form is found in binomial nomenclature: human beings are a
subtype of simian, which are a subtype of mammal, and so on). The
relationship is most easily understood by the phrase 'A is a B' (a human
is a mammal, a mammal is an animal).
The UML graphical representation of a generalisation is a hollow triangle

shape on the supertype end of the line (or tree of lines) that connects it
to one or more subtypes.
The generalisation relationship is also known as the inheritance or "is a"

relationship.
The supertype in the generalisation relationship is also known as the

"parent", superclass, base class, or base type.
The subtype in the generalisation relationship is also known as the

"child", subclass, derived class, derived type, inheriting class, or
inheriting type.
Note that this relationship bears no resemblance to the biological

parent/child relationship: the use of these terms is extremely common,
but can be misleading.
Generalisation-Specialization relationship
A is a type of B
E.g. "an oak is a type of tree", "a automobile is a type of vehicle"
Generalisations can only be shown on class diagrams and on Use case
diagrams.
Realisation
In UML modeling, a realisation relationship is a relationship between two
model elements, in which one model element (the client) realises the
behavior that the other model element (the supplier) specifies. A
realisation is displayed in the diagram editor as a dashed line with an
unfilled arrowhead towards the supplier.
Realisations can only be shown on class diagrams.
GENERAL RELATIONSHIP
Dependency (UML)
A dependency exists between two defined elements if a change to the
definition of one would result in a change to the other. This is indicated
by a dashed arrow pointing from the dependent to the independent
element. Several named varieties exist. A dependency can be between
instances, classes, or both.
Multiplicity
The association relationship indicates that (at least) one of the two
related classes makes reference to the other. In contrast with the
generalization relationship, this is most easily understood through the
phrase 'A has a B' {a mother cat has kittens, kittens have a mother cat}.
The UML representation of an association is a line with an optional

arrowhead indicating the role of the object(s) in the relationship, and an
optional notation at each end indicating the multiplicity of instances of
that entity (the number of objects that participate in the association).
Common multiplicities are:
0..1
No instances, or one instance (optional, may)
1
0..* or
*
1..*
Exactly one instance
Zero or more instances
One or more instances (at least one)
AGGREGATION
Aggregation differs from ordinary composition in that it does not imply
ownership. In composition, when the owning object is destroyed, so are
the contained objects. In aggregation, this is not necessarily true. For
example, a university owns various departments (e.g., chemistry), and
each department has a number of professors. If the university closes, the
departments will no longer exist, but the professors in those departments
will continue to exist. Therefore, a University can be seen as a
composition of departments, whereas departments have an aggregation
of professors. In addition, a Professor could work in more than one
department, but a department could not be part of more than one
university.
Composition is usually implemented such that an object contains

another object. For example, in C++:
class Professor;
class Department
{
...
private:
// Aggregation
Professor* members[5];
...
};
class University
{
...
private:
// Composition
Department faculty[20];
...
};
In aggregation, the object may only contain a reference or pointer to the
object (and not have lifetime responsibility for it):
Sometimes aggregation is referred to as composition when the distinction

between ordinary composition and aggregation is unimportant.
The above code would transform into the following UML Class diagram:
UNIT V
OO
Design
axioms
Class
visibility
refining
attributes Methods Access layer OODBMS Table

class mapping view layer. Quality assurance testing Inheritance and testing Test plan Usability testing
User satisfaction Testing.
OO DESIGN AXIOMS
Object oriented design is part of OO methodology and it forces
programmers to think in terms of objects, rather than procedures, when
they plan their code. An object contains encapsulated data and
procedures grouped together to represent an entity. The 'object interface',
how the object can be interacted, is also defined. An object oriented
program is described by the interaction of these objects. Object-oriented
design is the discipline of defining the objects and their interactions to
solve a problem that was identified and documented during objectoriented analysis.
Figure 1:An object

OBJECT-ORIENTED DESIGN
Input (sources) for object oriented design

Conceptual model (must have): Conceptual model is the result of objectoriented analysis, it captures concepts in the problem domain. The
conceptual model is explicitly chosen to be independent of
implementation details, such as concurrency or data storage.
Use case (must have): Use case is description of sequences of events that,
taken together, lead to a system doing something useful. Each use case
provides one or more scenarios that convey how the system should
interact with the users called actors to achieve a specific business goal or
function. Use case actors may be end users or other systems.
System Sequence Diagram (should have): System Sequence diagram
(SSD) is a picture that shows, for a particular scenario of a use case, the
events that external actors generate, their order, and possible intersystem events.
User interface documentations (if applicable): Document that shows and
describes the look and feel of the end product's user interface. This is not
mandatory to have, but helps to visualize the end-product and such

helps the designer.
Relational data model (if applicable): A data model is an abstract model
that describes how data is represented and used. If not object database
is used, usually the relational data model should be created before the
design can start. How the relational to object mapping is done is
included to the OO design.
Object oriented concepts supported by an OO language

The five basic concepts of object oriented design are the implementation
level features that are built into the programming language. These
features are often referred to by these common names:
Object/Class: A tight coupling or association of data structures with the

methods or functions that act on the data. This is called a class, or
object (an object is created based on a class).
Information hiding: The ability to protect some components of the object
from external entities. This is realized by language keywords to enable a
variable to be declared as private or protected to the owning class.
Inheritance: The ability for a class to extend or override functionality of
another class. The so called sub class has a whole section that is the
super class and then it has its own set of functions and data.
Interface: The ability to defer the implementation of a method. The ability
to define the functions or methods signatures without implementing
them.
Polymorphism: The ability to substitute an object with its sub objects.

The ability of an object-variable to contain, not only that object, but also
all of its sub objects as well.
Designing concepts
Defining objects, creating class diagram from conceptual diagram:
Usually map entity to class.
Identifying attributes.
Use design patterns (if applicable): A design pattern is not a finished
design, it is a description of a solution to a common problem. The main
advantage of using a design pattern is that it can be reused in multiple
applications. It can also be thought of as a template for how to solve a
problem that can be used in many different situations and/or
applications. Object-oriented design patterns typically show relationships
and interactions between classes or objects, without specifying the final
application classes or objects that are involved.
Define application framework (if applicable): Application framework is a
term usually used to refer to a set of libraries or classes that are used to
implement the standard structure of an application for a specific
operating system. By bundling a large amount of reusable code into a
framework, much time is saved for the developer, since he/she is saved
the task of rewriting large amounts of standard code for each new
application that is developed.
Identify persisted objects/data (if applicable): Identify objects that have to
be persisted. If relational database is used design the object relation
mapping.
Identify, define remote objects (if applicable)
Output (deliverables) of object oriented design

Class diagram: A class diagram is a type of static structure diagram that
describes the structure of a system by showing the system's classes,
their attributes, and the relationships between the classes.
Sequence diagram: Extends the System Sequence Diagram to add
specific objects that handle the system events. These are usually created
for important and complex system events, not for simple or trivial ones.
A sequence diagram shows, as parallel vertical lines, different processes
or objects that live simultaneously, and, as horizontal arrows, the
messages exchanged between them, in the order in which they occur.
Programming concepts
Aspect oriented programming: One view of aspect-oriented programming
(AOP) is that every major feature of the program, core concern (business
logic), or cross-cutting concern (additional features), is an aspect, and by
weaving them together (also called composition), you finally produce a
whole out of the separate aspects.
Dependency injection: The basic idea is that if an object depends upon
having an instance of some other object then the needed object is
"injected" into the dependent object. For example, being passed a
database connection as an argument to the constructor instead of
creating one internally
Acyclic Dependencies Principle: The dependency graph of packages or

components should have no cycles. This is also referred to as having a
Directed Acyclic Graph. For example, package C depends on package B,
which depends on package A. If package A also depended on package C,
then you would have a cycle.
Composite Reuse Principle: Favor polymorphic composition of objects
over inheritance.
METHODS
In software engineering and project management, a methodology is a
codified set of practices (sometimes accompanied by training materials,
formal educational programs, worksheets, and diagramming tools) that
may be repeatably carried out to produce software.
Software engineering methodologies span many disciplines, including

project management, analysis, specification, design, coding, testing, and
quality assurance. All of the methodologies guiding this field are
collations of all of these disciplines.
In object-oriented programming, the term method refers to a subroutine
that is exclusively associated either with a class (called class methods,
static methods, or factory methods) or with an object (called instance
methods). Like a procedure in procedural programming languages, a
method usually consists of a sequence of statements to perform an
action, a set of input parameters to customize those actions, and possibly
an output value (called return value) of some kind. The purpose of
methods is to provide a mechanism for accessing (for both reading and

writing) the private data stored in an object or a class.
Kinds of methods
As stated above, instance methods are associated with a particular
object, while class or static methods are instead associated with a class.
In all typical implementations, instance methods are passed a hidden
reference (e.g. this or self or Me) to the object (whether a class or class
instance) they belong to, so that they can access the data associated with
it. For class/static methods this may or may not happen according to the
language; methods of this kind are usually called class methods in
languages where they also get a reference to the class itself (as this or
self or Me), and static in languages where they don't. A typical example of
a class method would be one that keeps count of the number of created
objects within a given class.
An abstract method is a dummy code method which has no

implementation. It is often used as a placeholder to be overridden later
by a subclass of or an object prototyped from the one that implements
the abstract method. In this way, abstract methods help to partially
specify a framework.
An accessor method is a method that is usually small, simple and

provides the means for the state of an object to be accessed from other
parts of a program. Although it introduces a new dependency, use of the
methods are preferred to directly accessing state data because they
provide an abstraction layer. For example, if a bank-account class
provides a getBalance() accessor method to retrieve the current balance
(rather than directly accessing the balance data fields), then later
revisions of the same code can implement a more complex mechanism
balance retrieval (say, a database fetch) without the dependent code
needing to be changed. An accessor method that changes the state of an
object is called an update method, a modifier method, or a mutator
method. Objects that provide such methods are considered mutable
objects.
Some languages have a special syntax for Constructors, i.e. methods that
are called automatically upon the creation of an instance of a class. In
Java, C++, C#, ActionScript, and PHP they are distinguished by having
the same name as the class of the object they're associated with (PHP 5
also allows __construct as a constructor); in Visual Basic the constructor
is called New, and in Object Pascal constructors can have user-defined
names (but are mostly called Create). Under Objective-C the constructor
method is split between two methods, alloc and init, with the alloc
method setting aside memory for an instance of the class and the init
method handling the bulk of initializing the instance; a call to the new
method invokes both the alloc and the init method for the class instance.
Likewise, some languages have special Destructor methods, i.e. instance

methods that are called automatically upon the destruction of an
instance of a class. In C++, they are distinguished by having the same
name as the class of the object they're associated with, but with the
addition of a tilde (~) in front (or __destruct in PHP 5). In Object Pascal
destructors can have user-defined names (but are mostly called Destroy).
Under Objective-C the destructor method is named dealloc.
Isolation levels
Whereas a C programmer might push a value onto a stack data-structure
by calling:
stackPush(&myStack, value);
a C++ programmer would write:
myStack.push(value);
The difference is the required level of isolation. In C, the stackPush
procedure could be in the same source file as the rest of the program and
if it was, any other pieces of the program in that source file could see and
modify all of the low level details of how the stack was implemented,
completely bypassing the intended interface. In C++, regardless of where
the class is placed, only the functions which are part of myStack will be
able to get access to those low-level details without going through the
formal interface functions. Languages such as C can provide comparable
levels of protection by using different source files and not providing
external linkage to the private parts of the stack implementation but this
is less neat and systematic than the more cohesive and enforced isolation
of the C++ approach.
ACCESS LAYER
A Data access layer is a layer of a computer program which provides
simplified access to data stored in persistent storage of some kind, such
as an entity-relational database.
This Data Access Layer is used in turn by other program modules to

access and manipulate the data within the data store without having to
deal with the complexities inherent in this access.
For example, the DAL might return a reference to an object (in terms of
object-oriented programming) complete with its attributes instead of a
row of fields from a database table. This allows the client (or using)
modules to be created with a higher level of abstraction. This kind of
model could be implemented by creating a class of data access methods
which directly reference a corresponding set of database stored
procedures. Another implementation could potentially retrieve or write
records on to a file system. The DAL, hides from the external world, this
complexity of the underlying data store.
Consider that you have to interact from a specific table in the database
(like insert, delete, update) then you just create a class and a few stored
procedures in the database, where you call those Stored Procedures from
a method inside the class. and class in return on the coding side will
return an object containing the requested values.
Object-Relational Mapping tools provide data layers in this fashion,

following the Active Record model.
OODBMS
In an object oriented database, information is represented in the form of
objects as used in Object-Oriented Programming. When database
capabilities are combined with object programming language capabilities,

the result is an object database management system (ODBMS). An
ODBMS makes database objects appear as programming language
objects in one or more object programming languages. An ODBMS
extends the programming language with transparently persistent data,
concurrency control, data recovery, associative queries, and other
capabilities.
Some object-oriented databases are designed to work well with objectoriented programming languages such as Python, Java, C#, Visual
Basic .NET, C++ and Smalltalk. Others have their own programming
languages. ODBMSs use exactly the same model as object-oriented
programming languages.
Object databases are generally recommended when there is a business

need for high performance processing on complex data.
Object Database management systems grew out of research during the

early to mid-1970s into having intrinsic database management support
for graph-structured objects. The term "object-oriented database system"
first appeared around 1985. Notable research projects included EncoreOb/Server (Brown University), EXODUS (University of Wisconsin), IRIS
(Hewlett-Packard), ODE (Bell Labs), ORION (Microelectronics and
Computer Technology Corporation or MCC), Vodak (GMD-IPSI), and
Zeitgeist (Texas Instruments). The ORION project had more published
papers than any of the other efforts. Won Kim of MCC compiled the best
of those papers in a book published by The MIT Press.[1]
Early commercial products included Gemstone (Servio Logic, name

changed to GemStone Systems), Gbase (Graphael), and Vbase
(Ontologic). The early to mid-1990s saw additional commercial products
enter the market. These included ITASCA (Itasca Systems), Jasmine
(Fujitsu, marketed by Computer Associates), Matisse (Matisse Software),
Objectivity/DB (Objectivity, Inc.), ObjectStore (Progress Software,
acquired from eXcelon which was originally Object Design), ONTOS
(Ontos, Inc., name changed from Ontologic), O2[2] (O2 Technology,
merged with several companies, acquired by Informix, which was in turn
acquired by IBM), POET (now FastObjects from Versant which acquired
Poet Software), and Versant Object Database (Versant Corporation). Some
of these products remain on the market and have been joined by new
products (see the product listings below).
Object database management systems added the concept of persistence

to object programming languages. The early commercial products were
integrated with various languages: GemStone (Smalltalk), Gbase (LISP),
and Vbase (COP). For much of the 1990s, C++ dominated the commercial
object database management market. Vendors added Java in the late
1990s and more recently, C#.
Starting in 2004, object databases have seen a second growth period

when open source object databases emerged that were widely affordable
and easy to use, because they are entirely written in OOP languages like
Java or C#, such as db4o (db4objects) and Perst (McObject). Recently
another open source object database Magma has been in development.

Magma is written in Squeak.
Object databases have also gained a new audience of developers through

the popularity of Salesforce.com, a software-as-a-service application. Its
object-oriented database is exposed to administrators who can extend
the schema and retrieve data via a proprietary object query language.
Adoption of object databases

Object databases based on persistent programming acquired a niche in
application areas such as engineering and spatial databases,
telecommunications, and scientific areas such as high energy physics
and molecular biology. They have made little impact on mainstream
commercial data processing, though there is some usage in specialized
areas of financial services. It is also worth noting that object databases
held the record for the World's largest database (being first to hold over
1000 Terabytes at Stanford Linear Accelerator Center "Lessons Learned
From Managing A Petabyte") and the highest ingest rate ever recorded for
a commercial database at over one Terabyte per hour.
Another group of object databases focuses on embedded use in devices,

packaged software and realtime systems. The reason to adapt is to create
new objects according to users choice.
Technical features
Most object databases also offer some kind of query language, allowing
objects to be found by a more declarative programming approach. It is in
the area of object query languages, and the integration of the query and
navigational interfaces, that the biggest differences between products are
found. An attempt at standardization was made by the ODMG with the
Object Query Language OQL.
Access to data can be faster because joins are often not needed (as in a
tabular implementation of a relational database). This is because an
object can be retrieved directly without a search, by following pointers. (It
could, however, be argued that "joining" is a higher-level abstraction of
pointer following.)
Another area of variation between products is in the way that the schema
of a database is defined. A general characteristic, however, is that the
programming language and the database schema use the same type
definitions.
Multimedia applications are facilitated because the class methods

associated with the data are responsible for its correct interpretation.
Many object databases offer support for versioning. An object can be

viewed as the set of all its versions. Also, object versions can be treated
as objects in their own right. Some object databases also provide
systematic support for triggers and constraints which are the basis of
active databases.
Advantages and disadvantages

Benchmarks between ODBMSs and relational DBMSs have shown that
ODBMS can be clearly superior for certain kinds of tasks. The main
reason for this is that many operations are performed using navigational
rather than declarative interfaces, and navigational access to data is
usually implemented very efficiently by following pointers.[3]
Critics of Navigational Database-based technologies like ODBMS suggest

that pointer-based techniques are optimized for very specific "search
routes" or viewpoints. However, for general-purpose queries on the same
information, pointer-based techniques will tend to be slower and more
difficult to formulate than relational. Thus, navigation appears to
simplify specific known uses at the expense of general, unforeseen, and
varied future uses. (However, it may be possible to apply generic
reorderings and optimisations of pointer routes in some cases).
Other things that work against ODBMS seem to be the lack of

interoperability with a great number of tools/features that are taken for
granted in the SQL world including but not limited to industry standard
connectivity, reporting tools, OLAP tools and backup and recovery
standards. Additionally, object databases lack a formal mathematical
foundation, unlike the relational model, and this in turn leads to
weaknesses in their query support. However, this objection is offset by
the fact that some ODBMSs fully support SQL in addition to navigational
access, e.g. Objectivity/SQL++ and Matisse. Effective use may require
compromises to keep both paradigms in sync.
In fact there is an intrinsic tension between the notion of encapsulation,

which hides data and makes it available only through a published set of
interface methods, and the assumption underlying much database
technology, which is that data should be accessible to queries based on
data content rather than predefined access paths. Database-centric
thinking tends to view the world through a declarative and attributedriven viewpoint, while OOP tends to view the world through a behavioral
viewpoint. This is one of the many impedance mismatch issues
surrounding OOP and databases.
Although some commentators have written off object database

technology as a failure, the essential arguments in its favor remain valid,
and attempts to integrate database functionality more closely into object
programming languages continue in both the research and the industrial
communities.[citation needed]
Standards
The Object Data Management Group (ODMG) was a consortium of object
database and object-relational mapping vendors, members of the
academic community, and interested parties. Its goal was to create a set
of specifications that would allow for portable applications that store
objects in database management systems. It published several versions
of its specification. The last release was ODMG 3.0. By 2001, most of the
major object database and object-relational mapping vendors claimed
conformance to the ODMG Java Language Binding. Compliance to the
other components of the specification was mixed.[4] In 2001, the ODMG

Java Language Binding was submitted to the Java Community Process
as a basis for the Java Data Objects specification. The ODMG member
companies then decided to concentrate their efforts on the Java Data
Objects specification. As a result, the ODMG disbanded in 2001.
Many object database ideas were also absorbed into SQL:1999 and have
been implemented in varying degrees in object-relational database
products.
In 2005 Cook, Rai, and Rosenberger proposed to drop all standardization

efforts to introduce additional object-oriented query APIs but rather use
the OO programming language itself, i.e., Java and .NET, to express
queries. As a result, Native Queries emerged. Similarly, Microsoft
announced Language Integrated Query (LINQ) and DLINQ, an
implementation of LINQ, in September 2005, to provide close, languageintegrated database query capabilities with its programming languages
C# and VB.NET 9.
In February 2006, the Object Management Group (OMG) announced that

they had been granted the right to develop new specifications based on
the ODMG 3.0 specification and the formation of the Object Database
Technology Working Group (ODBT WG). The ODBT WG plans to create a
set of standards that incorporates advances in object database
technology (e.g., replication), data management (e.g., spatial indexing),
and data formats (e.g., XML) and to include new features into these
standards that support domains where object databases are being

adopted (e.g., real-time systems).
TABLE
In relational databases, SQL databases, and flat file databases, a table is
a set of data elements (values) that is organized using a model of
horizontal rows and vertical columns. The columns are identified by
name, and the rows are identified by the values appearing in a particular
column subset which has been identified as a candidate key. Table is
another term for relations; although there is the difference in that a table
is usually a multi-set (bag) of rows whereas a relation is a set and does
not allow duplicates. A table has a specified number of columns but can
have any number of rows. Besides the actual data rows, tables generally
have associated with them some meta-information, such as constraints
on the table or on the values within particular columns.
The data in a table does not have to be physically stored in the database.
Views are also relational tables, but their data is calculated at query
time. Another example are nicknames, which represent a pointer to a
table in another database.
Comparisons with other data structures

In non-relational systems, such as hierarchical databases, the distant
counterpart of a table is a structured file, representing the rows of a
table in each record of the file and each column in a record.
Unlike a spreadsheet, the datatype of each field is ordinarily defined by

the schema describing the table. Some relational systems are less strict
about field datatype definitions.
Tables versus relations

In terms of the relational model of databases, a table can be considered a
convenient representation of a relation, but the two are not strictly
equivalent. For instance, an SQL table can potentially contain duplicate
rows, whereas a true relation cannot contain duplicate tuples. Similarly,
representation as a table implies a particular ordering to the rows and
columns, whereas a relation is explicitly unordered. However, the
database system does not guarantee any ordering of the rows unless an
ORDER BY clause is specified in the SELECT statement that queries the
table.
An equally valid representation of a relation is as an n-dimensional

graph, where n is the number of attributes (a table's columns). For
example, a relation with two attributes and three values can be
represented as a table with two columns and three rows, or as a twodimensional graph with three points. The table and graph
representations are only equivalent if the ordering of rows is not
significant, and the table has no duplicate rows.
QUALITY ASSURANCE TESTING

Quality assurance, or QA for short, is the activity of providing evidence
needed to establish quality in work, and that activities that require good
quality are being performed effectively. All those planned or systematic

actions necessary to provide enough confidence that a product or service
will satisfy the given requirements for quality.
For products, quality assurance is a part and consistent pair of quality

management offering supposedly fact-based external confidence to
customers and other stakeholders that a product meets needs,
expectations, and other requirements. QA claims to assure the existence
and effectiveness of procedures that attempt to make sure - in advance that the expected levels of quality will be reached.
QA covers all activities from design, development, production,

installation, servicing to documentation. It introduced the sayings "fit for
purpose" and "do it right the first time". It includes the regulation of the
quality of raw materials, assemblies, products and components; services
related to production; and management, production, and inspection
processes.
The term Quality Assurance, as used in the United States Nuclear

Regulatory Commission regulation 10 CFR Part 50, Appendix B,
comprises all those planned and systematic actions necessary to provide
adequate confidence that a structure, system, or component will perform
satisfactorily in service. Quality assurance includes quality control,
which comprises those quality assurance actions related to the physical
characteristics of a material, structure, component, or system which
provide a means to control the quality of the material, structure,
component, or system to predetermined requirements.
One of the most widely used paradigms for QA management is the PDCA
(Plan-Do-Check-Act) approach, also known as the Shewhart cycle.
INHERITANCE AND TESTING

Inheritance is the practice of passing on property, titles, debts, and
obligations upon the death of an individual. It has long played an
extremely important role in human societies.
Both anthropology and sociology have made detailed studies in this area.
Many cultures feature patrilineal succession, also known as gavelkind,
where only male children can inherit. Some cultures also employ
matrilineal succession only passing property along the female line. Other
practices include primogeniture, under which all property goes to the
eldest child, or often the eldest son, or ultimogeniture, in which
everything is left to the youngest child. Some ancient societies and most
modern states employ partible inheritance, under which every child
inherits (usually equally). Historically, there were also mixed systems:
In eastern Swedish culture, from the 13th century until the 19th
century, sons inherited twice as much as daughters. This rule was
introduced by the Regent Birger Jarl, and it was regarded as an
improvement in its era, since daughters were previously usually left
without.
Among ancient Israelites, the eldest son received twice as much as the
other sons.
Among Galician people it was typical that all children (both men and
women) had a part of the inheritance, but one son (the one who inherited
the house) inherited one-third of all the inheritance. This son was called
the mellorado. In some villages the mellorado even received two-thirds of
all the inheritance. This two-thirds would be all the family's lands, while
other children received their part in money.
According to Islamic inheritance jurisprudence, sons inherit twice as
much as daughters when no will is left. The complete laws governing
inheritance in Islam are complicated and take into account many kinship
relations (so wills are usually recommended), but in principle males
inherit twice as females. There is one interesting exception: The
Indonesian Minangkabau people from West part of Sumatra island
despite being strong Muslims employ only complete matrilineal
succession with property and land passing down from mother to
daughter. They find no contradiction between their culture and faith.
Many states have inheritance taxes, under which a portion of any estate
goes to the government, though the government technically is not an
heir.
Employing differing forms of succession can affect many areas of society.

Gender roles are profoundly affected by inheritance laws and traditions.
Primogeniture has the effect of keeping large estates united and thus
perpetuating an elite. With partible inheritance large estates are slowly
divided among many descendants and great wealth is thus diluted,
leaving higher opportunities to individuals to make a success. (If great
wealth is not diluted, the positions in society tend to be much more fixed
and opportunities to make an individual success are lower.)
Inheritance can be organized in a way that its use is restricted by the

desires of someone (usually of the decedent). An inheritance may have
been organized as a fideicommissum, which usually cannot be sold or
diminished, only its profits are disposable. A fideicommissum's
succession can also be ordered in a way that determines it long (or
eternally) also with regard to persons born long after the original
descendant. Royal succession has typically been more or less a
fideicommissum, the realm not (easily) to be sold and the rules of
succession not to be (easily) altered by a holder (a monarch).
In more archaic days, the possession of inherited land has been much
more like a family trust than a property of an individual. Even in recent
years, the sale of the whole of or a significant portion of a farm in many
European countries required consent from certain heirs, and/or heirs
had the intervening right to obtain the land in question with same sales
conditions as in the sales agreement in question.
In common law jurisdictions an heir is a person who is entitled to receive

a share of the decedent's [1] property via the rules of inheritance in the
jurisdiction where the decedent died or owned property at the time of his
death. Strictly speaking, one becomes an heir only upon the death of the
decedent. It is improper to speak of the "heir" of a living person, since the
exact identity of the persons entitled to inherit are not determined until
the time of death. In a case where an individual has such a position that
only her/his own death before that of the decedent would prevent the
individual from becoming a heir, the individual is called an heir
apparent. There is a further concept of jointly inheriting, pending

renunciation by all but one, which is called coparceny.
In modern legal use, the terms inheritance and heir refer only to
succession of property from a decedent who has died intestate (that is,
without a will). It is a common mistake to refer to the recipients of
property through a will as heirs when they are properly called devisees or
legatees.
TEST PLAN
A test plan is a systematic approach to testing a system such as a
machine or software. The plan typically contains a detailed
understanding of what the eventual workflow will be.
TEST PLANS IN SOFTWARE DEVELOPMENT

In software testing, a test plan gives detailed testing information
regarding an upcoming testing effort, including
* Scope of testing
* Schedule
* Test Deliverables
* Release Criteria
* Risks and Contingencies
Test plan identifier
For example: "Master plan for 3A USB Host Mass Storage Driver
TP_3A1.0"
Introduction
State the purpose of the Plan, possibly identifying the level of the plan
(master etc.). This is essentially the executive summary part of the plan.
You may want to include any references to other plans, documents or

items that contain information relevant to this project/process.
Identify the objective of the plan or scope of the plan in relation to the
Software Project plan that it relates to. Other items may include,
resource and budget constraints, scope of the testing effort, how testing
relates to other evaluation activities (Analysis & Reviews), and possible
the process to be used for change control and communication and
coordination of key activities.
Test items (functions)

These are things you intend to test within the scope of this test plan.
Essentially, something you will test, a list of what is to be tested. This can
be developed from the software application inventories as well as other
sources of documentation and information.
This can be controlled on a local Configuration Management (CM)

process if you have one. This information includes version numbers,
configuration requirements where needed, (especially if multiple versions
of the product are supported). It may also include key delivery schedule
issues for critical elements.
This section can be oriented to the level of the test plan. For higher levels
it may be by application or functional area, for lower levels it may be by
program, unit, module or build.
Software risk issues

Identify what software is to be tested and what the critical areas are,
such as:
Delivery of a third party product.

New version of interfacing software.
Ability to use and understand a new package/tool, etc.
Extremely complex functions.
Modifications to components with a past history of failure.
Poorly documented modules or change requests.
There are some inherent software risks such as complexity; these need to
be identified.
Safety.
Multiple interfaces.
Impacts on Client.
Government regulations and rules.
Another key area of risk is a misunderstanding of the original
requirements. This can occur at the management, user and developer
levels. Be aware of vague or unclear requirements and requirements that
cannot be tested.
The past history of defects (bugs) discovered during Unit testing will help
identify potential areas within the software that are risky. If the unit
testing discovered a large number of defects or a tendency towards
defects in a particular area of the software, this is an indication of
potential future problems. It is the nature of defects to cluster and clump
together. If it was defect ridden earlier, it will most likely continue to be
defect prone.
One good approach to define where the risks are is to have several
brainstorming sessions.
Start with ideas, such as, what worries me about this

project/application.
Features to be tested
This is a listing of what is to be tested from the user's viewpoint of what
the system does. This is not a technical description of the software, but a
USERS view of the functions.
Set the level of risk for each feature. Use a simple rating scale such as
High, Medium and Low(H, M, L). These types of levels are understandable
to a User. You should be prepared to discuss why a particular level was
chosen.
Sections 4 and 6 are very similar, and the only true difference is the
point of view. Section 4 is a technical type description including version
numbers and other technical information and Section 6 is from the

Users viewpoint. Users do not understand technical software
terminology; they understand functions and processes as they relate to
their jobs.
Features not to be tested

This is a listing of what is 'not' to be tested from both the user's viewpoint
of what the system does and a configuration management/version
control view. This is not a technical description of the software, but a
user's view of the functions.
Identify why the feature is not to be tested, there can be any number of
reasons.
Not to be included in this release of the Software.

Low risk, has been used before and was considered stable.
Will be released but not tested or documented as a functional part of the
release of this version of the software.
Sections 6 and 7 are directly related to Sections 5 and 17. What will and
will not be tested are directly affected by the levels of acceptable risk
within the project, and what does not get tested affects the level of risk of
the project.
Approach (strategy)
This is your overall test strategy for this test plan; it should be
appropriate to the level of the plan (master, acceptance, etc.) and should
be in agreement with all higher and lower levels of plans. Overall rules
and processes should be identified.
Are any special tools to be used and what are they?

Will the tool require special training?
What metrics will be collected?
Which level is each metric to be collected at?
How is Configuration Management to be handled?
How many different configurations will be tested?
Hardware
Software
Combinations of HW, SW and other vendor packages
What levels of regression testing will be done and how much at each test
level?
Will regression testing be based on severity of defects detected?
How will elements in the requirements and design that do not make
sense or are untestable be processed?
If this is a master test plan the overall project testing approach and
coverage requirements must also be identified.
Specify if there are special requirements for the testing.
Only the full component will be tested.

A specified segment of grouping of features/components must be tested
together.
Other information that may be useful in setting the approach are:
MTBF, Mean Time Between Failures - if this is a valid measurement for

the test involved and if the data is available.
SRE, Software Reliability Engineering - if this methodology is in use and
if the information is available.
How will meetings and other organizational processes be handled?
Item pass/fail criteria

Show stopper issues. Specify the criteria to be used to determine whether
each test item has passed or failed. Show Stopper severity requires
definition within each testing context.
Entry & exit criteria

Specify the criteria to be used to start testing and how you know when to
stop the testing process.
Suspension criteria & resumption requirements

Suspension criteria specify the criteria to be used to suspend all or a
portion of the testing activities while resumption criteria specify when
testing can resume after it has been suspended.
For example, System Integration Testing in Integration environment can

be suspended in the following circumstances:
Unavailability of external dependent systems during execution.

When a tester submits a "Critical" or "Major" defect, the Testing Team will
call a break in testing while an impact assessment is done
When the Sanity Tests fail.
System Integration Testing in the Integration environment may be
resumed under the following circumstances:
When the "Critical" or "Major" defect is resolved

When the defect from the Sanity Test is resolved and available for retesting
When a fix is successfully implemented and the Testing Team is notified
to continue testing
Test deliverables
List documents, reports, charts, that will be presented to stakeholders on
a regular basis during testing and when testing has been completed.
Remaining test tasks

If this is a multi-phase process or if the application is to be released in
increments there may be parts of the application that this plan does not
address. These areas need to be identified to avoid any confusion should
defects be reported back on those future functions. This will also allow
the users and testers to avoid incomplete functions and prevent waste of
resources chasing non-defects.
If the project is being developed as a multi-party process, this plan may

only cover a portion of the total functions/features. This status needs to
be identified so that those other areas have plans developed for them and
to avoid wasting resources tracking defects that do not relate to this plan.
When a third party is developing the software, this section may contain
descriptions of those test tasks belonging to both the internal groups and
the external groups.
Environmental needs
Are there any special requirements for this test plan, such as:
Special hardware such as simulators, static generators etc.

How will test data be provided. Are there special collection requirements
or specific ranges of data that must be provided?
How much testing will be done on each component of a multi-part
feature?
Special power requirements.
Specific versions of other supporting software.
Restricted use of the system during testing.
Staffing and training needs

Training on the application/system.
Training for any test tools to be used.
The Test Items and Responsibilities sections affect this section. What is
to be tested and who is responsible for the testing and training.
Responsibilities
Who is in charge?
This issue includes all areas of the plan. Here are some examples:
Setting risks.
Selecting features to be tested and not tested.
Setting overall strategy for this level of plan.
Ensuring all required elements are in place for testing.
Providing for resolution of scheduling conflicts, especially, if testing is
done on the production system.
Who provides the required training?
Who makes the critical go/no go decisions for items not covered in the
test plans?
Planning risks and contingencies

What are the overall risks to the project with an emphasis on the testing
process?
Lack of personnel resources when testing is to begin.

Lack of availability of required hardware, software, data or tools.
Late delivery of the software, hardware or tools.
Delays in training on the application and/or tools.
Changes to the original requirements or designs.
Complexities involved in testing the applications
Specify what will be done for various events, for example:
Requirements definition will be complete by January 1, 20XX, and, if the

requirements change after that date, the following actions will be taken:
The test schedule and development schedule will move out an

appropriate number of days. This rarely occurs, as most projects tend to
have fixed delivery dates.
The number of tests performed will be reduced.
The number of acceptable defects will be increased.
These two items could lower the overall quality of the delivered product.
Resources will be added to the test team.
The test team will work overtime (this could affect team morale).
The scope of the plan may be changed.
There may be some optimization of resources. This should be avoided, if
possible, for obvious reasons.
Management is usually reluctant to accept scenarios such as the one
above even though they have seen it happen in the past.
The important thing to remember is that, if you do nothing at all, the

usual result is that testing is cut back or omitted completely, neither of
which should be an acceptable option.
Approvals
Who can approve the process as complete and allow the project to
proceed to the next level (depending on the level of the plan)?
At the master test plan level, this may be all involved parties.
When determining the approval process, keep in mind who the audience
is:
The audience for a unit test level plan is different from that of an
integration, system or master level plan.
The levels and type of knowledge at the various levels will be different as
well.
Programmers are very technical but may not have a clear understanding
of the overall business process driving the project.
Users may have varying levels of business acumen and very little
technical skills.
Always be wary of users who claim high levels of technical skills and
programmers that claim to fully understand the business process. These
types of individuals can cause more harm than good if they do not have
the skills they believe they possess.
TEST PLANS IN HARDWARE DEVELOPMENT
A test plan documents the strategy that will be used to verify and ensure
that a hardware product or system meets its design specifications and
other requirements. A test plan is usually prepared by or with significant
input from Test Engineers.
Depending on the product and the responsibility of the organization to

which the test plan applies, a test plan may include one or more of the
following:
Design Verification or Compliance test - to be performed during the

development or approval stages of the product, typically on a small
sample of units.
Manufacturing or Production test - to be performed during preparation
or assembly of the product in an ongoing manner for purposes of
performance verification and quality control.
Acceptance or Commissioning test - to be performed at the time of
delivery or installation of the product.
Service and Repair test - to be performed as required over the service life
of the product.
A complex system may have a high level test plan to address the overall
requirements and supporting test plans to address the design details of
subsystems and components.
Test plan document formats can be as varied as the products and

organizations to which they apply, but there are three major elements of
a test strategy that should be described in the test plan: Test Coverage,
Test Methods, and Test Responsibilities.
Test coverage in the test plan states what requirements will be verified
during what stages of the product life. Test Coverage is derived from
design specifications and other requirements, such as safety standards
or regulatory codes, where each requirement or specification of the
design ideally will have one or more corresponding means of verification.
Test coverage for different product life stages may overlap, but will not
necessarily be exactly the same for all stages. For example, some
requirements may be verified during Design Verification test, but not
repeated during Acceptance test. Test coverage also feeds back into the
design process, since the product may have to be designed to allow test
access (see Design For Test).
Test methods in the test plan state how test coverage will be
implemented. Test methods may be determined by standards, regulatory
agencies, or contractual agreement, or may have to be created new. Test
methods also specify test equipment to be used in the performance of the
tests and establish pass/fail criteria. Test methods used to verify
hardware design requirements can range from very simple steps, such as
visual inspection, to elaborate test procedures that are documented

separately.
Test responsibilities include what organizations will perform the test

methods and at each stage of the product life. This allows test
organizations to plan, acquire or develop test equipment and other
resources necessary to implement the test methods for which they are
responsible. Test responsibilities also includes, what data will be
collected, and how that data will be stored and reported (often referred to
as "deliverables"). One outcome of a successful test plan should be a
record or report of the verification of all design specifications and
requirements as agreed upon by all parties.
USABILITY TESTING
Usability testing is a means for measuring how well people can use some
human-made object (such as a web page, a computer interface, a
document, or a device) for its intended purpose, i.e. usability testing
measures the usability of the object. Usability testing focuses on a
particular object or a small set of objects, whereas general humancomputer interaction studies attempt to formulate universal principles.
If usability testing uncovers difficulties, such as people having difficulty

understanding instructions, manipulating parts, or interpreting
feedback, then developers should improve the design and test it again.
During usability testing, the aim is to observe people using the product
in as realistic a situation as possible, to discover errors and areas of
improvement. Designers commonly focus excessively on creating designs
that look "cool", compromising usability and functionality. This is often
caused by pressure from the people in charge, forcing designers to
develop systems based on management expectations instead of people's
needs. A designer's primary function should be more than appearance,
including making things work with people.
Simply gathering opinions on an object or document is market research

rather than usability testing. Usability testing usually involves a
controlled experiment to determine how well people can use the product.
1
Rather than showing users a rough draft and asking, "Do you
understand this?", usability testing involves watching people trying to
use something for its intended purpose. For example, when testing
instructions for assembling a toy, the test subjects should be given the
instructions and a box of parts. Instruction phrasing, illustration quality,
and the toy's design all affect the assembly process.
Setting up a usability test involves carefully creating a scenario, or

realistic situation, wherein the person performs a list of tasks using the
product being tested while observers watch and take notes. Several other
test instruments such as scripted instructions, paper prototypes, and
pre- and post-test questionnaires are also used to gather feedback on the
product being tested. For example, to test the attachment function of an

e-mail program, a scenario would describe a situation where a person
needs to send an e-mail attachment, and ask him or her to undertake
this task. The aim is to observe how people function in a realistic
manner, so that developers can see problem areas, and what people like.
Techniques popularly used to gather data during a usability test include
think aloud protocol and eye tracking.
Hallway testing (or hallway usability testing) is a specific methodology of

software usability testing. Rather than using an in-house, trained group
of testers, just five to six random people, indicative of a cross-section of
end users, are brought in to test the software (be it an application, web
site, etc.); the name of the technique refers to the fact that the testers
should be random people who pass by in the hallway. The theory, as
adopted from Jakob Nielsen's research, is that 95% of usability problems
can be discovered using this technique.
What to really measure

Usability testing generally involves measuring how well test subjects
respond in four areas: time, accuracy, recall, and emotional response.
The results of the first test can be treated as a baseline or control
measurement; all subsequent tests can then be compared to the baseline
to indicate improvement.
Time on Task -- How long does it take people to complete basic tasks?
(For example, find something to buy, create a new account, and order the
item.)
Accuracy -- How many mistakes did people make? (And were they fatal or
recoverable with the right information?)
Recall -- How much does the person remember afterwards or after
periods of non-use?
Emotional Response -- How does the person feel about the tasks
completed? (Confident? Stressed? Would the user recommend this
system to a friend?)
In the early 1990s, Jakob Nielsen, at that time a researcher at Sun
Microsystems, popularized the concept of using numerous small
usability tests -- typically with only five test subjects each -- at various
stages of the development process. His argument is that, once it is found
that two or three people are totally confused by the home page, little is
gained by watching more people suffer through the same flawed design.
"Elaborate usability tests are a waste of resources. The best results come
from testing no more than 5 users and running as many small tests as
you can afford." 2. Nielsen subsequently published his research and
coined the term heuristic evaluation.
The claim of "Five users is enough" was later described by a

mathematical model (Virzi, R.A., Refining the Test Phase of Usability
Evaluation: How Many Subjects is Enough? Human Factors, 1992. 34(4):
p. 457-468.) which states for the proportion of uncovered problems U
U = 1 (1 p)n
where p is the probability of one subject identifying a specific problem

and n the number of subjects (or test sessions). This model shows up as
an asymptotic graph towards the number of real existing problems (see

figure below).
In later research Nielsen's claim has eagerly been questioned with both
empirical evidence 3 and more advanced mathematical models (Caulton,
D.A., Relaxing the homogeneity assumption in usability testing.
Behaviour & Information Technology, 2001. 20(1): p. 1-7.). Two of the key
challeges to this assertion are: (1) since usability is related to the specific
set of users, such a small sample size is unlikely to be representative of
the total population so the data from such a small sample is more likely
to reflect the sample group than the population they may represent and
(2) many usability problems encountered in testing are likely to prevent
exposure of other usability problems, making it impossible to predict the
percentage of problems that can be uncovered without knowing the
relationship between existing problems. Most researchers today agree
that, although 5 users can generate a significant amount of data at any
given point in the development cycle, in many applications a sample size
larger than five is required to detect a satisfying amount of usability
problems.
Bruce Tognazzini advocates close-coupled testing: "Run a test subject

through the product, figure out what's wrong, change it, and repeat until
everything works. Using this technique, I've gone through seven design
iterations in three-and-a-half days, testing in the morning, changing the
prototype at noon, testing in the afternoon, and making more elaborate

changes at night." 4 This testing can be useful in research situations.
USER SATISFACTION
Computer user satisfaction (and closely related concepts such as System
Satisfaction, User Satisfaction, Computer System Satisfaction, End User
Computing Satisfaction) deals with user attitudes to computer systems in
the context of their environments. In a broader sense, the definition can
be extended to user satisfaction with any computer-based electronic
appliance. The term Computer User Satisfaction is abbreviated to user
satisfaction in this article. In general, the development of techniques for
defining and measuring user satisfaction have been ad hoc and open to
question. However, according to key scholars such as DeLone and
McLean (2002), user satisfaction is a key measure of computer system
success, if not in fact synonymous with it. Interest in the concept thus
continues. Scholars distinguish between user satisfaction and usability
as part of Human-Computer Interaction.
TESTING
Software testing is the process used to measure the quality of developed
computer software. Usually, quality is constrained to such topics as
correctness, completeness, security, but can also include more technical
requirements as described under the ISO standard ISO 9126, such as
capability, reliability, efficiency, portability, maintainability, compatibility,

and usability. Testing is a process of technical investigation, performed
on behalf of stakeholders, that is intended to reveal quality-related
information about the product with respect to the context in which it is
intended to operate. This includes, but is not limited to, the process of
executing a program or application with the intent of finding errors.
Quality is not an absolute; it is value to some person. With that in mind,
testing can never completely establish the correctness of arbitrary
computer software; testing furnishes a criticism or comparison that
compares the state and behaviour of the product against a specification.
An important point is that software testing should be distinguished from
the separate discipline of Software Quality Assurance (SQA), which
encompasses all business process areas, not just testing.
Today, software has grown in complexity and size. The software product
developed by a developer is according to the System Requirement
Specification. Every software product has a target audience. For example,
a video game software has its audience completely different from banking
software. Therefore, when an organization invests large sums in making a
software product, it must ensure that the software product must be
acceptable to the end users or its target audience. This is where Software
Testing comes into play. Software testing is not merely finding defects or
bugs in the software, it is the completely dedicated discipline of
evaluating the quality of the software.
There are many approaches to software testing, but effective testing of

complex products is essentially a process of investigation, not merely a
matter of creating and following routine procedure. One definition of

testing is "the process of questioning a product in order to evaluate it",
where the "questions" are operations the tester attempts to execute with
the product, and the product answers with its behavior in reaction to the
probing of the tester. Although most of the intellectual processes of
testing are nearly identical to that of review or inspection, the word
testing is also used to connote the dynamic analysis of the product
putting the product through its paces. Sometimes one therefore refers to
reviews, walkthroughs or inspections as "static testing", whereas actually
running the program with a given set of test cases in a given development
stage is often referred to as "dynamic testing", to emphasize the fact that
formal review processes form part of the overall testing scope.

Oops

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Oops

Transféré par

Droits d'auteur :

Formats disponibles

OBJECT ORIENTED PROGRAMMING AND SYSTEM DESIGN

Bjarae Stroustrup, The C++ Programming Language, (3rd and

Characteristics of Object Oriented Language data

CHARACTERISTICS OF OBJECT ORIENTED PROGRAMMING

Objects are the basic run-time entities in an object-oriented system.

The objects have two types of representation :

Here data and member functions are declared or defined externally

A class is a collection of objects of similar type. That is it is a collection of

The syntax for creation of objects is:

DATA ABSTRACTION AND ENCAPSULATION

Abstraction refers to the act of representing essential features

The wrapping up of data and functions into a single unit is known

Inheritance is the feature by which the objects of one class acquire

Polymorphism means the ability to take more than one form. An

It has the objectives:

over + loading= overloading

Binding refers to the linking of procedure call with the procedure to be

Static binding refers to making a link/relationships statically thro

Eg:While calling a polymorphic function the binding is done only at the

An object-oriented program consists of a set of objects that communicate

Creating class that define object and its behavior

Creating objects from class definitions

Establishing communication among them

Objects communicate with each other by sending or receiving messages.

C++ Data Types are classified as

Control statements are broadly classified into:

If the given condition is true then it will execute the statement;

If the test expression is true, then the true_block statements

When the switch is executed, the value of the expression is

We used a conversion statement index = mark/10; where, index is

loop that provides a more

concise loop control structure.

( i ) Initialization of the control variable is done first, using assignment

The value of the control variable is tested using the test

condition. The test condition is a relational expression. If the condition

On some occasions it might be necessary to executed the body of

On reaching the do statement, the program proceeds to evaluate the

BREAKING CONTROL STATEMENTS:

while ( test condition )

Two way branch

structures as function arguments.

6. It improves the efficiency of certain routines.

A pointer variable consists of two parts.

1. The pointer operator

It can be represented by a combination of * with a variable.

Eg: int *ptr;

Data type *ptr variable;

Eg: float * fpointer;

An address operator can be represented by a combination of &

A pointer is a variable datatype and hence the general rule to

A PROGRAM TO ASSIGN A CHARACTER VARIBLE TO THE POINTER

C++ allows functions to be referenced by a pointer. A pointer to a

General syntax of a pointer to a function is ,

return_type (*variable) (list of parameters);

void (*ptr) (float,float,int);

In the above declaration a pointer to a function returns void and takes

A PROGRAM TO FIND THE SUM OF THREE NUMBERS USING A

PASSING FUNCTION AS ARGUMENTS

C++ allows a pointer to pass one function to another as an

return_type function_name(pointer_to_function (other arguments));

Eg: float calculation(float(*)(float,float),float,float);

A PROGRAM TO DEMONSTRATE HOW A FUNCTION CAN BE PASSED