Head First Object-Oriented Analysis and Design

Chapter 4. Analysis: Taking Your Software into the Real World

It’s time to graduate to real-world applications.

Your application has to do more than work on your own personal development machine, finely tuned and perfectly set up; your apps have to work when real people use them. This chapter is all about making sure that your software works in a real-world context. You’ll learn how textual analysis can take that use case you’ve been working on and turn it into classes and methods that you know are what your customers want. And when you’re done, you too can say: “I did it! My software is ready for the real world!”

One dog, two dog, three dog, four...

Things are going well at Doug’s Dog Doors. The version of the dog door you just developed in Chapter 3 is selling like crazy... but as more doors get installed, complaints have started coming in:

Your software has a context

So far, we’ve worked on writing software in a vacuum, and haven’t really thought much about the context that our software is running in. In other words, we’ve been thinking about our software like this:

But our software has to work in the real world, not just in a perfect world. That means we have to think about our software in a different context:

The key to making sure things work and that the real world doesn’t screw up your application is analysis: figuring out potential problems, and then solving those problems—before you release your app out into the real world.

Analysis helps you ensure your system works in a real-world context.

Identify the problem

The first step in good analysis is figuring out potential problems. We already know that there’s a problem when there are multiple dogs in the same neighborhood:

Plan a solution

It looks like there’s a change we need to make in what our system does. Do you know what it is? Below is a part of the diagram detailing how the dog door system works:

Sharpen your pencil

What’s wrong with this diagram?

It’s your job to figure out how you would fix the dog door. You can add steps, remove steps, or change steps... it’s up to you. Write down what you think you need to change, and then mark your changes on the diagram above.

_____________________________________________________________________

_____________________________________________________________________

Sharpen your pencil answers

What’s wrong with this diagram?

There are no Dumb Questions

Q:	Q: I came up with a different solution. Does that mean my solution is wrong?
A:	A: No, as long as your solution kept all the dogs except for Bruce from going in and out of the dog door. That’s what makes talking about software so tricky: there’s usually more than one way to solve a problem, and there’s not always just one “right” solution.
Q:	Q: In my solution, I turned step 3 of the original use case into two steps, instead of just replacing the existing step. Where did I go wrong?
A:	A: You didn’t go wrong. Just as there is usually more than one solution to a problem, there is usually more than one way to write that solution in a use case. If you use more than one step, but have the scenario with other dogs barking handled, then you’ve got a working use case.
Q:	Q: So these use cases really aren’t that precise, are they?
A:	A: Actually, use cases are very precise. If your use case doesn’t detail exactly what your system is supposed to do, then you could miss an important requirement or two and end up with unhappy customers. But, use cases don’t have to be very formal; in other words, your use case may not look like ours, and ours might not look like anyone else’s. The important thing is that your use case makes sense to you, and that you can explain it to your co-workers, boss, and customers.

Write your use cases in a way that makes sense to you, your boss, and your customers.

Analysis and your use cases let you show customers, managers, and other developers how your system works in a real world context.

Brain Power

There’s an important addition that needs to be made to the dog door system, in addition to what’s shown in Sharpen your pencil answers. What is it?

Update your use case

Since we’ve changed our dog door diagram, we need to go back to the dog door use case, and update it with the new steps we’ve figured out. Then, over the next few pages, we’ll figure out what changes we need to make to our code.

We need a new use case to store the owner’s dog’s bark.

Our analysis has made us realize we need to make some changes to our use case—and those changes mean that we need to make some additions to our system, too.

If we’re comparing a bark from our bark recognizer to the owner’s dog’s bark, then we actually need to store the owner’s dog’s bark somewhere. And that means we need another use case.

Sharpen your pencil

Add a new use case to store a bark.

You need a use case to store the owner’s dog’s bark; let’s store the sound of the dog in the dog door itself (Doug’s hardware guys tell us that’s no problem for their door technology). Use the use case template below to write a new use case for this task.

Sharpen your pencil answers

Add a new use case to store a bark.

You need a use case to store the owner’s dog’s bark; let’s store the sound of the dog in the dog door itself (Doug’s hardware guys tell us that’s no problem for their door technology). Use the use case template below to write a new use case for this task.

There are no Dumb Questions

Q:	Q: Do we really need a whole new use case for storing the owner’s dog’s bark?
A:	A: Yes. Each use case should detail one particular user goal. The user goal for our original use case was to get a dog outside and back in without using the bathroom in the house, and the user goal of this new use case is to store a dog’s bark. Since those aren’t the same user goal, you need two different use cases.
Q:	Q: Is this really the result of good analysis, or just something we should have thought about in the last two chapters?
A:	A: Probably a bit of both. Sure, we probably should have figured out that we needed to store the owner’s dog’s bark much earlier, but that’s what analysis is really about: making sure that you didn’t forget anything that will help your software work in a real world context.
Q:	Q: How are we representing the dog’s bark?
A:	A: That’s a good question, and it’s one you’re going to have to answer next...

Design Puzzle

You know what classes you already have, and you’ve got two use cases that tell you what your code has to be able to do. Now it’s up to you to figure out how your code needs to change:

Your task:

1. Add any new objects you think you might need for the new dog door.

2. Add a new method to the DogDoor class that will store a dog’s bark, and another new method to allow other classes to access the bark.

3. If you need to make changes to any other classes or methods, write in those changes in the class diagram below.

4. Add notes to the class diagram to remind you what any tricky attributes or operations are used for, and how they should work.

A tale of two coders

There are lots of ways you could solve the design puzzle in Design Puzzle. In fact, Randy and Sam, two developers who Doug’s Dog Doors just hired, both have some pretty good ideas. But there’s more at stake here than just programmer pride—Doug’s offered the programmer with the best design a sparkling new Apple MacBook Pro!

Randy: simple is best, right?

Randy doesn’t waste any time with unnecessary code. He starts thinking about how he can compare barks:

Sam: object lover extraordinaire

Sam may not be as fast as Randy, but he loves his objects, so he figures that a new class devoted to dog barks is just the ticket:

Sharpen your pencil

Writing code based on a class diagram is a piece of cake.

You’ve already seen that class diagrams give you a lot of information about the attributes and operations of a class. Your job is to write the code for Sam’s Bark class based on his class diagram. We’ve written just a bit of the code to help get you started.

public class ____________ {
  private ___________ _________;

  public _____________(__________ ___________) {
    this._________ = ___________;
  }

  public ________ ___________() {
    __________ _________;
  }

  _________ _____________ ______________(________ ________) {
    if (________ instanceof _________) {
      Bark otherBark = (_________)_________;
      if (this._________.equalsIgnoreCase(_______._______)) {
        return __________;
      }
    }
    return ____________;
  }
}

Sharpen your pencil answers

Writing code based on a class diagram is a piece of cake.

Your job was to write the code for Sam’s Bark class based on his class diagram. Here’s what we did:

Note

Sam’s Bark class diagram.

Bark
sound: String
getSound(): String equals(Object bark): boolean

Sam: updating the DogDoor class

Since Sam created a new Bark object, he takes a slightly different path than Randy did in updating his version of the DogDoor class:

Comparing barks

All that’s left to do is add a comparison of barks into BarkRecognizer’s recognize() method.

Randy: I’ll just compare two strings

Sam: I’ll delegate bark comparison

Sam is using a Bark object, and he lets that object take care of all the sound comparisons:

Delegation in Sam’s dog door: an in-depth look

Sam is doing something very similar in his Bark and DogDoor classes. Let’s see exactly what’s going on:

1. The BarkRecognizer gets a Bark to evaluate.

   Doug’s hardware hears a dog barking, wraps the sound of the dog’s bark in a new Bark object, and delivers that Bark instance to the recognize() method.

   

2. BarkRecognizer gets the owner’s dog’s bark from DogDoor

   The recognize() method calls getAllowedBark() on the dog door it’s attached to, and retrieves a Bark object representing the owner’s dog’s bark.

   
   

3. BarkRecognizer delegates bark comparison to Bark

   The recognize() method asks the owner’s dog’s Bark object to see if it is equal to the Bark instance supplied by Doug’s hardware, using Bark.equals().

   

4. Bark decides if it’s equal to the bark from Doug’s hardware

   The Bark object representing the owner’s dog’s bark figures out if it is equal to the Bark object from Doug’s hardware... however that needs to happen.

   Note

   The details of how this comparison happens are hidden from all the other objects in the dog door application.

   

The power of loosely coupled applications

In Chapter 1, we said that delegation helps our applications stay loosely coupled. That means that your objects are independent of each other; in other words, changes to one object don’t require you to make a bunch of changes to other objects.

By delegating comparison of barks to the Bark object, we abstract the details about what makes two barks the same away from the BarkRecognizer class. Look again at the code that calls equals() on Bark:

Now suppose that we started storing the sound of a dog barking as a WAV file in Bark. We’d need to change the equals() method in the Bark class to do a more advanced comparison of sounds and account for the WAV files. But, since the recognize() method delegates bark comparison, no code in BarkRecognizer would have to change.

So with delegation and a loosely coupled application, you can change the implementation of one object, like Bark, and you won’t have to change all the other objects in your application. Your objects are shielded from implementation changes in other objects.

Delegation shields your objects from implementation changes to other objects in your software.

Back to Sam, Randy, and the contest...

With Randy’s quick solution, and Sam’s more object-oriented one, let’s see how their applications are working out:

Randy AND Sam: It works!

Both Randy and Sam ended up with a working dog door that let in only the owner’s dog.

Maria won the MacBook Pro!

To both Randy and Sam’s surprise, Doug announces that Maria, a junior programmer he got to work for the company as a summer intern, has won the laptop.

Randy: Oh, this is ridiculous. My solution worked! That laptop is mine, not some intern’s!

Sam: Whatever, man. My solution worked, too, and I used objects. Didn’t you read Head First Java? An object-oriented solution is the way to go... the laptop’s mine!

Maria: Umm, guys, I don’t mean to interrupt, but I’m not sure either one of your dog doors really worked.

Sam: What do you mean? We tested it. Bruce barked, “Rowlf!” and the door opened up... but it stayed shut for the other dogs. Sounds like a working solution to me.

Maria: But did you do any analysis on your solution? Does your door truly work in the real world?

Randy: What are you talking about? Are you some sort of philosophy major? Is this like a “there is no spoon” sort of thing?

Maria: No, not at all. I’m just wondering... what if Bruce were to make a different sound? Like “Woof” or “Ruff”?

Sam: A different sound? Like if he’s hungry...

Randy: ...or excited...

Maria: ...or maybe... he really needs to get outside to use the bathroom. That’s, ummm, sort of how things work in the real world, isn’t it?

Randy and Sam: I guess we hadn’t thought about that...

So what did Maria do differently?

Maria started out a lot like Sam did. She created a Bark object to represent the bark of a dog.

But Maria went even further: she decided that since a dog might have different barks, the dog door should store multiple Bark objects. That way, no matter how the owner’s dog barks, it still gets outside:

UML Up Close

We’ve added something new to our class diagrams:

Pay attention to the nouns in your use case

Maria’s figured out something really important: the nouns in a use case are usually the classes you need to write and focus on in your system.

Sharpen your pencil

Your job is to circle each noun (that’s a person, place, or thing) in the use case below. Then, in the blanks at the bottom of the page, list all the nouns that you found (just write each one a single time; don’t duplicate any nouns). Be sure to do this exercise before turning the page!

Sharpen your pencil answers

Your job was to circle each noun (that’s a person, place, or thing) in the use case below. Here’s the use case with all the nouns circled.

Maria: That’s right. That’s how I figured out I needed a Bark class... it showed up in the use case as a noun in Steps 2 and 6.3. So I created a Bark class.

Randy: So that’s where I went wrong... if I had looked at the use case and circled the nouns, I would have known to create a Bark class, too.

Maria: Probably. A lot of times, even if I think I know what classes I need, I double-check my ideas with the nouns in my use case to make sure I didn’t forget anything.

Sam: But you don’t need a class for some of those nouns, like “the owner” or “request,” or even “inside.”

Maria: That’s true... you still have to have some common sense, and understand the system that you’re building. Remember, you need classes only for the parts of the system you have to represent. We don’t need a class for “outside” or “inside” or “the owner” because our software doesn’t have to represent those things.

Randy: And you don’t need a class for “the button” because it’s part of the remote control—and we already do have a class for that.

Sam: This is all great, but I was just thinking... I came up with a Bark class, too, and I didn’t need the use case to figure that out.

Maria: Yeah... but then you didn’t end up with a dog door that really worked, did you?

Sam: Well, no... but that’s just because you stored more than one Bark object in the dog door. What does that have to do with the use case?

Looking at the nouns (and verbs) in your use case to figure out classes and methods is called textual analysis.

It’s all about the use case

Take a close look at Step 3 in the use case, and see exactly which classes are being used:

There is no Bark class here!

The classes in use here in Step 3 are BarkRecognizer and DogDoor... not Bark!

3. If the owner’s dog’s bark matches the bark heard by the bark recognizer, the dog door should open.

Note

Here’s Step 3 from the use case that Randy wrote for his dog door. In his Step 3, “bark” is a noun.

Step 3 in Randy’s use case looks a lot like Step 3 in our use case... but in his step, the focus is on the noun “bark”, and not “the owner’s dog.” So is Randy right? Does this whole textual analysis thing fall apart if you use a few different words in your use case?

What do you think?

Note

HINT: Look closely at Randy’s Step 3. Does it describe a system that works exactly the same as the system on page 170?

One of these things is not like the other...

It looks like Randy’s Step 3 is actually just a little bit different than our original Step 3... so where did Randy go wrong?

3. If it’s the owner’s dog barking, the bark recognizer sends a request to the door to open.

Note

Here’s our Step 3, from the original use case we wrote back in Chapter 3.

Focus: owner’s dog

Our original Step 3 focuses on the owner’s dog... no matter how the dog sounds when it barks. So if the owner’s dog barks with a loud “Rowlf!” one day, but a quiet “ruff” the next, the system will let the dog in, either way. That’s because we’re focusing on the dog, not a particular bark.

3. If the owner’s dog’s bark matches the bark heard by the bark recognizer, the dog door should open.

Note

And here’s Step 3 from the use case that Randy came up with for the same dog door.

Focus: owner’s dog’s bark

Randy’s use case focuses on the owner’s dog’s bark... but what if the dog has more than one sound it makes? And what if two dogs bark in a really similar way? This step looks similar to the original Step 3, but it’s really not the same at all!

There are no Dumb Questions

Q:	Q: So you’re telling me as long as I write use cases, all my software will work like it should?
A:	A: Well, use cases are certainly a good start towards writing good software. But there’s a lot more to it than that. Remember, analysis helps you figure out the classes from your use case, and in the next chapter, we’ll spend some time talking about good design principles in writing those classes.
Q:	Q: I’ve never used use cases before, and I’ve never had any problems. Are you saying that I have to write use cases to create good software?
A:	A: No, not at all. There are plenty of programmers who are good at their jobs, and don’t even know what a use case is. But if you want your software to satisfy the customer more often, and you want your code to work correctly with less rework, then use cases can really help you nail your requirements down... before you make embarrassing mistakes in front of your boss or a customer.
Q:	Q: It seems like this stuff about nouns and analysis is pretty tricky, and I’m not any good at English grammar. What can I do?
A:	A: You really don’t need to focus too much on grammar. Just write your use cases in conversational English (or whatever language you speak and write in). Then figure out what the “things” are in your use case—those are generally the nouns. For each noun, think about if you need a class to represent it, and you’ve got a good start on a real-world analysis of your system.
Q:	Q: But what if I make a mistake like Randy did, and use a noun in my use case when I shouldn’t?
A:	A: Randy’s mistake—using “bark” as a noun in step 3 of his use case—had nothing to do with Randy’s grammar. He didn’t think through the use case, and how his system would work in the real world. Instead of focusing on getting the owner’s dog outside, he was worrying about one specific bark. He focused on the wrong thing! When you write your use case, reread it, and make sure that it makes sense to you. You might even want to let a couple of friends or co-workers read through it, too, and make sure it will work in the real world, not just in a controlled environment.

A good use case clearly and accurately explains what a system does, in language that’s easily understood.

With a good use case complete, textual analysis is a quick and easy way to figure out the classes in your system.

Textual analysis tells you what to focus on, not just what classes you should create.

Even though we don’t have a Dog class, textual analysis gave us an important clue about what our system really needs to do: get the owner’s dog in and out of the door, regardless of how he barks. In other words, our analysis helped us understand what to focus on... and it’s not a specific bark.

Once you’ve figured that out, it makes sense to think about what a dog really does. Does a dog always bark the same way? That’s when Maria figured out her real-world solution: she realized that if the owner’s dog could bark in more than one way, and the point was getting the owner’s dog outside, then the dog door needed to store all the ways that the dog could bark, not just one of them. But Maria would have never figured this out if she hadn’t really analyzed her use case.

Sharpen your pencil

Why is there no Dog class?

When you picked the nouns out of the use case, one that kept showing up was “the owner’s dog.” But Maria decided not to create a Dog object. Why not? Below, write down three reasons you think Maria didn’t create a Dog class in her system.

1. _____________________________________________________________________

2. _____________________________________________________________________

3. _____________________________________________________________________

Answers in Sharpen your pencil answers.

Remember: pay attention to those nouns!

Even if the nouns in your use case don’t get turned into classes in your system, they’re always important to making your system work like it should.

The point is that the nouns are what you should focus on. If you focus on the dog in this step, you’ll figure out that you need to make sure the dog gets in and out of the dog door—whether he has one bark, or multiple barks.

Pay attention to the nouns in your use case, even when they aren’t classes in your system.

Think about how the classes you do have can support the behavior your use case describes.

The verbs in your use case are (usually) the methods of the objects in your system.

You’ve already seen how the nouns in your use case usually are a good starting point for figuring out what classes you might need in your system. If you look at the verbs in your use case, you can usually figure out what methods you’ll need for the objects that those classes represent:

Code Magnets

It’s time to do some more textual analysis. Below is the use case for the dog door you’ve been developing. At the bottom of the page are magnets for most of the classes and methods we’ve got in our system so far. Your job is to match the class magnets up with the nouns in the use case, and the method magnets up with the verbs in the use case. See how closely the methods line up with the verbs.

Code Magnets Solutions

It’s time to do some more textual analysis. Below is the use case for the dog door you’ve been developing. At the bottom of the page are magnets for most of the classes and methods we’ve got in our system so far. Your job is to match the class magnets up with the nouns in the use case, and the method magnets up with the verbs in the use case. See how closely the methods line up with the verbs.

Sharpen your pencil answers

Why didn’t Maria create a Dog class?

When you picked the nouns out of the use case, one that kept showing up was “the owner’s dog.” But Maria decided not to create a Dog object. Why not? Here are three reasons we think Maria made the right choice.

There are no Dumb Questions

Q:	Q: So the nouns in the use case turn into classes, and the verbs turn into methods?
A:	A: That’s almost it. Actually, the nouns are candidates for classes... not every noun will be a class. For instance, “the owner” is a noun in the use case (check out Steps 2.1 and 3.1, for example), but we don’t need a class for that noun. So even though “the owner” is a candidate for a class, it doesn’t become a class in the actual system. In the same way, the verbs are candidates for operations. For example, one verb phrase is “does his business,” but we just couldn’t bear to write a pee() or poop() method. We hope you’ll agree that we made the right choice! Still, textual analysis is a really good start to figuring out the classes and methods you’ll need in your system.
Q:	Q: It looks like the nouns that are outside the system don’t get turned into classes. Is that always true?
A:	A: Most of the time it is. The only common exception is when you have to interact with something outside the system—like when there’s some state or behavior that the system needs to work with on a recurring basis. In the dog door system, for example, we didn’t need a class for the owner because the Remote class took care of all the owner-related activity. If we ever needed to track owner state, though—like if the owner was asleep or awake—then we might have to create an Owner class.

From good analysis to good classes...

Maria’s Dog Door Class Diagram

UML Investigation

Maria’s gone pretty crazy with her UML diagrams... do you think you can figure out what all she’s done? On the diagram below, add notes to all the new things she’s added, and try and figure out what the lines, numbers, and additional words all mean. We’ve written a few notes of our own to get you started.

Answers in UML Investigation Complete.

Class diagrams dissected

There’s a lot more to a class diagram than boxes and text. Let’s see how some lines and arrows can add a lot more information to your class diagrams.

Sharpen your pencil

Based on the class diagram below, what types could you use for the barks member variable in your DogDoor class? Write your ideas in the blank below:

Note

Answers to this exercise are in Sharpen your pencil answers.

_____________________________________________________________________

UML Investigation Complete

Maria’s gone pretty crazy with her UML diagrams... see if you can figure out everything that she’s done.

Exercise Solutions

Sharpen your pencil answers

Based on the class diagram below, what types could you use for the barks member variable in your DogDoor class? Write your ideas in the blank below:

List, Array, Vector, etc._________________________________

Note

You could write any type that supports multiple values... most of the Java Collection classes would work.

Note

Notice that this diagram, although positioned very differently, has the same classes and associations as this diagram.

Randy: I may have missed creating a Bark class, but my solution wasn’t that bad, and I didn’t waste a bunch of my time drawing squares and arrows.

Maria: Haven’t you ever heard that a picture is worth a thousand words? Once I had my class diagram, I had a pretty good idea about how my whole system was going to work.

Randy: Well, yeah, I guess I can see that... but I had a good idea of how my system would work, too. It was just in my head, not drawn out on paper.

Sam: I think I’m starting to come around on this UML thing, Randy. I mean, once you’ve got the use case, it’s pretty natural to do some analysis, and turn the nouns into classes. It seems like you wouldn’t have to spend as much time worrying about what should be a class, and what shouldn’t.

Maria: Exactly! I hate writing a bunch of classes and then finding out I did something wrong. With use cases and class diagrams, if I make a mistake, I can just scribble things out and redraw my diagram.

Note

Remember how we said OOA&D helps you write great software, every time? This is one way OOA&D can help you avoid making mistakes in your code.

Randy: Well, I guess that’s true. Rewriting code takes a lot more time than rewriting a use case or redrawing a class diagram...

Maria: And you know, if you ever have to work with anyone else, you’re going to have to explain that system in your head to them somehow, right?

Sam: I think she’s right, Randy. I’ve seen your whiteboard when you’re trying to explain your ideas... it’s a mess!

Randy: OK, even I can’t argue with that. But I still think class diagrams don’t tell the whole story. Like, how is our code actually going to compare barks and figure out if the dog door should open up?

Class diagrams aren’t everything

Class diagrams are a great way to get an overview of your system, and show the parts of your system to co-workers and other programmers. But there’s still plenty of things that they don’t show.

Class diagrams provide limited type information

Class diagrams don’t tell you how to code your methods

Class diagrams only give you a 10,000 foot view of your system

What’s Missing

Class diagrams are great for modeling the classes you need to create, but they don’t provide all the answers you’ll need in programming your system. You’ve already seen that the dog door class diagram doesn’t tell us much about matching up return types; what other things do you think are unclear from this diagram that you might need to know to program the dog door?

Add notes to the diagram below about what you might need to figure out in order to program the door. We’ve added a note about comparing barks to get you started.

Answer in What’s Missing

So how does recognize() work now?

Maria’s figured out that her BarkRecognizer class should be able to compare any bark it receives against multiple allowed barks, but her class diagram doesn’t tell us much about how to actually write the recognize() method.

Instead, we have to look at Maria’s code. Here’s the recognize() method of her BarkRecognizer, and how she solved the barking problem:

Exercise Solutions

What’s Missing

Add notes to the diagram about what you might need to figure out to program the door.

*These are just a few of the things we thought of. Your answers may be totally different, if you thought of other things that the class diagram doesn’t really show.

Bullet Points

• Analysis helps you ensure that your software works in the real world context, and not just in a perfect environment.

• Use cases are meant to be understood by you, your managers, your customers, and other programmers.

• You should write your use cases in whatever format makes them most usable to you and the other people who are looking at them.

• A good use case precisely lays out what a system does, but does not indicate how the system accomplishes that task.

• Each use case should focus on only one customer goal. If you have multiple goals, you will need to write multiple use cases.

• Class diagrams give you an easy way to show your system and its code constructs at a 10,000-foot view.

• The attributes in a class diagram usually map to the member variables of your classes.

• The operations in a class diagram usually represent the methods of your classes.

• Class diagrams leave lots of detail out, such as class constructors, some type information, and the purpose of operations on your classes.

• Textual analysis helps you translate a use case into code-level classes, attributes, and operations.

• The nouns of a use case are candidates for classes in your system, and the verbs are candidates for methods on your system’s classes.

Design Puzzle

Maria’s old computer screwed up all the code she wrote for her dog door except for DogDoorSimulator.java, shown on the next page. All we’ve got to go on are the code fragments from her solution in this chapter, her class diagrams, and what you’ve learned about good analysis, requirements and OO programming. It’s your turn to be a hero...

The problem:

You need to code the dog door application so that it satisfies all of Doug’s new customers (that’s a lot of potential sales), especially the ones with more than one dog in the neighborhood. The door should operate just as the use cases in this chapter describe the system.

Your task:

1. Start out by re-creating the dog door application as it was described in Chapter 3. You can download this code from the Head First Labs web site if you want a jump start.

2. Copy or download DogDoorSimulator.java, shown on the next page. This is the only file that survived Maria’s laptop meltdown.

3. Make your code match up with Maria’s class diagram, shown in From good analysis to good classes....

4. Start coding! First concentrate on getting all of your classes to compile, so you can begin testing.

5. Use the DogDoorSimulator class to see if things are working like they should.

6. Keep up the analysis and coding until your test class’s output matches the output shown on the next page. Don’t give up!

7. Once you think you’ve got a working dog door, check your code against ours at the Head First Labs web site. We’ll be waiting.

What’s My Definition

UML and use cases have a lot of terms that are similar to, but not quite the same as, the programming terms you’re already familiar with. Below are several OOA&D-related terms, and their definitions... but everything is all mixed up. Connect the term to the definition, and unscramble the mess.

Noun Analysis	Lists all the code-level constructs, along with their attributes and operations.
Multiplicity	This is the UML term that usually represents a method in one of your classes.
Attribute	Helps you figure out the candidates for methods on the objects in your system.
Class Diagram	Visually shows that one class has a relation to another class, often through an attribute.
Operation	Equivalent to a member variable in a class.
Association	Describes how many of a specific type can be stored in an attribute of a class.
Verb Analysis	You do this to your use case to figure out what classes you need in your system.

OOA&D Cross

You know you love it... try another puzzling crossword to get those new concepts lodged firmly in your brain.

Across	Down
1. Use cases should use this kind of language.	2. Analysis makes sure your application works in this place.
5. Every class diagram has one of these for each member variable.	3. An operation is UML-ese for this
10. This focuses on putting your application into the correct context.	4. You do this to your use cases to figure out the classes and operation in your system.
12. Software always works better in the testing lab than here.	6. He replaced Fido as this chapter’s star.
13. Maria won the laptop because she paid attention to the	7. Class diagrams are a great way to get this of your system.
14. This relates one class to another	8. How many of a type an attribute can hold is its ____________.
16. You write your use case so you can ____________ your customers	9. These types of diagrams are worth a thousand words to a programmer.
17. Use cases should be ________ as well as easily understood.	11. Use cases aren’t formal, but they are ________.
18. UML is this type of modeling language.	15. Verb is to operation as this is to attribute.

Exercise Solutions

What’s My Definition

UML and use cases have a lot of terms that are similar to, but not quite the same as, the programming terms you’re already familiar with. Below are several OOA&D-related terms, and their definitions... but everything is all mixed up. Connect the term to the definition, and unscramble the mess.