Re: Ada & PDL (ick !)

[prism!jm59@gatech.edu (MILLS,JOHN M.)]

In article <EACHUS.92Dec10165132@oddjob.mitre.org> eachus@oddjob.mitre.org (Rob
ert I. Eachus) writes:
>
>In article <1992Dec10.154343.24720@mksol.dseg.ti.com> strohm@mksol.dseg.ti.com
 (john r strohm) writes:
>
>>  Which raises my old favorite question: As I understand it, the
>>  output of the CODING phase of the project is compilable code, while
>>  the input to the coding phase is the design of the (insert
>>  buzzphrase of your choice here) to be coded.

I normally _try_ to divide into: design, code, debug, integrate, [losts more
debug], test, vacation.

I know it's not that simple, but design concentrates on data and _what_
processing takes place between modules, routines, tasks, ..., _not_ on
the processing implementation.  Data structures, for example, should be
designed as early as possible, and should specify 'internal interfaces' of the
code.

If I don't always realize my original design, I at least start with _some_
design, so I know "how much is enough" for each major project activity.

YMMV.

>>  Now we have PDL that is compilable and compiled and is the same lanugage as
>>  the final implementation language for the project.

Contractually, we are often required to submit our design to outside review,
and this should be done before much effort is expended on coding.  (I would
try "proof of concept" code samples, try to confirm whether my timing
targets are attainable, etc, with some compiled code, naturally.)  I have
also been required to submit my designs to internal review, along with
H/W designs for modulators, transmitters, antennas, and so forth.  Sometimes
this has avoided big problems later in the project.  (Sometimes not.)

If you write code which only reflects the design (not the processing) of the
software, I think you are mainly designing your data structures.  This
seems [somewhat] useful.  If you know enough to proceed directly to code, 
fine.  I guess this depends on the scope of the project.

I have been offered PDL processing
tools which expect specific types of descriptive header information, and
turn it into structural and data-flow diagrams.  I don't know if these
tools are any good.  We had gotten our code almost done, so we elected to
produce the [contractually required] design description from the headers
and comments already in our code.  I won't argue this was ideal; only that
each tool has an appropriate time of application.  If you use it at the
wrong time, it won't be as useful as at the right time.

>>  What I want to know is this:  How SPECIFICALLY does this differ from just
>>  jumping straight into the coding?

I hope I gave an answer to that.

>>  I really wonder about this: I don't know
>>  how to be certain in such a case that a real formal DESIGN was done, and
>>  failure to do the DESIGN properly has killed or maimed a lot of projects.

I think it becomes essential when multiple programmers, or
joint hardware and software tasks must be coordinated.

I don't have any war stories but my own, and since I generally design first,
they are all glorious victories. [;->)

What experience have others had with CASE tools that proceed from specific
type of design descriptions?  Have they helped? hindered?

Thanks. --jmm--

-- 
John M. Mills, SRE; Georgia Tech/GTRI/TSDL, Atlanta, GA 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59
Internet: jm59@prism.gatech.edu
 ... Not so fast -- I'm still thinking.