Models shmodels
I can't spend one day without reading some article, blog entry, web page about the unified modeling language (UML), model-driven architecture (MDA), or "modeling visually" as a best practice. But I've been unable to find background documentation which says anything useful about the role of models and modeling in software development.I've only ever had two real insights regarding models and modeling, but they are relevant and perhaps important enough to share here. A small preamble first.
If I think about what the term "model" evokes in general, outside of its software-specific meanings, I come up with two things. One is "scale model" - some physical, made-of-atoms object which in some way stands for another object. A cardboard model of a cathedral, a rods-and-balls model of an atom or a molecule. The other meaning is "conceptual model" - some set of abstract statements which in some way is about the real world or some aspect of it.
On the face of it, the meaning which is more appropriate in the context of software development is the theoretical one. Software is not physical, the kind of "modeling" which involves actual atoms does not seem to apply, except perhaps in one kind of situation. We do sometimes write software which "stands for" some other software that will be built on a different scale - we call that "prototyping".
Other than that, modeling in software must for the most part consist of conceptual modeling. A conceptual model is a set of statements about something, a description of the world; it is a set of symbols with a definite structure, which can make sense to someone. But then, so is any descriptive statement. What's different about a model ?
Insight number one, which I got from a colleague keen on UML, is that a model generally discards most of the information available about what is described. A model is a good one if, with what little information it retains, it still lets us derive useful statements about what it describes. A Newtonian model discards just about all the knowledge we have about physical objects: their color, texture, taste, fragilty, chemical properties, etc. All it retains is mass and location in some coordinate system. Yet it can be used to predict planetary motion to great accuracy.
In other words (George Box's words) : "All models are false, but some models are useful."
Insight number two is about the way we use models - and it's not one that can be explained in one short sentence. I owe it to Betty Edwards' "Drawing on the Right Side of the Brain". I bought the book because I'm not a very visual person, which perhaps explains my lack of excitement about UML documentation in general. It hasn't turned me into an artist or a UML fanatic yet, but I took at least one thing of great value from it - a splendid metaphor for how models work. This is the "viewfinder" tool Edwards introduces at some point, a clear pane of glass or plastic with horizontal and vertical guidelines drawn across its center.
Most models work precisely the way the viewfinder works. They are something interposed between our unaided sight and reality. The lines they draw permit us to make distinctions; this thing is in the upper left quadrant, that thing in the lower right. These statements are not literally "true" of the things we see; they are only true statements about the relationships between the model and reality. But by using the viewfinder we can find out important structural relationships between things in the scene we are trying to draw. These two simple lines let us achieve what Edwards says is the key to drawing well: drawing what we actually see, not what we think we see, after having processed the scene through a variety of symbolic filters loaded with all sorts of preconceptions ("faces are round", "ceilings and walls are at right angles to each other").
Another parallel: most people, once they draw well, rely less and less on the viewfinder. (Or so I'm told. I still can't draw worth a red cent.) So it is with models: the more useful ones we "internalize" until we come to rarely, if ever, use them consciously.
For a great example of an actual model that looks very much like a viewfinder, see this entry by Brian Marick.
Taken together, these bits of insight make me extremely puzzled that we call a "model" a UML document, or more generally a picture which can be transformed to any extent into code. (This isn't to say that a UML diagram has no value. In particular, I think UML can be good for learning one's way around a given piece of software. Perhaps UML makes for good maps. A map can with some justification be called a model, but certainly not all models are maps, and we should use the more precise term.)
Perhaps there is some confusion resulting from the "discarding most information" aspect. It's true that design diagrams discard most of the detailed (and nevertheless important) information about code, just as it's true that a model discards most information about what it describes. This is the property of abstraction. But just because diagrams and models have abstraction in common isn't enough to call diagrams models.
Abstraction is important, and something I've thought about as well - but that'll have to wait until later entries.
No comments:
No trackbacks:
Trackback link:
Please enable javascript to generate a trackback url