"Density" of Ada 95 vs. Ada 83

"Density" of Ada 95 vs. Ada 83

[Ken Garlington]

We are using the PRICE-S software cost estimating model for a project 
where we intend to use Ada 95. We input some source-lines-of-code size 
estimates based on existing Ada 83 work. PRICE-S generated cost 
estimates for the new project which were higher than we expected.

Apparently, PRICE-S assumes that the average Ada 95 application will be 
"denser" than an Ada 83 application of equivalent functionality. That 
is, it should take fewer lines of Ada 95 code to express the same 
algorithms, data structures, etc. (on the average).

Does anyone have some good quantitative information on whether Ada 95 is 
"denser" than Ada 83 for a given domain, and it so, how much "denser" on 
average? For that matter, does anyone have any qualitative analysis on 
this issue? We are trying to decide how we should handle the PRICE-S 
factors in our planning, so anything that would confirm or refute the 
PRICE-S view of Ada 95 would be appreciated.

This information might be available on one of the web servers, but I 
haven't had time to do a search. Any pointers to such information would 
be appreciated.

-- 
LMTAS - "Our Brand Means Quality"

Re: "Density" of Ada 95 vs. Ada 83

[Michael F Brenner]

> ...it should take fewer lines of Ada 95 code to express the same
> algorithms, data structures, etc. (on the average).
>
> Does anyone have some good quantitative information on whether Ada 95 is
> "denser" than Ada 83 for a given domain, and it so, how much "denser" on
> average?

Without discussing the new object oriented, CORBA, remote procedure calls,
Posix compatibility, C language parameter compatibility, and built-in
libraries, which make many Ada-83 programs replaceable by a tiny Ada-95
procedure, there is one feature of Ada-95 which has a measurable effect
on lowering lines of code. That feature is MOD types. In Ada-83 many
type conversions, procedure calls, libraries of functions, and 
unchecked_conversions were required to do AND, OR, UNSIGNED_ADD, and
the other features that systems programmers and signal processor
programmers need in all their integers. These operations are now
built in to the Ada-95 MOD type, eliminating libraries
of functionalities, reducing all methods to the built-in functions "+",
"*", "AND", etc., except one. The one operation that is missing is
checked conversion between 32-bit signed and 32-bit unsigned numbers;
to do this in Ada-95 requires an unchecked_conversion, unlike Ada-83,
which permitted the user to implement unsigned numbers (without literals)
by using a single signed type with two sets of operators (signed
operators and unsigned operators). 

I recently downloaded EMCC from the net for use in HYTLIST, and converted
it to Ada-95. I made the minimal changes necessary, and measured them in
both function points and source code bytes (I did not measure them in 
less meaningful lines of code). The source code (when pkzipped) took up a
1.4 megabyte floppy, overflowing to a second floppy containing 26071 bytes.
After conversion to Ada-95 it fit on the 1.4 megabyte floppy (just barely).
This slight reduction was despite having to double the  generic packages, 
so they work both on signed and unsigned types in Ada-95. Just use a text
editor and copy-paste each one, and put the word MOD in the second copy. 
However, Ada-95 libraries, mod types, and built-in interfaces (no tagged 
types or protected records were used in this conversion) resulted in lines of 
code savings equal to the doubled generics, and an additional 2 percent
savings.

I estimate that by using tagged types, the EMCC packages would save 
about another 5 percent, because there is a lot of code that switches
device drivers through complicated levels of packages, case statements,
and alternate package bodies for the command language to compile in
to the same visible part to get the same effect on different output 
devices. This kind of code is a prime candidate for a tagged type, and
will become not only smaller, but much easier to modify, expand, and 
configure when adapted to the Ada-95 paradigms instead of just a minimal
conversion. Contradictingly, it will actually run faster also, despite
the run-time dispatching I am proposing to put into it, because the
tricks it now uses to get the effects of run-time dispatching use 
a couple of CPU cycles, even though recompiling package bodies is part
of those tricks. This is contrary to what would be expected with a
program designed with hard realtime embedded techniques, where adding
run-time dispatching would cause cache-voiding jumps and thus make it
run slower. 

The real problem is that so many people base their cost estimates on lines
of code. I once changed a spherical trigonometric equation in a satellite
location program (one line of code), using up approximately 6 months of
effort. How does your estimation model predict something like that?
Also, I can write 5 million lines of code in one minute (time me):

with EMCC;
procedure mike is
  package my_EMCC is new EMCC (integer, integer, integer);
begin
  my_EMCC.go;
end mike;

A second minute to compile, link, and run it. How does your model
handle the fact that the word NEW above automatically programmed
5 million lines of code?

D
D
begin 

Re: "Density" of Ada 95 vs. Ada 83

[Bruce Link]

Michael F Brenner (mfb@mbunix.mitre.org) wrote:
: I made the minimal changes necessary, and measured them in
: both function points and source code bytes (I did not measure them in 
: less meaningful lines of code). 

What tool did you use to measure function points?  All of the tools I am
aware of count lines and use a conversion factor (which is somewhat arbitrary).
I would be quite interested in a tool which will count function pints, as one
of the problems I had with function points (aside from their being primarily
oriented to MIS systems) was that they could only be estimated, even after the
code was written.

Does your tool also measure feature points?

Re the original question, Capers Jones (modern proclaimer of function points)
claims that The average number of statements per function point for some 
popular languages is as follows (see http://www.spr.com/library/langtbl.htm):

Ada 83     71
Ada 95     49
C         128
C++        53

This would imply that Ada 95 should be 31% "denser" than Ada 83, 
62% "denser" than C, and 8% "denser" than C++.  Of course, as always,
your mileage may vary.
-- 
----------------------------------------------------------------------------
Bruce Link                         |Team OS/2
bdl@mda.ca                         |Team Ada

Re: "Density" of Ada 95 vs. Ada 83

[Tucker Taft]

Ken Garlington (garlingtonke@lmtas.lmco.com) wrote:
: We are using the PRICE-S software cost estimating model for a project 
: where we intend to use Ada 95. We input some source-lines-of-code size 
: estimates based on existing Ada 83 work. PRICE-S generated cost 
: estimates for the new project which were higher than we expected.

: Apparently, PRICE-S assumes that the average Ada 95 application will be 
: "denser" than an Ada 83 application of equivalent functionality. That 
: is, it should take fewer lines of Ada 95 code to express the same 
: algorithms, data structures, etc. (on the average).

: Does anyone have some good quantitative information on whether Ada 95 is 
: "denser" than Ada 83 for a given domain, and it so, how much "denser" on 
: average? For that matter, does anyone have any qualitative analysis on 
: this issue? We are trying to decide how we should handle the PRICE-S 
: factors in our planning, so anything that would confirm or refute the 
: PRICE-S view of Ada 95 would be appreciated.

Capers Jones accumulates statistics on lines of code per function
point for hundreds of different languages, which is the inverse of 
density.  Check out his company's web site (unfortunately, I can't
remember the name of his company -- something like Software Research;
probably a Web search for "Capers Jones" would find it).

: This information might be available on one of the web servers, but I 
: haven't had time to do a search. Any pointers to such information would 
: be appreciated.

See above.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: "Density" of Ada 95 vs. Ada 83

[Alan Brain]

Tucker Taft wrote:

> Capers Jones accumulates statistics on lines of code per function
> point for hundreds of different languages, which is the inverse of
> density.  Check out his company's web site (unfortunately, I can't
> remember the name of his company -- something like Software Research;
> probably a Web search for "Capers Jones" would find it).
> 
> : This information might be available on one of the web servers, but I
> : haven't had time to do a search. Any pointers to such information would
> : be appreciated.

It's at:  http://www.spr.com/library/langtbl.htm

HOWEVER.....

The figures for the majority of languages have to be taken with between
one grain and several megatonnes of salt.

Ada-83 is measured directly , as is COBOL, FORTRAN 77 and a few others.
C is measured indirectly, by looking at projects coded in both COBOL and
C, and deriving a fudge factor.

But others are based on looking at the language specifications, then
deciding how similar they are to other languages they have data for. As
the people concerned are intellectually honest, they tell you this early
on. I just wish they'd given the number of LOCs and FPs they'd done the
measurement on, so an estimation of reliability could be guaged.

But at the moment, it's the only game in town. Gaining more data would
be an excellent MS or even PhD thesis.  

----------------------      <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
---------------------- o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling Maerklin Wagons, in 1/220 Scale

Re: "Density" of Ada 95 vs. Ada 83

[Matthew Heaney]

In article <Dy3DnK.GAE.0.-s@inmet.camb.inmet.com>,
stt@houdini.camb.inmet.com (Tucker Taft) wrote:

>Capers Jones accumulates statistics on lines of code per function
>point for hundreds of different languages, which is the inverse of 
>density.  Check out his company's web site (unfortunately, I can't
>remember the name of his company -- something like Software Research;
>probably a Web search for "Capers Jones" would find it).

The name of Jones' company is Software Productivity Research.  Their home
page is

http://www.spr.com/

and the function points info is at 

http://www.spr.com/library/funcmet.htm

BTW, Jones just released the second edition of his book Applied Software
Measurement.

>-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
>Intermetrics, Inc.  Cambridge, MA  USA

matt
mheaney@ni.net

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271