How to break application into LVOOP

[JimMacD]

I have a question on how a common use case I have could be broken into Classes/methods.

We do a lot of temperature control here, and run thermal recipes (setpoint profiles). The thermal profile consists of Times, Temperatures, and Ramp Rates.

Multiple “step types” can make up a profile (stored in Array of Cluster), each step type has different characteristic; some hold at a specific temperature for a set amount of time, others have different conditions that have to be met (such as user interaction), before they advance to the next step.

The output from the “profile module” is a setpoint value for the heating unit, and Time Remaining in the step.

I’m wondering how to break this down into classes and methods, it seems like Dynamic Dispatch would lend itself to this.

[PaulLotz]

I think your inclination to use dynamic dispatch is quite sound.  Based on your description I would recommend using the State Pattern (see the Gang of Four Design Patterns book).  The essence of this pattern is that each state is an object, and the system dynamically executes a specific method based on the object type (class).

We have done this with our own systems and it works quite well, and is quite clean and robust.  A really optimal implementation is nontrivial, but once you have such we have found it is quite straightforward to design and implement state-based controllers.

Some basic recommendations I have if you want to pursue this approach are:

1.       Distinguish between external triggers (those that come to the controller from outside, e.g., a user interaction) and internal triggers (things that you check each loop, e.g., holding a specific temperature for a set amount of time).

2.       Use the Factory Method Pattern to create the state objects when you need them.  This can greatly reduce code interdependencies.

3.       Use “interfaces” strategically to reduce interdependencies still further.

4.       Separate concerns as much as possible.  (A calculation class shouldn’t know anything about I/O, loops, or communications.)

In addition you may want to use the Command Pattern to handle sending demands to the system.  Pairing the Command Pattern and State Pattern takes some thought.  I can give you some pointers, though, based on what we have learned.  (We did a presentation at NI Week 2011 that describes our overall approach.)

Finally, if the only variation is the step (i.e., the step algorithm varies depending on the type of test) you may consider using the Strategy Pattern instead of or in addition to the State Pattern.  (These actually have the same form.)  I think, however, that the State Pattern will be the better solution for this task in practice because in reality I think you will find you have lots of state-based behaviors (triggers from various sources, short loops with many possible triggers, etc.).

Good luck!  Let us know what you end up doing!

Paul

[JimMacD]

Paul. Thanks for the input.

I am new to OO design, how much background (realistically) is needed to pull of an application of this size/complexity? You had mentioned that an optimal implementation is non-trivial.

-Jim

[PaulLotz]

Jim,

It's a little hard to answer that question.

As an example, I created a generic component template in around a month, but this was only after several years of O-O experience and project experience.  I was generalizing from lessons learned.

The time it takes will depend somewhat on the complexity and intended purpose (e.g., lifetime) of the system and how much you want to generalize this.  Maybe you will only need to focus on one aspect of design improvement.  (OK, I think you will find yourself wanting to do more once you realize how much more powerful and robust the application design can be.)  It will also depend on what help you can get from other people.

My suggestion is to work from the requirements to design a state machine.  I think then you will have a good idea of what you need to do, no matter which design route you take.  Then you can decide where you might need to focus your design efforts.

Paul

[AristosQueue (NI)]

Jim: The OO course taught by National Instruments walks you through breaking down one application, and it gives you some tools to do the analysis on any application you have in the future. It does take a bit of practice, but the OO analysis is generally considered way simpler than the functional analysis, which is why OO has become so dominant as a software engineering strategy. If you can do the functional analysis, you can do the OO, you just need to have someone hand-hold you through the first one. As I say, the customer education course aims to do this. It's available as a self-paced online course.

[cirrusio]

Hey Paul,

Would you consider putting a simple example of implementing the state pattern in place of a state machine?  I am intrigued - the basic implementation seems straight-forward, but going beyond the most rudimentary example seems to be quite complex (and often language specific).  Specifically, I am curious as to how you might build one centered around a UI where interface items need populating, the user can interrupt a state via UI interactions, etc etc.  I have gone over the DCT presentation but I am definitely missing the point given that there is no presenter there to expand on some of the details given in the slides (and I have no access to the demos).

Cheers, Matt

(I just realized that the original post was similar to a question I had.  David Staab recommended a composition pattern for this case.)

[PaulLotz]

Just for clarification, when you mention "the DCT presentation" are you referring to the NI Week 2012 presentation on the State Pattern?

I may put together an example.  Maybe we could agree on an example problem that would illustrate features effectively.  I will think about what that might be but maybe you have a suggestion.

"Specifically, I am curious as to how you might build one centered around a UI where interface items need populating, the user can interrupt a state via UI interactions, etc etc." We perform all these interactions in pretty much every application.  (I wouldn't use the phrase "centered around a UI," though.  We use a slightly modified Model-View-Controller arrangement.)

[cirrusio]

Thanks Paul.  I actually mean the 100 page tome from 2012 (I believe).  MVCs are great and I have built one with the actor framework, but this approach is not appropriate for every application.  I am selfishly considering my own needs and I have a UI that communicates with a RT PXI chassis over a network via SVs (I think you do something similar with your applications).  Right now, the UI is becoming ungainly and I am trying to clean it up without touching the chassis code and thought the state pattern might be a good approach.

I think a good approach regarding an example might be to take a look at the how we might build a DAQ around a single controller (such as doing some basic data acquisition using a USB multifunction DAQ card on a laptop).  This is a fairly generic and simple scenario that can demonstrate some of the finer points without sucking in the complexities of more specific cases. 

And that's my two cents...

BTW - have you looked at the implementation of the state pattern via the actor framework?

[cirrusio]

Paul, I have to remember to look at LAVA also!  Your description of your state pattern implementation there is enlightening!  It's starting to come together. Matt