comp.lang.ada
 help / color / mirror / Atom feed
* Re: Good Design Strategies <Was comments on comments>
@ 1989-02-27  9:09 Erland Sommarskog
  1989-02-27 15:46 ` William Thomas Wolfe,2847,
  1989-02-28  1:16 ` Bob Hathaway
  0 siblings, 2 replies; 26+ messages in thread
From: Erland Sommarskog @ 1989-02-27  9:09 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: comments on comments
@ 1989-02-23  2:15 Bob Hathaway
  1989-02-23  7:22 ` Dave Jones
  0 siblings, 1 reply; 26+ messages in thread
From: Bob Hathaway @ 1989-02-23  2:15 UTC (permalink / raw)



(I write)
>|This seems to go backwards.  Programmers should first design
>|their software then implement it.  You seem to be advocating 
>|implementation then design.  The descriptive algorithm should 
>|come first, then the code.

In article <9689@ihlpb.ATT.COM>, nevin1@ihlpb.ATT.COM (Liber) writes:
>I have a problem with Top-Down programming (design then
>implementation); it happens to be the same problem I have with
>Bottom-Up programming (implementation then design).  You so eloquently
>point it out in your next sentence:  

Design then implementation is not necessarily top-down programming.
First some terminology.  Top-down design involves a functional view
starting at the top and working its way down.  Top-down implementation
is a programming methodology which begins coding (implementing the design)
at the top level procedures.   Bottom-up design also involves a 
functional (procedural) view but starts design with the bottom level
procedures and bottom-up implementation begins coding with the bottom
level procedures.  For the past several years (since my first program)
I began with an Adt, or more object oriented approach to design and
implementation.  I would study the problem and form an informal solution
and identify the Adts (objects in the system).  The informal solution
would be in a high level pseudo-code and was usually top-down for the
main program and within modules.  This provided a modular design with
abstract data types.  It could also be categorized as a top down design
with the data structures and functionally related subprogram units
encapsulated within modules.  The Adts provided an excellent starting point
for coding.  They could be separately tested and frequently the driver
program for these tests was most conveniently the original program and
after "testing" my Adts the program was finished.  The fact that I was
often done weeks early attested to the techniques success.  The informal
pseudo-code is refined into working code but since pseudo-code usually
offers a more informal description of an algorithm than working code,
it is easier to understand.

>|If the algorithm can be coded in a
>|truly self descriptive form no comments will be necessary but in
>|instances where the design and implementation are not the same,
>|comments help.

>But design and implementation should not differ!  If this is happening,
>one of the two is wrong!  In the case of Top-Down, I would guess that
>it is probably the design that is wrong; something wasn't taken into
>account until someone actually tried to implement the design.  The

I disagree.  Pseudo-code is much easier to read than programming code.
Comments reflect algorithms in an informal way that is more understandable
than programming code.  They are semantically equivalent, but if I think an
informal description is easier to read, I'll provide it (you can put me in
the conscientious category of programmer who is always trying to write better
software).  When an algorithm can be directly expressed in code (ie. just add
underscores) as is often the case, comments aren't necessary.

>problem with Top-Down (and Bottom-Up) programming is that there is no
>feedback mechanism.  What happens when an implementation discovers a
>bug in a design?  Does it happen that people go back and formally
>re-review an already approved design document?  Not nearly as often as
>it should, I suspect.  Or at least go back and change the design to
>match the implementation?  It gets even worse when there are many
>levels to the design.  There needs to be a feedback loop.

Any conscientious programmer will update the appropriate documents.  But
if put on a system where the comments are in doubt, I can always ignore
them.  When working with large C programs, I often waste a lot of time
trying to understand undocumented field declarations and incomplete function 
descriptions.  A correct comment would save time and it should be obvious
from the code if a comment isn't accurate.  As suggested in an earlier
article, large software projects with elaborate standards can hold design and
code reviews to insure correctness.

>|True, but requiring Joe Programmer to design his software first will help,
>|and the design can be included in the comments.

>Yes, but until we have good hypertext systems that will allow Joe
>Programmer to do this easily and painlessly, he basically has to
>maintain TWO design documents, and when a human being has to do it, it
>tends to get out of sync, and eventually useless.

Yes, thats why there are software development environments and APSE's and why
I keep asking for them:-)

|I think the poorly designed, poorly documented systems have caused most
|of the trouble, not out-of-date commenting.   Just follow the convention
|that when code is updated so are the comments.  The benefits of a well
|commented design far outweigh the costs.  Well documented code is easy
|to understand and modifications to the software can be done in terms of
|the higher-level design.  Since the design is directly implemented in the
|code, corresponding changes should be easy.

> The real question is:  what can we do to make this happen?

Be conscientious!

Bob Hathaway
rjh@purdue.edu

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~1989-03-11 11:15 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-02-27  9:09 Good Design Strategies <Was comments on comments> Erland Sommarskog
1989-02-27 15:46 ` William Thomas Wolfe,2847,
1989-02-27 17:07   ` Mike Coffin
1989-02-28  4:16     ` Steven D. Litvintchouk
1989-02-28  4:11   ` Steven D. Litvintchouk
1989-03-04  1:25     ` Robert A. Agnew
1989-02-28 11:23   ` Mikael Eriksson
1989-03-01 22:25     ` William Thomas Wolfe,2847,
1989-03-02 22:14       ` Michael Schwartz
1989-03-03 17:26       ` Good Design Strategies <Was com ryer
1989-03-06  2:05         ` Ada Design Tools <was Good Design Strategies> Simonian RP 66449
1989-02-28 12:22   ` Good Design Strategies <Was comments on comments> Robert Claeson
1989-02-28  1:16 ` Bob Hathaway
1989-02-28  4:55   ` Rob Jellinghaus
1989-02-28 22:35     ` Dave Jones
1989-02-28  6:28   ` Meyer on Top-down/Bottom-up (was: Good Design Strategies) Edward C Horvath
  -- strict thread matches above, loose matches on Subject: below --
1989-02-23  2:15 comments on comments Bob Hathaway
1989-02-23  7:22 ` Dave Jones
1989-02-23 22:50   ` Good Design Strategies <Was comments on comments> Bob Hathaway
1989-02-25  1:07     ` Dave Jones
1989-02-26 19:34       ` Rob Jellinghaus
1989-02-27  0:58         ` William Thomas Wolfe,2847,
1989-02-27 15:29           ` John Baugh
1989-02-28  0:53       ` Bob Hathaway
1989-02-28 22:13         ` Dave Jones
1989-03-03  5:45           ` Bob Hathaway
1989-03-08 17:14             ` David P. Schneider
1989-03-11 11:15             ` Stuart H. Ferguson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox