Include composition and usage relationships (and maybe others) in class hierarchy window.

[PrimaryKey]

A graphical programming language deserves to have great graphical tools representing the design of big applications.

It is possible to use scripting to understand if a method of a class has another class as input or output terminal and to know if a class composes another class in private data. The only thing I cannot do right now myself is to show this information in Class Hierarchy window. Representing the usage and composition relationships only requires parsing through the project once, and then every time it changes. 

I am right now using a script to parse through all project classes to understand which have what relationships, which are actors and which are messages and I draw a Plant UML diagram from that. The intermediate step is to generate Plant UML text, but this should be integrated into LV.

https://forums.ni.com/t5/LabVIEW-APIs-Discussions/Project-to-Plant-UML-Diagram-Script/td-p/3984499

Please improve the readability of object oriented project with additional tools for LabVIEW. This is especially critical for NXG, where the currently the ability to understand an OO project is even more limited than LV19.

[wiebe@CARYA]

Before someone mentions OpenGDS as a solution, I agree this should be in LV.

[PrimaryKey]

Another reason why GDS is not a solution is all the baggage that comes with it. I do not want my classes to be GDS classes. I also don't need to create an architecture from UML. I just want to see a diagram for readability and understanding. 

[wiebe@CARYA]

(I'm on your side, but) I've been told OpenGDS also works fine with normal classes. The baggage is still there of course.

I just don't like to depend on things that aren't always available.

[thols]

I agree (or maybe not, I cannot decide), but I believe NI have said that they will not be making these things but rely on the community (when it comes to NXG especially). For NXG, NI has partnered with VITechnologies to make their UML addon. It is looking really promising.

For CG, I think we can completely forget that anything like this will be made.

I will not mention GDS, instead I can mention the G# uml plugin if you want something else for CG. It generates whitestaruml class diagrams and it works for native classes too. (The info on LVTN is old and there was an issue with generating a VIPM package so check www.addq.se/gsharp or the forum)

If there will be another community effort, I would prefer to have compatibility with external uml editors, like e.g. StarUML (the new one). I would both prefer sketching in a dedicated uml application, as well as getting the analyzed code to uml in a dedicated uml application. But I'm not sure, since I think VITechnologies implementation might be good enough.

[TiTou]

As much as I agree with the need for such a tool, I don't think NI will be inclined to put resources on this because of the existing tools : GDS & G# for CG and VITechnologies's tool for NXG.

[wiebe@CARYA]

The idea is not about adding a UML editor, but about simply drawing some lines.

I like the completeness of StarUML, but the problem is the closed character. Non just the code, but the information. I gave up trying to find out if it supports a open standard (xml or such). Closed source software is usually closed in other aspects.

[TiTou]

I'm not sure now... what is it you call "Closed source software"? LabVIEW or StarUML?

[thols]

@ Wiebe " I gave up trying to find out if it supports a open standard (xml or such)"

- XMI is the second most popular extension to StarUML. 

I would also prefer open source though. 

[wiebe@CARYA]

>I'm not sure now... what is it you call "Closed source software"? LabVIEW or StarUML?

Both are. The new StarUML, not the old one.

>I would also prefer open source though. 

WhiteStarUML looks promising. Another old StarUML spin-off.

Xmi is OK, and I actually have xmi generating code that did work with some tools, but not with (White)StarUML. Guess I have to read the manual (all 794 pages). Even when it worked, I didn't get the full potential of the (undocumented) native file formats.

[AristosQueue (NI)]

NI's position is subject to change and revision as we get different pressures from customers, but in recent years, for LabVIEW 20xx, the position has been:

1. The complete map of relationships among classes gets very complex.

2. There are many different "standard" views of these relationships.

3. Different users give us very different declarations of which relationships are important.

4. We have third-party tools that can display these relationships and allow for customization of the views. Those tools are FREE.

Because of this, we have been reluctant to add such functionality to LabVIEW 20xx. I do not expect us to change this policy, but we might if there were enough pressure from users -- I expect that the introduction of interfaces in LV 2020 will change the calculus of what is important for various users, but I don't know how.

I have supported the OpenGDS, NI-GDS, and G# as tools because they solve this problem so well for the customers that want this kind of tooling.

LabVIEW NXG has those tools being built by the community as well.