Instructor's Guide

introduction class diagrams use cases interaction packages state and activity discussion
As said before, the UML provides a generic toolbox for analysis and design. It offers no method, so the question remains: when to use what? The answer to that question may be very simple. Just use what you need to convey the properties of the system in a clear and understandable way. The answer may also be very complex, since `clear and understandable' are somewhat elusive notions. Following  [Fowler97], I would say: don't overdo. Use UML to clarify critical aspects of the system and highlights of design, and leave it at that. Never continue modeling when you experience it as a useless, or worse, boring activity.

The UML toolbox is very rich. It allows you to model every conceivable aspect of the system. Nevertheless, to my mind, graphical models are not always appropriate. But, on the other hand, most people like them and they often make a good impression, suggesting clarity ...

As concerns the use of UML, to some extent one can delineate a subset as core UML. Class diagrams lie at the heart of most object models. Dependending on the level of abstraction and the amount of detail, they may be regarded as either a domain model, concrete class design, or anything in between. Use cases delimit the functional requirements, and are essential for negotiating these requirements and also for phasing the delivery of the system. Most interesting, I think, is where combined modeling efforts lead to an indication of the validation and verification spots of the system. In particular, the combination of class diagrams, use cases and interaction (sequence) diagrams allows for spotting the high-risk parts of the system and, accordingly, for specifying test procedures to verify whether the system meets its requirement specifications.