Usually the total flow of developing in UML goes something like this.

You develop the use cases and create Use Case Diagrams... (it is not necessary to create Use Case Diagrams if you have a good Use Case document template, but for those that like visual documentation they are nice).

From the Use Cases, you begin to figure out what the Primary Classes are.. the Business Objects... You then can create a Class Diagram. This origionally contains the Attributes of each class.

Now you figure out how those classes interrelate.... what information needs to pass between the objects and what is their behavior. You can either use Correlation Diagrams or Sequence Diagrams (many times the UML tool will translate one to the other). I prefer to use sequence diagrams to do this. Sequence diagrams give me a little better idea of the order in which I need to access each class... In developing the sequence diagrams, I may find new attributes of each class or new behaviors.... And sometimes I find I need "helper classes" to act a a gobetween or manage something that is not a business object or collections of business objects....

You can also use Activity diagrams to look at the flow... and I've used State Diagrams to talk about things that need to operate in State Machines....

Your component diagrams help in determining the interfaces between components or layers....

I guess that's all I've used in development. You don't need to use ALL the diagrams in a project... and one person shouldn't be responsible for creating and designing using ALL the diagrams.

But this is a general idea of the flow... after you've worked out this stuff, the code almost writes itself..

Stephen McConnell