Re: Good Design Strategies <Was comments on comments>

Re: Good Design Strategies <Was comments on comments>

[Erland Sommarskog]

Bill Wolfe (wtwolfe@hubcap.clemson.edu) writes:
Rob Jellinghaus (jellinghaus-robert@CS.YALE.EDU) said:
>> Everyone involved in this discussion should get their hands on a copy
>> of Bertrand Meyer's book _Object-Oriented Software Construction_, Prentice-
>> Hall, 1988.  The design philosophy being discussed sounds virtually
>> identical to Meyer's exposition of the object-oriented design method.
>
>    I'd suggest Booch's coverage of object-oriented design in
>    "Software Components with Ada" instead; Meyer's book comes
>    bound up with a rather flaky programming language.

I don't want to start an Ada vs. Eiffel debate, but the view that
Eiffel is a flaky language is something Bill Wolfe have to stand for 
himself.

What I like to stress is: Ada is *not* an object-oriented language.
I used to think that, but there are just to much missing. Particulary
inheritance and dynamic typing. And although this is a trivial fact to
realise, it still seems necessary that from time to time make a reminder
about this. Due to Gary Booch and others it is easy for the casual
reader to get the impression that Ada <=> object-oriented programming.

But it's true that Ada is better for applying object-oriented strategies
than most other "conventional" languages.

As for bottom-up vs. top-down, Meyer explains this very well in his
book, and it's certainly applicable to the recent discussion. One 
drawback with top-down I haven't seen well covered, is the big risk
that you never see that two leaves are the same, or see it too late,
so you get the same code in two places. (Or even worse, you should
have two identical pieces of code, but in fact they are different.)
  The project I'm in right now was designed top-down, if it was designed
at all. (It's a real mess, but don't blame me I came in too late.)
And it is a clear mistake. OK, there is a set of library routines 
for low-level objects like formatting routines and simple database
accesses. But very little for handling of high-order objects like
account statements and other application specific things. I have 
tried to introduce it, but when you need more than a day for it,
you get in conflict with the time schedule, whichh of course give
no place for "luxury" like that.
-- 
Erland Sommarskog
ENEA Data, Stockholm              This signature is not to be quoted.
sommar@enea.se

Re: Good Design Strategies <Was comments on comments>

[William Thomas Wolfe,2847,]

From article <4343@enea.se>, by sommar@enea.se (Erland Sommarskog):
> I don't want to start an Ada vs. Eiffel debate, but the view that
> Eiffel is a flaky language is something Bill Wolfe have to stand for 
> himself.
> 
> What I like to stress is: Ada is *not* an object-oriented language.
> I used to think that, but there are just to much missing. Particulary
> inheritance and dynamic typing. And although this is a trivial fact to
> realise, it still seems necessary that from time to time make a reminder
> about this. Due to Gary Booch and others it is easy for the casual
> reader to get the impression that Ada <=> object-oriented programming.

    I quote from ACM SIGADA Ada Letters, March/April 1989, Volume IX,
    Number 2, Page 10:

      Software Productivity Solutions, Inc., has announced a new product,
      Classic-Ada (tm), which allows Ada software developers to use
      inheritance and dynamic binding in object-oriented Ada designs.
      The product runs on VAX/VMS and Sun/Unix systems.  For more
      information, contact:

         (407) 984-3370       Ms. Lois Valley
                              Vice President, Marketing
                              Software Productivity Solutions, Inc.
                              P.O. Box 361697
                              Melbourne, FL  32936-1697


   I stand by my statement regarding Eiffel's flakiness.  Obviously 
   it's just my opinion, and others may differ, but I think it's a 
   very well-founded opinion.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Good Design Strategies <Was comments on comments>

[Mike Coffin]

From article <4574@hubcap.UUCP> (William Thomas Wolfe,2847,):
>    I stand by my statement regarding Eiffel's flakiness.

Do you mean that the language design is flakey, or that an
implementation is flakey?  If the former, what is flakey about it?
-- 
Mike Coffin				mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci.	{allegra,cmcl2}!arizona!mike
Tucson, AZ  85721			(602)621-2858

Re: Good Design Strategies <Was comments on comments>

[Bob Hathaway]

In article <4343@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
>But it's true that Ada is better for applying object-oriented strategies
>than most other "conventional" languages.

I strongly agree, most other conventional languages are data-structure
oriented and not Adt/object oriented in programming constructs or
methodology.

>As for bottom-up vs. top-down, Meyer explains this very well in his
>book, and it's certainly applicable to the recent discussion.

Could you elaborate on this, does he advocate top-down, bottom-up, ???
I haven't read Meyer's book.  

Bob Hathaway
rjh@purdue.edu

Re: Good Design Strategies <Was comments on comments>

[Steven D. Litvintchouk]

In article <4574@hubcap.UUCP> billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes:

> From article <4343@enea.se>, by sommar@enea.se (Erland Sommarskog):
> > What I like to stress is: Ada is *not* an object-oriented language.
> > [it lacks] inheritance and dynamic typing.....
> 
>       Software Productivity Solutions, Inc., has announced a new product,
>       Classic-Ada (tm), which allows Ada software developers to use
>       inheritance and dynamic binding in object-oriented Ada designs.

Lest anyone get the wrong impression about Classic-Ada, let me
clarify: The Classic-Ada language is *not* legal Ada.  It is a unique
dialect, which consists of Ada extended (nicely) with a new
construct--the class--with inheritance and dynamic binding.

SPS, Inc., is to be commended for attempting to improve Ada's support for
object oriented programming.  But the resulting Classic-Ada language
is not legal Ada.  Classic-Ada programs must be put thru SPS'
translator to generate legal Ada.

Mr. Sommarskog is quite correct.  Ada lacks any specific mechanism for
defining relationships among classes; the Classic-Ada language
provides just this mechanism.  

Eiffel does manage to provide inheritance in a reasonably
strongly-typed framework.  In their zeal to facilitate object-oriented
programming, SPS added both inheritance and dynamic binding to
Classic-Ada.  Was dynamic binding necessary?  It seems to entirely
defeat the safety and reliability that was a goal of Ada.

I believe that Eiffel tries to provide both separate compilation and
generics, just like Ada.  And, just like Ada, I would suspect that the
early Eiffel compilers will have "teething problems."  (At OOPSLA '88,
I recall that several Eiffel users reported problems with the Eiffel
library manager; a real case of deja vu for us veteran Ada
programmers.)


Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753
ARPA:  sdl@mitre-bedford.arpa
UUCP:  ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl

	"Those who will be able to conquer software will be able to
	 conquer the world."  -- Tadahiro Sekimoto, president, NEC Corp.

Re: Good Design Strategies <Was comments on comments>

[Steven D. Litvintchouk]

In article <9443@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes:

> From article <4574@hubcap.UUCP> (William Thomas Wolfe,2847,):
> >    I stand by my statement regarding Eiffel's flakiness.
> 
> Do you mean that the language design is flakey, or that an
> implementation is flakey?  If the former, what is flakey about it?

From what I was able to gather at OOPSLA '88, the current Eiffel
*implementations* are indeed flaky, but no more so than was any Ada
compiler developed prior to 1985.

I am extremely interested in finding out whether Eiffel compilers do a
better job compiling Eiffel generics, than Ada compilers do compiling
Ada generics.  I remain disappointed in how poorly Ada generics are
implemented by some Ada compilers.


Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753
ARPA:  sdl@mitre-bedford.arpa
UUCP:  ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl

	"Those who will be able to conquer software will be able to
	 conquer the world."  -- Tadahiro Sekimoto, president, NEC Corp.

Re: Good Design Strategies <Was comments on comments>

[Rob Jellinghaus]

In article <6127@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes:
>In article <4343@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
>>As for bottom-up vs. top-down, Meyer explains this very well in his
>>book, and it's certainly applicable to the recent discussion.
>
>Could you elaborate on this, does he advocate top-down, bottom-up, ???
>I haven't read Meyer's book.  

Meyer advocates neither, although his strategy (which he terms simply
"object-oriented design") is closer to bottom-up than to top-down.  His
claim is that the best way to obtain reusability, maintainability, and
reliability (which should all result from good software engineering
technique), the best method is to focus design on the data objects that
the program is manipulating.  The resulting design can often be very
obvious, as it isn't too hard to find the objects in most applications.
Object-oriented languages then package the objects and their internal
representation together with the routines that operate on them, and
thus separate interface from implementation.  A good object-oriented
system quite often will consist largely of software components that
have been taken from older projects, which is not really a possibility
in either the top-down or the bottom-up model.  If the map of a top-
down system is a tree, with the principal function at the top, then
an object-oriented system is a net, with each object providing
services to other objects, with no clear hierarchical arrangement;
this enables the system to be locally modified without global effects.

That's a very brief summary of Meyer's arguments.  He goes into more
detail, with examples, in the book.

To respond briefly to Bill Wolfe's comments about Eiffel being flaky:
I can't say how good a language Eiffel is in the real world.  However,
Meyer uses it very effectively as an exemplar of a good object-oriented
programming language, and at every step throughout the book he discusses
the design decisions he made in creating Eiffel, and what the impli-
cations are for object-oriented programs.  He discusses the pros and 
cons of Ada, Smalltalk, etc., etc. at length, and he talks about the
essential features of any "true" (in his definition) object-oriented
language: multiple inheritance, genericity, polymorphism, dynamic
binding, etc.  Even if you don't agree with his decisions, his
exposition is very clear and (in my opinion) well-written.

(You can probably tell I like the book!)

>Bob Hathaway
>rjh@purdue.edu


Rob Jellinghaus                | "Next time you see a lie being spread or a
jellinghaus-robert@CS.Yale.EDU |  bad decision being made out of sheer ignor-
ROBERTJ@{yalecs,yalevm}.BITNET |  ance, pause, and think of hypertext."
{everyone}!decvax!yale!robertj |     -- K. Eric Drexler, _Engines of Creation_

Meyer on Top-down/Bottom-up (was: Good Design Strategies)

[Edward C Horvath]

In article <4343@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
>As for bottom-up vs. top-down, Meyer explains this very well in his
>book, and it's certainly applicable to the recent discussion.

From article <6127@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway):
> Could you elaborate on this, does he advocate top-down, bottom-up, ???
> I haven't read Meyer's book.  

The book is a GOOD read, and my summary can't hope to do it justice, but:
Meyer makes a good case that your current programming assignment is NOT
the "real" objective, since the goals and requirements of that program
will change, and something else (the same but with *one more feature*; or
a different program that deals with many of the same data) will be needed
"soon."  So: don't start by modeling "function" at all, start with modeling
the objects in the problem domain.  The objective isn't "new payroll
system," it's "understand your enterprise," with a *current* emphasis
on modeling employees, benefits, salaries, bonuses, tax situations, etc.
Meyer recommends deferring the functional objective as long as possible.

What emerges is more like bottom-up than top-down, but with important
differences; to me, bottom-up always meant "build the utility libraries
first."  Once again, emphasis on function.  Modeling "employee" requires
deciding what data and operations capture the notion of employee.  And you
can defer things, much as you do in -- hmm -- top down design!  Example:
all employees get paid, but the algorithm is different for hourly v. salaried
employees.  OK, declare something you do to an employee -- "Pay" -- and defer
the definition.  Special cases of employee will instantiate the deferred
method in different ways.

The presumed benefits -- and again, I haven't made the case, but Meyer is
quite convincing -- are that you emerge with a model of relevant entities in
your environment, not "merely" a program.  Thus the next program is already
well on the way to being done: add more classes as needed, more methods as
needed, and there it is.  Here again, Meyer makes a strong case that already-
defined classes should be both *open* and *closed* with respect to
modification.  "Open" is accomplished by letting older classes be members of
or ancestors of new classes; in particular, inheritance allows you to redefine
just those features of the new class that you need to change.  "Closed" is
just that a well-tested class can be cast in concrete: you needn't mess with
it, because you can modify by inherit with override.

He also makes a rather strong case for multiple inheritance, which is
lacking in most O-O languages (but is in Eiffel and C++ 2.0).  I don't have 
the slightest intention of starting a flame war by trying to summarize
that issue here: but go read Meyer's treatment.

Enough.  Go get the book, it may change your life.

=Ned Horvath=

Re: Good Design Strategies <Was comments on comments>

[Mikael Eriksson]

In article <4574@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
>From article <4343@enea.se>, by sommar@enea.se (Erland Sommarskog):
>> What I like to stress is: Ada is *not* an object-oriented language.
>
>    I quote from ACM SIGADA Ada Letters, March/April 1989, Volume IX,
>    Number 2, Page 10:
>
>      Software Productivity Solutions, Inc., has announced a new product,
>      Classic-Ada (tm), which allows Ada software developers to use
>      inheritance and dynamic binding in object-oriented Ada designs.

You mean that they sell a *super-set* of ADA?

Mild sarcasm on:
This must be what we all have been waiting for !
Mild sarcasm off.

ADA is too much of an elephant already. I totally agree that
inheritance is good but ADA would have to be pruned a lot
before something new should be added to it.

  mikael
-- 
Mikael Eriksson (Email: mikael@sm.luth.se)
.........
You are in error. 2+2=5
Thank you for your cooperation. The Computer.

Re: Good Design Strategies <Was comments on comments>

[Robert Claeson]

Bill,

In article <4574@hubcap.UUCP>, you write:

>    I stand by my statement regarding Eiffel's flakiness.  Obviously 
>    it's just my opinion, and others may differ, but I think it's a 
>    very well-founded opinion.

Can you please elaborate on that? I'm sure there are quite a few people
around who wants to know in what ways Eiffel is flaky.

-- 
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
Tel: +46 (0)758-202 50  Fax: +46 (0)758-197 20
EUnet:   rclaeson@ERBE.SE               uucp:   {uunet,enea}!erbe.se!rclaeson
ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET  BITNET: rclaeson@ERBE.SE

Re: Good Design Strategies <Was comments on comments>

[Dave Jones]

From article <52101@yale-celray.yale.UUCP>, by jellinghaus-robert@CS.YALE.EDU (Rob Jellinghaus):

> A good object-oriented
> system quite often will consist largely of software components that
> have been taken from older projects, which is not really a possibility
> in either the top-down or the bottom-up model.  If the map of a top-
> down system is a tree, with the principal function at the top, then
> an object-oriented system is a net, with each object providing
> services to other objects, with no clear hierarchical arrangement;
> this enables the system to be locally modified without global effects.
>



Point of semantics well taken.  Perhaps I should not be using the term
"bottom-up".  I guess if you get into the topology of it, inheritance
of structure (not reference), yields a directed acyclic graph which
may have lots of local bottoms and tops.  But if I said, "infrenum-supremum"
programming, who would know what I was talking about?




                              Dave J.

Re: Good Design Strategies <Was comments on comments>

[William Thomas Wolfe,2847,]

   [Due to the Followup-To, this article didn't make it to
    comp.lang.ada, although it obviously should have... Bill]

From: rsimonian@x102c.harris-atd.com (Simonian RP 66449)
>>
>>      Software Productivity Solutions, Inc., has announced a new product,
>>      Classic-Ada (tm), which allows Ada software developers to use
>>      inheritance and dynamic binding in object-oriented Ada designs.
>
>You mean that they sell a *super-set* of ADA?
>
>Mild sarcasm on:
>This must be what we all have been waiting for !
>Mild sarcasm off.
>
>ADA is too much of an elephant already. I totally agree that
>inheritance is good but ADA would have to be pruned a lot
>before something new should be added to it.

Classic-Ada is *NOT* a super-set of Ada.  Harris has also developed a
tool, called InnovAda, for true object-oriented programming in Ada 
(multiple-inheritance, dynamic binding, run-time message evaluation,
and so on).  Such tools generate compilable Ada code; if you wanted to,
you could have created the same code generated by the tool.  InnovAda
and similar tools are preprocessors which enhance productivity by giving
the designer/programmer a powerful development and maintenance environment.
There are graphic design tools on the market which do some amount of
code generation; would you consider those to be supersets of Ada?

InnovAda and other object-oriented preprocessors still provide one with
all the nice features of Ada, plus they supplement the language with the
advantages of true object-oriented design.  I have found these capabilities
to be indispensable for several problem domains; particularly when one
tries to implement Artificial Intelligence in Ada.



Richard P. Simonian     407/984-6006
Natural Language Processing Group
Harris GISD, Melbourne, FL  32902             
Internet: rsimonian@x102c@trantor.harris-atd.com

Re: Good Design Strategies <Was comments on comments>

[Michael Schwartz]

In article <4622@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
>...
>InnovAda and other object-oriented preprocessors still provide one with
>all the nice features of Ada, plus they supplement the language with the
>advantages of true object-oriented design. .,..
>
>Richard P. Simonian     407/984-6006

Lex and Yacc generate wonderful C code as well -- But the implementation
has to be judged by where it is maintained.

Classic Ada and InnovAda, by that measure, ARE languages in their own
right, and ARE supersets of Ada (legal Ada is legal Classic Ada).

On the other hand, C originally did not include its current
preprocessor, so the language definition changed to include it.

Whatever Language you use, it should be fun and useful.
-- 
Michael Schwartz
ncar!dinl!schwartz
MSchwartz@Dockmaster.ARPA

Re: Good Design Strategies <Was com

[ryer]

        Please excuse the following flame on whether a given "tool" is
        a compiler and whether its input space defines a language.
        Prompted by the posting excerpted below:

>/* Written  5:25 pm  Mar  1, 1989 by billwolf@hubcap.UUCP in inmet:comp.lang.ada */
>/* ---------- "Re: Good Design Strategies <Was com" ---------- */

>Classic-Ada is *NOT* a super-set of Ada.  Harris has also developed a
>tool, called InnovAda, for true object-oriented programming in Ada 
>(multiple-inheritance, dynamic binding, run-time message evaluation,
>and so on).  Such tools generate compilable Ada code; if you wanted to,
>you could have created the same code generated by the tool.  InnovAda
>and similar tools are preprocessors which enhance productivity by giving
>the designer/programmer a powerful development and maintenance environment.
>There are graphic design tools on the market which do some amount of
>code generation; would you consider those to be supersets of Ada?

Is "Classic Ada" (or InnovAda) an Ada superset?

a. Does using it result in SOURCE programs that aren't accepted by other
Ada compilation systems?

b. Does anyone reading the SOURCE code have to know more than Ada to
understand it?

c. Does it get confused when I put some reusable Ada components into the
SOURCE code (e.g. by complaining that "Classic-Ada" keywords are being used as 
variable names)?

In the above, "SOURCE code" is defined as that which the programmer writes and
the maintainer maintains, and which the design documentation describes in
detail.  It is the SOURCE code which contains comments that map accurately
to block and variable names, types, etc.  I belive that for "Classic-Ada", 
SOURCE code means the "Ada with extensions".  

Therefore, my opinion is that "Classic-Ada" is a programming language which
has all the drawbacks of any other Ada superset.  I'm sure it has 
advantages as well.  Whether "Classic-Ada" is a language is not dependent
on whether it is compiled in a single step, or in two steps with Ada
generated in between.

Current Syntax Editors and Graphic Design tools are not Ada supersets, because 
they are used to intially generate the Ada which is then maintained directly.
These tools help *generate* the SOURCE code which is still pure Ada.  

If the graphics form of a program was used to describe the entire program, and 
the comments and documentation refer to the graphics form, and maintenance is 
done by modifying the graphics and automatically re-generating the Ada, then 
graphics would be the SOURCE code, and such a CASE tool *would* be a programming
language different from Ada.  I have not heard of any such tools yet.

Mike Ryer
Employed by Intermetrics, Inc., but speaking for myself

Re: Good Design Strategies <Was comments on comments>

[Robert A. Agnew]

In article <45491@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes:
>In article <4574@hubcap.UUCP> billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes:
>
>> From article <4343@enea.se>, by sommar@enea.se (Erland Sommarskog):
>>       Software Productivity Solutions, Inc., has announced a new product,
>>       Classic-Ada (tm), which allows Ada software developers to use
>>       inheritance and dynamic binding in object-oriented Ada designs.
I believe there is also a proposal for the 199x revision to Ada to 
introduce Package types. The package type is the analogy of the C++
class. As far as I know there has been no proposal to include constructor
and destrustor operators, but this certainly should be considered.

	

Re: Ada Design Tools <was Good Design Strategies>

[Simonian RP 66449]

In response to Mike Ryer's comments:
>
>Is "Classic Ada" (or InnovAda) an Ada superset?
>

I can't speak for Classic-Ada, but InnovAda generates and maintains legal
Ada source code.  The code is documented and readable.  The user is not
expected to deal with the generated code, but is not prohibited from doing so.

>
>If the graphics form of a program was used to describe the entire program, and 
>the comments and documentation refer to the graphics form, and maintenance is 
>done by modifying the graphics and automatically re-generating the Ada, then 
>graphics would be the SOURCE code, and such a CASE tool *would* be a programming
>language different from Ada.  I have not heard of any such tools yet.
>

What you're talking about here is just different representations of a problem.
It will still be very obvious that Ada is the language being used by the CASE
tool.  I feel that Ada provides a very good mechanism for building specifica-
tion level tools, either graphical or textual.  I see a distinct advantage
to any tool that removes a burden from programmers/designers (i.e., by
generating implementation code) and allows one to work at a more abstract
and natural level.  True object-oriented programming tools are one solution.

Newsgroups: comp.lang.ada
Subject: Re: Good Design Strategies <Was com
Summary: 
Expires: 
References: <4622@hubcap.UUCP> <124000034@inmet>
Sender: 
Reply-To: ryer@inmet.UUCP             
Followup-To: 
Distribution: 
Organization: Harris Corporation GSS, Melbourne, Florida
Keywords: 

Richard P. Simonian     407/984-6006
Natural Language Processing Group
Harris GISD, Melbourne, FL  32902             
Internet: rsimonian@x102c@trantor.harris-atd.com