Follow-up questions from "G Interfaces in LV 2020" webcast (May 1, 2020)

[egraham]

Stephen, your reply is really helpful. This kind of discussion helps with my understanding.

As for UML, over the years I have reread the class relationship descriptions countless times because, like you said, it's confusing. However, I don't believe this is the fault of UML so much as it is the fault of software. In software, the components we build and the relationships between them are often complicated. I don't think it helps the situation to avoid exposing people to this language (UML). G users have the same types of architectural decisions to make as users of other languages so we need to study UML until it begins to make sense to us.... or until someone comes up with something that can better describe these complex relationships. I can't think of anything better at the moment.

I have been brought on to large projects where the UML is either non-existent or hasn't been kept up to date, and it's much more challenging than a project where someone has UML that accurately reflects the state of the project.

I updated the diagram as you suggested so now we have some arrows that point up and a sideways pointing arrow. As you stated, there are no cycles. I would like my dependencies to be drawn below the classes that depend on them, but I suppose that's just my attachment to an aesthetic that serves no real purpose.

In typical LV apps, I tend to model the device-under-test as something that I pass into sensor and control classes. Others invert that. As long as you're consistent, everything works out.

This is really the most helpful point you've made. Different developers choose to model systems differently, but both models can be valid ways to represent a system.

Best regards,

Eric Graham

[AristosQueue (NI)]

---

@egraham wrote:

I would like my dependencies to be drawn below the classes that depend on them, but I suppose that's just my attachment to an aesthetic that serves no real purpose.

---

That attachment serves a valid purpose -- visual confirmation that a hierarchy is cycle-free is relatively easy for humans to do. It's not a bad thing to desire. If the LV Class Hierarchy diagram were drawing all the relationships among classes, then that would have pushed Box down lower. LabVIEW does not ship with a tool to render all of those relationships. We support various add-on tools from other vendors that provide full UML support. (None of those tools are yet updated, to the best of my knowledge, to account for interfaces, by the way, but I'd expect movement on that over the next year.)

[CaseyM]

---

@AristosQueue (NI) wrote:

---

@jsiegel wrote:

I don't have that option.  Is there something I need to do to enable it?  I do already have an actor in my project.

---

Works for me. I tried several variations. Anyone else having this difficulty?

---

@jsiegel wrote:

Note that the slide also shows a menu item for creating a new XNode,

---

Ah. I forgot to turn that off. Good eye! But -- correct -- that's not a released option.

---

I don't see this option either. I've tried it from the example project and from my own.

[jsiegel]

---

@CaseyM wrote:

---

---

I don't see this option either. I've tried it from the example project and from my own.

---

Even on the full version of LabVIEW 2020, I don't see the option.

[CaseyM]

---

@jsiegel wrote:

---

@CaseyM wrote:

---

---

I don't see this option either. I've tried it from the example project and from my own.

---

Even on the full version of LabVIEW 2020, I don't see the option.

---

In case it helps, I'm using the 64-bit pro version.

[wiebe@CARYA]

XNodes development requires an XNode license. This is not publicly available. So, NI only.

The XNode license works exactly like the scripting license, before it opened up.

[CaseyM]

Sorry, I was talking about the "Interface for Actor" option, not XNodes. 

[wiebe@CARYA]

---

@CaseyM wrote:

Sorry, I was talking about the "Interface for Actor" option, not XNodes. 

---

Ah. My brain automatically removes everything 'actor' related 😊.

[JimB.]

---

@CaseyM wrote:

---

@AristosQueue (NI) wrote:

---

@jsiegel wrote:

I don't have that option.  Is there something I need to do to enable it?  I do already have an actor in my project.

---

Works for me. I tried several variations. Anyone else having this difficulty?

---

@jsiegel wrote:

Note that the slide also shows a menu item for creating a new XNode,

---

Ah. I forgot to turn that off. Good eye! But -- correct -- that's not a released option.

---

I don't see this option either. I've tried it from the example project and from my own.

---

Same here. I also cannot see the "Interface for Actor" option.

(Running LV2020 32-bit Pro Development System)

[jordankuehn]

I've been reading and did watch the live presentation, but I still have a question that I think should be straightforward. I have an AF Actor that can potentially have a couple types of callers. I would like to report its status to its caller and can do that just fine if it knows what type of caller it has. The issue is wanting to send the same message and having the caller know how to interpret it. The Low coupling/Zero coupling problem yes?

Now Interfaces are supposed to help with this correct? The previous way you would address this in a low coupling method would be to have all types of callers inherit from an empty common parent that has all the methods that are common that I would want to invoke via a message defined in the ancestor and overridden by each caller. It it accurate that this is a problem when the callers would prefer to inherit from something else and makes the inheritance tree messy? So then to use interfaces to make this better I would create an interface that holds the common methods, *and then* I would generate and call messages to the interface's methods and not the caller's?

Or have I bungled it all up? That's what I get for not digging into this when the live presentation was happening. Thanks!