The development team will have additional interviews with the restaurant experts, but first they work within the context of the business-process interview. The objective is to produce an initial class diagram. An object modeler does this by either working with the team during the interview or by going over the results of the interview. At this point the modeler looks for nouns, verbs, and verb phrases. Some of the nouns will become classes in the model, and some will become attributes. The verbs and verb phrases can become either operations or the labels of associations.

Examine the results of the interview from the previous hour. What nouns and verbs did the restaurateur use?

Here are the nouns:

Notice that each noun is in its singular form.

The verbs and verb phrases are

When you first note all the nouns and verbs, keep your mind open and include everything. Would a modeler ultimately use all these words in the model? No.

Common sense dictates which ones to keep and which ones to eliminate. Further interaction with the restaurateur will also help.

Put yourself in the role of the modeler and start developing the class diagram. Here's where the aforementioned common sense comes into play. Start by eliminating some of the nouns.

Recall from the interview that waiter and server are synonymous. Thus, you can eliminate one of these terms. The interviewer and the interviewee decided on server, so you can eliminate waiter. Customer and diner are also synonymous, so you can eliminate another noun. Try sticking with customer. Person seems a little too generic, so you can eliminate that one, too. Menu choice and selection seem to say the same thing, so eliminate one of them. Selection seems more descriptive (although this is a matter of opinion), so keep that one for this example.

Can you eliminate any others? Some nouns are more appropriate as attributes rather than classes. In your list, name, time, and reservation fit that category. Another noun, laundry, isn't physically part of the restaurant, so you can eliminate it.

Here's the other side of the coin: It's also possible to add classes. If you examine the interview, you'll see that the restaurateur referred to “designated areas” and “rotating the servers.” Who does the designating and rotating? Clearly another class, manager, belongs on your list. That class might not have emerged during the original interview simply because the analyst was focusing on the customer, the server, the chef, and the busser.

Adding a class (and as you'll see later, adding abstract classes) reflects the evolution of understanding as the effort proceeds.

After filtering out the synonyms and attributes and adding the new class, here's the list of nouns that can become classes:

You can use these classes to build the class diagram in Figure 17.1, capitalizing the first letter of each class name. If the class name has more than one word, put all the words together and capitalize the first letter of each constituent word.

Figure 17.1. The initial class diagram for the restaurant domain.

Now you can try to form some meaningful groups. One group consists of people: customer, party, busser, maitre d', assistant, chef, server, and manager. This group could stand some subdivision because all of its members, except the customer and the party, are employees. So you're left with customer, party, and the employee group.

Another group consists of food items: drink, dinner, bread, butter, water, daily special, dish, appetizer, main course, dessert, and coffee.

A third group consists of utensils: glass, silverware, tray, cup, napkin, and tablecloth.

The fourth group holds payment items: coat-check ticket, check, cash, change, credit card, credit card receipt, and tip.

Another group consists of areas within the restaurant: waiting area, smoking area, cocktail lounge, cloakroom, kitchen, serving area, table, and room. Room refers to the room that holds the tablecloths (and presumably other items) that the restaurant sends out to the laundry. To make the last one more descriptive, call it laundry room.

Finally, you can group restaurant forms together: menu, dessert menu, coat-check ticket, check, and form. The last one is the form the server gives the chef when the order goes into the kitchen. To be more descriptive, call it order form.

Notice that a couple of these last items fall into two groups (forms and payment items). This, as you'll see, is acceptable.

What do you do with these groups? Each group name can become an abstract class—a class that generates no instances of its own but serves as a parent for subclasses. Thus, the abstract class RestaurantArea has CocktailLounge, ServingArea, Table, WaitingArea, Cloakroom, and Kitchen as its children.

You can modify the class diagram from Figure 17.1 and produce the diagram in Figure 17.2.

Figure 17.2. Abstract classes partition the class diagram into meaningful groups.

Next, create and label associations among some of the classes. The verbs and verb phrases can help with the labeling, but don't limit yourself to the ones from the interview. Labels that are somewhat more descriptive might suggest themselves.

One strategy is to focus on a few of the classes and see how they associate with one another, and then move on to another group until you've exhausted the set of classes. After that, you'll develop aggregations and composites. Finally, you'll incorporate verbs and verb phrases as class operations.

Associations with Customer

Begin with the Customer class. Which classes associate with Customer? Reservation is an obvious one. Another one is Server. Some others are Menu, Meal, DessertMenu, Dessert, Order, Check, Tip, Coat, and Hat. Figure 17.3 shows the associations.

Figure 17.3. Initial associations with the Customer class.

At this point, you can make some decisions. Is it necessary to include Coat and Hat? After all, you're focusing on serving a meal. After some discussion, the development team would probably conclude that these classes should stay in the model because your field of interest includes the whole dining-out experience. This leads you to add another class, CoatCheckClerk, because someone has to check the coat and hat for the customer.

Try labeling the associations by generating phrases that characterize the associations. Here are some phrases that immediately come to mind:

• The Customer makes a Reservation.

• The Customer is served by a Server.

• The Customer eats a Meal.

• The Customer eats a Dessert.

• The Customer places an Order.

• The Customer selects from a Menu.

• The Customer selects from a DessertMenu.

• The Customer pays a Check.

• The Customer leaves a Tip.

• The Customer checks a Coat with a CoatCheckClerk.

• The Customer checks a Hat with a CoatCheckClerk.

Figure 17.4 shows the labeled associations.

Figure 17.4. Labeled associations with the Customer class.

Now you can turn your attention to multiplicities. A multiplicity, remember, is part of an association: It indicates how many instances of class B associate with a single instance of class A.

In most of the bulleted phrases, the Customer is involved with one instance of the other class. The second phrase is different from the others. It has a passive voice (“is served by”) rather than the active voice in the other phrases (for example, “pays” and “leaves”). This suggests that something different might be happening with this association. If you turn it around and examine the association from the Server's point of view (“The Server serves a Customer”), it's apparent that a Server can serve many Customers.

The final two phrases map to a kind of association you haven't encountered before:

• The Customer checks a Coat with a CoatCheckClerk.

• The Customer checks a Hat with a CoatCheckClerk.

How do you model this?

This kind of association is called a ternary association. Ternary indicates that three classes are involved. You model this kind of association by connecting the associated classes with a diamond, and you write the name of the association near the diamond, as in Figure 17.5. In a ternary association, the multiplicities indicate how many instances of two classes are involved when the third class is held constant. In this example, one Customer can check zero or more Coats with one CoatCheckClerk. (It's possible to have more than three classes in an association. For the sake of generality, the UML refers to n-ary associations.)

Figure 17.5. A ternary association.

In the next subsection, you'll see another way to handle this.

Figure 17.6 shows all labeled Customer associations with the multiplicities included.

Figure 17.6. Including the multiplicities in the associations with the Customer class.

Associations with Server

That Customer-Server association is a nice segue into associations with the server. One way to model many of the Server associations is to treat them as ternary:

• The Server takes an Order from a Customer.

• The Server takes an Order to a Chef.

• The Server serves a Customer a Meal.

• The Server serves a Customer a Dessert.

• The Server brings a Customer a Menu.

• The Server brings a Customer a DessertMenu.

• The Server brings a Customer a Check.

• The Server collects Cash from a Customer.

• The Server collects a CreditCard from a Customer.

This will undoubtedly clutter up the model and make it difficult to comprehend. A more efficient way is to examine these associations, use the minimum number of labels, and attach appropriate association classes.

The Server's job is apparently to take and bring requested items. You attach an association class called RequestedItem, and in that class you specify what is taken or brought. To do that, you give the association class an attribute called itemType and make it an enumerated type. The possible values of the attribute are the possible items that the Server can bring or take.

Figure 17.7 shows this in action.

Figure 17.7. Using an association class in the Server associations.

The Server also associates with an Assistant and a Busser, as Figure 17.8 shows.

Figure 17.8. Additional associations with the Server.

Associations with Chef

The Chef associates with Assistants, with the Server, and with the Meal, as in Figure 17.9. The association class Order models the order the Server brings to the Chef, and its attribute (which can be an enumerated type) shows the order's status.

Figure 17.9. Chef associations with Assistant, Server, and Meal.

Associations with Busser

As Figure 17.10 shows, the Busser has two associations. One indicates that the Server calls the Busser, and the multiplicities indicate that more than one Server can call a Busser. The other association shows that a Busser sets more than one Table.

Figure 17.10. Busser associations with Server and Table.

Associations with Manager

Manager is the new class you derived during the domain analysis. This class associates with many of the others, and you would develop these phrases:

• The Manager operates the Restaurant.

• The Manager monitors the Employees.

• The Manager monitors the Kitchen.

• The Manager interacts with the Customer.

Figure 17.11 models these associations.

Figure 17.11. Associations with the Manager.

A Digression

One school of thought holds that you should eliminate nouns that are roles in associations and just have a general class such as Employee. In the association, you would put the role name near the appropriate end of the association.

In some contexts (such as a payroll system), that works well. In this one, it probably won't. Consider these associations:

• The Server brings to the Customer.

• The Server takes from the Customer.

• The Server brings to the Chef.

• The Server takes from the Chef.

• The Server summons the Busser.

The diagram looks like Figure 17.12.

Figure 17.12. Modeling with the Employee class.

As you can see, the class icons in the diagram become dense and unclear, and you haven't even included the association classes.

In all things modeling-related, let comprehensibility be your guide.

You've been forming and naming abstract classes and associations, and another organizational dimension awaits. The next step is to find classes that are components of other classes. In this domain, that shouldn't be difficult. A Meal, for instance, consists of an Appetizer, a MainCourse, a Drink, and a Dessert. The Appetizer and Dessert are optional. Also, the components are in a specific order, and you want that order preserved in your model.

Here are some other composites:

In each case, the component is a member of only one aggregate, so Figure 17.13 models all these as composites.

Figure 17.13. Composites in the restaurant domain.

Further interviews and sessions will prove helpful for fleshing out your classes. Bear in mind that from here on in, an object modeler will sit in on all sessions, work with a computer-based modeling tool and refine the model on the fly. You can begin the refinement now by adding some attributes and operations.

Your most important classes appear to be Customer, Server, Chef, Manager, and Assistant. Check is another important class.

Customer

What are the obvious attributes for Customer? Here are a few:

• name

• arrivalTime

• order

• serveTime

How about the operations? Your verb list can guide you (but shouldn't limit you). Some Customer operations are

• eat()

• drink()

• beMerry (just kidding!)

• order()

• pay()

Figure 17.14 shows the Customer class.

Figure 17.14. The Customer class.

Employee

Server, Chef, Manager, and Assistant are all children of the abstract class Employee. Thus, you assign attributes to Employee and the child classes inherit them. Some of these attributes are

• name

• address

• socialSecurityNumber

• yearsExperience

• hireDate

• salary

For the Assistant, things get a little more complicated. First, you'll need a separate attribute called worksWith because an Assistant can help either the Server or the Chef. This attribute will be an enumerated type.

Operations will be specific to each child class. For the Server, the following operations seem appropriate and appear in Figure 17.15:

• carry()

• pour()

• collect()

• call()

• checkOrderStatus()

Figure 17.15. The Employee class and its children.

For the Chef:

• prepare()

• cook()

• prioritize()

• createRecipe()

For the Assistant:

• prepare()

• cook()

• serveBread()

• serveWater()

The Manager operations include

• monitor()

• operateRestaurant()

• assign()

• rotate()

Check

The Check is obviously an important class because it contains the information on collecting money for the meal. Its attributes are

• mealTotal

• tax

• total

Because total is the sum of mealTotal and tax, it's a derived variable. To show this in the model, you precede total with a slash. (See Figure 17.16.). The Check's operations are computeTotal(mealTotal,tax) and displayTotal().

Figure 17.16. The Check class.

At this point, you've gathered a lot of information. Here are a few hints to help you keep it all organized:

What have you learned from going through the domain analysis?

In the next hour, you'll move out of the conceptual realm and into system-related issues.

This hour continued the conceptual analysis that began in the previous hour. The business process interview results provide the foundation for the domain analysis. The nouns, verbs, and verb phrases in the interview are the candidates for the initial class diagram that defines the restaurant domain. Common sense tells you which ones to use and which ones to eliminate. It's possible that you'll add classes as you do your analysis.

The object modeler adds substance to this diagram by deriving abstract classes, associations, and multiplicities. Deriving aggregates and/or composites helps organize the model. Additional interviews and sessions will be necessary to completely flesh out the model, but it's possible to begin adding attributes and operations at this point.

This workshop tests the all-important skill of domain analysis—as embodied in the creation and development of a class diagram. The answers are in the domain of Appendix A, “Quiz Answers.”