[IGSTK-Developers] Application Framework Concept

[Patrick Cheng]

Hi Luis,

The visual programming environment sounds very interesting to me 
especially when applying it to programing the state machine.

As I have mentioned before, there are some project called FSMC (Finite 
State Machine Compiler), which has a GUI canvas for user to design the 
state machine by drag and drop states and transitions. And later on they 
can generate the state machine code base on this graphic model.

I think this will help the developer a lot for the first stage of 
mapping out the application work flow and state machine frames.

Patrick

Luis Ibanez wrote:
> 
> Hi Stephen,
> 
> The framework looks very nice.
> 
> 
> The approach of starting from the clinical workflow and
> mapping it into an application is definitely a good way
> to address our concerns about patient safety.
> 
> 
> The idea of generating the source code of the corresponding
> StateMachine will also help to address the concerns of
> developers who may find this task too complicated or at
> least boring.
> 
> 
> I'm not quite sure that a "Language" is the best mechanism for
> formalizing the workflow in this context, but it is certainly
> the approach that many "state machine" based frameworks have
> taken. So it will be easy to find references to other projects
> that have followed this approach and therefore provide support
> for our decision.
> 
> 
> Intuitively I would have preferred a sort of visual programming
> environment where the developer would have selected IGSTK components
> by dragging blocks into a canvas, connect them using colored lines.
> This will create the infrastructure of the application (e.g. if it
> has 2 Viewer2D and 1 Viewer3D, what SpatialObjects it needs, and so on.
> In a second canvas, it could represent the clinical workflow using
> also blocks that are dragged from a toolbar. Then generating the
> source code of a state machine from this flow diagram.
> 
> 
> On the other hand we all know that developing GUIs will require a large 
> amount of effort (time/money); so a language version of that interaction
> may be a more realistic approach.
> 
> 
> One thing that I would suggest to add is to have the notion of
> "checkpoints" at the application level. They may end up being
> implemented as transitions of the state machine, but from
> the point of view of the clinical level, they should be the
> ones that define when it is appropriate to pass from State A
> to Stage B or the intervention.
> 
> 
> 
>    Luis
> 
> 
> ===========================
> Stephen R. Aylward wrote:
>> Hi,
>>
>> I wanted to run a concept by ya'll.  Please take a second to let me 
>> know what you think of the following design for the application 
>> framework solution:  (please comment on the feasibility of the 
>> solution, no need to pick apart the text...yet... :) )
>>
>> [SNIP]
>>
>> Generating an IGSTK application at a minimum requires (1) carefully 
>> considering the workflow of the medical procedure and (2) implementing 
>> that workflow as a comprehensive set of state machine transitions that 
>> integrate chosen IGSTK modules.
>>
>> Our analysis of several interventional radiology tasks [REF] has 
>> revealed that there are a few general workflow frameworks that are 
>> common to many interventional radiology procedures, and substituting 
>> appropriate modules into a workflow framework is sufficient for 
>> specializing a workflow for a particular procedure.
>>
>> We propose to provide an application-builder program that allows a 
>> user to choose from a list of pre-defined workflow frameworks and to 
>> specify modules for the components of the chosen framework.  The 
>> application-builder program will then automatically generate the 
>> source code and CMake files needed to build that IGSTK application.
>>
>> The tasks of this project are
>>
>> 1)    Develop a language for defining workflow frameworks as 
>> application templates.
>> 2)    Develop a language for describing available IGSTK modules that 
>> can be plugged into the components of a workflow template.
>> 3)    Develop and validate a program that can load a framework and 
>> multiple module definitions, accept user input to assign modules to 
>> the components of the framework, and generate code that implements a 
>> complete application.
>>
>> The concept of an application-builder program is the penultimate 
>> embodiment of patient-safety-centric programming that has driven the 
>> development of IGSTK.
>>
>> [SNIP]
>>
>> Stephen
>>
> 
> 
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
> 
>