Using Agile Processes and Modeling To Build Enterprise Applications
Pages: 1, 2, 3

Release-level models

At the beginning of a given release, for example, a quarterly release, it is important to define the scope of the project so everyone is in agreement on what is within scope and what is not; this can easily be accomplished using a simple scope table, as shown in Table 1.




Time Expression will provide the capability to enter, approve, and pay for hours worked by employees.


Time Expression will calculate deductions from paychecks, such as federal/state taxes and medical expenses.


Time Expression will track vacation or sick leave.

Table 1. Sample Scope Table

Next, we could either start with a domain model or UI prototypes, depending on the nature and size of the application being built; for example, if the application does not have a UI, then having UI prototypes obviously makes no sense. In addition, which comes first also depends on what your organization gives priority to; for example, your organization may place more emphasis on domain models, so you may start there. However, other organizations find they can discover domain objects better and easier when working with users on UI prototypes.

A domain model helps to define major business concepts (entities) and the relationships among them, as demonstrated in Figure 3.

Figure 3
Figure 3. Sample domain model

User interface prototypes and storyboards are initial screen mockups to get a feel for how the customer visualizes the application; a sample prototype for a Enter Hours screen, is shown in Figure 4. A storyboard shows the flow of the screens, as demonstrated in Figure 5.

Figure 4
Figure 4. Enter Hours— a sample UI prototype

Figure 5
Figure 5. Sample storyboard (also known as UI Flow Diagram)

Another model that we may wish to define at the release level is a high-level architecture diagram, similar to what's shown in Figure 6. This should have just enough details to get the project going with the design details to be determined at the time of iteration they are needed in. A high-level architecture diagram can help with discussions about security, scalability, transaction management, exception handling, and other important application-wide issues.

Figure 6
Figure 6. Sample high-level architecture

One other thing to define at the release level is a glossary, a list of common business and technical terms that may be used during the project. This is essential to a project for shared understanding of terminology. For example, in our sample application, these terms may include period ending date, pending status, and so on. In the XP world, this is also the point where an initial release plan (essentially a project plan) would be defined.

Iteration-level models

By now we have enough information about our application to move forward with our first iteration. Sometimes, projects may actually develop a proof-of-concept, for example, a demonstration of round-trip connectivity between the UI and the database for an application. (In the XP world, this would be considered a spike solution, a simple program to explore potential solutions.) These types of exercises (for example, proof-of-concept) can be viewed as being part of iteration 0 (zero), since no customer features are delivered during this iteration.

An obvious consideration of object-oriented development is to design and code objects. In the XP world, objects can be explored with one or more members of the team using CRC cards. This exercise of exploring objects can also be used to define class and method naming conventions, something known as a system metaphor in XP. Before we begin exploring objects, let's see what we know about our sample application so far. For example, we already know our domain objects (from our domain model), we know that our architecture will utilize a Model-View-Controller (MVC) design pattern, we know about some UI screens (from our prototypes), and we presumably have some user stories (perhaps, with short tags/names for each of them). Given some of these facts, we can begin naming our objects. So, if we begin developing our Enter Hours screen (Figure 4), we may have a class named EnterHoursController, which in turn may use a service (or model) object named TimesheetManager. The TimesheetManager class in turn would require a Timesheet domain object (as demonstrated in Figure 7).

Figure 7
Figure 7. Sample CRC card

Once we have our basic objects explored using CRC cards, we could use something I like to call an Application Flow Map that shows an end-to-end flow of the user features. Figure 8 shows a sample application flow map; notice how we can see all the components of our MVC architecture. The other nice thing about this type of model is that it can be extended easily later in the project by adding columns for database tables affected by various parts of the application. For example, we could add four CRUD (create, read, update, delete) columns to show which database tables are affected and how.

Figure 8
Figure 8. Application flow map

CRC cards and the home-grown application flow map may work well for some projects; for other projects, UML class diagrams may be the norm and/or you may feel more comfortable with those techniques as many developers do. In this case, class and possibly package diagrams can be used as a substitute or to complement CRC cards and/or an application flow map. Figures 9 and 10 show examples of class and package diagrams for our sample application.

Figure 9
Figure 9. UML class diagram

Figure 10
Figure 10. UML package diagram

One other important thing to note about XP is the acceptance test. While user stories serve as high-level requirements at the release level, acceptance tests combined with ad hoc question-and-answer sessions with the user serve as detailed requirements at the iteration levels; acceptance tests are also used to write unit tests. For example, an acceptance test for our sample application may include something along the lines of "the maximum hours entered for any given day may not exceed 24."

Pages: 1, 2, 3

Next Page »