Luckily most machines nowadays have multi-core processors or
multiple processors.  If the machine in question has only a
single-core processor and nothing else, then there is no
good answer.  If the machine is 'modern' and had dual- or
more processors (or cores), then the answer is that your
heavy processing is best forked off into a separate thread
while the GUI is maintained by the first thread.  This
allows one processor to maintain good latency in processing
the GUI (and its controls) while the other processor(s) do
the processing.  End of story.

bcos in manier cases things will change in later phases.

You cant plan only for the current phase of the project as 
your future activities are still coarse granular. To have 
good plannig you need to have fine granularity w.r.t the 
tasks to get clear WBS

Every project (be it OO or otherwise) has certain unknown factors. It is just impossible to know every constraint in advance. Many things are discovered during detailed design and implementation stage. Hence too much of planning is a wastage of effort when unknown factors are bound to pop up. Hence the focus should be on flexibility rather than rigidness that comes with excess planning.

To mitigate the risks asap and it will also help them in
sizing and other things.

The query actually holds good in general for every situation in life. It is one of the principles of good time management. 

The idea is to tackle hard (and important) problems first. This, if resolved - will pep up your confidence to deal with other not so hard issues. Also, this could have cascading effect on other issues that may get resolved on its own.

I would rather stress on "important" than "hard" issues. If a "hard" problem is not coming in the way of your deliverables (means it is not important) - keep it aside. There is no need to spend a lot of time on it.

SRD contains the details about the system where the 
appliation is deployed.(i.e) software and harware 
specification 

FRD contains the details about the application which has to 
be developed. 

RDS contains the details about what actually need to be 
done/modified(if existing system) in the application that 
has to be developed.

The arguments distinguish functions with the same name 
(functional polymorphism). The name alone does not 
necessarily identify a unique function.  However, the name 
and its arguments (signatures) will uniquely identify a 
function.
In real life we see suppose, in class there are two guys 
with same name, but they can be     easily identified by 
their signatures. The same concept is applied here.
ex:
class person
{
public:
char getsex();
void setsex(char);
void setsex(int);
};
In the above example we see that there is a function setsex
() with same name but with different signature.

Usecase diagram.

Class diagram bcoz it is describe the static structure of objects in a system.

From the use cases, designers will incure class diagrams 
and Dynamic modelings like sequence diagrm,Activity diagram 
and Collaboration diagrams.And from the use case diagram, 
we will identify control classes, boundary classes and 
Interface classes.Every Inerface classes will have 
realisation classes(implementation of the abstract classes).
This is the way of conveying the implementation details to 
programmers

During the requirements phase of a project, analysts can take use cases to the next level by providing a more formal level of refinement. When that occurs, use cases are often refined into one or more sequence diagrams.
During the design phase, architects and developers can use the diagram to force out the system's object interactions, thus fleshing out overall system design.
The sequence diagram and class diagrams would be the implementation detail.

In Unified Modeling Language (UML) sequence diagrams, a 
guard condition, also called as an interaction constraint, 
is a Boolean conditional expression that guards an 
interaction operand in a combined fragment. A guard 
condition contains two expressions that designate the 
minimum and maximum number of times that a loop combined 
fragment executes.

One who plays different roles
One who is interacting with the system

A condition that determines whether a certain transition 
will occur in a state diagram when an event happens
A guard condition is evaluated only when the associated
event happens.

An Actor is something or someone who intract with the 
system under development. An actor can be a Human, device 
or an external system. An actor can be a giver / reciever 
of information or both.

An actor specified the role played by an external entity( 
may be human ,process or other system ) on the system.

An Actor is an entity which interacts with the System 
(either human(Developers & End-User) or hardware(Hardware 
Accessories) or system(Software System)).

It is useful to represent the complete and specific 
funtionality that an actor(USER) is desirous of.
This functionality is shown by the USECASE model with the 
help of Diagrams, i.e. Sequence Diagram and Colloboration 
Diagram. It shows the various states of a work flow(Project 
or Program).

Diagram which represents the requiremnets(usecase) of the 
user(actor). its needed to represent the dynamic model at 
the analysis stage to represent the graphical view of the 
requiremnetal behaviour.

an usecase is a sequence of actions which can be done by a 
actor.

use case is a interaction between actor(USER) and System
(application), for single system there many use cases 
depends on Requirements.

use case represents diagrams. there are two types of use 
cases BUC-> business use case and SUC-> system use case
In BUC we represent pictures related to Domain and SUC we 
represents shapes like elipse,arrows etc. this is the very 
first stage of design where we find out actors and related 
activity. actor performs happy activity

A use case is a methodology used in system analysis to 
identify, clarify, and organize system requirements. The 
use case is made up of a set of possible sequences of 
interactions between systems and users in a particular 
environment and related to a particular goal.

Types of UML Diagrams:
1. Use case Diagram
2.	State Diagram
3.	Class diagram,
4.	Sequence diagram
5.	Collaboration diagram


 Use case: A set of scenarios that describing an interaction
between a user and a system, including alternatives.

Use case diagram-Uses: 
 Used for describing a set of user scenarios
 Mainly used for capturing user requirements
 Work like a contract between end user and software developers

Use case diagram-Core components:
  a)	Actor b) Use case  c) System boundry

Use case diagram Relation's:
a)Association B) Generalization c) Include d) extend

When OOAD was in the birth phase, There were different 
different ways to define the OOAD consepts.
Before 1994 there were different methodologies like 
Rumbaugh, Booch, Jacobson, Meyer etc who followed their own 
notations to model the systems. The developers were in a 
dilemma to choose the method which best accomplishes their 
needs.     This particular span was called as ?method-wars?.

Selvan Pongy

No, you cannot apply the link and Association 
interchangeably. Since
* link is used represent the relationship between the two   
objects.

* But Association is used represent the relationship 
between the two classes.

link ::          student:Abhilash         course:MCA

Association::    student                  course

Links and associations can't be used interchangeably because
association is a relationship among classes and link is a
relationship among instance of classes.
e.g. => Person works for company. 
Here a connection exists  between two classes 'person' and
'company' so this is the example of association but if we
take one instance of each of the above classes as 'Ram' and
'Google' then we can be specific about the work which Ram is
doing for Google.
e.g. => Ram works as a programmer for Google.
But we cant use 'Person works as a programmer for Google'.
Hence we can't use links and associations interchangeably.

Aggregation is the relationship between the whole and a 
part. We can add/subtract some     properties in the part 
(slave) side. It won?t affect the whole part.
Best example is Car, which contains the wheels and some 
extra parts. Even though the parts are not there we can 
call it as car.
But, in the case of containment the whole part is affected 
when the part within that got affected. The human body is 
an apt example for this relationship. When the whole body 
dies the parts (heart etc) are died.

Static modeling is used to specify structure of the 
objects that exist in the problem domain. These are 
expressed using class, object and USECASE diagrams. 

 Dynamic modeling refers representing the object 
interactions during runtime. It is represented by sequence, 
activity, collaboration and statechart diagrams

Static Model - Time Independent view of the system.
e.g. Class has same number of students in an year.
Static model includes :
CLASS DIAGRAM
OBJECT DIAGRAM
COMPONENT DIAGRAM
DEPLOYMENT DIAGRAM

Dynamic Model - Time dependent view of the system
E.g. ATM can accept card only when it is in ready state. 
ATM cannot read card card when it is in ERROR state. Thus 
state of ATM is a dynamic aspect.
Dynamic Modelling includes
USE-CASE DIAGRAM
INTERACTION DIAGRAM
STATE DIAGRAM
ACTIVITY DIAGRAM

Funtional Model-What happens
Static Model- To whom it happens
Dynamic Model - When it Happens

Static Model refers to the model of system not during 
runtime. This is more structural than behavioral. This 
includes classes and it relationships(Class Diagram), 
Packages etc. For example, the concept of class itself 
static. At runtime there is no concept of Class, Sub class 
etc.

Dynamic model refers to runtime model of the system. This 
includes the concept of Objects, interactions, 
Collaborations, sequences of operations, Activities, state 
changes, memory model etc.

SBI stands for State, Behavior and Identity. Since every 
object has the above three.
* State:         
It is just a value to the attribute of an object at a 
particular time.

* Behaviour:

It describes the actions and their reactions of that object.

* Identity:

An object has an identity that characterizes its own 
existence. The identity makes it possible to distinguish 
any object in an unambiguous way, and independently from 
its state.

Object has
State:Described by attribute values 
Bahaviour:Described by methods 
identity: Object id for reference assigned by system(hex) 
or by address of memory location