Re: APSE Trends

[alden%jade@spp1.UUCP]

Ed,

Two of the issues that you are wondering about with respect to their
importance that I consider important are those dealing with
DIANA and the KAPSE.  (You have the CAIS listed separate from a KAPSE, 
I remind you that the CAIS is just one instance of a KAPSE, and happens to 
be a proposed MIL STD.).

The issue of DIANA can be generically placed in the category of the issue
of a standard or common internal representation for ada code.  Whetherer the
representatio is DIANA or some other future standard, I think the issue is
a good one becuase it allows for the possibility of developing small, very
specfic tools that work from a common database or preparsed code.  For 
the large kinds of systems that Ada development is suposed to address it 
self to, it would be impossible from an throughput point of view to
to have to compile code once to produce code and once for each tool 
to be used by the developer.  It only makes sense that if there are
to be a host of tools that need to parse Ada code before they can
do their job, that this only be done once.  Given the current speeds of
compilation, a trend to reduce this overhead is welcome.

With respect to the KAPSE.  First my credentials (for what they are
worth).  I am one of the members of the TRW team developing a CAIS prototype
under contract to NOSC.  The stated value of a KAPSE is that if tools
are written to conform to the KAPSE for all so called  O.S. dependencies,
then when it comes time to rehost the toolset to a new machine, the tools
will be transportable with no (or at least minimal) rework.  This is 
because the KAPSE would be ported and absorb all of the work.  For large
toolsets, the expense of porting an entire tool suite is likely to 
be more than porting the KAPSE.  Remember that you must include the
cost of testing each tool when you change its code.  Thus added to
the cost of tweaking code for each tool, you must add the cost of
completely testing the tool.  If you are porting just the KAPSE, it
it is likely that the complexity of testing is lower because you have only
one program to test.  One unanswered question that still remains is 
how costly will it be to report the KAPSE.  This of course depends on
what functions are in the KAPSE.  Experience with UNIX ports (Unix is
considered by many as an example of a KAPSE) shows that ports to 
new machines are extremely cost effective.  Why Unix is not viable
for an Ada KAPSE is another issue, not to be dealt with here.

Not mentioned yet is the cost of developing small new tools.  If 
you have to reinvent the parsing wheel each time you need a tool that
has to run through Ada code, it is likely that it will not be cost
effective to develop useful small tools - the overhead of such development
would be to high.  Having this aspect standardized reduces the overhead
of maintenance and development because the develpment community only
has to learn one set of such routines and not a new set for each
toolset that it needs to modify.

The underlying theme that ties both of the above issues together (issue
of DIANA and issue of a KAPSE) is that of centralization and standardization.
Both of these approaches rely on the idea that if you have a standard for
internal representations of Ada code that all tools agree on and have
a central place to put this with standard interfaces to work with this
repository then tools can be integrated in such a way that their sum power
is greater than the additive power of the individual tools. This synergy 
is what I hope will make the whole effort worth while.

	... Tony Alden
	    TRW
	    (213) 535-1624

P.S.

The above comments apply to my personal and academic views on the subjects 
discussed and in no way reflect the official views of TRW or any
obligations TRW has to fulfilment of its contractural obligations.