Very Computer

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.

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.

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.

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.

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

: 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

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:}

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.

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.

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.

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

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:}

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.

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

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.

[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.

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.

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.

Bert

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

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

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.

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.

Martijn

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).

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.

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.

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!

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:> 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?

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

: >> 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

Quote:>does

: > 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.

:
: > 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

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.

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.

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.

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.

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.

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.

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

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

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

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.

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

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?

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?

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.

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

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