Re: Estimating conversion of Ada 83 to Ada 95

["Paul Hussein" <paul.hussein@dial.pipex.com>]

Robert Dewar <robert_dewar@my-deja.com> wrote in message
news:7jk0do$hk$1@nnrp1.deja.com...
> In article <7jj9kr$2hr$1@news2.tor.accglobal.net>,
>   "Terry J. Westley" <twestley@buffalo.veridian.com> wrote:
> >
> > Anyone have any evidence that I'm way off on this estimate?
>
> Based on our extensive experience with people converting from
> VADS Ada 83 to Ada 95, I would say that no estimate like this
> can be even vaguely complete.
>
> It all depends on the quality of the original code. If people
> have been careful to write nicely portable code, your estimate
> is way high (and we have seen people do conversions with a
> productivity of at least ten times this figure, and even higher
> in some cases).
>
I agree whole-heartedly here having ported a real-time distributed sim in 83
to 95.
The problem is not in the porting itself, as this can be executed very
quickly, but in the testing and verification of the completed port.

The approach I took, which I stringly recommend is not to jump in the deep
end, but to gadually port your code. Take a look at all your code and assess
it for portability. Identify all those suspect non-portable units and
declarations and assumptions that are going to cause a problem. ( If found
the best way to do this was to take a small build of the system and compile
it with the new compiler.

Then attemp to fix the portability issues one at a time, and then test that
item with your original compiler until you are satisfied that it works.
Gradually shift your build to a portable build an a port, test, port test
cycle for each nom-portable issue. That way you are moving the build
gradually and in a controlled manner. You may then have a chance of having a
known build at the end of this process.

It does mean that you may not make the best use of all that 95 will give
you. However, if having a stable known build that you can work on under 95
is your goal, then this is the best approach. This principal holds true for
any porting really.


When the code is portable and in a known state,  then you can start
compiling with the 95 compiler to test that. Just that the build compiles in
no way means it will work. The advantage of doing it this way means you have
a fully working 83 build that you can probe and monitor to see what should
happen in your 95 build when you come across inconsistencies.

Most of my time was spent not on the porting itself, but on tracking down
these little inconsistencies.


Also I can recomend that whilst you are going to this effort, why not chuck
in another platform. I found it invaluable to have 2 to 3 platforms to build
the same code on. It gave extra insights into the portability issues that
the same compiler for your platform may mask over. In the end you may end-up
with a platform independant build aswell.

As for estimating, this is always very difficult. The actual mechanical
porting is relatively easy to estimate, but in my experience the problem is
estimating the little niggles that will be left. That is why I advocate
maintaining a portabe 83 build, and then it becomes less of a risk.


N.B. What you may find helpful, as I did initially to get a quick build
going, was to make use of some compatibility Ada packages that SGI produced
to aid in porting from VADS to  SGI GNAT. These reroduces lots of the VADS
packages but in GNAT form. They allowed quick assessment porting, and
insights in how one could replace them with standard Ada 95.


Hope this helps.

Anyone else feel free to comment.


> If on the other hand, the programmers have done a lousy job
> of writing clean portable code, then it may take arbitrarily
> long to do a conversion.
>
> The best thing is to do some sample conversions of small pieces
> of the system, to get a feeling for how well the code is
> written.
>
> Robert Dewar
> Ada Core Technologies
>
> P.S. If you are using GNAT for this conversion, ACT has
> extensive experience in helping with such conversions, and
> this is one area where our support services can definitely
> be very useful.
>
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.