On software quality and engineering
grail at goldweb.com.au
Mon Nov 4 13:46:31 EST 2002
Simon Fowler wrote:
> Yes, but if you make the specification /complete/, in the sense that
> the design for a piece of physical engineering is complete,
Ick.. Most software specification deals only with form, fit and
function. It's usually the case that more fine-grained design isn't
useful, since the requirements are not fully known before software
construction is commenced.
Thus many software systems are actually built during the "requirements
discovery phase" and never leave it.
As Fred Brooks said, "Always plan to throw out the first attempt and
start from scratch... you generally will anyway".
> Couldn't you translate directly from the mathematics to an
> executable representation, though?
Formal languages like "Z" deal with properties of the thing that is
going to be built (or the thing that is being tested). This is similar
to the test-first approach to software construction.
You describe certain parameters that indicate that the component "works"
- in the case of Config::IniFiles, for example, one specification goes
# Test 1
# Multiple equals in a parameter - should split on the first
$ini = new Config::IniFiles( -file => 'test.ini' );
$value = $ini->val('test7', 'criterion') || '';
ok($value eq 'price <= maximum');
Where the "test.ini" file contains:
criterion = price <= maximum
> Being cynical, I can't help wondering if a large part of the
> improvement in quality you get from putting all that effort into
> modelling the system comes from the simple fact that you've just
> spent a long time thinking very deeply about the system.
Thinking about the system doesn't always result in better software.
Sometimes you make some basic assumptions right at the beginning of a
software project, only to find 9 months in to a 12 month project that
you made the wrong assumptions (and usually it's one of the assumptions
you didn't realise you'd made), and you have to start from scratch.
Putting *some* thought in is usually better than putting *no* thought
in. That's why I feel that languages like Java are superior to Visual
Basic - in Java you have to think at least one step ahead. In Visual
Basic, you just copy/paste/modify.
Now, can anyone give me the ISBN for a good reference or tutorial book
on Z formal proof?
More information about the linux