> James Watson wrote > > > > There's no mention of requirements, let alone > > > "meets all requirements". > > > > It doesn't say anything about specifications either. > You > > proposed that specification was the criteria to judge > > whether something is correct. I was merely pointing > out > > that there is a common understanding of the > relationship > > between requirements and specification. I merely did > this > > because of your bizarre argument that requirements are > not > > related to correctness. I generally wouldn't need to > > point out such trivial facts in a sane and rational > > discussion. > > 1) No, you were not "merely pointing out that there is a > common understanding of the relationship between > requirements and specification". You made a statement > about "correct" and "correctness" [Jul 30, 2007 8:43 AM], > quibbled about the need to define those terms [Jul 30, > 2007 9:28 AM], and claimed the unwritten definition in > your head was the same definition used by the vast > majority of English speakers [Jul 30, 2007 2:03 PM].
My statement pointing out that requirements and specifications were related came after your assertion that correctness is defined by specifications. Look for yourself.
I still stand by my assertion that most English speaking people have a common understanding of what 'correct' means. It may not be precise but I never said it was. You are the only one quibbling about the definitions of words. No one else has stated any need to clarify what 'correct' means.
I then stated that correctness is commonly understood to mean that a program meets it's requirements with respect to software.
> You claimed "I am talking about 'correct' in the way it's > defined by the vast majority of English speakers" [Jul 30, > 2007 2:03 PM] but so far you have not provided a single > example of 'the commonly understood "meets all > requirements"' [Jul 30, 2007 12:50 PM].
Why should I have to? It's the only possible sensible definition with regard to this discussion. 'Passes all tests' is clearly untenable. That would mean a correct program could be become incorrect without changing anything about it. The other definition you have propose is compatible with 'meets all requirements'.
Do you believe that a program that does not meet its requirements can be correct?
Do you believe that a program that meets all of its requirements (stated or unstated) can be incorrect?
> All of that was before you mentioned "the relationship > between requirements and specification" for the first time > [Jul 30, 2007 3:00 PM]. > > 2) Now you falsely claim that I have made a "bizarre > argument that requirements are not related to > correctness". Where exactly am I supposed to have made > that argument?
'Programs are verified "correct" against a specification - in contrast, the only way we can validate the program "meets all requirements" is to ask someone "is this what you wanted?".'
Do you need to redefine the term 'contrast' now? If you aren't arguing that correctness is not related to requirements, then what exactly are you arguing? It seemed that you were arguing that correctness was related to tests.
> -snip- > > You are the one trying to redefine words in order to > prove > > your argument. Trying to make up a new definition for > the > > word 'correct' is an absurd word game. > > I am indeed the one who understood that words mean > different things to different people, and so made clear to > Cedric how I understood what he had written [Jul 26, 2007 > 2:51 PM].
That's great. But I was not responding to you when I made my statement about correctness.
> You seem to be insisting that the definitions in your head > don't need to be stated because somehow they are the > real definitions, and any other meanings are > redefinitions or new definitions.
You are using a lot of words that haven't been defined in this thread. You could mean anything! How can I possibly reply? First, you need to define the word 'definition' and 'meaning'.
> It's commonplace for someone to have no doubt and yet > still be wrong.
Is that supposed to stand-in for an actual argument? Do you think that I don't know this? You can't actually think that proves me wrong in some way, do you?
All I'm saying here is that you can't convince me that the term 'requirements' is not commonly understood to be the basis of determining a programs correctness so don't waste your time trying.
> > The concept that passing all tests makes the software > > correct is patently absurd. If the program crashes are > > you seriously going to argue that it is 'correct' > because > > it passed all tests? Testing is a way of trying to > gauge > > the correctness. It doesn't define the correctness of > > software unless you requirements are specified as > passing > > a number of tests which would severely limit the kinds > of > > requirements that could be defined. > > I wrote - 'When we say "correct" I think we're saying that > the program corresponds to the spec as defined by our > tests...' [Jul 26, 2007 2:51 PM] - and you dismissed it > out of hand "The definition you attempted to apply to > 'correct' is circular." [Jul 30, 2007 11:03 AM].
I wasn't replying to you and I wasn't terribly interesting in your discussion with Cedric. It is a circular definition with regard to the statement that I was replying to.
> Apparently you like it better when you say it - "It > doesn't define the correctness of software unless > you requirements are specified as passing a number of > tests ..."
If that's all you were saying then yes that's exactly the same thing I am saying except that I don't believe any non-trivial application can be properly specified as a set of tests. It's a hypothetical idea as far as I am concerned.
"I would like to point out that proving statically that software is correct is impossible. A static type system only proves that what you typed makes some kind of sense...but what kind of sense? it's unknown unless you run the program."
If the (unstated) assumption is that 'correct' is defined to mean 'passes all tests' then it's a pointless statement equivalent to static typing is not equivalent to testing of which no one has argued to the contrary.
Personally I don't think that was the definition of 'correct' that was meant. At the very least it was not the implication that I got from the statement. And in that case, it is also true that "that for most non-trivial applications, it is not feasible to prove correctness at all" as I responded originally.
It was only after that that you stated quibbling over what 'correct' means. I see no statement from Achilleas Margaritis (the person I was responding to) stating or confirming that he was using your definition of 'correct'. I definitely see no such statement between when you proposed it and when I responded to him.
> > For reference: > > > > http://en.wikipedia.org/wiki/Requirements_analysis > > > > http://en.wikipedia.org/wiki/Requirement > > From your links: > "Requirements must be measurable, testable, related to > identified business needs or opportunities, and defined to > a level of detail sufficient for system design." > > "Most requirements should be testable. If this is not the > case, another verification method should be used instead > (e.g. analysis, inspection or review of design). Testable > requirements are an important component of validation. > > Certain requirements, by their very structure, are not > testable. These include requirements that say the system > shall never or always exhibit a particular property. > Proper testing of these requirements would require an > infinite testing cycle. Such requirements are often > rewritten to state a more practical time period." > > So requirements must be testable?
First, let me point out that just because I posted a link to a wikipedia page doesn't mean I agree with everything on it. I didn't write it. The point is that requirements is a commonly understood term in the software industry that is related specifications. Specifically, specifications are derived from the requirements.
In any event, yes requirements should be testable. If you think that means '100% verifiable through testing' then you are reading too much into it. If that were the case, then requirements could not be stated properly for most non-trivial applications. Even things like finite state automata that are verifiable are often not verifiable via testing. They are verifiable statically, however.
> > How would you define the behavior of a web-browser as a > > series of tests? How about even just a SAX parser? Do > > you really think it would be easier to understand what > is > > required of a program if all you were given were a set > of > > tests to run? > > I'd be a lot more confident to build something close to > what is expected if I were given tests instead of a > requirements document with the usual ambivalence. There > e would also be a lot less discussion about correctness > and interpretation. Either the tests pass or they fail.
You didn't answer the question the first two questions. I think you'd have a hard time figuring out exactly what you are supposed to build with just the required results especially given the fact that those tests would be highly unlikely actually cover the entire set of desired behaviors.
> I still stand by my assertion that most English speaking > people have a common understanding of what 'correct' > means. It may not be precise but I never said it was. > You are the only one quibbling about the definitions of > words. No one else has stated any need to clarify what > 'correct' means.
Maybe no one else is interested in understanding what you (or I) say.
> Why should I have to? It's the only possible sensible > definition with regard to this discussion. 'Passes all > tests' is clearly untenable. That would mean a correct > program could be become incorrect without changing > anything about it.
That's right - a change to the specification requires a change to the tests which may require a change to the formerly correct program before it could be considered correct once more, what's surprising about that?
> 'Programs are verified "correct" against a specification - > in contrast, the only way we can validate the program > "meets all requirements" is to ask someone "is this what > you wanted?".' > > Do you need to redefine the term 'contrast' now? If you > aren't arguing that correctness is not related to > requirements, then what exactly are you arguing? It > seemed that you were arguing that correctness was related > to tests.
If I wanted to argue that correctness is not related to requirements I would have written correctness is not related to requirements - not what I wrote.
I contrasted verification with validation.
Verification checks conformance to spec - correctness.
Validation checks what was really wanted - "meets all requirements".
> > It's commonplace for someone to have no doubt and yet > > still be wrong. > > Is that supposed to stand-in for an actual argument? Do > you think that I don't know this?
What a coincidence - it seemed to me that "There is no doubt in my mind" was supposed to stand-in for an actual argument.
Maybe this was the argument - "If the program crashes are you seriously going to argue that it is 'correct' because it passed all tests?". A program that crashes could indeed be both correct "passed all tests" and correct "meets all requirements".
Those who care specify MTTF and Availability requirements.
> If the (unstated) assumption is that 'correct' is defined > to mean ...
> Personally I don't think that was the definition of > 'correct' that was meant. At the very least it was not > the implication that I got from the statement. ...
It was clear to me that your (unstated) assumption about the meaning of 'correct' was not conformance to spec and that's why I wanted to know what you did mean.
Erik Engbrecht wrote > Why do I suddenly feel like I'm sitting in court or > congress instead of in a tech forum discussing programming > languages?
I think it's usually like congress - folk appear and speak about the same things they usually speak about, without any particular regard for the given topic. (And there's hardly anyone there listening, except for the others waiting to speak.)
Maybe you're thinking about congressional hearings - they are definitely more legalistic.
> > > How would you define the behavior of a web-browser as > a > > > series of tests? How about even just a SAX parser? > Do > > > you really think it would be easier to understand > what > > is > > > required of a program if all you were given were a > set > > of > > > tests to run? > > > > I'd be a lot more confident to build something close to > > what is expected if I were given tests instead of a > > requirements document with the usual ambivalence. There > > e would also be a lot less discussion about correctness > > and interpretation. Either the tests pass or they fail. > > You didn't answer the question the first two questions. I > think you'd have a hard time figuring out exactly what you > are supposed to build with just the required results > especially given the fact that those tests would be highly > unlikely actually cover the entire set of desired > behaviors.
describe Browser do before(:each) do @browser = Browser.new end
it "should open a url that's typed in the location bar" do @browser.location_bar = "http://some.url" @browser.go @browser.document.should == "<html...." end
it "should display parsed html in the main window" do @browser.document = "<html...." @browser.window.should == "This is a test" end
it "should open clicked links" do @browser.document = "<html...." @browser.window.click(:test_link) @browser.window.should == "This is a linked page" end
end
describe SaxParser do before(:each) do @parser = SaxParser.new("<root><child/></root>") end
it "should get the next element" do @parser.next_element @parser.current.should == "root" @parser.next_element @parser.current.should == "child" end
It's amazing how the type system discussions are always the hottest! In LtU they had to break the discussions in multiple topics because it was getting too long.
Obviously static typing has its place in the industry, simply because some people feel safer with it. But we have a long way to go until programming becomes like painting.
Just like a painter has to see his work of art being developed in front of his eyes, programming would be much better if we could see what we were developing. As it is right now, programming is like painting blindfolded, and only be able to see the work after it is finished!
I think this is a major problem with programming today. If we had more interactive environments, the need for static typing would be lessen.
> It was clear to me that your (unstated) assumption about > the meaning of 'correct' was not conformance to spec and > that's why I wanted to know what you did mean.
I'm not sure I understand your statement but my understanding of correct in this discussion has always been related to requirements and specification is derived from requirements.
If you wanted to know what I meant, you should have just asked instead of accusing me of "quarreling about definitions without providing any." There was nothing unclear about my response to Achilleas about correctness. If you think there was, then the problem is with you.
> > describe SaxParser do > before(:each) do > @parser = SaxParser.new("<root><child/></root>") > end > > it "should get the next element" do > @parser.next_element > @parser.current.should == "root" > @parser.next_element > @parser.current.should == "child" > end > > end
Split the input on non-alpha characters and put that into an array. Next moves the current index, current retrieves the element at the current index.
> That's right - a change to the specification requires a > change to the tests which may require a change to the > formerly correct program before it could be considered > correct once more, what's surprising about that?
I didn't say anything about a change to the specification. The above is only true in the case where the tests are the specification. That is not how specifications are normally documented.
> If I wanted to argue that correctness is not related to > requirements I would have written correctness is not > related to requirements - not what I wrote.
No, you were just making a statement that is in contrast. That's a great rationalization.
> I contrasted verification with validation. > > Verification checks conformance to spec - correctness. > > Validation checks what was really wanted - "meets all > requirements".
And I'm the one playing word games. Unbelievable.
> What a coincidence - it seemed to me that "There is no > doubt in my mind" was supposed to stand-in for an > actual argument.
That was an incorrect assumption. A foolish one, actually.
> Maybe this was the argument - "If the program crashes > are you seriously going to argue that it is 'correct' > because it passed all tests?". A program that crashes > could indeed be both correct "passed all tests" and > correct "meets all requirements".
You are trying to side step the issue. It's very possible, common even, to have a program that passes all tests that doesn't meet all requirements. Do you consider such a program to be correct?
> > > > describe SaxParser do > > before(:each) do > > @parser = SaxParser.new("<root><child/></root>") > > end > > > > it "should get the next element" do > > @parser.next_element > > @parser.current.should == "root" > > @parser.next_element > > @parser.current.should == "child" > > end > > > > end > > Split the input on non-alpha characters and put that into > an array. Next moves the current index, current retrieves > the element at the current index.
Is 'next' a function or a method? Is 'current' a function or a method? What should split do? What is 'element'? What is 'index'? Move the index of what? Do all 3 "current"'s mean the same thing? What does retrieve mean? Does the function/method retrieve only retrieve the element from the array or does it also return it when called? How do I start it? How does it get input? How do you define non-alpha characters? Will something like *root*child*root* work as well? What if I don't have an array in my language?
> Is 'next' a function or a method? > Is 'current' a function or a method? > What should split do? > What is 'element'? > What is 'index'? Move the index of what? > Do all 3 "current"'s mean the same thing? > What does retrieve mean? Does the function/method retrieve > only retrieve the element from the array or does it also > return it when called? > How do I start it? How does it get input? > How do you define non-alpha characters? > Will something like *root*child*root* work as well? > What if I don't have an array in my language?
Um, do you understand that I was proposing a solution that meets your 'specs'? A lot of these questions are good ones. Show me show you will specify the answers as tests.
Flat View: This topic has 370 replies
on 25 pages
[
«
|
202122232425
|
»
]
Previous Topic
