Okay, what is a Model? Many arguments (discussions) arise from misunderstandings in terminology. So, as an aside to the SoftwareCannotBeModeled discussion, here are some definitions of (or feelings about) Models: From an interview with NoamChomsky by AlexanderCockburn (Models, Nature, and Language -- Grand Street Issue 50) Noam says: : "When you study natural objects you have to abstract away from irrelevant phenomena that can obscure nature. This is called idealization (which is a bit misleading because it actually carries you closer to reality). If you study the planets, for example, it helps to think of them as points which have mass and move in elliptical trajectories around other points. Of course, the planets are not points-- a point has no dimensions -- but if you treat them as such, you can predict and understand the solar system more clearly. That is a model." This was taken from the quarterly issue where all articles and artwork were focused on '''Models'''. -- ToddCoram ---- A model, at its simplest, is a vehicle which communicates ''fundamental'' principles from one mind to another. It is complete in and of itself, and no more. It contains all the flavor of a bite, or bites, but is not itself the meal. -- DonOlson ---- A common software model (should I write SoftwareCanSoBeModeled) is the prototype. In particular, the "human factors prototype" has the purpose of communicating between people what the system will look like. Merging the ideas of human factors prototyping, and incremental development, we get VisualProgrammingSystems. -- RonJeffries ---- A Model presupposes a Question, something to Examine. Having the Question explains why you left out the bits you left out, kept the things you kept, what you intend to do with it. When DonOlson says, "model, at its simplest, is a vehicle which communicates 'fundamental' principles from one mind to another", he leaves out who considers what to be fundamental, and what the two minds are interested in. Another statement, written around here somewhere, is that a model instruments something. Again, ... to examine some question. Without the notion of a Question or set of them, all the discussion of a model goes around and around. To me that answers the question of SoftwareCannotBeModeled ... of course it can, and look like so-or-so depending on what questions you want to examine. I provide some questions I want to examine over there (if I can get its editor to let me type on it.) -- AlistairCockburn ---- ''Stepping onto soapbox'' Noam's definition is a reasonable summary of the cyber-centric (see, I got that trite prefix in today <g>) view of the definition. Here is what The Random House Dictionary of the English Language (Unabridged) offers: Model: n 1. a standard or example for imitation or comparison. 2. a representation, generally in miniature, to show the construction or appearance of something. 3. an image in clay, wax, or the like, to be reproduced in more durable material. 4. a person or thing that serves as a subject for an artist, sculptor, writer, etc. 5. a person whose profession is posing for artists or photographers. 6. a person employed to wear clothing or pose with a product for purposes of display and advertising. 7. a style or design of a particular product: His car is last years model. 8. a pattern or mode of structure of formation. 9. a typical form or style. 10. a simplified representation of a system or phenomenom, as in the sciences or economics, with any hypotheses required to describe the system or explain the phenomenom, often mathematically. 11. (Zool.)an animal that is mimicked in form or color by another. [adj., v. forms elided] At the risk of pedantry, I think it's important to point out that our (we being the software industry) use of the term is ranked #10 in the above list. Most of our clients, and the bulk of the rest of the world, mean one of 1-9 when they use the term (even if they don't admit it). And at least some of us (MeaCulpa) explicitly mean definition #1 when we use the term "data model". I'm particularly disadvantaged here, because I also grew up making HO ''model''s of trains, where I strived mightily to capture *every* detail possible. So my point is that we have at least two imperatives at play here, both employing the same term. In the definition #1 sense, we often attempt to use our systems to create ''a standard or example for imitation or comparison'' of client data, business practices, or algorithms. In the definition #10 sense, we also often attempt to use our systems to create ''a simplified representation of a [client] system or phenomenom'' for analysis. Perhaps we can find a pattern to resolve these two forces? In the meantime, perhaps we can agree to use the term two different ways, or else qualify it (DataModel or AnalyticModel). ''Stepping down, to a smattering of polite applause, realizing that he has spent entirely too much time on chatservers'' -- TomStambaugh ---- Well, let's see if this thing will jumpstart, after sitting idle in the garage for four years. The term 'model' comes from the Latin ''modus'', meaning measure, and the 'l' at the end comes from the diminutive suffix "elle" or "ello" (depending on which Romance language you trace it through). So, a ''model'' is none other than a small measure. The reader will be quick to note that small measures mean little until applied to something. "A small measure of what?" Etymology, as usual, provides precious little specialization, leaving modern meaning to evolve in a bunch of different directions, as has happened to this little word. However, all modern meanings still derive from this basic concept of a small measure. BigModelsAreUseless, indeed. They're not even models! Since modeling* means going from relatively big to relatively small, there is an inherent data compression problem in all modeling: "what to leave behind?". Modeling is a "lossy" undertaking, and that's why "all models are wrong". There are as many ways of modeling a thing as there are ways of taking some but not all of it. Be that as it may, there are families of models, perhaps even ModelingPatterns**, that are characterized by the granularity and distributions of parts taken and parts left behind. For example, I can randomly sample the entire loaf of bread, taking seventeen crumb-sized granules, or I can lop off just a corner, or I can skin the loaf, taking the soft innards and leaving the tough crust behind. As Alistaire says above, the right model depends on what you're trying to do. Modeling and analysis must be second cousins once removed, and their relation is clearer if you also take the more archaic meaning of ''analysis'' (to break apart), as I am lobbying on this Wiki for software developers to do. In the first place, it's impossible to make a model of something without dividing it, that is, ''analyzing'' it. In the second place, we choose ''analytic models'' for their properties of revealing even more of the structure of the original thing than was evident in the initial direct observation of that thing. Hmmm. Isn't this a generative process? The first "break" is often crude, and only a little bit revealing. The next "break" goes deeper, and so on... Analysis for analysis' sake? Maybe, maybe not. - - - - - (*) Don't be afraid to spell modeling: "modelling", since the double-l harkens right back to that highly significant diminutive suffix (see above). (**) But where can I find them? -- WaldenMathews ---- CategoryDefinition