Ooad

OOAD
and
UML
( C to C++ Context)
Speaker: Animesh S Client: Juniper

Course focusses on OOAD-UML for
C++ Projects
Principles
of
Object
Orientation

Section Design Approach
Procedural Design Outlook
Data 1
Data 2 Simple data
Compound
Data
Intialization Complex Data
and
other Function 1
functions Function 2
Functions : Global : Any function can change

any data
Data : Global or purely Local to a function
It is never so in Real World
Better packaging is needed
To face current problems

Of Software Developer :
Maintenance
Lack of Flexibility in future releases
Accomodating Changes
during Project time
Re-Use of what is designed & coded
Make for one client. Adapt for others
Clear Demarcation of Responsibilities
between Members of Project
Team

Object Design OutLook File object f1 :
Knows contents of file1
Can operate on that file
File object f2 : ?
Report object r :
Knows report contents
File Object f1 File Object f2
Two month data
duly consolidated
Application Also formated for
W indow
Object w1
display
Report Object
r But no display code
Window object w1
Display characteristics
Font, color, size
User functions on
window
Minimize, close, move

Even a simple C++ program will fall under this category
Increasingly more projects are moving into C++ style
OO Approach from C style Procedural Approach.
In some projects an hybrid Approach of C and C++ ( and

even Assembly) code is resorted to, often for backward
compatibility and use of existing and legacy code.
It is not surprising to notice that some modern projects get

designed with OO, even though at coding level it will
compromise to a C / Assembly project. In such cases more
care is required in the OO design to stay within limitations
of using the C / Assembly code.
Section : Objects

FileName
FilePath
AN OBJECT IS A Length
SET File Object f1
OF Open
related Close
Seek
Flush
Data
And
Functions
File Object f1
Data :
File Name
File Length

File Path
Functions :
Open
Close
Seek
Flush
Think of an object as a fancy variable; it stores data, but you

can “make requests” to that object, asking it to perform
operations on itself.
In theory, you can take any conceptual component in the

problem domain you are trying to solve (things, services, etc.)
and represent it as an object in your program.

Every Object has IDENTITY
Every object is unique, in that it is distinctly

identified by an object identifier.
It can be an object itself : f1
Can be a pointer : File* p1 ;
Can even better be a Reference : File& r1 = ……;
File Object f1
File Object f2
Window Object w
Such a variable which refers to an object instance is called

Object Reference or identifier
f1 happens to be a identifier to the Object instance

The object identity is not used by the current object.
Languages provide for one automatically generated Field Value :
this -Java , C#, C++

Me - VB.Net )
so that the current object can refer to itself.
But other objects need to refer to this object.

That is why an unique object reference / identify is needed.

Where is a Object Reference declared and stored ?
Will it be in the Stack only ?
Will it be in the Heap only ?
Will it be in either place ?

An object has FIELD Attributes
( the Data Members of Object)
Every object has one and often more Field Attributes
Which means,
Object instance occupies Memory ( RAM)
by providing slots for the fields

The Fields provide
a characteristic to the object.
File length
Small or large file
File path
Where is it located ?
The data members of an object

are its Fields
Properties -> Are like Fields

But they are SMART FIELDS
They help the object control the way
Getters & Setters operate
Get : querying of value of attribute &

Set : modifying of attribute value
An object holds State

The value of its Field at
a specific point of time
is its state.
State is the nature

of Fields,
and is one which

keeps changing
due to dynamic nature

of a software.

State is important for us to
understand
how the object behaves.

Procedural Design:
Care only about Application State.
Object Orientation:
Care about Object States too.
Combine all Object states,

You get Application State

State change : how will it occur ?
A method (function) called by a client object changed state

f1.fx ()
A direct assignment can change state

f1.v1
A method (internal function) in the same object changed state
Point to Ponder :
A file Object.
Does it undergo state changes ?
Clue : File size :
Empty,
5 records,
100 records,
200,000 records.

Empty
Another Clue : File is open, File is closed.
Every object has Behavior

(the Functionality of each Object)
Every object has a behavior.

Behavior is related to its functions

File object f1
Open : Make it ready for file operations

Close : Flush it and
disallow any more
File operations

Behavior
is seen by the way the object
acts and reacts to requests.
Acting : Internal : Like flushing before close
Reacting : Externally visible behavior
: Like close
FileName
FilePath
Length
File Object f1
Open
Close
Seek
Flush
Each Method
exhibits
One behaviour Collectively Methods provide the
Behaviour of the Object
Behavior is exhibited
when Method is executed

Object Behavior
File Open, Close, Seek, Read
Window Open, Close, Minimize, Resize
Report Show, Order-Ascend, Show_Summary
Employee Join, Promote, inc_Salary, Separate
Browser Render, Submit, Open, Close …
Methods : Signature and Code
Signature : What does it do. Name

With what input ? Parameters
Is there an output ? Return Value
Code : How
How exactly does it happen
Algorithm
Business Logic body

Method :
Function, the only execution piece in C# /Java / C++
Procedure ( say in VB.Net)

Routines
Operation :
Only interfacing info

Only Signature

DISTINGUISH BETWEEN
METHODS
OPERATIONS
BEHAVIOUR
BEHAVIOUR : The way is acts, reacts
Example : File opening Behavior
Action : Load file, set up buffer

Reaction : Return the readiness
OPERATION : The way we know it from outside
void Open ( Mode m)
METHOD : The way it is (designed) inside

Incidentally the code block contains the Attribute Field
structure which is represented as Attribute values
Can objects work alone in a System ?
No. they need to co-operate.

A System is a society of co-operating objects.

It is our attempt to control the behavior
of one object from another
that makes us prepare
Applications out of OOPS

From Where ?
At minimum : One Client object, calling methods on a target

Object
In practice : Many such objects co-operating to deliver an

Application
TRAFFIC CONTROL SYSTEM

TRAFFIC SIGNAL :
Objects
FIELDS ????
METHODS ?????
CONTROLLER :
FIELDS ??
METHODS ????
Controller - Controlled
Remember : A project with only “just objects” and NO

Control Object
is not a well designed Project.
Objects may have different kind of responsibility
They may play “State Keeping Role” : Entity object

The role of keeping data
and allowing its proper manipulation only
Such objects also contain methods to store their state in

a permanent storage such as a File or DBMS
(such as RDBMS )
They may play “Flow Control Role” : Control

object
Controller - Controlled
The role of allowing controlled access

to a specified object

They may even play the role of facilitating
User interaction
: Boundary
object
( Presentation Role)
The role of GUI based interaction
SOFTWARE OBJECT
It is a small piece of software.

Not the whole Application
A software object contains

values and functions.
which only relate to
an unit of Representation

one ROLE
A software object represents
played by the system
just
Many such ROLEs ( Objects)

make a System.
File Object(s) , Report Object , Window Object :
Report Generation System
Traffic Signal objects, Traffic Control object
Traffic Management system
Note: Every object should play only one role.

If you have a badly designed object, it will be a bloated
object, playing many roles instead of one.
In fact every C or Assembly project has one single

object, the Application object. It plays many roles

and so does not have a significant behavior. That is why
Project systems are moving more towards OO.
OO SOFTWARE PROJECT
Many objects in Action

Each Play specific Role
Objects live for their lifetime

One Starter routine boot-straps
software
Objects invoke methods on other

Methods result in Behavior
State change in objects occur

After invoking main, the C++ project should pass on
control to
various other flows,
each relating to invocation in sequence
among a set of objects.
You may designate each such flow as a “Menu”.

All possible menu choices will be displayed by main.
Section : Define
DEFINING the SOFTWARE OBJECT

OO – About defining One Object at a time

OOAD – Designed to make them work together
Values such as age are defined as

INTEGER Type
or
Long Type
These are primitive types
int age;
Rules of object apply to age ?
Unique ?
Has Field(s) ?
Hold State?
Exhibits Behaviour ?
Operations ?
Primitive types :
General Field – Not Domain specific

General Operational Behavior
Primitive types :
General Attribute – Not Domain specific

General Operational Behavior
Primitive Types in C++ includes
int, short, long

float, double
char
C++ Primitives in a typical 32 bit Environemnt : Say

VC++
Range
Type Bytes Range (signed) Literals
(unsigned)
false,
bool 1 0..1
true
char 1 -128..+127 0..255 'a'
short 2 -32,768..+32,767 0..65,535 none

-
int 4 0..4,294,967,295 23, 0xAF
2,147,483,648..+2,147,483,647
- 23L,
long 4 0..4,294,967,295
2,147,483,648..+2,147,483,647 0xAFL
Type Bytes Range Accuracy Literals

3.14F
float 4 -3.4E38..+3.4E38 6-7 digits
6.02e23F
- 14-15
double 8 3.14 6.02e23
1.7E308..+1.7E308 digits
long
10 ??-?? ?? digits
double
Characters
Characters are stored in one byte (char) or two bytes wchar_t.
char is an integer type
What about “pointer types” ?
These are handles which work as an indirection

to a primitive type

What about “References” ( declared as something like
int& )
which is available in C++ ?
These are also pointers, but with more restriction in

the way the pointing is handled. It always needs
initialization
( so there cannot be a null pointing) and once
pointed, no navigation or re-pointing is permitted.
int originalvalue = 100;

int& referredvalue = orignalvalue; //initialised
You cannot separate the reference from the referent.

Unlike a pointer, once a reference is bound to a primitve
attribute, it can not be "reseated" to another attribute. The
reference itself is not an attribute (it has no identity; taking the
address of a reference gives you the address of the referent;
remember: the reference is its referent).
References to objects provide a convenient way to access

objects by reference but use the same syntax required to access
objects by value.

Primitives in other Languages
We need to build CLASSes from primitives

Such a CLASS will have
Fields
Methods
Developer ( User) designed Types : Class
Fields as required
Operations as needed
Objects are to be

defined first as
CLASS
class X {
…..
…..
};
CLASS is a Type ( Data Type)

which defines both the
Structure (What Data to hold)

and the
Related Behavioral Methods

Class
Attribute
Common
Code
Service Block
for
File Object f1 Class
File File
FILENAME : String : __________

FILEPATH : String : ___________
LENGTH:Int : __________
Open : Void : { .............. }
Close : Void : { .............. }
Seek ( P1, P2 ) : int (.............. }
File Object f2
Seek(P1,P2):int{……………}
Class – Object : How different ?
A class does not hold state. Objects hold state.
Class is loaded, just once, in CODE BLOCK of RAM :

CODE BLOCK of the Process
Object instances are in DATA AREA of RAM

DATA BLOCK of the Process

The object must be
instantiated
and be alive first Instantiation->
Instantiating a File class object :
File f1; // Declare,

instantiate
File* p1 = new File;

// point,
instantiate
now or later
File& r1 = new File;

// refer, must
initialize there
Objects are many

They are found in any run-time situation

Every Object instance occupies DATA Memory
Every CLASS occupies

CODE area of Memory
Just one per class
even if there are many
Objects of the class
Creating Instance
From CLASS to OBJECT
Instance Creation
Instantiation
OO : Create
OOPS : Language specific creation

Instantiate
( Instance Creation )
Constrcuctor
Obtains the A special M ethod
Unique File Object f1
File ( ) { .. }
ID as a
Reference
Caller
Object
LANGUAGE SPECIFIC SYNTAX ->
LIFE TIME MANAGEMENT
Constructor is a special method

which maps to a CREATE message
The object brings itself to life

against a Constructor call
A class does not hold state. Objects hold state.
The object must be

instantiated
and be alive first Instantiation->
Pointer to an Object : Heap creation
Student* p;
p = new Student(1002);
p->displayResult();
InLine Creation
Situation 1:
int main () {
Student s1;
// Created in STACK of main

}
Situation 2 :

class University {
Student s1;
// Created WHEREVER University Object is
created
// Embedded Object
….
};
Requests can be passed on as

messages thereafter
The order of requesting depends on the client

It has nothing to do with the order in which
Services are defined in the Class

Constructor : Language Specific Issues ->
There could be more than one way

in which a creation message is formed
Student Object
1. Construct from parameter passing
Student ( RollNo, Name, Course …..) ;
2. Constructor bring up GUI
Student ;

3. Find existing data in file,
Passing only Student RollNo
Student ( 1021) ;
The object brings itself to life

against a Constructor call
Student& r1 = new Student(1002);
In the corresponding class :

class Student {
…..
public :
Student() {…}
Student( int RollNo) { …}
….
};
So there is a possibility of having

more than one Constructor
Importance of Constructor Design
1. How many alternate ways to create the

Object Instance
2. How to make the object come up to its
initial State

class Student {
String name;
…..
public :
Student() …..
Student ( string n ) : name(n) { … }
// Use Member initialization List , for
efficiency
….
};
The member initialization list provides an alternate syntax for

initializing members of a class within a constructor. It is a
comma-separated list of members along with their initial values,
separated by a colon from the end of the parameter list and
before the opening bracket of the constructor body. Some or all
data members could be specified in the initialization list.
For members that are themselves classes, they should always

be initialized in the member initialization list.

From a performance perspective, it is important to note that
the sub-object is not separately created and copied , and it
should be part of the Member Initialization List.
Destructor ( or Finalizer )
is a (call back kind of)

method which
is not explicitly called
It GETS CALLED just before the

killing of the object
class Student {
String* sp ;
…..
public :
Student() { sp = new String(….) ; }

….
~Student ( ) { // Destructor
delete sp ;
}
};
Each object has its own memory made up of other

objects. Put another way, you create a new kind of object by
making a package containing existing objects. Thus, you can
build complexity in a program while hiding it behind the
simplicity of objects.
Constructors are procedures that control initialization of new

instances of a class. Conversely, Destructors are methods that
free system resources when an instance references leave scope
or is set to Null.
The constructor in C++ allows you to guarantee that variables of

your new data type (“objects of your class”) will always be
properly initialized. If your objects also require some sort of
cleanup, you can guarantee that this cleanup will always happen
with the C++ destructor.

In modern Language systems like Java and Dot Net the
destructor call would be non-deterministic
Together, constructors (special methods

that allow control over initialization) and
destructors support the creation of robust
and predictable class libraries.
OO Languages have made provision

for the developer to indicate
End of life of an object,
Implicit : Out of scope
{
Student s1;
// constructed, fairly
efficient
// Pass on messages to s1
} // s1 goes out of scope
// Very efficient stack
deallocation

Explicit : Null setting through delete operation
{
Student* p;
p = new Student();
// Not the best of
performance
// Pass on messages to p
delete p ;
// Not so efficient
compared to stack de-alloc
// Block continues;
// do not pass messages to p
}
Efficiency Issues with stack and heap
Lifetime of every object is

From its CONSTRUCTION

Till it is released for destruction
The object lives between these two milestones,

and messages can be sent
during this life time.

Language Specific : Destructor ->
Service
Service to be provided by the Class is the

Primary Consideration in Choosing a
Class

Service
A description of a work.
Design of Class starts with this.
Describing SERVICEs are part of

Definition of Objects
File class : Services are :
open
close
seek
read
write
As you design a Class

you are designing a Server
Service is the action by a Server.

Service Design is the core in Object Design
A Server object would have

one or more services.
Each service gets executed

only when a client ( object)
requests it through a message

Let us be very clear :
Where does the code (declare-instantiate-use) appear ?
Is it inside File class ? NO

Inside a client class :
class SomeClient {
….
void someFunc () {
File f1 (….. ) ;
f1.open(…);
f1…..
f1.close( );
};

How does the above method get invoked, if it the first need of
the application ?
int main ( ) { // Boot strapper
SomeClient s;
s.someFunc() ;
….
Why not hold data in structures

instead of designing classes for objects ?
Student Structure Student Object

Members :
Name Same Attributes
ID
Institution
Course

Year
Subject 1 Mark
Subject 2 Mark
Exam Result
Methods : ( If Student is a C structure, such methods

cannot exclusively be part of the struct . But it is
possible when it is a C++ class)
Methods : Designed based on Service
Make First Time Entry

Creational Behavior
Accept Marks
Validating Behavior
Update the Result

Business Behavior
Print Mark Sheet

Business Behavior

Authorization Check
Non-Duplication through State
Name
ID Design Fields only based on
Institution Method and its service
Course
Year First discover the Services
Subject 1 Mark
Subject 2 Mark
Exam Result
PrintedFlag
LANGUAGE SPECIFIC SYNTAX ->
So in OO Software :
Objects are instantiated
Class : encapsulate types, data (variables), and

operations.

- export some entities (operations)
- hide their internal details
- Objects are instances of Class
data
operations Outside world

class object
data
creates
operations
Object pass on Message to other Object(s)

Message is mapped to invoking Methods
Every object has a type. Using the parlance, each object is an

instance of a class, where “class” is synonymous with “type.” The
most important distinguishing characteristic of a class is “what
messages can you send to it ? ”

Message
Class is designed based on service

- Design Time : Create type
Object is instantiated first

- Runtime : type -> object
Messages are passed to request Service

- Major activity at Runtime

object -> object
Communication between
two entities
with a Message Packet

that gets delivered
s1.displayResult();
or
r1.displayResult ();
or
p->displayResult () ;
Software Messaging is :
Communication between two entities
Ideally a round trip communication

between
One object and another
Method invocation: Message Passing

Method Execution : Object Behavior
Sender requests something

By forwarding a MESSAGE
Receiver processes the message
Window
File Object f1
Object w1 Message Passing
f1.open (..... )
Code in a method of Window Object :
f1.open(….)
But where is the code of open Method ?

HOW DOES THE RECEIVER
PROCESSES THE MESSAGE ?
HOW DOES THE Target Object

PROCESS THE MESSAGE ?
Object has its own State Value

Parameters provide additional information
Processing is done with these
Return Value is computed during the process
Receiver Object :
1. Already knows its attribute and state values
f1.open( … ) : Need not contain

File Name
File Location

Right Design of parameter : void open( String mode)
For the call : f1.open( “rw”)
Wrong Design of parameter :

void open( String fileName, String mode)
For the call :

f1 = //declared and created
// f1( “filename”, “rw”);
f1.open( “filepath+name” , “rw”)
Receiver Object
2. May use the parameter
f1.open( “rw”, ….)
During such a processing

Receiver may carryout any
internal action,
using its attribute values
and any of its methods.

3. Returns control,
plus result - if any.
void open(.. ) – Returns control

SomeType open (..) – Returns value
WAYS OF USING OBJECTS
If Student is a CLASS

I. Code in some other object (class) can
CREATE an instance
Student& r1 = new Student();
II Using Attributes :
Can read them.
Can Change values.
Subject to it being accessible to the client object.

Private Fields may not allow this
r1.name=”XYZ"
III Invoking Methods
Client object can invoke all exposed methods.
r1.displayResult()

IV Objects can be passed as parameters
A Method in some class has the signature,
compare( Student sa, Student sb )
For the above signature, actual method call will be :
rankingObj.compare( s1, s2) ; // pass by value
where s1 and s2 are

two Student object references.
Alternate Design :
compare( Student* pa, Student* pb )
rankingObj.compare( p1, p2) ; // pass by

pointer
rankingObj.compare( r1, r2) ; // pass by reference

BigClassType &func( BigClassType &objname )
{
objname.doSomething();
// Note member-of operator(.) is used.
objname.SomeData = 7; // Data passed by non-const

// reference is modifiable.
return objname;
}
The important points about passing objects to a function by

reference are :
• The syntax for accessing members of class, struct, and
union objects is the same as if they were passed by
value: the member-of operator (.).
• The objects are not copied prior to the function call; their
addresses are passed. This can reduce the overhead of the
function call.
V. Objects can be return values
Student* findBetter (Student s1, Student s2 )

The actual call in some object will be
Student* b = evalObj.findBetter( s5, s7);
Better Design
Student& findBetter ( Student& s1, Student& s2 )
Functions that return a reference need only accept the address

of the object to which they refer, instead of a copy of the
whole object.
What is the SENDER- RECEIVER Equation ?
Sender : The Client object

Can access attributes of Receiver : If exposed

Can call Methods of Received : Whatever is
exposed
Method might carry parameter
Method may return a Value
Object has its own State Value

Parameters are ideally designed to be Objects

Return value may be a primitive / Object / void
So in OO Software :
Objects are instantiated
Object pass on Message to other Object(s)
Message is mapped to invoking Methods
Message Parameters : Better design as Objects

Message Return Types : Can be Objects too

Message is not a new idea
Message Variations:
Interrupt, Signal, Event
Messaging Variations:
One-Way Message,
Time Out Message

Section : Hide, Abstract, Encap
INFORMATION HIDING
When information hiding is in effect,
users of that object see only
the externals of the object
How much should we know about a TV

when we use the Remote Control ?
On / Off : Yes
Volume Control : YES
Potentiometer which control volume ?
Channel Change : Yes

Which frequency for a channel ?
Thus we see that most equipment

and apparatus provide
Information Hiding to the end user.
OO Software also should provide

a high degree of information hiding
to the user of the OO software
When we design class,
we are not talking about ultimate end user.
Who is the “user” of the class I design ?
Another Developer
I define : Other Developer :
class Student { // s1 – Instance of Student
public : s1.Name = “Nobody”;

char * Name ; INTEGRITY OF DESIGN ?
……
…..
};
I better define : Other

Developer :
class Student {
// s1
private :
– Instance of
char* Name ;
// Any non-public visibility Student
……
….. s1.Name =
“Nobody”;
public :
INTEGRITY OF
void changeName(..) DESIGN ?
{ }

changeName
executed on caller
}; check.
ID Check
if ( ….. ID = p )
else …….
I should “hide” information from the other developer
Why ?
To hold the integrity of my Design
s1.name = Change name

s1.course = Change course

s1.result = “FAIL” Assign instead of computing
Do you think all the above

Hold integrity of my STUDENT object ?
FileName
FilePath
HIDE : Length
File Object f1
W hich M ethods Open Write
are to be Close Read
HIDDEN ? Seek
Flush
ChangeLength
Classes are designed

with the facility of Information Hiding
in the form of
private,
public and
other
ACCESS SPECIFIERS
restricting access to its members.

Additionally one can achieve better performance and still maintain
some access control by declaring the necessary classes as friend
in its declaration.
Note that in a class :
You can declare global functions a friend : Not a OO measure
You can declare selected functions of another class a friend

: Needed when you decide on specific functions
only to have access to the private members of your class
You can declare another class as friend, which means all its
methods get access to private members of your class

Also note that friend in C++ is not transitive. This means friend of
a friend is not a friend and will not get access to private members.
Further note that friendship is granted by your class. There is

no way that the other class can “take” friendship.
Call these as
Access Specifiers
Or
Visibility Specifiers
DO not mistake
Visibility
with
Availability

s1 object has a private attribute : result
Available ?
Visible ?
Usually private members are visible only to the code inside the
Class
Attributes can be designed

to be private,
when we need controlled access

to
READ and
WRITE
operations on them.
Hidden Attributes

Methods can be designed
to be private,
when they are meant to provide

low level services to
other
non-private methods of the Class
Hidden Operations
= private methods
• A public element is visible to all elements that can access the

contents of the namespace that owns it.
• A private element is only visible inside the class that

owns it.
Where Friendship is granted, the granted element ( a global
function, a method of a class or all of a class code) also gets the
visibility.

Private access modifier is applicable only to the members of a
type.
It restricts access to the members within the type itself apart
from those that are declared as friends.
Make suitable decision about

which Methods Are to be HIDDEN?
FileName
File Path
HIDE:LENGTH
File Object f1
Open
Close
Seek Write
Flush Read
ChangeLength

Plan ACCESS SPECIFIERS
At suitable stage
in the DESIGN Phase
In C#, VB.Net … : Class, Interface, Events, …

And Fields, Properties, Methods … have Access specifiers.
In Java class, interface

And Attributes, Methods have Access specifiers
Hints to Design :
READ-ONLY Attributes : Can these be public

Other Attributes : Should these be Hidden ?
Methods which only return value

Should these be public ?
Methods which change the State ?

Can these be public and still

control integrity ?
Encapsulation
Enclosing something within a Capsule

It is the enclosing of
Field declarations : ->

Primitive type = Value type
Referential Type
Referenced by Field
Services : Methods
High level and exposed services

Usually public
Low level hidden Services

Can be private
All methods :

Encapsulate with
Appropriate parameters
Appropriate return type
With the Hiding of these from the view of others

who need not know about it.
Encap : Also need to decide
FROM WHOM TO HIDE
Excessive Encapsulation : Performance HIT

Lack of Encapsulation : What effects?
To Care during Encapsulation
Designer looks at Objects,

Defines Class
Provides for State Management

and Behavioral Methods

Hides the relevant members,
and plans
from WHOM to Hide
( Expose to Anyone and Every Object code,

Friends in same Subsystem and Assembly,
Future Designers who extend this class, or None )

CHANGE MANAGEMENT AND ENCAPSULATION :
I. Unit Testing :
The behavior of an object can be changed and tested

independent of all other objects.
One class, when designed can be Tested immediately
II. Maintenance :
A developer can change most of private portion of the

design without consulting developer of any other class.
Other C++ Aspects in Encapsulation :
A const member specifies that the value of the attribute or the

local variable cannot be modified

C++ Function can end with a
const declaration
MEMBER FUNCTIONS WITH const 'this' POINTER
v When you place the const modifier after the declaration of a

member function, the result is that the function's '
‘this’pointer is declared to be a const.(If the function is not
declared 'inline', the const keyword must also be placed after
the Function’s definition).
v When a function's ‘this’ pointer is declared to be a constant

the member function cannot modify, data member of the
object to which it belongs and cannot call other member
ftmctions unless they are also declared to be member
function with constant ‘this’ pointers.
Example: // Member function which returns const ‘this’ pointer
#include<iostream.h>
class Player {
private:

int strength;
public:
void setStrength( )
// this modifies the private member
// cannot be declared as const function
{ strength=12; }
void printStrength( ) const
{ return strength; }
};
void main()
{
Player p;
Player *ptr=&p;
Ptr->setStrength( );
Ptr->printStrength( );
}

CONST CORRECTNESS : FAQ
What is "const correctness" ?
It means using the keyword const to prevent const objects from

getting mutated.
void f1(const String& s)
Declaring the const-ness of a parameter is just another form of

type safety. It is almost as if a const String, for example, is a
different class than an ordinary String
You can also use references to declare a const reference to a

variable or object. A reference declared as const retains the
efficiency of passing an argument by reference, while preventing
the called function from modifying the original object.
void PrintIt ( const &Student)

Abstraction in Practice
ABSTRACTION means
a simplified representation
of real world objects and concepts.
Abstraction in Teaching :
Algebra and Calculus are taught in an abstract way.
Abstraction in Conceptualization :
When a child plays with a toy train, it is Abstraction.
Abstraction in Visualization :
What we have to model a building

even before it is built,
this is also Abstraction.

Abstraction in Operations :
Remote Control Of TV: Abstraction of its Usage

Running an Automobile: Services are abstracted so that users do
not need to learn its internals and all complex technology :
Abstraction in Software Application
An abstraction to the User,

when presented with ease of use.
Abstraction in Class Level Design :
A Class is Designed with Abstraction,

so that other Designers
who have to use this class
are made to understand its usage
in simplified manner
Remember that Abstraction in classes is provided by the

Designer, so that other can understand and make use of the
class in a better way.

HOW ? :
Class Name : Meaningful, Short, Simple
Public Members :
Meaningful Names : Self Explaining
Parameters :
Suggestive Names
Proper Coupling
A S/W Engineering Principle
Fields : If public, think twice
State holding Fields

Cohesive :
A S/W Engineering Principle
If needed, a Field is typed as
another Class

Enumeration :
Making the values of variables to be programmer-friendly

goes a long way in improving the degree of Abstraction.
Enumerations provide a convenient way to work with sets of

related constants and to associate constant values with names.
For example, you can declare an enumeration for a set of
integer constants associated with the days of the week, and then
use the names of the days rather than their integer values in
your code.
enum direction { east,west,north,south) } ;

direction dir=east;
cout<<dir;
The output in not east but 0, because C++ I / O treats

variables of enum types as integers
Ø Enumeration also enables extra amount of type checking in

the compiler. Using #define is not an ideal situation
enum COLORS {
BLACK,

BLUE,
GREEN,
RED = 4,
YELLOW = 6,
WHITE
};
Considerations in achieving Abstraction ->

Types of Abstraction

How to Achieve Abstraction ?
Abstraction is achieved when

a client of an Unit need not
know the whole to work with
that Unit
Abstracted
Make it Simple
For the Client User
To Understand
Encapsulated
Encapsulation is
achieved when the
client of that Unit is not
able to know more
than what is required
to work with that Unit

INFORMATION HIDING
SIMPLE & CLEAR Naming
PROPER GROUPING
More on Abstraction + Encapsulation
Every Class
All these are
The Sub to be
System Each Abstracted
Thru
Encapsulation
d
Project

Sub_System Itself
Language Aspects in Encapsulation :
Properties
Properties are accessor methods whose job it is to retrieve and
set the values of fields. It provides a way to protect a field in a
class by reading and writing and also support object-oriented
concept of encapsulation.
C# specific
Performance hint for OO Software :

Create Instance through best alternative
Keep Object Lifetime to be optimum
Let them live only as long as required
Design hints for OO Software

Abstraction : simple to understand by
all in the team
Hide : As necessary; Visibility is hidden
Encapsulate : Class level; Sub-System
Level
A simple look at TWO of the Many Abstraction

Mechanisms :
1. Overloading
2. Inheritance

Over Loading – A step towards Abstraction
POLYMORPHISM
POLY = Many MORPH = SHAPE
OverLoading : A Feature towards Abstraction
POLY = Polymorphism
Many Dynamic Static
Polymorphism Polymorphism
MORPH Overriding Overloading
= dispatch
SHAPE
Type polymorphism
Templates in C++
Generics – Java 1.5 , Dot Net 2.0

Object systems may allow
OVERLOADING - Polymorphism
at function level.
class Payslip {
// Other members such as EmpNo, Salary etc.,
void printslip (Screen s)

// algorithm sends payslip to screen
// takes care of screen specific values
void printslip (Printer p)

// algorithm sends payslip to printer
// after User interacts with print dialog
// honors no-of-copies, landscape mode etc.,
};
Object systems understand overloading polymorphism
Other object which associates with

Printslip object ps can
call either of the methods

ps.printslip ( pr ) ; // printer object as parameter
ps.printslip ( scr ) ; // screen object as parameter
Overloading has a real life counterpart:
Play is overloaded
Play ( Cricket )
Play ( Tennis )
Play ( Child )
Overloading is the creation of more than one method, instance

constructor, or property in a class with the same name but
different argument types.
Overloading is especially useful when your object model dictates
that you employ identical names for procedures that operate on
different data types.
Overloading makes it easier to use properties or methods

because it provides a choice of data types that can be
used.

You create an overloaded member for a class by adding two
or more properties or methods with the same name. Each
overloaded member must have different parameter lists
Overloading is one of ways in which

POLYMORPHISM is realized in OOPS.
Methods are overloadable
Constructors are also

Methods ( Functions)
Hence they also

can be overloaded
Sometimes operators are

Overloaded
A variable ( Attribute)
Cannot be overloaded
In function Examples :
overloading class X {

The name of the void fa ( int, int) {… }
function is to be the void fa ( int ) { … }
same
int fa ( int, float) {…}
The parameter list int fa ( float, int ) {…}
must ……..
have a difference };
class Y {
The return type does
not matter, as long as int add ( int, int ) {...}
the above two rules float add ( float, float) {….}
are satisfied. X add ( X, X ) { … }
…
};
When we have overloaded Constructor,

it implies that the User of this design
has more than one choice,
in deciding the way the object is created.
Student Object
1 Construct from parameter passing

2 Constructor bring up GUI
3 Find existing data in file,

Passing only Student ID
Polymorphism is based on ( Code )

Sharing with Differentiation Principle
In general all compilers have

numeric ( int, short, long etc)
types to be overloaded with
operators such as + and –
Further some languages allow +

to be used for
alphanumeric concatenation.
These are examples of compilers

( not programmer logic)
performing operator overloading.
Designer based Overloaded operator :
Box class : + means ?

Student class : > means ?
What are the benefits of operator overloading ?

By overloading standard operators on a class, you can exploit
the intuition of the users of that class. This lets users program in
the language of the problem domain rather than in the language
of the machine.
The ultimate goal is to reduce both the learning curve and the
defect rate.
Possible operator overloading include almost every operator

availabe in C+. except some not-allowed operator overloads.
Read the Link to get coding samples
Overloading is the ability to define methods, or operators that

have the same name but use different data types. Overloaded

procedures allow you to provide as many implementations as
necessary to handle different kinds of data, while giving the
appearance of a single, versatile procedure.
What is the advantage of overloading ?
Each method is designed

to work with respect to a context.
All the more better design if the context is an object.
Class : Payslip
Overloaded Methods Are :
Printslip ( Screen s )
Printslip ( Printer s )
Other Features of C++ which can help towards better

abstraction during Design
1. The :: operator : To provide scope resolution. Also to

provide for not-inlined method declaration in classes

2. The inline function which can be better alternative to
MACROS, which may have side effects, breaking the very
idea of Abstraction
3. See Sample on bad effect of Macros and the way to avoid it
4. Work Horses of cin, cout and help from Manipulators. Due

to these the readability of code improves greatly. We also
have clog and err.
See this link
5. Default Arguments, which can abstract the way a function

call is coded
See this link
Inheritance
In real life what does Inheritance mean ?
Something to do with PASSING ON the WHOLE

What is Inherited ? ---------------
#
IN OO, Inheritance is something
BETWEEN classes and another class

( A DESIGN – Compile Time feature )
NOT BETWEEN one object and another object

( NOT a RUNTIME feature )

A Class A Class B
-V1 Two Fields Three Fields
-V2 Two Methods Three Methods
+fx (... )()
+fy (.... )()
When we inform the compiler that Class B is inheriting
B from A :
-V3
+fz (... )() it implies that all members of class A ( including private
members), except the Constructor Members are
inherited into class B
Private Members, though inherited, will remain as not

visible. So class B cannot directly have private members
visible in its coding. However a non-private member of
class A may still access the same
Object of A Class Object of B Class

Instantiate Instantiate
A a1; B b1;
a1 = new A () b1 = new B ()
Memory Map in RAM Memory Map in RAM

Why should we go for Inheritance,
Why not two separate classes as the design ?
Allow ance Allow ance W orkAllow ance
W orkAllow ance
Inheritance promotes REUSE of Design.
Looking at Payroll as an OO Application

Some of its classes will be :
Employee_Info Allowance Deductions
Payslip
Why FOUR classes ?

Why not Five ?
Why not Three ?
Without a formal OOAD Mechanism

we have to empirically visualize the above
only on heuristic basis.
Now try to visualize the attributes

in each class
and the methods in each class.
Will each class have constructor ?

Will there be more than one constructor ?
Still some logic ( many details are too )

missing in the above design.
Where do we see the message

passing between the objects ?
When are the object created ?
When is it destroyed ?
What kind of ( menu ) sequences

pass through this object
as message requests ?
We do need a methodology
which can guide us through
the process of arriving
at a complete design.
This is where OOAD comes in.
Section : OOAD Methodologies

Fitting in OOAD Methodologies
Fitting in UML
DFD OOPS,
SSAD Non-UML
Methodologies
Non OOAD
Methodologies
OMT
Object Modeling
Technique
OOPS
James Rambaugh
OOAD
Methodologies
BOOCH
Grady Booch
Unification
By
Rational Corp
Objectory
OOSE
Iver Jacobson
UML 1.1, 1.2

Speaker: Animesh S Evolving UML 1.3, 1.4, Client: Juniper
Other Authors 1.5
And
Methodologists
Industry Input
2.0
The spirit and soul of UML
Every complex system is best approached through a small set of

nearly independent views of a model. No single view is sufficient.
The best models are connected to reality.
The Unified Modeling Language (UML) is a

language for specifying, constructing, visualizing,
and documenting the artifacts of a software-intensive system.

Modelling Language.
A model is a description of a physical system with a certain
purpose, such as to describe logical or behavioral aspects of the
physical system to a certain category of readers.
UML ( till 1.5) defined the following graphical diagrams:
• use case diagram
• class diagram
• behavior diagrams :
• statechart diagram
• activity diagram
• interaction diagrams :
• sequence diagram
• collaboration diagram
• implementation diagrams :
• component diagram

• deployment diagram
These diagrams provide multiple perspectives of the system

under analysis or development.
Good models are essential for communication among project

teams and to assure architectural soundness.
We build models of complex systems because we cannot

comprehend any such system in its entirety.
Later versions of UML
Diagrams as per UML 2.0

Diagram
StructureDiagram
BehaviourDiagram
ComponentDiagram
ActivityDiagram UseCaseDiagram StateMachineDiagram
ClassDiagram PackageDiagram
InteractionDiagram
ComponentStructureDiagram
SequenceDiagram
InteractionOverviewDiagram
DeploymentDiagram
CollabrationDiagram
TimingDiagram
UML 2.0 is based on OMG’s Model Driven Architecture (MDA) :

An initiative is an evolving conceptual architecture
It represents an approach and a plan to achieve a set of

cohesive set of model driven technology specifications.
The UML authors promote a development process that is

Use Case driven,
Architecture centric,
and iterative and incremental
The UML is an evolution from Booch, OMT, OOSE, other object-

oriented methods, and many other sources. It should be made
clear that the Unified Modeling Language is not a radical
departure from Booch, OMT, or OOSE, but rather the legitimate
successor to all three, with more divergent and convergent
ideas being added while it is a chasing Target.
An Artifact represents a physical piece of information that is

used or produced by a software development process. Examples
of Artifacts include models, source files, scripts, and binary
executable files.
While the UML does not guarantee project success, it does

improve many things.
For example, it significantly lowers the perpetual cost of training

and retooling when changing between projects or organizations.

It provides the opportunity for new integration between tools,
processes, and domains. But most importantly, it enables
developers to focus on delivering business value and gives them
a paradigm to accomplish this.
USECASE
DRIVEN
APPROACH
Section : About Use Case
An Use Case is
a broad area of functionality
of a system

An Use Case is a kind of usage
of the system
in which external objects (called actors)
interact with the system.
In Use Case analysis,

the system is treated
as a black box,
so that all Use Cases

must be visible,
in some sense,
to the actors.

Section System Level Use Case
Rank 0
Here we define the overall Goals
System Level Goals

Problem Domain Scope
Limitation
System
Level
UseCase
RANK 0: SYSTEM LEVEL USE CASE
IDENTIFY ACTORS
( AS MANY AS POSSIBLE)
BE CLEAR ABOUT
THE OVERALL SCOPE
Actors are outside

the Scope of Design
PROVIDE A
SUMMARY DESCRIPTION
OF THE SYSTEM

BASELINE
Of
PROJECT
ESTABLISHED
USE CASE : SYSTEM LEVEL
What is it based on ?
It is based on the Overall Requirement indicated by the End

Client of the Project.
What is it based on ?
It is based on the Overall Requirement indicated by the End

Client of the Project.
Link to our Case Study Requirement
What does it contain ?
1. One Ellipse = Use Case of Rank 0

Title is name of the system
BTMR Ticketing Control System
2. Many Actors :
Actors are those EXTERNAL ENTITIES which interact

with the System
Say :
Also Note the Line connecting Actor and the

ellipse
It is called Uni-Directional Association,

When referred to in Use Case
Diagrams
In Use Case,
the line connects
Intiator
To the
Initiated
(Often Actor to Use Case)
Actors need not be Human Beings
Can be another Software system.

Can even be Hardware Systems.
Ususally Embedded Projects present Hardware as Actors.
3. Simple DESCRIPTION ( Summary)

about the System :
This Ticket system is useful in issuing a variety of Cards, which

the Commuter can use for making Journeys. The Driver has a
Card which starts the logical portion of every Trip and
punctuality information is also captured.
Officials such as Operations Manager plays a control role while

the Depot Manager plays the role of checking the
accountability of valuables.
The software system is built on suitable embedded hardware.

The software architectures envisaged are : …….

If needed this Text is supplemented with illustrations (
say Process Flow Chart ). The description in Text form
can have additional support with Sequence Diagram,
Activity Diagram etc.,
Actor in Use Cases

Actor is
ALWAYS OUTSIDE THE
SYSTEM
And YET
INTERACTS WITH: THE SYSTEM
Primary Actor :
Directly interacts with the System
: Commuter
Secondary Actor :
Act on behalf of another Actor
: Operators
Software as Actor:
Another ( Client) Software
Comes in mostly for distributed Systems and in
simple client Server systems.

Hardware as Actor :
Acts through device Driver etc.,

: Firmware, Embedded-ware
Comes in mostly for Embedded Systems
Even external triggers like

Timer are Actors
Which Actor initiates a “Monthly Report” ? : Timer
Can one Use Case may involve

more than one Actor ?

Usually one Actor initiates the request
Other Actors are contacted during

this happening
Can one Actor may be involved

in more than One Use Case ?
Actor plays usage roles

In a Word software :
eg: Save, Print, Load, Spell Check
In most situations one Actor will be involved

in more than Use Case Scenario
At System Level,
We are showing all these
scenarios
through a single line
( Uni-Directional Association)
between the
Actor and the
System.

ACTOR_A
Actor_c
SYSTEM XXX
ACTOR_B
Why does the Arrow go from Actor to the System ( Use Case ) ?
The Arrow ( Uni-Directional Association) in Use Case is always

from the INITIATOR ( ACTOR) to WHAT IS NEEDED for that
initiator
( Initiated )

WHO needs System Level Use Case ?
This is a Use Case at RANK 0.
Useful in defining overall scope of the System
Serves as simple and overall SUMMARY

of the Requirement
All other Ranks of Use Cases look at this Rank

as the core.
Can be placed in the TRACK CHART Library of your Organization.

We need to step into White Box approach soon
An Use Case achieves

a particular goal
for the actors
participating in the Use Case.
Each Use Case is a

generic description
of what is done
such that
system goal is achieved.

Section : High Level
Rank 1
Rank 1 is for describing the Scenarios
Significant Scenarios
Can one Actor may be involved

in more than One Use Case ?
Actor plays usage roles

In a Word software :
eg: Save, Print, Load, Spell Check
In most situations one Actor will be involved

in more than Use Case Scenario

Rank 1 is for describing the Scenarios
Significant Scenarios
Most real systems have a

small set of Use Cases
-usually anywhere from

three to a couple dozen.
Scenarios are
instances of Use Cases.
A scenario is
a specific,
step-by-step sequence of
messages sent between
the actors and the system

and the actiont taken,
as seen from Actor Viewpoint
A Scenario as conceived
from Actor View point
A description which says

“What” rather than the “How”
So the basis is the Requirements Model
Take one Actor at a time

Look into the IMPORTANT Scenarios, from the viewpoint of
that Actor
Rank 1 : Some of the IMPORTANT Commuter initiated

Use Cases :

B u y in g a C a rd
C om m u te r S ta rtin g J o u rn e y
E n d in g J o u rn e y
Note :
1. What are all selected as (Use Case) Scenarios

2. How the Direction of Arrow is
3. How One Actor, many intiated scenarios are combined
Each Use Case is a specific way

of using the System
If an Use case is somehow executed ( realized),

it will be a “Running Instance” of the System.
The Use Case Modeling can be

approached duly structured

Rano 0 Use Case is a
System Level Description
Rank 1 can focus on Most Important

( Major, Most-Normal) happenings
Other Levels ( or Ranks ) will gradually

lead
to details and depth
Avoid looking into exceptional, error scenarios

In Rank 1 and 2.
USE CASE at Levels other than System Level :
Ø A description of USAGE SCENARIO
Ø It describes the HAPPENING
Ø Each Use Case limits itself to one Scene
Ø Based on Requirements Model

Rank 1 should focus on MAJOR TASKS
to be performed by the USER
USE CASE: HIGH LEVEL

RANK 1
MOST IMPORTANT HAPPENINGS
A High Level Requirements Capture
Starts from An ACTOR
Involves an Ellipse and a Description
Has a two way interaction with that Actor
May have interaction with other Actors

How is the Description Given ?
As a flow
Involves MANY SENTENCES,

NOT JUST ONE OR TWO!
Every Sentence is a part of

an integrated Flow
Ends only with a "LOGICAL FULL STOP "
Rank 1 : Commuter Related Use Cases :
DESCRIPTION :
The Commuter approaches a

Vending Kiosk and provides the
necessary inputs to the Vending
system. The system checks the
inputs. The Commuter provides
necessary amount of money. The
needed Card is internally
prepared. The details of the Card
is encoded on the magnetic

portion of a Physical Card.
Balance money, if any, is
calculated and pushed out. The
Physical Card is pushed out. The
Vending system is now ready to
accept the next request form the
next Commuter.
The Commuter approaches the

Start Slot portion of the
Validating system of the bus.
The Commuter submits the
Physical Card for necessary ‘in-
check’. The Start Slot checks the
Card for correctness of type. It
also makes other necessary
checks and makes necessary
markings on the Card.

The Card is then pushed out.
The Start Slot portion of the
Validating system is now ready
for the next Commuter
The Commuter approaches the

End Slot portion of the Validating
system of the bus. The Commuter
submits the Physical Card for
necessary ‘out-check’. The End
Slot checks the Card for
correctness of type. It also makes
other necessary checks and
makes necessary markings and
necessary deductions of amount
on the Card.
The Card is then pushed out. The

End Slot portion of the Validating
system is now ready for the next
Commuter.

Naming of Use Cases
Ø Ideally starts with a verb

: booking
Ø Emphasizes that it is a process
Ø Name that goes with the domain
: booking Ticket
Ø Name that is not too generic
: buying something
Ø Name that is not too vague
: doing User Operation
Complete Rank 1 Use Cases for Every Actor, Important Scenarios

Buy ing a Card
C om m uter Starting Journe y
Ending Journe y
Important Use Cases of one Important Use Cases of one

more Actor more Actor
Naming of Use Cases
Ø Ideally starts with a verb

: bookin
Ø Emphasizes that it is a process
Ø Name that goes with the domain

: booking A Ticket
Ø Name that is not too generic
: buying something
Ø Name that is not too vague
: doing User Operation
Do not forget, every Use Case must have a description
Not ONE LINE Description.

It is a flow description.
Happening inside System, Actor View Point
Use Case : Do’s

Name it properly
Always starts with a VERB
Describe it properly
Must be a multi-line Description
Complete Flow inside the System
is to be described as a Flow

Use Case : Don’ts
It is NOT A PROPER USE CASE, if
Name starts with something that is not a Verb
Description stops with one or two lines
Summarizing so far :
Scope
Limitation
Problem Domain
System
Level Rank 1
USeCase MOST IMPORTANT

HAPPENINGS
BASELINE
of GENERIC
PROJECT MOST IMPORTANT
SCENARIOS
ESTABLISHED CAPTURED
To whom is Rank 1 exposed ?
CLIENT ( send for sign-off)
The Whole Project Team
Test Case Generating Persons

USE CASE : MID LEVEL
2.A MOST Important HAPPENINGS, Drill

Down
Take an Use Case of Rank1

but describe it in different ways it
can be performed
DRILL DOWN into

Alternate Courses of Action
May proceed with a copy of

the
previous level Use Case Diagrams
And add the drill down details to it.
EXTENSION in Use Case

2.B Blow Up the Details
Look for Common Sub-Scenarios
Take an Use Case of Rank 1
Expand the One ellipse into many more
One Scenario :
Into many connected Sub-Scenarios
UseCase1 UseCase2 UseCase3
Actor1
UseCase4 UseCase5

Blow Up One Use Case into more Details : is Explosion
There is no Base
Use Case & Sub Use Cases come in.
Sub UseCase : INCLUSION -
Every Use Case must have an Actor
What about Use Cases which cannot identify

an Actor to initiate them ?
Such an Use Case is a SUB USECASE
It MUST be INCLUDED in at least another Use Case

Look at the arrow carefully
Green Use Case is the proper Use Case

Red is a Sub Use case
It is only an included portion
Green includes Red
Sub Use Case is only a chunk of behavior
It can be executed only

in the context of the main Use Case
2.C Start-Up and Shut-Down

( Exit Point ) Use Cases
About START-Up Use Cases
All systems have at least

one start-up use case

Client server systems will have two
Distributed systems will have many
More Samples of Mid Level Use Cases
All these involve START-UP Scenarios.
Please try to figure out the logic needed behind each of these
start-up scenarios before adopting them in your study and
providing the Description.
2.D Mid Level can include

next level of Happenings
Secondary Use Cases
NEXT_TO MOST SIGNIFICANT

HAPPENINGS IN SYSTEM
May add newer and independent

Use Case Diagrams

BOOKS on UML
Recommended book :
UML 2 Bible : By Tom Pender

Wiley Publication : ISBN 81-265-0452-8
Other UML 2.0 Books
UML 2 Toolkit
by Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado
Fast Track UML 2.0

by Kendall Scott, Apress
Other books :

v A book which explains the fundamentals of UML
UML Distilled
By Martin Fowler
Addison-Wesley Object Technology Series
The major strength of "UML Distilled" is its short, concise presentation of the essentials of UML and where it fits within
today's software development process. The book describes all the major UML diagram types, what they're for, and the basic
notation involved in creating and deciphering them.
ISBN 0321193687
v A book which serves as quick reference

UML in A Nutshell
By Sinan Si Alhir
O’Reilly Publication
v A book that serves as good topic-wise reference

The UML User Guide
By Grady Booch, James Rumbaugh, Ivar Jacobson

Addison-Wesley
v A book relating to Method ( Process) which follows UML

The Unified Software Development Process
By Ivar Jacobson, Grady Booch, James Rumbaugh
The Unified Software Development Process

by Ivar Jacobson, Grady Booch, James Rumbaugh
v A book of higher level details

Instant UML
By Pierre-Alain Muller
Wrox Press
v A book on UML based Component Development

Process called Catalysis
Objects, Components, and Frameworks With
UML : The Catalysis Approach
by Desmond Francis D'Souza, Alan Cameron Wills
v A Book on a Commercial Process ( Method) from

Rational Corporation

The Rational Unified Process
by Philippe Kruchten
Also refer to Web sites :
www.omg.org
www.rational.com
http://www.cetus-links.org/software.html
More Books
Practical Statecharts in C/C++:
Practical Statecharts in C/C++: An Introduction to Quantum Programming with

CDROM
by Miro Samek
Efficiently code statecharts directly in C/C++. You get a lightweight alternative to CASE tools that permits you to model
reactive systems with UML statecharts. Includes complete code for your own applications, several design patterns, and
numerous executable examples that illustrate the inner workings of the statechart-based framework.
ISBN1578201101

Understanding Uml: The Developer's Guide
by Paul Harmon 367 pages
The Unified Modeling Language (UML) is a third generation method for specifying,
an object-oriented system under development. It unifies the three leading object-orie
serve as the basis for a common, stable, and expressive object-oriented development
software applications increases, so does the developer's need to design and analyze a
them. This practical introduction to UML provides software developers with an over
design notation, and teaches Java programmers to analyse and design object-oriented
notation.
* Apply the basics of UML to your applications immediately, without having to wad
documentation
* Use the simple Internet example as a prototype for developing object-oriented appl
* Follow a real example of an Intranet sales reporting system written in Java that is u
throughout the book
* Learn from an example application modeled both by hand and with the use of Popk
Architect O-O visual modeling tool.
John Wiley & Sons
ISBN1558604650
Navigating C++ and Object-Oriented Design

by Gail Anderson
This comprehensive, practical tutorial helps programmers understand both C++ and object-oriented design methodologies, so
they can write C++ that truly meets its potential. This text incorporates the newer language features, including templates and
exception handling, and explains how to apply C++ language constructs, design guidelines, and object-oriented methodology
to solve real world problems.
his comprehensive tutorial reflects the authors' extensive experience teaching C++ to professional
developers. Start with the clearest introduction to object modeling you'll ever read. Then learn all the

essentials of C++ and more advanced topics such as exceptions, namespaces, and dynamic memory
allocation.
Next, discover C++ classes, the basic building block of object-oriented design. Through proven analogies
and examples, the authors introduce containment and inheritance, overloading, templates, RTTI, and
exception handling. And, the authors' unique presentation on multiple inheritance will give you
invaluable insights into this complex topic.
Learn to apply C++ and object-oriented techniques to real-world development. Discover how to design
classes effectively using the authors' class design boilerplate. Understand how to design container
classes. Walk through class designs using the powerful OMT methodology. Along the way, try out the
book's extensive exercises and take advantage of the exercise solutions and library of sample code on the
accompanying CD-ROM.
Navigating C++ and Object-Oriented Design is one of the first C++ tutorials that covers in detail
powerhouse ANSI C++ features like:
• Namespaces, bool, member templates, and RTTI

• Explicit, export, and nothrow versions of new and delete
• The IOStream Library and Standard Template Library
Why learnC++ simply as a "better C" when you can write C++ code that really meets its potential? One
book shows you how: "Navigating C++ and Object-Oriented Design!"
Prentice Hall PTR
ISBN0135327482

Real Time Uml: Advances in the UML for Real-Time Systems
by Bruce Powel Douglass - Computers - 2004 - 694 pages
: Addison-Wesley, 1996. [31 Hare!, David. ...
The Unified Process Construction Phase: Best Practices in Completing the Unified Process
by Scott W Ambler, Larry L Constantine - Computers - 2000 - 295 pages
The Unified Process Elaboration Phase: Best Practices in Implementing the UP

edited by Scott W Ambler - Computers - 2000 - 277 pages
Fundamentals of Object-Oriented Design in Uml

by Meilir Page-Jones, Larry L Constantine - Computers - 1999 - 480 pages
Embedded Systems Design: An Introduction to Processes, Tools & Techniques

by Arnold S Berger - Computers - 2001 - 237 pages
Embedded Systems Firmware Demystified

by Ed Sutter - Computers - 2002 - 366 pages
Page - active systems with UML statecharts. Includes complete code
ISBN 1-57820-073-3,
Do not leave us out. We are a source of permanant reference for

C++ : Simple to Advanced Courses
Dot Net Technologies

ASP.Net
VB.Net
C#
Web Service
OOAD
UML
Component Engineering
J2EE
App Servers : WebSphere, WebLogic
Higher & Modern Technologies :
Web Services
And so on.

Ooad

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ooad

Caricato da

Copyright:

Formati disponibili

OOAD

Speaker: Animesh S Client: Juniper

Speaker: Animesh S Client: Juniper

Procedural Design Outlook

Functions : Global : Any function can change

Speaker: Animesh S Client: Juniper

Better packaging is needed

To face current problems

Speaker: Animesh S Client: Juniper

Speaker: Animesh S Client: Juniper

In some projects an hybrid Approach of C and C++ ( and

It is not surprising to notice that some modern projects get

Speaker: Animesh S Client: Juniper

Speaker: Animesh S Client: Juniper

Think of an object as a fancy variable; it stores data, but you

In theory, you can take any conceptual component in the

Speaker: Animesh S Client: Juniper

Every object is unique, in that it is distinctly

Can be a pointer : File* p1 ;

Can even better be a Reference : File& r1 = ……;

Such a variable which refers to an object instance is called

f1 happens to be a identifier to the Object instance

Speaker: Animesh S Client: Juniper

Languages provide for one automatically generated Field Value :

this -Java , C#, C++

But other objects need to refer to this object.

Speaker: Animesh S Client: Juniper

Speaker: Animesh S Client: Juniper

Every object has one and often more Field Attributes

Speaker: Animesh S Client: Juniper

The data members of an object

Properties -> Are like Fields

Get : querying of value of attribute &

An object holds State

State is the nature

and is one which

due to dynamic nature

Speaker: Animesh S Client: Juniper

Speaker: Animesh S Client: Juniper

Combine all Object states,

Speaker: Animesh S Client: Juniper

A method (function) called by a client object changed state

A direct assignment can change state

A method (internal function) in the same object changed state

Does it undergo state changes ?

Clue : File size :

Speaker: Animesh S Client: Juniper

Another Clue : File is open, File is closed.

Every object has Behavior

Every object has a behavior.

Speaker: Animesh S Client: Juniper

Open : Make it ready for file operations

Speaker: Animesh S Client: Juniper

Acting : Internal : Like flushing before close

Reacting : Externally visible behavior

Speaker: Animesh S Client: Juniper

Methods : Signature and Code

Signature : What does it do. Name

Speaker: Animesh S Client: Juniper

Procedure ( say in VB.Net)

Only interfacing info

Speaker: Animesh S Client: Juniper