Re: Objects and Relations

On Feb 8, 7:23 pm, "David BL" <davi..._at_iinet.net.au> wrote:
> On Feb 8, 11:43 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
>
>
>
> > On Feb 8, 4:25 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
> > > On Feb 8, 1:04 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
>
> > > > On Feb 7, 8:12 pm, "David BL" <davi..._at_iinet.net.au> wrote:
> > > > <snip>
>
> > > > > The semantics of Clone at the problem domain level is generally
> > > > > unambiguous except in its scope (in the sense of has-a relationships
> > > > > to other objects). It always means making a copy of the object such
> > > > > that it has the same attributes but a different identity. This makes
> > > > > sense for a class named EmployeeModel, but not for a class named
> > > > > Employee.
> > > > <snip>
> > > > > The idea that you look at entities (let's just call them nouns if you
> > > > > like) and ask whether they are part of the abstract machine is simple
> > > > > yet important because it neatly explains, without meta-physical mumbo
> > > > > jumbo the non-overlapping difference in scope of RM and OO.
>
> > > > When I have worked with architects who have prepared models as
> > > > blueprints and they point to their model of a doorway, they call it a
> > > > doorway. They similarly use the terms "room" and "wall." There is no
> > > > confusion at all. I understand they are pointing to a model of a room
> > > > and calling it a room. Similarly with software. There is absolutely
> > > > no reason whatsoever not to name the components of your model after
> > > > that which they are modeling.
>
> > > Note firstly that you have only provided a metaphor with your
> > > architecture blue prints example. An (OO) object by definition
> > > encapsulates state, behaviour and identity. All three must be
> > > directly associated with the instance in memory. OO is fundamentally
> > > about building a machine, not a model of something else. The state,
> > > behaviour and identity must all be understood on that basis.
>
> > One could say the very same thing about a 3-D model of a building, one
> > that has doors that open, for example. Sure a doll house needs to be
> > a working, functioning "machine" (if you will) but it is still a model
> > of a house. Models have their own identity, but for a model of an
> > existing building, there is also a mapping to that which it is
> > modeling, even if only in the minds of those viewing it. Models do
> > not include everything about that which they model (or they become
> > clones). It is really very important, I think, to understand that a
> > shopping cart on a web site is a model for a shopping cart in a store
> > and that a ShoppingCart class in the software is also a model of that
> > shopping cart.
>
> > > If you were to build a *simulation* (not merely a model)
>
> > simulations are one type of model
>
> All the above comes down to definition.

I would typically agree with a statement like that, but in this case I think that unless you are using a dictionary you wrote yourself, it is a fact and not an opinion that simulations are one type of model, photographs are another, etc.

> Your usage of "model" is
> different to mine. I restrict it to the narrow sense

I wish you wouldn't.

> of the
> representation of knowledge (in the form of attributes and
> relationships) about external entities. I define "simulation" to be
> about creating a working machine that happens to *mimic* reality with
> no intention of storing knowledge about external entities. Are you
> saying such a distinction doesn't exist?

Simulations are a type of model with "moving parts" and a time dimension. Not to nitpick, but simulations do not have intentions, people do and with simulations they intend to mimic some aspects of reality, but need not intend to mimic all aspects. This is true of all models, including words, pictures, and logical data models--they model some aspects of reality, but not all. Simulations can surely be built to include data stores, if that is what you mean by "storing knowledge about external entities." I will agree that a simulation is a model of a different type than a UML diagram or a logical data model, for example (where we often care about only a single point in time), but fail to see the relevance.

> If so then we disagree. If
> it is merely over what the words "model" and "simulation" mean there
> is nothing interesting to discuss.
>
> I obviously can't prove that OO can't be used for modeling (using my
> sense of the term). I can only say it is not what OO is for.

OO is for developing software, including modeling data. It can be used to model data that is stored in memory or on a secondary storage device. So, we can discuss the pros and cons of modeling data with a relational data model or an OO data model (or others).

> > > using OO then
> > > it would be fair and reasonable to use real world names for the
> > > classes. For example a class called "car" may make sense in the scope
> > > of the simulation. The identity of a car, its state and its behaviour
> > > are all associated with an entity within the abstract machine. For
> > > example, change the accelerator position and the car in the simulation
> > > accelerates. If you like, take this as a definition of what
> > > "simulation" (as distinct from "model") means.
>
> > OK, you are able to see that something is a model when it very closely
> > resembles that which it models.
>
> Hang on I just said that the above car is *not* to be defined as a
> model. It is a simulation.

Sorry, but a simulation is simply one type of model. If you can find a full formal definition of "simulation" and "model" where a simulation is not a model, I'd be interested in seeing those.

> Please accept my usage of the words for
> the sake of discussing the underlying ideas.

I would much prefer you choose a different word for the type of model you are referring to when you write "model." Perhaps your distinction is related to whether there is a time dimension to the model, but I'm not sure if that is your point or not.

> > Now abstract it a bit. A model can
> > be very unlike a clone, perhaps with a focus on modeling only one
> > aspect of that which it is modeling. Models are like metaphors. They
> > capture some aspects, but not all.
>
> Yes, with your liberal use of the word "model" (which encompasses
> architecture blue prints, doll houses, RM and OO).

Ah, thanks for coming around on that.

> > > A (data) model by contrast is all about representing knowledge (in the
> > > form of attributes and relationships) about entities outside the
> > > abstract machine.
>
> > Physical data models might be about the shape of data on secondary
> > storage devices, but a logical data model has to do with the
> > interactions within software. It has to do with every point at which
> > a language (or UI, service...) interacts with a tool that can put and
> > get such data. Think of it as an abstract computer language that must
> > be instantiated (for example, as SQL) and then used. We use data
> > models. We use them in software, even if we do not care how the bits
> > are laid out on disk for storage.
>
> So?
>
> > > That is not what OO is intended for, and never
> > > was. The programmers who think that OO is suitable for building
> > > models should study the RM because it is far better suited for that
> > > purpose.
>
> > OO is quite capable of modeling data, as is the RM. These are two
> > different models. You are giving no proof that the RM is better
> > suited for modeling data, even if such data finds its way to a
> > secondary storage device.
>
> Have you used OO for systems programming?

Only for application programming.

> One has a very clear focus
> on using objects that encapsulate state, behavior and identity to
> create a working machine. I doubt whether you would find a systems
> programmer that refers to the creations as "models".

And yet the code surely is, right? It is a specification ("the best spec is the code"). Neither the Stack class, nor the myStack = new Stack(); object are stacks.

> There is no
> interest in representing knowledge about external entities.

I understand that systems programming is not the same as data processing, but am not sure I understand "external entity." If I am understanding correctly, the fact that your modeling (in this case coding) of a myStack object and related code can be compiled and run in a jvm so that an actual stack is instantiated, thereby creating an nifty link between the model and the instance (reality) makes the use of the term "Stack" in your model a good name. I will grant that there is a difference between the Stack model and an Employee class with an object myEmployee as there is no process that turns myEmployee into an actual employee.

Despite there being this distinct difference between these two, they are both models. It makes sense within a model to label the parts like those they are modeling.

> Contrast this with someone building a business application and they
> say to themselves "I need to represent all the employees in the
> company". Do you see the difference?

Yes.

> The abstract machine is
> irrelevant; instead the focus is on representation of knowledge about
> external entities.

In either case, the entities are external to the model, but in the one there is a way we can transform from one to the other.

> There is plenty of evidence to show that OO works very well for
> systems programming, and plenty of evidence that it is inferior to RM
> for representing knowledge about external entities.

I don't use either, but have used both. There are pros and cons. If I'm going to persist data in a JavaSpace, I'd prefer to model that data with OO, for example, but if I want to do set-based queries, I'm not about to figure out OQL or whatever else there is for doing such queries--again, pros and cons to different models.

> I agree there is no formal proof.
>
> > > Typically a model only represents partial information about the
> > > entities and there is an intention to keep the model in sync with the
> > > external entities.
>
> > There might be intention in the minds of users to keep the accounting
> > information in line with the "real world" for example, but there is no
> > automated means of aligning data about a person, for example, with any
> > computerized model.
>
> > > There is no intention to think of the model as a
> > > machine or even a simulation.
>
> > The model is a model, it need not be a machine. There are many kinds
> > of models. Please see if you can grasp this.
>
> Yes, with your liberal use of the word "model".

Good, I trust I am also catching on to your point, even if still disagreeing with it.

> > > It is to represent knowledge.
>
> > To model it, in fact.
>
> Your argument is based on trying to be unspecific.

Specifically, I can model the proposition "Jane Doe is married and has e-mail addresses of jdoe_at_aol.com and jane_doe_at_gmail.com" in many ways, including use of RM, OO, XML, Nelson-Pick, or other data modeling approaches.

> > > It is precisely when OO is misused that the semantic lie appears in
> > > the names of the classes.
>
> > If I see a model of a building, I still call the walls "walls." Do
> > you understand what a model is? A photograph is a model, as is a
> > drawing of an owl by a 1st grader. These are not machines and need
> > not be machines.
>
> You are merely defending your liberal use of the word "model".

Oddly, I feel more need to teach it than defend it right now.

> > > Therefore the ugly names represent a non-
> > > problem and are better regarded as a symptom of the misuse of OO.
>
> > I really hope you can get beyond this misconception.
> > > > As for the scope of RM and OO, there is obviously an overlapping
> > > > scope. The question is not whether one can persist data using one
> > > > model for the data or another, but what the pros and cons are for
> > > > using either or using some other model. Given a typical software
> > > > application, one could choose to use an OO model, a multivalued model
> > > > (Nelson-Pick model), a relational model, or a codasyl model, for
> > > > example, for the development of this software application. I think
> > > > that shows some overlap in scope, don't you? --dawn
>
> > > I regard an "OO model" as a contradiction. In that sense I can't see
> > > how it can overlap in scope with RM.
>
> > Again, you need to move beyond this. It really is inaccurate. There
> > are a lot of arguments out there for why the RM is "the only" possible
> > model we could use for a DBMS. They are all flawed, but no others I
> > have read have the holes in them that your argument does. Do some
> > reading about various types of models and I think you will see that
> > class Employee {...} is, indeed, a model of an employee. Best
> > wishes. --dawn-
>
> A class called Employee is a semantic lie. The word "Employee" is by
> definition a type of human, not a type of object. You want to resolve
> that problem by overloading the meaning of the word!

And the walls of a model of a building -- if we call those walls, is it this same type of "semantic lie"? Is it a semantic lie to call the owl in a picture an owl. Should we write on the picture "This is not an owl"?

> Imagine how many contradictions you'll get in mathematics if you
> overload definitions.

Certainly there can be difficulties if one confuses the model with the real thing. To this day I have never confused a software model for an employee with an actual employee, however, just as I do not confuse a picture of a pipe with a pipe.

> To be honest I'm surprised that members of a theory newsgroup would
> want to justify overloading the meaning of words (for the sake of
> brevity no less!!!!!!!!!) when the aim should be to properly
> understand what we're talking about.
>
> Overloading a word to mean different things causes confusion and
> limits your ability to reason.

What should we call a wall in a model of a building? Can you see that it would also be very confusing to give new names to the model components for each model?

> I note as well that most of your counterarguments are based on
> overloading the word "model".

I still contend that I am merely using it.

> One of the signs of progress is the
> development of more refined words and definitions. For example it is
> useful to understand the difference between speed, velocity, momentum
> and kinetic energy of a moving object.

Irrelevant. Yes, you are right that using the same terms to name components of a model can cause confusion, but it is still typically better to do so than not. I hope not to see an Employee class ever called EmployeeModel as that would simply be redundant. Surely I know that code or even the run-time object is not actually an employee. Convinced yet? --dawn Received on Fri Feb 09 2007 - 05:33:30 CET