My name is Terry Quatrani and I'm 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 to the Objectory and Booch techniques. I watched UML being born and followed it as it matured into UML 2.
I've 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 show interaction between users and the system. This lets you communicate with users and explain exactly what the system does. This same diagram can be used to communicate with development teams, letting early prototypes be built. The second benefit I've found by experience. Modeling helps me think. If I have to create a model, I'm thinking about my problem before I write a line of code. In the long run, this means I eventually develop better code.
I spend a great deal of time giving presentations about modeling and UML, and it amazes me that UML is 12-years-old and I'm still doing "Intro to UML" talks—and packing the house. It just goes to show that more and more professionals are looking at modeling as a way to overcome challenges.
"I am following an agile process so modeling is not important" is something I've 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 and the system matures. In an agile world, this isn't 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 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 the Dr. Dobb's Agile Adoption Survey (www.ddj .com/architect/200001986), 77 percent of people on agile projects responded that they do some up-front agile requirements and architecture modeling, and 93 percent indicated that they do whiteboard sketches. Interesting stats, considering that agilists supposedly don't model.
No matter what type of process, you still need requirements. If you are following an agile process, you probably won't 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 system. In fact, value stream maps, which are popular in the lean software development community, are one form of a timing diagram.
No matter what type of system you are building, no matter what process you are using, no matter what language you are using, architecture is important. I don't know anyone, even the best programming teams around, who can just sit at their computer and type out code. Some degree of planning is necessary. 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 because they are not nearly detailed enough. However, it is still modeling. 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 okay—you are still modeling.
Finally, sequence diagrams are great if they are used to capture user interaction with a system. You just create a diagram with two "objects"—the user and the system. You can then sketch out how users interact with the system. Again, this diagram will only be a sketch to help you think, but this is still modeling.
Modeling is here to stay. My advice 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!
