UMLClass Diagrams

We've seen how use case diagrams can depict who the users are—actors, what tasks the users are performing—use cases, and some of the principle ways these tasks relate to one another—the relationships among use cases. We've also seen how to describe just enough task detail to drive user interface and system specification using narrative scripts and their diagrammatic equivalent, a sequence diagram. Here we will explore how to describe in one unified picture the user's domain vocabulary.

Describing the user's domain vocabulary as a coherent whole is an essential part of system design. User interface analysts and designers are concerned with consistently portraying the user's domain to avoid usability problems arising from inconsistencies. For very similar reasons, information architects create controlled vocabularies to be certain web sites provide a consistent view of a user domain. And software engineers want a consistent description of the user's domain to be certain that a set of user requirements are coherent—that is,not self-contradictory—and to provide themselves with a sort of checklist to be sure that all user requirements are provided for by their design. All of these concerns can be addressed using the techniques discussed here.

Representing Domain Concepts

The first thing to do is to get an initial sense of what the user's concepts are. The best way to do this is to compile a list of the nouns that appear in narrative task descriptions, whether formal or informal. Each of these nouns should have an operational definition of each concept. The operational definition succinctly describes the concept and provides the basis for a more detailed description. This definition also serves as a manageable way to check consistency across concept definitions. Since operational definitions are short, it is much easier to spot gross inconsistencies.

The next step is to drive the detail down one level and, at the same time, to create a single representation of a group of related concepts to provide an even higher degree of consistency among definitions. One way to achieve this is through the use of a UML class diagram.

The figure below is a UML class diagram depicting a user domain related to catalog order fulfillment.

Figure: a UML class diagram, over 650 pixels wide—click here to open it in a separate window.

The preceding diagram lists a number of user concepts related to ordering a number of products based on a catalog—either printed or electronic, we haven't specified that yet. Let's take a few of these concepts and illustrate some of the important parts of a class diagram and how these parts represent and define user concepts.

A class diagram fragment depicting the user concept, Order.

This diagram fragment shows just one user concept, Order represented as a UML class. This class graphically depicts the concept as a box. Within the box two aspects of the concept are also described: the attributes of the concept and the operations—actions—the concept is able to perform. In this case Order has one attribute associated with it, an order number.

This may seem like a very skimpy depiction of an Order and, in fact, it is. Orders are all about commercial transactions between a buyer and a seller specifying goods to be sold. But beneath this operational definition of Order lie many additional concepts. We need to capture these additional concepts without being redundant. After all, payments are made in many contexts, addresses are used for many purposes, and so on. The next diagram fragment will expand our view of Order to encompass these related concepts.

A class diagram fragment depicting the user concept, Order, and its relationships to other user concepts.

Let's examine the preceding diagram fragment by breaking it down to a number of equivalent text statements.

1. An Order is ordered by a Customer.
2. An Order is fulfilled by an Employee.
3. An Order is paid via a Payment Method.
4. An Order is shipped via an Address belonging to the Customer who is the buyer.
5. An Order is composed of Order Items.

From these statements we begin to see a fuller picture of an Order and how it relates to other Customer-related concepts. Each of the statements describes one of the relationships in the diagram fragment.

The first four of these relationships are called associations. An association is a way of expressing an aspect of one concept in terms of a second—though associations are not limited to two concepts we won't discuss n-ary associations here. For example, the first of these associations is named, ordered by, and connects Order and Customer. Each Customer can have zero or more Orders. Each Order has only one Customer doing the ordering. All this from two boxes, a line, and some text and numbers!

The fifth of the relationships in the above list is called a whole-part relationship—also known as a composition relationship. This relationship tells us that an Order is composed of many parts, in this case, one or more Order Items. Each Order Item takes its identity from the Order in which it is composed.

The Order only needs to know the Payment Method that is going to be used to pay for it. But different Payment Methods involve different details in both user task and in the attributes that must be collected. Let's look at one more fragment of our concept model to see how to represent this.

A class diagram fragment depicting the user concept, Payment Method. This fragment includes specific types of Payment Method.

This diagram fragment tells us that the concept Payment Method has three specific concepts—Check, Money Order, and Debit Card—that can be used interchangeably in place of Payment Method. In UML these relationships are called inheritance relationships. Psychologists might describe these as concept categories. From this perspective, Payment Method is a superordinate category while the more specific concepts are Basic-Level or Subordinate categories. They give us the means of partitioning our definitions so that concepts like Payment Method can evolve over time while concepts like Order maintain the core of the identity unchanged.

Summary

We've discussed the use of UML class diagrams to represent user concepts. The concepts we've discussed are entities—those concepts that represent the things our users manipulate with their tasks. Later this year I'll add discussions covering the use of class diagrams to summarize user tasks and user interface.