From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,267eec8ad557a7d0 X-Google-Attributes: gid103376,public From: evans@evans.pgh.pa.us (Arthur Evans Jr) Subject: 4GL code in a deliverable (was: ARIANE-5 Failure) Date: 1996/06/18 Message-ID: #1/1 X-Deja-AN: 160826377 references: <834097751.22632.0@assen.demon.co.uk> <4pd540$rl2@Starbase.NeoSoft.COM> <4pd7qc$kp2@dfw-ixnews4.ix.netcom.com> <4pg9gj$ohs@Starbase.NeoSoft.COM> <31C0526C.2D99@lmtas.lmco.com> <31C57C5B.6C63@lmtas.lmco.com> organization: Ada Consulting newsgroups: comp.lang.ada Date: 1996-06-18T00:00:00+00:00 List-Id: In article <31C57C5B.6C63@lmtas.lmco.com>, Ken Garlington wrote: > The current DoD policy, as I recall, says that it is preferable to use > 4GLs where Ada is not possible, although a specific waiver is still > required. However, it doesn't say anything about needing a waiver to > use tools that generate Ada code, including 4GL tools. There is no > distiction drawn between writing (and maintaining) Ada code manually, > and auto-generating Ada code (and maintaining some higher-level > representation of the code). If you can find something specific in > the DoDD or DoDI set that says this, I would like to know. > > If you're saying the Ada policy _should_ be this way, that's fine, but > I find nothing that claims it _is_ this way. Certainly, the > instructions I've received as a contractor do not require a waiver in > these cases, even though our customer knows that we auto-generate Ada > code, and use it as an intermediate language, in some cases. Suggested here and in previous notes in this thread is the idea that a contractor may without obtaining a waiver use a 4GL tool (such as MatrixX) that generates Ada code, and then submit that Ada code as part of its contract deliverable. While this strategy may be legal, in my opinion it circumvents the intent of the Ada mandate and should not be permitted. Why? A major motivation for the Ada design, starting more than 20 years ago, is to reduce the cost of software maintenance. One of the important motivations for the mandate is that code written in Ada with use of proper software engineering provides important ease of maintenance. There is (supposed to be) a clear trail from design to final code, and _all_ _tools_ _that_ _participate_ _in_ _that_ _trail_ are delivered with the product for use by the maintainers. It seems fair to assume that there is a clear trail from design, through system equations, through MatrixX code (or whatever we call it), to Ada, to the final product. My question, then, is this: Are both the source code for the 4GL and the 4GL product itself delivered? There are of course two possibilities: - The 4GL source is not delivered. In that case the maintainer has no recourse in modifying the code except to do so in Ada. I think we'll all agree that this code is essentially unmaintainable, in the sense that it can be modified with the same danger present in modifying aswsembler code produced by a compiler. The maintainer _must_ have access to the 4GL source code and the 4GL tool. - The 4GL code is delivered. But in that case the contractor is admitting (the truth) that the algorithm was expressed in this notation (that is, programmed in it), even though no waiver was obtained permitting use of other than Ada. Now, I fully support using a 4GL such as MatrixX where appropriate to express complex algorithms. My point is only that there must be an up-front acceptance that this is happening so that the final product is properly maintainable. To do otherwise is to compromise Ada's laudable goal of improved maintainability. If current DoD policy is inconsistent here, I suggest that the policy needs to be modified. Art Evans Arthur Evans Jr, PhD Phone: 412-963-0839 Ada Consulting FAX: 412-963-0927 461 Fairview Road Pittsburgh PA 15238-1933 evans@evans.pgh.pa.us