Search the Community

I am posting this in the Application Design and Architecture forum instead of the OOP forum because I think it fits here better, but admins feel free to move the thread to the appropriate spot. Also, I am posting this to LAVA instead of the AF forum because my questions relate to all Actor Orientated Programming architectures and not just AF. Some background, I looked at AF and a few other messages based architectures before building my own. I stole liberally from AF and others to build what I am using now. But I am having a bit of a crisis of confidence (and several users I am sure will want to say 'I told you so') in the command pattern method of messaging. Specifically in how it binds all actors in your project together via dependencies. For example: If Actor A has a message (that in turns calls a method in Actor A) to create an instance of Actor B, then adding Actor A to a project create a static dependency on Actor B. This makes it impossible to test Actor A in isolation with a test harness. The recent VI Shots episode about AOP discussed the need to isolate Actors so they could be built and tested as independent 'actors'. If Actor B also has the ability to launch Actor C, then Actor C also becomes a dependency of Actor A. And if Actor B sends a message to Actor A, then the static link to that message (required to construct it) will create a dependency on Actor A for Actor B. So, the end result is adding any actor in your project to another project loads the entire hierarchy of actors into memory as a dependency and makes testing anything in isolation impossible. This is the effect I am seeing. If there is a way to mitigate or remove this issue without abandoning command pattern messaging, I would be very interested. In the meantime, I am considering altering my architecture to remove the command pattern portion of the design. One option I am considering is to have the generic message handler in the top level actor no longer dispatch to a 'do' or 'execute' method in the incoming message class but instead dispatch to an override method in each actor's class. This 'execute messages' method would then have a deep case structure (like the old QMH design) that would select the case based on message type and then in each case call the specific method(s) in the actor to execute the message. I would lose the automatic type handling of objects for the message data (and have to revert back to passing variant data and casting it before I use it) and I would lose the advantages that dynamic dispatch offers for selecting the right message execution code. I would have to maintain either an enum or a specific set of strings for message names in both the actor and all others that message it. But I will have decoupled the actor from others that message it. I think I can remove the launch dependency by loading the child actor from disk by name and then sending it an init message to set it up instead of configuring it directly in the launching actor. I guess am wondering if there other options to consider? Is it worth the effort to decouple the actors or should I just live with the co-dependency issues. And how does this affect performance? I suspect that by eliminating all the message classes from my project, the IDE will run a lot smoother, but will I get a run-time performance boost as well? Has anyone build systems with both types of architectures and compared them? I also suspect I will get a benefit in readability as it will be easier to navigate the case structure than the array of message classes but is there anything else I will lose other than the type safety and dispatch benefits? And does anyone who uses AF or a similar command pattern based message system for AOP want to try to defend it as a viable option? I am reluctant to give up on it as is seems to be the most elegant design for AOP, but I am already at 326 classes (185 are message classes) and still growing. The IDE is getting slower and slower and I am spending more and more time trying to keep the overall application design clear in my head as I navigate the myriad of message classes. I appreciate your thoughts on this. I think we need to understand the benefits and pitfalls these architectures present us so we can find a better solution for large LabVIEW application designs. -John

I try to build an executable out of a program that is fully functional under the development environment (LabVIEW 2011, Linux). The executable complains that one of asynchronously launched VIs is bad because one of its components cannot be found. The VI does not invoke any sub-VI dynamically. To identify the problematic sub-VI, I use the following code: A new executable was build including this code and the VI under investigation. A run results in the following error: Possible reason(s): LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS X, and / on Linux. Verify that the path is correct using the command prompt or file explorer. VI Path: /opt/***/Builds/Debugg/Debugg_GetDependencies/SubVIs/*** - Plots & Parameters.vi/0 Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library. LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets. /opt/***/Builds/Debugg/Debugg_GetDependencies/SubVIs/*** - Plots & Parameters.vi/0 The same mysterious path is indicated in the indicator "Array" with Execution State “Bad”. The corresponding name in the indicator “Dependency Names” is “*** - Plots & Parameters.vi:Instance:0”. So, I tried to run the same debugging code under LabVIEW development environment and got the same error (while the program works without any complains under LabVIEW). What could be the reason? Had any of you solved such a problem? Thank you