On software quality and engineering

[Matthew Hawkins]

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.

-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20021103/c7d5bac4/attachment.bin