Inception
Elaboration
Construction
Transition

Four Process Phases

The Unified Process consists of cycles that may repeat over
the long-term life of a system. A cycle consists of four
phases: Inception, Elaboration, Construction and Transition.
Each cycle is concluded with a release, there are also
releases within a cycle. Let's briefly review the four
phases in a cycle:

    * Inception Phase - During the inception phase the core
idea is developed into a product vision. In this phase, we
review and confirm our understanding of the core business
drivers. We want to understand the business case for why the
project should be attempted. The inception phase establishes
the product feasibility and delimits the project scope.
    * Elaboration Phase - During the elaboration phase the
majority of the Use Cases are specified in detail and the
system architecture is designed. This phase focuses on the
"Do-Ability" of the project. We identify significant risks
and prepare a schedule, staff and cost profile for the
entire project.
    * Construction Phase - During the construction phase the
product is moved from the architectural baseline to a system
complete enough to transition to the user community. The
architectural baseline grows to become the completed system
as the design is refined into code.
    * Transition Phase - In the transition phase the goal is
to ensure that the requirements have been met to the
satisfaction of the stakeholders. This phase is often
initiated with a beta release of the application. Other
activities include site preparation, manual completion, and
defect identification and correction. The transition phase
ends with a postmortem devoted to learning and recording
lessons for future cycles.

1.Visualisation2.
Specifying
3.Construction and
4.Documentation

Object-Oriented Analysis:

Emphasis is on finding and describing the objects or 
concepts of the problem domain. Focus on what the system 
must do. Do the right thing. 

Object-Oriented Design:

Emphasis is on defining software objects and how they 
collaborate to fulfill requirements. Focus on how the 
system will do it. Do the thing right. 

In OOA we just gather the resouces
In OOD we can design with the use that resources

Analysis is modeling the desired behaviour ie totally
concentrating upon the functionalities required by the
system to be developed.

While design to create architecture for above model
considering both functional as well as non functional
requirements like performance, security, scalability etc

I agree with #1 & #3 responses.

Analysis is more from an end user perspective - what the desired behavior of the system should be.

Design is from the developer perspective - how the system is going to deliver the required behavior as established above.

The difference is "what" and "how".

Identity : Every instance of a class should be unique. e.g.
in memory, every object has its own memory address. This is
part of the unique id, other than which a user can have
member variables uniquely identifying the instance of the class.

State : Every object, at any given point of time would have
to have a set of attributes defining its State.

Behavior : Every object based on its state and optionally
identity will have particular behavior.

Object is an instance of the class.And oject must have the 
identity because of object can be specified in Class. And 
has carries the behaviour of that perticular class

RAD,CASEtools

I use UML, in particularly Sparx Enterprise Architect.

Sparx Architect .

Abstract classes are represented using a special tag
{abstract} and the name of the class is represented in
Italics. Static members are represented as underlined members.

Have an association/associative class

An example of a many-to-many relationship in the greenhouse
plant application is between the Plant and Additive
entities. Each plant may be treated with one or more
Additives. Each Additive may be given to one or more Plants.
The ERD for this relationship is shown below.

Many-to-many relationships cannot be directly converted into
database tables and relationships. This is a restriction of
the database systems, not of the application. The
development team has to resolve the many-to-many
relationship before it can continue with the database
development. If you identify a many-to-many relationship in
your analysis meeting, you should try to resolve it in the
meeting. The participants can usually find a fitting entity
to provide the resolution.

To resolve a many-to-many relationship means to convert it
into two one-to-many, many-to-one relationships. A new
entity comes between the two original entities, and this new
entity is referred to as an intersection entity. It allows
for every possible matched occurrence of the two entities.
Sometimes the intersection entity represents a point or
passage in time.

The Plant-Additive many-to-many relationship above is
resolved in the following ERD diagram:

With these new relationships, Plant is now related to
Treatment. Each Plant may be given one or more Treatments.
Each Treatment must be given to one and only one Plant.
Additive is also related to Treatment. Each Additive may be
used in one or more Treatments. Each Treatment must be
comprised of one and only one Additive. With these two new
relationships, Treatment cannot exist without Plant and
Additive. Treatment can occur multiple times, once for each
treatment of a plant additive. To keep each Treatment
unique, a new attribute is defined. Treatment now has
application date and time attributes. They are the unique
identifiers or the primary key of Treatment. Other
attributes of Treatment are quantity and potency of the
additive.

There are 4 kinds of relationships
1.Dependancy
2.Association
3.Generalization
4.Realization

A relationship between two entities, where one uses the
other is known as Association.

Contrast this with Dependancy, where one entity needs to use
another entity for its completion.

Association is a link between two things

Activity diagram is used to show identify the interaction
between domains and Sequence diagram is used to show the
logical execution flow of a business process.

Activity diagrams : 
are typically used for business process modeling, 
for modeling the logic captured by a single use case 
or usage scenario, or for modeling the detailed logic 
of a business rule. This is the OOAD version of flowchart 
or data flow diagram.

Sequence Diagrams:
model the flow of logic within your system in a visual manner, 
enabling you both to document and validate your logic, 
and are commonly used for both analysis and design purposes.
Sequence diagrams identify behavior within the system.

GRASP patterns to assign responsibilities
Structural patterns to refine the structural design
Creator patterns to optimize the object creation

Operator Overloading helps users/developers use a particular
class in an intuitive manner for different kind of
operations logically possible on the class. 
It's used for ease of code read and maintainability.

e.g. Date 'b' can be subtracted from another instance of
Date, say 'a', to get the difference in number of days
between the two days.
So, you would overload the subtraction operator '-' for the
Date class accordingly.
Date a("07/04/2008);
Date b("05/04/2008);

//operator overoading for '-' for Date
//returns number of days
int Date::operator-(const Date& rhsDate)
{
   //wotever logic
   return <number of days between the (this) date and rhsDate>
}

Persistent object is one which is stored even after the 
creator of the object ceases to exist whereas transient 
object only exist till the creator exists and not stored 
permanently

It is about what happens when the application is shutdown
and started again.
Persistent - These objects are stored during shutdown and
recreated when application is started again or when necessary.
Transient -  Can not survive after application ends.

Realization is a kind of relationship that exist between 
classes in class diagram which is used to denote that an 
interface is realized or implemented by a class.Also this 
is used to realte two use cases.

class itself is a specification not an object. Object is a 
instance of class.

Everything is an object. So class, metaclass and everything
are objects.

And Object is not a class. But all the objects can be
classified with a class named as Object for the behavior of
being Object.

A class is just a template that is used to create the 
objects and to define its behaviours.

But object is an instance of a class.

The ability to take more than one form is known as 
polymorphism.

Polymorphism is the mechanism used to decouple the caller of
a functionality or sender of a message and the actual
implementation that serves by without necessitating the
client knowing about the actual implementor &
implementation/response.

Polymorphism, according to the OO programming is the ability of objects belonging to different data types, to respond to the method call with the same name according to a type specific behavior.

Yeh, I know it is cryptic. But that is how it is. At the end, the interviewer will be confused so much so that - you are guaranteed to get in :)