Lesson 1

In the previous module, you learned how to use the class diagram. You learned that the class diagram is the focal point of all the models provided by the UML. One of the major problems in learning a tool like the UML is the seductive simplicity of the models. It is very easy to draw a class diagram, a few rectangles and lines, and some labels, and there you have it.
But how do you know the model will work? How do you know once this model becomes software that it will perform as expected? One way is to start coding as soon as possible, the method used by too many shops. This basically reduces the models to optional tools, nice to have but unnecessary, because you do all your real work in the code.

Object Diagram Importance
There is a much more cost-effective way to test your object model. The object diagram is simple means to test your class diagram easily. The notation is even simpler than the class diagram.

After completing this module, you will be able to:

1. Define the purpose and function of the object diagram
2. Compare and contrast the class diagram and the object diagram notation
3. Apply test cases to verify, refine, and correct an object model

In the next lesson, you will learn about the object diagram.

If Booch's OOAD brought class modeling and Jacobson's OOSE gave us use cases, state transitions, and interaction modeling, then James Rumbaugh added his object modeling technique (OMT). Although Booch's class and object diagrams were well loved by his adopters (those clouds again), it was the class and object diagram notation from OMT that most influenced what was to come. The OMT's notation for its object view was arguably simpler to draw, even if its interclass relationships were not as intuitive as Booch's.