Diagram:

1. A plan, sketch, drawing, or outline designed to demonstrate or explain how something works or to clarify the relationship between the parts of a whole.

2. Mathematics. A graphic representation of an algebraic or geometric relationship.

3. A chart or graph. [DICT1]

For our purposes in this book, a diagram is the layout and visualization of different modeling elements as described within the UML. Each UML diagram is used for a specific purpose, typically to visualize a certain aspect of your system (summarized next). Each diagram uses specific UML symbols to achieve its purpose.

What Diagrams Are in the UML?

The UML contains two different basic diagram types: structure diagrams and behavior diagrams. Structure diagrams depict the static structure of the elements in your system. The various structure diagrams are as follows:

• Class diagrams are the most common diagrams used in UML modeling. They represent the static things that exist in your system, their structure, and their interrelationships. They are typically used to depict the logical and physical design of the system.

• Component diagrams show the organization and dependencies among a set of components. They show a system as it is implemented and how the pieces inside the system work together.

• Object diagrams show the relationships between a set of objects in the system. They show a snapshot of the system at a point in time.

• Deployment diagrams show the physical system's runtime architecture. A deployment diagram can include a description of the hardware and the software that resides on that hardware.

UML 2.0 adds the following structure diagrams:

• Composite structure diagrams show the internal structure of model elements.

• Package diagrams depict the dependencies between packages. (A package is a model element used to group together other model elements.)

Behavior diagrams depict the dynamic behavior of the elements in your system. The various behavior diagrams are as follows:

• Activity diagrams show the flow of activities within a system. You often would use them to describe different business processes.

• Use case diagrams address the business processes that the system will implement. The use cases describe ways the system will work and who will interact with it. [BOOCH1]

• Statechart diagrams show the state of an object and how that object transitions between states. A statechart diagram can contain states, transitions, events, and activities. A statechart diagram provides a dynamic view and is quite important when modeling event-driven behavior. For example, you could use a statechart diagram to describe a switch in a telephone routing system. That switch will change states based on different events, and you can model those events in a statechart diagram to understand how the switch behaves. In UML 2.0, these are called state machine diagrams.

• Collaboration diagrams are a type of interaction diagram, as are sequence diagrams (along with others in UML 2.0, noted next). The collaboration diagram emphasizes how objects collaborate and interact. In UML 2.0, the equivalent of the collaboration diagram is thecommunication diagram.

• Sequence diagrams are another type of interaction diagram. Sequence diagrams emphasize the time ordering of messages between different elements of a system.

UML 2.0 adds the following behavior diagrams:

• Timing diagrams are another type of interaction diagram. They depict detailed timing information and changes to state or condition information of the interacting elements.

• Interaction overview diagrams are high-level diagrams used to show an overview of flow of control between interaction sequences.

The UML 2.0 diagrams that are relevant to mere mortals will be discussed further in Chapter 8, "Is That All There Is?."

Although these diagrams are the defined diagrams of the UML, you may encounter additional diagrams that tool vendors can create, which are specific to their tools. You need not be concerned about the proliferation of additional UML diagrams. Few people even use all of the standard UML diagrams when modeling their systems. Some you may never use. In subsequent chapters, we will focus on those diagrams that are most important and that will most frequently be encountered by mere mortals.

What Is the Difference Between Diagrams and Models?

Although they might appear to be similar at first glance, a diagram and a model are different from each other. A model is an abstraction that contains all the elements needed to describe the intention of the thing being modeled. This can include all aspects concerning the business, systems, relationships, and more. A diagram is a specific view into what you are trying to understand in a specific context. Diagrams are just one way of looking at all or some part of that model. You can have a specific modeling element exist only once within a model, but the same element can appear on one or more diagrams.

For example, if I am modeling a navigational system for a vehicle, the system model will represent all the parts of the entire system. However, I may create specific diagrams that contain just the elements that deal with the map display, error correction, or the navigational satellite constellations.