Guest Blog: The Truth About Agile Modeling
My name is Terry Quatrani and I am the Rational Evangelist at IBM. I must confess that I am also a modeling bigot. I started modeling in 1988 using a GE proprietary methodology that eventually became the Object Modeling Technique (OMT). In the early 90s I moved on to the Objectory and Booch techniques. I watched UML being born and followed its progress as it matured into UML 2.
Over the years I have found two main benefits to modeling. The first is communication. When you have a model you have a visual representation of your system that can be used as a discussion point between different groups of stakeholders. For example, a simple sequence diagram can be used to show interaction between a user and the system. This will allow you to communicate with the user and explain exactly what the system will do. This same diagram can be used to communicate with the development team allowing early prototypes of a system to be built.
The second benefit is one that I have found by experience. It is the fact that modeling helps me think. If I have to create a model, I am thinking about my problem before I write a line of code. In the long run, I have found that this means I eventually develop better code.
I spend a great deal of my time traveling the world giving presentations about modeling and UML. I must confess, it still amazes me that UML is 15 years old and I am still doing Intro to UML talks and packing the house. I guess it just goes to show that more and more professionals are looking at modeling as a way to overcome some of the challenges we face as we develop the computer systems of today.
“I am following an agile process so modeling is not important” is a phrase that I have been hearing lately. My answer is simply “that is not true”. Even if you are following an agile process, you will do some degree of modeling – you just won’t do it as much as you would if you were following a traditional process. Also, the degree of formality will probably be different.
For a traditional process, many of the diagrams are persistent and are updated as changes are made as the system matures. In an agile world, this is not the case. Many of the diagrams that are created are simply sketches that are used to help one think out a particular problem. A lack of formality doesn't mean that you're not modeling - it just means that you're likely focusing on getting the benefits of modeling without the drawbacks of extraneous documents.
In a previous Dr. Dobbs Agile Adoption survey 77% of people on agile projects responded that they do some up front agile requirements and architecture modeling and 93% indicated that they do whiteboard sketches -- interesting stats considering that agilists supposedly don't model.
No matter what type of process you are following, you still need requirements. If you are following an agile process, you probably will not be creating use case diagrams. In fact, you may not even be creating use cases. Instead, your requirements may be captured as customer tests. This is what people are referring to as Test Driven development.
When you think about it, you're modeling when you're writing a customer test just like you're modeling when you're writing a use case. One aspect that is very important to testing is timing. UML 2 introduced a Timing Diagram as an official UML diagram. A quick sketch of timing requirements is a great way to capture and communicate performance requirements for a system – especially if it is a heavy user interaction type of system. In fact, value stream maps, which are very popular amongst the lean software development community, are one form of a timing diagram.
Next, let’s look at the architecture of a system. No matter what type of system you are building, no matter what process you are using, not matter what language you are using, architecture is important. I don’t know anyone, even the best pair programming teams around, who can just sit at their computer and type out code. Some degree of planning is necessary.
Here, class diagrams are typically created to show the major classes of a system and the architecture of the system. The level of detail in the diagrams is not what you would see from someone doing traditional development and code could not be generated from these diagrams since they are not near detailed enough. However, this is still modeling. Additionally, free form or stack diagrams are often used to describe the technical aspects of an architecture - so sometimes you need to go beyond the UML to get the job done and that's perfectly OK, you are still modeling.
Finally, let’s look at sequence diagrams. These diagrams are great if they are used to capture user interaction with a system. You simply create a diagram with two “objects” – the user and the system. You can then sketch out how a user will interact with the system. Again, this diagram will only be a sketch to help you think, but this is still modeling.
In conclusion, I think some degree of modeling is here to stay. The advice that I always give to people is simple – do what makes sense. You only want to create enough diagrams to help you communicate and think out your problem. In the end, this will help you build better software faster! For more information on agile modeling solutions from IBM Rational, please visit ibm.