Today I am preparing to teach a UML course at Emageon in Milwaukee, WI. I have presented this course several times for different clients in the past and have refined it each time. The central theme in my training is a "use case driven" process coupled with visual modeling. These two concepts are cornerstones to the USDP.
UML, therefore, is a visual expression and expansion of the use case model. The use case model is a reflection of the system requirements, and the UML model expands upon this model. It is beneficial to achieve both behavioral and structural views of the use case model using UML. Structural views manifest themselves as class diagrams, component diagrams, and collaboration diagrams, while behavioral views are manifested by activity diagrams, sequence diagrams, and state machines. Additionally, it is helpful to have a good mix of these diagram types -- each one is intended to address a specific viewpoint or level of detail.
Structural models address the "static" view of things. For example, class diagrams express the structure of classes, their associations with other classes, and their inheritance hierarchy. Behavioral models address the dynamic interaction of things in the system. For example, a sequence diagram emphasizes the messages between objects in a scenario, especially the sequence of those messages. It is very important to address both the structure and the behavior of objects in a system.
Another useful view is the State Machine, which is primarily used to express the complex behavior exhibited by a class, especially when the class exhibits different behavior depending on its state.
I have found that the most useful progression of UML modeling is as follows:
1) Begin with the use case model.
2) Expand the use case model using Activity diagrams.
3) Identify the "things" in the system. These are most evident by looking for nouns in the use cases and activity model. These are classes, modeled (of course) by a Class diagram.
4) Examine the simple behaviors of each class and how each class collaborates with other classes. Document these behaviors as operations on each class (in the Class diagram) and as collaborations (in the Collaboration diagram).
5) Document each scenario in which message sequence is critical by using a Sequence diagram.
6) In cases where objects exhibit complex, state-dependent behavior, use a State Machine.
For completed systems, use the Component and Deployment diagrams to depict the physical implementation and relationships among nodes.
