Software Cannot Be Modeled

Can software be captured in diagrams on paper or any other medium but the actual instance of itself?

Can Software be modeled? (Page influenced by SoftwareHasNoShape and related to WhatIsaModel). (This page heavily restructured Oct 99 as a test of RefactorByCondensingConversation, comments on the restructuring welcome. Old version at SoftwareCannotBeModeledOldVersion for comparison. -- AlistairCockburn)

First, what is a model for? Add digest of your view at the top of the list, longer comments below. (The anonymous versions were pruned from lines by WardCunningham & JimCoplien & AlanWills & DonOlson & ToddCoram & AlistairCockburn &...)

Software *is* a model. I may have other separate models of my software because... I don't want to show all the details all the time. -- PatrickLogan

Models are things I created to wrap my wits around those problems I lacked the confidence to tackle head on, an aid in discovery by seizing my attention so that I am not continuously terrorized by the enormity of the beast. -- DonOlson

We make models to understand relationships, without having to dwell in details beyond what is minimally necessary. -- DonOlson

Models are a way to gain confidence; text, diagrams, prototypes, CRC cards, ... I don't have faith that it is possible to model a system to the point where it yields the system itself. -- DonOlson

A model is a spoof of the original, like the thing but not the thing, designed to be faithful in some areas and deceptive in others;

We build models to examine specific questions we have about the system. This justifies our abstracting and removing "irrelevant" things. "Irrelevant" means things that do not contribute to the examination. (see WhatIsaModel) -- AlistairCockburn

Software is not always a model of the system in which it resides or with which it interacts; it is part of that system, and as such, there are limits to its function as a model of that system; but,

Models are limited in fidelity, because abstraction always loses information. When the properties of interest are sufficiently manifest in software itself, further modeling is inappropriate.

Models are worth preserving because they keep clear, through many variations and many generations of maintainers, the the aims and principles on which the software is built.

Models are safe to monkey with because they do not bear the burden of the expectation of success or financial gain.

Anything that exists can be modeled, and software is no exception. How good the model is and what it can be used for are related questions. -- WaldenMathews

No. Software is its own best representation of itself. No matter how well you have attempted to diagram, explain or model software, the truest representation of functionality lies within the code itself.

Of course, we try to manage the complexity of software by documenting the design, but you cannot expect to get the feel of a system until you see it yourself. (See ArtHouse)

This is even more true in object oriented software development. We may go through a complete Analysis, Model and Design using CaseTools or documentation systems, but we end up changing the objects and their relationships during implementation. (Of course, we go back and revise the design docs when this happens. ;-)

Good ClassBrowsers? are great for walking through software buildings. They are not a substitute for design docs which may attempt to give the big picture, but they are great for letting you roam about. You want to really understand a software system? Browse it.

-- ToddCoram

Many people model software. The pertinent question is: why bother?

"All models lie; many models are useful." CRC cards are a software model: a particularly good and dynamic model. They don't model performance or memory requirements particularly well, but they are still useful. ("If you want to understand a system, be the code").

Bertrand Meyer relates that he has long been intrigued by the industry fascination with CaseTools. Why would anyone in their right mind want to build abstract models, when there is so much to express in the code, and learn from the code? One morning, while shaving in front of the mirror, it struck him: bubbles and arrows don't crash.

Blueprints are models; they serve a purpose. I wouldn't use them to evaluate aesthetics. If aesthetics are important to you, you want something other than a blueprint.

There are many who believe that software should "model" the real world; this is one of the themes of the OO camp. I agree only in small degree. TerryWinograd has strong sentiments against this perspective, based on his work in cognitive science. There are deep hermeneutical issues at work here, too: can you look through a Window to the outside, or pull down a shade or close the blinds on a Window? Why, when you close a Window, does it go away, and when you open it, it comes back into being? There are many dangers in this "inverse reification", particularly for the growing programming populace that lacks training.

-- JimCoplien

Can Software be accurately and faithfully modeled?

No -- ToddCoram

Software can be modeled to a point. Once again, it requires judgement, experience, and occasionally luck to determine just how much modeling is sufficient to support the next development step. With the right people, it all seems to happen in such a seamless, fluid manner that we all continue to crack our skulls over exactly how we can refine it into a series of steps that are guaranteed to produce perfect software, first time, every time. Are we perhaps forgetting that even a discipline as old as architecture requires refinement at every stage, and that occasionally entire walls, or plumbing sections have to be torn up and redone by the construction crew despite the detail of the design? Hasn't there been at least one sewer system, which despite the best hydrological modeling did not respect the fundamental fact that shit runs downhill? Someday we will accept that there is no substitute for judgement, and that the degree of modeling will be flexibly based on the complexity of the problem, the expertise of the team implementing the system, the tools available, and a dozen other factors that only human experience and intellect can evaluate.

Tangential thought: read the chapter, "The Psychology of Machines" in NormanMailer?'s Of a Fire on the Moon. His thesis is that beyond a certain point in complexity, no machine can be completely comprehended and its behavior must be considered psychologically rather than mathematically. Something like that. -- DonOlson

Yes, we can model software "to a point". But modeling only reproduces its archetype "to a point"; to do moreso would cause it not to be a model.

I think it is not a question of faithful, but of complete. Tautologically, a complete model is not a model. We use quite faithful models of telephone network performance to do traffic engineering. They are faithful to the real thing, but they abstract (unimportant) details (unimportant to the modeling objective).

I loosely use the term "model" for performance models, reliability models, and other system perspectives that can be captured using mathematical formalism. (I'm not arguing for a standard definition, just conveying my personal use of the term). Stuff like CASE tool diagrams, I call specifications. As the name suggests, they are specific. Specifications leave many dimensions unarticulated; I think this is fundamental to any specification of a non-trivial system. The code itself is the most specific specification. But it may be a lousy model.

-- JimCoplien

Software *is* a model. I may have other separate models of my software because...

My software may be incomplete, but I want to show what I do know. Or my tools may not allow me to view my software in multiple ways, but I don't want to show all the details all the time.

Ideally, there is one instance of my software and multiple ways to present it. As I know more about my software, I add to it. But ideally, I can still view it many ways.

As I add to it, there may be ways to "execute" it. Execution may tell me things that help me add to my knowledge about it. Some types of execution may be sufficient such that I do not need to add to it. I can stop adding to (for awhile, anyway) and perhaps give it (or sell it) to someone else.

I hope this obtuse message communicates something about how I view the analysis/design/implementation distinctions as something to be avoided.

-- PatrickLogan, patrick_d_logan@ccm.jf.intel.com

I agree with JimCoplien's statement that a complete model is no longer a model. However, I believe that you can model software. You do this by creating a complete model where the interfaces to the realworld are unchanged when you use the model as a model verses feeding the model to a machine to create a real world application. In this case the model is also then a specification for the exact application that it models.

Consider this point and extend the concepts to an arbitrary 'language' for model specification. If the language is capable of specifying everything except the interfaces to the real world, it might become quite complex. One might then be tempted to just use the language of the system where the real world interface exists.

What I am trying to bring out is that your program can be considered a model if it can be used with the real world interfaces stubbed off. If you wanted to then replace those interfaces with machines, you could model the real world.

The fundamental issue for me is if you can not mechanically (and in some automated fashion) move your model representation into an application representation then you have no model.

Humm, did I say anything different than what has already been said? I think I said that if you call something on paper a model, it can't be (that was said above). The point I think I made was you can model software if the subset of the real world application that you call the model can be mechanically transformed into the application. There are many code generating case tools which purport to do such things. I don't know how many actually let you create models of the real world interfaces that would allow you to not have to 'rewrite' the interfaces to the real world when the model was transformed to a real application. whew...

-- GreggWonderly

I think we have once again been bit by the computer industry's appropriation of the word "model". Above, we used the term in its sense of reducing the complexity of a real-world phenomenon. On the other hand, in the context of, say, object modeling, or business process modeling, or even model-view-controller, we mean something different, I think.

DouglasHofstadter goes into this at great length in GoedelEscherBach, where he talks of isomorphism and its relationship to information and meaning. I think that when I create a "data model", I create a software entity that is isomorphic in its environment to the real-word entity that I am modeling. I try *not* to simplify, if possible, but instead to describe. While some simplification is inevitable with today's systems, I think that that is an implementation artifact rather than part of the fundamental semantics of the process.

If we accept that, then I see no reason why software can't be modeled - the model and real life happen to both be soft when I do. The existence of the model allows me to capture and manipulate the structure of the software that is otherwise more difficult to discover. Consider, for example, the rule that all VisualAge identifiers contain the "Abt" prefix. In fact, because the model and the phenomenon being modeled are both the same medium, in some sense the model can be more faithful.

When the model and the software being modeled exist in the same environment, I have a reflective environment. This allows me to, for example, discover that a method has only one implementer and compile away the message dispatch overhead. I can't do that unless the system has a *model* of objects, messages, and execution.

The environments that I'm most interested in, like Lisp and Smalltalk, are *causally* reflective. This means that they not only contain a model of themselves, but a change to the model causes a resulting change in the system behavior.

Yes, software be modeled, and it's actually *easier* to model than ugly real world stuff like mass that spins, fluid that flows, and storms that cause snow.

Finally, I think that the essence of successful application building is successful modeling. When I work on software tools, such as compilers, browsers, pattern editors, and so on, I model software. So I certainly hope that it's possible!

-- TomStambaugh

Yes, software can be modeled, since a model simply exists to allow a question to be examined (from WhatIsaModel). I have a whole lot of questions I want to examine about software - performance, load, fanin, fanout (aka coupling), ownership, changes, error rates, etc. So I want a performance model of the software, a coupling model, an ownership model, a error model, etc. All of these are valid models, satisfying the notion of "a model of software" as distinct from "the software itself". None of these models generates the software, which was somehow the implication in some of the original comments. I put a rule of thumb in HighLevelModeling. -- AlistairCockburn

Software can obviously be modeled; people do it all the time. The reason that people give that it cannot is that the model lacks some of the characteristics of the real system, but that is always the case with models. Models are not reality. Models always miss detail. Sometimes models are useful, sometimes they are not. Even when they are, we eventually have to turn from the model and face reality. So, the question is not whether software can be modeled, but when it should be modeled, and how. -- RalphJohnson

Anything that exists can be modeled, and software is no exception. Etymologically, 'model' is a noun meaning something that is a small version of something else. Here on this page, it is promoted to a verb: 'to model', meaning to build a model. Another way to look at the word is to think of it as the name of a relationship between two things. This helps keep the conversation concrete. The question becomes "Is X a model of Y?", or "Can a model of Y be constructed?". The answers must be highly subjective, since they depend on individual perceptions and whether you or I see any similarity between X and Y. For X to be a model of Y, X must share some attribute with Y, and X must be smaller than Y with respect to the problem we are trying to solve.

The purpose of models is to achieve ideals, or at least to approach them. The reason 'model' also means 'ideal' (as in he is a 'model' student) is in the fundamental truth that in the macro world, smaller things are easier to control than bigger things. When you build a model, you are striving for a kind of perfection that would not be possible in full scale. For instance, I may build a balsa model of the Empire State Building myself and succeed quite well at that, whereas I have no chance of building the real thing by my self. I may model a large brick building with a small swatch of red cloth, or a series of swatches of varying tones of red. When I get the color perfect, I am then left with the problem of making brick in that exact color. That's a related problem, but it's not a modeling problem per se, unless you extend the definition of 'modeling' to include growing a model into its full-scale counterpart.

I've never seen a good definition of software. I don't know if it's the bits in the executable, the language of the source, the medium on which source is stored, the executing system in action, or just what it is. Nevertheless, I do believe it exists. And therefore, whatever the hell it is, you can build (or find) a model of it. The problem is more likely to be the opposite of the name of this page. There are too many eligible models. -- WaldenMathews

A model is a representation of a characteristic or limited set of characteristics of a more complex object. A model's value is in its limited view of the original. The greatest problem associated with a model is that it does not reflect all of the characteristics of the original.

Anyone who has built a prototype GUI has built a model of the eventual software. You are hoping the prototype accurately reflects what the final product will be. Anyone who has written test code to recreate a performance problem and test solutions has written a model. You are hoping the solutions that work on your model will also work on the target system. -- WayneMack

Right, and maybe it's illuminating to point out that within software development, models are almost always aimed at making complexity smaller, whereas in the physical world, this is not at all the case. A good model railroad system is way complex and faithful to the real thing, just little enough (physically) to put up in the attic.

If you visit a real railroad engine, you would discover that, by its self, the engine control panel is more complex than an entire model railroad system. The model railroad system abstracts only the minimal features of the real thing. CM

Mental models are essential to understand your own code and explain that code with others. In technical discussions at work, I discuss and whiteboard various abstractions, and rarely look at a line of code. To the extent that it's possible, I shelter my coworkers from the coding details as we focus on the underlying ideas.

Moved from DesignWithoutResponsibility

Modelling is design without responsibility

(Perhaps unfair, in an environment wherein the model is the code... but try saying it to a roomful of methodologists! -- DavidHarvey)

I am fascinated by the dominant frame of reference here - the software as an artifact that embodies a design. The definitions thus far are mostly about models that reflect the structure of the software itself. A good an useful thing, but hardly complete.

Software is also the result of a process of humans thinking together. It is also an economic entity, the results of some investment with one hopes some value. Software is a static and formal description of dynamic behavior. Software - the source code itself perhaps - is an artifact in its own right independent of the run time behavior or the "model" it represents (similar to looking at a text independent of it's content, counting commas in Ulysses, for example). There is a lot to be gained by addressing these other aspects of "Software" in terms of models.

As three examples, take CASE tools (an example introduced above), XP (a painfully popular topic here and elsewhere) and Microsoft commercial software. There is some insight to be gained, I think, by considering how each of these topics relates to "software as artifact" (most of the preceding discussion), "software in the thinking process", "software as economic entity", "software as a static description of a dynamic process", and "software code as text independent of meaning."

Having done the thought experiment - three topics by five points of view - it seems to me that these vastly different models have some value. I may believe that "software the artifact" is well represented in the code at least some of the time. I'm less convinced that no other models need apply. I'm pretty sure that the four other points of view are not well represented in the code, yet can be modeled, and the modeling has some value. -- JamesBullock