A Note Regarding Supplemental Files

Chapter 10. The OOA&D Lifecycle: Putting It All Together

Are we there yet? We’ve been working on lots of individual ways to improve your software, but now it’s time to put it all together. This is it, what you’ve been waiting for: we’re going to take everything you’ve been learning, and show you how it’s all really part of a single process that you can use over and over again to write great software.

Developing software, OOA&D style

You’ve got a lot of new tools, techniques, and ideas about how to develop great software by now... but we still haven’t really put it all together.

That’s what this chapter is all about: taking all the individual things you know how to do—like figuring out requirements, writing up use cases, and applying design patterns—and turning it into a reusable process that you can use to tackle even your trickiest software problems, over and over again.

So what does that process look like?

Let’s build a software project, from start to finish, using this process.

We’ve used all of the different parts of this process to work on software projects throughout the book, but we haven’t yet really put it all together. But that’s all about to change... we’re going to let you build a pretty complex piece of software in this chapter, from feature list to implementation and delivery.

Along the way, you’ll see for yourself how all the things you’ve been learning really do help you build great software. Get ready, this will be your final test.

OOA&D GENERAL’S WARNING: Answers to this exercise do NOT appear on the next page. Go ahead and work through this chapter, and we’ll come back to these answers at the end of the chapter.

Before we dive into the problem we’re going to be solving in this chapter, you need to make sure you see where all the things you’ve been learning fit in the big OOA&D Project Lifecycle. At the bottom of this page are OOA&D magnets for lots of the things you’ve learned about already; your job is to try and put those magnets on the right phase of the OOA&D lifecycle, shown again below.

You can put more than one magnet on each phase, and there are some magnets you may want to use more than once, so take your time, and good luck.

The problem

Here’s the project we’re going to work through in this chapter, from beginning to end:

Congratulations! Based on your amazing work for Rick’s Stringed Instruments and Doug’s Dog Doors, we’d like to commission you to program our brand new Objectville Travel RouteFinder.

With the recent increase in travel to Objectville, we want to provide tourists an easy way to see the wonderful sights that make Objectville so unique. The RouteFinder should be able to store Objectville’s complete network of subway lines, as well as all the stations along each line. Objectville’s subways are state-of-the-art, and can go backwards and forwards between stations, so you don’t need to worry about the direction of any of the lines.

The RouteFinder should also be able to take a starting station, and a destination station, and figure out a route to travel. Our travel agents should be able to print out the route, indicating which lines to take, which stations are passed on a line, and when travelers may need to get off one line and get on another at a connecting station.

We pride ourselves on flexibility and extensibility in Objectville, so we expect the RouteFinder to be easy to extend as we come up with new ways to provide our tourists the best experience around in object-based travel.

We look forward to seeing your design and a working RouteFinder soon. We’re all counting on you!

Sincerely,

Orbin Traveloctic, CEO

P.S. To help you get started, we’ve provided a map of Objectville’s subway lines, and a file with all of the stations and lines.

$image with no caption$

Objectville Diner

This page left intentionally blank, so you can cut out the cool Objectville Map on the next page and hang it up on your cubicle wall.

Write the feature list for the RouteFinder app.

We’re throwing you right into things. Your job is to take the Statement of Work in The problem, and use it to develop a feature list. You can refer back to Chapter 6 if you need help on what features are, and what a typical feature list looks like.

Objectville RouteFinder Feature List

________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________

You don’t have to use all of these blanks if you don’t think you need them all.

Q:
Q: Why aren’t we gathering requirements? I’m still not clear on how a feature is really that different from a requirement, anyway.
A:
A: Features and requirements are often used almost interchangeably. Most of the time, though, people say “feature” when they’re talking about BIG things that an application needs to do. So it might take several requirements to satisfy one feature. And since features are usually a little bigger-picture than requirements, it’s a good idea to start any new project by writing out a feature list, like we’ve done with the RouteFinder.
Q:
Q: Why did you list printing out the route as a separate feature? That’s pretty easy once you’ve got a valid route between two stations, isn’t it?
A:
A: It probably will be, yes. But the feature list isn’t just a list of hard problems you have to solve—it’s a list of all the things your application has to be able to do. So even if a feature seems easy or trivial, put it on your feature list anyway.

Now you should really know what you’re supposed to do

With a feature list in hand, you should have a good understanding of the things that your app needs to do. You probably even can begin to think about the structure of your application, although we’ll spend a lot more time on that in just a bit.

Once you’ve got your feature list down, you should move on to use case diagrams. Those will help you connect what your app does to how it will be used—and that’s what customers really are interested in.

Your feature lists are all about understanding what your software is supposed to do.
Your use case diagrams let you start thinking about how your software will be used, without getting into a bunch of unnecessary details.

Decide on the structure for the RouteFinder code.

With feature lists in hand, let’s look at how our app is going to be used. Below, we’ve started a use case diagram for the RouteFinder app. For this project, there are two actors, and just two use cases (sounds sort of simple, doesn’t it?).

It’s up to you to figure out who (or what) the two actors are, and to label the two use cases. If you need help, refer back to Chapter 6 for more on use case diagrams.

Answers in Exercise Solutions.

Use cases reflect usage, features reflect functionality

Let’s look more closely at one of the feature-use case matches we showed you on the last page:

The “Load network of subway lines” use case really does not directly use our feature that deals with representing the subway. Obviously, we have to be able to represent the subway for this use case to work, but it’s a stretch to tie the two together like this.

That’s not a mistake, though; when we’re writing use cases, we’re dealing with just the interactions between actors and a system. We’re just talking about the ways that your system is used (which is where the term “use case” came from).

The features in your system reflect your system’s functionality. Your system must do those things in order for the use cases to actually work, even though the functionality isn’t always an explicit part of any particular use case.

Q:
Q: Didn’t you say that I should be able to match up every feature to a use case in my system?
A:
A: Yes, and that’s still true. Every feature in your system will be at least a part of addressing one or more uses cases in your use case diagram. But that doesn’t mean that the use case has to actually directly use that feature. Lots of times, a feature makes it possible for a use case to function without being directly used by the use case itself.
In our RouteFinder, there would be no way to load a network of subway lines into the system (one of our use cases) without having a representation of a subway in the first place (one of our features). But the “Load Network” use case doesn’t have any steps that match up directly with that feature... the steps in the use case just assume that a representation of the subway exists. So the use case indirectly uses the feature, without explicitly referring to it.
Q:
Q: So is a use case a requirement, or is a feature a requirement?
A:
A: Both! Use cases are requirements for how people and things (actors) interact with your system, and features are requirements about things that your system must do. They’re related, but they are not the same. Still, to implement a system’s use cases, you’re going to need the functionality in the system’s features. That’s why you should always be able to map your features to the use cases that they enable and are used by.
Q:
Q: What happens if I find a feature that I can’t match up to a use case, even indirectly?
A:
A: You should take a hard look at the feature, and make sure it really is a required part of your system. Your customer—and her customers—only interact with your system through the use cases. So if a feature doesn’t at least indirectly make a use case possible, you’re customer really isn’t going to see a benefit. If you think you’ve got a feature that doesn’t really affect how your system is used or performs, talk it over with the customer, but don’t be afraid to cut something if it’s not going to improve your system.

The features in your system are what the system does, and are not always reflected in your use cases, which show how the system is used.
Features and use cases work together, but they are not the same thing.

We’re starting to pick up some steam. With use case diagrams in place, you’re ready to break this problem up into some smaller pieces of functionality. There are several ways to do this in any application, but our goal here is to keep the RouteFinder system very modular. That means keeping different pieces of functionality separate—each module should have a single responsibility.

Go ahead and break up the RouteFinder system into four different “modules”. Think carefully about the best way to break up your system... it isn’t necessarily going to line up with your four features (although it might!).

HINT: Remember, you need to handle the system’s functionality, but you also need to prove to the customer that your system works.

Now start to iterate

Iteration 1

Once you’ve broken up your software into several individual pieces of functionality, you’re ready to start iterating over each piece of functionality, until the application is complete.

At this point, we need to take our big-picture view of the system, from our use case diagram, and refine that into requirements that we can begin to tackle, one by one. For this first iteration, let’s take the “Load network of subway lines” use case, and turn that into a set of requirements that isn’t so big-picture. Then we can take care of that use case, and iterate again, working on the next use case.

Note

We’re taking the first use case from our diagram, and starting with it.

Write the use case for loading subway lines.

Turn that little oval into a full-blown use case. Write the steps that RouteFinder needs to take to implement the “Load network of subway lines” use case.

Load network of subway lines Use Case

_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
You can use more room, or more steps, if you need them.
_____________________________________________________________________

Not too sure about this use case? It’s OK... turn the page for some help...

You’ll often have to do some extra work between breaking up the problem and writing your use cases.

You’ve just uncovered a “secret step” in our process for writing software the OOA&D way:

If you get stuck writing a use case, there’s nothing wrong with taking a step back, and examining the problem you’re trying to solve a bit. Then, you can go back to your use case, and have a better chance of getting it written correctly.

A closer look at representing a subway

Iteration 1

Note

We’re on Iteration 1, trying to handle the first use case: loading a network of subway lines.

Before we can figure out how to load a subway line, there are two things we need to get a good grasp of:

Understanding the basics of what a subway system is.
Understanding the information an administrator would have when they’re loading a set of subway stations and lines.

What is a station?

A subway system has stations, and connections between those stations, and lines that are groups of connections. So let’s begin by figuring out exactly what a station is.

And a connection between two stations?

As soon as you start adding several stations, you’ve got to deal with the connections between those stations:

Then a line is just a series of connections...

If you put several connections together, then you’ve got a subway line.

Let’s take a look at that subway file

We’ve got a basic idea now of what a subway is, so let’s see what kind of data we’ve got to work with. Remember, Objectville Travel said they would send us a file with all the stations and lines, so this should give us an idea of what an administrator will use to load the lines into the subway system.

Iteration 1

Q:
Q: My use case looks totally different. Is your use case the only solution to the puzzle?
A:
A: No, not at all. By now you realize that there are lots of decisions you have to make to solve any problem, and our use case simply reflects the decisions we made. We’re going to work with this particular use case throughout the rest of this chapter, so make sure you understand our reasoning behind it, but it’s perfectly OK if you came up with your own use case that solves the same problem of loading a network of subway stations and lines.
Q:
Q: I didn’t add any steps about validation to my use case. Is that OK?
A:
A: Validation is something that you should add to your use case if you left it out. Making sure the stations for a connection actually exist is a lot like not having a dog door automatically close. It seems innocent enough, until the real world creeps in, and someone misspells a station name. Suddenly, you have the equivalent of software rodents: a connection that goes to a non-existent station. So if you left out validation, be sure to add it in to your own use case.

Iteration 1

Let’s see if our use case works

The use case for loading a network is a little tricky, and has several groups of steps that repeat. Let’s check the flow of things against our text file before we go on to analyzing the use case, and starting to design the classes in our system.

This time, it’s your job to take on two phases of the OOA&D process at once. First, you need to perform textual analysis on the use case below, and figure out the nouns that are candidate classes, and the verbs that are candidate operations. Write the nouns and verbs in the blanks provided below the use case.

Load network of subway lines Use Case

The administrator supplies a file of stations and lines.
The system reads in the name of a station.
The system validates that the station doesn’t already exist.
The system adds the new station to the subway.
The system repeats steps 2-4 until all stations are added.
The system reads in the name of a line to add.
The system reads in two stations that are connected.
The system validates that the stations exist.
The system creates a new connection between the two stations, going in both directions, on the current line.
The system repeats steps 7-9 until the line is complete.
The system repeats steps 6-10 until all lines are entered.

Nouns (candidate classes):

_________________	_________________	_________________
_________________	_________________	_________________

Verbs (candidate operations):

_________________	_________________	_________________
_________________	_________________	_________________

Iteration 1

It’s on to preliminary design. Using the candidate nouns and verbs you got from the use case, draw a class diagram below of what you think the subway system might look like modeled in code. Use associations and any other UML notation you think will help make your design clear and understandable.

Load network of subway lines Use Case

The administrator supplies a file of stations and lines.
The system reads in the name of a station.
The system validates that the station doesn’t already exist.
The system adds the new station to the subway.
The system repeats steps 2-4 until all stations are added.
The system reads in the name of a line to add.
The system reads in two stations that are connected.
The system validates that the stations exist.
The system creates a new connection between the two stations, going in both directions, on the current line.
The system repeats steps 7-9 until the line is complete.
The system repeats steps 6-10 until all lines are entered.

Nouns (candidate classes):

Verbs (candidate operations):

Iteration 1

To use a Line class or not to use a Line class... that is the question

It was pretty easy to look at our use case and figure out that we need a Station, Connection, and Subway class—those are fundamental to our system. But then we decided to not create a Line class. Instead, we just assigned a line name to each connection:

We made this decision based on one thing: we know how the system is going to be used. In the original Statement of Work (back in The problem) from Objectville Travel, we were told we needed to represent a subway, and get directions between one station and another. Once we have those directions, we can simply ask each connection for its line; there doesn’t seem to be a need for an actual Line class.

Your design decisions should be based on how your system will be used, as well as good OO principles.

Iteration 1

Q:
Q: I found the “validates that a station exists” verb, but where does that operation appear on any of the classes in your design?
A:
A: We modeled that operation as hasStation() on the Subway class. You could have called that operation validate() or validateStation(), but those aren’t as descriptive as hasStation(), and you should always try and make your code as readable as possible.
Q:
Q: Could you talk a little more about how you showed those repeated steps in the use case?
A:
A: Lots of times a use case has a set of steps that need to be repeated, but there’s not a standard way to show that in use cases. So we just made one up! The point of a use case is to provide you with a clear set of steps that detail what your system should do, and we thought the clearest way to show those repeated steps was to write down “Repeat Steps 7-9.”
Q:
Q: I’ve been thinking about that subway representation, and it looks a lot like a graph data structure to me. Why aren’t we using a graph?
A:
A: Wow, you must have taken a data structures or algorithms class recently! Yes, you can use a graph to represent the subway. In that case, each station would be a node, and each connection would be a labeled edge.
Q:
Q: So then why aren’t we using a graph structure in this example?
A:
A: We think it’s really overkill in this situation. If you already know about graphs and nodes and edges, and you happen to have code for that sort of data structure lying around, then go ahead and use them. But from our point of view, we’d do more work adapting a graph to our needs than just coming up with a few simple classes for Station and Connection. Like almost everything else in the design stage, there are several ways to solve a problem, and you need to choose a solution that works well for you.
Q:
Q: You lost me on the whole graph thing... what’s all this about edges and nodes?
A:
A: It’s OK; you don’t need to know about graphs in order to understand and solve this particular problem. It’s nothing to worry about, at least until we come up with a Head First Data Structures book (anyone? anyone?).

Code the Station class

We’ve got requirements in the form of a use case, a class diagram, and we know the Station class will fit into our Subway model. Now we’re ready to start writing code:

When you override equals() in Java, you should usually also override hashCode() to ensure correct comparisons.

The Java specification recommends that if two objects are equal, they should have the same hash code. So if you’re deciding on equality based on a property, it’s a good idea to also override hashCode() and return a hash code based on that same property. This is particularly important if you’re using your object in a Hashtable or HashMap, which both make heavy use of the hashCode() method.

Note

For a lot more on equals() and hashCode(), check out Chapter 16 of Head First Java.

Iteration 1

Write the Connection class.

Using the class diagram on the right, complete the Connection class by filling in the blanks with the correct lines of code. Be sure your class will compile before you turn the page and see our answers.

public class Connection {

  private _________ ___________, ____________;
  private _________ ___________;

  public Connection(__________ __________, _________ _________,
                    __________ __________) {
    this.__________ = station1;
    this.__________ = station2;
    this.__________ = lineName;
  }

  public _________ ___________() {
    ________ station1;
  }

  public _________ ___________() {
    ________ station2;
  }

  public _________ ___________() {
    ________ lineName;
  }
}

Iteration 1

Code the Subway class

Next up is the Subway class itself. With Station and Connection done, and a good class diagram, nothing here should be a surprise:

Points of interest on the Objectville Subway (class)

We threw a couple of new things into the Subway class; first, you’ll see this line of code quite a bit:

Station station = new Station(stationName);

For example, when we create a new Connection, we have code like this:

Station station1 = new Station(station1Name);
Station station2 = new Station(station2Name);
Connection connection =
  new Connection(station1, station2, lineName);

Lots of programmers would take station1Name, and iterate through the list of stations in the Subway class to find the Station object that has a name of station1Name. But that takes a lot of time, and there’s a better way. Remember how we defined an equals() and hashCode() method on our Station class?

These methods allowed us to tell Java that when it compares two Station objects, just see if their name is the same. If the names are equal, even if the objects don’t refer to the same location in memory, they should be treated as the same. So instead of looking for a particular Station object in the Subway class’s list of station, it’s much easier to just create a new Station and use it.

Note

Normally, equals() in Java just checks to see if two objects actually are the SAME object... in other words, it looks to see if they are actually both references to the same place in memory. But that’s NOT what we want to use for comparison of two Station objects

Because we overrode equals() and hashCode(), we can save search time and complexity in our code. Your design decisions should always make your implementation better, not more complicated or harder to understand.

Iteration 1

What Java’s default equals() implementation does...

What our equals() implementation does...

Q:
Q: What does any of this have to do with OOA&D?
A:
A: This is the very core of what makes OOA&D useful: because we understand our system, we realize that two stations should be considered identical if they have the same name. And, our design is improved by being able to compare stations based on their name, rather than their location in memory.
So the time we spent on requirements and getting a good grasp of our system made our design better, which in turn made implementing that design a lot simpler. That’s the power of OOA&D: you can turn knowledge of your system into a flexible design, and even end up with cleaner code—all because you spent time up front listening to the customer and gathering requirements, rather than diving right into an IDE and typing in source code.

Frank: That’s true. So we could change our Subway class to look more like this:

Jill: But then you’re exposing the internals of your application!

Joe: Whoa... not sure what that means, but it sure doesn’t sound like something I want to do. What are you talking about?

Jill: Well, look at our code right now. You don’t have to work with a Station or Connection at all to load up the subway. You can just call methods on our new Subway class.

Frank: How is that any different from what we’re suggesting?

Jill: If we went with your ideas, people that use the Subway class would have to also work with Station and Connection. In our version right now, they just work with Strings: the name of a station, and the name of a line.

Joe: And that’s bad because...

Frank: Wait, I think I get it. Their code is getting tied in to how we implement the Station and Connection classes, since they’re having to work with those classes directly.

Jill: Exactly! But with our version, we could change up Connection or Station, and we’d only have to change our Subway class. Their code would stay the same, since they’re abstracted away from our implementations of Connection and Station.

Iteration 1

Protecting your classes (and your client’s classes, too)

Frank, Joe, and Jill are really talking about just one more form of abstraction. Let’s take a closer look:

You should only expose clients of your code to the classes that they NEED to interact with.
Classes that the clients don’t interact with can be changed with minimal client code being affected.
Note
In this application, we could change how Station and Connection work, and it wouldn’t affect code that only uses our Subway object; they’re protected from changes to our implementation

The SubwayLoader class

We’re almost done with our first iteration, and our first use case. All that’s left is to code the class that loads a subway based on the test file we got from Objectville Travel, Inc.

Iteration 1

You’re almost done with the first use case, and our first iteration! All that’s left is to test out our solution, and make sure it actually works.

The problem:

You need to test loading the ObjectvilleSubway.txt file, and make sure that SubwayLoader correctly loads in all stations and connections in the file.

Your task:

Add a method to Subway to check if a particular connection exists, given the two station names and the line name for that connection.
Write a test class, called LoadTester, with a main() method that loads the Objectville Subway system from the text file we got from Objectville Travel, Inc.
Write code in LoadTester that checks a few of the stations and connections from the text file against the Subway object returned from SubwayLoader’s loadFromFile() method. You should check to make sure that at least three stations and three connections on three different lines were all entered correctly.
Run your test program, and verify that we’re really done with Iteration 1.

Q:
Q: Wouldn’t it be easier to write the hasConnection() method if we used a Line object, like we talked about a few pages ago?
A:
A: It would. If we had a Line object, we could look up the line using the name passed into hasConnection(), and just iterate over the Connection objects for that line. So in most cases, hasConnection() would involve less iteration, and return a We still decided not to use a Line object, though, because we’ve only added hasConnection() to help us test our classes. So adding a Line object just to make a test method return faster doesn’t seem like a good idea. If we find that we need the hasConnection() method in other parts of our app, though, this result faster, if we had a Line object.

Iteration 1

Write a test class, called LoadTester, with a main() method that loads the Objectville Subway system from the text file we got from Objectville Travel, Inc.
Write code in LoadTester that checks a few of the stations and connections from the text file against the Subway object returned from SubwayLoader’s loadFromFile() method. You should check to make sure that at least three stations and three connections on three different lines were all entered correctly.

It’s time to iterate again

Our test proves that we really have finished up our first iteration. The “Load network of subway lines” use case is complete, and that means it’s time to iterate again. Now, we can take on our next use case—“Get directions”—and return to the Requirements phase and work through this use case.

But before we start Iteration 2...

It’s been a LONG iteration, and you’ve done some great work. STOP, take a BREAK, and eat a bite or drink some water. Give your brain a chance to REST.
Then, once you’ve caught your breath, turn the page, and let’s knock out that last use case. Are you ready? Then let’s iterate again.

What’s left to do?

We’ve made a lot of progress, on both our use cases, and our feature list. Below is the feature list and use case diagram we developed earlier in the chapter:

Back to the requirements phase...

Now that we’re ready to take on the next use case, we have to go back to the requirements phase, and work through this use case the same way we did the first one. So we’ll start by taking our use case title from our use case diagram, “Get directions,” and developing that into a full-blown use case.

Focus on code, then focus on customers. Then focus on code, then focus on customers...

When we started breaking our application up into different modules way back in The Big Break-Up, Solved, we were really talking about the structure of our application, and how we are going to break up our application. We have a Subway and Station class in the Subway module, and a SubwayLoader class in the Loader module, and so on. In other words, we’re focusing on our code.

But when we’re working on use cases, we’re focusing on how the customer uses the system—we looked at the format of an input file to load lines, and began to focus on the customer’s interaction with your system. So we’ve really been going back and forth between our code (in the Break Up the Problem step) and our customer (in the Requirements step):

When you’re developing software, there’s going to be a lot of this back-and-forth. You have to make sure your software does what it’s supposed to, but it’s your code that makes the software actually do something.

It’s your job to balance making sure the customer gets the functionality they want with making sure your code stays flexible and well-designed.

Note

Do some of these exercises look familiar? You use the same techniques in each iteration of your development cycle.

It’s time to take on more domain analysis and design for your system. Take the use case below, figure out the candidate classes and candidate operations, and then update the class diagram on the right with any changes you think you need to make.

Get directions Use Case

The travel agent gives the system a starting station and a station to travel to.
The system validates that the starting and ending stations both exist on the subway.
The system calculates a route from the starting station to the ending station.
The system prints out the route it calculated.

Nouns (candidate classes):

_________________	_________________	_________________
_________________	_________________	_________________

Verbs (candidate operations):

_________________	_________________	_________________
_________________	_________________	_________________

Iteration makes problems easier

The class diagram on the last page really isn’t that much different from our class diagram from the first iteration (flip back to Let’s see if our use case works to take a look at that earlier version). That’s because we did a lot of work that applies to all our iterations during our first iteration.

Once you’ve completed your first iteration, your successive iterations are often a lot easier, because so much of what you’ve already done makes those later iterations easier.

Implementation: Subway.java

Figuring out a route between two stations turns out to be a particularly tricky problem, and gets into some of that graph stuff we talked about briefly back in There are no Dumb Questions. To help you out, we’ve included some Ready-bake Code that you can use to get a route between two stations.

Ready-bake Code

Sometimes the best way to get the job done is find someone else who has already done the job for you.

It might seem weird that at this stage, we’re giving you the code for getting a route between two stations. But that’s part of what makes a good developer: a willingness to look around for existing solutions to hard problems.

In fact, we had some help from a college student on implementing a version of Dijkstra’s algorithm that would work with the subway (seriously!). Sure, you probably can come up with your own totally original solution to every problem, but why would you want to if someone has already done the work for you?

Note

Thanks, Felix Geller, your code really saved the day.

Sometimes the best code for a particular problem has already been written. Don’t get hung up on writing code yourself if someone already has a working solution.

What does a route look like?

The getDirections() method we just added to Subway takes in two Strings: the name of the starting station, and the name of the station that a tourist is trying to get to:

getDirections() then returns a List, which is filled with Connection objects. Each Connection is one part of the path between the two stations:

So the entire route returned from getDirections() looks like a series of Connection objects:

You’re almost done! With a working getDirections() method in Subway, the last feature to implement is printing those directions out. Your job is to write a class called SubwayPrinter that takes the data structure returned from getDirections(), which is a list of Connection objects, and prints out the directions. The directions should be printed to an OutputStream, supplied to the constructor of the SubwayPrinter class when an instance of the printer class is created.

Here’s the class diagram for SubwayPrinter that you should follow:

SubwayPrinter
out:PrintStream
printDirections(Connection [*])

Your output should look similar to this:

One last test class...

All that we need to do now is put everything together. Below is the SubwayTester class we wrote to load the Objectville Subway system, take in two stations from the command line, and print out directions between those two stations using our new getDirections() method and printer class.

Check out Objectville for yourself!

It’s time to sit back and enjoy the fruits of your labor. Compile all your classes for the Objectville Subway application, and try out SubwayTester with a few different starting and stopping stations. Here’s one of our favorites:

Way back in OOA&D Magnets, we asked you to think about where lots of different things you’ve been learning about fit on the OOA&D lifecycle below. Now that you’ve written another piece of great software, you’re ready to take this exercise on, and see how we answered it, too. Go ahead and work this exercise again; did you change where you put any of the magnets after working through this chapter?

Oh, and don’t forget, you can put more than one magnet on each phase, and there are some magnets you may want to use more than once.

This time, answers are on the next page!

Q:
Q: It seems like I could put almost every magnet on each phase... but that can’t be right, can it?
A:
A: That’s exactly right. Although there are definitely some basic phases in a good development cycle, you can use most of the things you’ve learned about OOA&D, OO principles, design, analysis, requirements, and everything else at almost every stage of development.
The most effective and successful way to write great software is to have as many tools as you can, and to be able to choose any one (or more) to use at each stage of your development cycle. The more tools you have, the more ways you’ll have to look at and work on a problem... and that means less time being stuck or not knowing what to do next.

OOA&D is about having lots of options. There is never one right way to solve a problem, so the more options you have, the better chance you’ll find a good solution to every problem.

Iteration #3, anyone?

No, we’re not going to launch into any more design problems. But, you should realize that there is plenty more that you could do to improve the design of our RouteFinder application. We thought we’d give you just a few suggestions, in case you’re dying to take another pass through the OOA&D lifecycle.

Make loading more extensible

Right now, we’ve just got a single class that handles loading, and it only accepts a Java File as input. See if you can come up with a solution that allows you to load a subway from several types of input sources (try starting with a File and InputStream). Also make it easy to add new input sources, like a database. Remember, you want to minimize changes to existing code when you’re adding new functionality, so you may end up with an interface or abstract base class before you’re through.

Allow different output sources (and formats!)

We can only print subway directions to a file, and the directions are formatted in a particular way. See if you can design a flexible Printing module that allows you to print a route to different output sources (like a File, OutputStream, and Writer), in different formats (perhaps a verbose form that matches what we’ve done already, a compact form that only indicates where to changes lines, and an XML form for other programs to use in web services).

Note

Here’s a hint: check out the Strategy pattern in Head First Design Patterns for ideas on how you might make this work.

Yes, it’s a sad day: you’re looking at the last crossword in the book. Take a deep breath, we’ve crammed this one full of terms to make it last a little longer. Enjoy!

Across	Down
2. All of your features should map to these, at least indirectly. 3. When you override equals() in Java, you should create a related implementation of this method. 5. Your features reflect this in your application. 6. You do this once you complete one feature or use case. 10. A feature list focuses on what your software __________. 12. When you complete this phase, you’re either done or need to iterate again. 15. Break your application up into these, based on your app’s functionality. 17. Understanding how a system is used should help you make better __________ decisions. 18. The approach to development we used in this chapter (3 words). 19. Never be afraid to use a __________ to a problem that someone else came up with. 21. Your design decisions are based on how this is used as well as good OO principles. 22. Iteration makes problems _______. 23. Each module in your applications should have a single ____________________.	1. Make a list of these to get your development started. 4. You usually create this type of diagram based on your domain analysis. 7. This iteration is usually the toughest. 8. OOA&D is about giving you lots of these. 9. You sometimes have to add a step to do this with your problem before writing use cases. 10. The kind of analysis that involves speaking to the customer in language that they understand. 11.This proves that your implementation is working. 13. The nouns in your use case are these types of classes. 14. You have to balance what the customer wants with your software’s _____________. 16. This is the stage where you apply good OO principles. 20. Use case diagrams focus on how your software will be ____________.

Across

Down

2. All of your features should map to these, at least indirectly.

3. When you override equals() in Java, you should create a related implementation of this method.

5. Your features reflect this in your application.

6. You do this once you complete one feature or use case.

10. A feature list focuses on what your software __________.

12. When you complete this phase, you’re either done or need to iterate again.

15. Break your application up into these, based on your app’s functionality.

17. Understanding how a system is used should help you make better __________ decisions.

18. The approach to development we used in this chapter (3 words).

19. Never be afraid to use a __________ to a problem that someone else came up with.

21. Your design decisions are based on how this is used as well as good OO principles.

22. Iteration makes problems _______.

23. Each module in your applications should have a single ____________________.

1. Make a list of these to get your development started.

4. You usually create this type of diagram based on your domain analysis.

7. This iteration is usually the toughest.

8. OOA&D is about giving you lots of these.

9. You sometimes have to add a step to do this with your problem before writing use cases.

10. The kind of analysis that involves speaking to the customer in language that they understand.

11.This proves that your implementation is working.

13. The nouns in your use case are these types of classes.

14. You have to balance what the customer wants with your software’s _____________.

16. This is the stage where you apply good OO principles.

20. Use case diagrams focus on how your software will be ____________.

The journey’s not over...

Now take OOA&D for a spin on your own projects!

We’ve loved having you here in Objectville, and we’re sad to see you go. But there’s nothing like taking what you’ve learned and putting it to use on your own development projects. So don’t stop enjoying OOA&D just yet... you’ve still got a few more gems in the back of the book, an index to read through, and then it’s time to take all these new ideas and put them into practice. We’re dying to hear how things go, so drop us a line at the Head First Labs web site, http://www.headfirstlabs.com, and let us know how OOA&D is paying off for YOU.

Previous Chapter

9. Iterating and Testing: The Software is Still for the Customer

Next Chapter

A. Leftovers: The Top Ten Topics (we didn’t cover)

	Single Responsibility Principle		Delegation
	Don’t Repeat Yourself		Polymorphism
	Encapsulation		Liskov Substitution Principle

Table of Contents for Head First Object-Oriented Analysis and Design

Chapter 10. The OOA&D Lifecycle: Putting It All Together

Developing software, OOA&D style

The problem

Objectville RouteFinder Feature List

Now you should really know what you’re supposed to do

Use cases reflect usage, features reflect functionality

Note

Now start to iterate

Note

Load network of subway lines Use Case

A closer look at representing a subway

Note

What is a station?

And a connection between two stations?

Then a line is just a series of connections...

Let’s take a look at that subway file

Let’s see if our use case works

Load network of subway lines Use Case

Load network of subway lines Use Case

To use a Line class or not to use a Line class... that is the question

Code the Station class

Note

Code the Subway class

Points of interest on the Objectville Subway (class)

Note

What Java’s default equals() implementation does...

What our equals() implementation does...

Protecting your classes (and your client’s classes, too)

Note

The SubwayLoader class

Brain Power

It’s time to iterate again

But before we start Iteration 2...

What’s left to do?

Back to the requirements phase...

Focus on code, then focus on customers. Then focus on code, then focus on customers...

Note

Get directions Use Case

Note

Iteration makes problems easier

Implementation: Subway.java

Note

What does a route look like?

One last test class...

Check out Objectville for yourself!

Iteration #3, anyone?

Make loading more extensible

Allow different output sources (and formats!)

Note

The journey’s not over...

Now take OOA&D for a spin on your own projects!

Highlight

Highlight

Table of Contents for
Head First Object-Oriented Analysis and Design