Modelling and Software Development

pattern n. .... 2. a model or design or instructions according to which something is to be made ...5. a regular form or order in which a series of actions or qualities etc. occur....

pattern v. 1. to model according to a pattern^[1].

Anyone who has studied human geography has probably come across the work of Walter Christaller. In 1933 he proposed a model to describe the settlements patterns in southern Germany - see side bar. While this model shed some light on where settlements had occurred nobody really expected it to actually give the location of settlements; it described settlement patterns in an abstracted way.

Models, by their nature make assumptions to simplify things: when Airfix produced their model F1-11 - the company attempted to show you what a particular jet bomber looked like but they never claimed it would fly (OK, I'm sure I was not the only boy who tried to fly the odd Airfix model out the bedroom window!)

From a programming perspective we are concerned with information models: this places us closer to the models of Christaller than Airfix.

If at this point you wonder what all this has to do with software let me spell it out: when we create computer systems we are creating models. Sometimes these are obvious: I once worked in a department modelling the electricity market, these predictions where used directly by management to decide which electricity contracts to sign; sometimes these models are less obvious: a customer relationship management (CRM) system models the expected interactions between company and customer, when the model fails we find post-it notes on people's terminals "If Jack Smith phones transfers him to Jo."

Our models have boundaries: within these conditions and scenarios are dealt with. Some boundaries are explicit, some are tacit. Economists are familiar with these boundaries: every economics model comes with the "all other things being equal" pre-condition. Their models will attempt to describe activity provided every other boundary condition remains unchanged. In many cases these models make sweeping generalisations. The monetarist model (see side bar) attempts to predict inflation in a closed economy. In itself it is useless because it is so general, but it does allow economists to reason about an economy. It also forms the starting point for sophisticated models used by make economic predictions.

In software development we build many different kinds of model, on any project the different models look at the problem domain from different perspectives.

When we use CASE tools like Rational Rose our modelling is obvious, but even when we write C++, Java and Pascal we are codifying our logic in a language model. The languages and machines which run our models are all Turing equivalent so no computer or language is really more powerful than another, but each brings different techniques for modelling the problem, for thinking about the problem, and this is where their power lies.

Object oriented Java is not more powerful than procedural Pascal because it runs faster; it is more powerful because it allows us to think, to model, in different concepts.

Beyond language we have notations: when I draw a UML chart you know that a rectangle means one thing and circle means another. Actually, I will take exception with my own argument here: I think many of our notations, especially UML, rely too much on subtleties, a folded corner on a rectangle means it is different to a regular rectangle, while a dotted line is different to an solid line. I think we often try and put too much information into our notations.

I found the following story in Software Fundamentals: "if the presenter showed a block diagram, Dave [Parnas] would ask about the semantics - the meaning of different block shapes ... the meaning of an arrow; whether an unfilled arrow meant something different than a solid, filled arrow... Usually these frills had no meaning. They certainly didn't aid careful analysis, and they often got in the way."^[2]

In recent years the patterns community has moved to define more labels for more models. In the case of the GoF book they defined a meta-model that could be used to describe all their models^[3]. Now when I say Singleton, Chain-of-responsibility or Mediator you know what I mean - OK, I deliberately included Mediator because it is not so well known and this is one of the problems the patterns community faces; it has been so successful in defining patterns that, outside of a core half dozen, few are widely known.

Like Christaller we can never expect our models to exactly describe a situation - by their nature they are abstractions. The simplification we make to create the model and generalise it return in real life. This brings us to the realm of Chaos Theory, a small variation can, over time, when repeated, magnify into significant difference.

We also face the problem of Catastrophe Theory - when multiple parameters are varied things start to break down. And as if this weren't bad enough we also have to face the law of diminishing returns^[4].

The key with a model is identifying variability^[5] however, we frequently miss points of variability and need to adjust our models accordingly - but add too many points of variability, too many if's and but's and instead of a model we have just a list of special cases.

The more parameters a model has the less useful it is. There is no model of the game of soccer because there are too many parameters which can effect the game, we can make generalisations: Manchester United usually win, Everton usually lose^[6].

We should not expect our models to be exact, nor should we expect to follow them blindly. Sometimes it just doesn't make sense. Yes, we would like our singletons to be nicely destroyed at the end of the program, but what does it matter if the OS model will clean things up? Sometimes the work involved is not justified: consider the GPS system in a cruise missile, what does a memory leak matter in the final few milli-seconds before impact? Attempting to have a GPS-singleton delete itself neatly is more work for the programmers and adds more variability to a system at the exact moment when it must be totally predictable.

And not only with code and patterns: the process models of Yourdon, Jackson and Beck are really just more Christaller models. Yes, we can learn from them, we can compare ourselves to them, but to attempt to adopt them as laid out by the authors is about as sensible as ignoring the a mountain range when building your village!

Models provide us with many benefits:

However, they come with drawbacks:

The value of a model lies in the abstractions it makes: by focusing on what the important elements are we are not distracted by the irrelevant ones. This is a classic definition of software abstraction but it also brings us back to Christaller: on the German plains Christaller accurately isolated the abstractions that describe settlement patterns. But, you would never expect to find Christaller's settlement patterns exactly because there are things like rivers, hills, particularly fertile land areas and such. Equally you should not expect your software model, your pattern, to describe exactly your software.

Models are an essential way of abstracting problems and patterns. Using models we can codify and communicate ideas - this in turn allows us to learn and to share ideas. However, as other disciplines know, models have limits, we should not expect our idealised models to be used straight out the box. Every model, whether it is a design pattern, a process or a programming style must be adapted to our present circumstances.