I started work on a new application today. We sat around the white board coming up with objects/data, and I did some rapid modeling of the white board data into a rough
UML class diagram using
OmniGraffle 2.0. OmniGraffle is a fine choice for anyone (on Mac OS X) doing some form of
Agile Modeling.
I've had a love-hate relationship with UML over the years, and especially with modeling tools. There are many problems (that have been acknowledged, and some tools even do their best to solve them), such as
model and source code getting out of sync, or
how do you effectively model a language like "Python"?. On top of these issues lie many of the issues that have plagued programming, especially in the age of internet development, for years - the need for speed (just hurry and get it done! document it later!), scope (a project is [often misconceived as] too small to spend time modeling}, or inability to map web based programming techniques into communicative diagrams (is a JSP page a class? A UI Component? Or is its rendered state a UI component? Huh?). And often, good development processes seem to be killed by the attempted formalization of a process.
This is why it's been good to see the rise of practices like "Extreme Programming", "Agile Modeling",
Refactoring, and so on. While there is definitely value to a heavy process like the
Rational Unified Process or
Catalysis, small shops and teams just can't take on that kind of overhead most of the time.
So, like my story about "Testing Joys" where I was able to get over that often difficult first hump from idea to realization through unit tests, today I
re-experienced the same thing with a quick model. And I emphasize re-experienced, because these feelings get lost quickly during the course of a project, where deadlines and other pressures often kill off even the best practices a developer tries to have.
So, "Agile Modeling". Today is actually the first time I've read about it at all, besides seeing the book title. And I don't claim to follow any of their practices fully. I just like the general idea. Modeling is about
communication. Sometimes that communication is in the form of ideas of how a system could be shaped. Sometimes that communication is in the form of details about how a system
is shaped. And often, a tool can be too rigid which gets in the way of the "shaping of ideas", or it can be too typecast to a particular language or target environment to accurately express the details of what has been/is being produced.
The latter bullet has gotten in my way plenty of times. Few tools support Python concepts. Fewer still support Zope-ish ones. At
Zope Corp, we were never able to come up with a really good system that would let an engineer jump right in easily, even using a Python friendly tool like
Object Domain. Furthermore, many UML tools available for the Mac OS are either pure Java, or some other cross-platform compilation, making them awkward to use on a Mac.
So where does my take on "Agile Modeling" come in? Usually, I need diagrams most for sketching out ideas about a schema design or workflow model. A tool like
OmniGraffle makes this easy, since it's really a very basic diagramming tool. And that's its strength.
Visio and
Concept Draw are both expansive diagramming tools, with more flexibility than their Pure-UML/CASE tool counterparts, but they're still too heavyweight. The learning curve is probably too steep for a developer to pick up quickly enough to do something like capture a schema concepts off of a white board. And still other tools, like
Illustrator are too design focused to be used quickly for technical diagrams. OmniGraffle seems to get it just right. It has plenty of built in
Palettes of usable objects, which are often simple shapes or compounds of simple shapes. It includes a UML palette, with various UML objects and connectors. And, it's Mac OS X native, meaning most expected shortcuts (option-click-drag to duplicate) work as expected. Since it's not a die-hard UML tool, it doesn't try to do any sort of type-enforcement and it doesn't present rich dialog boxes or property inspectors to fill in special properties about a class or a method. The parts of a UML Class object are just boxes with text in them that are freely editable. This is very good for rapid, er, "Agile" modeling situations, like being in a meeting and trying to capture whiteboard notes that don't necessarily fit in an outliner, or working on a diagram while meeting a perspective client while he's talking to someone else. A fast, flexible tool that gives you just enough features to communicate a design to a boss, coworker, client, customer, or general public...where can it go wrong?
It can go wrong when it comes to handling large models. A pure UML tool, or advanced diagramming tool like Visio, can attach a lot of smart data to a visual representation. Behind a UML Class object on a diagram can be all sorts of data, such as public/private member settings, where the class resides, OCL constraints, relationships, etcetera. All of this data can be used in another diagram in the same model, but with different visual representations. And, in theory, the data could be used to generate code from models. Documentation can also be auto-generated from all of this extra data in a model.
But, since code and models can get out of sync with each other rather quickly, it's sometimes still best to go couple "Agile Modeling" practices with "Extreme Programming" - keep the code clean and clear enough so that it can communicate the grand design on its own, and use models to express fundamental relationships, schemas, activities, or other aspects of the system before, during, and after the development process. You rarely
need anything heavier than that.
The ultimate point of this rambling post - the diagram I was able to throw together today based on our whiteboard meeting immediately drew expressions of "can I get a printout of that?". Since I was able to keep up with the meeting and design as it was happening, instead of wrestling with the tool, the results were on target even though the design was in flux throughout the meeting. Then, without too much effort, I was able to tweak the diagram after I got back to my desk to better communicate relationships between objects, with very little fuss from the program. And since it was so quick to start up, work on, and print out, I have no real strong ties to it - I know that changes to the design will be easy to record and reflect, and not take up too much of my time away from producing the software I'm expected to produce. This ultimately means that I'm more likely to either keep the diagram up to date, or discard it when it's no longer needed. This is in contrast to trying to enforce heavier process guidelines on myself, causing me to have to do big "hat switches" to shift from modeling mode, to coding mode, and back again - usually grumbling about "ugh, I have to update the model now..".