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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: Ken Garlington Subject: Re: 4GL code in a deliverable (was: ARIANE-5 Failure) Date: 1996/06/24 Message-ID: <31CE8801.729D@lmtas.lmco.com> X-Deja-AN: 161901799 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> <31C7B8D4.60AA@lmtas.lmco.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.02 (Macintosh; I; 68K) Date: 1996-06-24T00:00:00+00:00 List-Id: Robert Dewar wrote: > > Ken said > > " > Would this "truth" also exist if the device used to generate the Ada code > from the database was a human being, rather than a machine? It seems to > me the consequence of this interpretation of Ada policy is that all requirements > and design artifacts must be generated without the use of tools, else an > Ada waiver is required!" > > nonsense, no one is saying that! What is being said is that the critical > point is what level the code will be maintained at. If the code is to be > maintained at the Ada source level, then it matters not a whit how it > was developed, by humans, clever tools, or friendly martians. > > If on the other hand, the maintenance is to be done on the "original" source > code (which may of course be in the form of a database and not a text in the > normal sense -- that makes no difference), then indeed it is important to > be sure that this source code is written in an appropritae language, which > is properly supported, preferably standardized, and preferably avoids > the danger of single sourced tools. > > Ken, do you really disagree with this? If so, I am surprised, and would > appreciate you making the source of your disagreement clear! I do not disagree that this makes sense, and that in general (never mind the 4GL issue), that a contracting agency should ask for both the implementation of the software, and also the data/documentation/tools associated with that software, if the contracting agency intends to provide post-deployment support (directly or through a third party). Such a request should be written into the contract, and in fact, such requirements are part of many programs. However, you raised a much narrower issue. If a code generator is used to generate Ada source code (specifically, a code generator whose inputs are a graphical representation of the algorithms and interfaces a la MatrixX), does such an approach violate the DoD Ada policy, and therefore require a _waiver_? My reading of DoD 5000.2-R and DoDD 3405.1 indicates that if Ada source code is used in the process of creating an application, then it's an Ada application, independent of the process used to maintain that application. The only change introduced in 5000.2 is that, if the Government has _no_ interest in what maintenance process is chosen, then Ada is _not_ required. If someone can quote something from 5000.2, 3405.1, or a service policy that states conditions under which a software application is built from "only" Ada source code as part of the process, but still requires an Ada waiver, I would be interested in seeing this analysis. You might argue that words should be added to these directives, but in their current form, I think they bear out my position. As to whether they _should_ have words about requiring Ada waivers for code generators, I'm ambivalent. As I said before, I agree that a system maintained at a "4GL" level should continue to be maintained at that level. (I also think that requirements databases should continue to be maintained during maintenance, for that matter). However, requiring extra paperwork to use innovative approaches to reduce the cost of generating Ada source code seems counter-productive, particularly since (a) the maintenance site may choose to maintain the software differently from the developing site, and (b) even automatically-generating Ada code can still accrue many of the benefits of the Ada policy, such as a common implementation notation, fewer tools, etc. Note that this discussion points out a well-known (at least, I _thought_ it was a well-known) flaw in the Ada policy as written. Just requiring software to be written in Ada does not, by itself, cause fundamental improvements in depot costs. Other issues, such as the number of different tools required, the number of documentation and data formats/conventions used, etc. also have large effects. Ada policy may indirectly improve some of these other factors, but it has to be coupled with other initiatives (e.g. electronic data exchange standards) to provide large-scale returns. -- LMTAS - "Our Brand Means Quality"