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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,66752102482bbdca X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Required Metrics Date: 2000/05/06 Message-ID: <8f26s6$lrj$1@nnrp1.deja.com> X-Deja-AN: 620095975 References: <5DDO4.2237$wb7.194854@news.flash.net> <8ek4ea$5ta$1@nnrp1.deja.com> <390DC8AD.59B5EBEE@averstar.com> <8ep0k3$jlr$1@nnrp1.deja.com> <8es5fv$4ov$1@nnrp1.deja.com> <_HnQ4.7884$wb7.550012@news.flash.net> <8eukm0$ssm$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x42.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Sat May 06 22:37:58 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-05-06T00:00:00+00:00 List-Id: In article , "Ken Garlington" wrote: > Except, of course, for those of us who read the word > "requirement" as it's > used in software engineering. And there perhaps lies the crux of the problem, a formal language definition has almost NOTHING to do with an informal "software engineering" requirements document. It is that confusion in the understanding of the word requirement that lies at the heart of the confusion. Indeed, most software projects are specified with a requirements document where the requirements are often very much subjective, and not anywhere *near* being a mathematical formal specification. > You know, I lose those requirements battles from time to time > myself. It never occured to me to just ignore the ones that I > considered infeasible to meet. You keep saying this, but that does not make the argument here any more convincing. The documenatation requirements are trivial to meet. Everyone meets them, no one ignores them. That of course is from a formal language specification point of view, but the standard is a formal language specification, nothing more and nothing less. > Again, you're confusing "what a customer wants" with "what the > standard requires". In software engineering, validation > addresses the former, > verification the latter. Please don't bring your software engineering background to the table, you will just confuse yourself, it is irrelevant. Yes, a lot of people don't understand this, including some people who participated in the language design effort. A background in formal language semantics is much more relevant here, and I definitely think you will have trouble writing semantic equations for the documentation requirements, no matter WHAT formalism you choose. Yes, we chose to use formal english (which is not that great mathematically) to describe the semantics of Ada 95, so that it would be more accessible, but it has to be equivalent to a formal specification in some sense, or it is useless. It's a bit like the controversy over translating the bible into english. When this was first done, priests worried that people would look at the result and try to interpret in an informal context which would lead to misunderstandings. I leave it to others to judge whether there concern was misplaced, but for sure there is a danger in making standards accessible if people start reading them like software engineering specifications. Now the "implementation advice" sections of the RM *can* be read this way, and including these sections was a brilliant innovation on the design team's point of view, because it allowed us to state informal pragmatic implementation "requirements" where requirements here is used in Ken's sense of software engineering, without contaminating the formal definition with junk. > Do you think it's fair to accuse me of such an accusation, > when the quoted statement doesn't actually say that? Yes, I think it's fair, reread what you said. > Like I said, "with a pen in the hand, and a song in the > heart." Nope! No "song in the heart", which I take to mean with an intent other than a formal declaration. Perhaps you have some other meaning, if so, it is obscure to me. > Of course, > your signature is based on your determination as to which requirements are > "real" requirements, believing that all other requirements are "met" no > matter what. All requirements are requirements. I am not saying that the documentation requirements are not requirements, just that they are trivially met. > You may believe that the ACVC review board, and all other > vendors, agree with you. You mean I agree that there can be no formal tests for whether you meet the documentation rquirements. I cannot imagine anyone with any reasonable knowledge thinking otherwise. > You may be right, for that matter. If you're wrong, > there's no way to find out, since apparently the list of non-requirements > has never been formally established, and nobody (not even the vendor) checks > that any requirement is met beyond passing the conformance test. There is no list of non-requirements, because there are no non-requirements. THe DOC requires that you have not made any intentional deviations from the FULL SET of requirements, including the documentation requirements. > You might want to re-read your original statement: "How can the DOC be > signed if you have ignored a requirement?" Note that the word > "intentionally" does not appear. intentionally is of course critical. Otherwise the DOC would be a declaration that your compiler was bug free. This is not intended, and would be impractical. > > Nope, the issues with pragma Reviewable are also all > > documentation based, let's look: > > Yes, let's. Specifically, let's look at the words which appear just before > paragraph 5: > > ***** Implementation Requirements ***** > > "5 The implementation shall provide the following information ..." > > Now, I suspect you're using the term "documentation" informally, not in the > sense of ARM 1.1.2. However, since all Implementation Requirements, like all > Documentation Requirements, are not really requirements, perhaps we _should_ > use the same name for both. Of course implementation requirements are requirements, what gave you the lunatic idea that this is not the case. I say lunatic here, because it simply makes no sense. There are many critical implentation requirements. Where ON EARTH did you get this idea, certainly not from anything I wrote. Here is an example (there are hundreds maybe thousands of others) Implementation Requirements 15 An implementation shall support lines of at least 200 characters in length, not counting any characters used to signify the end of a line. An implementation shall support lexical elements of at least 200 characters in length. The maximum supported line length and lexical element length are implementation defined. This is formally definable, and of course tested by the ACVC tests. Again, I ask where did you get the idea that implementation requirements are not requirements??????? > When we were discussing these safety and security requirements during that > industry-implementors meeting lo these many years ago, I was frankly > surprised that the vendor representatives (including yourself) didn't put up > more of a fuss. Now I see why. What a total waste of our time. Actually many useful things came out of those meetings, but if you thought that the meetings were about requiring vendors to provide useful usable implementations, you were indeed deluding yourself, since language standards can never guarantee this. > > !topic Non-Requirement Requirements > !reference RM95-1.1.2(24-39) > !from Ken Garlington 00-05-05 > !keywords requirements, advise > !discussion > > The referenced paragraphs define several different categories of the > standard. Some of these categories use the term "requirements," although > they are not considered requirements by the Ada vendor community. There > should be an explicit list of which categories can be considered > requirements (i.e., it is possible for a vendor to "fail" to meet it). All > other categories should be described in the terms currently used for > "Implementation Advice." This is plain silly, I can't imagine the ARG giving it much attention, since it amounts to nothing more than an unfounded polemic. There is no part of the Ada community that considers any requirements in the RM not to be requirements, and certainly the vendor community does not ignore any requirements. Again, I think the entire problem comes from the fact that you don't really understand the purpose of a formal language definition, and that you read the word "requirement" in (to use your terms) "software engineering" sense, which is totally misleading in this context. This reminds me of people who use to operate under the curious illusion that validation had something to say about guaranteeing that a compiler was usable (of course failing validation does say that a compiler may NOT be usable, but passing validation does not for a MOMENT constitute a guarantee that a compiler is usable). Perhaps we should have used VDM for the Ada standard after all -- it would certainly have helped eliminate uncertainties and for sure would have avoided this kind of user confusion :-) Sent via Deja.com http://www.deja.com/ Before you buy.