[IGSTK-Developers] Crash recovery?

[Tina Kapur]

Thanks, Luis. 

Another question: why the state machine pattern? I've read a couple of IGSTK
papers and the discussion on the project wiki. I appreciate the motivation
to keep the code as robust as possible and to prevent programmers from
making mistakes. However, the choice of the architecture typically most
directly impacts extensibility and maintainability of the code base rather
than robustness. The quality of programmers and test suites is what is going
to determine the robustness of IGSTK.  Did I miss the point of what the
state machine pattern buys here? Again, all your reputations precede you as
architects and engineers, and I can see this architecture choice being a
no-op in the worst case, but if there are any particular discussions that
point to the benefits of this pattern in the case of IGS, I'd appreciate a
pointer to increase my knowledge base in this area.

And thanks again to everyone for any time this discussion might cost you... 

Best,
-Tina 

>-----Original Message-----
>From: Luis Ibanez [mailto:luis.ibanez at kitware.com] 
>Sent: Friday, September 09, 2005 2:26 PM
>To: Tina Kapur
>Cc: 'David Gobbi'; 'Andinet Enquobahrie'; 'IGSTK Developers'
>Subject: Re: [IGSTK-Developers] Crash recovery?
>
>
>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
>> 
>> 
>
>
>