Weblogs Forum - Modelling the real world.

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Modelling the real world.

31 replies on 3 pages. Most recent reply: Apr 6, 2004 7:02 AM by Marco Dorantes

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 31 replies on 3 pages [ 1 2 3 | » ]

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Modelling the real world. (View in Weblogs)

Posted: Mar 8, 2004 10:04 PM

Reply

Summary
The concept of modeling the real world has been so badly abused in the OO community, that I want to find the person who first coined the notion and flay him alive. (not really.)

Advertisement

I don't know who came up with "Objects should model the real world." but we need to find the guy and trash him soundly. I think it must have been some poor schmuck who was trying to sell his boss on buying an early C++ compiler. (In the mid '80s you could spend as much as $30,000 for a good compiler.) I imagine the dialog going something like this:

Schmuck: Sir, we need to buy a C++ compiler.

Boss: How much will it cost?

Schmuck: It's $30,000.

Boss: NO. That's too much money.

Schmuck: But sir, the benefits!

Boss: What benefits?

Schmuck: We'll be able to better manage dependencies!

Boss: Manage them without it.

Schmuck: But our code could be more flexible and robust.

Boss: Make it flexible and robust without it.

Schmuck: But... er.... uh....

Boss: Time is money schmuck, get to the point.

Schmuck: ...Our software will be more like a ... uh ... model of the ... uh ... real world!

Boss: Hmmmm. Software that looks like a model of the real world eh?

Schmuck: Yes sir.

Boss: Would it be easier to understand then?

Schmuck: Yes sir.

Boss: Will it allow junior developers to program like experienced developers?

(Aside to audience) If this is true, I'll be able to fire all these expensive software geeks and hire kids right out of school!

Schmuck: Well, sir, that's possible, yes. Our software would be much easier to understand since it would have a much better structure and have it's...

Boss: (Eyes glaze over, foot taps.)

Schmuck: (continuing)...dependencies so well managed. Yes sir.

Boss: OK, Schmuck, you've sold me. Go buy that compiler. But I want to see models of the real world in our software within three months or your ass will be grass.

It's true that we want the vocabulary and relationships of the problem domain represented in our objects and methods. But that's not the same as "modeling the real world".

OO was "discovered" when two guys who were using a block structured language to write a simulation engine played around with moving the stack frame for a block to the heap, thus making the blocks long-lived. Voila: objects! From this very geeky beginning, OO has grown to be a

<fanfare> Major Methodology </fanfare>

requiring

<fanfare> Management Support and Approval </fanfare>

and

<twenty-one-gun-salute> Object Modelers and Architects </twenty-one-gun-salute>

and

<30-seconds-of-silence/> U.......M.......L <cheering-of-the-multitudes/>

------>Aside. You'll probably enjoy reading Eric Evan's book "Domain Driven Design". He takes a very pragmatic view of the "real world modeling" issue, and provides lots of very good advice about it. <------

(Sigh) the hype associated with OO, and the religious zeal with which it can be (badly) practiced is sometimes disheartening. OO is a very nice tool for structuring source code and managing dependencies. And, yes, it is a good idea (as it has always been) to incorporate the vocabulary and relationships of the problem domain into the design of the source code. However, when people make software related decisions based solely upon whether or not the object properly models the real world, they need to find some other career -- because they sure aren't software developers.

Charles Bell

Posts: 519
Nickname: charles
Registered: Feb, 2002

Re: Modelling the real world.

Posted: Mar 9, 2004 6:09 AM

Reply

Great article Robert.

In the simulation world, its called "Real Time Programming" and the code is referred to as modeling of "First Principles".

If its physics which is basically "real world" math, I think it fits. Much of physics is modeling of physical processes. Maybe I should change that to abstract world math.

Hey, its spelled "modeling" according to Microsoft Word? I honestly can't tell which one is right. I keep trying to spell it with two lls.

Javid Jamae

Posts: 16
Nickname: javidjamae
Registered: Jan, 2003

Re: Modelling the real world.

Posted: Mar 9, 2004 7:34 AM

Reply

Modelling and Modeling both appear in multiple dictionaries. I would assume both are acceptable.

http://www.onelook.com/?w=Modeling+&ls=a
http://www.onelook.com/?w=Modelling+&ls=a

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Modelling the real world.

Posted: Mar 9, 2004 1:55 PM

Reply

It's true that we want the vocabulary and relationships of the problem domain represented in our objects and methods. But that's not the same as "modeling the real world".

What in your view is the difference between encoding those relationships and modelling the problem domain?

OO was "discovered" when two guys who were using a block structured language to write a simulation engine played around with moving the stack frame for a block to the heap, thus making the blocks long-lived.

Those two guys being Ole-Johan Dahl & Kristen Nygaard.

Ole-Johan Dahl has written about:
"The Birth of Object Orientation: the Simula Languages"
http://heim.ifi.uio.no/~olejohan/birth-of-oo.pdf

Kristen Nygaard, in his ECOOP 2002 Banquet Speech, seems to be saying that OOP is about understanding, describing and representing a system (domain) on a computer. Isn't that modelling?

"In object-oriented programming the programs are not organised in a single sequence. Instead, an object is created for each individual component of the traffic system, the production system, the organisation system: Cars, aircraft, machines, operators, metal parts to be processed, offices, documents all are represented in the computer as objects.

Each object is described by 1) the set of data associated with it: Speeds of aircraft, weight of metal parts, addresses of documents, etc.,2) then the descriptions of actions the object is carrying out: traffic lights changing colour in a well-defined sequence, machines working on metal parts selected from a queue, and 3 finally also the interactions with other objects: a controller's office inspecting invoices and sending messages about payment authorising to the appropriate other offices, and so on.

In this way a system, including information systems, may be understood, described and represented by a collection of objects in a computer, each object acting and/or is acted upon through the carrying out of the parallel object-related computing sequences."

( Simula history, for the curious:
"COMPILING SIMULA" Jan Rune Holmevik
http://www.ifi.uio.no/~cim/sim_history.html )

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Modelling the real world.

Posted: Mar 9, 2004 3:17 PM

Reply

> What in your view is the difference between encoding those
> relationships and modelling the problem domain?

The point of the article, in case you missed it, was the last sentence.

I don't think there's any difference between the two concepts. However, I think much harm has been done in the name of building models. Building models is not a bad thing. Building models instead of software is. Ignoring good software structure for the sake of building a model is.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Modelling the real world.

Posted: Mar 9, 2004 5:03 PM

Reply

The point of the article, in case you missed it, was the last sentence
Sometimes I do have difficult finding the point of an article amid the rhetoric :-(

I don't think there's any difference between the two concepts
So "we want the vocabulary and relationships of the problem domain represented in our objects and methods" and that is the same as "modeling the real world".
Well OK.

Building models is not a bad thing. Building models instead of software is. Ignoring good software structure for the sake of building a model is
Ignoring model validity would be worse - the beautifully structured software wouldn't do the right thing. Or to rephrase the point - when people make software related decisions based solely upon whether or not the software has good structure...

Maybe it's a question of balance.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Modelling the real world.

Posted: Mar 9, 2004 5:38 PM

Reply

I have a different take on how we got here. I fell the real world thing "hook, line and sinker" in the early days and it seemed to me that the idea was really popularized by the people with database and AI backgrounds. I suspect that many of them thought "hey, these OO languages look like they allow programmers to do what we do with ER diagrams and domain ontologies." I know some pressure came from that direction. No doubt it was a confluence of many things.

It is hard to get this concept across to new programmers, that we aren't modeling the real world but we use vocabulary from the world. One good example is a payroll application. In one factoring, it makes sense that an Employee class calculates the employee's pay. In software, it can be a good place for that responsibility even though it might be hard to find a real world company where all employees calculate their own pay. ;-)

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Modelling the real world.

Posted: Mar 9, 2004 7:57 PM

Reply

> Maybe it's a question of balance.

Most certainly!

Alexander Jerusalem

Posts: 36
Nickname: ajeru
Registered: Mar, 2003

Re: Modelling the real world.

Posted: Mar 10, 2004 9:01 AM

Reply

My problem with the "modelling the real world" phrase has always been that, more often than not, creating software feels like _creating_ a world that wasn't there before. In contrast, simulation is all about making a machine do what some existing system already does or would do under certain conditions.

In most analysis sessions I had with clients or colleagues, we were thinking more about how things should be than how they actually were. Of course, there are always existing facts and concepts you have to deal with, but it'd be wrong to look at software development as a process of discovering the nature of "real" things.

I would be much more comfortable with "modelling _a_ real world".

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Modelling the real world.

Posted: Mar 10, 2004 10:28 AM

Reply

Modeling the world is for wimps. In the late 80's, in addition to my day job, I took a night job at a company that made a grandiose Computer Aided Engineering application ("the largest Smalltalk application in existence"). Needing a significant engineering problem to put this application through its paces, a couple of us decided to model the entire universe. Of course, we didn't get too far, when talks broke down on whether the basemost object should be object or string.

Frank Mitchell

Posts: 37
Nickname: fmitchell
Registered: Jan, 2003

Re: Modelling the real world.

Posted: Mar 10, 2004 11:14 AM

Reply

> My problem with the "modelling the real world" phrase has
> always been that, more often than not, creating software
> feels like _creating_ a world that wasn't there before. In
> contrast, simulation is all about making a machine do what
> some existing system already does or would do under
> certain conditions.

A lot of software written today uses the real world as metaphor for fundamentally computer-centric processes (word-processing, message routing, etc.). The "models", if any, are simple caricatures of the real world. Among younger programmers, OO is a thing unto itself; "modeling the real world" has given way to hacking out "an object" to wrap this or that functionality. PHB take the modelling metaphor too literally, but in a strange way, it's as much a shame that so programmers ignore the "modelling" metaphor completely.

I suspect too many people forget that a model is an *abstraction* of the real world. A styrofoam model plane can't fly or carry passengers, but it tells an engineer about the flight characteristics of the eventual real plane. A model of the solar system substitutes fixed rods and gears for gravity in a 3D space, but it can still predict -- within certain limits -- the motion of real planets.

Instead of "model(l)ing" the world" (old style) or hacking out objects (new style), successful analysts and designers first understand the problem, and concentrate on shaping the software into a toy that provides insight into a far more complex process. Objects and classes *sometimes* make toy-building easier, but not always.

Alexander Jerusalem

Posts: 36
Nickname: ajeru
Registered: Mar, 2003

Re: Modelling the real world.

Posted: Mar 10, 2004 12:09 PM

Reply

> > My problem with the "modelling the real world" phrase
> has
> > always been that, more often than not, creating
> software
> > feels like _creating_ a world that wasn't there before.
> In
> > contrast, simulation is all about making a machine do
> what
> > some existing system already does or would do under
> > certain conditions.
>
> I suspect too many people forget that a model is an
> *abstraction* of the real world. A styrofoam model plane
> can't fly or carry passengers, but it tells an engineer
> about the flight characteristics of the eventual real
> plane. A model of the solar system substitutes fixed rods
> and gears for gravity in a 3D space, but it can still
> predict -- within certain limits -- the motion of real
> planets.

Your examples show precisely the problem I mean. You come up with examples from the physical world and for a good reason because for all other things, this whole notion of modelling or abstracting from the real world simply fails. What is the real world object that amazon's patented one-click order is modelled upon? What do we abstract from when we create a BankLoan class? The notion of abstraction as a process of selecting features of an object that are important in a particular context and leaving away other features that are not important, makes an implicit assumption that there _is_ an object with features in the first place and that these features can be discovered. But there are no natural BankLoan objects that we could look at and whose behaviour we could observe. Yes banks already have products called loans and we could look at them as an example for our class. But they are not modelled upon some original natural object, they are creations that reflect the bank's idea of what they can sell to their customers.

So when we create a new BankLoan class for a different bank, we do not search for a better abstraction of _the_ real natural BankLoan object. What we (or rather the bank managers) do is think about what a more attractive loan _should_ look like. We invent features, we don't discover or selct them. And that's what I think is not well represented in the phrase "modelling the real world".

Alexander Jerusalem

Posts: 36
Nickname: ajeru
Registered: Mar, 2003

Re: Modelling the real world.

Posted: Mar 10, 2004 12:23 PM

Reply

> Modeling the world is for wimps. In the late 80's, in
> addition to my day job, I took a night job at a company
> that made a grandiose Computer Aided Engineering
> application ("the largest Smalltalk application in
> existence"). Needing a significant engineering problem to
> put this application through its paces, a couple of us
> decided to model the entire universe. Of course,
> we didn't get too far, when talks broke down on whether
> the basemost object should be object or
> string.

Well, Aristotel failed at this task a rather longish time before the 80's and everyone should have known by then that single rooted, single inheritance taxonomies just don't work ;-)

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Modelling the real world.

Posted: Mar 10, 2004 12:29 PM

Reply

> ...So when we create a new BankLoan class for a different
> bank, we do not search for a better abstraction of _the_
> real natural BankLoan object. What we (or rather the bank
> managers) do is think about what a more attractive loan
> _should_ look like. We invent features, we don't discover
> or selct them. And that's what I think is not well
> represented in the phrase "modelling the real world".

Well put. Reminds me of feelings I had when I first began to learn OOP and C++. There are many cases where concepts get wrapped into objects for which there is no real world counterpart. Collections are a common example of this phenomenon. I've never seen a HashTable in real life (but then, I'm not a drug dealer!). In general, it seems that things exist in the real world, but are not in collections.

If you go to far in the OOP direction, you find yourself wrapping objects around things that are really not objects, but processes. Processes are just as common, if not more common, than things (objects) are in the real world.

Some languages, like Java and C#, require you to define a class (of objects) as the first act of creating a program. Depending upon your point of view, this can be good because it encourages OO-thinking from the outset (which is, of course, immediately circumvented by students who crank out one huge static main() function; see the Java Answers Forum at http://www.artima.com/forums/forum.jsp?forum=1 for examples), or bad, because it often forces you to create some artificial "application" class.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Modelling the real world.

Posted: Mar 10, 2004 12:41 PM

Reply

> If you go to far in the OOP direction, you find yourself
> wrapping objects around things that are really not
> objects, but processes. Processes are just
> as common, if not more common, than things (objects) are
> in the real world.

Which may not be bad. The Command pattern uses objects for processes, and that's fine.

Flat View: This topic has 31 replies on 3 pages [ 1 2 3 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use