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.

The object diagram is not typically included in modeling tools. Unfortunately, its value as a testing tool is often overlooked, especially by those who are new to object modeling. We will see a very simple example in this lesson that illustrates how easy and how valuable the object diagram is for testing your class diagram.

An object diagram in the Unified Modeling Language (UML), is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time. An object diagram is a graph of instances, including objects and data values. A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The use of obect diagrams is fairly limited, namely to show examples of data structure. An object diagram is a snapshot of the objects in a system at a point in time, because it shows instances rather than classes, an object diagram is often called an instance diagram.
An object diagram focuses on some particular set of objects and attributes and the links between these instances. A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time. In early UML specifications the object diagram was described as:

Use cases show what your system should do. Activity diagrams allow you to specify how your system will accomplish its goals. Activity diagrams show high-level actions chained together to represent a process occurring in your system. For example, you can use an activity diagram to model the steps involved with creating a blog account. Activity diagrams are particularly good at modeling business processes . A business process is a set of coordinated tasks that achieve a business goal, such as shipping customers' orders.
Some business process management (BPM) tools allow you to define business processes using activitydiagrams, or a similar graphical notation, and then execute them. This allows you to define and execute, for example, a payment approval process where one of the steps invokes a credit card approval web serviceusing an easy graphical notation such as activity diagrams.

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.