[IGSTK-Developers] Application Framework Concept

Wed May 3 21:40:16 EDT 2006

Stephen,

The application of workflow concepts as you suggest makes sense and is
appropriate for certain types of applications. A few things -

- "workflow" has a lot of connotations, particularly in the business 
application
  space. While that is not our domain, NIH folks might start equating it 
with
  patient information applications, where the term workflow is heavily used.
- The workflows referred to sounds like usability patterns as much as 
they are
  workflow "architectures" - and this is a good thing. Guide, hub, and 
wizard
  patterns that incorporate an ease-of-use, task-oriented "flows" would show
  we are thinking about how to make these applications easy to use, easy to
  develop, and consistent (for safety).
- You use the term "framework" but I am not sure what the term refers to in
  the context you use it. I think the word can be dropped altogether.
  Common terms are "workflow" or "process" to refer to the template and
  "workflow instance" or "process instance" to refer to a bound instance.
- Worklow languages and GUI-oriented development are complementary. I can't
  imagine supporting one without the other. Certainly I cannot see how or
  why one would have GUI-driven development without an underlying language -
  how else could one demonstrate safety with any rigor?
- I find it curious that a graphical design tool with code generation is now
  being considered after such an approach was quickly dismissed early in the
  project. Perhaps the application-oriented nature of this discussion and
  the maturity of IGSTK state machines have caused this change of heart?
- The implication of a workflow-oriented model is that the "trigger" for a
  cascading set of events would be from the user, presumably via the GUI.
  Given recent discussions on concurrency, can we assume this? Do we 
need to?
  Concurrency modeling in workflows is common but certainly more complex.
- Our UML activity diagrams from Brian's requirements represent a few
  application-oriented workflows we have explored.  Activity diagrams with
  OCL is considered a workflow language - and a specialization of 
statecharts
  in UML 2.0
- Our state machines govern the activity of an individual component, but not
  an entire workflow. State machines may be used for this, but I am pointing
  out that we use them on an entirely different level right now.
- Finally, I would caution against us recreating the wheel. For example, 
there
  are an awful lot of process definition languages out there. There are
  many GUI-driven component composition tools. There are many code 
generators,
  particularly those following a Model-Driven Architecture (MDA) approach,
  such as Rational Rose RT and Rhapsody.

While I have a number of questions, I like the idea very much. Creating an
application framework that allows application developers to think in terms
of tasks that have to be accomplished more closely resembles the strict way
in which surgical procedures are defined, and as such are a natural way to
present IGSTK to developers. Furthermore, thinking about how components
interact to complete tasks will resolve an issue that is gnawing in my
gut about IGSTK.

Brian?

K2

Patrick Cheng wrote:

> 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
>>
>>
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers

-- 
===
Kevin A. Gary, Ph.D.
Assistant Professor
DCST, ASU East       
(480)727-1373
http://kgary2.east.asu.edu
kgary at asu.edu