[IGSTK-Developers] Sequence Diagram for DICOMImageReader

[Kevin Gary]

All,

Attached are 2 sequence diagrams for the call sequence
involved with DICOMImageReader. They assume the SM
is in the ImageDirectoryNameReadState and the caller
invokes ReadImageRequest (generating a ReadImageRequestInput).
One of the diagrams demonstrates a typical successful
call, another a failed call.

I have a few comments. I apologize upfront if they sound
too critical; I do not even know who wrote this code, and
I'm sure I have some misunderstanding here.

It seems in both the success and failure cases that the
SM sets its state before the actual transition operation
is executed (as per the needed change in Processinput
a few weeks back). This creates a situation where the
target state is set before the transition completes
(or even starts). This would be a problem in a
multithreaded scenario, as there is a period when the
state is basically incaccurate. It is worse in the
failed case, since the state is set to "ImageRead", yet
if the transition operation fails (AttemptReadImage)
I cannot find where the state is reset. Perhaps this
is done via the event mechanism, but I did not see it
(and even if it did it would seem quite a strange and
convoluted way to do it).

This SM does not have states for "AttemptToDoXXX" as I
saw in the tracker code last month. I believe this type
of FSM is called a Mealy FSM, while the tracker's is
called a Moore FSM. The benefit of the latter is you are
always in a known state, even as an operation is going on,
whereas you are not with the former. This is part of the
source of the problem mentioned in the paragraph above.

DICOMImageReader is a subclass of ImageReader, yet
ImageReader is not governed by a SM. When ConnectImage is
called the sequence goes outside the SM. Perhaps the
nature of ConnectImage is considered safe, but it looks
like it does set a spatial object somewhere. If Get methods
need a SM why shouldn't this?

In the failed read case, an error event is generated but
I cannot find any observers for it. It would seem that
the object itself would have to listen for such an event
and invoke a callback to generate an input to the same
state machine? As you can tell I am getting really
confused now!

I'm still struggling, in light of the system being
essentially single-threaded, in the utility of using
PushInput and invokeEvent in the way we do. I cannot
envision a need for queued inputs in a single-threaded,
non-asynchronous application. Events make sense for
things like updating a GUI or Logger, but the way they are
used goes against the intent of decoupling the event
generator from the receiver. And I would think this extra
complexity would decrease safety due to an increase in
human error.

I owe the group a few more of the diagrams so we can see
if different objects use a consistent SM pattern.

K2


-- 
===
Kevin A. Gary, Ph.D.
Assistant Professor
DCST, ASU East
(480)727-1373
http://kgary2.east.asu.edu
kgary at asu.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DICOMImageReader-ReadRequestImage-Success.pdf
Type: application/pdf
Size: 44334 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20051006/234f98d5/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DICOMImageReader.RequestReadImage.Error.pdf
Type: application/pdf
Size: 43734 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20051006/234f98d5/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kgary.vcf
Type: text/x-vcard
Size: 369 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20051006/234f98d5/attachment.vcf>