Eg Software Cannot Be Modeled

"Immutable" version of a major refactoring of SoftwareCannotBeModeled by AlistairCockburn on 19th October 1999. Please do not edit this page. See http://c2.com/cgi/quickDiff?EgSoftwareCannotBeModeled for the (large number of) differences between the original and refactored versions. Comments welcome in RefactorByCondensingConversation.

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)

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.

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 Norman Mailer'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.

-Patrick Logan, 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 phenomenom. 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 phenomenom 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