Using Agile Processes and Modeling To Build Enterprise Applications

by Anil Hemrajani
05/09/2006

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.

Scope Functionality
Include Time Expression will provide the capability to enter, approve, and pay for hours worked by employees.
Defer Time Expression will calculate deductions from paychecks, such as federal/state taxes and medical expenses.
Defer 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. 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. Enter Hours— a sample UI prototype

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. 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. 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. 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. UML class diagram

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."

Tying it all together

If you have come across the myth that XP programmers simply code without designing, you have surely noticed by reading this article that it couldn't be further from the truth. Furthermore, XPers consider refactoring a daily design since it constantly improves the code. To illustrate my point further, Figure 11 shows the various models we created at the release and iteration levels; these can also be viewed from another perspective, that is, as conceptual and physical models.

Figure 11. How the models fit together

The next steps most likely will include creating the actual database and, of course, writing code!

In my opinion, the database and code base are the lasting artifacts, and models can easily be reverse-engineered from both of these. All the other models we created up to this point could potentially be considered "throw aways" once the database and code have been implemented. The reason I mention this is because most projects I've been on fail to maintain the design and requirements documents anyway, so what's the point of keeping them around? Of course, some day OMG's vision of going directly from models to executable may come true (with or without an intermediary code-generation step); if it does, that would be absolutely wonderful because then the models would effectively replace the code we write these days and there would be no need to keep models and code synchronized.

Agile Versus Traditional Methods

On BRUF/BDUF style projects, more times than not, the requirements and/or design documentation becomes the goal toward the beginning of a project. This is typically not the case with agile projects. As a result, you may have noticed that the process and modeling techniques I discussed in this article did not require lots of formal and detailed requirements or design up front.

On the requirements side, using XP we start out with some general ideas of feature requests in the form of simple user stories, enough to do some release planning. The details are handled at the iteration level using acceptances tests as our detailed requirements during the applicable iteration. On BRUF-style projects, these may have all been handled up front in the form of detailed use cases with sections on pre-conditions, post-conditions, success paths, failure paths, business rules, and so on. As a result, BRUF-style projects often end up with a book of requirements that project stakeholders seldom read cover to cover.

On the technical (design) side of agile development, we can use an informal, high-level architecture to give us a sense of the enterprise application being built, enough to move forward with the first couple of iterations. In other words, we would not spend an enormous amount of time designing the physical database or creating detailed object relationship diagrams since they evolve over the course of a release. Furthermore, agile methods incorporate refactoring techniques to continually improve the design of an application. The rationale behind this is that many aspects of architecture and design can only get flushed out and/or proven once some coding has been done. In BDUF-style projects, the architecture design is typically finalized up front, before even a single line of code is written.

Download

You can download the code behind the sample application, Time Expression, described in this article: bookcode.zip

Conclusion

I just reviewed how to use a couple agile methods such as XP and AMDD to develop enterprise applications. These techniques aren't rocket science or entirely original, in that they build on years of what has been proven to work (or not). However, they do incorporate some of the techniques that enable you to work in a nimble fashion and that help you adapt quickly and embrace change in your organization, projects, and stakeholder needs. I would recommend using these merely as guidelines because when process, models, or documentation become your goal, you are losing sight of what really matters, the customer you are building the application for.

References

Appendix: A Note About Agile Draw

You may have noticed that many of the models used in this article use a free-form technique; this is no accident. The techniques used here are part of an effort called Agile Draw, a new technique backed by many published authors (including me) and many other experienced people. This technique is virtually notation-free and highly simplifies modeling, particularly at the conceptual level. The idea behind Agile Draw is to use the simplest tools possible and keep the notation to a bare minimum (for example, there are only three core shapes: circles, boxes, and lines). The emphasis is on "what" the models convey (that is, concepts and content) and not "how" it is conveyed (such as notations and tools). In addition, Agile Draw provides guidelines to take these models one step further, if needed, by adding "pizzazz" to them through colors, shadows, callouts, and more. These snazzier models can be used for presentations, proposals, Web sites, and so on.

Anil Hemrajani is the author of Agile Java Development With Spring, Hibernate and Eclipse. He has 20 years of IT experience and has worked with Java Technology since late 1995 as a developer, entrepreneur, author, and trainer.