- What Is the Unified Modeling Language (UML)?
- What Is a Model?
- What Is a Diagram?
- Terms
- Summary
- Review Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
What Is a Diagram?
Diagram:
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.
Mathematics. A graphic representation of an algebraic or geometric relationship.
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 the communication 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.
Deep Dive—Meta-Models
A meta-model is a model of a model. The UML meta-model expresses the proper semantics and structure for UML models. A UML model is made up of many different elements. The meta-model defines the characteristics of these elements, the ways in which these elements can be related, and what such relationships mean.
What does this mean in plain English? Let's say you want to model various types of people. All people have some common characteristics (e.g., height, weight, eye color). But people also have characteristics and behaviors that are specific to each of them. A construction worker, a dancer, and an engineer are all types of people, but they are different from each other in some ways. You can model this in the UML because the structure of the UML meta-model allows you to model relationships between specific things (construction worker, dancer, engineer) and a general thing (a person)—this is called a "generalization" relationship. In other words, the UML meta-model sets the rules for how you can model.
The UML meta-model is also the foundation for UML's extensibility. Using the definitions of UML elements in the meta-model, you can create new UML modeling elements. You can add additional properties to the new elements. This allows you to give the new element additional characteristics and behaviors for your specific needs, while it still remains compliant with the structure and semantics of the original element that it was based upon. In this way, users can customize the UML to their specific needs.
Most technical languages, including Structured Query Language (SQL, the relational database language) and Business Process Modeling Language (BPML), have a meta-model. Different tool vendors may alter the standard meta-model to fit their tool or to differentiate it from their competition. In this way, tool vendors take advantage of the standards but also differentiate themselves from each other through these extensions.