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

[Bill Gooch <bill@iconcomp.com>]

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