- Taking a Tour Through Agile Modeling
- Using Agile Modeling in a Sample Session
- Summary
- Q&A
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Using Agile Modeling in a Sample Session
So far, this hour has covered mainly concepts and practices. Now's the time to see how these might work on an XP project! We'll take a sample user story and work through a series of models until we're ready to begin development (or we run out of time). We will do the following in our sample session:
Get a user story from the customer
Create a workflow model to better understand the user story
Remodel as a flow diagram to further refine our understanding
Write new user stories that flow from our new understanding
Develop some screen mockups
Use the screen mockups and our workflow diagram to create a physical data model
Our customer runs a small library and is interested in offering library users a service whereby they can order books over the phone. The library will then mail the book or books out to the customer. Who knows how they will get them back! Phase 2 of this project will be to extend the system's functionality to online ordering over the Internet. For now we'll start with the basic system. Table 23.7 lists our customer's user story.
Table 23.7 Sample User Story for Library System
|
Title |
Ordering books over the telephone |
|
Description |
The system should allow users to search for books based on customer criteria and then allow ordering of any book. |
Our customer's user story looks like it might need to be split into three or four stories; we'll leave that question mark and see what pops out as we begin to model.
TIP
Remember, we are using modeling to further our understanding of requirements; the goal is to write software that meets our customer needs. Modeling is our means to that end.
Our user story in Table 23.7 is, by definition, pretty vague. We begin by discussing with the customer the steps involved in ordering and selecting a book. Our job is made easier by the fact that the business domain (library systems) is common and easily understood. Try to visualize; we take turns at the whiteboard, drawing, sketching, erasing, and redrawing, until we arrive at a common understanding. We can expect that at this stage we'll be mixing business or process flow with system-related information. No need to become worried about this; having a big picture of business processes will always be helpful. Figure 23.1 is the result of our discussions.
){kind=link}
Figure 23.1 The business process for our library sample.
Our diagram is a little rough around the edges, but it has highlighted some interesting workflows and issues for us. Notice the use of metaphors—house for customer, Rolodex for index, and mailbox for postal service. This looks like the kind of diagram that customer and developer alike could understand! One problem with it is that it's hard to get the correct order or sequence of events. In fact a diagram like this would likely be used as basis of to iterate from; in the end, it's thrown away. This is a great example of the AM practice of Iterate to Another Artifact. To get some sense of sequence, we'll create a simple flow diagram.
It turns out that your hotshot Visio expert has been modeling the flow while you were evolving your whiteboard sketch. Both diagrams tell different sides of the same story and this demonstrates the AM practice of Create Several Models in Parallel. Figure 23.2 is our much tidier flow diagram.
){kind=link}
Figure 23.2 Using a flow diagram to capture business process flow.
Now the team will distill the diagram down a little further, using an interface prototype model. Are you seeing new user stories appear from the woodwork as we model and discuss? Here are some that you might have noticed:
Search for book
List books
Get customer details
Get book order details
Process order
Back to the whiteboard again to get a sense of what screens we might need to build. Figure 23.3 is the team's sketch of the probable screens they'll need.
){kind=link}
Figure 23.3 Modeling the screen flow.
Without getting into detail we can see the need for the following screens:
Search screen to capture criteria
Results screen that lists books and authors
Book details screen that displays status of the book, reviews, summary, and location in the library
An order details screen where customer contact information is added and the order is accepted for processing
By the way, we added the option to go straight from the list into the order detail.
Let's take a first pass at defining the likely screen layout. Figure 23.4 illustrates our whiteboard sketch. Notice how we captured some useful information about values in the drop-down box and the length (50 characters) of the text box.
){kind=link}
Figure 23.4 Search screen mockup sketch.
From here we can go our next screen, which is the list results screen displayed in Figure 23.5.
){kind=link}
Figure 23.5 List screen mockup sketch.
We're demonstrating the AM practice of Create Simple Content here by only displaying the barest requirements. For example, we will take sketches and then build HTML mockups; our model has to be good enough to get us started on the right track and no more. We showed lines under each header (title, author, and order); the team knows these refer to hyperlinked text. If we were going to transmit the image to a satellite team or site, we'd need to produce more accurate drawings.
Figure 23.6 illustrates the book detail screen.
){kind=link}
Figure 23.6 Book detail screen mockup sketch.
Our last mockup screen is the order detail where we take down the customer's address and then accept the order for processing. We uncovered a user interface question while doing this mockup; how do we handle ZIP code, state, and city? Should they be saved as text or in some kind of lookup? We'd probably figure this out before we start on the screen because it will affect our database design. Most likely we'll make the state a lookup and leave the rest as text. Figure 23.7 illustrates the book detail screen.
){kind=link}
Figure 23.7 Order detail screen mockup sketch.
So, we now have some rather impressive screen mockups and a good feel for the overall system flow. We've been uncovering database-related issues as we worked through our models. In reality, we could argue that we can go right to our database-modeling tool, as the structure seems simple enough.
TIP
Modeling tools are not evil! Agile Modeling doesn't mean always use paper and whiteboard, and applications such as CASE or database modelers can be used when it makes sense. The trick is knowing when to use them; that is Agile Modeling!
In our case we could have assigned the task of coming up with a data model to a single developer. This developer would then report back to the group for feedback, as shown in Figure 23.8.
){kind=link}
Figure 23.8 Library system physical data model.
We're now at the point where at least some development can begin. Here are some of the things we have achieved in our session:
Clear understanding of the business problem
Decomposition of the base user story into more specific stories
Screen mockups ready for conversion into HTML
Draft physical data model completed
In the process we switched back and forth between software application tool and paper. This pattern will continue as development starts and programmers need to grasp more technical issues; they will select modeling tools and techniques that communicate best in their own situation.