[IGSTK-Developers] Crash recovery?

[Luis Ibanez]

Tina,

If we implement applications as C++ classes that derive from an
igstk::Application class endowed with a State Machine, then testing
of the application should be feasible with 100% code coverage and
with full path combinations (calling its method in arbitrary orders).

Stress testing should also be possible, since it becomes a matter
of adding new test programs that rerun the application class as many
times as desired and in as many combinations of inputs as desired.

The use of simulators, such as the tracker simulator that Hee-Su
wrote, will help a lot to make this vision of full testing a practical
reality.


    Luis


-----------------
Tina Kapur wrote:
> Speaking of reliability and testing, is testing of applications considered
> outside the currently defined scope of the toolkit?  I am sure that those of
> you who have worked with FDA requirements on products have suffered through
> the mechanism of writing one or more tests corresponding to each requirement
> in the req spec, and then documenting that you ran the test and it passed.
> Other measures of robustness that I've also found useful are stress testing
> in which we simulate multiple passes through the software (this which
> basically checks for memory leaks and re-entrant code).  Again, as we all
> know, testing applications is a pretty large task and I don't want to use
> too many of the group's cycles on it if it is currently outside the scope of
> the project...
> 
> -Tina
> 
>  
> 
>>-----Original Message-----
>>From: David Gobbi [mailto:dgobbi at atamai.com] 
>>Sent: Thursday, September 08, 2005 5:31 PM
>>To: Andinet Enquobahrie
>>Cc: Tina Kapur; 'IGSTK Developers'
>>Subject: Re: [IGSTK-Developers] Crash recovery?
>>
>>Andinet Enquobahrie wrote:
>>
>>
>>>Tina Kapur wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>Does IGSTK have a mechanism for crash recovery?  I was 
>>
>>making a wish 
>>
>>>>list of what such a toolkit should have, and I can see how the 
>>>>logging mechanism could be used for recovery from a mid surgery 
>>>>crash, but just wanted to check if the feature was planned for 
>>>>anytime in the near future.
>>>>
>>>>Thanks.
>>>>-Tina
>>>
>>>Hi Tina,
>>>
>>>We hope that the toolkit wont crash in the middle of a surgery...may 
>>>be before or after :) But on a serious note, the main reason 
>>
>>the state 
>>
>>>machines were introduced in IGSTK is to make it "ideally" 100% 
>>>predictable. All error conditions and scenarios should be handled by 
>>>the state machines. IGSTK should be unrecoverable-condition proof. In
>>>fact, we had  a discussion this afternoon on the TCON about   
>>>introducing state machines into the applications itself. Something 
>>>like an application class with state machines that every application 
>>>should be derived from. This design will tighten it up even more.
>>>
>>>cheers,
>>>-Andinet
>>
>>I think as we design IGSTK, we should work with the assumption 
>>that it is never going to perfectly crash-proof.  We need to 
>>be ready for the worst.  The titanic wasn't an unsinkable 
>>ship, regardless of what its designers thought.
>>
>>One of the most important things for medical software is to be 
>>able to quantify its reliability.  I wonder if there is some 
>>way we can do this for IGSTK?  Usually reliability statistics 
>>are computed at the application level, by looking at failure 
>>rates or counting how often critical bugs are found.
>>
>>- David
>>
>>
>>
>>
> 
> 
> 
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
> 
>