Re: OOP/OOD Philosophy

Robert C. Martin wrote:

>Yes, and still... Confounding the issue with many different
>definitions does not change the underlying theme. We express
>requirements as executable tests.

Stating that requirements are expressed as tests does not define what
requirements are. I seriously doubt that all automated tests express
requirements (unless of course you define 'execution test' to mean
'test of requirement'). The reason I'm harping on the issue of what
is meant by a 'requirement' is because it is important to
understand 'what it is' that is being demonstrated when a piece of
software passes an automated execution test suite.

For example, a customer requiring that a bell should sound when a
patient's heart stops does not care if the software writes 0x65 to
memory location 0x6754. The customer only cares that the bell goes off.
If an automated test suite checks that 0x65 is written to location
0x6754, it does not check the requirement. It simply checks that some
part of the specification of the software is met.

>I am speaking specifically of the specification of the behavior of the
>software as defined/agreed by the customer.

Customers do not in general express the behavior of the software as
requirements. They express the behavior of stuff outside the computer
(or possible outside the software being written) as requirements. I see
this as the main difference between specification of the software and
requirements from customers.

>Any line of code that can be written can be tested.

Of course, but many lines of code may produce a large number of states
that cannot be tested through execution tests. Also, all problems
cannot be decomposed into parts that can be analyzed independently.

>However, execution tests can be the primary
>mechanism that you depend upon to ensure that the system is correct.

Agree and disagree. For some systems the primary mechanism may be
automated execution tests. For others, it may be equations from
physics, mechanics or chemistry together with automated execution tests
that are the primary mechanisms that ensures that the system is
correct. I feel a little uncomfortable with the word 'primary'
since it sounds as if it is OK to exclude other mechanisms for ensuring
that the software is correct.

Regards,
Hans Ewetz

.