How OO can A be? / let's actually do this interplanetary stuff

How OO can A be? / let's actually do this interplanetary stuff

Post by Martijn Meijerin » Sat, 27 Dec 1997 04:00:00



Nick Leaton wrote in reply to Martijn Meijering:

Quote:> > This is all very nice, but it is not very significant. The real problem
> > is modelling the movement of all these bodies, for which we need
> > classical mechanics and differential equations. This is the hard part.

> But it is hard in OO, and in any other area.

I did not mean to suggest that we should not use OO for this problem. If
I were to write a program for interplanetary navigation I would
certainly want to use OO methods. My point is that for this application
domain analysis is extremely important. I think that OO Analysis does
not have a lot to contribute to this. I fully expect OO Design and OO
programming to be  useful for this application.

Quote:> However, you do have to be
> careful. Do you want to solve the problem the same way that you would
> try and solve the problem on paper? No always. In this case I would
> think that a simulation using Eulers method would be the solution to try
> first.

I certainly would not try to solve it on paper. Except for very special
cases, you can't give an elementary expression for the solution. We
would have to apply numerical methods. Euler's method is probably not
the right one. It is notorious for its numerical instability. There are
far more complicated methods. Numerical mathematics is a very
sophisticated discipline...

Quote:>Then there would be more behaviour in celestial body. Solar
> system iterates all the bodies for each body in turn. Then you update
> the forces on that body, and for a small step update its position. After
> all there is no N-body solution. The converse is also true. The computer
> solution can be much more complex that the mathematical solution.

This sounds reasonable, but I think we are now already concerned with
*software*. I'd like to separate the physical and mathematical
considerations from the software engineering considerations. I'd call
the physical considerations domain analysis. I don't consider OO methods
very useful at this point. I don't expect physicists and astronomers to
adopt OO techniques any time soon.

Perhaps we should also call the mathematical considerations domain
analysis. But we are already moving in the direction of software here.
We might be studying numerical methods for solving the differential
equations, shooting methods, numerical stability etc.

At this stage OO methods are still not very useful.

Quote:

> > RANT

> > I think domain analysis should be about clearly and carefully defining
> > relevant concepts and reasoning about them. In other words it should be
> > *mathematical modelling*. There are lots of useful concepts from
> > mathematics and logic (sets, functions, relationships, products etc)
> > that we can use and I remain unconvinced that OO has much to add to
> > this, especially where it concerns continuous phenomena.

> At the end of the day, this isn't the problem. The fundamental
> difficulty is to get the users (or yourself) to express what is needed
> in a clear, unabiguous way. The assumptions need to be stated clearly.

This is indeed one of the problems, but I would not consider it the
(only) fundamental difficulty. There are a couple of fundamental
difficulties. Stating precise requirements is hard. Tracing requirements
to implementation requires effort. Making your design maintainable is
hard. Planning is hard. For some applications analysis is hard and can
require mathematical methods.

I think that for interplanetary navigation modeling the problem domain
(its physics and mathematics) is the most difficult part. OTOH, for most
business applications I think stating the requirements may be a more
important concern.

CONSIDER YOURSELF INVITED!

A while back someone suggested that we do a project together in order to
test our theories and find out if our disagreements were really
substantial or mainly the result of different terminology. It never got
off the ground.

I've been toying with the idea of developing a program for
interplanetary navigation. It looks like a lot of fun. We'd actually be
doing rocket science! I think it would make a good case study because it
would require a great deal of analysis. Anyone interested in joining me?

Martijn

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by El » Sun, 28 Dec 1997 04:00:00


: Nick Leaton wrote in reply to Martijn Meijering:
: > > This is all very nice, but it is not very significant. The real problem
: > > is modelling the movement of all these bodies, for which we need
: > > classical mechanics and differential equations. This is the hard part.

: > But it is hard in OO, and in any other area.

: I did not mean to suggest that we should not use OO for this problem. If
: I were to write a program for interplanetary navigation I would
: certainly want to use OO methods. My point is that for this application
: domain analysis is extremely important. I think that OO Analysis does
: not have a lot to contribute to this.

But you couldn't see heat/heat flow as an object.  Perhaps if you could
you might find OOA generally to be an effective means of understanding and
modelling the world.

: I fully expect OO Design and OO
: programming to be  useful for this application.

While a domain can be modelled any number of ways, if you are going to use
OOD and OOP, it seems like OOA would in most cases be better choice for
modelling domain in most such cases.

What is the beef people have with OOA?  It's like OO is cool as long as I
don't have to see the world that way.  I think people are so accustomed to
not seeing the world as objects and polymorphism, it's very hard for them
to do so.  Plus OOA is a very broad minded way of seeing the world, and I
don't think everyone is ready for it.

Elliott
--
   Copyright 1997 Elliott. exclusive of others' writing. may be copied
        without permission in comp.* usenet and bitnet groups.
"The domain object model is the foundation of OOD."
"We should seek out proven optimal practices and use them."
See SW Modeller vs SW Pragmatist Central: http://www.access.digex.net/~ell

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Martijn Meijerin » Sun, 28 Dec 1997 04:00:00



>> If
>> : I were to write a program for interplanetary navigation I would
>> : certainly want to use OO methods. My point is that for this >application
>> : domain analysis is extremely important. I think that OO Analysis >does
>> : not have a lot to contribute to this.

> But you couldn't see heat/heat flow as an object.  Perhaps if you could
> you might find OOA generally to be an effective means of understanding and
> modelling the world.

You said something about units of heat like a btu possibly being
relevant. What's a btu? (English is not my native language).

Anyway, I *can* think of heat or the flow of heat as an object. I just
don't see how thinking of it in terms of an interface and an
implementation, with attributes and (especially) methods is going to
help me in analysis. But perhaps this is not what you mean.

There are lots of concepts that could conceivably *evolve* into classes
in my code: the flow of heat, the distribution of heat, the conductivity
of the material, the laws of physics that govern the flow of heat etc.
And a number of them should.

I strongly believe that we should capture the vocabulary of our problem
in the classes of our programs. Classes should represent concepts.
Definitely.

When I'm writing code I'm often struck by the beauty of the OO way of
saying things. In the programming class I help teach the students are
programming a small simulation of our university cafetaria. I can see
obvious classes here: bread, cheese, plates, people, queues etc. If the
stack of clean plates is empty we should do the dishes and put the clean
plates back onto the stack. Easy, just say it:

CafetariaEmployee:DoWork()
{
  if (stack_of_plates.Empty())
    for (Set<Plate>::Iterator i(dirty_dishes); !i.Finished(); i.Next())
    {
      i.Current().clean=true;  
      stack_of_plates.Push(i.Current());
      dirty_dishes.Remove(i.Current());
    }
  }

Quote:}

I think it is excellent if code reflects the real world this way. I want
as much of my code as possible to be this way.

Part of this comes from practical considerations. It makes your code
more natural and probably easier to understand. This must be a good
thing. It may make economic sense as well.

But quite apart from economic considerations, I also want this for
esthetic reasons. A while ago someone one comp.lang.c++.moderated said
he liked to write code that was like a sonnet. I share that feeling.
Esthetics has an important influence on my code. I want my code to be
"natural" and elegant even if it does not necessarily make economic
sense.

However, this is only a matter of taste. People can in all reason hold
different opinions. I would not want to force my style of programming on
anyone.

Perhaps it is only a difference in terminology, but I would not consider
using classes to capture domain vocabulary to be analysis. Or at best, I
would consider it to be only a part of analysis. To me analysis is much
more.

Quote:

> : I fully expect OO Design and OO
> : programming to be  useful for this application.

> While a domain can be modelled any number of ways, if you are going to use
> OOD and OOP, it seems like OOA would in most cases be better choice for
> modelling domain in most such cases.

Perhaps. But I don't see how OOA is going to help me do the physics and
mathematics.

There are a number of things we have to analyse:

1: the physics
2: the mathematics
3: the requirements

All these will have influence on the class model. But in and of
themselves they are not class modeling. If you call the process of
capturing the domain vocabulary as found by 1,2 and 3 OOA, then I'm in
favour of OOA (bien e'tonne' de se trouver ensemble!). Is this what you
mean?

I really believe that is is what Robert calls high level design. I know
you have expressed considerable, well let's say skepticism, about this,
but that's the way I see it.

To my mind we are then already dealing with software, albeit on a very
high level.

But if we agree on the importance of this something, whatever we call it
(OOA, Up, high level design, vocabulary, ontology), then I think we need
something else as well, namely the analysis proper (you might prefer a
different term) that led to the model.

Quote:> What is the beef people have with OOA?  It's like OO is cool as long as I
> don't have to see the world that way.

Yes, in a sense. But not because it is going to far. I actually think it
is not going far enough. I think we need to move beyond OO for analysis.
See below.

Quote:> I think people are so accustomed to
> not seeing the world as objects and polymorphism, it's very hard for them
> to do so.  Plus OOA is a very broad minded way of seeing the world, and I
> don't think everyone is ready for it.

It may very well be true that not everybody is ready for it.

As I said, my view is that OOA is actually not broad enough. Or perhaps
it is better to say that it is not deep enough.

Of course, in mathematics, you analyse things as objects with properties
and relationships. Because not all objects are created equal, you might
want to add types to this. Then you get typed logic. This is well known.
It can certainly be advantageous to add inheritance to this. All this is
fine. But it is still only the vocabulary of analysis.

We need to be able to make statements about these objects and reason
about them. We might want to identify certain axioms, constraints and
laws about these objects. I think that this is what is missing from OOA.
It gives us a vocabulary (similar to that used in traditonal logical,
but more elaborate) but we need a grammar as well. (For representing
knowledge, that is). To my mind this is at least half of analysis.

Of course, you could go meta on this and try to express axioms and
constraints as objects, but I don't think this is very practical from an
analytical point of view. It would be a good idea if you were designing
a computer algebra system, but not for actually doing the algebra.

BTW would you be interested in joining this interplanetary project.
After all, it was your example :-)

I think I'll post some analytical stuff next week.

Martijn

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Robert C. Marti » Sun, 28 Dec 1997 04:00:00



> When I'm writing code I'm often struck by the beauty of the OO way of
> saying things. In the programming class I help teach the students are
> programming a small simulation of our university cafetaria. I can see
> obvious classes here: bread, cheese, plates, people, queues etc. If the
> stack of clean plates is empty we should do the dishes and put the clean
> plates back onto the stack. Easy, just say it:

> CafetariaEmployee:DoWork()
> {
>   if (stack_of_plates.Empty())
>     for (Set<Plate>::Iterator i(dirty_dishes); !i.Finished(); i.Next())
>     {
>       i.Current().clean=true;
>       stack_of_plates.Push(i.Current());
>       dirty_dishes.Remove(i.Current());
>     }
>   }
> }

You have said that the OO way of saying things is beautiful.  Consider
this:

DoWork(CafeteriaEmployee& e)
{
  Stack* s = stack_of_plates[e.employee_id]; // get employee's stack.
  if (Empty(s))
  {
    int dirtyDish = 0;
    while (nDirtyDishes > 0)
    {
      Dish* d = dirtyDishes[dirtyDish++];
      Clean(d);
      nDirtyDishes--;
      cleanDishes[nCleanDishes++] = d;
    }
  }

Quote:}

There is a one to one correspondence between these two functions.
I have translated the containers and iterators into arrays and indexes;
but otherwise the algorithms are virtually identical.

Granted, we would expect polymorphism in your example, and we would
not expect it in mine (but it might still be there).  But the
beauty of expression is equivalent in both....  

****

It is easy to get e*d about the ability to tell an object to
do something.  i.e. d.Clean() seems somehow more elegant than
Clean(d).  But the two are equivalent forms.

Quote:> I think it is excellent if code reflects the real world this way.

But notice that this real world reflection had nothing to do with
OO.  The procedural version of the function expresses the real world
just as well as the OO version.

Indeed, this begs a question.  If the two are equivalent; then what
is it about the first version that is OO?  We cannot tell!  There is
no indication whether the first function uses any OO principles at all.
The reason is that we cannot see any polymorphism.  The only candidate
for polymorphism is the dish.  If there are different kinds of
dishes, and they are all cleaned in different ways, then this might
mean that the first algorithm used some OO principles.

--
**We are looking for good engineers, See our website
**for more information.

Robert C. Martin    | Design Consulting   | Training courses offered:

14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.veryComputer.com/  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Bert Bri » Sun, 28 Dec 1997 04:00:00



> CafetariaEmployee:DoWork()
> {
>   if (stack_of_plates.Empty())
>     for (Set<Plate>::Iterator i(dirty_dishes); !i.Finished(); i.Next())
>     {
>       i.Current().clean=true;  
>       stack_of_plates.Push(i.Current());
>       dirty_dishes.Remove(i.Current());
>     }
>   }
> }
> I think it is excellent if code reflects the real world this way. I want
> as much of my code as possible to be this way.

That may be a nice goal, but do you think this will hold in a large system? You
will find that a lot of the 'simple' mechanisms don't work anymore. Because of:
duplication of data, methods, pre-existing classes, concurrency, etc. etc. Mind
you, this is not just 'refinement'. Tasks that are in your code will be done by
other object, or the CafetariaEmployee will inherit a template method that does
the work, but quite differently, the worker will not check for emptyness, but
some generic TaskManager will, etc.

So, I can see the same requirements lead to unrecognizably different code spread
over many classes. Why the hell do we do that? Because there's much more than
the simple, current requirements. we need to be able to cope with complexity,
the future, performance, and so forth. I just cannot afford to design like this:
it would ignore the established architecture in the system. That architecture
was not chosen to be an obstacle to intuitive understanding. Of course not. That
is _also_ a design goal. But there's a whole series of design goals, each of
them more or less important in a certain context.

Nothing wrong with you teaching this example (a minor detail is that it is, in
fact, hardly object-oriented, more object-based). The fact is, however, that
there are a couple more levels of insight one must get before one can manage the
problems of large systems.

Quote:

> Part of this comes from practical considerations. It makes your code
> more natural and probably easier to understand. This must be a good
> thing. It may make economic sense as well.

> But quite apart from economic considerations, I also want this for
> esthetic reasons.

It does make economic sense, but it is a part of the story. Esthetic reasons can
be very satisfying, but are generally not affordable for a software engineer.

[snip]

Quote:> > I think people are so accustomed to
> > not seeing the world as objects and polymorphism, it's very hard for them
> > to do so.  Plus OOA is a very broad minded way of seeing the world, and I
> > don't think everyone is ready for it.

> It may very well be true that not everybody is ready for it.

It is a very unrespectful remark. Maybe I don't _want_ to see everything as
objects. Maybe I have rejected this one-sided view. Saying that someone is not
ready for something is almost always offensive. Don't get mixed up in Ell's
strategic statements!

Quote:

> As I said, my view is that OOA is actually not broad enough. Or perhaps
> it is better to say that it is not deep enough.

> Of course, in mathematics, you analyse things as objects with properties
> and relationships.

Are you sure all your collegues will agree to this statement?

Quote:> Because not all objects are created equal, you might
> want to add types to this. Then you get typed logic. This is well known.
> It can certainly be advantageous to add inheritance to this. All this is
> fine. But it is still only the vocabulary of analysis.

> We need to be able to make statements about these objects and reason
> about them. We might want to identify certain axioms, constraints and
> laws about these objects. I think that this is what is missing from OOA.
> It gives us a vocabulary (similar to that used in traditonal logical,
> but more elaborate) but we need a grammar as well. (For representing
> knowledge, that is). To my mind this is at least half of analysis.

Maybe you can place these remarks in the context of R. Martin's remarks on
Analysis and the OO-ness of it. What makes you think the above analysis
ingredients are OO-specific? Aren't there already loads of the above in other
contexts?

Bert

-- de Groot - Bril Earth Sciences B.V.
-- Boulevard 1945 - 24, 7511 AE Enschede, The Netherlands

-- Tel: +31 534315155 , Fax: +31 534315104

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Martijn Meijerin » Sun, 28 Dec 1997 04:00:00



> You have said that the OO way of saying things is beautiful.  Consider
> this:
> [snip ]
>But the
> beauty of expression is equivalent in both....

Absolutely true.

Quote:> It is easy to get e*d about the ability to tell an object to
> do something.  i.e. d.Clean() seems somehow more elegant than
> Clean(d).  But the two are equivalent forms.

Of course. I think this elegance is desirable but not fundamental. My
feeling is that Elliott has become infatuated with the elegance and
accords too much importance to it. For me, it is just a matter of style,
not of substance. Still, personally, I find style important.

Quote:> > I think it is excellent if code reflects the real world this way.

> But notice that this real world reflection had nothing to do with
> OO.  The procedural version of the function expresses the real world
> just as well as the OO version.

Yes. I should not have referred to this as the "OO way of saying
things". What I really mean is writing code that is as close to human
language as possible. This has a great deal of charm, but to me it is no
more than a matter of style. If we can have it without compromising
other goals, I'd like to have it.

Martijn

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Martijn Meijerin » Sun, 28 Dec 1997 04:00:00



> That may be a nice goal, but do you think this will hold in a large system?

Actually, I don't. But I think that I can understand how Elliott feels
about this. It is easy to get e*d about it. I have felt e*d
about it. But it doesn't scale, in my experience.

On a less ambitious scale, I think that we should express concepts as
classes. Perhaps, this is just another way of saying that we should use
good identifiers. A lot of these concepts will be *solution* domain
concepts. That doesn't mean we can't try to include the domain
vocabulary as well.

Quote:> Nothing wrong with you teaching this example (a minor detail is that it is, in
> fact, hardly object-oriented, more object-based).

Quite right. We'll do OO when we get to the SE course.

Quote:> The fact is, however, that
> there are a couple more levels of insight one must get before one can manage the
> problems of large systems.

I agree completely.

Quote:> It does make economic sense, but it is a part of the story. Esthetic reasons can
> be very satisfying, but are generally not affordable for a software > engineer.

Indeed. That is why I consider it a personal preference and a matter of
style. I was trying to find as much common ground with Elliott as I
could. I wanted to convince Elliott that I share his sentiment (as far
as I can tell of course, I can't look into his head) and I hope I have.
He finds it much more important than I do, but at least we have both
felt it.

Quote:> > It may very well be true that not everybody is ready for it.

> It is a very unrespectful remark. Maybe I don't _want_ to see everything as
> objects. Maybe I have rejected this one-sided view. Saying that someone is not
> ready for something is almost always offensive. Don't get mixed up in Ell's
> strategic statements!

It is not very respectful. Still, it might be true :-) I think there may
be lots of people who are not ready for it. But I also suspect that
Elliott had Robert and Tim in mind. In that case I think he is wrong.
Still, I don't want to get into a mud slinging contest with Elliott. I
think we are having a productive discussion right now and I want it to
stay that way.

Quote:> > As I said, my view is that OOA is actually not broad enough. Or perhaps
> > it is better to say that it is not deep enough.

> > Of course, in mathematics, you analyse things as objects with properties
> > and relationships.

> Are you sure all your collegues will agree to this statement?

I think so. But I there is nothings very "OO" about these objects. I
might as well have called them blobs.

Quote:> Maybe you can place these remarks in the context of R. Martin's remarks on
> Analysis and the OO-ness of it. What makes you think the above analysis
> ingredients are OO-specific? Aren't there already loads of the above in other
> contexts?

Typed logic certainly is not OO. As far as I know it existed long before
OO. You can add subtyping to this without too many problems I think.
This seems like a useful extension, but not a particularly revolutionary
one.

When I said that in mathematics we analyse things as objects with
properties and relationships I didn't mean to say anything deep.

But I'm trying to find common ground here. Elliott seems to think that
object modeling is a great technique for modelling almost anything. He
sees objects everywhere. Of course, I see these objects too. But to me,
they are not much more than the objects of mathematics. But I have
nothing against adding types and inheritance. I would seem to be a good
idea, but only a minor improvement. (On the other hand, if we were
developing a formalism for reasoning *about* OO programs, this may
become much more important.)

If this is OOA, I'm for it. So Elliott and I agree on this. Of course,
he believes it is *fundamental* and I don't. To me this means that we
don't have to be afraid that our discussions will stop anytime soon.

Martijn

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Alicia Carla Longstree » Mon, 29 Dec 1997 04:00:00




: >> If
: >> : I were to write a program for interplanetary navigation I would
: >> : certainly want to use OO methods. My point is that for this

Quote:>application

: >> : domain analysis is extremely important. I think that OO Analysis
Quote:>does

: >> : not have a lot to contribute to this.

: > But you couldn't see heat/heat flow as an object.  Perhaps if you could
: > you might find OOA generally to be an effective means of understanding
and
: > modelling the world.

Heat flow is a process, but it always occurs between two objects.  If you
were developing a system to describe heat flow, OO Analysis and Design
could certainly apply.  Each class or object would reflect either a source
or sink for the heat flow.

: You said something about units of heat like a btu possibly being
: relevant. What's a btu? (English is not my native language).

British Thermal Unit.

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by El » Mon, 29 Dec 1997 04:00:00


:
: > CafetariaEmployee:DoWork()
: > {
: >   if (stack_of_plates.Empty())
: >     for (Set<Plate>::Iterator i(dirty_dishes); !i.Finished(); i.Next())
: >     {
: >       i.Current().clean=true;  
: >       stack_of_plates.Push(i.Current());
: >       dirty_dishes.Remove(i.Current());
: >     }
: >   }
: > }
: > I think it is excellent if code reflects the real world this way. I want
: > as much of my code as possible to be this way.

:That may be a nice goal, but do you think this will hold in a large system?

I've seen similar real world modelling code work successfully in a number
of large scale system code.  The code and systems were both Structured,
and OO.

:You
:will find that a lot of the 'simple' mechanisms don't work anymore. Because of
:duplication of data, methods, pre-existing classes, concurrency, etc. etc.

Are you calling the example code 'simple mechanisms'?  If so why?  And how
does "duplication of data, methods, pre-existing classes, concurrency,
etc.  etc." affect the issue?

:Mind
:you, this is not just 'refinement'. Tasks that are in your code will be done by
:other object, or the CafetariaEmployee will inherit a template method that does
:the work, but quite differently, the worker will not check for emptyness, but
:some generic TaskManager will, etc.

So how do these issues invalidate code which reflects domain entities?
You are naming things, but I don't see how they invalidate such code.

:So, I can see the same requirements lead to unrecognizably different code
:spread
:over many classes. Why the hell do we do that? Because there's much more than
:the simple, current requirements.

Because you logically model, or simulate the domain, *and* meet current
use cases, does not mean you can not, and are not designing for the
future. In fact basing the design on the domain model is probably the best
basis for future growth.

Change typically occurs more in system use cases versus key domain model
abstractions.  So a system that has low logical fidelity to the domain
model but is designed to meet current as well as future *anticipated* use
cases is more apt to actually miss the mark in the future than one that
has high logical fidelity to the domain model and as well is designed to
model current and future use cases.

:we need to be able to cope with complexity,
:the future, performance, and so forth.

Myself, and from reading, most others in traditional OO have not found
code based on domain models to be an impediment to "complexity, the
future, performance, and so forth".  On the contrary we generally find
such code to be the best basis for dealing with those issues.

:I just cannot afford to design like this:
:it would ignore the established architecture in the system.

Because an architecture is established, or template like, does not mean
it's antithetical to domain based code like the above.  Such architectures
are typically modified to express logical domain entities and
relationships.  Or those architectures are incorporated into larger more
domain specific architectures.

: > > I think people are so accustomed to
: > > not seeing the world as objects and polymorphism, it's very hard for them
: > > to do so.  Plus OOA is a very broad minded way of seeing the world, and I
: > > don't think everyone is ready for it.

: > It may very well be true that not everybody is ready for it.

: It is a very unrespectful remark. Maybe I don't _want_ to see everything as
: objects. Maybe I have rejected this one-sided view. Saying that someone is not
: ready for something is almost always offensive.

While you may have consciously rejected seeing the world in an OO manner,
there are others, like Martin, who can't see the world in an OO manner.
And there are others as I say, who find it troubling.

: Don't get mixed up in Ell's
: strategic statements!

What does that mean?  There's nothing strategic about it what I just said,
it's simply the facts.

: > Because not all objects are created equal, you might
: > want to add types to this. Then you get typed logic. This is well known.
: > It can certainly be advantageous to add inheritance to this. All this is
: > fine. But it is still only the vocabulary of analysis.
: >
: > We need to be able to make statements about these objects and reason
: > about them. We might want to identify certain axioms, constraints and
: > laws about these objects. I think that this is what is missing from OOA.

Please explain what kinds of axioms, constraints and laws you are talking
about.  Some things are analysis issues and others are design issues.

: > It gives us a vocabulary (similar to that used in traditonal logical,
: > but more elaborate) but we need a grammar as well. (For representing
: > knowledge, that is). To my mind this is at least half of analysis.

What do you mean we need to represent knowledge and how does a grammar
come into play with it?

: Maybe you can place these remarks in the context of R. Martin's remarks on
: Analysis and the OO-ness of it.

Or rather Martins's remarks on Analysis and his assertion that it does
not, or can not have OO-ness.  Which makes sense given that he doesn't see
OO in the real world.

Elliott
--
   Copyright 1997 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.
"The domain object model is the foundation of OOD."
"We should seek out proven optimal practices and use them."
See SW Modeller vs SW Pragmatist Central: http://www.access.digex.net/~ell

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Bert Bri » Mon, 29 Dec 1997 04:00:00





[:xxx is me ...]
> :You
> :will find that a lot of the 'simple' mechanisms don't work anymore. Because of
> :duplication of data, methods, pre-existing classes, concurrency, etc. etc.

> Are you calling the example code 'simple mechanisms'?  If so why?  And how
> does "duplication of data, methods, pre-existing classes, concurrency,
> etc.  etc." affect the issue?

Yes. Because they are not influenced by the environment that any large project
will have. In such an environment things are more difficult mainly (but not
only) because otherwise maintenance would become virtually impossible.
Duplication is a common problem that has to be tackled. For example the choice
to wash the dishes in all the Employee classes may be more maintainably put in a
TaskManager class. This reduces 'intuitive' simplicity but enhances another
design goal.

Quote:

> :Mind
> :you, this is not just 'refinement'. Tasks that are in your code will be done by
> :other object, or the CafetariaEmployee will inherit a template method that does
> :the work, but quite differently, the worker will not check for emptyness, but
> :some generic TaskManager will, etc.

> So how do these issues invalidate code which reflects domain entities?
> You are naming things, but I don't see how they invalidate such code.

The simple example shows that the TaskManager takes the checking of the plates
out of the hands of the Employee object. In the domain, the employee does it, in
the software solutions this may be very unwanted. I cannot believe you are
unable to think up many, many of these mechanisms yourself.

Quote:

> :So, I can see the same requirements lead to unrecognizably different code
> :spread
> :over many classes. Why the hell do we do that? Because there's much more than
> :the simple, current requirements.

> Because you logically model, or simulate the domain, *and* meet current
> use cases, does not mean you can not, and are not designing for the
> future. In fact basing the design on the domain model is probably the best
> basis for future growth.

1) _The_ domain model. Which one?
2) Why would that be so? Why would the TaskManager be inferior?

BTW, one of your assumptions seems to be that we can never do better than 'the
real world'. But one of the nice things of software is that it much more
flexible than 'the real world'. And I want to take advantage of that fact.

Quote:

> Change typically occurs more in system use cases versus key domain model
> abstractions.  So a system that has low logical fidelity to the domain
> model but is designed to meet current as well as future *anticipated* use
> cases is more apt to actually miss the mark in the future than one that
> has high logical fidelity to the domain model and as well is designed to
> model current and future use cases.

We also want to protect our high-level logical design against unanticipated
changes, analysis errors, changing external constraints, inefficient structure,
and more. Have you ever thought about the possibility that other people want to
go _futher_ on the path of abstraction than you do?

Quote:

> :we need to be able to cope with complexity,
> :the future, performance, and so forth.

> Myself, and from reading, most others in traditional OO have not found
> code based on domain models to be an impediment to "complexity, the
> future, performance, and so forth".  On the contrary we generally find
> such code to be the best basis for dealing with those issues.

So your experience is different from mine. Have you ever thought about the
possiblity that there is a difference between highly administrative software and
more technical software? If the system is basically an interface to a database
things look a bit different than in R&D environments.

Quote:

> :I just cannot afford to design like this:
> :it would ignore the established architecture in the system.

> Because an architecture is established, or template like, does not mean
> it's antithetical to domain based code like the above.  Such architectures
> are typically modified to express logical domain entities and
> relationships.  Or those architectures are incorporated into larger more
> domain specific architectures.

As usual, leaving out relevant stuff for your convenience. Don't you like the
text?

> :That architecture
> :was not chosen to be an obstacle to intuitive understanding. Of course not. That
> :is _also_ a design goal. But there's a whole series of design goals, each of
> :them more or less important in a certain context.


> : > > I think people are so accustomed to
> : > > not seeing the world as objects and polymorphism, it's very hard for them
> : > > to do so.  Plus OOA is a very broad minded way of seeing the world, and I
> : > > don't think everyone is ready for it.

> : > It may very well be true that not everybody is ready for it.

> : It is a very unrespectful remark. Maybe I don't _want_ to see everything as
> : objects. Maybe I have rejected this one-sided view. Saying that someone is not
> : ready for something is almost always offensive.

> While you may have consciously rejected seeing the world in an OO manner,
> there are others, like Martin, who can't see the world in an OO manner.
> And there are others as I say, who find it troubling.

The point is that someone 'being not ready' can be said respectfully only in
hindsight. It insults people when the argument is still on - and there is a
chance of you being wrong. IMO, there is no excuse for using this type of
discussion techniques.

Quote:

> : Don't get mixed up in Ell's
> : strategic statements!

> What does that mean?  There's nothing strategic about it what I just said,
> it's simply the facts.

Saying that something under discussion 'is a fact' is another indicator that
there is something wrong. There is something wrong when you don't pick up the
signals from a lot of people in this group that your _methods_ of discussion are
not acceptable.

It very much seems like all your discussion arguments are strategic. You answer
only what can serve your goal and ignore questions that you can't use. That
looks like you are not really interested in finding out 'the truth', but that
you want to win discussions at any cost.

Bert

-- de Groot - Bril Earth Sciences B.V.
-- Boulevard 1945 - 24, 7511 AE Enschede, The Netherlands

-- Tel: +31 534315155 , Fax: +31 534315104

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Tim Ottinge » Tue, 30 Dec 1997 04:00:00



> What is the beef people have with OOA?  

Perhaps it's not the practice, but the name of the practice that
people question, or even refuse? Or maybe it's not even that,
but the way that the OOP terms are "punned" in OOA to mean something
subtly different (for instance, the way Actors "inherit") that
may cause the less savvy to translate the OOA directly into OOD
exactly as given?

Consider the current situation we have where we argue whether
your domain model is our high-level design. What are the criteria
by which to name it? If someone said it was one or the other in
the 60s or 70s, does that (should that) settle the question?

Say that your analysis does not result in something you can
simply extend into code. In that case it would clearly not
be a design. Consider what it would look like: would it
necessarily be OO, or does OO require that classes and inheritance
(directly codeable constructs) are used?

Say I take a model and it translates exactly, perfectly into
code. It seems to be a low-level, physical design, since it
considered everything I need to realize it on a computer. Is
it an analysis model? Could it be one?

Everything between is looking a little grey and fuzzy, too.
Of course, you can call it what you like, and state your reasons
for it, and have good ones in either direction. Many people have
stated that the only difference between analysis and design is
the intent of the author. In that case, anything used as a
design is a design model, and anything used as an analysis is
an analysis. In the case, code can be analysis and graphic models
can be design.

Try to find a few different perspectives. Try not to refuse any
unless it is because of clarity and usefulness, not out of dogma
alone.

This is a mental excercise that should be something a rationalist
would enjoy greatly. Treat it as such. See where it takes you
mentally.

The result should be a set of definitions that clarify,
edify, and which can be given consensus. I wouldn't mind
if they came from you or anyone else. I'd like to see the
fuzziness and greyness dispelled or at least explained in
a clear, lucid, teachable, reasoned way.
--
tim
+-----------------------------------------------------------+
| Tim Ottinger:      http://www.oma.com/ottinger            |
| Object Mentor:     http://www.oma.com        800-338-6716 |
+-----------------------------------------------------------+
|         Design, Consulting, Mentoring, Training           |
+-----------------------------------------------------------+
The important thing is to never stop questioning - A Einstein

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Tim Ottinge » Tue, 30 Dec 1997 04:00:00



> Because you logically model, or simulate the domain, *and* meet current
> use cases, does not mean you can not, and are not designing for the
> future. In fact basing the design on the domain model is probably the best
> basis for future growth.

This is true if:
1) The domain does not change
2) The domain changes will not affect the designs or code that exist
   For instance: Entities don't join or split, and responsibilities
   are never redistributed
3) Domain changes will be isolated in the internals of one or more
   methods.

Quote:> Change typically occurs more in system use cases versus key domain model
> abstractions.  

You qualify this heavily: *key*, and *abstractions* being right up
there.
I may agree with you, though I would consider these to be high-level
design entities. While I know what I would mean by key, I don't know
what you mean when you use the word. I suspect some agreement, though.

Quote:> So a system that has low logical fidelity to the domain model but is
> designed to meet current as well as future *anticipated* use cases is
> more apt to actually miss the mark in the future than one that
> has high logical fidelity to the domain model and as well is designed to
> model current and future use cases.

Hmmm.. both are designed to meet current as well as future use cases,
which you say are the most common types of changes. So we've got some
very useful levels of abstraction/decoupling going on here, right? There
is clearly a positive note in there.

Then the concern here has to do with "mark missing" and "logical
fidelity".

Can we shake hands on the agreements we've had so far and press on to
discussion of mark-missing, and logical fidelity? I would love this.
It would be a dramatic narrowing of the topic.

--
Tim
+-----------------------------------------------------------+
| Tim Ottinger:      http://www.oma.com/ottinger            |
| Object Mentor:     http://www.oma.com        800-338-6716 |
+-----------------------------------------------------------+
|         Design, Consulting, Mentoring, Training           |
+-----------------------------------------------------------+
The important thing is to never stop questioning - A Einstein

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Michael Feather » Sun, 04 Jan 1998 04:00:00




Quote:> Consider the current situation we have where we argue whether
> your domain model is our high-level design. What are the criteria
> by which to name it? If someone said it was one or the other in
> the 60s or 70s, does that (should that) settle the question?

> Say that your analysis does not result in something you can
> simply extend into code. In that case it would clearly not
> be a design. Consider what it would look like: would it
> necessarily be OO, or does OO require that classes and inheritance
> (directly codeable constructs) are used?

It is nice that the UML recognizes that the term class
is more than a programming language construct.
A class is a description of a set of instances regardless
of whether they are software instances or real
world instances.  If they are software, we have
<<implementation class>> if they are real world
we have <<type>> but both are kinds of classes, i.e.,
subtypes of class in the metamodel.  This is the
reason why it works when Robert talks about
using <<entity>> on classes to do ERD.  When you
make an entity stereotype, you are saying Entity
is a kind of class.

The basis for OO is pervasive in western thought.
OO comes from the way that we are taught to organize
our perceptions.  The basis for object orientation is
Plato and Aristotle's classification theory.  Classes and
objects represent the type/instance dichotomy in that
metaphysics.  As such it has been the natural way of
viewing the world in western thought.  It underlies everything
from common speech "Mercedes is a kind of car" to
taxonomy and the Dewey Decimal system.

In the early part of this century, Wittgenstein challenged
the view of classification by common properties to use
the more cognitive notion of family resemblance.  This
was the foundation of the prototype theory of classification.
Only recently have software languages started working with
this.  Self and Kevo are examples of prototype programming
languages.

Inheritance is a programming language mechanism for
doing what is conceptually regarded as subtyping.  That
is: fuller differentiated description of a family of instances
in a domain.

Quote:> Say I take a model and it translates exactly, perfectly into
> code. It seems to be a low-level, physical design, since it
> considered everything I need to realize it on a computer. Is
> it an analysis model? Could it be one?

Yeah, it could.  The nice thing about models is that one
model can model more than one thing.  A model is an
abstraction of the essence of something.  A software
structure and a real world structure can share
the same essential abstractions.  Simulation thrives
on this.

Quote:> The result should be a set of definitions that clarify,
> edify, and which can be given consensus. I wouldn't mind
> if they came from you or anyone else. I'd like to see the
> fuzziness and greyness dispelled or at least explained in
> a clear, lucid, teachable, reasoned way.

Check out _Classes versus Prototypes: Some
Philosophical and Historical Observations_
by Antero Taivalsaari in the November/December
issue of JOOP last year.

I wouldn't want to get rid of that fuzziness and
and greyness.  It is really abstraction, our bread and
butter.

 
 
 

How OO can A be? / let's actually do this interplanetary stuff

Post by Tim Ottinge » Tue, 06 Jan 1998 04:00:00



> Because you logically model, or simulate the domain, *and* meet current
> use cases, does not mean you can not, and are not designing for the
> future. In fact basing the design on the domain model is probably the best
> basis for future growth.

I would like to see the study that suggested this. It would make a
good "experience" paper. Instead of restating that this is right and
all who disagree are accursed, how about showing how and why this is
right, and how it helps you to survive unforeseen changes in
requirements,
and how changes in technology won't apply, and how systems written for
one user will be usable for a completely different company, and how it
makes reuse more likely and easier.

I'd like to see some positive comments like these, rather than an
oblique
statements that its best,  and negative statements towards those who
disagree.

--
+-----------------------------------------------------------+
| Tim Ottinger:      http://www.oma.com/ottinger            |
| Object Mentor:     http://www.oma.com        800-338-6716 |
+-----------------------------------------------------------+
|         Design, Consulting, Mentoring, Training           |
+-----------------------------------------------------------+
The important thing is to never stop questioning - A Einstein

 
 
 

1. space stuff: progress so far (Was: let's actually do this interplanetary stuff)

[cross-posted to comp.object and the otug mailing-list]
Last week, I posted an invitation to join a toy project on
interplanetary navigation. The
goal of this proposed project was giving us something real to base our
discussions on.

So far, I've had positive responses from Robert Martin, Tim Ottinger and
Vikas Sahni. That
makes four of us. I hope some more people will follow if there is more
material to
react to. Until that happens I don't think we need a separate news group
:-).

If this project does come off the ground we may at some point need to
have some repository
of information. Perhaps we could use personal pages for that. Let's
worry about that if or
when it happens.

For the time being, I think we need to be able to easily identify the
postings related to
our project. Until someone comes up with a snazzier title I suggest the
prefix "space stuff:"
on the subject line.

Let's see what needs to be done. We need to work on (at least) the
following areas of
analysis:

- customer needs
We have a preliminary requirements document (the one I posted last
week).
I have edited it somewhat in the hope of making it a bit more useable.
I have made a preliminary list of use cases.
In order to clarify the problem we face I have made a model of the
"queries"
a user is going to make.

(Perhaps you feel the problem I proposed is too boring. We could perhaps
make this
into a system for intercepting (nuking) incoming asteroids. Perhaps you
have other
suggestions. We are not going to get very far if everybody finds the
problem too boring.)

- the physics involved
I'll post a few things on classical mechanics in the course of this
week, unless someone
beats me to it :-).

- mathematical algorithms for finding appropriate trajectories
I'll post something on the mathematics involved (shooting methods etc)
after
the classical mechanics stuff.

I have made a list of technical terms from the preliminary requirements
that
need further clarification.

I've entered the use cases and classes in Rose. For the time being the
project is small
enough to be useable with the demo version of Rose (freely available at
www.rational.com).

If you're interested in this stuff, but don't have access to Rose and
can't run the demo
(people working under Unix) please let me know.

Martijn

2. K?pes:Redovisa Direkt

3. difference between STUFF *stuff & STUFF stuff[]???

4. DOS Printing to HP855 under win95

5. Question: Explanation of 'oo framework' and 'oo environment' ?

6. Survey articles about neural nets

7. Classes, I am not sure what i am doing wrong!

8. WinRisc

9. USYNC_PROCESS - what's am I doing wrong

10. Disable 'close' button for NTVDM dos box running DOS app

11. difference between Java(also Smalltalk)'s OO and C++'s OO

12. Is Windows DOS-based and how does it handle 'DOS-Boxes'???

13. What is "DoEvents" actually doing?