Programmer's ROM - The Computer Language Library/programmersrom.iso/ada/message/gmhftr.doc

Text File | 1988-05-03 | 25.7 KB | 485 lines

,type 106
type 86 86 86 86
,end
                                                       73503-85U/P7046
                                                        15 April 1985



                       FINAL TECHNICAL REPORT

1.0 INTRODUCTION

    This report has been prepared under contract #N66001-84-C-0425
by Veda Incorporated to meet the requirements of paragraph C.4.5.2 of
the Statement of Work.

    The purpose of this report is to "...summarize experiences in Ada
software engineering with emphasis on ways to streamline the
documentation process to support distributed software engineering in
a network culture". In addition, recommendations for new documentation
methods, standards, and supporting tools were solicited.

    In Section 2 we describe and summarize our experiences with using
Ada, in the context of the Telesoft compiler, version 2.1. We speak
from the position of software engineers fairly knowledgeable about Ada
but with little real hands-on experience in its use as a HOL in
significant applications. We feel that our experiences should be of
interest to others who are about to begin their first complicated
software development in Ada.

    In Section 3 we offer our recommendations for future activities,
methods, etc to the Ada community. We see several steps that DOD might
take, both to support the goal of more efficient software development,
and to encourage the voluntary use of Ada.

2.0 LESSONS LEARNED.

    It is probably worthwhile to describe the project team. It consisted
of three software engineers. The project manager has a PhD in
mathematics,fifteen years of experience in software development and
engineering, and has been studying Ada, using it as a PDL, going to
symposia, etc since 1979. He was the designer for the earlier versions
of the editor products. The second member of the team is a computer
science major with two years experience. He has been reading about Ada
since college, and has production-level experience (high fluency) with
both Pascal and PL/I. He was also involved with the last two editor
products. The final team member is an engineer with five years of
software engineering experience, mostly on embedded systems. He has
used Ada as a PDL and has attended tutorials.

    We can segment our experiences into three groups: those elements
which are primarily application dependent; those which are descriptive
of Ada as a software engineering asset; and those which relate to
the specific Ada environment in which this project was conducted.

2.1 Application Specific Experiences.

    The output of this effort is a formatted message handling system,
and a generic message editor definition. The validity of these products
is demonstrated by two instances of the generic, one for RAINFORM
messages and one for UNITREP messages. The reader may wish to refer to
the Generic Message Handling Facility (GMHF) Functional Description (FD)
for further details.

   The primary aspect of GMHF which is of interest is its use of an
extremely sophisticated generic definition. Other aspects include the
use of generics and predefined Ada packages for user input, the use of
command (function) keys on top of the standard Ada I/O routines, and the
use of a terminal definition which supports portability.

   Recall that the purpose of this contract is to generate viable
applications in Ada from existing products developed in other languages.
Therefore, it is relevant to address our thoughts on rehosting into Ada.
In any rehost, whether between languages or between computers, there is
always some element of redesign. This may be a requirement of the new
environment, it may be done to fix outstanding problems, or it may just
be that the rehosters want to fiddle with and (hopefully) improve things
a bit.

    In rehosting from a simple language to a complex one, the optimal
strategy is to find the proper balance between using the existing
strengths of the software (i.e. not making a lot of changes) and using
the strengths of the new language (i.e. redesigning to take advantage of
the new language features). We found it easy to find a good balance
in those areas of most maturity in the existing software. Since we were
essentially turning version 3 of a FORTRAN product into version 4 in
Ada, most of the components had a stable proven design, and were highly
modular in construction. Thus from the bottom up, the job was relatively
easy, and the code generation proceeded rapidly on existing functions.
The impact of Ada was felt mostly at the highest levels of the system.

    From the top down, the structure in which the basic editor lives,
was redesigned to take advantage of Ada's ability to define complex
data types, use linked lists (access), and define generic components.
Over all of this was the ability to logically segment chunks of the
system into packages. The fact that the package structure we delivered
is not that which we started with is indicative of the fact that
packages are useful and can tend to proliferate. We experimented with
group development by developing the specification for the PRINT_PACKAGE
and assigning it to one of the team who could not then discuss it with
the others. Not only did it work well, but it convinced us to make some
changes in the way we assign tasks in our FORTRAN development efforts.

    The generic editor definition was by far the largest new item. It
embodies most typical formatted message editor functions, but allows
an implementor to define a message standard and some related items
and instantiate a new version of the editor for that type. This can
be a simple process or a complex one depending on the complexity and
size of the message standard and the number of existing implementation
specific tools which can be reused. We found that in doing our second
instantiation, we could borrow much from our first. In particular, an
implementor may find useful several utilities which support the
instantiation process and which have been delivered. The use of generics
in this application may be close to the edge of the current envelope.

    Standard message lines typically have fields whose content is
strictly limited. These are called 'fixed fields'. An example is
a month field whose contents must be one of the strings "JAN" ...
"DEC". Ada supports these field types beautifully through user
defined enumerated types. Then the built-in (TEXT_IO.ENUMERATION_IO or
the value clause) facilities may be used and substantial software
development avoided. Also, it makes the validation process much simpler,
as only the type definition must be 'proof-read' and an instance of the
generic tested. This is as opposed to 'by-hand' testing of input
routines for each field type. The only negative here is that the items
of an enumerated type must either take the form of an Ada identifier or
be a character literal. It often happens, however, that a fixed field
might have an entry which: a) begins with a digit, or b) contains
characters other than just letters, digits, and underscores, or c) is
an Ada reserved word. In any of these cases, work-arounds must be used.
While the work-arounds are easy to manage, they are kludges and Ada
should minimize the requirement to kludge.



2.2 General Experiences using Ada as a HOL.

    We found the built-in generics to be extremely useful, and found
ourselves genericizing elements throughout the development process.
The only negative aspects of generics we encountered are discussed in
paragraph 2.3 below. Other built-in features which proved extremely
worthwhile are the attributes associated with various constructs; for
example the pos, value, and image attributes. These allow the programmer
powerful tools to access the aspects of a type or object.

    Packaging is probably that aspect of Ada that is most important,
at least within our experience on this effort. Properly done, packages
support compartmentalized development by allowing agreement on specs
as a contract between components. This requires that package specs
must be VERY CAREFULLY defined. We found that by keeping the
declarations in any spec to a minimum, and defining other entities in
the body, confusion between programmers was minimized.

    At the same time that the specifications are designed, care should
be taken to minimize the number of packages which must be linked using
a 'with' clause. The more packages that are linked to the specification
of any given package, the higher the probability that the given package
will have to be recompiled due to a recompilation of one of the 'withed'
packages. Such unnecessary recompilations chain together and can be
extremely time consuming.

    Packages also support debugging by allowing the tester to localize
problems. Here, exceptions are very useful, as a production tool
certainly, but as debugging tools as well. We found that if one avoided
the others clause during development/debugging, it illuminated the whole
process, while when we used the "when others =>" in an exception handler
it tended to obscure exactly what/where the exception was occurring.

    Separate compilation of package specs and bodies is not available
in some of the "almost-Ada" subsets we've seen. For a fairly large
application, this is a crucial feature. It allows the developer to
separate, in his mind, the 'what' from the 'how'. That separation is
extremely important. As future software development requirements
continue to outstrip capability, more and more code will be developed
by relatively inexperienced personnel - a fact of life. Junior
programmers usually have a great deal of difficulty in separating
what has to be done, and how one might choose to do it. Separate
compilation of specs and bodies helps (forces) them to keep this in
mind. It keeps implementation decisions from insiduously creeping
throughout a system. Furthermore, if something does get implemented
poorly, it minimizes the cost and risk in fixing it. (We at Veda are
all outstanding software engineers, but we can extrapolate ...)

    While trying to avoid twenty pages of motherhood on how great
Ada is, I do feel compelled to mention the importance of user
defined data types in applications such as ours. For many real-time
types of applications, they may not have much impact, but for message
handlers, and other C3 applications they are crucial. In no other
language can one RATIONALLY define the data types being used, and
ensure (redefines) that apples are not inadvertently mixed with oranges.
In an area where the structure and validity of the data are of utmost
importance, only Ada supports data definition adequately. Those
familiar with highly classified message types can appreciate the impact
of the features mentioned above, and the definition of private types,
on software development and ADP security. In this connection, users must
get in the habit of using Ada's data typing facilities. It is easy to
regress into using obscurely named or ill-defined data elements for
"quick-and-dirties" or for "debugging-only". In the long run, it appears
to us to be much more time effective to think out and clearly name all
data elements, even those which may be expected to have a short
"half-life".


2.3 Ada in the Telesoft/VAX environment.

    There are two ways to deal with this subject. One way would be a
diatribe against Telesoft listing every problem and detailing how much
it cost us in time and design coherency. We choose rather to try to
be a little more general, and focus on the kind of environmental
parameters which can cause problems.

    The first, and most general, comment is that the LRM defines a
language with great specificity. It leads designers to believe that
they can design to it. However, one can only design to an implementation
which may or may not meet all of the specification. Areas where a
specific implementation are lacking must be fully defined, even to the
extent of raising questions about areas that are thought to be ok but
might not be. It is extremely frustrating to base a design on some
feature(s) of the language and find that that feature is not yet
implemented. The way to avoid these frustrations is to be sure you
have detailed information on the state of the implementation to be used,
and to carefully and completely assess the impact of any implementation
deficiencies prior to beginning any serious design work.

    The second thought is that one does not ask an auto manufacturer
to build cars without a sophisticated set of tools. In the same sense,
one must not ask software engineers to build complicated pieces of
software without adequate tools. We have all been impatient to get our
hands on Ada. There is a real risk that if those who are less than
enthusiastic about the language (and possibly the concept) are faced
with a first foray into Ada with compilers which are abysmally slow and
which have numerous documented (and undocumented?) bugs, they will
become active antagonists, rather than enthusiastic supporters and
users.

   The specific problems which caused us the most grief are listed
below. Others who are just beginning a development might take heed.

    * Slow compilation speed.

    * Requires too much time to link

    * Limitation on size of .COD segments (require kludges)

    * Lack of nested generics (caused major redesign)

    * Lack of incomplete type definitions within generics (ditto)

    * Lack of separate compilation for generic subunits
                                                    (severe time impact)

    * Bugs in ENUMERATION_IO and VALUE clause (require kludges)

    * Too many "too many jumps" (require kludges)

    * Various library bugs


2.4 Productivity in Ada.

    We did not perform a controlled, scientific study on programmer
productivity; the end result of this effort was to be code. However,
our experience with Ada produced such striking results that we feel
that they are worthy of documentation, even if informally.

    A major concern with Ada has been the amount of "up-to-speed" time
required. Our ability to complete the effort within the calendar time
frame allowed was of some concern due to this requirement for knowledge
assimilation and integration. In fact, we found the time required to
become proficient in Ada was much less than we would have expected, even
given the fact that the project team consisted of experienced software
engineers. Each of the team was developing code efficiently within 2-3
weeks of his first compile.

    There are (at least) two relevant measures of programmer
productivity: lines of code generated per day, and the number of lines
of code generatable automatically for future applications. The GMHF team
generated over 5 Ada statements per man hour. That does not include the
over 7000 comment lines also written. During those man hours,
significant design work was accomplished (this was not as simple a
rehost as some others) and well over 1000 lines of documentation
written. We feel that this is amazing, especially considering that none
of the team had any previous production-level coding experience with
Ada, and that none had ever seen the Telesoft compiler until two months
after contract inception.

    The second parameter is less usual than statements per hour, but
just as, if not more, important. The central element of this application
was the generic definition of message types and message editors. As
mentioned above, we developed the structure, instantiated the Rainform
editor, and then instantiated the Unitrep editor. Furthermore, the team
member who instantiated the Unitrep editor had not been involved with
the development of the generic definition or with the editor portion of
the system. (He had developed the Print Package). He completely
instantiated the Unitrep editor in approximately 60 man hours. This
resulted in over 1100 "executable" statements and approximately 1600
data definition statements. About 900 of the data definition statements
were gotten from SAIC (another example of reuse of Ada code). Even if
these are not counted, the statements per hour figure ends up at over
30. The programmer involved feels that he could easily instantiate
another message type of complexity similar to Unitrep in half the time
it took him to do Unitrep. Thus not only has Ada code generation proved
much more efficient than anyone had hoped, but code reusability can
substantially improve efficiency in ways impossible in any language
but Ada.


3.0 RECOMMENDATIONS.

    There are two groups of recommendations offered below. First, and
perhaps most important, we offer some general recommendations for future
development of Ada tools and facilities, and in one case for the
evolution of the language itself. The second group of recommendations
are GMHF specific, and are only of interest to potential GMHF users, and
to those with some interest in the areas of applied research that GMHF
represents.

3.1 General Recommendations.

    At some point in the future, the Ada specification will be thawed -
unfrozen at least to some extent, or there will be a "follow-on" next
version of a language for embedded applications. Our application dealt
primarily with data structures, and particularly with enumerated types.
We would strongly recommend that when input is being gathered as to what
improvements might be made in the language itself, consideration be
given to specifying that an enumerated type be able to have as an
element any string comprised of characters in the standard character
set.

    Our remaining recommendations concern support tools and structures.
We recognize that activity is already on-going in several areas which we
mention below. We wish to take this opportunity to state for the record
our support of such activities in the hope that the government will
continue to sponsor the development of integrated environments which
will significantly promote programmer efficiency.

    * Large scale APSEs are desperately needed. They should include
      those elements specifically mentioned in Stoneman. In addition,
      we need to make a wide variety of special purpose tools available.
      Examples include:

         a) a routine which determines compilation order dependencies
            between a large number of packages

         b) a scope evaluator which would create a comment block at the
            beginning of a package defining the types, variables, and
            procedures made available by the various 'with' clauses.

         c) a pretty printer to generate code in the format discussed
            in the next bullet

    * There should exist, as a MIL-SPEC an Ada programming style guide
      providing requirements for indentation, comment placement, banner
      style, naming conventions, and so on. Pretty printers should be
      available which reformat source files into the SPEC format, and
      a validator should be available to determine whether a source
      file does in fact meet the SPEC.

    * While the idea has some legal ramifications, we would like to see
      some sort of institutional, independent baseline parameter
      measurements for Ada implementations. Certainly DOD might be in a
      position to issue descriptions of compilers and tools which are
      validated for use in DOD applications. Such data could include a
      profile of measures of performance (MOPs) in each of a number of
      critical areas.

    * An Ada library should be aggressively implemented. It should be
      well publicized and easy to use. Access to it should be part and
      parcel to every Ada-related development contract. (e.g. a first
      deliverable, informal 30 DAC wherein the contractor describes the
      results of his library search to find elements of use in the
      subject development - kind of a hard-ass approach, but at first,
      it might be what it takes)


3.2 GMHF Specific Recommendations.

    The GMHF is complete and useable as is. However, it can certainly be
improved. There are three areas in which continued work should be done.
First, the kludges required by the state of the Telesoft compiler should
be removed. Second, the user entry of data during message construction
should be improved. Finally, research in the use of more sophisticated
data structures to define message components, and possibly messages
themselves, should be continued.

3.2.1 Clean-up of Existing Code.

    The existing functions should be restructured within the structure
of the original design to improve portability and maintainability. GMHF
has the potential to be widely used, both on its own merits, and as a
point-of-departure for future message handlers. While its existing
structure is well documented, the various kludges described elsewhere
result in inconsistancies and a structure which is not as simple and
straightforward as it should be. The cost of the current less than
optimal structure to future implementors is difficult to estimate, but
is certainly non-trivial. The time required to come up to speed is
increased, the time required to make modifications is increased, and the
risk of injecting errors is increased. These negative factors can be
minimized by putting the code in a more logical architecture. Also, it
is difficult and somewhat unrealistic to measure parameters of any
system when that system's implementation has been negatively impacted
by environmental factors. As Ada comes into more general use, the
generation of baselines and the measurement of performance will be ever
more important.

    We suggest that design compromises described here and in the Users/
Implementors Manual be remedied. The original architecture should be
implementable on compilers now available. One assumes that these
compilers would not themselves require other kludges, but that would
depend on the particular compiler made available. Specific change areas
suggested include reducing the number of packages and increasing the
scope of the generic definition. These changes are covered in more
detail in the Users Manual.

3.2.2 Enhanced User Data Entry.

     The existing system validates all user data entry through the use
of Ada data definitions and built-in validation features. However, the
user is required to enter the data, character at a time. For freeform
fields, there is no alternative, but most fields in message standards
at which GMHF is targeted are defined to contain one of several specific
data entries. To facilitate data entry for such fields, we suggest that
two additional approaches be integrated into GMHF. Implementors would
then be able to define a field to have its data entered in any of the
three ways.

     The two suggested additional methods of data entry are list fields
and abbreviated entry. There are cases in which either has advantages.
A list field is a screen area in which one of the allowable data choices
for a particular field is displayed. When the field is active, the
up/down arrows allow the user to scroll legal choices through the field.
When the desired choice is displayed in the field, the user simply moves
on to the next field. On most terminals, this type of data entry is
completed entirely through the use of the arrow keys. It is extremely
popular with users when the number of allowable choices is fairly small,
say 10 or less items.

     When the number of list items is large, the method of abbreviated
data entry is preferable. Using this method, the user need enter only
enough characters to uniquely identify the desired data item. This
might be the entire item, but in practice is usually much less, often
only a single character.

     There are existing implementations of list fields in Fortran, and
we know of an implementation of abbreviated data entry in Ada which can
probably be used to support GMHF enhancement. In integrating these data
entry methods into GMHF, we would also enhance the user prompt handler
to allow the implementor to handle full screen and even multi-screen
prompts.

3.2.3 Message Data Structure Enhancements.

    Part of the purpose of the GMHF development was to gain practical
experience in how well Ada handles complex data structures. This goal
was partially met. A number of complex data structures are defined and
implemented in GMHF, and Ada is found to handle them effectively.
However, we had hoped to go even further than we did, and to define a
message as a single entity. We were not able to implement this due to
the compiler version available early in the effort. By the time a later
version was available which supported the required constructs, our
design was complete and there was not time to step back and redesign
the system. With the initial version of GMHF complete and in use, it
would be of interest to continue research in this area.

    Essentially, what we propose to do is to change the way GMHF
internally handles message data. At present, a message is a linked
list of lines, each line being a string. Data are entered through
the use of data structures, and then converted to strings for storage
using built-in features of the language. We would like to deal with
messages as arrays of lines of variant type. We would then define a
line as an array of fields of variant type. Fields would be defined
to be data elements, similar to the way they are currently defined.
Aside from the obvious advantages of eliminating conversions, this
structure would, we think, facilitate the validation and handling of
messages, as entities, by software which would receive and/or transmit
the message. If we are correct, this would be a significant enhancement.
If we are not, perhaps in finding out why we will uncover alternative
approaches.

    Veda stands ready to continue GMHF research and development should
the government choose to support such an effort.

------