Hello nitin.
Because I'm starting with OOAD all the following should be validated or dismissed by anyone with more experience.
My opinion is that you have arrived to a slightly old-dated process.
I have understood the concept that is an iteration between the static and dynamic model
I think the point isn't to distinguish bettween static or dynamic modelling, but that an interation is made of analysis, design, coding and feedback from previous interactions.
I came to know about robustness diagram which is in between usecases and the sequence diagrams.
Robustness diagrams are part of the Objectory method by Jacobson, an old method.
It seems that there wasn't a class diagram drawn from the conceptual perspective in the domain model in this method. Thus the robustness diagram tried to carry out its functions.
Taking the analysis-design-coding approach using a robustness diagram seems to me like mixing the design phase with the anlysis one. Drawing a class diagram from the conceptual perspective mustn't show design decisions, however a robustness diagram in an analysis model seems to specify some design decisions, as which class is a controller or acts like an interface. In analysis only the problem should be considered, not how is going to be resolved.
Anyway if you take the objectory method or decide to draw a robustness diagram within an analysis-desig-coding approach, and you find some value, please send a post to let me know how it worked.
Consider the
robustness diagram in the ATM example.
I think that the behaviour of the system can be much better taught/learnt from the class diagram than from it. The value of the robustness diagram is to classify the classes as controllers, boudaries or entities. However, again, this isn't related to the domain but to the way we resolve the problem.
Maybe as an alternative to robustness diagrams, the system sequence diagrams are possible. They express the messages sent between the actors and the system, and also intersystems ones.