Random Ramblings on LabVIEW Design

So back from the Paris CLA summit full of ideas and material, saw some superb presentations (Kudos to all!) and had some very interesting discussions and debuted my new line in Mildly Offensive Corporate Wear.

One of these discussions occured about 4am after a few beers and made me go back and do some research. It is showed up something I've been troubling myself with for a little while now and it all centres around encapsulation.

Encapsulation Defined

In programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:

• A language mechanism for restricting access to some of the object's components. (data encapsulation)
• A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data. (functional encapsulation)

As an information hiding mechanism

Under this definition, encapsulation means that the internal representation of an object is generally hidden from view outside of the object's definition.

A benefit of encapsulation is that it can reduce system complexity, and thus increases robustness, by allowing the developer to limit the interdependencies between software components.

So for this blog we will be looking at a Power Supply Unit as an easy reference point.

In Traditional LabVIEW you'd have a palette.

I've stored them in a LVLIB....

So do we have encapsulation because the VIs are in an lvlib? -->correct answer is no, but we're getting better.

So how about LVOOP PSU Class (this is going to end in a heated debate)

Well is this encapsulation?-->correct answer is no, but we're getting better again, this has got data encapsulation, i.e. you can only get to the data via a method.

We are interested in functional encapsulation where it is a language mechanism for restricting access to some of the object's components.

From our design perspective.

Block diagram A gives no better encapsulation than block diagram B below

This is still functional decomposition.

Our method of encapsulation is similar to the design of the OO language Smalltalk.

When an object receives a message, a method matching the message name is invoked.

http://en.wikipedia.org/wiki/Smalltalk#Methods

So when we keep banging on about wrapping stuff up this is one reason why!!

So here's our implementation

This is functional encapsulation, there is a PSU VI (action engine), the implementation may be LVOOP, standard LabVIEW, dlls, activeX or anything else. The implementation details are hidden. Scaleability is also an implementation detail. This VI would then be called by higher level action engines, say for example a Test System vi.

Now the arguments are why put in the extra effort of wrapping everything up like this. Our view is that the block diagram is the mechanism for navigating and understanding the sourcecode, only the items pertinant to solving the problem are visible. If you want to change the order of the methods you just need to change the messages, or you can drive them from files etc etc.

Hope this helps

au revoir
Beaucoup d'amour

Steve Watts