6.6 Reuse

   

In the future you'll visit your software supermarket and go shopping for components that you can plug into your pattern, and in a very short time your application will be ready for action. Hmmm. . . . Despite a large amount of effort in this arena it still seems a fair distance away.

Reuse like most good ideas is simple in concept and surprisingly hard work in practice. The benefits do outweigh the effort but it is a long- term strategy.

Why reuse? Essentially , because if you didn't reuse your existing work you'd have to write everything from scratch, which would get very tedious very quickly. There are hidden benefits because reused code has been tested before (if it hasn't been changed). This gives us quality benefits as well as productivity improvements.

What can we salvage?

  • Designs

  • Source code

  • Documentation

  • Tests

6.6.1 Opportunistic Reuse

The easiest route to reuse is opportunistic reuse (some gurus call it "informal reuse"). This essentially involves hacking old programs to make new ones, and it is what most of us do to some extent or another.

The biggest obstacle LabVIEW presents is when it picks the wrong file path and you end up killing one of your originals (or even worse changing it without killing it).

If there is consistency of design, opportunistic reuse can be quite effective. Studies have shown that you can expect 40 percent productivity improvement.

But for anything more than a one-man band , leveraging advantage from reuse will take a certain amount of management.

6.6.2 Planned Reuse

This is where a company puts in the effort required to gain real benefits from creating and maintaining a reusable library of components.

Looking at several projects it would be safe to assume that the completely unique aspect of each is in the top-level design and some of the bottom-level detail. The commonality would be far higher than the 40 percent productivity improvement quoted for opportunistic reuse, which implies a certain amount of waste in the process. So how do we get to this cornucopia of high-efficiency state-of-the-art clean room programming? We don't know and its very frustrating. But the solution will come from management rather than from software engineers . Someone has to set up a reuse library and manage it, they will also need to promote its use, police the components that are input, reward or acknowledge the authors, and finally monitor the effectiveness of the policy.

We need to take small steps. Lasting benefits will come from approaching the problem in a careful manner rather than trying to cure all the world's ills at once.

There are things that can be done to improve efficiency and we are going to discuss the tools and techniques that will help.

The speed of developing in LabVIEW already owes a lot to the amount of reusable stuff provided with it. There are also some places to buy VIs, but the market is not well developed yet. The downside of this is the variable quality of the code available. There is also a problem with the consistency of the interface. If you have to learn the code (or tidy and correct it), the benefits of reuse will disappear. One of the advantages of ActiveX components is that they automatically provide and enforce a properties and methods interface. However a commercial marketplace for LabVIEW components will never develop until a common component interface is agreed.

How can LCOD help in moving toward planned reuse. The concept of components is reuse-friendly to start with, and the mind-set when developing cohesive, loosely coupled components is to produce an independent entity that can be reused. By having a self-documenting interface (popping up an enumerated type constant) detailing all of the component's functionality you are again making your component more reusable.

There are also tools provided with LabVIEW that can help, and these are discussed next .

6.6.3 Merge VIs

There is always a risk of damaging the original code when editing existing source code to create new software. If you want to reuse code fragments , there is a reasonably unknown tool that you can employ ”Merge VIs. An example will explain all.

First, take a useful bit of code that you find yourself writing over and over again (keep it compact without too many subVIs). Here's a VI for monitoring a button cluster for menu selection as shown in Figure 6.58.

Figure 6.58. Merge VI menu buttons example.

graphics/06fig58.gif

A button press will pass the button number to the case structure. All you will need to do is to fill out the actions in the relevant case. So, for Button 1 you would put your code in case number 1. The button numbers are controlled by their cluster order.

It would save time if this source code were available to drop onto our existing software.

Figure 6.59 shows how to set up a merge VI:

Figure 6.59. Editing Functions Palette.

graphics/06fig59.jpg

This will allow you to add submenus, VIs, and controls to the Functions and Controls Palettes. Right-clicking on the area where you want to make changes brings up the allowable options.

We will create a new personalized palette by selecting "New Setup . . ." from the drop-down box, as in Figure 6.60

Figure 6.60. New Setup. . . .

graphics/06fig60.gif

This will give you a default palette to play around with that can be saved under its new name .

Next we want to create a submenu called Merge VIs, which will hold all of our reusable code fragments. Right-click on an empty slot of the palette (you can insert new rows and columns as well) and select Submenu. . . . Figure 6.61 demonstrates this.

Figure 6.61. Insert Submenu. . . .

graphics/06fig61.gif

Give it a name "Merge VIs" and change the icon to make it pretty.

You can now open the submenu and perhaps put in another submenu titled "User Interface". In this submenu we'll put our VI. Now insert your VI and select Merge VI, as in Figure 6.62. Save your palette and the job is done.

Figure 6.62. Select Merge VI.

graphics/06fig62.gif

Now let's see what we've done. Open up a new VI and drag your new VI from the palette as shown in Figure 6.63. Finally, as illustrated by Figure 6.64, you drop it, the code and controls are transferred. Lovely!

Figure 6.63. Drag Merge VI.

graphics/06fig63.gif

Figure 6.64. Drop the code.

graphics/06fig64.gif

6.6.4 VI Templates

Another way to reuse code and structures is VI templates (.vit).

Creating and editing them is as easy as saving your VIs as VITs. What interested us was more complex VIs that had subVIs and so on. You need to save all of your subVIs as VITs as well (you'll notice that a blue T has appeared on the subVI icons). You can open, edit, and save these Template VIs as normal, but if you select the File>>New..>>Start From Template option and load your template file from here it will create a numbered copy of itself. When you save it, all the subVI templates will moan and require saving as well. The VI templates can be put onto the Function Palette and dragged onto your diagram, but unfortunately they drop as VITs, which isn't a lot of use. If you load them from the Select a VI option they seem to drop properly. So with LabVIEW, if you make template files you cannot stick them in the palette and expect them to act correctly.

From a reuse point of view we found the easiest way of managing reused code was not to share any of it. So each application would be completely isolated from changes in any other. When you want to reuse code, copy the whole directory structure from the original to the new location.


   
Top


A Software Engineering Approach to LabVIEW
A Software Engineering Approach to LabVIEW
ISBN: 0130093653
EAN: 2147483647
Year: 2003
Pages: 66

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net