The CASE (Tool) for Agility: Rational XDE

by Gary K. Evans

President, Evanetics, Inc.

One of the most exciting -- and contentious -- debates in software development today centers on "agile" process techniques. Several approaches have been put forth by various authors (see Sidebar), but a recent straw poll indicates that the practice of agility is still very much in the early-adopter stage.

In April 2002 I was invited to participate in a methodologies panel at the Software Development West Conference (SD West), in San Jose, California. At the beginning of the discussion, the panel moderator polled the 800 or so attendees regarding the software development process they were currently following. When she asked how many were using waterfall, or a modified waterfall, approach, it seemed as if every hand in the room went up. Then she asked how many were actively engaging agile techniques -- about a dozen hands were raised. When she asked how many were currently using extreme programming (XP) techniques, only six hands went up.

What interests me is not the specific process these practitioners are currently following, but rather the intense questions they raised about the benefits they might obtain from these agile processes.

The Call of Agility

Until one lives through an agile project, the benefits are very much in the eye of the beholder, and colored deeply by one's gestalt about how software should be developed. Received wisdom of the last thirty or so years says that software is manufactured, or engineered, much as automobiles and airplanes are engineered. But those of us who do software for a living have long recognized that how we really develop software doesn't fit neatly into this manufacturing box. To many of us it is self-evident that software is organically composed, like music or a short story, rather than linearly manufactured, step-by-step, like bridges and buildings.1

What is the philosophy of agility? In its simplest expression it advocates the obvious: "If you need to do something, do it; if you don't need it, don't do it." But the tension in applying this perspective comes in deciding "How do I determine if I need to do X, or Y, or Z?"

In the decades-old discourse about software process improvement, agility is a disruptive element. It has burst onto the software scene making the purposeful and calculated promise that "doing less will get you more." It sounds a bit like snake oil. Yet, the bizarre often becomes mainstream. In this case, the principles and practices of agility assault our thinking and our comfort zones infinitely more than they affect our code. Agility doesn't just change how we write code -- it changes everything about how we develop software.

Agile Flavors

Agility is not a single technique or methodology. It is an attitude and a philosophy. There are many approaches to agility. This is a brief list of the more well-known contenders (in alphabetical order), and where you can find more information on each.

Adaptive Software Development

- See Jim Highsmith's Web site: http://www.adaptivesd.com/

Agile Modeling

-See Scott Ambler's Web site: http://www.agilemodeling.com/ and book: Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. Wiley, 2002.

Crystal

- See Alistair Cockburn's Web site: http://alistair.cockburn.us

eXtreme Programming

-See Ron Jeffries' Web site: http://xprogramming.com-See Kent Beck, Extreme Programming Explained: Embrace Change. Addison- Wesley, 2000.

Feature-Driven Development

-See Peter Coad, Eric Lefebvre, Jeff De Luca, Java Modeling In Color With UML: Enterprise Components and Process.Prentice Hall PTR, 1999.

SCRUM

-See Jeff Sutherland's and Ken Schwaber's

A Contrast in Viewpoints

Our goal in commercial software development is to meet our customer's expectations. How do we obtain and understand these expectations? Through the requirements of the customer. And how do we validate that we are meeting the requirements? Ah, here's the fork in the road that unsettles us.

The traditional waterfall approach has been validation "in the large." This is carried out by "Big Requirements Up Front," usually embodied in a huge tome and justified by the twin dogmas that a) we must understand everything before we start building the system, and b) if we write it down it must, therefore, be correct. The waterfall approach implicitly assumes that software is manufactured, that it is actually possible to understand everything up front, and that it's possible to do all the design before coding, all the coding before system test, and so on.

Agile approaches perform validation "in the small." They advocate appropriating a "good enough" understanding of the problem to be solved, and building software in small steps. The agile mindset is a humble view: It says that we simply cannot understand everything about our system until we actually build the system. And to build the correct system, we must build it in small, verifiable pieces that we

Web site: http://www.controlchaos.com/continuously validate against the customer's expectations.

Simply put, with the waterfall approach we try to understand so we can then go forward to build the system. With the agile approach we begin building so we can understand. With the traditional approach we do not expect, nor schedule time, to go backward and make changes to what we have already done (because we should have figured it all out before we started). But with the agile approach, we go forward so we can justify going backward to fill in what we inevitably missed in a previous step. This backtracking is planned. As the XP community says: Agility embraces change.

This is the essential difference between planned iteration and the unplanned rework so common in waterfall-based projects. With the traditional approach, adherence to the prescribed software process is considered the major determinant of success. With the agile approach, adaptation toward achieving the end-goal -- working software -- is the major factor in success.

Table 1 summarizes some contrasts between these remarkably different approaches.

Table 1: Waterfall vs. Agile Approach

Waterfall Agile

Guiding metaphor Manufacturing/Engineering Organic/Emergent

Focus Documentation, Schedule People, Working Code

Dynamic structure Cause and Effect,Preventive Approach

Chaordic (Ordered Chaos),Adaptive Approach

An Agile Perspective on RUP

If the philosophy of agility is so non-traditional, does this imply that we must reinvent software development, and "roll our own" processes, jargon, and activities? And what benefit can we obtain from a large and purposely generic process such as the Rational Unified Process® (RUP®)?

In my consulting work, the confusion over the essential elements of RUP is staggering. Rational initially marketed RUP as both a process and a product. But in the past couple of years Rational has responded proactively to this confusion and launched a re-branding of RUP as a framework: a set of worker roles, activities, deliverables, and more that can, and must be, completed with organization-specific content to produce a working and workable process. Articles and books on how to take advantage of RUP's "agile" capabilities have proliferated in the past year and a half. I published a very brief description in the January 2001 Rational Edge -- it actually fits on one or two pages of paper -- of the "extreme" RUP process I follow in my consulting engagements. Philippe Kruchten's Rational Edge article, "Agility with the RUP," is a brief evangelistic monograph that clearly conveys this framework perspective. Scott Ambler's recent book, Agile Modeling (Wiley, 2002), devotes several chapters to how agility in object modeling can be accomplished within a RUP framework. I am

going to refer often to the practices of Agile Modeling (AM) in this article because of its affinity with the modeling activities of RUP.

For all that RUP is, or can be, it is to be commended for its foundation on best practices. The issues surrounding the application of RUP have never been on the qualitative value of developing iteratively, modeling visually, or using component-based architectures. Instead, in my experience, the concerns have been over the quantitative application of these practices: How many models should I develop? How much detail should I put into them? What are the required activities to follow? What CASE tool should we use?

Do CASE Tools Fit Anywhere?

Indeed, the issue of where, and whether, CASE tools even fit into an agile process is highly contentious. Positions pro and con are hotly debated, but the reality is that most tools are basically process-agnostic. One of AM's practices is Use the Simplest Tool, and sometimes the simplest tool may be a whiteboard, or Post-It® Notes, or possibly a $5,000 CASE tool. The point is not the tool, but rather how the tool is used.

I recently wrote a review of Rational's new XDE/Java tool,2 which is an impressive product just based on its expansive feature set. But even more impressive is the ease with which I can make it work for me. XDE can be used in a heavyweight, high ceremony process if you want to use it that way, but its native personality is to be accommodating.

Let's look at how a tool like XDE can be used in an agile approach to a small software effort. I'll present a small case study because of the limits of this article, but the basic approach can be used on much larger, multi-person development projects.

The basic vision for this project is to develop a Java application that manages the nutritional profiles of bodybuilders and fitness people. This population has a particular interest in establishing meal plans that supply specific target values of the main nutritional components of fats, carbohydrates, and proteins. The major stakeholders are the bodybuilders and fitness participants, plus personal trainers and nutrition consultants.

What are the major features, and how do we capture these? We have at least three options:

● Traditional, paragraph-style requirements format ("The system shall...must...")

● Use-case descriptions

● Stories

The traditional approach is too heavy, and we can get stuck in "Big Requirements Up Front" much too easily. How about use cases then? They are an integral part of RUP, but still require one to three pages for a complete process description. The basic services provided by this fitness application are pretty atomic, so let's try stories. Stories are part of XP, and are very simple textual descriptions of discrete features in our system. (You can think of them

as analogous to line items within a use case.) Here are some of the major stories for our system:

#1: Manage Food Items

The client (i.e., the user) can create and manage food items and their nutritional properties. For example, a food item could be captured as: Roast Beef, 4 ounces, 250Kcal, 12 gm. fat, 2 gm. carbohydrate, 22 gm. protein.

#2: Managing Meals

The client can construct meals and populate these with food items. The nutritional properties of a meal are derived from the nutritional properties of its constituent food items. All changes to contained food items are immediately reflected in the meal's properties.

#3: Recipes

The system allows the client to define recipes that may then be managed as food items (e.g., Mom's Beef Stew).

#4: Graphing Goal Compliance

The system will graph the client's planned nutritional goals, and the actual nutritional properties attained. The client can specify an arbitrary time duration (week, month, June 6-21) that should be graphed.

#5: Convert Quantities

The system automatically updates nutritional properties when a client changes a food item's amount (e.g., 1 pound changed to ý pound), or weight dimension (e.g., 1 pound changed to 64 grams).

Now we have some basic idea of the behavior we should provide. What's next? Well, we have some concepts in our system that could become classes. The criteria for determining classhood are several, but the most important are: 1) the candidate concept has identifiable behavior that is meaningful for our domain; and 2) the candidate concept (usually) has associated data upon which this behavior operates.

Right away we can see that we probably have classes of FoodItem and Meal. (Without these we don't have a nutrition application.) OK, so do we start modeling these in XDE right away? Not yet. Let's stay really agile for now, following the AM core principle of Travel Light -- that is, create only the minimum documentation or models needed. The next step is to define the responsibilities for these two classes. We can use 4 x 6 index cards and a CRC (Class-Responsibility-Collaborator) approach, as shown in Figure 1.

Figure 1: Defining Class Responsibilities

By doing stories and CRC cards, we are following AM's practices of Create Several Models in Parallel and Iterate to Another Artifact.

Now I can step up to a whiteboard and draw a quick UML class diagram to be sure I understand the basic semantics of the relationship between Meal and FoodItem. Is this association, aggregation, or composition? Hmmm, association is a peer-level relationship, and there seems to be a whole-part relationship here. Composition is best reserved for whole-parts that are immutable once formed, so aggregation seems the best choice.

Following the AM practice of Prove It with Code, now I can fire up XDE and enter a very simple model (Figure 2).

Click to enlarge

Figure 2: The XDE/Java Modeling Window

Why so simple and sparse? Because I am following the AM practice of Create Simple Content. This application certainly has more than two classes. Why don't I do more analysis and make sure I understand all the classes. Why didn't I put operations and attributes in the model? Because this model is enough to

get started. And with XDE in auto-synchronization mode, it has generated Java class skeletons for me that contain a default constructor (see Figure 3).

Figure 3: Class Code Generated by XDE/Java

How do I populate the classes? By writing tests that will invoke operations that don't yet exist in the classes. I'm using the JUnit (www.junit.org) unit test framework, so I add the junit.jar file to my XDE project Build path, and I create a test driver module in XDE with a JUnit framework. Stay with me.

Let's start with the FoodItem class. It is responsible for knowing its nutritional properties and its quantity. I talk with my customer and find this translates into the ability to create a FoodItem with fully populated properties. So, I write a JUnit test method (testNewFoodItem() in Figure 4) that creates an instance of FoodItem with arguments representing the values for Kcal, quantity, quantity dimension, fats, carbs and proteins. Inside testNewFoodItem() I invoke the JUnit assertEquals() method, which evaluates the truth of the condition expressed in the arguments to assertEquals().

Click to enlarge

Figure 4: JUnit Test Driver in XDE/Java

What is interesting about this method testNewFoodItem() is that I am writing this test before I write the code that will be successfully tested. My story says I need to be able to create a fully populated FoodItem. But my FoodItem class so far has only a zero-argument constructor: FoodItem(). And the methods getName(), getKCal(), and so forth, also aren't in the class yet. This means that the first time I run testNewFoodItem(), it will fail-- and that is exactly what I want. In Figure 5 we see the errors XDE reports in my test results in XDE's Run/Debug perspective.

Click to enlarge

Figure 5: XDE/Java Runtime Error Results from JUnit Test

Now I return to my modeling perspective window, open my code window for FoodItem, and add the methods I need for the method testNewFoodItem() to succeed (Figure 6). When I run the program this time, my test succeeds.

Click to enlarge

Figure 6: The FoodItem Class Code Needed to Pass the JUnit Test

Now I turn my attention to the Meal class. My story #2 tells me I need to be

able to add FoodItems to a Meal. So I write a test method to do this. TestAddFoodItem() creates an instance of FoodItem and calls the Meal.add(FoodItem) method.

public void testAddFoodItem() { FoodItem fi1 = new FoodItem("beef,"2,POUNDS,500,5,20,50); Meal m = new Meal(); m.add(fi1); }

But this test fails when I compile it, because I haven't written the Meal.add(FoodItem) method. So I add this method to Meal and rerun the test program. Voila, the test passes! This is fun!

Cool. My program is working, and I know it meets its requirements in the stories, because I first wrote tests to validate those requirements and then added the code to make the tests successful. I now have Meal and FoodItem working together.

But story #5 says the program should allow me to convert a FoodItem between dimensions: for example, convert pounds to ounces, or ounces to grams. I think about this and consider that a convert() operation in FoodItem is a reasonable first approach. But let's think about this: Should a "business" object like FoodItem also be doing utility-like calculations? I don't like this, because it would pollute the interface of the FoodItem class, and I would also like to be able to use this conversion capability in other ways.

So I move to the XDE modeling window and add a new class called Quantity that represents a quantity amount and dimension (Figure 7). Now, anything with amount and dimension will use an instance of Quantity to represent these. I add Quantity as a member of the class FoodItem.

Click to enlarge

Figure 7: Refactoring the Classes to Add a Quantity Class

Now I return to the code window, and in class FoodItem I replace the instance variables amount and dimension with an instance of the new class Quantity. I modify the getAmount() and getDimension() methods to use the Quantity class. After these changes my JUnit tests still work because I have only refactored the

existing logic without changing the public interface of FoodItem.

Conclusion

As I have explored the development of this little sample application, I have followed the philosophy of agility that encourages me to do whatever is best for the task at hand. CRC cards, whiteboard models, XDE/Java to get to code as quickly as possible, write the test before you write the code, and so forth. It works.

We have touched on a number of issues in this article. I hope the evolution of the brief project example has clarified the agile philosophy and practices. If you carry away nothing else from your reading of this, I hope it is that, contrary to some of the uninformed hype on agile techniques, agility is very disciplined and demanding. It is focused on tangible results -- working software.

In my own journey to agility I learned to ask a single question about every task on my consulting projects: Does this task directly contribute to delivering working software? If the answer is "no," then you should let your stakeholders know that this may be an obstacle to your primary goal of delivering software. (This is in accord with AM's core principle: Maximize Stakeholder Investment.) Or, you can just stop doing it and wait to see if anyone really notices.

When I was involved in the Agile Modeling forum3 I had serious reservations about some of the ideas being advocated by the XP community. Ron Jeffries, an XP luminary, made this challenge to the group: "If you eliminated one-half of your process, would you miss it?" This stunned me. I realized that over the past few years I have done less and less, and gotten more and more results. All of my projects follow RUP, but today I do less than half of what I did just three years ago -- and I don't miss what is missing. The issue is not RUP vs. another process; it's not CASE tools or their absence, and it's not models versus code. What's important is, do the simplest thing possible, and only do those tasks that directly contribute to delivering working software.

It's that simple.

Notes

1 Peter McBreen's recent book, Software Craftsmanship (Addison Wesley, 2001), articulately captures this artisan character of software development.

2 See http://www.sdmagazine.com/documents/s=7147/sdm0206d/0206d.htm

3 See http://www.agilemodeling.com

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information