Let's cover this one more time...

Let's cover this one more time...

[CONDIC]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Let's cover this one more time...
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



Fellow Ada Devotees:

I know this question comes up on a regular basis and generally
gets the contempt it deserves. However, I feel morally obliged to
ask it, because my boss was pretty insistent and in our present
climate of "rightsizing" and "outsourcing" I thought it best to
be viewed as cooperative.

    "Does anybody know of any automatic tools for translating
    Crappy Fortran code into even Crappier Ada code?"

We have a jet engine simulation that is very large and very old
and someone up the heap is looking for an economical way of
moving it from Fortran to Ada to be more compatible with our
engine control software.

To make it more interesting, how about thinking up instead, good
reasons why programmer performed module by module Adatran
translation is better than anything done by machine translation.
And then, go think up even better reasons why an ancient engine
simulation would be best reengineered into *real* Ada. Then go
one step further and give reasons why an engine simulation ought
to be engineered from the ground up with OOProgramming techniques
using Ada 9x.

You get extra points for lucid letters, putting a PhD after your
name or citing real or imaginary government studies. Bonus points
will be given for Creative Credibility or anything else that
helps me persuade the Senior Bozos that the real right thing to
do is rewrite the simulation in 9x.

Reply here to the INFO-Ada listserver or send it directly to me
at:
        CONDICMA@PWFL.COM

Thanks for your moral support...

Pax,
Marin


Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
    "'Shut up,' he explained."

        --  Ring Lardner
===============================================================================

Re: Let's cover this one more time...

[Nick Sizemore]

    In response to:

    > Date:    Wed, 16 Nov 1994 15:35:40 EST
    > From:    CONDIC@PSAVAX.PWFL.COM
    >          Marin David Condic, 407.796.8997, M/S 731-93
    > Subject: Let's cover this one more time...

         I am aware of reverse engineering/conversion tools from:

    Scandura          - PRODOC re/Nu FORTRAN-Ada WorkBench
    Reasoning Systems - REFINE/<lang> series
    McCabe Associates - (don't recall tool name).

         There are others, but these are some I have seen in various
    literature sources for several years, so I assume they have had some
    commercial success.  I have not used these but have aquired literature
    for others in my organization.

         Is there some reason, either in priciple or in practice, why such
    tools (as opposed to the line by line 'converters') are out of the
    question for the project described?  I do know of at least one company
    locally which used the McCabe tools to re-engineer an Ada system
    (i.e., no conversion) and was pleased with the results.  Just asking -
    I have no vested interest.

   +------------------------------+---------------------------------+
   |N. L. Sizemore                | (602) 538-4883 [Voice]          |
   |Computer Sciences Corporation | (602) 538-4933 [FAX]            |
   |P.  O. Box 719                | sizemore@huachuca-emh17.army.mil|
   |Ft. Huachuca, AZ  85613-0719  |                                 |
   +----------------------------------------------------------------+
   |    "For aggregate success, members must be the same to the     |
   |    system and different to the environment."                   |
   |                                                                |
   |    Second Aggregate Law        in General Principles of        |
   |                                System Design                   |
   |                                Gerald & Daniela Weinberg       |
   +----------------------------------------------------------------+

Re: Let's cover this one more time...

[Charles Stump]

In article A04713@huachuca-emh17.army.mil, Nick Sizemore <sizemore@HUACHUCA-EMH17.ARMY.MIL> () writes:
>    In response to:
>
>    > Date:    Wed, 16 Nov 1994 15:35:40 EST
>    > From:    CONDIC@PSAVAX.PWFL.COM
>    >          Marin David Condic, 407.796.8997, M/S 731-93
>    > Subject: Let's cover this one more time...
>
>         I am aware of reverse engineering/conversion tools from:
>
>    Scandura          - PRODOC re/Nu FORTRAN-Ada WorkBench
>    Reasoning Systems - REFINE/<lang> series
>    McCabe Associates - (don't recall tool name).
>
>         There are others, but these are some I have seen in various
>    literature sources for several years, so I assume they have had some
>    commercial success.  I have not used these but have aquired literature
>    for others in my organization.
>
>         Is there some reason, either in priciple or in practice, why such
>    tools (as opposed to the line by line 'converters') are out of the
>    question for the project described?  I do know of at least one company
>    locally which used the McCabe tools to re-engineer an Ada system
>    (i.e., no conversion) and was pleased with the results.  Just asking -
>    I have no vested interest.

For starters, line-by-line translation is usually a bad answer. You end
up with an unmaintainable, unreadable Ada system that looks just like
the original. That is, your Ada code will look like FORTRAN or Jovial or
whatever. 

Using something like REFINE/Ada (mentioned above), very good translation
and porting environments can be built. A good soultion is to have a 
flexible, extensible translation environment that is tailored to
each translation task. This type of tool can take advantage of info.
like documentation, design knowlege, developer's input, coding standards,
 etc. in order to help do a better job of translation.

With this type of tool, you can do "intelligent" translation. Lets take 
FORTRAN for example. You reverse engineer the FORTRAN and analyze its
semantics. FORTRAN is a flat langauge. No nesting. Line-by-line translation
usually yields Ada that is flat. That is, VERY bad Ada. What should be 
done is for the tools to examine the FORTRAN and nest units and data
based on their usage in the system. In this way, globals (COMMONS) and
units can be placed at the correct level and good encapsulation and
data hiding enforced in the generated Ada code. 

Another example of things that a translation tool should fix are
parallel arrays. Standard FORTRAN does not have records. A common 
practice is to use multiple arrays and a special varialbe that 
indexes all the arrays. In this way, each array is used like a field
in a record. This activity should be identified by a tool and correctly 
translated into records in the traget language.

Another very usefull capability is a tool to allow Ada packages to be 
generated. Many older systems contain utilities and i/o functions that
are not of much concern during the translation. These units should be 
tagged in some way that they become Ada packages which are withed by 
those units that use them.

Basically, language translation is not easy. Any one who says it is 
wrong. Run away from them very quickly! At this time, good language
translation is, in my opinion, not totally automateable. The majority of
it is. The "trick" is to have sufficient tool and process support to 
allow the non-automateable parts to be accomplished without destroying 
the project.

---
======================================================================
= Charles W. Stump II,   Sr. Software Engineer,   cstump@levtech.com =
======================================================================
= Leverage Technologists, Inc.	=	Reverse Engineering,         =
= P.O. Box 4638			=	Reengineering,               =
= Rockville, MD			=	Maintenance, and             =
= 20849-4638			=	Quality Assurance            =
= (301)309-8783			=	tools and services.          =
= http://stout.levtech.com/	=	                             =
======================================================================

Re: Let's cover this one more time...

[CONDIC]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: Let's cover this one more time...
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



Nick Sizemore <sizemore@HUACHUCA-EMH17.ARMY.MIL> writes:
>         Is there some reason, either in priciple or in practice, why such
>    tools (as opposed to the line by line 'converters') are out of the
>    question for the project described?  I do know of at least one company
>    locally which used the McCabe tools to re-engineer an Ada system
>    (i.e., no conversion) and was pleased with the results.  Just asking -
>    I have no vested interest.
>
It's more of a personal bias - I don't believe that an automated
translation of "legacy" code from *any* language to *any other*
language is ever going to be done well. By this, I mean you will
end up with code that is not very intelligible or will use obscure
language constructs to insure correct translation and in general
will be more difficult to work with than the original system.
(Ever wonder why people generally don't want to mess with the
assembler output of a compiler?)

Throw on top of it that we are talking about a fairly old and
really large body of FORTRAN code to be translated. Sight unseen,
most of us would out-of-hand admit that we can do a better job of
"engineering" a system today than was originally done back in the
mid-70's. Sight seen - I can asure you this is the case.

I'd prefer to make the case that it would be more cost effective
(say, over five years) to reengineer the system from the ground
up than it would be to auto-translate it and spend forever
patching the code until it works.

Pax,
Marin


Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
    "Paranoia is just a kind of awareness, and awareness is just a
    form of love."

        --  Charles Manson
===============================================================================

Re: Let's cover this one more time...

[Michael J. Meier]

: Marin David Condic (CONDICMA@PWFL.COM) writes:

: It's more of a personal bias - I don't believe that an automated
: translation of "legacy" code from *any* language to *any other*
: language is ever going to be done well. By this, I mean you will
: end up with code that is not very intelligible or will use obscure
: language constructs to insure correct translation and in general
: will be more difficult to work with than the original system.
: (Ever wonder why people generally don't want to mess with the
: assembler output of a compiler?)

: Throw on top of it that we are talking about a fairly old and
: really large body of FORTRAN code to be translated. Sight unseen,
: most of us would out-of-hand admit that we can do a better job of
: "engineering" a system today than was originally done back in the
: mid-70's. Sight seen - I can asure you this is the case.

: I'd prefer to make the case that it would be more cost effective
: (say, over five years) to reengineer the system from the ground
: up than it would be to auto-translate it and spend forever
: patching the code until it works.

I had a similar experience with some ancient FORTRAN code a few years back
when I was working on a C program.  Of course, we wanted to convert to C
instead of Ada, but the principle's the same.  We found it beneficial to
first apply a Fortran de-spaghetti-fier (or something like that) to turn the
awful Fortran code into somewhat structured Fortran code.  This at least
made the code a bit more understandable.  We were then able to figure out
the code and make the manual conversion with some confidence that the result
would be close to the original.  We chose this approach despite the fact that
line-by-line Fortran-to-C converters exist for the same reasons that you seem
to be expressing: understandability -> long-term cost effectiveness!

I believe that several companies offer a Fortran de-spaghetti-fier, but the
one that springs to mind had a name something like "Cobalt 4".

Mike Meier
meier@magec.com