Re: Interresting thread in comp.lang.eiffel

["David K Allen" <dkallen@visi.com>]

> David Gillon wrote:
>
> > One thing I'm still waiting to hear in this discussion is how [DBC]
> > would handle a temporal constraint of the type 'Signal A will be updated
> > with its new value within 2.5 ms of a change to any of its source
> > inputs'.

That is easy in theory, there is no magic here. You can do this in any
language, and many probably have.
But there is a cost to the calculation.  In time-sensitive applications, the
cost of calculating the answer may exceed the cost to do the calculation ;)
I have no magic solution for that. Obviously this technique can only be
practical when the cost of calculating the duration is immaterial compared
to the cost of the process being measured.  Although I will say that if
these time-sensitive routines were in an embedded,  real-time situation,
then the 'timer'object shown below, could be a hardware timer that was
dedicated to just such a task, so the measurement apparatus would have a
negligible effect on the overall calculation in many cases.

Also, someone else asked "What if my routine does not like the allowed
duration chosen?  Am I stuck with it failing, even though I might have
wanted the answer even if it came later?"  I will illustrate how to work
around that.
Assume a function 'signal' as follows:
------------------------------
signal (input: REAL): REAL is
            -- return 'signal' based upon 'input'
    require
        input_non_negative: input >= 0
    do
        timer.start
        ....
        timer.stop
    ensure
        signal_valid: (input > 0) implies (Result > 0) and (input = 0)
implies (Result = 0)
        duration_within_tolerance: timer.duration <= Max_Allowed_Duration
    end
-------
This illustrates how DBC can be used in the 'ensure' clause to enforce the
timing constraint
Notice also that the reference point 'Max_Allowed_Duration' is a variable,
to allow flexibility in application.
This addresses the issue someone else raised (I could not find the post, but
it was within the last few days).
For a client to set this allowable duration to a value appropriate for the
application, one merely writes a routine:
-----------------------------------------
set_max_allowed_duration (d: REAL) is
        -- allow client routines to set the 'Max_Allowed_Duration' to suite
their requirements
    require
        duration_valid: d > 0.01
    do
        ...
    ensure
        Max_Allowed_Duration = d
    end
--------------------------------------------
Or you could also have a feature pair 'disable_time_limit', and
'enable_time_limit' where do the obvious.

What do you think of this approach?  Can anyone think of better ways to
model limits to duration in DBC?
--
Best Wishes,
David Kreth Allen
Software Consultant
Minneapolis, Minnesota - USA