EBERARD@USC-ECLB.ARPA (Edward V. Berard) (10/03/85)
I have good news and I have bad news. The good news is that
DOD-STD-2167, the new DoD standard for software development (which
supersedes DOD-STD-1679A (NAVY) and MIL-STD-1644B (TD)), does indeed
address Ada technology. Specifically, in Appendix C of the copy I have
(dated 4 June 1985), the following paragraph appears:
"30.2 Applicability. This appendix contains design and coding standards
generally applicable to all programming languages. However, it does not
provide complete design and coding standards for some higher order
languages with advanced capabilities (e.g., Ada, PROLOG, etc.). In such
cases, the contractor should propose additions to this appendix in
either the the SSPM or SDP (see Appendix D) and obtain contracting
agency approval."
The good news appears to get even better. There is a MIL-HDBK-287, the
"Defense System Software Development Handbook." This handbook is
currently under formal review and will supersede DOD-HDBK-281. The copy
I have is dated 6 September 1985. On page 43 of MIL-HDBK-287, starting
with paragraph 4.4.17, there is a discussion of "Use of Ada with
DOD-STD-2167 and Associated Standards." Among other things, this
paragraph says:
"This language, because of its advanced constructs, needs its own set of
coding standards, as well as an explanation of how it maps to
DOD-STD-2167 terminology. Appendix B provides a general set of coding
standards that can be implemented on all Ada programs. The mapping of
DOD-STD-2167 terminology to Ada is as follows:"
This is followed by four paragraphs which talk about the mapping of Ada
program units to DOD-STD-2167 terminology.
Those of you who have any kind of background in software development
methodologies and Ada, should recognize the above as the beginning of
the bad news. DOD-STD-2167 is oriented almost exclusively towards a
functional decomposition approach to software development. This makes
the use of modern software engineering technology particularly
difficult.
Object oriented approaches (e.g., Object Oriented Design ala Booch or
Love) and modeling approaches (e.g., Jackson System Development) are far
better for Ada software development than functional decomposition. (I
know this is a strong claim, yet I, and others, can back it up with
empirical evidence, if you are interested.) In addition, concepts like
"design a little, code a little" and prototyping have proven useful in
the software development process, yet they do not seem to fit within
the rigid mold cast by DOD-STD-2167. (Yes, I know that clever Ada
software developers can "work around" the restrictions imposed by
DOD-STD-2167, but they should be able make use of sound software
engineering methodologies in a straightforward manner without having to
subvert the intentions of the DoD.)
[It seems inconsistent that the same organization, i.e., the DoD, can
sponsor both DOD-STD-2167 and METHODMAN I & II. The former would have
been an excellent document in the late 1960s, and the latter documents
at least get us to the early 1980s.]
The bad news gets worse. A quick check of Appendix B in MIL-HDBK-287
reveals that the authors have an uneven knowledge of both Ada and
software engineering. Consider the following direct quotes:
"20.6.1.2 Loops without exits (i.e. a loop without a FOR clause, a WHILE
clause, or a nested exit statement) shall be used only in task bodies.
In general, an infinite loop is a programming error. However, in Ada
they do find use in the body of a task that must continue its function
as long as the program is running."
[This is a strange restriction, especially given that Ada is intended to
be used in real-time applications where infinite loops are far more
common than in non-real-time applications. Yes, infinite loops will show
up most commonly, *but not exclusively*, in task bodies.]
"20.10 Tasking. Ada tasking shall be used to implement parallel
processing. Ada provides tasking features to allow parallel processing
to be expressed within the language."
[This statement I find particularly confusing. Does the author mean that
I should not attempt to implement parallel processing using some other
feature of the language?]
"20.10.4" A task shall not call its own entries. This will result in a
deadlock situation."
[I find this admonishment particularly insulting. Do they think that a
professional software engineer would produce code which would attempt
this, and that the testing of the software would be so slipshod as not
to detect such a blatant error?]
There is no mention of generics in Appendix B. Maybe the concept of data
abstraction is foreign to the author(s).
To be fair, there is some sound advice contained in Appendix B of
MIL-HDBK-287. Concepts like information hiding and abstraction are
mentioned and strongly suggested. I agree with many of the coding
suggestions made in the appendix. However, the level of the discussion
in Appendix B indicates that the author(s) has a strong background in
a language other than Ada (possibly Pascal).
Sadly, both DOD-STD-2167 and MIL-HDBK-287 treat Ada as "just another
coding language with some 'advanced capabilities'" which must be mapped
into the FORTRAN mindset.
The bad news gets even worse. It is extremely difficult to introduce new
software technology. Even with DoD Directive 5000.31, it is difficult to
insert Ada technology within an organization. Particularly enlightened
organizations have realized that the language by itself is not enough,
i.e., it must be used in the context of modern software engineering
technology to achieve maximum benefits. Organizations such as Magnavox
and Ford Aerospace have made radical changes in their treatment of the
software life-cycle to accommodate not only the Ada language, but
methodologies like Object Oriented Design. These changes involve a
great deal of time money and effort. These organizations, and others,
have been frustrated when they find that their contracting offices only
think of Ada as a programming language, and in fact *discourage* the use
of modern software engineering.
It is not only the DoD contractors who must be educated in the new
technology. The contracting agencies themselves must be aware of,
appreciate, and *accommodate* modern software engineering technology.
The DoD is to be commended for attempting to bring order out of the
chaos which all too often characterizes software development. However,
the current solution (i.e., DOD-STD-2167) penalizes better solutions in
favor of 1960s style software development methodologies. The solution to
the problem is to develop a software development standard which is
capable of recognizing a variety of superior development methodologies.
-- Ed Berard
[If you are wondering why you haven't heard about MIL-HDBK-287, the list
of reviewers, which includes organizations like EIA, AIA, IEEE, NSIA,
and SSQ, does *not* include ACM, SIGAda, or AdaJUG.]
P.S.: If you are interested in doing something about DOD-STD-2167,
positive or negative, you should contact the newest SIGAda
working group: "DOD-STD-2167 Constraints Upon Ada-Oriented
Methodologies." The point of contact is:
Mr. Donald Firesmith
Magnavox Electronic Systems Company
Advanced Software Systems Department
TC-10-C-3 D519
1313 Production Road
Fort Wayne, IN 46808
(219) 429 - 4327
-------macrakis@HARVARD.HARVARD.EDU (Stavros Macrakis) (10/14/85)
Agreed: Dod needs to do some work in making its software development standards reasonable. Agreed about functional decomposition vs. other approaches. I have never understood the structure of Dod software development standards, but I understand they are trying to incorporate prototyping and the like into at least one of these standards. 20.10 I believe this is intended to keep programmers from using the traditional method of making run-time executive calls. In the olden days (before Ada), real-time tasks typically were scheduled using such calls as call RepetitiveProcess(subroutine_name,time_interval) which would call the subroutine every so often. Note that the subroutine did not have a thread of control from one execution to the next, so all state information had to be kept in global variables. What 20.10 also appears to exclude, incorrectly, is the use of Ada tasks for coroutining (cf. Jackson -- but the technique goes back about 20 years before Jackson). As for Sadly, both DOD-STD-2167 and MIL-HDBK-287 treat Ada as "just another coding language with some 'advanced capabilities'" which must be mapped into the FORTRAN mindset. perhaps they are just being realistic. It is going to take many years of education (more than just training) to get old Fortran/Jovial/CMS-2 programmers into Ada-land. Isn't there some mechanism for commenting on 2167? -s