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

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
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. For details, visit the AgileDraw.org Web site.

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.