How to analyse and upgrade undocumented vi?

[ERIS]

I have inherited a LabView project with no application-specific documentation as to its internal functioning.  It runs, can be stepped through in the LabView 8.6 debugger, and is well understood as to it's performance and operation.  The original author is no longer available.  Can anyone suggest a general strategy for learning an application-level VI and it's sub-VI's so that upgrade modifications may be made?

[RavensFan]

Start with viewing the VI hierarchy of the project so you can see which VI's interact with which.  Work from the top down and the bottom up.  Bottom up to see what some of the lowest level VI's do so you know their purpose when you see them in a higher up VI.   Top down so you can see the overall architecture.

Make a backup of the entire code base and store it someplace safe.  Even on a CD so you don't accidentally corrupt working code.  Thay way if you make a mistake, you can find a working copy.  You may want to edit the VI's and start adding documentation on the block diagram and in the VI properties.  Edit the icons to give them meaningful icons in the event they don't have them already.  Usually 2 or 3 short words in the VI icon with a black box around them will give you an ID what the subVI does when you see it on a higher level diagram.  Don't modify any code yet.  The goal is to just get a better handle on what each VI does and improve the documentation in the process.

[ERIS]

Thanks Fan!  I was starting to go that way already, but your advice is much more systematic than my admittedly ad-hoc (newbie!) approach.  I was also starting to trace program flow by setting breakpoints near where I want to change functionality, but that only works if you know in advance where to set them.

[johnsold]

In addition to Ravens Fan's excellent suggestions working from the front panel can be helpful.  Particularly when you start upgrading, understanding and having documented the function of each front panel control and indicator can be helpful.  You need to be able to answer such questions as "What does the program do in the Initialization mode if the user presses 'Pause'?" or "What is displayed on the graph 'Current Data' during AutoRun with the Vibration Channel disabled?"

Making a list of all controls which require immediate action when changed, all controls or indicators which are ever disabled or made invisible, and any controls or indicators which have different functions when the program is in different modes will give you a "check list" of places where the program might not behave as expected.  You can build tables of actions and references to the parts of the program where those actions occur to help organize your thinking.

Essentially you need to create a specification for the program: A document which describes what the program must do (and not do).  If you do this and get both the users of the program and the person in charge of the upgrade to agree that the specification describes the program and any changes they want made, then you have a starting place for your design.  This also protects everyone in the (not too unlikely) case that your analysis shows that the old program does not work the way they thought it did (bugs).

Create specification.  Get it approved.

Design program.

Modify/develop code.

Test.

New project or rebuilding an old one: This procedure works.

Lynn