In the last chapter, we came up with some user stories to implement. Now we’ll look at what classes need to be modified or created to support the new features. We’ll do that by expanding the user stories into use-case descriptions.
OK, let's take a look at where we are:
We have a new set of features to put in (thanks to our user stories).
We have an existing application to merge the new features into.
We need a sensible approach or methodology.
Now what? A great place to start is by finding the entities, or main architectural components of the application. That is, which items will be doing the heavy lifting.
How do we do this?
We'll go through a few steps:
We will generate use-case descriptions to determine our entities.
We'll determine which entities are new and which existing ones need to be modified.
Generate Use-Case Descriptions to Define Your Entities
Let’s walk through a use-case and play a game of "spot-the-noun" to define our entities. Let's start with the use case, “As a pilot, I want to capture a minor maintenance issue as soon as I have landed so that it can be fixed quickly.”
The PILOT logs into the system.
The system validates the LOGIN.
The pilot selects new MAINTENANCE ISSUE.
The system presents the maintenance selection screen.
The pilot selects minor maintenance issue.
The system presents the maintenance entry screen.
The pilot selects the PLANE with the issue.
The pilot select the SUBSYSTEM of interest.
The pilot enters DETAILS about the subsystem that is working incorrectly.
The system records the minor maintenance issue associated with the plane.
You’ll notice that I've capitalized the nouns. These nouns have the potential to be domain entities.
Determine Which Entities Are New or Need to Be Modified
OK, now we'll look at the current system to see which of these domain entities already exist.
Pilot, Login, and Plane exist. But Maintenance, Issue, Subsystem, and Details are new.
Now, let's look more closely at the use case. It refers to minor maintenance issues. The word minor implies there is a major, or maybe moderate issue level as well. So we need to take these other levels into account.
Also, it shows that airplanes have subsystems that need maintenance. We’ll have to add this idea as well. Also, it appears the maintenance record is associated with a specific plane. That is a new idea and needs to be reflected in our diagram:
If we continue the current architectural approach, we need to tie these new entities to Java Swing and SQLite as well. An updated diagram looks like this.
Wow, that's pretty messy. 😱 This is why we're going to clean it up in the coming chapters!
Try It Out For Yourself: Defining and Analyzing Entities
Now it’s your turn. First, we’ll look at the other new user story. “As an aircraft mechanic, I want to update a maintenance issue as soon as it has been addressed so that the airplane can be considered ready for flight.” Read the use case below. Spot any new nouns that need to be added to our system, then see if you can add them to our existing diagram.
The aircraft mechanic logs into the system.
The system validates the login.
The mechanic selects view all aircraft maintenance issues.
The system presents the outstanding maintenance issues screen.
The mechanic selects an outstanding maintenance issue.
The system presents the update maintenance entry screen.
The mechanic checks the fixed indicator, and verifies the date of updates.
The system updates the maintenance issue.
Answer
Here are the nouns you should have spotted: aircraft mechanic, login, maintenance issues, fixed, date of update.
Before checking out my version, see if you can map out the new entities. Here are new items added to the class diagram:
Now, look at the use case that started it all: “As a tour group leader, I want to book a flight of up to 12 people so that they can experience someplace unique.” Again, read the use case below. Spot any new nouns that need to be added to our system, then see if you can add them to our existing diagram.
The tour guide selects the book tour option.
The system prompts for the number of tourists.
The tour guide enters the number of tourists.
The system prompts for the destination.
The tour guide enters the destination.
The system determines if an airplane can manage the trip based on anticipated weight and distance.
The system replies if the trip can be made.
The system prompts for departure (leaving for) and return(coming home) dates.
The system records the trip.
The system prompts for tourist information (repeated).
The system searches for a possibly available pilot.
The system reserves the plane and pilot.
Answer
It looks like we need “tour” and “tourists.” Now we can update our system with the appropriate entities.
Since our diagram is getting messy, because of our poor architecture, I’ll just show a portion of it.
Continuing down this architectural path is leading to an application that will become even harder to test and modify.
Let's Recap!
Create a use-case description for each user story.
Look for nouns that will become entities.
Determine if the entities are new, or possible modifications of existing ones.
Update your diagram.
Now that we know what needs to be added or modified, we can examine the weaknesses in our current system. Onward!
