... .  .    .       .joeberkovitz.com

Software Modelling: Soft Focus or Hard Edges?

May 17, 2007 on 2:49 pm | In Programming |

An ex-colleague recently posted a question about “model-driven architecture” (or MDA for short) at the company he works for. It was a set of issues that I’ve heard many times in different guises over the years, phrased in different ways. I’d paraphrase what he said something like this (the original was more coherent):

Some people here seem to think it’s better to have a process where you have to design everything in UML up front, so that you’re forced to model things before you can write a line of code. In fact, they want to universally generate a code “backbone” from the model, which means the UML has to be constrained and decorated with extra detail so that code generation can succeed. This runs counter to my experience that super detailed design throughout the project lifecycle doesn’t really help. Testing should drive development, not ever-more-detailed design. Agile development really seems better than model-driven architecture.

This made me think about a bunch of reactions that I’ve had — also recurring over the years — to this kind of question. After all, model-driven approaches and agile development are hardly new concepts, although the nomenclature of “MDA” and “agile” is more recent.

I replied something like this…

I don’t think of MDA and “agile” methods as necessarily opposed to each other. Modelling, whether it’s UML or some other system, can serve several good (and potentially agile) purposes:

1. Modelling is an aspect of software design, and design certainly helps at the appropriate point in the project — i.e., an early point.
And if the project tracks the model (a huge “if”, of course) you wind up with a useful artifact that documents the work.

2. Some models are far simpler than the corresponding structures in the target programming language, in which case code generation from a model may save a lot of needless work. Complex state machines are an example.

3. Models can serve as a unified representation that can then be run through code generation to produce output in multiple target languages, if and when that matters.

At Allurent, all three of these factors come into play, and MDA really helps us a lot on certain model-heavy aspects of our projects (although we don’t use UML to represent our models, but XML documents — we generate UML from those). Since you didn’t mention #2 or #3, so I assume the folks at your company are thinking in terms of #1.
In that case it sounds like the issue may be a question of “brittle design” vs. “agile design”. Is modelling and code generation getting in the way of doing your work or helping it? It can do both, depending on how it’s used and the attitudes in play.

The chief value of modelling as a design tool (whether it’s UML or any other methodology) is that it forces any design discussion to exclude detail that gets in the way of examining the “value system” of a design — the key concepts that help you grasp what it’s about and whether it does its job clearly and effectively. I think this is helpful. For some aspects of design, mostly the high-level responsibilities and interactions between objects, I appreciate and advocate models as the best way to debate and refine ideas before code gets written. So I think modelling (UML included) does indeed have value even before your code is written.

But the very same “soft focus” that helps this kind of discussion gets in the way when you try to turn a model into actual code. Generating code from UML or anything else can start to feel like a real chore if the model doesn’t really correspond to the code on a perfect 1-to-1 basis. Either the needs of the code “over-sharpen” the model, making it fussy and annoying as a modelling tool, or the gray areas in the model “blur” the code, meaning that you still have to do a lot of tedious work to bring the generated code to the point where you’re able to work with it effectively.

Now, one can absolutely use UML and agile methods together, if UML doesn’t mire you in tedium. But it sounds like your colleagues may want to force UML to be used for a finer level of design than is always helpful, and that the code generation tail may be wagging the modelling dog. Model-driven code generation is great if it has a net positive effect (#2 and #3 above, again), but it can be abused in the name of forcing models into canonical statements of what the code does. Usually the end result diverges from the original model anyway, unless round-trip model/code generation is used, and that is often fraught with difficulties. So unless code generation is really a necessary and integral aspect of your use of modeling, the soft-focus-vs.-hard-edge dilemma tends to drive the model in a somewhat different direction from the code — and with good reason (since the model’s purpose is to expose and elucidate, not to describe canonically).

I have a suggestion — to try to move things in a good direction, perhaps focus on the the question of how UML is being used as a design tool and how its use can be made more agile and use less developer time on non-modelling-related work. Starting a debate on “modelling bad, agile good” can misdirect the conversation.