Good Design Strategies <Was comments on comments> 
Author Message
 Good Design Strategies <Was comments on comments>

In response to Mike Ryer's comments:

Quote:

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

Quote:

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

Sender:

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            



Mon, 17 Aug 1992 02:05:00 GMT  
 Good Design Strategies <Was comments on comments>
Another point to note is that for large (complex) projects, identifying the
subject of ADTs (e.g., Object-oriented design) may require an analysis step
using traditional requirements-oriented techniques, such as  data-flow  di-
agrams.   The associated data dictionary would then be used to identify the
objects or components, and the transform bubbles would be used to  identify
the required operations on those objects.

Note that traditional software engineering (Pressman, for instance)  breaks
the pre-release part of a project into *three* phases: analysis first, then
design, and finally implementation.   Analysis  tries  to  identify  system
characteristics   and   requirements   without   going   into   design-  or
implementation-level descriptions (which would  prematurely  constrain  op-
tions); design translates the output of analysis into implementable specif-
ications, and implementation puts code behind them thar words.   Note  that
the differentiation is a matter of degree more than type.

I'm gearing up for a term paper on the subject  of  object-oriented  design
and software reuse in complex projects, and if you can provide me with some
additional references in the trade journals, or have  had  experience  with
using ADT/object-oriented design on large projects, your mail would be wel-
come.

                                                David P. Schneider
                                                     BiiN (tm)
                                                  Wednesday, 3.8



Mon, 17 Aug 1992 17:14:00 GMT  
 Good Design Strategies <Was comments on comments>

Quote:

>>What is needed to improve self-documentation are better programming languages.
>This is certainly true, but even the "better" programming languages allow for
>the inclusion of comments. There will probably always be parts of the
>programmer's concept which need to be expressed in an informal way through
>comments.

I have learned to include comments like "Doing it <this_way> appeared obvious
at first but didn't work because of <something>".  I hate solving the same
problem twice (even if it a year or so later).  You can also list what trade
offs lead you to solve a problem the way you did.  The code can never tell
you the why.  Telling the person maintaining the code (maybe yourself) why
something was done will help them from creating those crash every 5th
Tuesday type of bugs.
----

--



Mon, 17 Aug 1992 21:12:00 GMT  
 Good Design Strategies <Was comments on comments>


| >...My assertion -- must I repeat it again? --
| >is that good modules are more likely to come from a bottom-up approach.
| Ok, I'll admit you've made a good point although I still think starting at
| the top is the natural way to design systems (and algorithms).
 [ ... ]
| Ok, how about a quick example starting at top level.  When designing
| a "Classical" compiler/interpreter front-end, I know the structure will
| consist of a scanner to read input and a parser to read the grammar.  
 [ ... ]

Bob goes on to develop a design for a compiler front end in a very
rational and structured top-down type way.

The problem with this example is that it already a solved problem.
Parsing computer languages is such a well solved problem in fact that
there are tools to generate these programs automatically from terse
formal descriptions.

The real test of a design methodology is to try it on a not-so-well
solved problem.  How would you go about designing a WYSIWYG text
processing program, or a hyper-text environment, or a graphical
user interface toolkit?  (If you've done these before, substitute
something you have no IDEA about how to design.)

The pure "top-down" approach starts with some black box called "the
system" which you then break into smaller units and those into even
smaller units until you have something you can implement in a page
or two of code.  The difficulty is that the first decision you have
to make (i.e. breaking "the system" into a first level of components)
is the most far-reaching and nearly impossible to make without knowing
the whole design first.

Also, you know that users are going to demand things you can't imagine
now, so how do you go about designing your systems now so they are
expandable enough to meet the needs of the future?

Reference:  David Parnas, Paul Clements "A Rational Design Process:
                How and Why to Fake It."  IEEE trans soft-eng Feb 1986

The first part of the article is priceless.
--

                Action by HAVOC



Mon, 17 Aug 1992 11:15:00 GMT  
 
 [ 53 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software