On software quality and engineering
matt at mh.dropbear.id.au
Sun Nov 3 11:04:23 EST 2002
David Gibson (david at gibson.dropbear.id.au) wrote:
> More to the point, once you put the specifications into a formal
> language, it's not clear that it's significantly easier to tell that
> the specifications are correct than to tell that the code is correct.
How do you prove it is correct? What is "correct" ? For some problems,
there will be a mathematical proof, and mathematics is simply a formal
specification language. The proof may be logic based, it may involve
the application of formulas, which in turn could be proven. It could be
a bit of both (inductive whatsit..)
For other problems which do not involve mathematics, you may be able to
build a test harness around that specific part which proves it... was
the file made, did the function return a result in the set of results
that we accept, etc.
I was under the impression that languages like UML existed for two
purposes, firstly to demonstrate a solution in a manner that managers
understand, so they're able to "manage" the project. Secondly, by
serving as some kind of middle-ground like Java bytecode, it opens the
doors for much of the real implementation to be auto-generated, freeing
programmers from mundane tasks.
Oh, I guess in some respects it also seperates the men from the boys, so
to speak. If you can visualise and describe the problem solution in a
different language ("thinking outside the box") then you know you
understand it, and implementation simply becomes syntax.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20021103/c7d5bac4/attachment.bin
More information about the linux