Converting a complex vi to DQMH

[FlatCat]

I'm in the process of updating an existing application -- carefully written, about 125 vi's in size -- that has not been touched in a long time. There are 10 or so user-facing vi's that are based on the JKI State Machine. Each of these has about a dozen states, and within the "Idle" state, there is an Event Structure that handles 20 FP events and some user events that are used to communicate between vi's. 

It's DQMH-like in some ways, but with the MHL and EHL combined into a single loop, and with all the Broadcast and Request events for the entire application gathered into a huge cluster that is curated by hand. Each of the state machines is launched via Start Asynchronous Call. So it is not easy to modify and to trace the flow of execution. 

I'm considering trying to convert some or all of these state-machine vi's into DQMH modules, both for the sake of the application and as an opportunity improve my DQMH skills. But it seems like doing so would require almost a complete rewrite of these 10 vi's, copying the code from hundreds of states and user events by hand into the new DQMH module. The probability of introducing bugs during that process seems very high. 

 
Is it worth doing the conversion? Is the existing architecture good enough? And if not, is there an easier, more systematic, or less error-prone way to update the vi's to DQMH?

Thanks, 

David

[Taggart]

You'll want to do iterative refactoring. If you don't have tests in place then you'll want to be extra careful to take small provably safe steps.

I would 

- tackle 1 module at a time ( in fact the first one can be an experiment to see if it's even worth it all and how long it takes).

- for each module create a blank DQMH module and drop the State Machine as Helper Loop. 

- recreate all the I/O messages of the state machine into DQMH broadcasts and requests. Just have them delegate to the JKI State mahine

- At this point you now have a DQMH module that you can drop into your calling app. Yes as of right now it just delegates everything to the JKI State Machine. That is the next thing to fix.

- then one at time start moving the message handling out of the state machine and into the DQMH MHL.

- in parallel or afterwards or you'll have to figure out what makes sense, you'll have to move the state data.

- run the tests often if you have them

- if you have no tests, take really small steps and commit often and do manual testing as often as you can. You may look into Approval Tests, you may find it useful. Depending on how well the code is architected you may be able to get a test up and running in a few minutes. If so, it's definitely worth it.

A DQMH module is NOT a state machine. It is a Queued Message Handler so that changes the paradigm a little bit. Depending on exactly what your state machine was doing, that may be a big deal or it may not. It may be easy to switch the paradigm to DQMH or you might find that it is not worth it at all. 

[FlatCat]

What a great idea, Sam. I will try starting with the state machine in a helper loop. Thanks much, 

David

David Ferster

Lafayette Instruments

[ChrisFarmerWIS]

I want to reiterate Sam's suggestion of using the JKI State Machine in the helper loop.  This has been something I wanted to try at some stage.

And if you want to refactor to use DQMH, and not use JKI State Machine, then I'd recommend you would likely need to create your own state machine within the DQMH Module helper loop regardless, ?

So therefore the JKI State Machine in the helper loop is a good way to go.

[greenfish3]

I agree with Sam and Chris on making a HL out of the JKI SM. It would be a good incremental step.

I've used a JKI SM as a SubVI in the timeout case of my DQMH HLs so that I could take advantage of the browse/explore states and the other right-click stuff the JKI State Machine tool has. (I found that the tool will break if you delete the JKI SM event structure or while loop so I just set the event structure to never timeout and stop criteria to continue if true, since it was already in the timeout case of my HL.)

[drjdpowell]

Just a note, but the JKI "State Machine" is a queued message handler and not an actual state machine, despite it's inaccurate naming.  I would suggest OP develop any new modules with DQMH and interface them with the existing JKI ones. They all just talk with User Events. 

[MichaelAivaliotis]

As a huge advocate of both the JKI state machine and DQMH, I would discourage converting the JKISM code to DQMH. They can both co-exist. In fact I use this design pattern all the time. I prefer using the JKISM for main user interfaces and DQMH for subpaneled or headless code. Try to use DQMH for all new development and slowly migrate as needed. What problem does the existing code have that you are trying to solve?

[FlatCat]

The existing code functions well enough. I could leave it as is. But I am planning to make a lot of changes to the code, and tracing the execution of the various vi that are generating and receiving events is very cumbersome. Modifying the events or adding events is also tedious, whereas DQMH does must of the work for you.