Planning the Second Release

Now that we have a good idea of where we want to take the mapplet in the second release, we can begin to identify specific features. These can then be broken down into tasks (estimable chunks of work).

Features can be high or low level. They’re also an orthogonal concept to a use case: there may be a direct correlation between a feature and a use case, but it’s more likely to be by coincidence than by design.

We can identify features before we spend time to identify use cases. However, to create a project plan with realistic cost estimates, we need to identify the use cases that will be defined in order to implement the features. And before we begin the process of discovering new use cases, we need an up-to-date domain model.

Luckily, it doesn’t take a huge amount of time to do this (perhaps a morning, or a day at the most). But it’s definitely worth spending the time up front creating (or updating, as this is the second release) the domain model first, to reflect our new requirements. But before we do even that, we need to define a set of high-level requirements.

High-Level Requirements for Release 2

Before we update the domain model and use cases, we need a list of requirements for release 2. We’ve done some interaction design prior to this, to help identify some of the new requirements. Other requirements were identified via e-mails flying back and forth between ESRI and the customer, and through face-to-face review sessions of release 1 with the customer.

The requirements are as follows:

• Use a different base map that shows major attractions and landmarks on the map (if this data is available)—for example, theme parks (e.g., Disneyland, Sea World, etc.), stadiums (e.g., Dodger Stadium), airports (e.g., O’Hare Airport), and so forth.

• Include a U.S. map with rollovers that allow the user to drill down to map destination pages. (See the next section, “The ‘Uber’ Use Case,” for more information.)

• Implement driving directions (this was discussed as a possibility, but left as a potential enhancement to be implemented after this book is published).

• Highlight specially discounted (Hot Rate) hotels.

• Resolve Netscape compatibility issues.

The “Uber” Use Case

The following use case was dreamed up by the customer while taking a stroll through a cool, tree-shaded park on a sunny California day—just the sort of situation in which inspiration can strike! This use case turned into the second requirement (see the previous section). Also, during use case modeling and subsequent e-mail discussions with the developers, this use case was refined from this initial “Eureka!” version.

Basic Course:

The system displays a zoomable, clickable map of the United States, accompanied by the following radio buttons: Zoom In, Zoom Out, Pan, and Show Hotels. The map contains a shapefile layer shown as labeled red dots and consisting of the destinations defined in www.vresorts.com/mapplet/340destinations+.html. When the user moves the mouse over one of the destination dots, the system displays a rollover map tip with the name of the destination. If the user clicks the dot, the system displays a persistent “thumbnail” map tip, which is a reduced-scale map screenshot approximately 150 pixels wide that is shown underneath the name of the destination.

Underneath the thumbnail image are three links: Show Destination Page, Show featured hotel, and Browse hotel map. The links for Browse hotel map are the URLs linked to the Show Map links in www.vresorts.com/mapplet/340destinations+.html. The Show Destination Page links are simply links to static HTML pages. The Show featured hotel links are as shown on the 340destinations+ page.

Alternate Course:

If the user clicks in an “empty” (nondestination) area of the map with Show Hotels selected, the system performs a statewide hotel search and shows the search results in a new window.

The 340destinations+ page (defined originally as a test suite for the mapplet) is shown in Figure 8-1. As you can see, this is a basic list of U.S. states divided into cities, each with links to maps, hotel lists, and a featured hotel for each city. For release 2, the plan is to transcribe this basic text page to a much groovier, interactive mapplet page in which the user can zoom, pan, search, and so forth. (In fact, you can see the final result in Figure 8-8.)

Figure 8-1: 340Destinations+ page

Updated Domain Model

The updated domain model is shown in Figure 8-2.

Figure 8-2: Updated domain model for release 2

There are a few changes between this version and the version for release 1 (see Figure 6-4):

• Hotel Filter has been added in addition to Display Filter.

• Amenity List and Amenity Item have been added.

• The old Hotel Collection/Hotel objects and relationship have been replaced with the Composite pattern that was discussed in Chapter 7.

• An AOI class was added. (This was a late but important addition—the domain model was incomplete without this central class!)

• The Boundary object Show Map was added. This object represents the ShowMap.aspx web page. It’s the cornerstone of the mapplet, so it really needs to be on the domain model. It’s shown in the final class diagram (jumping ahead to Figures 8-7) as having a dependency on Hotel, so we replicate that in the domain model. We wouldn’t normally go into great detail on relationships among objects in the domain model, but this particular one is such an important relationship that it’s worth emphasizing.

Updated Use Case Diagram

Figure 8-3 shows the use cases for release 2. We can compare this with the use case diagram for release 1 back in Figure 5-5. As you can see, there are two new use cases here: “Filter Hotels” and “Browse by US Map.”

Figure 8-3: Use cases for release 2

Because there are only the two new use cases, it’s pretty easy to keep track of what’s new for release 2. However, in a larger project, you’d almost certainly want to visually separate the new use cases in some way. A stereotype such as <<Release 2>> would be useful.

Modeling Question 

What if the project has hundreds of new use cases? In this case, you could separate the use cases into different diagrams. But it would also be worth questioning why there are so many use cases in a single release. Remember, this is meant to be an agile project with short timescales for each release, so if you end up with hundreds of use cases, you need to do some more work prioritizing them and dividing them into separate, smaller releases.

Here are the two new use cases in detail. (The second one, “Browse by US Map,” was rewritten from the customer’s original use case shown earlier in this chapter during use case modeling.)

Use Case: “Filter Hotels” 

Filter By Amenity:

The system displays the List of Amenities in the Amenity List. The user selects one or more amenities from the list and then selects Update Map. The MapViewer creates a HotelFilter based on the selected items in the Amenity List. The MapViewer queries the HotelServer for all hotels in the AOI and then filters the results with the HotelFilter. The map is refreshed and a label is placed adjacent to the map indicating the current selection criterion.

Filter by Hotel Chain:

The system populates a Hotel Chain pick list from the Hotel Chain table. The user selects one Hotel Chain from the pick list. The MapViewer creates a HotelFilter for the selected Hotel Chain. The MapViewer queries the HotelServer for all hotels in the AOI and then filters the results with the HotelFilter. The map is refreshed and a label is placed adjacent to the map indicating the Hotel Chain selected.

Alternate Scenario 1:

If there are no Hotels that meet the filter criterion, the following message is displayed: “No hotels meet selection criterion. Please expand search.”

Use Case: “Browse by US Map” 

Basic Scenario:

The Grouped Destination shapefile is shown as a set of points on an overview map of the United States. The user positions the mouse cursor over a Grouped Destination point. The mouse icon changes to a selection hand, and the icon changes to a selected icon. The system shows a map tip displaying the list of cities grouped in the region (e.g., “Birmingham, Huntsville, Montgomery, Mobile”). The user clicks the Regional Destination icon, and the associated URL opens in a new browser window.

Alternate Scenario 1:

If the user zooms in, the system will zoom in to a suitable scale to show the Destinations city layer. If the user positions the mouse cursor over a city, the city name is displayed in the map tip. If the user clicks the city, the system will zoom in to the city and display the hotels in that city.

Alternate Scenario 2:

If the user chooses to zoom in when the Destination city layer is shown, the map will display the hotels in the zoomed-in area.

Alternate Scenario 3:

If the user attempts to pan at the U.S. level, the system will not allow this action.

Alternate Scenario 4:

If the user attempts to zoom out at the U.S. level, the system will not allow this action.

Release 2 Plan

Let’s review the release plan as it stands now. If you look back at the plan shown in Table 5-1 (which shows the use cases to be implemented for the first four releases), you can see that (now that release 1 is out of the way) this plan doesn’t bear much resemblance to reality at all. This is understandable—release 1 was primarily an exercise in prototyping to gain a greater understanding of what’s possible in the time frames involved and what (if any) dependencies exist.

So let’s revisit the plan, and then correct it for release 1 so we can see what really happened (see Table 8-1).

Table 8-1: Corrected Release Plan for Release 1

Release	Use Case	Comments
1	Create AOI for Address
	Generate Hotel Map for AOI
	View Map
	Pan/Zoom Map	Basic
	View Hotel Information	Basic
	Create Shapefile
	Display Rollover Information	Basic
	Pan/Zoom Map	Progressive disclosure
	View Multiple Hotel Info	Multiple hotels found at click coordinates

So in fact, all the items that had originally been penciled in for release 2 were also implemented in release 1 and within the timescale that was originally estimated for release 1. Not bad, although we would certainly hope that the release plans will become more accurate over successive releases. It’s unusual for a release to include significantly more than was originally planned! (Maybe there’s something to this low-ceremony stuff after all.)

Release 2, then, simply consists of the two new use cases in Figure 8-3, plus the nonfunctional requirements listed earlier in this chapter. Let’s put these together in a plan for release 2 (see Table 8-2).

Table 8-2: Release Plan for Release 2

Release	Use Case/Nonfunctional Requirement	Comments
2	Filter Hotels
	Browse by US Map
	Netscape compatibility
	Automatically scale AOI