"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,
[email protected]
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