What You'll Learn in This Hour:
The scenario for the case study
Discovering and modeling business processes
Tips on interviewing
Now that you've had some UML experience and exposure to a skeleton development methodology, you're going to see how the UML is applied in a development effort. This hour begins Part II, a case study that applies the UML in the context of the GRAPPLE process.
The noted multinational (and fictional) conglomerate LaHudra, Nar, and Goniff, Inc. has surveyed the world of restaurants and come to some startling conclusions: People like to eat out, but they don't enjoy some parts of the experience.
“You know,” said LaHudra, “I could have predicted the results from our survey. When I go out to eat, I hate it when I give the waiter my order and he disappears for an hour. Go out to a classy place, and you expect better treatment than that.”
“That's true,” said Nar. “Sometimes I change my mind after I order and I want to get a hold of the waiter. Or I have a question . . . or something . . . and I can't find the guy.”
Goniff chimed in: “I agree. But still, the dining-out experience is a lot of fun. I like it when someone waits on me. I like the idea of a kitchen staff preparing a meal for me. Our survey results show that most people feel that way, too.”
“Isn't there some way we can retain the essential experience but enhance it somehow?”
“How?” asked Nar.
“I know how!” said LaHudra. “With technology.”
And that's when they decided to have one of their corporate software development teams build the restaurant of the future.
The development team members are all strong proponents of GRAPPLE. They understand that most of the project time will be devoted to analysis and design. That way, coding will take place quickly and efficiently, and the likelihood of a smooth installation and deployment will increase.
The effort has to start with requirements gathering and with an understanding of the restaurant domain. As you'll recall from the last hour, the requirements-gathering segment consists of these actions:
Discovering business processes
Performing domain analysis
Identifying cooperating systems
Discovering system requirements
Presenting results to client
In this hour, you'll cover the first action.
LaHudra, Nar, and Goniff don't do anything in a small way. They're ready to take on the world of restaurants, and they've put together a new LNG Restaurants Division. They've hired a number of experienced restaurateurs, waiters, chefs, and maintenance people.
All they're waiting for is the technological backbone for the restaurant of the future. Then they'll launch their first restaurant, complete with the technology to increase the pleasure of dining out.
The development team members are lucky. They're starting with a blank piece of paper. All they have to do is understand the business processes and the domain, and then they're on their way.
The business process analysis starts with an analyst interviewing a restaurateur. During the interview, a note-taker is sitting by, typing away at a laptop. At the same time, a modeler is working at a whiteboard, drawing and modifying an activity diagram that the analyst, the note-taker, and the restaurateur can all see.
In the subsections that follow, we'll go through an interview for each business process in a restaurant. The goal is to produce activity diagrams that model the processes.
“Thanks for taking the time to do this,” said the analyst.
“My pleasure,” said the restaurateur. “What exactly do you want to know?”
“Let's start with a single business transaction. What happens when a customer walks into a restaurant?”
“It works like this: If the customer has a coat on, we help him or her take it off and store it in our cloakroom, and then we give the customer a coat-check ticket. We can do that for a hat, too. Then we . . .”
“Just a second. Let's backtrack. Suppose there's a waiting line. Do they get in line first, or leave their name up front, or . . .”
“No. We try to make them feel as comfortable as possible right off the bat. Then we worry about lines, if there are any. If, in fact, there's a waiting list, we ask the customer whether or not they made a reservation. We always try to honor those in a timely way and seat people with reservations as quickly as possible. If there's no reservation, they leave their name and then they have the option of going to our cocktail lounge and having a drink before dinner. They don't have to do that, of course. They can sit and wait in a well-appointed waiting area.”
“Interesting. They haven't even sat down yet to order a meal, and several decision points have already been reached.”
Let's stop for a moment and take stock of where we are. The activity diagram of the business process now looks something like Figure 16.1.
Figure 16.1. The beginning stages of the activity diagram for the restaurant business process “Serving a customer.”
Back to the interview.
The analyst's job is to proceed with the business process.
“Okay. After the waiting-list customer's turn comes up, or the reservation customer has arrived, it's time to seat that customer, right?”
“Right. But, now that I think of it, it's not quite that simple. The table has to be ready. It has to be clean, of course, so a busser gets rid of the tablecloth from the previous customer and sets the table. When it's ready, the maitre d' walks the customer to the table and calls for a waiter.”
“'Calls for'?”
Tip 1: Pursue Definitions
Notice what the analyst does here. The restaurateur has used a new term (“new” within the context of the interview), and the analyst pursues the definition.
Knowing when and how to do this is part of the art of interviewing, and experience is the best teacher.
“Yes. That's not too involved because waiters have their designated serving areas, and they generally know when a table is ready. They sort of hover in the area, and they usually see the maitre d' gesturing for them.”
“What happens next?”
“Well, the waiter takes over from here. He shows each diner a menu, and he asks them whether they want to order drinks while they decide. Then he calls over an assistant who brings a tray of bread and butter and pours a glass of water for each person in the party. If someone orders a drink, the waiter goes and gets it.”
“Just a second. You said 'he.' Is the person who waits on tables always a man?”
“No. I just say that out of force of habit. Sorry.”
“Okay. How about if we use the neutral term 'server'? I also notice that the customer has a couple of opportunities to order a drink.”
“That's true. If a customer is waiting for a table and they're in the lounge with a drink, they can bring the drink to the table if they haven't finished it by the time the table is ready. By the way, we always reserve the right to refuse service to someone who's obviously had one too many.”
Tip 2: Detect Business Logic
The interviewer isn't just a passive listener after asking a question. Here, the analyst has put together a common theme from some earlier answers and asked a question based on something cropping up a few times (the opportunity to order a drink).
The answer contains a piece of business logic, a rule that the business follows in a particular situation. In this case, the business logic pertains to refusing service to an inebriated customer.
“Glad to hear it. We're back at the table with the diners deciding on a menu choice.”
“Yes. We always have some daily specials that aren't on the menu, and the waiter . . . uh, server . . . recites those to the customers.”
“You know what I've noticed happens a lot? People ask the server what they recommend, and the servers usually seem pretty honest—they'll tell you if one dish is better than another. Is that something you encourage?”
“Yes, I do. Certainly our servers eat at our restaurant, and they have their opinions on what they like and don't like. If they really, really don't like a particular dish, we want them to tell the chef before they tell the customer, but I don't mind if they express a preference. Of course, we don't want our servers telling the customers the food stinks, but expressing a preference for one dish over another is okay.”
“Understood. All right, let's summarize. The customer and . . . Well, it's actually a party isn't it? . . . The party leaves their coats, possibly sits in the lounge if they're waiting for a table, gets seated, possibly orders drinks, gets served bread and water, and looks at the menu.”
Tip 3: Stop and Summarize
It's a good idea to stop and summarize from time to time. It helps you check your understanding, gives you the opportunity to use the domain's terminology, and usually gives the interviewee a comfort level that you've been listening intently to him or her.
“Right. The server comes back with any drinks, and the customers drink while they read the menu. The server allows them five to ten minutes to make a selection and then comes back. The server comes back sooner, of course, if they've made up their minds sooner.”
“How does the server know to come back sooner?”
“Well, they have to somehow get his attention. The server's usually in the area of the table, unless he's back in the kitchen getting an order or talking with the chefs for some reason.”
“Area?”
“Yes. Each server is assigned an area that consists of a number of tables. One area is designated as the smoking area, the rest are for non-smokers.”
“How do you determine who serves in what area?”
“We rotate the servers through all the different areas.”
“Let's get back to the serving process. The diners make their selections, the server writes them down, and then . . .”
“And then notifies the chef. The server does that by writing the selection on a form he gives the chef.”
“What's on the form?”
“The table, the selection, and—this is extremely important—the time.”
“Why is that so important?”
“Because the kitchen is usually (we hope) a very busy place, and the chef often has to prioritize his efforts in terms of the time an order arrives.”
“Can that get complicated?”
“Actually, it gets a little more complicated down the line.”
“How so?”
“Most meals consist of an appetizer before the main course. Most people like to have the main course hot. So the chef prepares the appetizers—many are already made, like some of the salads—and the server brings them out to the party. The challenge is to bring out the main course for everyone in the party at the same time and have it hot. I say 'challenge' because people at the table typically finish their appetizers at different times. The whole thing has to be coordinated.”
“Hmmm . . . This sounds like a separate process. Let's have it be a whole different discussion—from the chef's point of view.”
“Okay. That sounds like a good idea.”
“We're at the point where the chef is cooking the main course. By the way, how does our diagram look to you?” (See Figure 16.2.)
Figure 16.2. The intermediate stages of the activity diagram for the restaurant business process “Serving a customer.”
“I think you've got it. Anyway, the chef cooks the main course, and the server picks it up when the people in the party are finished with their appetizers. The server brings it to the table. The people eat their meals, and the server comes over at least once to check on things.”
Tip 4: Discuss Complex Processes Separately
The analyst has made an important decision—to put off the discussion of a sequence that will probably turn out to be a separate process. Recognizing when to do this comes with experience.
A good rule of thumb is, if the interviewee uses words such as complex and complicated, or answers “yes” when you ask whether something's about to get complicated, you're probably facing a set of steps that will require its own model. Let the interviewee talk a bit before you make the decision on this.
“Suppose a customer isn't satisfied with something about the meal?”
“Then we do our best to make sure they are, even if it costs us some money. It's better to lose a little money than to lose a customer.”
“Nice concept.”
“Thanks. When the diners finish their meals, the server comes by and asks whether they want dessert. If they do, the server provides a dessert menu and takes their orders. If not, he asks if they want coffee. If they do, the server brings coffee and cups, and pours it for them. If they don't want anything, the server brings the check. After a few minutes, he comes by and collects cash and/or credit cards. He brings change and/or credit card receipts, the customers leave a tip, pick up their coats, and leave.”
“Is that it?”
“Not quite. The server calls a busser over to clean the table, set it, and get it ready for the next party.”
“Since that doesn't involve the customer, I'm going to consider that a separate process, albeit a brief one. I wanted to ask you a couple of questions. First, how does the server know when the people are finished?”
“He stays in his area and glances over at each table. With experience, he knows about how long it takes to eat a meal, so he can anticipate when to be near the table. You have another question?”
“Yes. Earlier you said the server might be back in the kitchen talking to the chef for some reason. Why does that happen?”
“Sometimes a customer wants to know how long it will be before the meal comes out. In cases like that, the customer summons the server, who goes back and asks the chef. When he finds out, he comes back and tells the customer.”
“You know, I never realized all the things that go into serving a customer in a restaurant.”
“Funny you should say that. Until you asked me to spell out all the steps, I never thought that much about it. I think your diagram captures everything I said, and it's a useful picture for clarifying my own thinking.” (See Figure 16.3.)
As you learned in Hour 11, “Working with Activity Diagrams,” you can turn an activity diagram into a swimlane diagram. When you model a business process, this is a good thing to do because the swimlane diagram shows how each role figures into the process. Figure 16.4 is a swimlane diagram for the business process “Serving a customer.”
Remember that first separate business process the interview revealed? Let's rejoin the analyst and the restaurateur and explore the process of “Preparing the meal.”
“When we were talking before,” said the analyst, “you mentioned that most meals provide an appetizer before the main course, and that most people prefer the main course hot. You mentioned the challenge of bringing out the main course for everyone in a party at the same time and still having it hot, and you mentioned the importance of coordination. Could you elaborate?”
“Certainly,” said the restaurateur. “People in a party almost always finish their appetizers or salads or soups at different times. We have to coordinate to bring out hot main courses to everyone. The coordination takes place between the server and the chef. The chef receives the order from the server and starts preparing the appetizers and cooking the main course. When the appetizers are finished, the server comes back to the kitchen, gets the main courses, and brings them out to the table.”
“And the server knows the appetizers are done because . . . ?”
“Because he checks the kitchen from time to time. Now, here's where the coordination comes in: The chef, after giving the appetizer to the server, relies on the server to let him know when everyone in the party is almost finished with their appetizers before he puts the final touches on the main course. The server stays in his or her designated area and keeps an eye on the table. At the appropriate time, the server goes back to the kitchen, tells the chef the party is just about ready for the main course, and the chef finishes preparing it. A skillful chef, working with a group of assistants, balances the meal preparation for a number of parties at once. The goal is to have the main course ready as soon as everyone in the party is ready for it.”
“Does it always happen exactly on time?”
“No, not always. But with a little experience and common sense, you get it right more often than not. What sometimes happens is that one slow eater in a group isn't quite ready when we bring out the main course, but that's a minor glitch.”
“Got it. What do you think of our diagram for this process?” (See Figure 16.5.)
As was the case with the previous business process, a swimlane diagram is appropriate, as Figure 16.6 shows.
“Let's get back to that other separate process—the one where the busser cleans the table,” said the analyst.
“That one involves a little coordination, too. The server first makes sure everyone has left and then calls for the busser to come and take care of the table. On a busy night, this has to happen quickly. We don't have as many bussers as we have servers, so sometimes this is a haphazard process. The bussers aren't always nearby, so the server might have to hunt for one.”
“I think I know what you mean by 'take care of the table,' but how about getting a little more specific?”
“Sure. In the restaurants I run, we have a new tablecloth for every party. So the busser has to remove the used tablecloth, bundle it up, and bring a fresh set of silverware and cloth napkins to the table. He folds the napkins and arranges the silverware and a plate for each position at the table. Then he brings the bundled-up tablecloth to a room in back of the kitchen. We pack them up and send them to the laundry the next day.”
Figure 16.7 shows the activity diagram for this process.
If you're an aspiring analyst, remember these lessons from this “interview”:
It's good to stop and summarize from time to time to test your understanding, practice with the terminology, and make the interviewee comfortable.
Always get the interviewee to explain any terminology that you think is unfamiliar. Don't worry about looking unknowledgeable. The reason you're there is to acquire knowledge and learn the terminology. After all, you're going to have to use the new vocabulary when you get into the domain analysis.
Every so often, you'll be able to ask a question based on a theme you discern in the answers to some preceding questions. Keep your mind and ears open for opportunities to ask questions like this. Business logic often emerges in the answers.
Take note when rules of business logic come out. Maintain a record of these rules. They'll probably come in handy later. (You never know—someday you might want to build an automated decision tool that relies on these rules.) Of course, a running record should appear in the meeting notes.
If you sense part of the process becoming complicated and convoluted, consider setting off the complication as a separate business process. It will be easier to model, and the resulting model will be clearer than if you try to lump everything together into one process.
Get the interviewee's feedback on the activity diagram. Make any modifications that he or she suggests.
You've been through a lot in this hour, and you got a look at some valuable techniques. As you gain experience, you'll come up with some techniques of your own.
In the next hour, you'll learn about domain analysis.
This hour introduced the scenario for a case study that applies the UML in a development effort. In the scenario, the fictional conglomerate LaHudra, Nar, and Goniff decides to incorporate computer technology into the restaurant of the future. As an analyst, your job is to understand the business processes involved, understand the domain, and gather the requirements—actions in the first segment of GRAPPLE.
The newly created LNG Restaurants Division supplies you with the domain experts you'll require to understand the business processes.
The content of this hour was largely devoted to the dialog in an interview and how that might proceed. Interspersed notes provided hints about how to conduct the interview. The objective was to show you how to map the interview results into a UML model.
In the next hour, you'll learn about analyzing a domain.
To really get the hang of all this, follow along with the quiz questions and exercises. The answers are in Appendix A, “Quiz Answers.”
1: | Try applying the principles from this hour to a different domain. Suppose LaHudra, Nar, and Goniff have engaged you to head up a development team to build a system for their corporate library. Start the requirements-gathering segment by understanding and modeling the business processes involved. For this one, you'll have to rely on your own knowledge of libraries. Hold on to your notes for your solution because you'll use this library example in the exercises for the hours that follow in Part II, “A Case Study.” |
2: | Go back over the interviews in this hour. What pieces of business logic emerged? |
3: | Although the activity diagrams in this hour are sufficient for describing business processes, you might want to try your hand at applying a technique from UML 2.0. Take a look at Figure 16.5. What object nodes would you include? |