Showing results for 
Search instead for 
Did you mean: 

An UML modeller issue to reverse engineering a project

Hi guys.

I am tackling to read a huge project, which is produced by previous researchers.

Unfortunately, since old researchers didn't remain documents, I try to make block diagram to understand the relationship between each VIs.

UML modeler seems useful for this purpose but reverse engineering function of UML modeller stop with error when I targeted a top VI in my project.

The error mentioned as attached picture.

I imagine that my project is too large for UML modeller and it stopped.

Do you have good idea to run UML modeller on huge project?

0 Kudos
Message 1 of 7

I have had some experience trying to understand, maintain, and improve large undocumented LabVIEW Projects.  Particularly if you are doing this largely by yourself, this can present quite a challenge.


You describe using a UML Modeller, but fail to describe where/what this is.  A Web search did not show me any really obvious candidates -- I could find no reference for LabVIEW-related software after about 2010, so I can't really comment on the (unknown-to-me) Tool that you are using.


My own approach was two fold -- first, try to get a good understanding of what the software was designed to do.  This entails understanding all of the Required Inputs (things to be measured), required Outputs (recordings to be produced, graphs and indicators to be presented, and things to be controlled), and the general "flow" of Program Operation (in broad terms), along with any other requirements (such as necessary Sampling Rates),


The next Step is the most difficult, but also the most important -- once you know what the Program needs to do, you need to abandon the old code and "Start Over".  The best way to do this is to start writing the Documentation, describing the things you already know, namely "What does the Program Do", "What are the critical Inputs and Outputs", "What (in broad terms) is the Program Flow".


Now pick one or more Design Patterns.  In recent years, I've adopted architectures based on State Machines, often resembling the Queued Message Handler (take a look at the DQMH, available on the LabVIEW Tools Network).  If you have a good understanding of "What" you want to do, you can start coding the top levels (I often have States called "Init", "Get Input Parameters", "Set Up DAQ", etc.).  Put off as long as practical the "How" questions -- these are "details" you might not need to decide on yet.


Do you know about Good LabVIEW Style?  Particularly if you are going to be the Architect of a large LabVIEW Project, you need to write LabVIEW code that will be easily understood six months after you finish writing it, both by another LabVIEW Developer (in case you are not available) or by yourself.  The most influential LabVIEW book I ever read was "The LabVIEW Style Book", by Peter Blume, which emphasized that Good Style is important in producing Good LabVIEW Code.  Some key principles:

  • Every Block Diagram should fit on a single Laptop Screen.
  • Use Sub-VIs to "hide the details".
  • Every VI needs an Icon.
  • Every VI needs a Description that says (briefly) what the VI does and describes its Inputs and Outputs.
  • Top-Level VIs benefit (greatly) from a recognizable Design Pattern.

Good Luck.  One other piece of advice is to have a "collaborator" with whom you can discuss your Project.  They do not need to know LabVIEW, but should have some idea about programming.  If you can't explain what you are doing, then you need to rethink, simplify, reorganize your thoughts, rewrite the Documentation (I went through several drafts), and try again to explain.


Bob Schor

0 Kudos
Message 2 of 7

Thank you for your kind message.


The exist project using state machine method and it controls two set of full pxi chassis with high speed.

I noticed that I still not understand part of operations and that makes me annoying.

Fortunately, one other researcher knows how to operate of the project so I am asking the usage to him.


By the way, UML modeller is a tool of Goop Development Suite.

I also tried "VI hierarchy" of labview tool but results seems chaos since the project is too huge. I imagine that if I can specify the depth of showing a hierarchy, hierarchy map might be readable but I cannot find the setting of limiting the depth.




0 Kudos
Message 3 of 7

The problems you are describing, a large, complex, undocumented LabVIEW Project, possibly "thrown together" without being properly designed, is the reason I recommended that you "Start Over, beginning with Writing (Some of) the Documentation First".  Again, concentrate (in the initial design/documentation phase) in describing What you want to do.  Since you have two PXI chassis, I'm assuming that this is a LabVIEW RT Project with two Targets (though one of your PXI's may be doubling as the Host -- I think I would advise against that), knowing the Duties and Responsibilities, including Data Rates, "Who is in Control of What", and the broad Top-Level Tasks of each CPU, is vital in coming up with a good Design.


Bob Schor

0 Kudos
Message 4 of 7

As you already mentioned, the UML modeller is a tool from the GOOP suite. As such it is not a tool that can create UML diagrams from random code but specifically LabVIEW classes that follow the GOOP design model.


You can also use it to design your own UML diagrams by hand, which is how I usually use it but it is not a magic tool that can create a UML design overview from a mess of VIs .

Rolf Kalbermatter
DEMO, TU Delft
My Blog
0 Kudos
Message 5 of 7

Thank you for all your great replies.


Since the project was so large, I decided to read the codes and made a lot of descriptions to understand the code.


Fortunately, the project seems running and I could add some functions to the code.

0 Kudos
Message 6 of 7

@Eigo wrote:

Fortunately, the project seems running and I could add some functions to the code.

Careful there!


"It works" isn't a (good) reason to avoid changes. As I see "it works" for the computer, telling it what to do. But it doesn't seem to work for you. Good software works for both you and the computer.


If you're not solving the problems, you're probably making it worse.


Avoidance has a way of getting back to you (at the most inconvenient time)... Just a friendly warning.

0 Kudos
Message 7 of 7