LabVIEW Development Best Practices Discussions
Converting an Activity Diagram to an OOP Pattern
Solved!
Hello all,
I thought I might throw this out there since there are people here more knowledgeable in using OOP patterns. I have a system that currently runs through a cycle for an autocalibration in the midst of operation. Currently, the entire system is built off of a queued state machine and after data acquisition, the system checks to see what the current mode is, i.e. has the user specified that the system should be running through a series of calibration steps? If the user has specified that the system should be calibrating, then the system should run through a series of steps based on time. This means that, while in calibration mode, after data acquisition is complete the code will roll around and check the current time and then adjust certain parameters such as temperature and flows based on the current time and the previous state. Currently, I accomplish this through a single functional global variable (attached) which will maintain a record of the current state. It's messy and difficult to understand given that there are two different cycles with different patterns in the calibration procedure (one running within the other). Now, the end user wants to change this and have two different calibration modes. Below is an activity diagram for one of the modes.
You can see that there are two different cycles running in this (labeled Big and Small) with one running within the other. For the sake of maintainability (you can see a lot of case structures buried in this thing), I was considering using OOP to run through the cycles. Would this be inappropriate (based on the garbled description of use above)? What pattern might be most useful (I was thinking a State Pattern)?
Any thoughts would be much appreciated.
Cheers, Matt
My advice: Ditch the supposition that you should use any formal OOP Design Patterns, and just figure out the best design for your refactoring project's goals. When I first read a couple of books on design patterns, I wasted a lot of my employer's money trying to shoehorn them into every project I was assigned. Over time, I've come to realize that they're called "patterns" because they're general representations of a way of solving coding problems that "most" people eventually discover on their own. They're not canon, and each pattern comes with a bucketful of caveats for its implementation under various constraints. These days, I get the most use out of my copy of GOF by recognizing when I've written a chunk of code a certain way, then comparing it to the reference material to see if there are any performance/maintainability tweaks I can apply to that implementation. All this is ex post facto: if I try to consult the reference first, I lose the ability to follow inspiration in my design and end up trying to force the code to look like what I read.
Stepping off my soapbox, I recommend this (re)design approach: You have a composed set of sequences: the "small cycle" is a sequence of steps, and the "big cycle" is a sequence of sequences. You can model this very well by defining a Step class and a Sequence class that inherits from it. Let the Sequence class compose an array of Step objects. Since a Sequence inherits from a Step, you can put a Sequence inside another Sequence to nest them. This is a common implementation of a data tree, and it works nicely for defining composable automation sequences:
- Big Cycle: Sequence
- Check Filter: Step
- Small Cycle: Sequence
- Set O2 Flow: Step
- Check Bypass: Step
- Check Spk: Step
- Set T: Step
- Check Temperature: Sequence
- Evaluate T: Step
...and so on.
Honestly, I don't see any instances of statefulness in your diagram. Maybe it's not giving the full picture, but I'm pretty sure everything in this automation uses input values to generate output values or transition decisions immediately, with no need to change a step's behavior based on some state variable.
Note: It looks like you described a few transition criteria as if they were steps: Filter == TRUE, Bypass == TRUE and Spk == TRUE. What happens if any of those is FALSE?
Note 2: you forgot to attach your FGV. 
Arrrrggggh! Just spent the past (insert long period here) trying to respond to this post and broke the thing by clicking on advanced editor thus losing everything! Sigh....
Ok - in response to your soapbox: With my work, I have ample time and opportunity to invest in refactoring (a luxury for most). I see trying to figure out how to apply patterns as helping me along the way with my own design and development. Inheritance and abstraction are awesome, but being able to understand how to apply an OOP pattern takes OOP to that next level - OOD. I have had several instances where I have mucked around for a while trying to come up with a solution amongst a myriad of them only to hit the gas and go with my "inspiration" discovering later that there was a better and more obvious solution that would have helped me maintain and potentially reuse the software (I gave a presentation to that effect at a recent CLD summit). Here I am trying to do what you talk about - I have a package of code that I have developed (and it serves the current purpose well), but I have the opportunity to reconsider the design potentially making it better and in the process improving my own skills. I was hoping that, based on the pattern, something might jump out at me as similar. Now on to the topic....
You beat me to the punch in your response. You are correct - there are no readily identifiable discreet states. However, there is a state that needs to be maintained and this is the state that answers question - where am I? We need to know currently where we are in the cycle to know how to proceed to the next step. For instance, if we just completed the "Big Cycle" then we need to know if that was the last set of data we need to cycle through. If it wasn't, we will need to do all of those steps you have outlined above (which can be done in parallel, but that is beside the point) and then wait for the current T to equal the Tset. Once it does we begin to step through (for certain periods of time) all of the small cycle steps and then repeat. To be honest, your suggestion is probably good but I don't fully understand it. How does the system know exactly where to go if you have to act on certain conditions (in this case time and temperature - T)? Aren't these part of a state data that must be maintained? I guess that we could maintain a list of commands that must be executed (Change Spk, Change Flow, etc.), but 1) this seems cumbersome and 2) a still can't see how this is done with out having some state data associated with the cycle.
Rethinking what I put up, I think the action states such as Spk = False, Bypass = False (forget the == which is a test for equivalency; these are actually commands) and Set O2 Flow should be signals that are sent out to change a value. Considering that these are actually commands that will be sent to the instrument, I think I could model the class design like this:
The actual implementation of the class State is meaningless to you - but suffice it to say that we have two different implementations of those cycles (Big and Small) that you suggest be an overarching Sequence class. I guess you could say that your Step class here is represented by Command. This is obviously different than what you suggested - here I maintain the state of the sequences using my state class (this will keep a record of the details of how we want the sequences to run as well as where we are in the cycle). When we go to check the current state condition and find that it is time for the next, we issue a command based on 1) what kind of sequence we are and 2) where we are in the sequence (represented by the Command class). But I am still not sure about the actual implementation.
Thanks for taking the time to respond to all of this, David. It is always nice bouncing ideas off of someone more knowledgable than myself. I will see if I can get that VI up (can't seem to find the "Attach file" button anywere...)
Matt
mtat76 wrote:
Arrrrggggh! Just spent the past (insert long period here) trying to respond to this post and broke the thing by clicking on advanced editor thus losing everything! Sigh....
Years of providing tech support on forums.ni.com taught me to select all text and copy it to the clipboard before every clicking "submit" on a web form. 
To be honest, your suggestion is probably good but I don't fully understand it.
Start with this pattern, then tweak it to meet your application's needs: https://en.wikipedia.org/wiki/Composite_pattern
How does the system know exactly where to go if you have to act on certain conditions (in this case time and temperature - T)? Aren't these part of a state data that must be maintained? I guess that we could maintain a list of commands that must be executed (Change Spk, Change Flow, etc.), but 1) this seems cumbersome and 2) a still can't see how this is done with out having some state data associated with the cycle.
I have to approach two disctinct topics at once to respond here, and I should take this opportunity to warn you that I was never formally trained in the language of Computer Science; I may misspeak or reassign the meaning of a term on accident. (1) When a fork or loop needs to be added to the sequence, you'll have to evaluate a condition to decide which step/subsequence to execute, whether to loop or break, etc. You can create a step to make this evaluation, or you can embed the evaluation logic in a method of the executive class (which would define the program that's running this automation sequence). Now the evaluation of conditions is a fixed behavior in your application diagram, so that input values are used to generate a decision in an explicit manner. (2) Statefulness affects behavior, not data. An object's current state is described by unique data, so sometimes that fact can be confusing...but the purpose of defining and storing state data is to evaluate which behavior an object should use when responding to a method/command/request. So if your decision behavior -- how it manipulates input values to determine its outputs -- never changes, then there's no need for statefulness in the decision step.
As for it being cumbersome to create unique objects for every action that your automation executive takes...I don't know a better approach to modularizing an automation sequence. As supporting material, I provide NI TestStand to the court, which uses this approach to define modular sequences for test automation. Every action in TestStand either is a step or a (sub)sequence.
I'd like to respond to your diagram in detail, but I have a date. It is Friday, after all. 
Here is just a quick class diagam of what I would have done, without knowing too much of your requirments.
paul.dct wrote:
--even if the revised approach in that session fell short of an ideal implementation. (The State Pattern would have provided a better answer; the solution in the presentation nevertheless makes several key steps forward.)
That's the exact same thing I thought after the presentation. Norm and I spent some time talking about it afterwards and he's almost on board with the State Pattern.
OK, so I took David's idea and ran with it and here is the resulting class structure:
I apologize that it is difficult to see, but you can get a general idea of the structure from the wiki entry for which David provided a link above. The main difference lies in the concrete classes for the leaves and sequences. In addition, I have a SUB class which represents subsequences.
Some points about my realization of this pattern:
- The SEQ class represents a sequences of steps and is therefore composed of at least 1 STEP. Instances of the STEP class are stored in a queue. I am sure that you could do this multiple different ways, but this is the approach I took.
- All classes have to override the abstract execution method. Since the SUB class is just a sequence called by another sequence, the call to this method is recursive.
- Execution of steps may occur over multiple calls - this allows me to interrupt processes that might ordinarily occur over multiple iterations (such as waiting for a timeout).
- Messages regarding sequence execution are returned via a user event.
I realize that my interpretation is not necessarily the best. One weakness is the use of a queue for maintaining a sequence of steps. While I can add elements at the beginning or end of the queue, if I want to insert a new step at another location, the code would require substantial jiggering.
Anyway, thanks for your help. This has worked nicely and in the case of calibration sequences is probrably superior to the use of a state pattern. That being said, if the state of the system can not necessarily be determined prior to runtime (i.e. the next step queued depends on the results from the previous step), some implementation of the state pattern might be best.
For your edification, I have attached the base code to the original post (i.e. that which is not implementation dependent). Let me know if you have any questions, comments or suggestions. Cheers, m
