LabVIEW
OOP Design Decisions + Inheritance
Hi all,
Thanks for the valuable input on the last thread, linked here: http://forums.ni.com/t5/LabVIEW/Is-LabVIEW-OOP-mature-enough-for-large-applications/m-p/3297360
I'm going to go into a little more detail in this post, and hopefully someone can tell me places where I could improve.
The three applications I'm referring to are all biological control systems. The first is a SingleSimulator, made so that you can run and analyze individual simulations of the controller against some model of the biological system. The second is a DatabaseSimulator, made to pull simulation jobs from a database, run them, and commit the results via parameterized queries. The DatabaseSimulator and the SingleSimulator both run on top of the same model, the difference is a slight modification in the underlying state machines + error handling. The third and final application is, you guessed it, RunHardware. In this application, instead of interfacing with a model, the controller is interfaced with a set of pumps via serial communications.
My current class hierarchy goes something like this:
- Mode.lvclass, ancestor class for the three applications. Each child will have DIFFERENT block diagrams, but the same base state machine.
--RunHardware.lvclass, block diagram uses producer/consumer design to handle acquisition of sensor data and processing for use in controller, as well as state machine within consumer loop. Simple UI allows you to specify pump locations, system characteristics, sensor locations etc.
--Simulator.lvclass, ancestor class for the two types of simulators
---DatabaseSimulator, block diagram is a state machine with events, with an extra state for error handling and recovery (loss of network connectivity, deadlocks while inserting, etc). Database configuration information is in a udl file specified within a config file.
---SingleSimulator.lvclass, also state machine with events, but a fairly rich UI used to customize the simulation deeply.
Separately, we have ControllerType.lvclass, which will allow for more than one controller to be dropped in; useful for pitting controllers against eachother in large scale simulations using DatabaseSimulator.
My current setup is to have a ControllerType class as the private data of Mode, and this allows me to put different modes with different controllers without creating a class for every combination (which seemed against the point of using OOP in the first place. Picture:
Here is how I have set up the mixing and matching:
This seems to work well, albeit a little strange in the state machine. Here is the base state machine for Mode:
This seems to work, except you get structures like this in states where your controller is supposed to do stuff:
First question, is this supposed to be what things look like when you take an OOP approach? Or is there some better way to handle this? It's only structured this way because Mode and ControllerType are separate classes. Mode specifies how things are structured on an application level, ControllerType specifies how things are controlled on a system (referring to the control system, not the OS) level.
----
Another issue I'm facing is how to have different models for use in the Simulator classes. We have a base model, which essentially solves a vector valued DE using RK4 approximation, but we'd like to have support for more models in the future, all while still maintaining the ability to "mix and match" different modes, models, and controllers. Here's what I think this would look like:
However, I want the Model VI to "dynamically dispatch" based on the config for the model specified in the config file/User Input. The problem I see is that The Model VI doesn't need to be overridden by the DatabaseSimulator or SingleSimulator classes (in fact this would break the "mix and match" idea), it just needs to be available in several forms. Is it as easy as creating a Model class, with subclasses for different models? The idea being that I would then include the Model class in the class private data of the Simulator parent class, similarly to how I did it with Mode and ControllerType:
Of course, I could be overthinking this, and I simply need to read from the config file to see the model the user wants and use a simple case structure.
Forgive me if these are simple questions about OOP design, I'm doing this project on my own and don't have much experience in the design phase of OOP.
