From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fe2aecddaa6badba X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-11-18 11:54:49 PST Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!pipex!uunet!news1.digex.net!stout!cstump From: cstump@levtech.com (Charles Stump) Newsgroups: comp.lang.ada Subject: Re: Let's cover this one more time... Date: 18 Nov 1994 16:10:00 GMT Organization: Leverage Technologists Inc. Distribution: world Message-ID: <3aijko$95v@news1.digex.net> References: <9411171208.A04713@huachuca-emh17.army.mil> Reply-To: cstump@levtech.com NNTP-Posting-Host: stout.levtech.com Date: 1994-11-18T16:10:00+00:00 List-Id: In article A04713@huachuca-emh17.army.mil, Nick Sizemore () 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/ 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/ = = ======================================================================