A Snapshot in Time

Some time ago, I was involved with an application that allowed users to draw the floor plan of a building on a GUI. The program captured the rooms, doors, windows, and wall openings in the data structure, as shown in Figure 16-1. Although this diagram shows you what kinds of data structures are possible, it does not tell you exactly what objects and relationships are instantiated at any given time.

Figure 16-1. Floor plan

Let's assume that a user of our program draws two rooms, a kitchen, and a lunchroom, connected by a wall opening. Both the kitchen and the lunchroom have a window to the outside. The lunchroom also has a door that opens outward to the outside. This scenario is depicted by the object diagram in Figure 16-2. This diagram shows the objects that are in the system and what other objects they are connected to. It shows kitchen and the lunchRoom as separate instances of Space. It shows how these two rooms are connected by a wall opening. It shows that the outside is represented by another instance of space. And it shows all the other objects and relationships that must exist.

Figure 16-2. Lunchroom and kitchen

Object diagrams like this are useful when you need to show what the internal structure of a system looks like at a particular time, or when the system is in a particular state. An object diagram shows the intent of the designer. It shows the way that certain classes and relationships are going to be used. It can help to show how the system will change as various inputs are given to it.

But be careful; it is easy to get carried away. In the past decade, I have probably drawn fewer than a dozen object diagrams of this kind. The need for them simply has not arisen very frequently. When they are needed, they are indispensable, and that's why I'm including them in this book. However, you aren't going to need them very often, and you should definitely not assume that you need to draw them for every scenario in the system or even for every system.