Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Dong Oh Kim]

Hello~
First of all, thank you for your reading this article.

I'm preparing for a paper associated with object-oriented modelling
approach and now investigating the current state of OOA & OOD, and CASE
tools...

There're two sides about this topic. 
That is...some people told me, "It's good now...I can develop a program
with 'xxx' oo method and its CASE tool". But others, "OO methods needed
more supplement...And still I can't believe CASE tools "

Let me have your opinions about followings:

 1. Is everything OK with existing oo development methods?
    If not, what are needed? and what stage should be enforced in the  
    future,i.e,analysis or design,etc...?

 2. Are you using a specific CASE tool?
    If so, what are main advantages and disadvantages?

 3. Did you have any experience of developing s/w systems by specific
    OO method? If so, could you do with ease?

 4. What's really needed to an engineer,who is not accustomed to OOP, to
    develop a software by OO paradigm??

Your opinion will help many people engaged in this area and better
software development environment...

Thanks in advance...


PS. "I'll send my paper all of you when completed with great pleasure.."
-- 
Dongoh Kim
Graduate student
K-JIST

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Paul_Gover]

In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim <kdo@kyebek3.kjist.ac.kr> writes:
> ...
>Let me have your opinions about followings:
>
> 1. Is everything OK with existing oo development methods?
>    If not, what are needed? and what stage should be enforced in the  
>    future,i.e,analysis or design,etc...?
> ...

OK, here's my 2 cents: most OO development methods concentrate too much
on objects and too little on classes.  This obstructs investigation of
inheritance and polymorphism, making it hard to attain the benefits of OO.
IMHO, in many cases this is because the design method derives from some
entity modelling tool from before the days of OO, and entities are objects,
not classes.

Paul Gover
IBM Warwick Development Group
Mumbling for myself, not IBM

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Jan Steinman]

In article <55pqr5$136a@grimsel.zurich.ibm.com>, Paul_Gover@uk.ibm.com wrote:

> In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim
<kdo@kyebek3.kjist.ac.kr> writes:
> > ...
> >Let me have your opinions about followings:
> >
> > 1. Is everything OK with existing oo development methods?
> >    If not, what are needed? and what stage should be enforced in the  
> >    future,i.e,analysis or design,etc...?
> > ...
> 
> OK, here's my 2 cents: most OO development methods concentrate too much
> on objects and too little on classes...

Gee, in my 8 month experience with one well-known methodology, I felt just
the opposite! It was impossible to model instance-specific behavior
without pretending it was a class. Of course, we might just have been
using it wrong...

-- 
 : To foil junk mailers, REPLY won't work. Please paste address in.
 : Jan Steinman <mailto:Jan@Bytesmiths.com>
 : Bytesmiths <http://www.bytesmiths.com>
 : 2002 Parkside Court, West Linn, OR 97068 USA, +1 503 657 7703
 : On the Internet since it was the DARPANET.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Alan Lovejoy]

Paul_Gover@uk.ibm.com wrote:
> 
> In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim <kdo@kyebek3.kjist.ac.kr> writes:
> > ...
> >Let me have your opinions about followings:
> >
> > 1. Is everything OK with existing oo development methods?
> >    If not, what are needed? and what stage should be enforced in the
> >    future,i.e,analysis or design,etc...?
> > ...
> 
> OK, here's my 2 cents: most OO development methods concentrate too much
> on objects and too little on classes.  This obstructs investigation of
> inheritance and polymorphism, making it hard to attain the benefits of OO.
> IMHO, in many cases this is because the design method derives from some
> entity modelling tool from before the days of OO, and entities are objects,
> not classes.

Objects are objects, not classes.

OO programs are systems of interacting **objects**, not systems of interacting **classes**.

The architecture and design of a program is a function of what **objects** it contains and 
how they interact.  What classes these objects may or may not be instances of is a separate 
issue--a fact which becomes obvious in a Self program, for example.  What matters is the
**interface** supported by each object, and the **role** each object plays in the program.
Note that two objects may support the same interface, but be instances of different
classes and/or play different roles.

Class inheritance is an abstraction mechanism for code sharing.  It has nothing much to do 
with architecture or design of a program.  Proof: any program using class inheritance can
easily be converted into a completely equivalent program where all the leaf classes are root
classes: one simply duplicates all the inherited methods in each leaf class.   Of course,
this requires either dynamic typing or Java-like interfaces, but that's a different
issue.

It's true that static typing and improperly using classes as type constraints "obstructs
investigation of...polymorphism, making it hard to attain the benefits of OO."  But blaming 
that on OO methodologies that focus on objects instead of classes is unjustified.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Snowball]

Paul_Gover@uk.ibm.com wrote:
> 
> In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim <kdo@kyebek3.kjist.ac.kr> writes:
> > ...
> >Let me have your opinions about followings:
> >
> > 1. Is everything OK with existing oo development methods?
> >    If not, what are needed? and what stage should be enforced in the
> >    future,i.e,analysis or design,etc...?
> > ...
> 
> OK, here's my 2 cents: most OO development methods concentrate too much
> on objects and too little on classes.  This obstructs investigation of
> inheritance and polymorphism, making it hard to attain the benefits of OO.
> IMHO, in many cases this is because the design method derives from some
> entity modelling tool from before the days of OO, and entities are objects,
> not classes.
> 
> Paul Gover
> IBM Warwick Development Group
> Mumbling for myself, not IBM

I agree with Paul here, this is the reason I have been developing Snowball Rapid 
Rapid Systems Engineering Tool, a dedicated Smalltalk tool which I call a RASE 
(Rapid Systems Engineering) tool.
It looks like a CASE tool but it is radically different to one. The site is 
still under heavy construction but you can read about my ideas and approach in our 
web pages http://www.rase.com/ and http://www.rase.com/snowball/

Tansel Ersavas
mailTo:tansel@deep.net

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Joachim Durchholz]

alovejoy@concentric.net wrote 06.11.96:

> Objects are objects, not classes.

Of course :)

> OO programs are systems of interacting **objects**, not systems of
> interacting **classes**.

I think this is a bit misleading.
OO program texts are definitely systems of classes (or, rather, textual  
representations of classes). We don't specify a single objects when  
writing code for a class; instead, we specify the behaviour of a set of  
objects, of which there may be none, one, or an unlimited number present  
at run-time.

> The architecture and design of a program is a function of what **objects**
> it contains and how they interact.

Well, now I have to disagree. An OO program consists of classes, which are  
descriptions of the behaviour of object sets. I.e. it is object behaviour  
that we describe, not objects themselves (which are a bit irrelevant  
anyway, we want the computer to *behave*, not to *be*).

> Class inheritance is an abstraction mechanism for code sharing.

It is much more. It is a mechanism for specifying similarities, and in  
this respect goes far beyond mere code sharing.
I can have exactly the same amount of code sharing with subroutines (that  
take routines as parameters in cases where I need dynamic dispatch). This  
is available in C, but nobody would regard C equivalent to an OO language!

> It has
> nothing much to do with architecture or design of a program.  Proof: any
> program using class inheritance can easily be converted into a completely
> equivalent program where all the leaf classes are root classes: one simply
> duplicates all the inherited methods in each leaf class.

On the same basis, I could declare C to be equivalent to assembler. Proof:  
it is always possible to mechanically produce an equivalent assembler  
program. (I won't do this :)

The mere possibility to reproduce a program in a different way just proves  
Turing equivalence, which we aren't too interested in when discussing  
software engineering issues. The real issues are readability,  
maintainability, and reusability of the code, by a human programmer, and  
representation can have a tremendous impact on that.

Regards,
-Joachim

--
Looking for a new job. Resume available on request. WWW version of resume
available under http://www.franken.de/users/herold/jhd/resume/index.html

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Piercarlo Grandi]

>>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:

alovejoy> Objects are objects, not classes.

Ok, even if there are some famous authors that don't seem to agree.

alovejoy> OO programs are systems of interacting **objects**, not
alovejoy> systems of interacting **classes**.

Consider:

  class complex
  {
  private:  float rho,theta;
  public:   float proj_real(); float proj_imag();
	    complex operator +(complex);
	    ....
	    
  };

  class rational
  {
  private:  float above,below;
  public:   float num(); float den();
	    rational operator +(rational);
	    ....
  }

  ....

So far this is not an OO program, according to your definition, for
there are no objects whatsoever in it, only classes, and there are no
``interactions'' among classes in it either.

alovejoy> The architecture and design of a program is a function of what
alovejoy> **objects** it contains and how they interact.

Now let's try to add some more detail:

  // the above plus ...

  main()
  {
    complex c1, c2;

    operator >>(cin,c1); operator >>(cin,c2);
    operator <<(cout,operator +(c1,c2));

    // or more briefly: cin >> c1; cin >> c2; cout << (c1+c2);

    exit(0);
  }

Is this an OO program? It's hard for me to see any objects in it either
for I can only see variables (memory objects, a different concept) and
they don't interact with each other in any sort of interesting meaning
of the word.

To my naked eye the above is an (outline of an) OO program, but it
contains only classes ('complex' and 'rational', variables ('c1', 'c2',
'cin', 'cout') and procedures ('main', 'operator <<', 'operator >>'
'operator +', and 'exit').

Objects do come into existence (thanks to the execution of constructors)
only during the _execution_ of the program, and they are passed as
arguments to various procedures at execution time too; they don't seem
to be contained in the *program*, and even when they are contained in a
computation created by executing the program they don't seem to
interact, any more than the arguments to a procedure may be said to
``interact''.

alovejoy> What classes these objects may or may not be instances of is a
alovejoy> separate issue--a fact which becomes obvious in a Self
alovejoy> program, for example.  What matters is the **interface**
alovejoy> supported by each object,

alovejoy> and the **role** each object plays in the program.  Note that
alovejoy> two objects may support the same interface, but be instances
alovejoy> of different classes and/or play different roles.

What is a role that an object may play? It is usually easy to see
interfaces in OO programs; for example in the above program it is easy
to discern which interfaces the 'complex' and 'rational' classes have
got; but what roles do objects play in the above program?

I do realize that according to your definitions the above program is not
an OO program (there are no objects and no interaction among them); then
perhaps you could provide an example of an OO program, in which
according to your definition there are objects, they ``interact'', they
have interfaces, and they play roles. For the sake of appealing to a
wider audience, it would be important that the example be written in
something resembling C++.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Paul_Gover]

In <Jan-0611961134040001@news.imagina.com>, Jan Steinman <No@Junk.Mail.Please> writes:
>In article <55pqr5$136a@grimsel.zurich.ibm.com>, Paul_Gover@uk.ibm.com wrote:
>> ... 
>> OK, here's my 2 cents: most OO development methods concentrate too much
>> on objects and too little on classes...
>
>Gee, in my 8 month experience with one well-known methodology, I felt just
>the opposite! 
> ...

Jan, I did say "most", not "all"!  So, which well-known methodology was it?
I'd like to know more; either I don't know it, or I've misunderstood it.

Paul Gover
IBM Warwick Development Group
Mumbling for myself, not IBM

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Joachim Durchholz]

alovejoy@concentric.net wrote 08.11.96:

> > I think this is a bit misleading.

Seems I got mislead my self a bit :)

> execution of a program.  And in a Self program, classes never exist at all
> (not even in the program text).

Well, I don't know Self (or any other prototype language), so I'm a bit  
bewildered about what you say about this statement.
Could anybody post a short characterisation of prototype languages?

> > We don't specify a single objects when
> > writing code for a class; instead, we specify the behaviour of a set of
> > objects, of which there may be none, one, or an unlimited number present
> > at run-time.
>
> To the extent that this is true, this is an artifact of using classes as an
> abstraction mechanism to specify the behavior of objects.

I don't think it is too artificial to define a class, even if it is for a  
single object. At least not if the class specification isn't longer or  
more complicated than the specification for the single object.
I do see some overhead in that it is necessary to declare an attribute  
that is instantiated with the constructor of the class. Given the size of  
class texts, I doubt that this overhead is a problem.

> > > Class inheritance is an abstraction mechanism for code sharing.
> >
> > It is much more. It is a mechanism for specifying similarities, and in
> > this respect goes far beyond mere code sharing.
>
> A class specifies the internal mechanisms of an object.  Class inheritance
> therefore specifies the commonality of implementation mechanisms.
> ...
> This is actually what I was trying to get at
> in saying that "class inheritance is an abstraction mechanism for code
> [implementation mechanism] sharing."

Not in all cases. Most OO languages have abstract/virtual/deferred classes  
that primarily serve to specify external behaviour, not implementation.

I definitely agree that inheritance can be used for code sharing, but it  
is also useful for object classification.

> The type/interface hierarchy is an important topic in design, and hence is
> an important issue that should be addressed by a design methodology.
> ...

Agreed. (As with the rest of your post :)


-Joachim

--
Looking for a new job. Resume available on request. WWW version of resume
available under http://www.franken.de/users/herold/jhd/resume/index.html

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Alan Lovejoy]

Joachim Durchholz wrote:
> 
> alovejoy@concentric.net wrote 06.11.96:
> > OO programs are systems of interacting **objects**, not systems of
> > interacting **classes**.
> 
> I think this is a bit misleading.
> OO program texts are definitely systems of classes (or, rather, textual
> representations of classes). 

In most languages that supposedly have them, "classes" exist only at compile 
time, not while the program runs.  In any case, it is definitely the instances 
of the classes (the objects) whose interactions constitute the execution of a 
program.  And in a Self program, classes never exist at all (not even in the 
program text).

Programs are not texts.  They may be **specified** by texts, but the distinction
is important.  The purpose of a design methodology is to help design and describe
a program, not the text that specifies the program.  The ideal methodology would
be language independent, and the program would be derivable directly from the
design without ever being expressed in a traditional programming language text.

Classes are just one way to specify the behavior of an object.  They are an 
abstraction of the common case where there are many objects all of which have 
the same potential behavior (I'll discuss "potential" behavior later). However,
an object is a "black box." Any two objects with the identical behavior and 
state are functionally equivalent.  How it is that there can be two different
objects with the identical state and behavior makes no difference.  It is an
implementation detail that is intentionally hidden by the "black box" of
information hiding that encapsulates an object.  Perhaps the two objects
were created as instances of the same class, but that is not the only 
possibility, nor is it required.  In fact, any such requirement would 
essentially be a violation of the encapsulation of the object.

The point here is that classes are just one possible mechanism for defining
the properties of objects.  The purpose of a design methodology is to design
programs whose behavior meets their requirements.  The textual notation used
to specify the program, what language it may be written in, what the class
inheritance hierarchy may be, and whether the language even has classes
should be irrelevant to the methodology.  Any methodology that would be
helpless in the design of a program to be written in Self (which has
objects but not classes) is seriously flawed.

> We don't specify a single objects when
> writing code for a class; instead, we specify the behaviour of a set of
> objects, of which there may be none, one, or an unlimited number present
> at run-time.

To the extent that this is true, this is an artifact of using classes as an 
abstraction mechanism to specify the behavior of objects.  However, it is
not in general true. What a class does not do is to define the role that 
any of its instances will play.  The role is a) the **actual** behavior of an 
object (that is, what messages it is sent, in which order, with what arguments, 
by which senders), and b) the semantics of the object, the purpose that that 
particular object (instance) serves in the program.  Obviously, the roles of 
two different instances of the same class may be very different.  And since a 
class can be used in any number of different program texts, the roles that 
the instances of a class may play in one program may differ substantially from 
the roles that instances of the class may play in some other program.

A class defines the **potential** behavior and states of its instances.
But just because an object can respond to a particular message does not mean
it will necessarily ever be asked to do so.  This is the difference between
potential and actual behavior.  It is central to the distinction between
type and role.

In order to define or specify the role that an object plays, it is essential
to be able to deal with the issue of object identity.  And in fact, OO languages
(as opposed to OO design methodologies) typically permit the programmer to
do so.  It is just when the issues of object identity and the roles of specific
objects become important to the design that users of the run of the mill OO
design methodologies are forced to abandon the methodology and go write code.

> > The architecture and design of a program is a function of what **objects**
> > it contains and how they interact.
> 
> Well, now I have to disagree. An OO program consists of classes, which are
> descriptions of the behaviour of object sets. I.e. it is object behaviour
> that we describe, not objects themselves (which are a bit irrelevant
> anyway, we want the computer to *behave*, not to *be*).

At best, the **texts** that specify a program in some programming language
contain class definitions--although in some highly reflexive languages such as 
Smalltalk, classes are objects that exist at run time, but this is not relevant 
(otherwise, ALL OO languages would be required to have run-time class objects).

It is true that program texts define the properties of objects, "and not the
objects themselves."  However, the ultimate goal of a program is the behavior
of the objects, not any particular text that defines that behavior.  Whether
a program meets its requirements, and satisfies the person(s) who paid for
it to be written, can only be determined by the behavior of the program and
its objects, not by the form of the text that specifies the program.

> > Class inheritance is an abstraction mechanism for code sharing.
> 
> It is much more. It is a mechanism for specifying similarities, and in
> this respect goes far beyond mere code sharing.

It's true that inheritance relationships express what will be common among sets 
of objects.  However, it is important to distinguish between the external and
internal similarities among objects.  One important purpose of object encapsulation 
is to hide the internal dissimilarities between objects, so that those objects
that are externally equivalent can be used interchangeably.

A class specifies the internal mechanisms of an object.  Class inheritance therefore
specifies the commonality of implementation mechanisms.  However, it is typical
that the "type" or "interface" inheritance hierarchy is different than the class
(implementation) inheritance hierarchy--especially in dynamically-typed languages.
This is actually what I was trying to get at in saying that "class inheritance
is an abstraction mechanism for code [implementation mechanism] sharing."

The type/interface hierarchy is an important topic in design, and hence is an
important issue that should be addressed by a design methodology.  However,
while implementation inheritance is important for code reuse, change propagation
and speed of development, it is at best a peripheral issue for a design
methodology.  Implementation inheritance should be hidden behind the "black box"
of object encapsulation, at least at the design level.  

Why?  One reason is that there are other abstraction mechanisms that can specify 
sharing of implementation mechanics, such as macro expansion as might be done in
C, or dynamic delegation as used in the so-called prototype languages (Self, Cecil, 
Dylan).  A design methodology should not get indigestion just because some other 
abstraction mechanism than class inheritance is used for this purpose.  

The other reason is to make the design polymorphic--that is, the design should 
permit any object that satisfies the required interface to be used, regardless of 
its internal implementation. The only place in the design where the internal 
implementation of a "Dictionary" should matter is in the module that specifies 
the design of a "Dictionary."

> I can have exactly the same amount of code sharing with subroutines (that
> take routines as parameters in cases where I need dynamic dispatch). This
> is available in C, but nobody would regard C equivalent to an OO language!

Well, that's because C doesn't have objects.   And no one said that inheritance
is the only way to share code.

> > It has
> > nothing much to do with architecture or design of a program.  Proof: any
> > program using class inheritance can easily be converted into a completely
> > equivalent program where all the leaf classes are root classes: one simply
> > duplicates all the inherited methods in each leaf class.
> 
> On the same basis, I could declare C to be equivalent to assembler. Proof:
> it is always possible to mechanically produce an equivalent assembler
> program. (I won't do this :)

Whether or not two languages are equivalent is not the issue.  The issue is
the properties of design methodologies, not the properties of languages.

> The mere possibility to reproduce a program in a different way just proves
> Turing equivalence, which we aren't too interested in when discussing
> software engineering issues. The real issues are readability,
> maintainability, and reusability of the code, by a human programmer, and
> representation can have a tremendous impact on that.

My argument was not that one can code two programs using different languages,
algorithms, data structures, notations and object models such that both programs
will have the same external inputs and outputs.  I think we both agree that
this can be done, but that it is irrelevant.

My argument was much more specific and constrained: I was making the point
that object encapsulation makes implementation inheritance irrelevant
to the behavior of a program, and that therefore implementation inheritance
is irrelevant to the logical design of a program as it should be expressed
in a good design notation.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Alan Lovejoy]

Nick Thurn wrote:
> 
> alovejoy@concentric.net wrote 06.11.96:
> >
> > Class inheritance is an abstraction mechanism for code sharing.
> > It has
> > nothing much to do with architecture or design of a program.
> >
> This is a dangerous notion! IMHO those who subscribe to this notion
> should work for "the opposition". :)

But my statement is merely an obvious and intended consequence of information
hiding and object encapsulation.  An object is a "black box."  You're not 
supposed to know or care what the internal mechanisms are that give it its
externally visible properties and behavior--and that includes what class
it may be an instance of, or what behavior it inherits instead of implementing 
locally.

> So what pray tell *is* to do with architecture and design?

Architecture is a question of the division of responsibility among the
objects and subsystems within a system.  It is about the roles that objects
play, the relationships among and interactions between objects, and of how 
objects collaborate to carry out their responsibilities.  Design is the
process of converting a set of requirements into a specification of the
types of objects than can exist and how objects of the specified types
will operate as a system to satisfy the requirements.

> 
> > Proof: any
> > program using class inheritance can easily be converted into a completely
> > equivalent program where all the leaf classes are root classes: one simply
> > duplicates all the inherited methods in each leaf class.
> >
> This is wrong.
> 
> It is not "simple" unless the translated program doesn't use polymorphis.
> Where it was used explodes to a mess of conditionals and special cases.
> 
> Polymorphism moves complexity from class clients to the runtime.
> Your "proof" is bogus. An equivalent program cannot be mechanically
> produced by simply copying method implementations as *much* new code is
> required to deal with the dispatch of those methods.
> 
> Think of a program with two sets of interacting objects. The OO version
> has two hierarchys each with a base abstraction that fully describes
> the behaviour of derived objects. The program must deal with two things
> only.
> 
> Remove the polymorphism and what happens? The program must now deal
> with N things everywhere. The complexity increases exponentially with
> the number of new objects and all parts of the program are touched by
> any additional types.

You don't understand.  You are thinking in terms of some statically-typed
language that uses classes as type contraints (such as C++).

In a dynamically-typed language such as Smalltalk, it is syntactically legal 
to send any message to any object.  If the object does not understand the message, 
an error will be reported at run time.

In a statically-typed language that uses interfaces instead of classes as
type constraints (such as can be done in Java), one just needs to define
a hierarchy of interfaces, and then declare each class to be an implementor
of the appropriate interface.  Doing this gets you an otherwise equivalent
program without using any class inheritance at all, and without having
to use any additional switch or if statements.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Paul_Gover]

In <328109CD.6685@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> writes:
> ...
>The architecture and design of a program is a function of what **objects** it contains and 
>how they interact.  What classes these objects may or may not be instances of is a separate 
>issue--a fact which becomes obvious in a Self program, for example.  What matters is the
>**interface** supported by each object, and the **role** each object plays in the program.
>Note that two objects may support the same interface, but be instances of different
>classes and/or play different roles.
>
>Class inheritance is an abstraction mechanism for code sharing.  It has nothing much to do 
>with architecture or design of a program.  Proof: any program using class inheritance can
>easily be converted into a completely equivalent program where all the leaf classes are root
>classes: one simply duplicates all the inherited methods in each leaf class. 
> ...

Alan, If you restrict your statements above to "architecture" or "analysis" I'd be in
complete agreement.  However, I disagree when it comes to design; this might be a
difference in our view of where to separate design from coding.  My view is that design
includes implementation detail such as inheritance.  I most certainly consider that
"OO development methods" should address it.

I think from your statement about converting to equivalent programs indicates you
consider implementation to be outside the scope of the design (since you describe two
different implementations for the same design); in that case, do you think that
questions of inheritance and so forth are not part of the development method?
I think this is dangerous; in your example, the coverted program has large amounts of
duplicated code, so making changes is harder because the programmer has to find all
occurrences of the duplicated code, and we have lost one of the benefits of OO.

Paul Gover
IBM Warwick Development Group
Mumbling for myself, not IBM

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Ell]

Paul_Gover@uk.ibm.com wrote:
: In <328109CD.6685@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> writes:
: >Class inheritance is an abstraction mechanism for code sharing.  It has nothing much to do 
: >with architecture or design of a program.  Proof: any program using class inheritance can
: >easily be converted into a completely equivalent program where all the leaf classes are root
: >classes: one simply duplicates all the inherited methods in each leaf class. 
: > ...
 
: I think from your statement about converting to equivalent programs indicates you
: consider implementation to be outside the scope of the design (since you describe two
: different implementations for the same design); in that case, do you think that
: questions of inheritance and so forth are not part of the development method?
: I think this is dangerous; in your example, the coverted program has large amounts of
: duplicated code, so making changes is harder because the programmer has to find all
: occurrences of the duplicated code, and we have lost one of the benefits of OO.

I agree with you that inheritance should be more than a means of code
sharing.  But it seems he is saying we can take all of the methods
declared and defined along the branch of an inheritance hierarchy and
aggregate them in root classes.  Perhaps he will clarify.

Elliott

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Jon S Anthony]

In article <6KRKVf9k3RB@herold.franken.de> jhd@herold.franken.de (Joachim Durchholz) writes:

> alovejoy@concentric.net wrote 06.11.96:
> 
> > Objects are objects, not classes.
> 
> Of course :)
> 
> > OO programs are systems of interacting **objects**, not systems of
> > interacting **classes**.
> 
> I think this is a bit misleading.
> OO program texts are definitely systems of classes (or, rather, textual  
> representations of classes). We don't specify a single objects when  

I see that "all the world is a class" view has clouded your
perceptions! :-).  Not all OO (languages,systems,programs,etc) are
class based.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Alan Lovejoy]

Ell wrote:
> 
> Paul_Gover@uk.ibm.com wrote:
> : In <328109CD.6685@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> writes:
> : >Class inheritance is an abstraction mechanism for code sharing.  It has nothing much to do
> : >with architecture or design of a program.  Proof: any program using class inheritance can
> : >easily be converted into a completely equivalent program where all the leaf classes are root
> : >classes: one simply duplicates all the inherited methods in each leaf class.
> : > ...
> 
> : I think from your statement about converting to equivalent programs indicates you
> : consider implementation to be outside the scope of the design (since you describe two
> : different implementations for the same design); in that case, do you think that
> : questions of inheritance and so forth are not part of the development method?
> : I think this is dangerous; in your example, the coverted program has large amounts of
> : duplicated code, so making changes is harder because the programmer has to find all
> : occurrences of the duplicated code, and we have lost one of the benefits of OO.
> 
> I agree with you that inheritance should be more than a means of code
> sharing.  But it seems he is saying we can take all of the methods
> declared and defined along the branch of an inheritance hierarchy and
> aggregate them in root classes.  Perhaps he will clarify.

I am saying that all classes could be root classes--that is, one can have classes 
and objects without inheritance, and construct objects and programs that have exactly 
the same functionality as those that use inheritance.  The only difference is the amount 
of code that must be written, and the effort required to make certain changes in the 
program.

The point is that whether or not one uses inheritance does not change the **design** 
of the program at the architectural level at which a design methodology should concern 
itself (although using or not using inheritance can be said to be a difference in design, 
it is a physical implementation difference, not an architectural difference).  Using
inheritance versus duplicating code does not in itself change what an object or program 
does.

Consider an argument from the opposite direction:  One can construct many very different
programs using the very same class library.  Let's say the class library has 26 leaf classes,
named A through Z.  One program can be started by instantiating an instance of class M,
and then sending it the message "startUpProgram1."  Another program can be started by
instantiating an instance of class C, and sending it the message "doSomeStuff."   Either
program may instantiate objects of any class (A through Z), and send whatever messages
such instances will understand. The set of possible programs in this situations is
a function of what messages can be understood by which objects, and what each method
does.  The inheritance hierarchy used to povide each object with a set of messages it
can understand makes no difference.

If the same class hierarchy can be used to create many different programs (without
defining any new classes or methods), then it should be obvious that the class 
inheritance hierarchy and program architecture and design are not at all the same 
things!

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Alan Lovejoy]

Paul_Gover@uk.ibm.com wrote:
> 
> In <328109CD.6685@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> writes:
> > ...
> >The architecture and design of a program is a function of what **objects** it contains and
> >how they interact.  What classes these objects may or may not be instances of is a separate
> >issue--a fact which becomes obvious in a Self program, for example.  What matters is the
> >**interface** supported by each object, and the **role** each object plays in the program.
> >Note that two objects may support the same interface, but be instances of different
> >classes and/or play different roles.
> >
> >Class inheritance is an abstraction mechanism for code sharing.  It has nothing much to do
> >with architecture or design of a program.  Proof: any program using class inheritance can
> >easily be converted into a completely equivalent program where all the leaf classes are root
> >classes: one simply duplicates all the inherited methods in each leaf class.
> > ...
> 
> Alan, If you restrict your statements above to "architecture" or "analysis" I'd be in
> complete agreement.  However, I disagree when it comes to design; this might be a
> difference in our view of where to separate design from coding.  My view is that design
> includes implementation detail such as inheritance.  I most certainly consider that
> "OO development methods" should address it.

I think you've hit the nail on the head.  I do distinguish between "design" and "coding".

To me, the "design" of a program is a language-independent abstraction.  Implementation
inheritance is a coding issue.  It's about how to express the program in a programming
notation with the least amount of code duplication and/or the least amount of code changes
when requirements change.

> I think from your statement about converting to equivalent programs indicates you
> consider implementation to be outside the scope of the design (since you describe two
> different implementations for the same design); in that case, do you think that
> questions of inheritance and so forth are not part of the development method?

I think implementation inheritance is overemphasized.  Many seem to think that the
class hierarchy **is** the design!  As I noted in another post: the same class hiearchy
may permit the specification of many different programs, each with a different 
architecture and design.

> I think this is dangerous; in your example, the coverted program has large amounts of
> duplicated code, so making changes is harder because the programmer has to find all
> occurrences of the duplicated code, and we have lost one of the benefits of OO.

Hey, I'm not saying that inheritance is not a good thing!  Far from it!  Yes, the "converted
program" has those problems, but I wasn't recommending that programs be coded that way, but
rather pointing out that they could be.  I was hoping that contemplation of that fact 
would illuminate the difference between design, class hiararchies and implementation
inheritance.

The issues that a design methodology should address with respect to implementation inheritance
would be questions such as the following:

* Just because two objects have the same behavior may or may not mean that they should
inherit the shared behavior.  The methodology should provide the guidance needed to
resolve this issue (is the fact that the behavior is the same simply accidental, or
does it depend upon some reliable invariant?  How likely is it that a changed requirement
will necessitate changing the behavior of one of the objects, but not the other?).

* When should delegation be used instead of inheritance?

* When should the Strategy pattern be used instead of inheritance?

However, implementation inheritance should be treated as a refinement of the design, not
as the body and soul of it.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Nick Thurn]

alovejoy@concentric.net wrote 06.11.96:
>
> Class inheritance is an abstraction mechanism for code sharing.
> It has
> nothing much to do with architecture or design of a program. 
>
This is a dangerous notion! IMHO those who subscribe to this notion
should work for "the opposition". :)

So what pray tell *is* to do with architecture and design?

> Proof: any
> program using class inheritance can easily be converted into a completely
> equivalent program where all the leaf classes are root classes: one simply
> duplicates all the inherited methods in each leaf class.
> 
This is wrong. 

It is not "simple" unless the translated program doesn't use polymorphis.
Where it was used explodes to a mess of conditionals and special cases.

Polymorphism moves complexity from class clients to the runtime. 
Your "proof" is bogus. An equivalent program cannot be mechanically
produced by simply copying method implementations as *much* new code is 
required to deal with the dispatch of those methods. 

Think of a program with two sets of interacting objects. The OO version
has two hierarchys each with a base abstraction that fully describes
the behaviour of derived objects. The program must deal with two things
only. 

Remove the polymorphism and what happens? The program must now deal
with N things everywhere. The complexity increases exponentially with
the number of new objects and all parts of the program are touched by
any additional types.

Nick (my opinions only)

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Richard A. O'Keefe]

jhd@herold.franken.de (Joachim Durchholz) writes:
>I think this is a bit misleading.
>OO program texts are definitely systems of classes (or, rather, textual  
>representations of classes).

This is an overgeneralisaton.  Not every OO language is class based.
The OO system in Xlisp-Stat, for example, is not class based,
and nor is SELF.  Nor need there be any text or fixed collection of
texts that describes a SELF program.  SELF is not alone in this:  I have
used a GUI builder where you constructed _objects_ on the screen that
were then dumped out as textul representations to be used to construct
_objects_, not classes.

>> The architecture and design of a program is a function of what **objects**
>> it contains and how they interact.

>Well, now I have to disagree.

Well, no, you don't.  What you _do_ have to do is understand that there is
more than one way to skin a cat, and that in some OO languages you _do_
describe objects and methods that are attached to objects (individual
objects, not classes), while in some other OO languages you _don't_.
Looked at NewtonScript lately?

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Piercarlo Grandi]

Alan Lovejoy writes:

> OO programs are systems of interacting **objects**, not systems of
> interacting **classes**.

ok> jhd@herold.franken.de (Joachim Durchholz) writes:

jhd> I think this is a bit misleading.  OO program texts are definitely
jhd> systems of classes (or, rather, textual representations of
jhd> classes).

>>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.edu.au> writes:

ok> This is an overgeneralisaton.  Not every OO language is class
ok> based. [ ... consider Self etc ... ]

Well, but then they something like prototype based, as you observe.

The observation above is, as per your remark, strictly speaking not
general enough; but then just saying "OO module" instead of "class"
would give it generality.

For whether class or prototype based, an OO program is a collection of
(OO) modules, and values at runtime are either instances of a class or
clones of a prototype.

OO programs (as opposed to their executions) do occasionally contain
some instances or clones, but this does not justify the observation that
"OO programs are systems of interacting **objects**".

While the analysis and design of an OO program may/should be based on
some mental image of how it is going to be executed, both activities are
really about deciding into which ``encapsulated'' concepts and modules
to decompose the solution to a problem, and not into which
``interacting'' objects (even if in some languages OO modules are
objects, and in some others objects to interact).

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[vlad]

Paul_Gover@uk.ibm.com wrote:

>However, I disagree when it comes to design; this might be a
>difference in our view of where to separate design from coding.  My view is that design
>includes implementation detail such as inheritance.  I most certainly consider that
>"OO development methods" should address it.

Design of what? Design of a class or design of a system. In the design of a
system you  don't need to bother with inheritance. What about objects, that are
not defined by classes or what about objects, which can change it's class at
run-time.
In the design of a system the most important thing is a object interface and how
it coopeates with other objects. 

If you design a class, then you will find inheritance usefull. Of course the
"inheritance" can be replace by delegating and then we even don't need classes.
So inheritance is a implementation detail, that is not important in design of
your application. It is my view and I may be wrong. 



>I think from your statement about converting to equivalent programs indicates you
>consider implementation to be outside the scope of the design (since you describe two
>different implementations for the same design); in that case, do you think that
>questions of inheritance and so forth are not part of the development method?
>I think this is dangerous; in your example, the coverted program has large amounts of
>duplicated code, so making changes is harder because the programmer has to find all
>occurrences of the duplicated code, and we have lost one of the benefits of OO.

>Paul Gover
>IBM Warwick Development Group
>Mumbling for myself, not IBM

 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Chris]

OOP design is interresting for two points.

First, it may be a way to think about/to solve your problem. Just a
different approach (not better, not worse than others). You may not have
here to really think about inheritance or polymorphism.
Second, when designing your solution, you may think about reusing what you
found. Then inheritance and polymorphism are useful.

What's making OOP a better approach than other non-OOP paradigms is that
you can orient your design toward the present problem AND the futures at
the same time (could get it a little longer, thus).


-- 
Chris, drunk philosoph and bad programmer
--------------------------------------------------------------------

"The nail pulling up calls the hammer"

                                     zen proverb



> > I think implementation inheritance is overemphasized.  Many seem to
think
> > that the class hierarchy **is** the design!
> 
> > As I noted in another post: the
> > same class hiearchy may permit the specification of many different
programs,
> > each with a different architecture and design.
> 
> This is possible, but is it useful? If my implementation hierarchy
differs  
> too far from the design hierarchy, I'd expect horrible costs just to keep
 
> them in sync.
> 
> If the objects involved are design objects, I'd take a long, hard look at
 
> the classes involved. If two objects have identical behaviour, and I feel
 
> they shouldn't go in the same class, then I probably forgot to include  
> some behaviour that differs. (Or behaviour that might differ in the  
> future. In that case, the future evolution paths should be fixed by some 

> constraints on the class.)
> 
> > * When should delegation be used instead of inheritance?
> >
> > * When should the Strategy pattern be used instead of inheritance?

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Vlastimil Adamovsky]

"Chris" <gaijin@infonie.fr> wrote:

>Second, when designing your solution, you may think about reusing what you
>found. Then inheritance and polymorphism are useful.

Inheritance can be a maintanance nightmare. To be really able to reuse
inheritance effeciently. you need source code. Thus, inheritance is very usefull
for in-house development. When you use objects written by other companies, you
should use aggregation instead. Approach of Microsoft's OLE is surprisingly
effecient and reusability is high.




 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Vlastimil Adamovsky]

pcg@aber.ac.uk (Piercarlo Grandi) wrote:

>>>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:

>alovejoy> Objects are objects, not classes.

>Ok, even if there are some famous authors that don't seem to agree.

>alovejoy> OO programs are systems of interacting **objects**, not
>alovejoy> systems of interacting **classes**.

>Consider:

>  class complex
>  {
>  private:  float rho,theta;
>  public:   float proj_real(); float proj_imag();
>	    complex operator +(complex);
>	    ....
>	    
>  };

>  class rational
>  {
>  private:  float above,below;
>  public:   float num(); float den();
>	    rational operator +(rational);
>	    ....
>  }

>  ....

>So far this is not an OO program, according to your definition, for
>there are no objects whatsoever in it, only classes, and there are no
>``interactions'' among classes in it either.

It is correct, your above definitions of whatever is not Object oriented
programming. You are actually defining algorithm. This issue has been
succesfully addressed by STL.

>alovejoy> The architecture and design of a program is a function of what
>alovejoy> **objects** it contains and how they interact.

>Now let's try to add some more detail:

>  // the above plus ...

>  main()
>  {
>    complex c1, c2;

>    operator >>(cin,c1); operator >>(cin,c2);
>    operator <<(cout,operator +(c1,c2));

>    // or more briefly: cin >> c1; cin >> c2; cout << (c1+c2);

>    exit(0);
>  }

>Is this an OO program? 

No.

>To my naked eye the above is an (outline of an) OO program, but it
>contains only classes ('complex' and 'rational', variables ('c1', 'c2',
>'cin', 'cout') and procedures ('main', 'operator <<', 'operator >>'
>'operator +', and 'exit').

It contains only one class 'complex', which is in this context a mere type.

>Objects do come into existence (thanks to the execution of constructors)
>only during the _execution_ of the program, and they are passed as
>arguments to various procedures at execution time too; they don't seem
>to be contained in the *program*, and even when they are contained in a
>computation created by executing the program they don't seem to
>interact, any more than the arguments to a procedure may be said to
>``interact''.

The OO design describes objects and their behaivor at the run-time. Behavior and
classes, types and delegees and delegators can change on demand during running
the program. 
So classes are usefull to describe behavior of a object at given time but but
not at another time.



I

 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[drs]

Piercarlo Grandi wrote:

[C++ prototypes omitted]

>So far this is not an OO program, according to your definition, for
>there are no objects whatsoever in it, only classes, and there are no
>``interactions'' among classes in it either.

This is correct. "classes" are merely prototypes in C++. "Objects" are properly 
instantiations, as far as C++ or smalltalk is concerned.

alovejoy> The architecture and design of a program is a function of what
alovejoy> **objects** it contains and how they interact.

>Now let's try to add some more detail:

  // the above plus ...

  main()
  {
    complex c1, c2;
	//etc.
  }

>Is this an OO program? It's hard for me to see any objects in it either
>for I can only see variables (memory objects, a different concept) and
>they don't interact with each other in any sort of interesting meaning
>of the word.

Well, c1 and c2 are indeed instantiations of the above prototype; they have a 
defined address and can do things (unlike the prototype). You're wrong if you 
think c1 and c2 are not objects; they are. entities of the class complex create 
their own scope, which is internal and allows internal processes. This really is 
quite different from C. Now, if your idea is that "Object-oriented"  boils down to 
message sending, then I think you're correct; but by that definition there are 
only a few true "object-oriented" languages, and C++ is not one of them. 

>Objects do come into existence (thanks to the execution of constructors)
>only during the _execution_ of the program, and they are passed as
>arguments to various procedures at execution time too; they don't seem
>to be contained in the *program*, and even when they are contained in a
>computation created by executing the program they don't seem to
>interact, any more than the arguments to a procedure may be said to
>``interact''.

This is wrong. c1 and c2 are scoped within the whole of main(). This is 
not really different from any globally scoped object in, say, smalltalk.
You could easily cause c1 and c2 to interact, although your example 
does not call for much interaction. Performing an addition of two 
complex numbers is not really much of an "interaction" anyway because
the numbers themselves are probably const. The overloaded + probably
instantiates a new number, and changes nothing in the args. But let's 
suppose class bicycle

class bicycle
{
	Wheel w1, w2;
	Brake b1, b2;
	Frame f1;
	Seat s1;
	Freewheel fw1;
	//etc.
	public:
	
	void ride();
	void slowdown();
	void changegears();
	//more methods for interaction between parts
};

The parts model the whole. If you now instantiate an instance of 
class bicycle, in order of it to do anything, the parts *must* interact.
So the issue of what really is "Object-oriented" turns much more 
on a world-view (a way of concieving a problem, perhaps) than on
any particular feature such as "runtime polymorphism." Setting up a 
bicycle object is *qualitatively* different than doing computations about
riding using C functions. 


Regards,

DRS

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Anthony Menio]

On 11 Nov 1996 > 

> Yes, but what's the relevance of this to the question of whether "OO
> programs are systems of interacting **objects**" rather than systems of
> modules (either classes or prototypes or actors) that ``contain''
> procedures that invoke each other?
> 
> Do OO programs by and large describe static relationships between
> modules (or parts thereof like interfaces)? Or do they describe
> collections of instances/clones of those modules (or their types) and
> how they interact?
> 
> 
I think the answer to this can be found in the analysis model.
The analysis model descibes the objects that will be existance
during the systems existance. In this model and thus the
functioning system your interested in definate articals ie
actual entities not classes of entities(ie currentProcess,
ActiveWindow, nextTransaction, rather than definitions of
the types which these are instances of) . The relationships
expressed are dynamic ones as the effects of the messaging between
these objects will be related to thier state. Having state
is a characteristic soley of objects not classes they have
attributes whuch describe abstactly the set of possible states
but not states themselves. In terms of database concepts the
analysis model and the functioning system descibes the
extension of the system and classes the intension of the system.
Thus the design model is a description system in terms
of the classes and class relations that will be used to 
create the objects and dynamic messaging relations which
exists in the functioning system. 

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Anthony Menio]

On 11 Nov Paul Gover
> I can see that an application's design might be expressed as
> a network of interacting objects, and without such objects there's no
> application.  I can also see that it's possible to design class hierarchies
> to solve application development problems (for example a matrix class to
> help develop a linear programming application) which clearly contain
> executable program code despite having neither objects nor their interactions
> defined as part of the program.
 > 
> To clarify, we write such a class definition in terms of the indefinite article -
> "A matrix inverse" - whereas in the application definition we'd write in terms of
> the definite article - "THE costs matrix.  (My apologies to readers whose native
> language is Russian, which I think has neither definite nor indefinite articles!)
> 
> If we restrict a development method to applications, I think it's perfectly
> possible to consider a design which specifies no implementation details.
> But if we consider a development method for programs, I suggest it should
> address implementation details such as capacity, performance, reliability,
> generality.
> 
> If that's so, can we separate development methods into two groups along this line,
> (and if so, are the groups non-empty :-)?  Does the term "OO" mean the same thing when
> applied to the different groups?  I suggest not: application designs seem to be
> independant of implementation, so if we use the term to mean inheritance,
> encapsulation and polymorphism, it's irrelevant; in the application context it's
> more a synonym for "entity -relationship" (which I'd justify by pointing to Alan's
> interacting object instances).  Conversely in "component" design, the traditional
> OO attributes are very relevant to the implementation.  Perhaps the
> entity-relationship details now come more as constraints on the design, ie, an input,
> than a design product.
> 
> Paul Gover
> IBM Warwick Development Group
> Mumbling for myself, not IBM.
> 
> 
	I think the distinction you are speaking od is the one 
between the analysis model and the design model. The analysis
model is one of the objects which will exist in the system and the
interactions between them. These are objects not classes, thus
they are definite articals. This model is assumed to take place in
an ideal environment. Thus the specifics of the development environment
are ignored, ie operating system, language,database system in use etc.
The design model describes the classes and class relations which the
objects in the previous model will be created from. This model
is developed from the previous now in the specific implementation
model for the system. The the processes that create these models
should be seemless thus the implementation model should be
created from and be as consistant as possible with the
analysis model. Thus both described the system and both
do so in terms of same architecture(an OO) just at
different levels of detail. So in essence your talking
about the deliverables of two different stages in an
OO systems development process rather than two
different sets of methods, and the answer is that these
both reflect the OO architecture of the system equally.
Regardless of the size or complexity of any system thier exists
both an analysis model and a design model which will
be equally valid descriptions of it. Thus any component
you wish to create must have the abilites of an instance
of it modeled and then a blue print to create these instances 
of. Consider the development of a set of components
from a physical system lets say a transmission you would
be interested in describing the behavoir and attributes of a
example of this transmission and its sinteraction with everal
instances of types of cars. From this model you would create your
blueprint thus your design the type description.
 

Anthony Menio
I.S. student
menio@pegasus.montclair.edu

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Nick Thurn]

Alan Lovejoy (alovejoy@concentric.net) wrote:
> Nick Thurn wrote:
> > 
> > alovejoy@concentric.net wrote 06.11.96:
> > >
> > > Class inheritance is an abstraction mechanism for code sharing.
> > > It has
> > > nothing much to do with architecture or design of a program.
> > >
[...]
> > So what pray tell *is* to do with architecture and design?
> 
> Architecture is a question of the division of responsibility among the
> objects and subsystems within a system.  It is about the roles that objects
> play, the relationships among and interactions between objects, and of how 
> objects collaborate to carry out their responsibilities.  Design is the
> process of converting a set of requirements into a specification of the
> types of objects than can exist and how objects of the specified types
> will operate as a system to satisfy the requirements.
> 
I totally agree! 

But objects are described by a text (smalltalk or otherwise) 
as classes that may be related by inheritance, containment or usage. 
Inheritance is not just code organisation (although it does organise code). 

I think there is a chicken and egg problem here. Architecture is expressed
in code and code is organised by architecture. My issue (and where I think
we agree) is that architecture is *more* important than code organisation
because:
	it is more fundamental to correctness of model
	code will be organised anyway by a "good" model
[...]
> 
> You are thinking in terms of some statically-typed
> language that uses classes as type contraints (such as C++).
>
> In a dynamically-typed language such as Smalltalk, it is syntactically legal 
> to send any message to any object.  If the object does not understand the message, 
> an error will be reported at run time.
> 
You are correct, I am thinking in statically typed terms. This does not invalidate
what I said. Sending "any message to any object" still requires the semantics
to be understood. The "typelessness" may be useful or may increase complexity. 
This is a design call and your milage may vary :) 

Nick (my opinions only)

> --
> Alan L. Lovejoy		|==============================================| 
> Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
> alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Paul_Gover]

I think there's a general thread appearing here over the boundary between
design and coding, and over what constitutes a program.  What happens to
the discussion if we introduce another boundary between applications and
programs?

I can see that an application's design might be expressed as
a network of interacting objects, and without such objects there's no
application.  I can also see that it's possible to design class hierarchies
to solve application development problems (for example a matrix class to
help develop a linear programming application) which clearly contain
executable program code despite having neither objects nor their interactions
defined as part of the program.

To clarify, we write such a class definition in terms of the indefinite article -
"A matrix inverse" - whereas in the application definition we'd write in terms of
the definite article - "THE costs matrix.  (My apologies to readers whose native
language is Russian, which I think has neither definite nor indefinite articles!)

If we restrict a development method to applications, I think it's perfectly
possible to consider a design which specifies no implementation details.
But if we consider a development method for programs, I suggest it should
address implementation details such as capacity, performance, reliability,
generality.

If that's so, can we separate development methods into two groups along this line,
(and if so, are the groups non-empty :-)?  Does the term "OO" mean the same thing when
applied to the different groups?  I suggest not: application designs seem to be
independant of implementation, so if we use the term to mean inheritance,
encapsulation and polymorphism, it's irrelevant; in the application context it's
more a synonym for "entity -relationship" (which I'd justify by pointing to Alan's
interacting object instances).  Conversely in "component" design, the traditional
OO attributes are very relevant to the implementation.  Perhaps the
entity-relationship details now come more as constraints on the design, ie, an input,
than a design product.

Paul Gover
IBM Warwick Development Group
Mumbling for myself, not IBM.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[David N. Smith]

In article <3283BB94.2D82@concentric.net> Alan Lovejoy,
alovejoy@concentric.net writes:
>To me, the "design" of a program is a language-independent abstraction.  Implementation
>inheritance is a coding issue.  It's about how to express the program in a programming
>notation with the least amount of code duplication and/or the least amount of 
>code changes when requirements change.


I try to stay out of 'design' discussions for a variety of reasons,
partly because they often have little to do with Design, and partly
because the design-it-and-throw-over-the-wall school of thought seems to
have the same kinds of problems in computing as it has in other fields.
Yet, here is Alan saying these things and somehow I can't resist
commenting. :-)

Many other fields have found that integrating design, engineering, and
manufacturing (into an iterative process) leads to better products,
cheaper products, and products that are easier to maintain. One doesn't
end up with air-conditioners or exhaust manifolds on top of spark plugs,
making a simple job into a half-day or more of work. 

For that matter, Alexander's patterns involve all parts of the job, from
materials all the way to living in the building. A building is not just
designed then dumped on some construction worker to figure out how to
make fit on a lot and which materials to use.

Computer languages differ greatly in how they express algorithms. One
thinks differently in APL than in FORTRAN or Scheme, or in Smalltalk
compared to C. C++ programmers seem to think quite differently than
Smalltalk programmers, having lots of ideas like friend functions, type
hierarchies, templates, and lots more stuff that I find incomprehensibly
unnecessary and totally void of need or interest.  My own biases aside,
the point is simple: Programmers think differently in different
languages. Even Java and C++, two peas in similar pods, foster different
thinking patterns.

I'm not interested in starting a language war. I'm a widely known
Smalltalk bigot (or at least widely know as a Smalltalk bigot :-) and
probably warped beyond any chance of a cure. But when I hear my friend
Alan make such inflammatory statements, My fingers start to itch.

I do not think one can separate design from 'mere' coding, no matter how
grungy one thinks coding to be, nor how lofty one's ideas of Design. One
designs a fiberglass body (and much of the rest of the car) very
differently than a steel body. One designs a stone house in a totally
different way than a frame house. One should design a Smalltalk program
in a different way than a C++ program since there are fundamental
differences in how the languages work and how people think in them when
using them well.

The design of a program should be an integral part of the design of the
implementation of a program which should be an integral part of the
coding of a program. This does not mean there is so separation between
the parts. Car companies still have designers, design engineers,
manufacturing engineers, and assemblers. These people with different
points of view need to work together as partners, with the designer
cognizant of enough of the details of the target language not to get in
too much trouble, and the ultimate programmer cognizant of enough of the
high-level design to understand where it all is going.

Failing to consider the language at design time can leave issues open
that need to be closed. If the designer has learned 'object design' but
has never programmed an object, a condition I fear happens all to often,
is the design suitable for implementation and maintenance in any language?

Please note that I am not saying that it is impossible to implement
designs thrown over the wall from a designer who doesn't consider
language. I am suggesting that such designs can lead to very poor
programs. Since programs are the ultimate product of the whole process,
and it is the program that will be used, lived with, maintained, or
thrown away, it is the program that matters, not the original design. To
the extent that a programmer had to perform heroics to fit a design to a
language, the design has failed and the resulting product is the poorer
for it.

Dave

_____________________________________________
David N. Smith
IBM T J Watson Research Center, Hawthorne, NY
Mailto: dnsmith@watson.ibm.com
Home Page: http://www.dnsmith.com/
_____________________________________________
Any opinions or recommendations are those 
of the author and not of his employer.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Bill Gooch]

Alan Lovejoy wrote:
> 
> I think you've hit the nail on the head.  I do distinguish between "design" and "coding".
> 
> To me, the "design" of a program is a language-independent abstraction.  Implementation
> inheritance is a coding issue....

I'd like to hear more about how you think design can be done
independent of language, and what such a "design" would look
like.  I can see that the most abstract levels of design can 
be language-independent, but refinement from this level is an 
essential aspect (IMO) of doing good design.  Such refinement 
necessarily goes down through layers including language, frame-
work, database,... dependencies; in fact, it takes into account 
*all* requirements, including hardware constraints.

If you don't agree that all of this is important in producing
good designs, then I have a question: what do you call a 
program specification, not involving code, which does take
these issues into account?

I think it is impossible to progress very far from a domain 
model into design without considering target language, and
the other things I've mentioned.  A very abstract design, not
considering these issues, may be useful some of the time, but
the design one actually implements *must* consider them.
 
> Many seem to think that the class hierarchy **is** the design! ...

Well, I do not.  But there are many levels of design, and
it is important to ultimately be specific.

> The issues that a design methodology should address with respect to implementation inheritance
> would be questions such as the following:
> 
> * Just because two objects have the same behavior may or may not mean that they should
> inherit the shared behavior.  The methodology should provide the guidance needed to
> resolve this issue (is the fact that the behavior is the same simply accidental, or
> does it depend upon some reliable invariant?  How likely is it that a changed requirement
> will necessitate changing the behavior of one of the objects, but not the other?).
> 
> * When should delegation be used instead of inheritance?
> 
> * When should the Strategy pattern be used instead of inheritance?

I agree that IWBNI methods could help with these things.
I don't know of any method that even comes close, however.
This is why design remains largely a black art - not the
best situation, but it's the way things are.  I'd really
like to hear from anyone who can suggest how to address 
questions such as the ones Alan has raised here in a
method(olog)ical or systematic fashion.

> However, implementation inheritance should be treated as a refinement of the design, not
> as the body and soul of it.

From the last, I gather that in some sense, we are in
agreement.  But again, what do you call this refinement,
if it isn't another (more specific, closer to code) layer
of design?

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Daniel Drasin]

Piercarlo Grandi wrote:
> 
> >>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> alovejoy> Objects are objects, not classes.
> 
> Ok, even if there are some famous authors that don't seem to agree.
> 
> alovejoy> OO programs are systems of interacting **objects**, not
> alovejoy> systems of interacting **classes**.
> 
> Consider:
> 
>   class complex
>   {
>   private:  float rho,theta;
>   public:   float proj_real(); float proj_imag();
>             complex operator +(complex);
>             ....
> 
>   };
> 
>   class rational
>   {
>   private:  float above,below;
>   public:   float num(); float den();
>             rational operator +(rational);
>             ....
>   }
> 
>   ....
> 

> 
> To my naked eye the above is an (outline of an) OO program, but it
> contains only classes ('complex' and 'rational', variables ('c1', 'c2',
> 'cin', 'cout') and procedures ('main', 'operator <<', 'operator >>'
> 'operator +', and 'exit').

[Bunch of more stuff that only includes class descriptions/definitions]

> 
> Objects do come into existence (thanks to the execution of constructors)
> only during the _execution_ of the program, ...
> 

[More examples/discussions along the same lines

-------------------------------Break------------------------------
You are both right (and wrong).  The question is, what is the point of
the distinction.  P.G.  Just 'cause you can't "see" the objects doesn't
mean that they're not there.  E.g. A psychiatry textbook will describe
behavior of "humans," "men," and "women."  These are types but clearly
in actual application, these "laws of psychiatry" apply to the actual
individual people involved.  

Smalltalk, C++, and java use what's called "class-based programming"
which
means that the behavior of individual objects is described by its 
type or class.  Therefor classes will be manipulated in order to affect
the behavior of objects.  Which leads back to by origional question:
What is the point of the distinction?  What is the point of saying
that an OO program is the interaction of objects (and not classes)?
If the point is to direct the student to understand the runtime behavior
that needs to be focused on, then objects are what the program consists
of (ognoring the reflective meta abilities...).  However, if the aim
is to understand what must be created at compile time in order to
create a program, then "classes" are the elements are the program.

Dan



-- 
	Daniel Drasin			Applied Reasoning Systems Corporation
	drasin@arscorp.com		2840 Plaza Place, Suite 325
	(919)-781-7997			Raleigh, NC  27612
	http://www.arscorp.com

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Piercarlo Grandi]

>>> "vlad" == Vlastimil Adamovsky <vlad@world2u.com> writes:

vlad> pcg@aber.ac.uk (Piercarlo Grandi) wrote:

>>>>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:

alovejoy> OO programs are systems of interacting **objects**, not
alovejoy> systems of interacting **classes**.

pcg> Consider>:

pcg> class complex {
pcg> private: float rho,theta;
pcg> public: float proj_real(); float proj_imag();
pcg>         complex operator +(complex);
pcg> .... };

pcg> class rational {
pcg> private: float above,below;
pcg> public: float num(); float den();
pcg>         rational operator +(rational);
pcg> .... };

pcg> ....

pcg> So far this is not an OO program, according to your definition, for
pcg> there are no objects whatsoever in it, only classes, and there are
pcg> no ``interactions'' among classes in it either.

vlad> It is correct, your above definitions of whatever is not Object
vlad> oriented programming. You are actually defining algorithm.

The above defines two ADT implementations, for some sort of 'complex'
and 'rational' ADTs. The implementation is a class rather than a
prototype, but that does not change much; the representation is
encapsulated ('private:'), and it is implied without much detail that
all and only the procedures that need to access that representation are
listed in the class definition.

This to me seems if not an OO progam, at the very least an OO library;
In the above lines there is not much (perhaps it can be implied in the
'....' bits) of an algorithm, for there is no definition of a procedure
of function (only declarations of them).

vlad> This issue has been succesfully addressed by STL.

And by RogueWave's, and by quite a few other collections of OO
components/templates/classes/prototypes/...; to me STL and things of its
ilk do seem to be OO programs, even if they contain no interacting
objects.

Then as I remarked it is well reasonable that:

alovejoy> The architecture and design of a program is a function of what
alovejoy> **objects** it contains and how they interact.

if one rephrases it a little :-) differently; but still it seems to me
that in neither class/prototype/actor based systems programs are systems
of interacting objects...; systems of objects happen when a program is
executed, and then they interact in some meaningful way only in actor
systems, while in both class and prototype systems it is procedure
instances (os perhaps threads) that interact.

pcg> Now let's try to add some more detail:

pcg> // the above plus ...

pcg> main()
pcg> {
pcg>   complex c1, c2;
pcg>   operator >>(cin,c1); operator >>(cin,c2);
pcg>   operator <<(cout,operator +(c1,c2));
pcg>   // or more briefly: cin >> c1; cin >> c2; cout << (c1+c2);
pcg>   exit(0);
pcg> }

pcg> Is this an OO program? 

vlad> No.

pcg> To my naked eye the above is an (outline of an) OO program, but it
pcg> contains only classes ('complex' and 'rational', variables ('c1',
pcg> 'c2', 'cin', 'cout') and procedures ('main', 'operator <<',
pcg> 'operator >>' 'operator +', and 'exit').

vlad> It contains only one class 'complex', 

Well, we also have 'rational' (the second bit is an extension of the
first bit, perhaps you have missed where I say "add"), which is not used
though -- fairly common, any given OO program usually mentions only a
small fraction of the ADT implementations provided in the environment in
which it is developed.

vlad> which is in this context a mere type.

Well, in C++ classes are types; so it's a type. But what do you mean by
"mere" here?

pcg> Objects do come into existence (thanks to the execution of
pcg> constructors) only during the _execution_ of the program, and they
pcg> are passed as arguments to various procedures at execution time
pcg> too; they don't seem to be contained in the *program*, and even
pcg> when they are contained in a computation created by executing the
pcg> program they don't seem to interact, any more than the arguments to
pcg> a procedure may be said to ``interact''.

vlad> The OO design

We were actually discussing "OO programs"; but then I don't see how OO
design is much different

vlad> describes objects and their behaivor at the run-time. Behavior and
vlad> classes, types and delegees and delegators can change on demand
vlad> during running the program.  So classes are usefull to describe
vlad> behavior of a object at given time but but not at another time.

Yes, but what's the relevance of this to the question of whether "OO
programs are systems of interacting **objects**" rather than systems of
modules (either classes or prototypes or actors) that ``contain''
procedures that invoke each other?

Do OO programs by and large describe static relationships between
modules (or parts thereof like interfaces)? Or do they describe
collections of instances/clones of those modules (or their types) and
how they interact?

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Cesar A. Gonzalez Perez]

Dong Oh Kim wrote:

>  1. Is everything OK with existing oo development methods?
>     If not, what are needed? and what stage should be enforced in the
>     future,i.e,analysis or design,etc...?

IMHO, we need more integration between OO methods and other technologies
such as components, client/server, document management, time-awareness,
databases, or distributed systems.
The difference betwwen analysis and design, although attacked by many,
makes a lot of sense since analysis "analyzes" the observed reality to
form a model of it, while design "designs" a computer-real model from
the previuos one. They're much different activities, and both absolutely
necessary.

>  2. Are you using a specific CASE tool?
>     If so, what are main advantages and disadvantages?

No, we're not using a CASE tool. They're usually too expensive and hard
to use. We're using the Fusion method on paper and ad-hoc Access
databases.

>  3. Did you have any experience of developing s/w systems by specific
>     OO method? If so, could you do with ease?

As I said before, we use the Fusion method and it's great!.

>  4. What's really needed to an engineer,who is not accustomed to OOP, to
>     develop a software by OO paradigm??

Be educated and trained properly, by people who _really_ understand the
OO paradigm. Notice that OOP (the P is for Programming, isn't it?) is
just a part of the OO way-of-doing, which involves OO analysis and
design, OO thinking, etc. (even OO pizzas and shakes, some say).

> Your opinion will help many people engaged in this area and better
> software development environment...

I'd love it does.

-- 
Cesar A. Gonzalez Perez
GTArPa/TI, USC
Spain

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Joachim Durchholz]

alaric@abwillms.demon.co.uk wrote 12.11.96:

> >Could anybody post a short characterisation of prototype languages?
>
> Basically, instead of creating a class, we instead create a blank
> object and insert methods into it. Any object of that 'type' is a kind
> of clone of that prototype object.

Hum, I think this description applies to class-based languages as well.  
Just say 'class' instead of 'blank prototype object'.
When are the methods inserted - at run-time? Then there's a real  
difference, but in that case I'm asking myself how they make sure no  
undefined routine is called. I see serious efficiency problems if these  
checks are done at run-time.

Regards,
-Joachim

--
Looking for a new job. Resume available on request. WWW version of resume
available under http://www.franken.de/users/herold/jhd/resume/index.html

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Snowball]

Robert C. Martin wrote:

> 
> Objects execute inside computers.  They take up memory space and CPU cycles.
> Classes are source code.  They specify the objects and create a structure
> from which the objects are created.
> 
This is true for C++ and some other languages, however for Smalltalk
Classes are 
objects which take up memory space (and sometimes CPU cycles). 

> Any method that concentrates on one more than the other is doing a disservice
> to its inventors and its users.  Rather we must focus on both.  We generally
> use dynamic models (i.e object diagrams, interaction diagrams, etc) to specify
> objects and the way that they interact.  We use static models (i.e. class
> diagrams, package diagrams, etc) to specify classes and the static
> relationships between them.

When we are talking about static and dynamic models, something bothers
me. There are 
two types of complexities in any system. One is the static or structural
(or 
sometimes I call it detail) complexity, the other one is dynamic
complexity. 
To me some canonical forms of systems such as class hierarchy can be
reasonably understood 
by static diagrams, however, it is not very intuitive to attempt to
model dynamic behavior 
in static diagrams such as object or interaction diagrams. I can
differentiate between 
structural complexity and dynamic complexity with an example: a car
engine totally taken 
apart and lying on the floor with all parts visible, and even sorted out
to parts, may 
create an atmosphere for us to develop a detailed understanding of each
part but will not 
give us a clear idea of how it runs. An engine timing diagram can help
us but the best way 
to understand how an engine works is to observe it "running" preferably
with a power to control 
the motion of the time domain. This means that we can take the engine,
replace one of the side walls 
of it with say a glass panel, and let it slowly run, even single step,
so that we can follow the 
entire motion. Same analogy for a software system running would be to
add a layered visual 
debugger and a reverse engineering tool to obtain and animate certain
diagrams to observe how the 
behavior of the system changes in time. (It just happens that I am
working on such a visual 
debugger for Smalltalk to be added to a tool I developed)

> There is a mapping between the two kinds of models that must be maintained.
> Every relationship on a dynamic model; that is, ever pathway accross which
> a message is sent; must be supported by a static relationship in a static
> model.

I totally agree here. To me, they are essentially two different views of
the same system. 
We are mostly defining the structure (time independent portion) of the
system with the static 
models, and we shape the behavior of the system (or how a system behaves
in time). 
Of course in many current languages there is a sharp distinction between
these two views 
although in the real world this distinction is thinner than we think.
For every system adaptation 
is a key to survival. Adaptation requires structural change. That means
adding and/or deleting 
classes, or changing class structure or behavior in time. If this is the
case the ?staticness?
(is there such a word?) of the static diagrams will not hold any more. A
correct class diagram 
for a system initially will not be the correct diagram after some
classes are added or modified 
dynamically. 

Tansel Ersavas
RASE Inc.
mailTo:tansel@deep.net
http://www.rase.com/

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Alan Lovejoy]

Jan Steinman wrote:
> 
> In article <32875B03.3729@iconcomp.com>, bill@iconcomp.com wrote:
> 
> > Alan Lovejoy wrote:
> > >
> > > I think you've hit the nail on the head.  I do distinguish between
> "design" and "coding".
> > >
> > > To me, the "design" of a program is a language-independent
> abstraction.  Implementation
> > > inheritance is a coding issue....
> >
> > I'd like to hear more about how you think design can be done
> > independent of language, and what such a "design" would look
> > like...
> 
> The biggest disasters I've seen were designed with the philosophy that the
> implementation vehicle was unimportant. (In fact, the January issue of The
> Smalltalk Report is rumored to have a column on this very topic... :-)
> Conversely, the most successful projects I've seen were ones where the
> designers were well-versed in the implementation language.
> 
> I think it is necessary for the designer to understand -- if not excel in
> -- the implementation vehicle. "Real" architects study civil engineering
> as well as architecture, or else they might design a skyscraper made of
> wood and paper.

My usage of the word "design" in the quote above is being interpreted in a way
other than I intended.  In the context of the earlier posts, it should have been
clear that by "design" I was referring to the objects that exist when the program 
runs, and how they interact.  And I was **defining** the term design as I had
used it, not trying to suggest that the implementation technology is not important,
or that one should not consider such issues when producing a design or implementing
a system!

For a design to be "language independent", it is sufficient that it be implementable 
in any language.  Whether it would be the optimal implementation in each language
is a different (although admittedly important) issue.

So I actually agree with your thesis.

> > I think it is impossible to progress very far from a domain
> > model into design without considering target language...
> 
> Here here!

Well, not **impossible**, just ill-advised.

> > > * When should delegation be used instead of inheritance?
> 
> Hmmm... how do you accomplish *that* in a language independent manner?

Again, I did not suggest that you should.

> Turn it over to a C++ coder, they might consider multiple inheritance,
> turn it over to a Smalltalker, they're going to think of general
> delegation.

Of course.  But the methodology should deal with this issue, and give the right 
answer for each language--or perhaps suggest that the wrong implementation language
is being used for the problem at hand.

> Programming is still a combination of art, craft, and science. Most
> methodologies I've encountered try to force programming entirely into the
> "science" realm. I think that is a mistake.

Yes, but the goal of scientific rigor is a good one.  Recognizing that we aren't
there yet can only be healthy, whether one is a methodology user or a methodology
researcher.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Alan Lovejoy]

Bill Gooch wrote:
> 
> Alan Lovejoy wrote:
> >
> > I think you've hit the nail on the head.  I do distinguish between "design" and "coding".
> >
> > To me, the "design" of a program is a language-independent abstraction.  Implementation
> > inheritance is a coding issue....
> 
> I'd like to hear more about how you think design can be done
> independent of language, and what such a "design" would look
> like.  I can see that the most abstract levels of design can
> be language-independent, but refinement from this level is an
> essential aspect (IMO) of doing good design.  Such refinement
> necessarily goes down through layers including language, frame-
> work, database,... dependencies; in fact, it takes into account
> *all* requirements, including hardware constraints.
> 
> If you don't agree that all of this is important in producing
> good designs, then I have a question: what do you call a
> program specification, not involving code, which does take
> these issues into account?

Oh dear.  I think what we have here is merely :-) a terminology problem.

There is a difference between design methodology, the process of producing a design, 
and the result of that process.  Unfortunately, the term "design" (without modifiers)
can be applied to any or all of these things.

Please believe that I am well aware of the fact that one absolutely must take the 
idiosyncracies of the implementation technology (such as the programming language)
into account in desgining and coding a program. I'm sorry that so many people seem
to think I have suggested otherwise!

Any "program specification" that could be used to actually execute a program,
or generate an executable program, is by definition a program text, and the notation
in which it is written is in effect a programming language.

"Programming languages" such as C or Smalltalk are designed so that human beings
find it convenient to write program texts in them, and also so that computer programs
can translate such texts into equivalent programs that execute efficiently on typical 
hardware.

Design notations have a different purpose: to communicate what the design of the
program is to human readers--often ommitting details that should be specified
if the program actually needs to be executed by a computer.  However, those
details should be **optionally** specifiable, so that those cases in which
such details are important at the "design level" can be dealt with there.

My thesis is that a design **methodology** should be able to handle designing
a program regardless of language, although it will certainly need to take the
differences between langauges into account.  If I have to use a completely
different methodology for each part of the system that is implemented in a
different language, something is wrong.

Similarly, the design notation should be flexible enough to handle any and
all implementation languages.  One may use different capabilities of the
notation and/or and specify different designs due to the intended target
language.  But if the notation becomes completely worthless in the face of
an implementation language such as Self, perhaps there is something wrong with 
the notation (and/or its underlying object metamodel) at a fundamental level.

> I think it is impossible to progress very far from a domain
> model into design without considering target language, and
> the other things I've mentioned.  A very abstract design, not
> considering these issues, may be useful some of the time, but
> the design one actually implements *must* consider them.
> 
> > Many seem to think that the class hierarchy **is** the design! ...
> 
> Well, I do not.  But there are many levels of design, and
> it is important to ultimately be specific.

Agreed.  I am reacting to all the times I've seen people start their design process
by drawing class hierarchies.

> > The issues that a design methodology should address with respect to implementation inheritance
> > would be questions such as the following:
> >
> > * Just because two objects have the same behavior may or may not mean that they should
> > inherit the shared behavior.  The methodology should provide the guidance needed to
> > resolve this issue (is the fact that the behavior is the same simply accidental, or
> > does it depend upon some reliable invariant?  How likely is it that a changed requirement
> > will necessitate changing the behavior of one of the objects, but not the other?).
> >
> > * When should delegation be used instead of inheritance?
> >
> > * When should the Strategy pattern be used instead of inheritance?
> 
> I agree that IWBNI methods could help with these things.
> I don't know of any method that even comes close, however.
> This is why design remains largely a black art - not the
> best situation, but it's the way things are.  I'd really
> like to hear from anyone who can suggest how to address
> questions such as the ones Alan has raised here in a
> method(olog)ical or systematic fashion.

Yep.  The methodologists have some work to do.  I think patterns have started the right
things happening in this regard.

> > However, implementation inheritance should be treated as a refinement of the design, not
> > as the body and soul of it.
> 
> From the last, I gather that in some sense, we are in
> agreement.  But again, what do you call this refinement,
> if it isn't another (more specific, closer to code) layer
> of design?

Implementation?  But again, I think we are arguing terminology, not substance.

My practice has been to use the term "design" in way that is apparently more abstract
than those who have read and objected to my posts.  

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Anthony Menio]

On 11 Nov 1996, Piercarlo Grandi wrote:
> 
> Do OO programs by and large describe static relationships between
> modules (or parts thereof like interfaces)? Or do they describe
> collections of instances/clones of those modules (or their types) and
> how they interact?
> 
> 
In addition to the comments made in my last post I though following
would offer a clear and correct answer. Systems with an object
oriented architecture consist of objects. Classes are merely blue
prints to create objects from. Just as a building
is made of beams, rooms,prefab components and cars of
transmissions,radiators,exhust systems system  and not
the blueprints of these things so with an OO software system.
The essence of OO architecture is the viewing
of abstract systems in terms of the real world, ie as if the were
physical systems. Thus it a fundamental process to
resolve such questions through examing systems of the source
domain of the metaphor to gain a better understanding
of conceptual issues in the target domain. 

Anthony Menio
I.S. Student
menio@pegasus.montclair.edu

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Anthony Menio]

On 11 Nov 1996, David N. Smith wrote:
 
> The design of a program should be an integral part of the design of the
> implementation of a program which should be an integral part of the
> coding of a program. This does not mean there is so separation between
> the parts. Car companies still have designers, design engineers,
> manufacturing engineers, and assemblers. These people with different
> points of view need to work together as partners, with the designer
> cognizant of enough of the details of the target language not to get in
> too much trouble, and the ultimate programmer cognizant of enough of the
> high-level design to understand where it all is going.
> 
> Failing to consider the language at design time can leave issues open
> that need to be closed. If the designer has learned 'object design' but
> has never programmed an object, a condition I fear happens all to often,
> is the design suitable for implementation and maintenance in any language?
> 
> Please note that I am not saying that it is impossible to implement
> designs thrown over the wall from a designer who doesn't consider
> language. I am suggesting that such designs can lead to very poor
> programs. Since programs are the ultimate product of the whole process,
> and it is the program that will be used, lived with, maintained, or
> thrown away, it is the program that matters, not the original design. To
> the extent that a programmer had to perform heroics to fit a design to a
> language, the design has failed and the resulting product is the poorer
> for it.
> 
> Dave
 
 
System development is really just model building, the
deliverable of each subprocess of the design process
is simply a model, a description of the system, which the
next subprocess takes as it input. Thus these models
should be seemless, the next can be built from the
previous while maintaining as much consistancy as possible.
The whole point of design model is to turn the analysis
model into descriptions of the classes of objects identified
in light of the given implementation environment as the
next phase in the development process is implementation. Thus
design must consider the language used, operating system
and performance considerations of the environment. However
analysis does not, it assumes an ideal environment so its
possible to developed this model in a totally language
independent manor as you are only concerned with the
objects in the system and the behavoiral relations
between them. This is obviously an iterative process
as well as one where there can be reverse flow. I
think this is in agreement with engineering practice
and industrialization process in other industries. This
as it should be as the key of OO is the ability to
reuse the engineering principles applied to physical
systems, as we wish software systems to have
the same attributes we expect of real world systems.

Anthony Menio
I.S. Student
menio@pegasus.montclair.edu

	Your power is your ideas, your ideas are products of
	perception, your perception is the product of your
	architecture, architecture is everything - me

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Anthony Menio]

On Mon, 11 Nov 1996, Daniel Drasin wrote

> You are both right (and wrong).  The question is, what is the point of
> the distinction.  P.G.  Just 'cause you can't "see" the objects doesn't
> mean that they're not there.  E.g. A psychiatry textbook will describe
> behavior of "humans," "men," and "women."  These are types but clearly
> in actual application, these "laws of psychiatry" apply to the actual
> individual people involved.  
> 
> Smalltalk, C++, and java use what's called "class-based programming"
> which
> means that the behavior of individual objects is described by its 
> type or class.  Therefor classes will be manipulated in order to affect
> the behavior of objects.  Which leads back to by origional question:
> What is the point of the distinction?  What is the point of saying
> that an OO program is the interaction of objects (and not classes)?
> If the point is to direct the student to understand the runtime behavior
> that needs to be focused on, then objects are what the program consists
> of (ognoring the reflective meta abilities...).  However, if the aim
> is to understand what must be created at compile time in order to
> create a program, then "classes" are the elements are the program.
> 
> Dan


The classes are simply blue prints of the the objects which
can be created, and thus describe the attributes and behavior
of objects. The runtime system consists of objects and these
are what must be specified and the interactions between them
at implementation time. Your source code consists of instances
of these classes and the messages you designate to have
happen and the states and messages these result in across the
system. The messages you designate might simply create the
system (constructors) and determine interobject relations and
than wait for user messages.The system
you build is thus described by the objects created and the 
methods you specify to be called
and the states these create and manipulate a runtime.
Classes are simply blueprints and thus describe the
domain of states and possible behaviors an instance can
assume. A software system consists of assumed behavoirs
and determined behavoirs in response to runtime
user messages and thus of objects.
In terms of source code your system is really 
object creations and method invocations that occur at runtime
implied by code like the following:

Application my_App();

myapp.setDbase("Oracle");

FileSever netsever10(CURRENT_IP);

requestObject *action= application.idle();

if (interupt)
{
netserver.request(requestObject);
myapp.continue(requestObject);
}

further more even this is simply a blue print for
the system as a whole the true system only exists at runtime
however even its implementation description refers to definite
articals to be created ie objects. I think this distinction
maybe subtle but is important.  

Anthony Menio
I.S. Student
menio@pegasus.montclair.edu

	Your power is your ideas, your ideas are products of
	perception, your perception is the product of your
	architecture, architecture is everything - me

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Piercarlo Grandi]

>>> "drs" == drs  <drs@inxpress.net> writes:

[ ... much omitted,including an outline for a class 'complex' ... ]

piercarl> main()
piercarl> {
piercarl> complex c1, c2;
piercarl> //etc.
piercarl> }

piercarl> Is this an OO program? It's hard for me to see any objects in
piercarl> it either for I can only see variables (memory objects, a
piercarl> different concept) and they don't interact with each other in
piercarl> any sort of interesting meaning of the word.

drs> Well, c1 and c2 are indeed instantiations of the above prototype;

Which ones? (rhetorical question alert)

drs> they have a defined address and can do things (unlike the
drs> prototype).

What can they do? (rhetorical question alert)

drs> You're wrong if you think c1 and c2 are not objects; they
drs> are. entities of the class complex create their own scope, which is
drs> internal and allows internal processes. This really is quite
drs> different from C.

Oh no, oh please -- we have been on this subject for the past few months
(and before that a few years ago with the "simply put an object is a
variable" thread). Not again, not so soon. Oh no, not again.

Well, I'll then quote high authority, Grady Booch, hoping that it will
be enough:

OOADWA>     Suppose that we have the following declarations:

OOADWA>   StorageTank s1,s2;
OOADWA>   WaterTank w;
OOADWA>   NutrientTank n;

OOADWA>   Variables such as 's1', s2' w, and 'n' are not objects. To be
OOADWA>   precise, they are simply names that we use to designate
OOADWA>   objects of their respective types: when we say ``the object
OOADWA>   's1''' we really mean the instance of 'StorageTank' denoted by
OOADWA>   the variable 's1'. We will explain this subtlety again in the
OOADWA>   next chapter.

Too bad that the next chapter does not really contain a good
explanation, butnthis should be enough.

drs> Now, if your idea is that "Object-oriented" boils down to message
drs> sending, then I think you're correct;

Oh no, not again, I think I have participated in thread on this very
same subject at least three times in as many years. Oh no, not again. 

drs> but by that definition there are only a few true "object-oriented"
drs> languages, and C++ is not one of them.

Oh no, not again, I think I haveparticipated in threads on this very
same subject at least N times in as many years. Oh no, not again.

Well, as the saying goes, repetition is the very essence of USENET,
whose very essence is repetition, as somebody said.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Alaric B. Williams]

jhd@herold.franken.de (Joachim Durchholz) wrote:

>alovejoy@concentric.net wrote 08.11.96:

>> > I think this is a bit misleading.

>Seems I got mislead my self a bit :)

>> execution of a program.  And in a Self program, classes never exist at all
>> (not even in the program text).

>Well, I don't know Self (or any other prototype language), so I'm a bit  
>bewildered about what you say about this statement.
>Could anybody post a short characterisation of prototype languages?

Basically, instead of creating a class, we instead create a blank
object and insert methods into it. Any object of that 'type' is a kind
of clone of that prototype object.

In Self, this is implemented by parent pointers in objects that refer
to the objects they derive from. EG, point objects derive from a
prototypical point ("traits Point"). They contain overriden x and y
variables, so they have individual identity (otherwise, they'd always
refer to the prototypical x and y objects in the prototype point).

This is kinda cool for some things!

ABW
--

"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."

(Windows for Early Warning and Defence User's manual P385)

Alaric B. Williams Internet : alaric@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Robert C. Martin]

In article <Jan-0611961134040001@news.imagina.com>, Jan Steinman
<No@Junk.Mail.Please> wrote:

> In article <55pqr5$136a@grimsel.zurich.ibm.com>, Paul_Gover@uk.ibm.com wrote:
> 
> > In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim
> <kdo@kyebek3.kjist.ac.kr> writes:
> > > ...
> > >Let me have your opinions about followings:
> > >
> > > 1. Is everything OK with existing oo development methods?
> > >    If not, what are needed? and what stage should be enforced in the  
> > >    future,i.e,analysis or design,etc...?
> > > ...
> > 
> > OK, here's my 2 cents: most OO development methods concentrate too much
> > on objects and too little on classes...
> 
> Gee, in my 8 month experience with one well-known methodology, I felt just
> the opposite! It was impossible to model instance-specific behavior
> without pretending it was a class. Of course, we might just have been
> using it wrong...

Objects execute inside computers.  They take up memory space and CPU cycles.
Classes are source code.  They specify the objects and create a structure
from which the objects are created.

Any method that concentrates on one more than the other is doing a disservice
to its inventors and its users.  Rather we must focus on both.  We generally
use dynamic models (i.e object diagrams, interaction diagrams, etc) to specify 
objects and the way that they interact.  We use static models (i.e. class 
diagrams, package diagrams, etc) to specify classes and the static
relationships between them.  

There is a mapping between the two kinds of models that must be maintained.
Every relationship on a dynamic model; that is, ever pathway accross which
a message is sent; must be supported by a static relationship in a static 
model.

For example, if object A sends a message to object B, then there must
be a class relationship somewhere that supports that.  For example, the
relationships might be an "aggregation" relationship between the class
of A and the class of B.  Or it might be an 'association' between
one of the base classes of A and one of the base classes of B, etc.

Static models, when developed in the absense of dynamic models, cannot be
proven correct.  They often have missing relationships and unnecesary
relationship because the suite of relationships was untested by dymnamics.

On the other hand when dynamic models are developed in the absense of static
models, the structure of the software is seldom as flexible and maintainable
as needed.  Opportunities for reuse and robustness are lost.  The code
becomes interdependent and slowly rots.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

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

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Robert C. Martin]

In article <328109CD.6685@concentric.net>, Alan Lovejoy
<alovejoy@concentric.net> wrote:

> The architecture and design of a program is a function of what
**objects** it contains and 
> how they interact. 

I disagree.  The architecture of a program is a function of the way
it manages to decouple the source code while allowing the interactions
to remain unaffected.  

This is true irrespective of language.  It is as true in Smalltalk as
it is in Java or C++.  Whenever one neglects to manage the static relationships
between source code units, one winds up in trouble.

> Class inheritance is an abstraction mechanism for code sharing.  It has
nothing much to do 
> with architecture or design of a program.  Proof: any program using
class inheritance can
> easily be converted into a completely equivalent program where all the
leaf classes are root
> classes: 

This is truer for Smalltalk than it is for Java or C++.  But it isn't really
even true in Smalltalk.  Consider, that the way your two systems are affected
by a change in specifications is very different.  In the flattened model,
the classes can, and must, be changed independently.  
But in the hierarchical model a change in the middle of a hierarchy affects
all those classes that depend upon it.  Thus, the design of the heirarchy
must take into consideration the most likely changes that will occur; and
should strive to minimize the effort involved in making those changes.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

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

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Jan Steinman]

In article <32875B03.3729@iconcomp.com>, bill@iconcomp.com wrote:

> Alan Lovejoy wrote:
> > 
> > I think you've hit the nail on the head.  I do distinguish between
"design" and "coding".
> > 
> > To me, the "design" of a program is a language-independent
abstraction.  Implementation
> > inheritance is a coding issue....
> 
> I'd like to hear more about how you think design can be done
> independent of language, and what such a "design" would look
> like...

The biggest disasters I've seen were designed with the philosophy that the
implementation vehicle was unimportant. (In fact, the January issue of The
Smalltalk Report is rumored to have a column on this very topic... :-)
Conversely, the most successful projects I've seen were ones where the
designers were well-versed in the implementation language.

I think it is necessary for the designer to understand -- if not excel in
-- the implementation vehicle. "Real" architects study civil engineering
as well as architecture, or else they might design a skyscraper made of
wood and paper.

> I think it is impossible to progress very far from a domain 
> model into design without considering target language...

Here here!

> > * When should delegation be used instead of inheritance?

Hmmm... how do you accomplish *that* in a language independent manner?
Turn it over to a C++ coder, they might consider multiple inheritance,
turn it over to a Smalltalker, they're going to think of general
delegation.

Programming is still a combination of art, craft, and science. Most
methodologies I've encountered try to force programming entirely into the
"science" realm. I think that is a mistake.

 : To foil junk mailers, REPLY won't work. Please paste address in.
 : Jan Steinman <mailto:Jan@Bytesmiths.com>
 : Bytesmiths <http://www.bytesmiths.com>
 : 2002 Parkside Court, West Linn, OR 97068 USA, +1 503 657 7703
 : Java: the elegant simplicity of C++ and the blazing speed of Smalltalk.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Alan Lovejoy]

Robert C. Martin wrote:
> 
> In article <328109CD.6685@concentric.net>, Alan Lovejoy
> <alovejoy@concentric.net> wrote:
> 
> > The architecture and design of a program is a function of what
> **objects** it contains and
> > how they interact.
> 
> I disagree.  The architecture of a program is a function of the way
> it manages to decouple the source code while allowing the interactions
> to remain unaffected.
>
> This is true irrespective of language.  It is as true in Smalltalk as
> it is in Java or C++.

I have to admit that I don't really understand what you mean. Perhaps you could 
clarify?

> > Class inheritance is an abstraction mechanism for code sharing.  It has
> nothing much to do
> > with architecture or design of a program.  Proof: any program using
> class inheritance can
> > easily be converted into a completely equivalent program where all the
> leaf classes are root
> > classes:
> 
> This is truer for Smalltalk than it is for Java or C++.  But it isn't really
> even true in Smalltalk.  Consider, that the way your two systems are affected
> by a change in specifications is very different.  In the flattened model,
> the classes can, and must, be changed independently.
> But in the hierarchical model a change in the middle of a hierarchy affects
> all those classes that depend upon it.  Thus, the design of the heirarchy
> must take into consideration the most likely changes that will occur; and
> should strive to minimize the effort involved in making those changes.

The design/architecture of the **source code** of a program (what you called
the "static model" in another post, assuming I understood you) is different than the 
desgign/architecture of the program as it exists at execution time (what you called 
the "dynamic model").

As I have used the term "design" in earlier posts, it refers to what you have called
the "dynamic model" (assuming I have correctly understood you). My thesis is not that 
the "static model" is unimportant, but rather that one needs to know what dynamic model 
one wants to achieve before one can optimally derive a static model.  The dynamic model 
is the heart of the design, because it is where the real work gets done, and because
the purpose of the static model is the specification of the dynamic model.  You can't
implement a good static model that specifies a dynamic model without having a good idea 
of what dynamic model you intend to specify!

That being said, I completely agree that a "flat" class library with no inheritance is 
not a good idea. I mentioned it solely to highlight the difference between the static and  
dyanmic models.

Finally, this thread started with the claim that there wasn't enough focus on class 
inheritance in the static model in typical design methodologies.  I and some others 
objected to this, because in our experience typical methodologies don't have sufficient 
support for handling the dynamic model, and overemphasize static modelling issues such as
class inheritance.  In view of the OO languages such as Self that don't even have classes,
one has to question how central class inheritance (as opposed to type inheritance) really
is to even static modelling (not that getting inheritance right is easy, or that getting
it wrong is inconsequential).  The earlier posts should be interpreted in that context.

Bottom line: "Design" involves much more than class hierarchies.  

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Alan Lovejoy]

Robert C. Martin wrote:
> For example, if object A sends a message to object B, then there must
> be a class relationship somewhere that supports that.  For example, the
> relationships might be an "aggregation" relationship between the class
> of A and the class of B.  Or it might be an 'association' between
> one of the base classes of A and one of the base classes of B, etc.

Really?  Supose the implementation language has objects, messages and methods,
but no classes?  For example, a program written in Self.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Nick Thurn]

Alan Lovejoy (alovejoy@concentric.net) wrote:
[...]
> 
> Design notations have a different purpose: to communicate what the design of the
> program is to human readers--often ommitting details that should be specified
> if the program actually needs to be executed by a computer.  However, those
> details should be **optionally** specifiable, so that those cases in which
> such details are important at the "design level" can be dealt with there.
> 
> My thesis is that a design **methodology** should be able to handle designing
> a program regardless of language, although it will certainly need to take the
> differences between langauges into account.  If I have to use a completely
> different methodology for each part of the system that is implemented in a
> different language, something is wrong.
> 
Alan,

I think you are refering to what I would call domain modeling or analysis.
 
> Similarly, the design notation should be flexible enough to handle any and
> all implementation languages.  One may use different capabilities of the
> notation and/or and specify different designs due to the intended target
> language.  But if the notation becomes completely worthless in the face of
> an implementation language such as Self, perhaps there is something wrong with 
> the notation (and/or its underlying object metamodel) at a fundamental level.
>
Big ask! Personally I prefer something that fits *my* needs not tries to be
all things to all people. 
 
> 
> Agreed.  I am reacting to all the times I've seen people start their design process
> by drawing class hierarchies.
>
This may or may not be appropriate, horses for courses!

[...] 
> Yep.  The methodologists have some work to do.  I think patterns have started the right
> things happening in this regard.
> 
> Implementation?  But again, I think we are arguing terminology, not substance.
> 
> My practice has been to use the term "design" in way that is apparently more abstract
> than those who have read and objected to my posts.  
> 
I fear you are confusing analysis with design. I agree analysis should be largely
language independent (I guess this means you don't do any if you're creating
a C++ library :-). Design should not *be* implementation but it can not be done
without regard to the limitations and idiosyncrasies (?) of the implementation
language.

cheers
Nick (my opinions only)

> --
> Alan L. Lovejoy		|==============================================| 
> Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
> alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Nick Thurn]

Alan Lovejoy (alovejoy@concentric.net) wrote:
> 
> My usage of the word "design" in the quote above is being interpreted in a way
> other than I intended.  In the context of the earlier posts, it should have been
> clear that by "design" I was referring to the objects that exist when the program 
> runs, and how they interact.  And I was **defining** the term design as I had
> used it, not trying to suggest that the implementation technology is not important,
> or that one should not consider such issues when producing a design or implementing
> a system!
> 
Alan,

These objects interpreted (compiled at runtime) or otherwise are 
surely the products of implementation. You seem to presuppose an implementation
which leads to a design, isn't this backwards?

The objects that exist when the program runs are a mixture of implementation
objects, domain objects, library objects, ui objects, comms... etc. Trying to
think back from them seems very unhelpful. IMHO even thinking *forward* to
these implementation objects too early is dangerous. 

Do you mean this or do I have it wrong?
 
cheers
Nick (my opinions only) 

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Richard A. O'Keefe]

jhd@herold.franken.de (Joachim Durchholz) writes:

>> execution of a program.  And in a Self program, classes never exist at all
>> (not even in the program text).

>Well, I don't know Self (or any other prototype language), so I'm a bit  
>bewildered about what you say about this statement.
>Could anybody post a short characterisation of prototype languages?

Here it is in one line:
    - objects inherit methods and fields from *other objects*.

In Self, for example, an object is a collection of named slots, some of
which contain methods, some of which contain data, and some of which
contain references to other objects called "parents".  An object need
not have _any_ parents, may have one, or may have more than one.  If
a slot is needed for an object that doesn't directly contain a slot
with that name, the parents are searched.  A parent slot may be changed
at any time, so "mycar" may reparent itself from "vehicle" to "scrap_metal"
at any time...

>Not in all cases. Most OO languages have abstract/virtual/deferred classes  
>that primarily serve to specify external behaviour, not implementation.

In the OO languages I am familiar with, nothing prevents an abstract
class providing implementations of _some_ of its methods, and this is
very often done.

>I definitely agree that inheritance can be used for code sharing, but it  
>is also useful for object classification.

The trouble is that there are applications where the way an object should
be classified (without changing its identity) varies with time.  And
even when that doesn't happen, the two hierarchies don't necessarily line
up perfectly (which is why Java has both 'interfaces' which refer to
`is-a' and 'classes' which refer to `is implemented using parts of').

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Richard A. O'Keefe]

piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

>The observation above is, as per your remark, strictly speaking not
>general enough; but then just saying "OO module" instead of "class"
>would give it generality.

Yes, but it would provide generality by means of obscurity and vagueness.
What, for example, is an "OO module"?  I am aware of several languages
having both objects and modules:
 Ada 95 (module=package, object=tagged record instance)
 ISO Pascal Extended with Object-Oriented Extensions to Pascal
	(module=module, object=object=pointer to extended record)
 Oberon-2
 Common-Lisp/CLOS (module=package, object=class instance)
 C++ (module=translation unit maybe, or better, namespace; object=record)
so the term "OO module" seems to mean something like "module containing OO
components".


>For whether class or prototype based, an OO program is a collection of
>(OO) modules, and values at runtime are either instances of a class or
>clones of a prototype.

(1) In Self, it's not who you are _cloned from_ that determines your
    properties, but who _your parents are_.  The nearest analogue of
    a class would be a partial function from parent slot names to
    objects, e.g. the "class" (parent*=o123, uncle*=o125, locale*=o23)

(2) The parents of an object can vary through time.

>OO programs (as opposed to their executions) do occasionally contain
>some instances or clones, but this does not justify the observation that
>"OO programs are systems of interacting **objects**".

It seems to me that there may be an equivocation involving the word
"program" here.  Even for C++, it is true that
    "the EXECUTION of a program is a system of interacting objects".
You are saying "even for a prototype based language, a program is
statically composed of classes and methods", but once again, nothing
says that an OO language has to be batch compiled.  In the static
sense which I think you have in mind, no "program" as such need ever
exist.

>While the analysis and design of an OO program may/should be based on
>some mental image of how it is going to be executed, both activities are
>really about deciding into which ``encapsulated'' concepts and modules
 ^^^^^^
>to decompose the solution to a problem, and not into which
>``interacting'' objects (even if in some languages OO modules are
>objects, and in some others objects to interact).

Is the Sun "really" a nuclear reactor or is it "really" just a big ball
of hot gas or is it "really" a source of heat and light?

I don't think anyone is denying that the "analyse, design static structure,
build static structure, light blue touch paper and stand well back" approach
is appropriate for a very large number of applications and projects.  (I am
reading this in comp.lang.ada, after all, and I wouldn't be using Ada if I
didn't think that was the right way to do some things.)  The point is that
it doesn't _have_ to be that way for _all_ applications and projects, and
there _are_ languages permitting a different mindset.  In particular, I
cannot imagine why anyone would want to rule out meta-design, where your
program _at run time_ constructs new 'OO modules' (whatever they are) with
good interfaces and starts using them.  It's not too much to say that that's
exactly how the Newton works.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Alan Lovejoy]

Nick Thurn wrote:
> 
> Alan Lovejoy (alovejoy@concentric.net) wrote:
> >
> > My usage of the word "design" in the quote above is being interpreted in a way
> > other than I intended.  In the context of the earlier posts, it should have been
> > clear that by "design" I was referring to the objects that exist when the program
> > runs, and how they interact.  And I was **defining** the term design as I had
> > used it, not trying to suggest that the implementation technology is not important,
> > or that one should not consider such issues when producing a design or implementing
> > a system!
> >
> Alan,
> 
> These objects interpreted (compiled at runtime) or otherwise are
> surely the products of implementation. You seem to presuppose an implementation
> which leads to a design, isn't this backwards?
> 
> The objects that exist when the program runs are a mixture of implementation
> objects, domain objects, library objects, ui objects, comms... etc. Trying to
> think back from them seems very unhelpful. IMHO even thinking *forward* to
> these implementation objects too early is dangerous.
> 
> Do you mean this or do I have it wrong?

Pardon me, I see I wasn't clear.  The "dynamic model" or "dynamic design" **deals with**
or **is concerned with** the objects that will exist at run time, what roles they will
play, what responsibilities they will have and how they will interact.  Of course the
run time objects are NOT themselves the design (in spite of the fact that my imprecise 
wording might give one the impression that I was saying that).

Many objects that exist at run time may have internal mechanisms that you have no
control over, such as those that may be instantiated from classes in the standard
library.  You can of course always choose not to use such "standard" or "system"
objects, and in some languages (such as Smalltalk) you may be able to easily change
them, but simply using them as-is is what usually happens.  You don't need to design
such "standard" objects, but you do need to know how to interface to them, and 
decide what roles (if any) they will play in your system.

Perhaps a concrete example will clear up the confusion.  The Model-View-Controller
concept is now familiar to many, so I will use that as the example.

The inventor of MVC (Trygve Reenskaug) calls the MVC architecture an example of what
he calls a "role model."  A role model specifies what objects collaborate together
in the "role model," and what the role of each object is in the collaboration.

The MVC "role model" specifies that there are three objects, a "model," a "view" and
a "controller" that collaborate in an MVC "role model."  The objects are named according
to the role that each plays.  It may be that more than one object will play the same
role as another, but that does not happen in the basic case of the MVC role model. It
may also be that the same object will play more than role, perhaps because it is also
a collaborator in a different role model.  Complex designs are constructed by composition
of multiple role models.

The responsibility of the "view" in the MVC role model is to graphically display informaition
about the state of the model. The responsibility of the controller is to get and respond to 
user input. The responsibility of the model is to maintain displayable state.  A formal
role model would specify the messages each object in the role model will send to the
other objects, what events would prompt the sending of such messages, and what the semantics 
of those message are.

The collaborating objects in a role model are understood as instances, not classes.  And a 
role is a function of a) the responsibility of an object and what purpose it serves, b) the 
messages that it will be expected to respond to (which might well be a subset of all the 
messages it could respond to), and c) the messages it will send to other collaborators
(which might not be all the messages it could send, nor all the receivers to which it may
potentially send messages).  The MVC role model does not just say that there are models,
views and controllers, and that they send certain messages to each other.  It specifically
says that a particular model, a particular view and a particular controller must collaborate
together.  The view can't collobarate with just any model it happens to find in memory.
It becomes associated with a particular model and controller, and collaborates with those
particular objects.  Object identity matters, and is explicitly dealt with.  If you want
to dynamically change which model the view and controller are associated with, that change
has to become part of the protocol specified by the role model.

From this it should be clear that roles are not classes.  One can use multiple inheritance,
dynamic typing with polymorphism, interfaces or dynamic delegation in order to put any object 
into one of the roles.  It just has to correctly respond to all the messages specified by the
role, and send only those messages allowed by the role.  This is of course easier to do
in a dynamically typed language, but it can also be done in statically typed languages
that support interfaces or multiple inheritance.

I wholeheartedly endorse role modelling, and recommend doing it **before** trying to worry
overmuch about the class hiearchy.  Wouldn't it be nice to identify the role models in which
the objects in your program will participate before designing the class hierarchy that will
provide the classes whose instances can be collaborators in those role models?

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Ell]

Alan Lovejoy (alovejoy@concentric.net) wrote:
: Bill Gooch wrote:
: > I'd like to hear more about how you think design can be done
: > independent of language, and what such a "design" would look
: > like.  I can see that the most abstract levels of design can
: > be language-independent, but refinement from this level is an
: > essential aspect (IMO) of doing good design.  Such refinement
: > necessarily goes down through layers including language, frame-
: > work, database,... dependencies; in fact, it takes into account
: > *all* requirements, including hardware constraints.

: Oh dear.  I think what we have here is merely :-) a terminology problem.
: 
: There is a difference between design methodology, the process of producing a design, 
: and the result of that process.  Unfortunately, the term "design" (without modifiers)
: can be applied to any or all of these things.

As I observe, most in the software engineering area use the term "design" 
similar to what Gooch is saying above.  *Implementation* of analysis.
Otherwise there is a muddle.

Elliott

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Ell]

Alan Lovejoy (alovejoy@concentric.net) wrote:

: If the same class hierarchy can be used to create many different
: programs
: (without defining any new classes or methods), then it should be obvious
: that the class inheritance hierarchy and program architecture and design
: are not at all the same things! 

Earlier I should have said that using the term "design" in a non-standard
way can lead to incorrect thinking about related issues.

I think you need to distinguish analysis from arcitecture from design. 
From what I gather in my experience in and readings on the development
phases, analysis examines requirements and traditionally in sw engineering
posits a logical solution.  Architecture takes that and creates an overall
physical design for implementation based in large part on language. Design
is mostly considered to be subsystem and category/object creation - though
architecture is the first part of it. 

I agree with you however that polymorphism/subtstitution in analysis
should be portrayed as a kind of non-specific (indefinite :-)
generalization rather than inheritance.  And that inheritance if
applicable should only first show up in architectural blueprints.

Elliott

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Peter Pflaum]

*SYNERGY-NET on http://metro.turnpike.net/~pflaump
http://www.altavista.forum.digital.com/ Floor 503 
If you need other assistance, please write to
synergy@mail.trevista.com (do not reply to this e-mail).

RE: Punctuated Equilibrium - PC revolution II How to survive ?

The recruits to a tough training program are traditionally told
to "Look to the right, look to the left, one of you won't be here
next year." Sixty five million years ago, at the annual meeting
of the Dinosaurs /IBM/MS/PC Productions Inc. they heard a talk by
the current management guru about becoming small, fast and furry.
They were told, their survival depended on their ability to adapt
to the rapid changes in their global environment. The huge
Dinosaurs looked at each other and wondered how they were going
to change from large, cold blooded reptiles to mammals. The
motivational speaker suggested "visualization". They should relax
and imagine "in their minds" eye that they were small, fast and
furry. If they had a "positive" attitude nothing was impossible.
It didn't work.

Almost all species that ever existed are extinct.

Human, as all creatures large and small ( except maybe insects )
are not biologically designed for rapid change. What happens is
mass extinctions. The space ( niches ) made by short periods of
extinctions are then slowly filled ( somewhat at random ) by the
survivors. Species survive by geographic dispersion and innate
variety. 

How to survive the mass extinction that NC's will cause among PC
's or how to become very small, very fast and very furry.

The high ground is an expanded vision of the ISP ( Internet
Service Provider ) and this will happen a order of magnitude
faster than most people think.

RE: EPCOT II: Electronic Prototype Community On-line Technology

MS/GE/NBC, ATT, MCI/BT, Oracle/Netscape/Sun - ( and others )
evolve and create new networks of low orbit satellites, earth
stations, transponders, cells, wires, cables, something like the
NSA/DOD and Navy global communications systems. For big
organizations the systems are almost in place, for middle size
companies they are serviced from "EPCOT II Club Houses ", and
individual consumers on a ad hoc basis using AS phone modems,
cable, dishes, microwaves and what ever sort of works. The earth
stations are all purpose servers using object management multi-
channel programs to provide complete on-line services.  (IIOP)

So you can do a lot of things from almost anywhere. EPCOT II is a
set of franchise EPCOT II clubs offering work station cubicles to
office suites with T3 satellite up links. Within their zone they
are a quality Internet Service Provider ( ISP ) for the big
organization and individual users. People can work on the
road or at home, so they can live in some very nice places. The
current market targets are places where there is already a high
density of high tech users. The idea is "synergy" shared
resources rather than stand alone systems. The idea is "plug and
play" turn-key utilities rather than complex on-site equipment
and operations. Larry ( Oracle ) has it about right but is a
little possessive, Marc (Netscape) understands the technology and
Bill (MS) who is very possessive will get on board by the end of
the year. 

Where do you want to be, alone on the California coast, in a
planned community in Costa Rica, The Swiss or Colorado Mountains,
New Zealand or Australia, the French Riviera, a Greek Village;
the EPCOT work and pay master will help you do your work, using
temporary synergy groups, video conferences, high quality
image processing, what ever, where ever. 

EPCOT II global work groups can produce content, hardware,
software, server management, education and training, video, web
pages, news, applications what ever. It's a company made of off
site locations, with a temporary work group and employment
agency, it's a server of home and remote work locations, it's a
hotel, it's a cafe, it's a node and ISP, it's a planned physical
place and network of hard wired connections between international
high-tech communities of transponders, cables and phones.  It is
the Electric Prototype Community on-line Technology of today and
tomorrow, the global village, the world according to Charles
Handy. 
see http://metro.turnpike.net/~pflaump/hotflash.htm for AS lines and
communications systems.
http://www.washingtonpost.com/wp-srv/WPlate/1996-11/12/098L-111296-idx.html 
Wireless connections:  businesses and schools that have
     been trying out a system that beams data from the Internet to their
     computers using high- frequency radio waves. The wireless
     technology allows users to travel in cyberspace at about 10 million
     bits per second, nearly seven times faster than today's high-speed
     data lines and almost 350 to 700 times faster than the average
     modem.

     "The speed is just blinding," said Stephen Coran, a partner at the
     firm who uses the Internet to search legal databases.

     The radio wave pilot project, which has been operating since early
     summer, is run by CAI Wireless Systems Inc. in Albany, N.Y., and
     Hybrid Networks Inc. in Cupertino, Calif. Hybrid plans to offer
     commercial service in the area by the middle of next year, said
     Chuck Zumbaugh, a Hybrid consultant working on the project.

Copies of the SYNERGY JOURNAL sent by request: pflaump@MSN.COM
SYNERGY-NET on http://synergy.trevista.com/
Peter E. Pflaum Ph.D. , Headmaster GLOBAL_VILLAGE_SCHOOLHOUSE 
225 Robinson Road, New Smyrna Beach, FL 32169-2176 (904) 428-9609 
pflaump@mail.trevista.com   http://metro.turnpike.net/~pflaump/
http://forum.trevista.com/ or join #synergybunch on IRC. 
Go in and set up conference, documents, newspaper, teams. 
http://www.altavista.forum.digital.com/ Directory Floor 503 & 504


http://earth.ics.uci.edu:8080/faqs/punc-eq.html
http://earth.ics.uci.edu:8080/origins/biblio/punctuated_equilibri
um.html

Natura non facit saltum; ( Nature does not take leaps but it
does?)
http://metro.turnpike.net/~pflaump/winhttpd/htdocs/doc1a.htm
Evolution, competition, survival of the fittest is a fact but
Darwin's theory of evolution does not explain the " Origins of
the Species" or the "Decent of man". The physical fossil record
does not support, and never has, the idea of slow steady
"progress" from simple to complex, in small steps from ammonites
to people. "Time Frames" by Niles Eldredge explains how science
adjusted to the reasonable social expectations of the machine age
by imposing on the data preconceived notions of progress and
order. Darwin's type of slow evolution does happen but so does
rather sudden extinctions and discontinuous bursts of creative
activity. 

Physics: The Uncertainty principle: Con't doc1a.htm ( above )

Copies of the SYNERGY JOURNAL sent by request: pflaump@MSN.COM
SYNERGY-NET on http://synergy.trevista.com/
Peter E. Pflaum Ph.D. , Headmaster GLOBAL_VILLAGE_SCHOOLHOUSE 
225 Robinson Road, New Smyrna Beach, FL 32169-2176 (904) 428-9609 
pflaump@mail.trevista.com   http://metro.turnpike.net/~pflaump/
http://forum.trevista.com/ or join #synergybunch on IRC. 
Go in and set up conference, documents, newspaper, teams. 
http://www.altavista.forum.digital.com/ Directory Floor 503 & 504

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[David N. Smith]

>jhd@herold.franken.de (Joachim Durchholz) writes:
>
>>> execution of a program.  And in a Self program, classes never exist at all
>>> (not even in the program text).

It is interesting to note that the optimizer creates things that look a
lot like classes so that clones of objects don't take up a lot more space
than necessary. But they are fully hidden.

Dave

_____________________________________________
David N. Smith
IBM T J Watson Research Center, Hawthorne, NY
Mailto: dnsmith@watson.ibm.com
Home Page: http://www.dnsmith.com/
_____________________________________________
Any opinions or recommendations are those 
of the author and not of his employer.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Nick Thurn]

Alan Lovejoy (alovejoy@concentric.net) wrote:
> Nick Thurn wrote:
> > 
> > The objects that exist when the program runs are a mixture of implementation
> > objects, domain objects, library objects, ui objects, comms... etc. Trying to
> > think back from them seems very unhelpful. IMHO even thinking *forward* to
> > these implementation objects too early is dangerous.
> > 
> > Do you mean this or do I have it wrong?
> 
> Pardon me, I see I wasn't clear.  The "dynamic model" or "dynamic design" **deals with**
> or **is concerned with** the objects that will exist at run time, what roles they will
> play, what responsibilities they will have and how they will interact.  Of course the
> run time objects are NOT themselves the design (in spite of the fact that my imprecise 
> wording might give one the impression that I was saying that).
> 
Alan,

I see what you mean, however I still don't agree. In my experience the dynamic model
is several things:
	- sanity check on static model
	- discoverer of missing abstractions
	- discoverer of patterns of interaction to be further encapsulated

The static and dynamic model interact in a feedback loop so precedence is not clear
ie static first vs dynamic first. IMHO you must start with a static model of your
domain prior to embarking on the dynamic model. Sure this model may be incomplete
or prove inappropriate but it is the seed from which an implementable system should
be grown (IMO). read on.. 

> Many objects that exist at run time may have internal mechanisms that you have no
> control over, such as those that may be instantiated from classes in the standard
> library.  You can of course always choose not to use such "standard" or "system"
> objects, and in some languages (such as Smalltalk) you may be able to easily change
> them, but simply using them as-is is what usually happens.  You don't need to design
> such "standard" objects, 
>
Again I disagree. Standard objects *are* part of your design just because you *use*
vs. *implement* doesn't reduce their importance. In fact the greatest benefits come
when programmers -stop- -writing- -code- and -start- -using- -code-. 

> but you do need to know how to interface to them, and 
> decide what roles (if any) they will play in your system.
>
I agree with this. The timing is still *after* you have a static analysis or domain
model and a set of requirements stating what your users want this system to do. How
can you even think about object roles until you know which objects you have? and
what your program should do?

> Perhaps a concrete example will clear up the confusion.  The Model-View-Controller
> concept is now familiar to many, so I will use that as the example.
> 
[...snipped MVC discription...]
> 
> The collaborating objects in a role model are understood as instances, not classes.  And a 
> role is a function of 
> 	a) the responsibility of an object and what purpose it serves
> 	b) messages that it will be expected to respond to 
>		(which might well be a subset of all the messages it could respond to)
> 	c) the messages it will send to other collaborators
> 		(which might not be all the messages it could send, 
>		nor all the receivers to which it may potentially send messages).
>
[...snipped MVC discription...]
> 
> From this it should be clear that roles are not classes. 
>
No they are perhaps patterns and certainly design artifacts. They may be implemented
as classes if appropriate, and could be abstract base classes or cooperating generics.
Or whatever your language supports.

> I wholeheartedly endorse role modelling, and recommend doing it **before** trying to worry
> overmuch about the class hiearchy.  Wouldn't it be nice to identify the role models in which
> the objects in your program will participate before designing the class hierarchy that will
> provide the classes whose instances can be collaborators in those role models?
>
You are forgetting that at this point you know stuff that makes the role relevant eg
that your app is GUI based vs embedded vs commandline vs ... How did you get to
know this stuff? You are talking about plumbing which IMO should be put into librarys
if possible and reused. Yes plumbing is a design issue, yes object interaction roles are
relevant but plumbing comes AFTER your static model, AFTER you know what you are
doing and why you are doing it. 

Object roles are *discovered* during dynamic modeling, (this can mean "force fit" :)
they are not ends in themselves.

cheers
Nick (my opinions only) 

> --
> Alan L. Lovejoy		|==============================================| 
> Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
> alovejoy@concentric.net |==============================================|

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[David N. Smith]

In article <32891BA4.4AA5@concentric.net> Alan Lovejoy,
alovejoy@concentric.net writes:
>In view of the OO languages such as Self that don't even >have classes,
>one has to question how central class inheritance (as opposed to type inheritance) really
>is to even static modelling (not that getting inheritance right is easy, or that getting
>it wrong is inconsequential).

Alan:

One can think of SELF as a language in which all objects are classes
since any object can serve the function of a prototype for a family of
objects differing only in their 'data'. Inheritence in SELF is not type
inheritence; it is much more purely implementation inheritence than even
Smalltalk.

I do agree that classes are often thought of as necessary an basic in all
OOP languages and the definition of OOP often includes the concept of
class. That's basically wrong. 

Classes are necessary and basic only in those restricted 'OOP' languages
that use type inheritence.

Dave

_____________________________________________
David N. Smith
IBM T J Watson Research Center, Hawthorne, NY
Mailto: dnsmith@watson.ibm.com
Home Page: http://www.dnsmith.com/
_____________________________________________
Any opinions or recommendations are those 
of the author and not of his employer.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Bill Gooch]

David N. Smith wrote:
> ....
> I do agree that classes are often thought of as necessary an basic in all
> OOP languages and the definition of OOP often includes the concept of
> class. That's basically wrong.

Agreed.

> Classes are necessary and basic only in those restricted 'OOP' languages
> that use type inheritence.

Type inheritance is independent of classes; indeed, it is
not at all restricted to OO.  

I'd say that classes are necessary and basic only in those
restricted "OOP" languages in which classes are necessary
and basic.  None of the useful things about OO depend on a
class/instance stratification. 

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Bill Gooch]

Alan Lovejoy wrote:
> 
> Bill Gooch wrote:
> >
> > I'd like to hear more about how you think design can be done
> > independent of language, and what such a "design" would look
> > like....  I have a question: what do you call a
> > program specification, not involving code, which does take
> > these issues into account? 
> ....
> Please believe that I am well aware of the fact that one absolutely must take the
> idiosyncracies of the implementation technology (such as the programming language)
> into account in desgining and coding a program. I'm sorry that so many people seem
> to think I have suggested otherwise!...

Well, I'm sorry that I apparently misinterpreted what you wrote.
I do believe that you know these things, and perhaps what we are
dealing with is a reflection of the fact that "design" is a very
broad term.  I think of software designs in layers, from the most
abstract (related directly to the domain model) to concrete (the
closest to the implementation, and most language-specific).  This
covers such a broad range that the relationship between layers at
each end is often lost, simply because there are so many refining
transformations in between, and methods don't support specifying
those refinements very clearly or completely.  (This can change.)

> Any "program specification" that could be used to actually execute a program,
> or generate an executable program, is by definition a program text, and the notation
> in which it is written is in effect a programming language....

"In effect," maybe it is - but consider that many CASE tools can
generate executable, and by itself entirely useless, code from 
diagrams.  Does this qualify the diagram notation as a "programming
language?"  Maybe some notations could be, but mostly I think
they are not, because there are too many details they can't deal
with effectively, if at all.

In any case, I didn't say that the specification I referred to
was necessarily executable, nor usable to generate a program.  

> My thesis is that a design **methodology** should be able to handle designing
> a program regardless of language, although it will certainly need to take the
> differences between langauges into account.  If I have to use a completely
> different methodology for each part of the system that is implemented in a
> different language, something is wrong.

More or less, I agree.  But in a practical sense, it isn't so
much the *methods* that are limited (with some exceptions), it
is the *notations* which don't span languages very well.  The
need to be able to specify language-dependent aspects of design
when appropriate argues for multi-lingual, rather than language
independent, notation.  IOW, perhaps you flip a language switch 
when you're ready to deal with the more concrete design layers.

Mapping designs between languages is even more problematic.   
 
> Similarly, the design notation should be flexible enough to handle any and
> all implementation languages.  One may use different capabilities of the
> notation and/or and specify different designs due to the intended target
> language.  

OK, now it seems that we're on the same track...

> But if the notation becomes completely worthless in the face of
> an implementation language such as Self, perhaps there is something wrong with
> the notation (and/or its underlying object metamodel) at a fundamental level.

Perhaps; I'm not sure.  I think the notations probably don't have 
more trouble with Self than some other languages, but the inter-
pretation of the models (the meta-model) is very different.  Sure,
the designed structures are likely to be different also.  The
question in my mind is: is a prototype-based language really the 
same kind of animal as a class-based language?  There must be 
limits on the domain our methods and notations are intended for,
so where do we draw the line?

> I am reacting to all the times I've seen people start their design process
> by drawing class hierarchies....

I don't have too much trouble with that, as long as they've 
previously built some reasonable domain models which aren't
concerned with implementation or class structure.  It's a 
question of the starting point; if you understand the problem
well enough, then solutions (including some of the class
structure) may be fairly apparent.

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Soren Skogstad Nielsen]

Snowball wrote: (and many others)
> 

> When we are talking about static and dynamic models, something bothers
> me. There are
> two types of complexities in any system. One is the static or structural
> (or
> sometimes I call it detail) complexity, the other one is dynamic
> complexity.
> To me some canonical forms of systems such as class hierarchy can be
> reasonably understood
> by static diagrams, however, it is not very intuitive to attempt to
> model dynamic behavior
> in static diagrams such as object or interaction diagrams. I can
> differentiate between
> structural complexity and dynamic complexity with an example: a car
> engine totally taken
> apart and lying on the floor with all parts visible, and even sorted out
> to parts, may
> create an atmosphere for us to develop a detailed understanding of each
> part but will not
> give us a clear idea of how it runs. An engine timing diagram can help
> us but the best way
> to understand how an engine works is to observe it "running" preferably
> with a power to control
> the motion of the time domain. This means that we can take the engine,
> replace one of the side walls
> of it with say a glass panel, and let it slowly run, even single step,
> so that we can follow the
> entire motion. Same analogy for a software system running would be to
> add a layered visual
> debugger and a reverse engineering tool to obtain and animate certain
> diagrams to observe how the
> behavior of the system changes in time. (It just happens that I am
> working on such a visual
> debugger for Smalltalk to be added to a tool I developed)
> 
> > There is a mapping between the two kinds of models that must be maintained.
> > Every relationship on a dynamic model; that is, ever pathway accross which
> > a message is sent; must be supported by a static relationship in a static
> > model.
> 
I have some experience with a notation which keeps the dynamic and
static properties in sync. Thereby you actually have ONE basic model
from which you may derive a static AND a dynamic view. It is my
experience that the interplay between the static and dynamic views
enlightens my understanding of the structure of both and thereby of
their same underlying model. To this notation is coupled a 
description of when to look for what in the two views. This guide
telling when to decide on what (coupling, inheritance, methods,
aggregation, etc) is in fact what I understand with the concept a
methodology. 
It is described under the name of OoASE, a tool supporting the notation
and the
methodology is available too. You may send me a mail if interested in
more information.

- The world is just one big friendly surprise -

Soren Skogstad Nielsen
A-Informatik
Bredgade 36 E Copenhagen Denmark
email: soren.s.nielsen@ddf.dk

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Piercarlo Grandi]

>>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes:

menio> On 11 Nov 1996, Piercarlo Grandi wrote:

piercarl> Do OO programs by and large describe static relationships
piercarl> between modules (or parts thereof like interfaces)? Or do they
piercarl> describe collections of instances/clones of those modules (or
piercarl> their types) and how they interact?

menio> In addition to the comments made in my last post I though
menio> following would offer a clear and correct answer. Systems with an
menio> object oriented architecture consist of objects. Classes are
menio> merely blue prints to create objects from. Just as a building is
menio> made of beams, rooms,prefab components and cars of
menio> transmissions,radiators,exhust systems system and not the
menio> blueprints of these things so with an OO software system.

"Just as" is a bit ambitious above, isn't it? Just look at how buildings
are built, and build OO systems accordingly. I wonder why nobody :-)
ever realized it is so simple. It is also extremely convenient for the
sake of terseness to make statements without any sort of supporting
argument. It reminds me of the writing style of several OO-speak gurus.

menio> The essence of OO architecture is the viewing of abstract systems
menio> in terms of the real world, ie as if the were physical systems.

Please describe how you would view an OO program that does calculations
using matrixes of complex numbers as if it were a physical system...

menio> Thus it a fundamental process to resolve such questions through
menio> examining systems of the source domain of the metaphor to gain a
menio> better understanding of conceptual issues in the target domain.

Continue writing in this style and you'll become a wealthy OO-speak guru
like Brady Gooch or Steve Mellor. ``A sucker is born every minute.''

menio> Anthony Menio I.S. Student menio@pegasus.montclair.edu

Just as a curiosity: could you post the titles of the OO books from
which you have gleaned the above statements? I must confess that I have
some expectations as to what they can be...

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Piercarlo Grandi]

>>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes:

menio> On 11 Nov 1996 > 

piercarl> Yes, but what's the relevance of this to the question of
piercarl> whether "OO programs are systems of interacting **objects**"
piercarl> rather than systems of modules (either classes or prototypes
piercarl> or actors) that ``contain'' procedures that invoke each other?

piercarl> Do OO programs by and large describe static relationships
piercarl> between modules (or parts thereof like interfaces)? Or do they
piercarl> describe collections of instances/clones of those modules (or
piercarl> their types) and how they interact?

menio> I think the answer to this can be found in the analysis model.
menio> The analysis model descibes the objects that will be existance
menio> during the systems existance. In this model and thus the
menio> functioning system your interested in definate articals ie actual
menio> entities not classes of entities(ie currentProcess, ActiveWindow,
menio> nextTransaction, rather than definitions of the types which these
menio> are instances of) . The relationships expressed are dynamic ones
menio> as the effects of the messaging between these objects will be
menio> related to thier state.

According to your argument, which has already been seen in slightly
different guises, if a bank has a customer list application, then the
analysis model will describe N million objects if the bank has N million
customers. If the bank acquires a new customer, or loses a customer,
then the analysis model will have to be revised, for the "objects that
will be in existance during the system existance" will have changed.

"think before you leap"...

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Tim Ottinger]

Bill Gooch wrote:

> Well, I'm sorry that I apparently misinterpreted what you wrote.
> I do believe that you know these things, and perhaps what we are
> dealing with is a reflection of the fact that "design" is a very
> broad term.  I think of software designs in layers, from the most
> abstract (related directly to the domain model) to concrete (the
> closest to the implementation, and most language-specific).  This
> covers such a broad range that the relationship between layers at
> each end is often lost, simply because there are so many refining
> transformations in between, and methods don't support specifying
> those refinements very clearly or completely.  (This can change.)

> In any case, I didn't say that the specification I referred to
> was necessarily executable, nor usable to generate a program.
> 
[Alan Lovejoy wrote]
> > My thesis is that a design **methodology** should be able to handle designing
> > a program regardless of language, although it will certainly need to take the
> > differences between langauges into account.  If I have to use a completely
> > different methodology for each part of the system that is implemented in a
> > different language, something is wrong.
> 
> More or less, I agree.  But in a practical sense, it isn't so
> much the *methods* that are limited (with some exceptions), it
> is the *notations* which don't span languages very well.  The
> need to be able to specify language-dependent aspects of design
> when appropriate argues for multi-lingual, rather than language
> independent, notation.  IOW, perhaps you flip a language switch
> when you're ready to deal with the more concrete design layers.
> 
> Mapping designs between languages is even more problematic.

If there's one thing that we should learn from Mr. Booch and the many
others who've been with OO through the good, the bad, and the ugly
projects, it's that we have to watch out for "the big project".

The Big Project is the "clean-break from the past", "do it all", "no
limits", type of project which typically fails.  Typically, people
believe that they can build a complex system, which works, from 
scratch.

An end-all notation is a great idea, and if you can make a notation
or method which is independent of all technologies but which uses
every technology well, then I would love to see it.

We have to face the "fact" that a design notation has to map cleanly
into the engineering realm. If I could borrow the flimsy and much-
touted "other fields" analogy, what good would a circuit diagramming
notation do if it didn't map cleanly into manufacturing?  In fact, 
if we don't consider manufacturing in our notation, we're probably 
making a big mistake.

For instance, it's sometimes a mistake to use OO notation for a SA/SD
software project, likewise it's frequently troublesome to use SA/SD
design, and expect to manufacture an OO system easily from it.

[ SOAP BOX WARNING: BEGINS NOW ]

As much as we like to glorify our jobs, we analyse in order to design
well, and design well so that we can build well, and we build well so
that the software will run well.  If my design is "independent of tech"
that might be nice unto itself, but it pushes problems downstream.

A lot of the analysis/design/code/test/release/revisit talks I hear are
legitimate.  You clearly should know what you want before you start, 
etc.  Ad-hoc hacking can lead to some pretty ill-conceived systems,
which
act ill-conceived.  Nobody wants that.

On the other hand, a lot of talk seems to be trying to maintain a status
quo for the "SE" career path
(tester->coder->designer->analyst->manager).
Let's face it, our separation of concerns is often separation of
careers,
and it exists to give us a promotion path with requisite pay raises and
status.

We're in an incremental world now.  We iterate (okay, not all of us,
SM).
If we can't maintain our business organization and separation of roles
and pay ranges in this world, is that a problem with the methods or the
status quo?

It's a hard call.  It's bigger than this list, and can't be corrected
by developers (though we can push for this).  When we change our 
manufacturing methods, we must change the front-line skills, the tools
(notation/language) and the organization of labor.

We can surf, or we can get washed away.  

[SOAPBOX WARNING OVER]

But the "ultimate" methodology should match the way we generate
software.
It should not be independent of it.  It should not limit our abilities,
and some tradeoff must be made from time to time.  But our early
analysis
must eventually map onto hardware, or it wasn't a very useful part of
the
software development process (though it can be good for professional 
development ;-) )

-- 
Tim
+------------------------------------------------------------------+
|     Tell me again, *why* must we publish estimates before we     |
|     gather requirements?                                         |
+------------------------------------------------------------------+
| Tim Ottinger, Sr Tech			     tottinge@csci.csc.com |
| CSC Communications Industry Services		 217-351-8508x2420 |
| TRIS Division -- Cellular Billing and Support	  Fax 217-351-2640 |
+------------------------------------------------------------------+

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Anthony Menio]

On 18 Nov 1996, Piercarlo Grandi wrote:

> >>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes:
> 
> menio> On 11 Nov 1996, Piercarlo Grandi wrote:
> 
> piercarl> Do OO programs by and large describe static relationships
> piercarl> between modules (or parts thereof like interfaces)? Or do they
> piercarl> describe collections of instances/clones of those modules (or
> piercarl> their types) and how they interact?
> 
> menio> In addition to the comments made in my last post I though
> menio> following would offer a clear and correct answer. Systems with an
> menio> object oriented architecture consist of objects. Classes are
> menio> merely blue prints to create objects from. Just as a building is
> menio> made of beams, rooms,prefab components and cars of
> menio> transmissions,radiators,exhust systems system and not the
> menio> blueprints of these things so with an OO software system.
> 
> "Just as" is a bit ambitious above, isn't it? Just look at how buildings
> are built, and build OO systems accordingly. I wonder why nobody :-)
> ever realized it is so simple. It is also extremely convenient for the
> sake of terseness to make statements without any sort of supporting
> argument. It reminds me of the writing style of several OO-speak gurus.
> 
Evidence ? witness Component architectures this is a prime example of
reuse of concepts and methods of construction from the physical domain.

> menio> The essence of OO architecture is the viewing of abstract systems
> menio> in terms of the real world, ie as if the were physical systems.
> 
> Please describe how you would view an OO program that does calculations
> using matrixes of complex numbers as if it were a physical system...
> 
I think the problem here is your interpretation of of the phrase "as if
they were physical systems". The meaning I wished conveyed is in
"in terms of conceptually" not of "not in terms of literally". 
As far as your specific example wouldn't such a OOP program
still consist of instances of needed classes and
method invocations between them ?  Hence the ideas of classification,
instances, encapsulation would still be key to design and
evident in the runtime system. These concepts are paramount
to our viewing of real world systems, of physical systems,
and such systems are the source of these ideas. OO is
every where in the real world isn't the blue prints for
a new Buick LeSabre simply a class ? The interface to
an instance of this class(brakes,gas pedal,sterring) provide
an implementation independent means of communicating
with it. Thus if this is so then isn't the OO program for
matrix calculations modeled in terms of the physical world? 


> menio> Thus it a fundamental process to resolve such questions through
> menio> examining systems of the source domain of the metaphor to gain a
> menio> better understanding of conceptual issues in the target domain.
> 
> Continue writing in this style and you'll become a wealthy OO-speak guru
> like Brady Gooch or Steve Mellor. ``A sucker is born every minute.''
> 
Drwaing parallels from  my ideas and communication skills to those of
accepted OO speakers is hardly an argument against my ideas
and communication skills. In fact thanks for the complement :) 

> menio> Anthony Menio I.S. Student menio@pegasus.montclair.edu
> 
> Just as a curiosity: could you post the titles of the OO books from
> which you have gleaned the above statements? I must confess that I have
> some expectations as to what they can be...
> 
>  
If you are of the opinion that my posting are simply a
regurgitation for the exposings of the authors I have read,
rather than critical reflections upon their ideas,
than  you should take this argument up with
them. I'm not sure of Ivar Jacobson's and Grady Booch's
email addresses but I'm sure you can find them someplace.


Anthony Menio
I.S. Student
menio@pegasus.montclair.edu

	Your power is your ideas, your ideas are products of
	perception, your perception is the product of your
	architecture, architecture is everything - me

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Robert C. Martin]

In article <32891BA4.4AA5@concentric.net>, Alan Lovejoy
<alovejoy@concentric.net> wrote:

> Robert C. Martin wrote:
> > 
> > In article <328109CD.6685@concentric.net>, Alan Lovejoy
> > <alovejoy@concentric.net> wrote:
> > 
> > > The architecture and design of a program is a function of what
> > **objects** it contains and
> > > how they interact.
> > 
> > I disagree.  The architecture of a program is a function of the way
> > it manages to decouple the source code while allowing the interactions
> > to remain unaffected.
> >
> > This is true irrespective of language.  It is as true in Smalltalk as
> > it is in Java or C++.
> 
> I have to admit that I don't really understand what you mean. Perhaps
you could 
> clarify?

Sure.  Imagine a program that trasmits files between computers using
modems.  That program could deal with lots of different kinds of modems in
several different ways.  It could use a switch statement every time it needed 
to interact with a modem, choosing the correct modem each time and executing
the right code.  Or it could create an abstract Modem class and then create
derivative for each type of modem.  

In the first example, adding a new modem means ripping through all the code
and finding every place where there is a switch statement and adding the
new modem to it.

In the second example, adding a new modem is a easy as writing a new derivative
class of Modem.

On the other hand,  if we need to add a new function to all the modems, then
in the first example, all we have to do is add a switch statement, but in
the second example, we must modify the abstract modem class and all its 
derivatives.

This is an architectural choice; and it is based upon which kind of change
is more likely.  If it is more likely that new functions will be added to
existing modems, then the switch statement is probably the better choice.
If it is more likely that new kinds of modems will be added, then the class
structure is probably better.

The point is that the interactions between the program and the modems
remain identical regardless of which architecture you choose.  The 
architecture is strategy for decoupling the source code so that changes
are easily made.

> As I have used the term "design" in earlier posts, it refers to what you
have called
> the "dynamic model" (assuming I have correctly understood you). My
thesis is not that 
> the "static model" is unimportant, but rather that one needs to know
what dynamic model 
> one wants to achieve before one can optimally derive a static model. 
The dynamic model 
> is the heart of the design, because it is where the real work gets done,
and because
> the purpose of the static model is the specification of the dynamic
model.  You can't
> implement a good static model that specifies a dynamic model without
having a good idea 
> of what dynamic model you intend to specify!

Damn straight!  Static models are meaningless without dynamic models to
justify them.  By the same token, dynamic models are fantasies without
static models to support them.  Both are important.  Neither can
stand alone.  One cannot create a static model without a decent
dynamic model.  But by the same token, one cannot create a realistic
dynamic model without it being constrained by a good static model.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

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

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Michael Malak]

In article <rmartin-2011960223130001@vh1-036.wwa.com>,
Robert C. Martin <rmartin@oma.com> wrote:
>
>Sure.  Imagine a program that trasmits files between computers using
>modems.  That program could deal with lots of different kinds of modems in
>several different ways.  It could use a switch statement every time it needed 
>to interact with a modem, choosing the correct modem each time and executing
>the right code.  Or it could create an abstract Modem class and then create
>derivative for each type of modem.  
>
> [snip]
>
>This is an architectural choice; and it is based upon which kind of change
>is more likely.  If it is more likely that new functions will be added to
>existing modems, then the switch statement is probably the better choice.
>If it is more likely that new kinds of modems will be added, then the class
>structure is probably better.

THANK YOU! for confirming my conjecture.  I posted this idea a few
weeks ago on comp.lang.c++.moderated to see if it was valid, and I
got blasted.

Response 1: Use templates
    My unspoken response: I still have to write a bunch of functions
         for every new method I wish to implement

Response 2: Arthur Reil's book says you're in danger of creating a
            "God" class
    My unspoken response: none, since I don't have the book

Response 3: This is the Visitor pattern; buy the Gamma book
    My unspoken response: Yes, I have the Gamma book, and yes, I was
         familiar with the Visitor pattern, but the Visitor pattern
         looked too complicated to achieve what I wanted.  As "bad"
         as "switch/case" is, it appears to minimize the complexity
         in this situation.

I was just a meek C++ student back then, so I didn't post any responses.
I put those bad old thoughts of "switch/case" out of my mind.

If you are interested in seeing the thread, search for this message
ID in DejaNews: <54titl$imt@netlab.cs.rpi.edu>

-- 
Michael Malak         Home: malak@access.digex.net
Washington, DC        Work: malak@notes.sonix.com

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Piercarlo Grandi]

>>> "jhd" == Joachim Durchholz <jhd@herold.franken.de> writes:

>>>> Could anybody post a short characterisation of prototype languages?

>> Basically, instead of creating a class, we instead create a blank
>> object and insert methods into it. Any object of that 'type' is a kind
>> of clone of that prototype object.

jhd> Hum, I think this description applies to class-based languages as
jhd> well.  Just say 'class' instead of 'blank prototype object'.

Not quite -- for one can then change one of those clones and make it
into a prototype for a new kind of objects, something which is quite not
possible in class based systems.  Also note that the prototype need not
be ``blank'' at all.

Also, if procedures belong _to_ objects instead of encapsulated _in_
classes, it becomes fairly natural to do reuse not quite by defining a
class by mixing in it procedures from other classes, but by forwarding
operations from one object to another, which need not be its prototype;
thus it is fairly natural to use delegation rather than inheritance in
prototype systems (even if the 'clone of' relationship can be used as if
it were an inheritance like relationship).

  An example is that if a trait of a prototype is declared irrevocably
  immutable, there is no need to duplicate it in every clone of that
  prototype object; it and all its clones can ``share'' that trait. The
  net effect is that then the implementation starts to resemble very
  much that of a class based system.

jhd> When are the methods inserted - at run-time?

Could well be, but not necessarily.

jhd> Then there's a real difference, [ ... ]

Not quite, for there are systems where classes can also be changed at
runtime

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Robert Dewar]

Michael says

"    My unspoken response: Yes, I have the Gamma book, and yes, I was
         familiar with the Visitor pattern, but the Visitor pattern
         looked too complicated to achieve what I wanted.  As "bad"
         as "switch/case" is, it appears to minimize the complexity
         in this situation."


One thing you will learn rapidly that there are a lot of people in this
field who are much more interested in fiddling with the latest gizmos
than in writing clearly and minimizing complexity :-)

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Robert Dewar]

Robert Martin says

"On the other hand,  if we need to add a new function to all the modems, then
in the first example, all we have to do is add a switch statement, but in
the second example, we must modify the abstract modem class and all its
derivatives.

This is an architectural choice; and it is based upon which kind of change
is more likely.  If it is more likely that new functions will be added to
existing modems, then the switch statement is probably the better choice.
If it is more likely that new kinds of modems will be added, then the class
structure is probably better.
"


Yes indeed, this is an important fundamental principle that does not seem
to be widely enough understood. It is useful to think of a matrix with
operations on the columns and types on the rows, then the issue of whether
to organize a program vertically or horizaonally with respect to this
particular subdomain is made on the basis of whether you expect to add
to rows or columns.

It is also appropriate to consider domains of expertise, does a typical
expertise extend over columns or rows of this matrix? If there is a clear
answer to this question, which is sometimes the case, then that may be
another consideration in deciding whether to organize horizontally or
vertically.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Anthony Menio]

On 18 Nov 1996, Piercarlo Grandi wrote:

> >>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes:
> 
> menio> On 11 Nov 1996 > 
> 
> piercarl> Yes, but what's the relevance of this to the question of
> piercarl> whether "OO programs are systems of interacting **objects**"
> piercarl> rather than systems of modules (either classes or prototypes
> piercarl> or actors) that ``contain'' procedures that invoke each other?
> 
> piercarl> Do OO programs by and large describe static relationships
> piercarl> between modules (or parts thereof like interfaces)? Or do they
> piercarl> describe collections of instances/clones of those modules (or
> piercarl> their types) and how they interact?
> 
> menio> I think the answer to this can be found in the analysis model.
> menio> The analysis model descibes the objects that will be existance
> menio> during the systems existance. In this model and thus the
> menio> functioning system your interested in definate articals ie actual
> menio> entities not classes of entities(ie currentProcess, ActiveWindow,
> menio> nextTransaction, rather than definitions of the types which these
> menio> are instances of) . The relationships expressed are dynamic ones
> menio> as the effects of the messaging between these objects will be
> menio> related to thier state.
> 
> According to your argument, which has already been seen in slightly
> different guises, if a bank has a customer list application, then the
> analysis model will describe N million objects if the bank has N million
> customers. If the bank acquires a new customer, or loses a customer,
> then the analysis model will have to be revised, for the "objects that
> will be in existance during the system existance" will have changed.
> 
> "think before you leap"...
> 
> 

A system in which a 1:N object relationship exists and often
undergoes large changes in the n side of this relationship
requires a structure capable of handling these 
changes. An analysis model which describes the system as
dynamic interactions and relations  between objects 
is fundamental in creating such a structure. The example
you mention can only be though of in terms of
varying numbers of instances of a customer class, thus
in terms of objects. The behavior being  modeled is in terms
of messages between some subset of the N customers and the
list object. The very concept of sending messages to multiple
copies of the same class  by definition requires you to think
in terms of objects.  Even in class definition  your thinking  is
in terms of a typical instance of the class being created. Implementation
of behavior is defined in terms of state, state is a characteristic
of objects. Example

 
customer_list::add_client(customer *new_client)
{

client_vector.add(new_client);


}

customer::customer(char *social_security, dollars opening_deposit)
{
this->identity = social_security;
this->current_balance = opening deposit;


}

the very idea of the assignment of a runtime determined parameter(an
argument)  to an instance variable can only be though of terms of
objects. The same holds true for the idea of increasing the current 
client list by the new client in the above customer_list::add_client()

In a pure OO environment the very act of running an application is
a create message to the application from the user via the O.S.
Application execution begins with instantation of a class, object
creation and messaging. Thus an application as a whole is a dynamic
entity with equally dynamic relationships with other such
entities in other words a a subsystem of a system of interacting
objects. The very idea of persistance mechanisms revolves around
allowing these objects to exist in a dormant state, construction
and destruction can only be thought of in terms of objects, these
activities are essential to OOP execution. Thus OOP programs
are interacting systems of objects.


Anthony Menio
I.S. Student
menio@pegasus.montclair.edu

	Your power is your ideas, your ideas are products of
	perception, your perception is the product of your
	architecture, architecture is everything - me

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Tucker Taft]

Robert C. Martin (rmartin@oma.com) wrote:

: ... Imagine a program that trasmits files between computers using
: modems.  That program could deal with lots of different kinds of modems in
: several different ways.  It could use a switch statement every time it needed 
: to interact with a modem, choosing the correct modem each time and executing
: the right code.  Or it could create an abstract Modem class and then create
: derivative for each type of modem.  

: In the first example, adding a new modem means ripping through all the code
: and finding every place where there is a switch statement and adding the
: new modem to it.

: In the second example, adding a new modem is a easy as writing a new derivative
: class of Modem.

: On the other hand,  if we need to add a new function to all the modems, then
: in the first example, all we have to do is add a switch statement, but in
: the second example, we must modify the abstract modem class and all its 
: derivatives.

: This is an architectural choice; and it is based upon which kind of change
: is more likely.  If it is more likely that new functions will be added to
: existing modems, then the switch statement is probably the better choice.
: If it is more likely that new kinds of modems will be added, then the class
: structure is probably better.

This is certainly a good point, but I think that the class structure
still has certain advantages over the "switch" structure even when adding 
new "functions" is somewhat more common than adding new modem variants.

In the "switch" world (in which I have spent many pleasant hours ;-),
one tends to presume that almost every new function requires its
own personal switch statement.  In the "class" world, when adding
a new operation, one has the option of implementing it in terms of
some preexisting more primitive operation, rather than creating
a new operation for every modem variant.  

Although this is difficult to prove, my sense is that by being 
forced by the "class" structure to express the differences between 
type variants by a set of primitive operations, one is more likely 
to find that many new "interesting" operations are implementable 
in terms of the existing operations.  In the "switch" structure,
you often don't ever get around to defining the "primitive"
operations, but instead just keep defining miscellaneous operations,
each with their own switch statement, without any great thought
to creating a minimal but complete set of "primitive" operations.
The net effect is that when you want to change some aspect of
the implementation, or fix a bug, there is much more cut & paste
that has happened in the "switch" world, and hence much more of
a maintenance problem.

To reiterate, when it comes to writing a new operation, with the "switch"
structure, you will often have to write a new switch statement, probably
partially copying and then editing some existing switch statement.
With the "class" structure, it is more likely that you will only
have to write a small amount code, containing calls on preexisting 
operations.  

: Robert C. Martin    | Design Consulting   | Training courses offered:
: Object Mentor       | rmartin@oma.com     |   Object Oriented Design
: 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
: Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Piercarlo Grandi]

>>> "menio" == Anthony Menio <menio@earhart.montclair.edu> writes:

menio> On 18 Nov 1996, Piercarlo Grandi wrote:
>>>>>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes:

menio> On 11 Nov 1996 > 

piercarl> Do OO programs by and large describe static relationships
piercarl> between modules (or parts thereof like interfaces)? Or do they
piercarl> describe collections of instances/clones of those modules (or
piercarl> their types) and how they interact?

menio> I think the answer to this can be found in the analysis model.
menio> The analysis model descibes the objects that will be existance
menio> during the systems existance. In this model and thus the
menio> functioning system your interested in definate articals ie actual
menio> entities not classes of entities(ie currentProcess, ActiveWindow,
menio> nextTransaction, rather than definitions of the types which these
menio> are instances of) . The relationships expressed are dynamic ones
menio> as the effects of the messaging between these objects will be
menio> related to thier state.

piercarl> According to your argument, which has already been seen in
piercarl> slightly different guises, if a bank has a customer list
piercarl> application, then the analysis model will describe N million
piercarl> objects if the bank has N million customers. If the bank
piercarl> acquires a new customer, or loses a customer, then the
piercarl> analysis model will have to be revised, for the "objects that
piercarl> will be in existance during the system existance" will have
piercarl> changed.

menio> A system in which a 1:N object relationship exists

I am not familair with this concept: what is an 1:N object relationship?

A customer list application has N million customer objects, which can be
related among them in many ways; for example there might be a
"provided_reference" relationships between one object and many others,
or a "cosignatory" relationships between several customer objects (and
an account object, presumably).

menio> and often undergoes large changes in the n side of this
menio> relationship requires a structure capable of handling these
menio> changes. An analysis model which describes the system as dynamic
menio> interactions and relations between objects is fundamental in
menio> creating such a structure.

Why is it fundamental to model N million objects, as opposed to just
modeling their type/class/prototype?

menio> The example you mention can only be though of in terms of varying
menio> numbers of instances of a customer class, thus in terms of
menio> objects.

I frankly cannot think in those terms; I can only think of it in terms
of classes, for otherwise one has to keep track of all the individual
relationships among individual objects. That's sometthing computers are
good at; when I write a program i want to deal with abstractions, be
they classes or prototypes.

menio> The behavior being modeled is in terms of messages between some
menio> subset of the N customers and the list object.

Which list object? I haven't seen any mention of a list object. What I
have seen mentioned is a list of N million customers; this list may be
implemented as a list object, or anything else; then there may be M
million customer accounts, X million transactions between those
accounts, and so on.

menio> The very concept of sending messages to multiple copies of the
menio> same class

Which concept? Where has this concept arosen?

menio> by definition requires you to think in terms of objects.

Why? It seems to me that to model relationships between groups of
essentially similar entities one should well describe them abstractly in
terms of the types of those entities.

menio> Even in class definition your thinking is in terms of a typical
menio> instance of the class being created.

Really? Consider some sort of 'complex' class: what is a ``typical''
complex number?

menio> Implementation of behavior is defined in terms of state, state is
menio> a characteristic of objects.

Really? What is the state of the object representing the complex number
(2,3i)?

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Piercarlo Grandi]

>>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes:

menio> On 18 Nov 1996, Piercarlo Grandi wrote:

>>>>>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes:

menio> On 11 Nov 1996, Piercarlo Grandi wrote:

  piercarl> Do OO programs by and large describe static relationships
  piercarl> between modules (or parts thereof like interfaces)? Or do they
  piercarl> describe collections of instances/clones of those modules (or
  piercarl> their types) and how they interact?

  menio> In addition to the comments made in my last post I though
  menio> following would offer a clear and correct answer. Systems with an
  menio> object oriented architecture consist of objects. Classes are
  menio> merely blue prints to create objects from. Just as a building is
  menio> made of beams, rooms,prefab components and cars of
  menio> transmissions,radiators,exhust systems system and not the
  menio> blueprints of these things so with an OO software system.

  piercarl> "Just as" is a bit ambitious above, isn't it? Just look at how
  piercarl> buildings are built, and build OO systems accordingly. I
  piercarl> wonder why nobody :-) ever realized it is so simple. It is
  piercarl> also extremely convenient for the sake of terseness to make
  piercarl> statements without any sort of supporting argument. It reminds
  piercarl> me of the writing style of several OO-speak gurus.

menio> Evidence ?

Easy enough:

  OOADWA>   In the field of artificial intelligence, developments in
  OOADWA> knowledge representation have contributed to an understanding
  OOADWA> of an object-oriented world. In 1975, Minsky first proposed a
  OOADWA> theory of frames to represent real-world objects as perceived
  OOADWA> by image and natural language recognition systems. Since then,
  OOADWA> frames have been used as the architectural foundation for a
  OOADWA> variety of intelligent systems.
  OOADWA>   Lastly, philosophy and cognitive science have contributed to the
  OOADWA> advancement of the object model. The idea that the world could
  OOADWA> be viewed either in terms of objects or processes was Greek
  OOADWA> innovation, and in the seventeenth century, we find Descartes
  OOADWA> observing that humans naturally apply an object-oriented view
  OOADWA> of the world. In the twentieth century, Rand expanded upon
  OOADWA> these themes in her philosophy of objectivist epistemology.
  OOADWA> More recently, Minsky has proposed a model of human
  OOADWA> intelligence in which he considers the mind to be organized as
  OOADWA> a society of otherwise mindless agents. Minsky argues that
  OOADWA> only through the cooperative behaviour of these agents do we
  OOADWA> find what we call _intelligence_.

This is an excellent example of the work on an OO-speak guru, and
consists of a series of rather daring statements unsupported by any
argument.

menio> witness Component architectures this is a prime example of reuse
menio> of concepts and methods of construction from the physical domain.

Really? Please exemplify how component architectures are such a prime
example. In fact I would regard them as a prime example that concepts
and methods of construction in the software domain are nowhere like
those of the physical domain. Software component reuse is uniquely
useful and powerful precisely because it is not at all anything like in
the physical word: for reuse of abstractions has uniquely convenient
properties that are simply impossible to achieve in the physical world.

menio> The essence of OO architecture is the viewing of abstract systems
menio> in terms of the real world, ie as if the were physical systems.

piercarl> Please describe how you would view an OO program that does
piercarl> calculations using matrixes of complex numbers as if it were a
piercarl> physical system...

menio> I think the problem here is your interpretation of of the phrase
menio> "as if they were physical systems". The meaning I wished conveyed
menio> is in "in terms of conceptually" not of "not in terms of
menio> literally".

Wonderful! How would you view software systems "in terms of
conceptually" "as if they were physical systems". Let me say that I
suspect that the "conceptually" bit will be amazingly flexible.

menio> As far as your specific example wouldn't such a OOP program still
menio> consist of instances of needed classes and method invocations
menio> between them ?  Hence the ideas of classification, instances,
menio> encapsulation would still be key to design and evident in the
menio> runtime system. These concepts are paramount to our viewing of
menio> real world systems, of physical systems, and such systems are the
menio> source of these ideas.

Amazing news from America! Just consider encapsulation: if you really
think that it "paramount to our viewing of real world systems" please
exemplify a real world system which involves encapsulation.

menio> OO is every where in the real world isn't the blue prints for a
menio> new Buick LeSabre simply a class ?

No. It is isn't even remotely so. A class is a mental construct,
precisely defined formal entity; a set of blueprints are not even
remotely anything like that.

menio> The interface to an instance of this class(brakes,gas
menio> pedal,sterring) provide an implementation independent means of
menio> communicating with it.

Do you really think that a pedal is anything remotely related to a
method or an attribute?

menio> Thus if this is so then isn't the OO program for matrix
menio> calculations modeled in terms of the physical world?

Well, I am seriously unable to see how. To me your arguments above are
incomprehensible gibberish, for you mix in various types of analogies
entities that to me are on entirely different levels and domains of
discourse. You have mentioned "classification, instances,
encapsulation", which are purely abstract mental activities, and nowhere
even remotely related to the physical world.

  menio> Thus it a fundamental process to resolve such questions through
  menio> examining systems of the source domain of the metaphor to gain
  menio> a better understanding of conceptual issues in the target
  menio> domain.

piercarl> Continue writing in this style and you'll become a wealthy
piercarl> OO-speak guru like Brady Gooch or Steve Mellor. ``A sucker is
piercarl> born every minute.''

menio> Drwaing parallels from my ideas and communication skills to those
menio> of accepted OO speakers is hardly an argument against my ideas
menio> and communication skills. In fact thanks for the complement :)

It is not an argument against or for: it is merely a good omen for your
future wealth.

Your phrase above is admirable: it is entirely content-free, but it
sounds profound and important, and uses a good number of buzzword:
"metaphor", "conceptual", "issues", "domain". This is going to sell very
well. As OOADWA has demonstrated, there are a lot of happy customers
that are prepared to pay quite a bit of money to read this sort of speak.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[Piercarlo Grandi]

>>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.edu.au> writes:

ok> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

piercarl> The observation above is, as per your remark, strictly
piercarl> speaking not general enough; but then just saying "OO module"
piercarl> instead of "class" would give it generality.

ok> Yes, but it would provide generality by means of obscurity and vagueness.
ok> What, for example, is an "OO module"?  I am aware of several languages
ok> having both objects and modules:
ok>  Ada 95 (module=package, object=tagged record instance)
ok>  ISO Pascal Extended with Object-Oriented Extensions to Pascal
ok> 	(module=module, object=object=pointer to extended record)
ok>  Oberon-2
ok>  Common-Lisp/CLOS (module=package, object=class instance)
ok>  C++ (module=translation unit maybe, or better, namespace; object=record)
ok> so the term "OO module" seems to mean something like "module containing OO
ok> components".

Well, I had hoped that it was very clear from the context is that I was
using ``OO module'' in the sense of ``module designed according to the
OO paradigm''. This encompasses, as I had written, both the concept of
class and of prototype (and of actor).

piercarl> For whether class or prototype based, an OO program is a
piercarl> collection of (OO) modules, and values at runtime are either
piercarl> instances of a class or clones of a prototype.

ok> (1) In Self, it's not who you are _cloned from_ that determines your
ok>     properties, but who _your parents are_.

Please reread more carefully the above paragraph: I was not talking of
the properties of a clone, but its instantiation relationship to
``something''. Most definitely in Self like in other prototype based
languages a clone is an instance of its prototype, and not of its
parents, just as in class based languages an object is an instance of a
class, and not of the parents of that class.

ok>     The nearest analogue of a class would be a partial function from
ok>     parent slot names to objects, e.g. the "class" (parent*=o123,
ok>     uncle*=o125, locale*=o23)

I think this point is based on confusing the distinction between
delegation and inheritance for reuse of interface and implementation,
with the distinction between class and prototype as a template for
instantiation.

The ``properties'' (operations etc.) of an object depend on the sum of
the properties of the class parents in (some) class based languages, and
on the sum of properties of the clone parents in (some) prototype
languages; however objects are still instances of one specific class and
of one specific prototype.

ok> (2) The parents of an object can vary through time.

This has nothing to do with being class or prototype based; it has
something to do with the ability to change ``types'' (metamorphism) at
runtime, which is not even unique to Self, or to prototype based OO
systems, or to OO systems.

piercarl> OO programs (as opposed to their executions) do occasionally
piercarl> contain some instances or clones, but this does not justify
piercarl> the observation that "OO programs are systems of interacting
piercarl> **objects**".

ok> It seems to me that there may be an equivocation involving the word
ok> "program" here.  Even for C++, it is true that
ok>     "the EXECUTION of a program is a system of interacting objects".

How? In what sense? How do objects interact in the execution of a C++
program? Are you sure? When I use some sort of debugger to watch the
execution of a C++ program I see threads running procedures in different
modules, those procedures call each other, passing objects as arguments;
I have never seen those objects interacting. It would be interesting to
know what I have been missing.

ok> You are saying "even for a prototype based language, a program is
ok> statically composed of classes and methods",

Not at all: this is presented as a quote, but it is nowhere like what I
have said; please reread more carefully what I have actually written:

  piercarl> For whether class or prototype based, an OO program is a
  piercarl> collection of (OO) modules, and values at runtime are either
  piercarl> instances of a class or clones of a prototype.

ok> but once again, nothing says that an OO language has to be batch
ok> compiled.

Nor have I ever written anything even remotely suggesting this. Are you
sure you have been reading my article? All I am saying is that an OO
program must be composed of modules, such modules may be classes or
prototypes (or actors). I have never stated or implied that such modules
or prototypes should be defined statically or should be batch compiled.

What I am saying is really just something obvious: that programs, and OO
programs no more and no less than others, are descriptions of
abstractions over their executions; therefore they are composed of
``template'' like entities, e.g. modules, types, procedures, that will
be instantiated into objects of various sorts at runtime, but such
objects are not described in the program itself.

A program, being an exercise in abstraction, does not describe a
potentially very large collection of execution objects; it describes
abstract entities, templates that give rise to those. Those templates
can then be dynamically defined, can be interpreted, compiled, or
anything in between; still the program is composed (almost exclusively)
of such abstraction/templates, and not of interacting objects.

ok> In the static sense which I think you have in mind,

This attempt at telepathy unforunately has failed. Please read what I
have written instead of trying parapsychology. I have never ever implied
any static sense; merely stated the obvious, that programs, whether
static or dynamic, are (mostly) composed of abstract entities (modules
for example), not of their instances.

Both abstrations and instances can be created statically or dynamically;
however (by and large) programs are systems of related (I would use
``interacting'') abstractions, like classes or prototypes in the OO
case, or procedures, not of instances; viceversa program executions are
(by and large) systems of interacting instances (threads, procedure
instances, actors, for example), but not abstractions.

Still, as I wrote it, I did not rule out static creation of instances or
runtime creation of abstractions.

ok> no "program" as such need ever exist.

Well, actually it must: for _something_ must be well defined at some
time to be called a ``program''. People write programs, and they get
signed off and released. If we had any sort of General Problem Solver,
the issue of writing and releasing programs would not arise; but then OO
would be largely useless as well, for OO is an idea on how to maximize
reuse in human-written programs. There is no reason to think that
maximizing reuse, or even just maximizing it in the OO way, would be the
right thing to do if the author of the program were a mechanical instead
of a human program synthetizer. Still, at any point in time, even a
program synthetizer must define a currently running program, the one
being executed.

piercarl> While the analysis and design of an OO program may/should be
piercarl> based on some mental image of how it is going to be executed,
piercarl> both activities are really about deciding into which
piercarl> ``encapsulated'' concepts and modules
                                        ^^^^^^
piercarl> to decompose the solution to a problem, and not into which
piercarl> ``interacting'' objects (even if in some languages OO modules
piercarl> are objects, and in some others objects to interact).

ok> Is the Sun "really" a nuclear reactor or is it "really" just a big
ok> ball of hot gas or is it "really" a source of heat and light?

The analogy fails here: for the Sun is a physical entity, and you are
just presenting different views (mental constructs) of it, and none may
be more appropriate than another.

But that an OO program *is* a set of modules is so by _construction_,
and that "analysis and design of an OO program [ ... ] are really about
deciding into which ``encapsulated'' concepts and modules to decompose
the solution to a problem" is not therefore a point of view, but the
construction process that produces it.

ok> I don't think anyone is denying that the "analyse, design static
ok> structure, build static structure, light blue touch paper and stand
ok> well back" approach is appropriate for a very large number of
ok> applications and projects.  (I am reading this in comp.lang.ada,
ok> after all, and I wouldn't be using Ada if I didn't think that was
ok> the right way to do some things.)

Not that I have written any of the sort, but it is an interesting point
of view, and is in fact correct, if one looks at programs as produced by
humans. At some point, if only because one is the author of a program
synthetizer, this is what must be done.

ok> The point is that it doesn't _have_ to be that way for _all_
ok> applications and projects, and there _are_ languages permitting a
ok> different mindset.

Not at all; you are confusing the notions of writing a program, and of
writing a program synthetizer. Some languages allow doing runtime
synthesis and execution of programs, some don't; but in both cases the
program *as delivered by the human* _must_ be statically defined, and in
both cases the program, whether its source is human/static or
mechanical/dynamic, _must_ be composed of modules, and not their
instances.

That human generated program _must_ be static is _unavoidable_, for
humans don't live inside computers and are not part of its execution
environment. (the point about static/dynamic program composition has
been raised by you; I had not in any way restricted my argument
explicitly or implicitly to statically constructed programs, or to those
authored by humans).

That programs, whether generated statically by a human or by a
synthetizer, or dynamically by a synthetizer, must (mostly) consist of
abstractions and not of their instances is also all but necessary, for
the essence of the usefulness of a program is that is it is an
abstraction over all its possible executions.

This applies both to OO and non-OO programs; in the particular case of
OO programs, whether they are statically or dynamically authored, by a
human or by another program, they must be (mostly) composed of
abstractions which are modules, and these modules must respect the OO
decomposition paradigm (encapsulation of all and only the procedures
that access the representation of a single type) whether these modules
are classes, or prototypes, or actors or whatever else.

It *is* possible to write OO programs which _are_ indeed systems of
interacting objects, for example an actor system program that prints the
result of summing 2 and 3, but this is a rather exceptional case because:

  * objects don't interact, even at execution time, except in actor
    systems.

  * writing programs as systems of objects, whether interacting or not,
    is rather less useful than writing them as systems of related
    abstractions, for example because in general there will be many less
    such abstractions than their instances, such being the nature of
    abstractions.

ok> In particular, I cannot imagine why anyone would want to rule out
ok> meta-design,

Who has ruled this out in this discussion? I am not aware of anbyody
having done so.

ok> where your program _at run time_ constructs new 'OO modules'
ok> (whatever they are) with good interfaces and starts using them.
ok> It's not too much to say that that's exactly how the Newton works.

That's perfectly OK. But the program that does this _must_, in order to
be OO, be decomposed in modules that satisfy the OO decomposition
strategy, and so the programs that is generated. Whether the latter, the
output of a programs synthetizer _should_ be structured in the OO way,
or any other way, or structured at all, is a rather interesting question
for which I don't think there are as yet any answers.

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Piercarlo Grandi]

>>> "snowballinfo" == Snowball  <snowballinfo@rase.com> writes:

snowballinfo> Robert C. Martin wrote:

Robert> Objects execute inside computers.

I would say that they can be stored; given that most OO systems are not
actor based, the idea that objects "execute" lacks generality.

Robert> They take up memory space and CPU cycles.

Usually but not always...

Robert> Classes are source code.

Never; they are linguistic constructs, often represented as source code
(but not always: for example in Smalltalk-80 there is no source code
representation for classes, only printed, displayed and reified
representations).

There is an interesting section in Bjarne's Stroustrup's "The design and
evolution of C++" on decoupling languages from their textual
representation as source code as a possible evolution of C++, on page
207, with title "Beyond files and Syntax":

  "  A C++ program contains a wealth of information that in a typical
  environment is available only to a compiler. I want that information
  at the programmer's fingertips. However, most people look at a C++
  programs as a set of source files  or as a string of characters. That
  is to confuse the representation with what is represented. A program
  is a collection of types, functions, statements, etc. To fit
  traditional programming environments, these concepts are represented
  as characters in files.
     Basing C++ implementations on character oriented tools has been a
  major impediment  to progress. [ ... much more ... ]"

I personally sympathize with the sentiment, but after many years I have
become persuaded that there is no hope of easy interchange except in
text files, and that easy interchange is of such paramount importance
that it overrides even the desires to have the representation of a
program in a more directly structural form than a stream of characters.

Robert> They specify the objects and create a structure from which the
Robert> objects are created.

snowballinfo> This is true for C++ and some other languages, however for
snowballinfo> Smalltalk Classes are objects which take up memory space
snowballinfo> (and sometimes CPU cycles).

Well, surely not in Smalltalk-80, which is arguably the ``classic''
Smalltalk that most people have heard of; which is the Smalltalk dialect
you are thinking of in which classes are objects, instead of being
merely represented by objects as in Smalltalk-80? Can it still be called
``Smalltalk''? After all that classes are not objects and that the two
concepts are very distinct is one of the major design decisions of
Smalltalk-80 (in the early versions of PARC Smalltalk the distinction
was, arguably, not that sharp).

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Piercarlo Grandi]

>>> "snowballinfo" == Snowball  <snowballinfo@rase.com> writes:

snowballinfo> Robert C. Martin wrote:

Robert> Objects execute inside computers.

I would say that they can be stored; given that most OO systems are not
actor based, the idea that objects "execute" lacks generality.

Robert> They take up memory space and CPU cycles.

Usually but not always...

Robert> Classes are source code.

Never; they are linguistic constructs, often represented as source code
(but not always: for example in Smalltalk-80 there is no source code
representation for classes, only printed, displayed and reified
representations).

There is an interesting section in Bjarne's Stroustrup's "The design and
evolution of C++" on decoupling languages from their textual
representation as source code as a possible evolution of C++, on page
207, with title "Beyond files and Syntax":

  "  A C++ program contains a wealth of information that in a typical
  environment is available only to a compiler. I want that information
  at the programmer's fingertips. However, most people look at a C++
  programs as a set of source files  or as a string of characters. That
  is to confuse the representation with what is represented. A program
  is a collection of types, functions, statements, etc. To fit
  traditional programming environments, these concepts are represented
  as characters in files.
     Basing C++ implementations on character oriented tools has been a
  major impediment  to progress. [ ... much more ... ]"

I personally sympathize with the sentiment, but after many years I have
become persuaded that there is no hope of easy interchange except in
text files, and that easy interchange is of such paramount importance
that it overrides even the desires to have the representation of a
program in a more directly structural form than a stream of characters.

Robert> They specify the objects and create a structure from which the
Robert> objects are created.

snowballinfo> This is true for C++ and some other languages, however for
snowballinfo> Smalltalk Classes are objects which take up memory space
snowballinfo> (and sometimes CPU cycles).

Well, surely not in Smalltalk-80, which is arguably the ``classic''
Smalltalk that most people have heard of; which is the Smalltalk dialect
you are thinking of in which classes are objects, instead of being
merely represented by objects as in Smalltalk-80? Can it still be called
``Smalltalk''? After all that classes are not objects and that the two
concepts are very distinct is one of the major design decisions of
Smalltalk-80 (in the early versions of PARC Smalltalk the distinction
was, arguably, not that sharp).

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Robert C. Martin]

In article <E1Hpuz.5w2.0.-s@inmet.camb.inmet.com>,
stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> Robert C. Martin (rmartin@oma.com) wrote:
> 
> : This is an architectural choice; and it is based upon which kind of change
> : is more likely.  If it is more likely that new functions will be added to
> : existing modems, then the switch statement is probably the better choice.
> : If it is more likely that new kinds of modems will be added, then the class
> : structure is probably better.
> 
> This is certainly a good point, but I think that the class structure
> still has certain advantages over the "switch" structure even when adding 
> new "functions" is somewhat more common than adding new modem variants.

Building class structures is also my preference; even when new functions
are added with relative frequency.  I will use 'Visitor' or 'Decorator'
to add those functions.  However, in the extreme case, when adding new
new functions will continue to be the primary means of modifying the software,
the switch statement route is probably the better choice.
> 
> In the "switch" world (in which I have spent many pleasant hours ;-),
> one tends to presume that almost every new function requires its
> own personal switch statement.  In the "class" world, when adding
> a new operation, one has the option of implementing it in terms of
> some preexisting more primitive operation, rather than creating
> a new operation for every modem variant. 

This is a matter of style.  There is no reason why primitives cannot
be created when using switch statements.  That some people tend not
to do that is unfortunate, but no different from the fact that some people
tend to build classes with no behaviors other than accessors and mutators.
 
I don't want to seem that I am advocating a programming structure based
upon procedural principles.  Generally I do not support such structures. 
I ususally try to arrange the structure of the program such that the 
'types' vary more frequently than the functions.  However, there are times
when a procedural architecture is the right choice.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

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

Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Tucker Taft]

Robert C. Martin (rmartin@oma.com) wrote:

: ...There is no reason why primitives cannot
: be created when using switch statements.  

I certainly agree.  What I was trying to convey was the "typical"
behavior, not the "possible" behavior.  Empirically, you take the
same programmers, expose them to the same problem, and my anecdotal
evidence indicates that they tend to create more switch statements than
would be necessary if they focused on creating the right "primitives,"
resulting in even more information "spreading" and de-modularization.

: Robert C. Martin    | Design Consulting   | Training courses offered:
: Object Mentor       | rmartin@oma.com     |   Object Oriented Design
: 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
: Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA