Channels ▼

Extreme Modeling

, November 01, 2000

November 2000: Extreme Modeling

Did you decide to read this column simply because the headline included the word "Extreme?" If so, then you have likely fallen victim to the Extreme Hype (EH) surrounding eXtreme Programming (XP)—an important and growing movement within the software engineering community, despite the hoopla. For many software development teams, XP makes eXtreme Sense (XS) because it encompasses a collection of proven principles and practices of software engineering that few projects can do without. However, when taken at eXtreme Face Value (XFV), XP appears to be little more than a thin veneer atop hacking. Nothing could be further from the truth. Over the past year, I have noticed an eXtreme misUnderstanding (XU) in the software development community: Many believe that XP practitioners do little or no modeling. My experience has shown that this is simply not the case. Instead, XP practitioners take an adaptive approach to all aspects of development, including modeling. This month I examine XP, instead of taking it at XFV, to resolve any XUs regarding modeling by discussing an extreme modeling process that makes XS. Also, I’ll cut out the eXtreme Abbreviations (XA) because I hope I’ve made my eXtreme pOint (XO) about the EH surrounding XP.

XP is simply a collection of interrelated principles and practices, some of which focus on basic activities such as configuration management, but many of which focus on the communication and cultural aspects between team members and between the team and the organization in which it operates. XP’s pair programming, collective ownership and position on coaching help to promote teamwork and communication between team members, and its focus on understanding the requirements and inclusion of a user representative as an active member of the team promotes communication with other parts of the organization.

Not Just a Hack

Working closely with users as equals? Working as a team, not as a lone genius? XP sounds like it’s more than hacking to me. Instead, XP is a well-thought-out software process worthy of consideration.

Now let’s look at XP’s approach to modeling. To quote Kent Beck from Extreme Programming Explained (Addison-Wesley, 2000): "We will continually refine the design of a system, starting from a very simple beginning. We will remove any flexibility that doesn’t prove useful." Contrary to the claims of some of XP’s detractors, you do in fact invest time modeling when taking an XP approach. XP recognizes that it is significantly more productive for a developer to draw some bubbles and lines to think through an idea, or to compare several different approaches to solving a problem, than it is to simply start hacking out code. Where XP differs from many software processes, or at least how many software processes such as the Rational Unified Process (RUP), the OPEN Process and my own Object-Oriented Software Process (OOSP) are typically implemented, is that it doesn’t require the development and maintenance of a monolithic model of what you are building. Instead, XP’s philosophy is to invest just enough effort into understanding what it is you intend to build and then to build it to see whether your design is right. In short, XP suggests that you take an iterative approach—as does RUP, OPEN and OOSP—it’s just that XP is a little more blatant about it. XP practitioners believe that you shouldn’t invest time generalizing your design because it isn’t clear yet whether the extra code that you will need to write and test will actually be necessary. Instead, you should develop for today’s problem and trust that you can solve tomorrow’s problem tomorrow by refactoring your code as needed. However, XP practitioners aren’t stupid: If the impact of a change is likely to be severe, they will invest the resources to reflect a likely change in their design from the beginning—an excellent compromise.

XP and Business Models

What types of models would you need to create a business application? I have been trying to answer this question for years, at least from the point of object-oriented software, and my answer, presented in Figure 1, depicts the latest incarnation of the solution to the detailed modeling process pattern. Adapted from my latest book, The Object Primer, 2nd Edition (Cambridge University Press, 2000), Figure 1 illustrates what I consider to be the primary artifacts that software developers may create while building object-oriented business software. (For simplicity’s sake, I have left out project management artifacts such as estimates and testing artifacts such as test cases.) The boxes in the diagram represent potential development artifacts such as essential use case models and activity diagrams. The lines depict the major relationships between artifacts; for example, information in your analysis class model drives the development of information in your design class model. These relationships are important because they reveal how you are likely to iterate between development of the artifacts. For instance, you may be working on your use case model and find that it makes sense to develop a sequence diagram, which in turn leads you to change your class model. The highlighted boxes indicate artifacts that are described by the industry-standard Unified Modeling Language (UML), developed and maintained by the Object Management Group (

Figure 1. Detailed Object Modeling (2000)
The primary artifacts that software developers may create while building object-oriented business software.


The adaptation in Figure 1 is the addition of the "External Interface Specification," which encompasses the design of how to integrate your system with another one, perhaps through an application programming interface (API), a data file or simply a shared database. Although I believed I had a fairly comprehensive answer, I quickly discovered on a recent project that I was missing this artifact and that it was critical to the project’s success. The lesson to be learned, one taken from James Highsmith’s latest book Adaptive Software Development (Dorset House, 1999), is that, although you can begin a project with a reasonably good approach, you need to be prepared to adapt to the situation at hand.

XP in Practice

So how can you use the information contained in Figure 1 on an XP project? First, understand that although there are many modeling artifacts available, you probably won’t need to create them all. Just like you wouldn’t order every item on the menu when you eat at a restaurant, you don’t need to gorge yourself on every model available. Instead, you should apply only the modeling techniques that enable you to better understand the software that you are building. For example, essential user interface prototypes enable you to better understand the requirements for a user interface; however, if your user interface needs are well understood, then this technique likely offers little value for your team, and you shouldn’t apply it. Similarly, activity diagrams are useful for discerning the flow of complex business logic, but they aren’t very valuable if the workflow is straightforward.

Second, just because you need an artifact, doesn’t mean that you have to create a formal version of it. I often draw an activity model or a sequence diagram on a white board as part of understanding whatever it is that I’m modeling, but I won’t formalize it using a CASE tool. Instead, if I want permanent copies for later reference, I may take a snapshot of these diagrams with a digital camera or simply create a hand drawing. Don’t get me wrong, I’ll use CASE tools when they add value to my development efforts. For example, TogetherSoft’s Together/J ( can be valuable on Enterprise JavaBean (EJB) projects because of its round-trip integration with Java and I-Logix’s Rhapsody ( for development of embedded software due to its focus on real-time modeling. In short, sometimes a whiteboard or a paper napkin is a sufficient modeling environment, whereas only a complex CASE tool addresses the needs of a project team other times.

Third, having a variety of artifacts at my disposal actually makes modeling easier. The greater the selection of models available, the greater the chance that you will find one that meets your specific needs. If you need to cut a piece of wood in half and your toolkit only contains a hammer and screwdriver, you’ll have a significantly harder time than if your toolkit also included saws, wrenches and pliers. I only need a saw for that specific job, but it doesn’t hurt to have a wide range of tools at my disposal. Granted, you need to be skilled at using these tools to be effective: If you try to cut the wood using a wrench, then having a saw in your toolkit wasn’t useful. When I develop business software I often need to model the user interface, which is why Figure 1 includes several artifacts that focus on this issue. I often need to work with some sort of data storage mechanism, such as a relational database (RDB) or objectbase, to persist my objects, which is why I included a persistence model. I am far more effective as a developer when I have these artifacts available to me because I can use the right tool for the job. Your project team needs people who are trained and experienced at applying these techniques; not everyone needs to be expert at everything, but you should strive to have a team with a wide range of skills. In fact, if you are unable to put together a team with the requisite skills to complete the job, or at least a team that has the ability to learn any missing skills as work progresses, then you shouldn’t attempt the project at all.

Real-World Implications

What are some of the other interesting implications of Figure 1? The fact that not all of the boxes are highlighted implies that UML is not sufficient for the real-world needs of application developers, something that the OMG should attempt to address as they evolve UML. The figure also indicates that software development is both serial and iterative. It’s serial because as you traverse the diagram from left to right, the focus of the artifacts starts at requirements, shifts to analysis, then design and then finally to implementation. (I have always argued that source code is an incredibly detailed model of your software.) Development is also iterative because you can quickly move back and forth between artifacts. I am often in a situation where a user describes a requirement to me, and I internally analyze what they are telling me, formulate a design that fulfills the requirement and even begin thinking about how I will code it—all within a matter of seconds. That’s about as iterative as you are going to get. My belief is that although the concepts of requirements, analysis and design are all important, what you are really doing is modeling and constantly changing your focus as you do so. At times, it’s important to identify what the users want or need (requirements), identify what you can deliver (analysis) and describe how you intend to build the software (design). The reality is that these concepts are intertwined. Modeling is serial in the large and iterative in the small. Finally, it’s clear that software development is hard. You need software professionals that recognize this fact—ideally, professionals who are skilled at working with several of the artifacts indicated in the diagram.

Modeling is an important part of software development, one that is a fundamental part of XP, regardless of what the name may imply. Models don’t kill projects, people kill projects. The best software professionals have a wide range of techniques in their development toolkit, and they know when and how to apply them effectively.


Suggested XP Resources
Books and URLs to pump up your design and process skills.

Extreme Programming (XP)

The XP Web site,, is a good place to learn about XP, but the best source of information is Kent Beck’s book, Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999), a 1999 Software Development Productivity award winner.

Essential Modeling

The book Software For Use: A Practical Guide to the Models and Methods of Usage-Centered Design (ACM Press, 1999), 1999 Jolt winner, written by Larry Constantine and Lucy Lockwood, is the best source of detailed information on this topic. My own book, The Object Primer, 2nd Edition: The Application Developer’s Guide To Object Orientation (Cambridge University Press, 2000) also presents a good overview of essential modeling techniques and object modeling techniques in general.


Martin Fowler’s Refactoring: Improving the Design of Existing Code (Addison-Wesley, 1999) presents a large collection of strategies for refactoring object-oriented source code.

The Unified Modeling Language (UML)

The Unified Modeling Language Reference Manual (Addison-Wesley, 1998), written by the Three Amigos (James Rumbaugh, Grady Booch and Ivar Jacobson), is an excellent resource for any serious developer because it explains the various parts of UML in great detail. However, to learn how to apply the techniques of UML, I suggest my book, The Object Primer, 2nd Edition, UML Distilled: Applying the Standard Object Modeling Language (Addison-Wesley 1997) by Martin Fowler and Fundamentals of Object-Oriented Design in UML (Dorset House, 2000) by Meilir Page-Jones.

Software Process

Begin with James Highsmith’s Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (Dorset House, 2000), which presents an interesting and new look at how to be successful at software development. Highsmith examines the cultural aspects of software development and suggests practices and principles that reflect the realities of the complex and changing environment in which modern software development exists. Small teams should stick with Extreme Programming Explained, whereas larger teams likely need something along the lines of Philippe Kruchten’s The Rational Unified Process: An Introduction, 2nd Edition (Addison-Wesley, 2000). However, to extend the Rational Unified Process (RUP) for large-scale, real-world development, I would then follow up with CMP Books’ Unified Process Series—The Unified Process Inception Phase, The Unified Process Elaboration Phase and The Unified Process Construction Phase—all published in 2000 and coedited by myself and Larry Constantine. You will also find The Process Patterns Resource Page,, and the OPEN Consortium’s Web site,, valuable.


Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.