From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UML class relationship implementation in LabVIEW

Solved!
Go to solution

Hello all,

 

Can anyone suggest me how to use below UML class relationship in LabVIEW Class.

 

VipinrajKK_0-1586705389608.png

 

 

I know below relationship and how to implement that in LabVIEW.

 

Generalization - Inheritance

Composition - Using a class instance inside the private data of another class.

Dependencies - Using a class method inside the method of another class.

 

 

What about association ,Aggregation ,interface and Realization?

 

 

 

Vipinraj KK

CLA.png

 

 

0 Kudos
Message 1 of 6
(2,923 Views)
Solution
Accepted by topic author VipinrajKK

Ok, this is quite a question... Hope this is helpful. I'm not 100% sure about the C++ comparison (is it an abstract or virtual or pure virtual interface?), but pretty confident about the rest.

 

Dependency

 

This would be a VI (in a class) that uses a class. There would be a dependency between the classes, but no aggregation.

 

The class could be an input of the VI, but that isn't required. For instance, a VI can use a utility VI from a utility class.

 

Aggregation\Composition

 

This would happen when you put a class B in the private data of another class A. Class A would be composed of Class A (and optionally others).

 

The difference between Aggregation\Composition is more significant in other languages, AFAIC. It's about who is responsible for creating and releasing the contained object. We don't have to worry about that much in LabVIEW (as long as we work by wire\by value).

 

Inheritance\Realization

 

Realization is a reason for Inheritance. Extension is another. Specialization is one too.

 

In C++, a class will often "realize" an interface. In LabVIEW, an interface is a bit different. You're not able to make an virtual interface like in C++, one that can't be instantiated. Interfaces won't be available until LV2020.

 

However, realization is still a reason to make a child, and can be specified like that in UML.

 

Interface

 

In LV2020, interfaces would allow you to get run time polymorphic behavior, without inheritance.

 

LabVIEW doesn't allow multiple inheritance, for good reasons. Sometimes you still want to throw a bunch of unrelated classes in an array, and call a method they all share. That's when you'd need an interface. So each class that has a "store" method can put in array of a "storage" interface class, as long as it implements the "store" method. Inheritance would require all classes to inherit from the same parent.

 

For "storage" that is doable, but you might have a "visualizer", "sound output", "whatever" interface as well. So with inheritance, and without multiple inheritance, you'll end up with a) a super parent, implementing everything, b) a "visualizer" inheriting from "sound output", inheriting from "whatever", or c) all classes containing "visualizer", "sound output", "whatever". Interfaces will solve that.

 

Until we have interfaces, .vims (malleable VIs) implement static polymorphic behavior. Interfaces will give us run time polymorphic behavior. A malleable VI will adapt it's input to the wired class, and change the method that is called, to what is wired to it. The interface of the method doesn't even have to be the same, as long as it doesn't break the .vim. However, it won't be able to adapt to a class\object at run time. So it doesn't work for an array of classes. An array of unrelated classes will result in an array of LabVIEW classes (but the objects are still the original objects), and the .vim won't be able to call a method on a LabVIEW object (because it doesn't have methods).

Message 2 of 6
(2,855 Views)

Thank you  

 

 

 

 

 

 

 

 

 

0 Kudos
Message 3 of 6
(2,832 Views)

I'd say (only based on intuition and the limited amount of information) that a Devices uses Inter Process Communication.

 

But, if the Device is an entity running on it's own, or uses Inter Process Communication everywhere, it might make sense to put it in Device's private data.

 

So the first seems better, more natural. But the second can not always be avoided.

 

BTW. What you're doing is one of the hardest things to do. It only makes sense if you have an application where everything needs to be flexible at runtime. Or if you're going to use this over and over again in different setups. If all hardware is static, I wouldn't aim for the holy grail (the one and only HAL that solves all problems that will ever exist). At least not straight away. Not saying you're doing that, but being pragmatic is the way to get things done (in time).

Message 4 of 6
(2,820 Views)

The Device class is running its own.

I have below three methods in that 

 

Device Preint

Device Function

Device StopCore

 

The start of my Application ,

 

Each Devices will be executing a Device Preinit  method , where I will be creating all Inter Process communication for that device.

For Example: If my Device is a M Series Card ,which is having AI,DI and DO. For this device I will initialize 3 inter process communication and update the communication reference to that device object.

 

After that I will Launch Device Function Method of that device

 

Once Device Function Method is launched, based on device type, It will Start Acquire or Generate or Wait for command from other part of the code.

If the device is for acquiring the signal, it will update the acquired values (Channel Values) to Inter process Communication (Notifier or Queue or DVR)

If the device is for Generating the signal , It will read the Data from Inter Process Communication (Notifier ,Queue or DVR) and update to respective channels.

a Device can have all the functions like Analog Acquisition ,Digital Acquisition and Analog Generation Digital Generation and Etc.

 

These Device communication reference is used for other operations , like getting data from a particular device and comparing some channel values or Generate the value in some channel of a device based on some conditions.

0 Kudos
Message 5 of 6
(2,803 Views)

It seems to me you're taking the right steps (OO Analysis, OO Design before OO Programming).

 

With OO, as long as you think things out before starting to program, the sky is the limit, really.

 

The only caveat it that you get (exactly) what you designed. Taking the next step can be incredibly hard, if the design didn't anticipate that step. Guess that is even worse without OO, though 😁.

Message 6 of 6
(2,784 Views)