Re: Ada & PDL (ick !)

Re: Ada & PDL (ick !)

[Jim Lonjers]

In article <NX5FVB2w165w@cruiser.uucp> bdl@cruiser.uucp (Bob Lombard) writes:
>Hi netters:
>
>  A question has arisen at work regarding Ada & PDL.  Some work we
>are currently tasked with requires the use of PDL.  So, we are wondering
>how the rest of the world approaches this, primarily those working on
>DoD projects.  
>
>  If you indeed use PDL, what do you write your PDL in, Ada itself
>  or something else ? (Psuedo-english ?)
>
>  In the dark ages of Fortran there were pre-processors that would
>  xlate PDL into semi-compileable code.  Do similar tools exist for
>  use with Ada ?
>
>  Comments ? Reccomendations ? (Flames to dev.null thanks)

Yes, we use compiled Ada as a PDL on our 2167A projects during preliminary
and detailed design stages.  It works quite well for that purpose.
Although there are some minor drawbacks, I would personally not choose a
different form of PDL.

Jim

Re: Ada & PDL (ick !)

[joh n r strohm]

In article <1992Dec10.113630.3412@gvl.unisys.com>, lonjers@prc.unisys.com (Jim 
Lonjers) writes:

>In article <NX5FVB2w165w@cruiser.uucp> bdl@cruiser.uucp (Bob Lombard) writes:
>>Hi netters:
>>
>>  A question has arisen at work regarding Ada & PDL.  Some work we
>>are currently tasked with requires the use of PDL.  So, we are wondering
>>how the rest of the world approaches this, primarily those working on
>>DoD projects.  
>>
>>  If you indeed use PDL, what do you write your PDL in, Ada itself
>>  or something else ? (Psuedo-english ?)
>>
>>  In the dark ages of Fortran there were pre-processors that would
>>  xlate PDL into semi-compileable code.  Do similar tools exist for
>>  use with Ada ?
>>
>>  Comments ? Reccomendations ? (Flames to dev.null thanks)
>
>Yes, we use compiled Ada as a PDL on our 2167A projects during preliminary
>and detailed design stages.  It works quite well for that purpose.
>Although there are some minor drawbacks, I would personally not choose a
>different form of PDL.
>
>Jim

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.

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

What I want to know is this:  How SPECIFICALLY does this differ from just
jumping straight into the coding?  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.

Re: Ada & PDL (ick !)

[Rex Heck]

In article 24720@mksol.dseg.ti.com, strohm@mksol.dseg.ti.com (john r strohm) wr
ites:


 
>What I want to know is this:  How SPECIFICALLY does this differ from just
>jumping straight into the coding?  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.
>
>From the syntax viewpoint Ada PDL is the same as Ada code. With Ada PDL for th
e
the preliminary design, interfaces are described in Ada package specifications
and stubs are used for the bodies with Ada comments in free form English text
to descirbe the process to be performed in the body. This gives a riegorous 
definition of the interfaces that can be validated with the Ada compiler. As th
e
design is refined, the comments are enahnced by Ada code. When coding is comple
te,
There will be an English description of the process followed by the code that
implements the process.

Advantages => Software engineers only have to learn one syntax, Ada, and not a
              PDL that is only useful for design.
              The code is documented and commented before coding.
              The Ada environment supports the design phase.
              Only one environtment is required.
Disadvantages => Managers and customers have to learn to read Ada.
              The coder may not update design comments if the implementation is
              different (Of course we know he won't update PDL)

I have found Ada PDL is a good design tool when communicating with software
people. When you get to hardware folks and managers, well then nothing works. :
-)

Rex

Re: Ada & PDL (ick !)

[Robert I. Eachus]

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.

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

>  What I want to know is this:  How SPECIFICALLY does this differ from just
>  jumping straight into the coding?  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'll take a shot at this...  COBOL many years ago tried to divide
the code from other parts of a program.  In some areas it succeeded
better than in others, but it did not try to split out design.  In Ada
the main division of compilation units in a project is into
specifications and bodies.  Detailed design is 90% concerned with the
package specificatations.  Coding is 90% concerned with package bodies
and subunits.  With a little bit of effort it is possible to have a
complete compilable design in Ada without writing a line of what would
be considered executable code in other languages.

     But...the problem that you mention does exist.  It is hard to
have a hard and fast rule as to what is design and what is coding, and
use this to keep people from riding off the deep end.  My attitude has
been that it is better to depend on good faith efforts by the
programming staff.  If their goals are yours, the project will
succeed, if they consistantly try to subvert the project, no standards
or rules will help.  The only case where you have to use judgement
with Ada is in determining when a "superprogrammer" is creating more
work than he is accomplishing, rather than flat out telling him to
stop coding or get off the project.



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada & PDL (ick !)

[Alex Blakemore]

In article <1992Dec10.200346.1406@den.mmc.com> heck@hercules.den.mmc.com writes
:

> I have found Ada PDL is a good design tool

I second that - along with a *few* key pictures (not necessarily bubbles) 

Ada as PDL also supports iterative development, forming contracts between devel
opers
early (based on commented specs). It takes some discipline to resist the urge 
to march right into some interesting routine while leaving the big picture half
 baked,
but thats true with PDL in general.

DEC supports a mode on their compiler (/DESIGN I think) that just does front en
d checking
and relaxes some Ada rules - specifically for supporting PDL.  For example, you
 can
have LSE tokens and placeholders in the file, dont have to bother supplying
private parts and a few other niceties.  This way you can quickly check your de
sign
level specs for consistency without having to fill in all the details to get pa
st
the compiler.  Then just dont use the design compiler option when you're ready 
to
get serious.

One last DEC ad, they were demoing some really great compiler advances at TriAd
a -
smart recompilation so that if you only change one procedure (say) in a package
spec, then only the units that actually reference that procedure have to be rec
ompiled.
all the other units that depend on the revised package are just magically broug
ht up to date.
This could be a real boon to large system development.  They said it would be i
n the
next version. (I know Rational does similar things, but many dont have access o
ne)
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

Re: Ada & PDL (ick !)

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

Re: Ada & PDL (ick !)

[Jim Lonjers]

In article <EACHUS.92Dec10165132@oddjob.mitre.org> eachus@oddjob.mitre.org (Rob
ert I. Eachus) writes:
>
>                            Detailed design is 90% concerned with the
>package specificatations.  Coding is 90% concerned with package bodies
>and subunits.  With a little bit of effort it is possible to have a
>complete compilable design in Ada without writing a line of what would
>be considered executable code in other languages.
>
>     But...the problem that you mention does exist.  It is hard to
>have a hard and fast rule as to what is design and what is coding, and
>use this to keep people from riding off the deep end.  My attitude has
>been that it is better to depend on good faith efforts by the
>programming staff.  If their goals are yours, the project will
>succeed, if they consistantly try to subvert the project, no standards
>or rules will help.  The only case where you have to use judgement
>with Ada is in determining when a "superprogrammer" is creating more
>work than he is accomplishing, rather than flat out telling him to
>stop coding or get off the project.

Bob has stated my views rather accurately.  This "completion criteria"
problem is the same problem that one must consider in the transition from
preliminary to detailed design, and to some extent, in trying to keep
design material out of requirements analysis.  There is no substitute for
good engineering judgement.

Jim Lonjers