Object Oriented Design Patterns Technical Manual and Exercises

[Elijah_K]

This session will explore how popular software design patterns (ie: Command Pattern and Factory Pattern) can be applied in LabVIEW to develop complex applications that require scalability, extensibility and maintainability. Specifically, we will cover the use of a factory pattern to dynamically load and run plugins within a framework and the use of the command pattern to extend the functionality of a typical queued message handler / state machine. These concepts will be combined to illustrate an example of a object-oriented hardware abstraction layer in LabVIEW.

Summary

This technical manual demonstrates some of the most important object-oriented design patterns and how they can be used in LabVIEW to improve the scalability and maintainability of an application. A functionally equivalent version of the application that was built using a classic producer consumer queued message handler (PC-QSM) pattern is also provided in order to relate the example to a well-known LabVIEW approach.  This application also demonstrates how proper architecture can enable a highly modular application that enables multiple people to work on separate components without impacting or breaking un-related components.  This modularity is made possible by the fact that several dependencies are dynamically loaded at run-time, including the plugins and the images.  In addition, the menu interface was designed separate of this application and is another independent resource.

Revision History

• 10/12 - New version of manual and demos released for LabVIEW 2012.  One installer places everything in the 'Create Project' dialog.
• 7/11 - Updated for NIWeek 2011
  
• 3/11 - Updated for Developer Days 2011

Setup Instructions

1. Requires LabVIEW 2012 or later
2. Download and install the VI Package Manager (VIPM) from here
   
3. Run the configuration file with VIPM
4. Click 'Create Project' from the Getting Started Window

Related Content

• Applying Object-Oriented Text-Based Design Patterns to LabVIEW
• LabVIEW OO: The Decisions Behind the Design
• Hardware Emulation Using LabVIEW Classes (VI Shots)

[NI-hilator]

Oops didn't need to reply to anyone specifically so reposted as general comment:

Any tips on keeping the various plugins loaded instead of swapping them out? Obvious things that come to mind are not unloading when loading a new, ensuring all unload when stopping, determine where/how their front panels will be displayed - a tab control with a new tab for each plugin would make it simple.  I also want a central logging so would be adding a producer-consumer pattern with multiple producers. The goal is a "slow speed" (1 to10 seconds intervals) monitoring/logging app with dynamic (runtime) selection of plugins. Would I be better to start with a different design pattern or framework? Thanks in advance for any insights!

[Elijah_K]

You might check out this link for an example of how to manage that: https://decibel.ni.com/content/docs/DOC-26625#/

[ClassyQ]

Hi,

I am making a determined effort to migrate a particular application of mine over the fence to OO, but I would like to be "hearded" towards using the correct or proper design pattern(s).  This application of mine is a TCP Client app that allows the user to connect to one (1) test server as to display test data in various forms (i.e. tabular, time-histories, gauges, etc.) using a single tab control.  There can be up to ten (10) such Clients logged in at one time.

I have read recently that several folks on NI & LAVA forums advise to move away from the tab control and to use sub panels instead.  Combine that with this web page's neat UI plugin example, I seem to be getting close to finding the proverbial "light switch" in the dark room, but ... it could be something else ....

Some notes:  I do have LabVIEW 2012 at my disposal.  The test server is written in C++.  Down the road a bit we may need to encrypt the XML stream so I may need to put a LabVIEW web service in between the Server and each Client using SSL - if thats a future design bit to note here.

Thank you very much in advance !!!

- (Looking for) Common Sense

[AristosQueue (NI)]

CommonSense: This is a post that I would recommend you post onto LAVA ( http://lavag.org ). The ni.com forums are monitored by a lot of NI folks whose job it is to unstick people from specific problems and point them towards existing documentation. There are a lot more professional G users over on lavag.org who can advise on general open-ended questions like architecture design, the kinds of questions that stay open for a couple months as you work your way through a problem. There are such folks monitoring ni.com, but there's a greater concentration on LAVA. Thus the name... LabVIEW Advanced Virtual Architects. 🙂

When you post, try to put together some information on what you've tried thus far and where you stand in your design process. It'll make it a lot easier for people to answer your questions if you can highlight "I need help with XYZ" than with a flat "I want to design something like this"... having said that, if you really are at such an early stage of design that you're only to the "something like that" phase, there are folks there that may be interested in giving you a hand along.

[ClassyQ]

AQ,

From reading NI Community posts for several years (i.e. mid 1990's) I would have to say that there are several LV programmers who post here who could easily answer the general design decision that I am asking about (i.e. TCP Client & UI Data Display - very simple!).  Hence, I still would like to entertain responses on an NI Community group - this particluar one or another more suitable one.

I will also post my question on LAVA too.

Thank you for your response,

CS

[CharlesP]

CS,

SSL (version 3 = TLS: IETF RFC 2246) is a transport layer protocol implemented in the lower layers of the application layer. If an end-to-end channel exists the XML will be delivered encrypted or not. Both raw TCP sockets and web services can handle encrypted messages. Are you looking at securing the transport channel or the application alone?

Since you are already redefining your system it might be worth investing a bit more time to evaluate the ultimate goal. The stepped approach might mitigate the knowledge gap but in the end it might be more expensive.

Looking at the current implementation, my challenge to you would be:

• If the client side is only displaying the test data in multiple formats why is it limited to 10 viewers?
• What is the advantage of embedding a browser within LabVIEW?
  • Will a standalone browser-based client not be more available?
  • With browser based application the number of clients will be determined by the available bandwidth in your organization for concurrent users without taking away the choice of an Access Control List (ACL) or employing SSL. In this case, the web services can deliver the data from the producer to the client without crossing development domains. Bulk data transfer can be handled by opening up a connection that allows that.

Bottom line, the starting point is re-examining the architecture before looking at the coding paradigm. I hope this helps.

At times the best option is to throw away the hammer. 🙂

CP

[ClassyQ]

CharlesP,

Down the road (3 years +) we may be told by our I.T. folks that our custom, unencrypted XML (EU's) tcp stream that is currently stays behind the company firewall is not good enough in terms of due diligence.  I've heard these non-LabVIEW types are also getting nervous that Shared Variable pipes which are most of the time a flattened string using a custom cluster as the format will also not be good enough (coins are flipping till it comes up a different way ...).  So, a truly encrypted steam will be needed, but not in the near term. 

SSL only came up as my non-technical mananger heard about a different test system (which I have never seen) written in text based coding had implemented a web service but the clients are very simple .asp type web pages.  In the future, I would investigate using or leveraging SSL via a LabVIEW Web Service or use something like symmetric block cipher Blowfish which I have used before on another LabVIEW project. Either way has its pro's and con's per mainly how much coding has to be done on both sides just to have an encrypted stream. 

To answer another of your questions is that the design on the Server allows 10 clients maximum right now.  It can be set to any amount but usually the client side only has about 1-3 viewers so having 10 is far above what we need.  I've tried embedding a browser in LabVIEW but I don't think that is what I'd like to work with now. 

Thank you for all your suggestions/questions.  My focus here is really toward what OO design framwork to use based upon a TCP client and having a UI that is easy (relatively speaking) to maintain such as subpanels and AF.  So, it is more about the UI framework and not so much encryption of the stream.  Sorry to have sent the focus down another path!

Thank you,

CS

[jijing]

Hallo,

I have a problem. I have download your Framework and made a Example Project.

But why the .exe can not exactly run? Can you help me?

thank you

[#10]

Sorry about my OOO msg... deleting it

[PietH]

Hi Elijah,

great Example. Thank you! 

Even so, starting a new OOP project from scratch is not that easy. I need a tip on how to get started.
For years, we have been using software in the experimental area which I have developed with the help of the AMC reference library.

Since the devices often have to be changed or exchanged lately I have to change the source code again and again. Which costs a lot of time.

I would like to do this now with your plug-in concept.

As you can see in the sketch there are 3 device classes. "Patient Monitor", "Ventilator" and "Special Devices".

A setup routine is used to select the device from a pool of devices. 1 patient monitor, 1 ventilator and several special devices.
The devices communicate with the PC via RS-232, LAN, USB or WLAN, depending on the device manufacturer.
With "Start DAQ" the selected devices should be loaded as Plug-In. Every device is already programmed.
With "Store Data", the measurement data of all devices should be stored in a TDMS file.
With "Stop DAQ" the plug-in devices should be stopped and the windows closed.

Can this concept be realized with OOP? Or should I better choose GOOP?

I still miss a push in the right direction. Which classes are useful here? I would be very happy about a suggestion.

I work with LabVIEW 2018 and Windows 10.
Greetings.