What concepts are modeled by the different UML diagrams?

jim conallen

First I must emphasize that diagrams in UML are simply carefully crafted views into the underlying model. So for example if you see a class diagram that shows classes A and B, and there are no relationships drawn between them, it doesn't mean that in the model there are none. It just means that the author of this particular diagram decided not to show any relationship between them, and that most likely the purpose for this diagram was to express some other concept of the system.

UML diagrams can be categorized into Structural and Behavioral.


Class diagram - shows structural relationships between classes and interfaces. These diagrams peek into the underlying structure of the classes in the system. Much of the analysts and designers work is done in these diagrams, since most case tools allow classes and relationships to be defined in them. When a relationship is added in a class diagram, it is added to the underlying class model.

I try to keep my class diagrams all focused on a single topic, and try to keep the number of classes less than 20. I like to create separate diagrams for each major behavioral process. For example I might have a separate diagram for expressing the structural relationships involved in an object to relational mapping mechanism. Only those relationships and classes that participate in this process are expressed in this diagram. In other diagrams of the model these same classes may also appear and possibly with additional relationships suitable for expressing whatever the diagram's purpose was to show.

Component diagram - shows components and their dependencies on each other. A component is in this sense a distributable part of the system (DLL, EXE, Java .class or JAR file, etc.). Components realize classes and most likely have dependencies on each other. For example my VB EXE might have a dependency on the ADODB recordset ActiveX control, or my Enterprise Java Bean which has a dependency on my vendor's ejb.jar implementation.

The component diagram is useful for expressing these dependencies which are not only useful during development, but also during deployment.

Deployment diagram - shows the nodes in the system and which processes (i.e. components) are running in each. In a web application there are nodes for the client, web server, application server and database server. The components running in the client are the web browser, and any JavaScript or Applets. The web server runs all the ASP/JSP/PHP/CFM pages and code. The application server contains all the transactional components (MTS/EJB) and owns the bulk of the business logic. The database node might also execute some key stored procedures, but mostly runs the database code.

Object diagram - shows an example of object instances that are participating in a specific scenario, and the relationships between them. Each object (not a class!) in these diagrams represents an object instance. This diagram is useful for getting an understanding in to the nature of the structural relationships in a collaboration (not the dynamics). I like to use this diagram to get an idea of what and how many object instances are involved in a particular collaboration. In an object diagram of a web application's shopping cart there might be many objects instances of a LineItem class. Each would have it own object name and state (each one representing one line in the cart).

I like to use object diagrams to flesh out scenarios. They help me better understand the nature and characteristics of a specific behavior. I have to admit that I don't create many of these (except when modeling web app storyboards), and prefer sequence diagrams to express the behavior of scenarios.

Behavioral Diagrams:

Use Case diagram - shows the system's use cases as icons, and their relationships to other use cases and the actors of the system. This diagram IMHO is mostly a container for other behavioral diagrams. The real meat of a use case is of course in the specification which is a textual document.

Sequence diagram - shows a specific scenario of execution in the system in terms of object instances. This diagram focuses on the time ordered messages between objects that collaborate to accomplish some task (e.g., process a payment, or search a catalog).

Collaboration diagram - closely related to the object diagram and sequence diagram. This diagram expresses a single scenario like the sequence diagram, but in this case the focus is not on time but rather object instances. It still contains ordered messages between objects but in a collaboration diagram you can position the object instances anywhere, and better express a combination of structural and behavioral concepts.

Statechart diagram - shows a state machine. Great for expressing the state of a user interface or workflow, where the interface disables certain functions according to some state of operation. In real-time architectures, the state chart is the principal diagram for expressing the system's behavior, and the principal source for code generation.

Activity diagram - flow chart on steroids. This diagram is great for expressing process flow. I like to create an activity diagram for each use case in the system. This helps me ensure that there are no loose ends in a use case's textual description.