LabVIEW Design - An introduction

[swatts]

We've been banging on about the advantages of using proper design techniques in LabVIEW for well over 10 years and I'm not about to stop now. To start my blogging career I thought it might be a good idea to describe what we mean by good design.

A good design....

1. Simple things are easy to change, more difficult things do not make the system unstable.
2. Can be understood by an average LabVIEW programmer.
3. Is robust enough for the customers requirement.
4. Performs to customers expectations.
5. As much as possible can be reused.
6. Is predictable in the way it works.
7. The block diagram represents and describes what the source code is doing.

I also want to establish some separation between the tools and the design.

1. OOP -->tool
2. LCOD -->tool

The key is if you can make a bad design with it,  then it is a tool. A tool is used to express your design. So saying you are a good designer because you use OOP is like saying I'm a good architect because I use concrete!

I would also like to put some distance between declarations not backed up by evidence .

The following are common statements.

• Globals are bad --> not for storing globally required data they are not, unlimited use of global data is bad!
• LabVIEW Functional Globals are bad --> see above
• Sequence structures are as bad as gotos --> again for enforcing a sequence of events they are OK, there are better ways to do it but let's keep it in perspective, there are bigger fish to fry.

It is better to use a technique knowing the consequences than not knowing the risks at all.

On the coming subjects I really want a discussion, there are elements to these ideas that will need properly exploring.

For many decades the following ideas have contributed most to the design arena (in whatever language you use). Get a feeling for these concepts and you'll make your programming life less stressful, guaranteed!

Coupling

http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29

Example: Using globals is bad because global memory is very tight coupling. If any subroutine can access and change data at any time it doesn't take a genius to work out that this will make the code hard to understand.

Cohesion

http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

Example: Keep all like functionality encapsulated into one VI. The encapsulation needs to be done at block diagram level, using references, lvlibs, classes is not as helpful.

Take the following Use Case.

An instrument is used throughout a test system, it has 50 functions that can be set by sending text commands via a serial port. A non-cohesive method is to send commands at each point in the test via VISA. The implications of this design choice (and believe me we've seen it) is that if you change the instrument you will have to find every VISA call related to this instrument and change the text.

Information Hiding

http://en.wikipedia.org/wiki/Information_hiding

Hiding the implementation detail behind a defined interface allows changes to be made internally without affecting the rest of your code. I've come to the conclusion that this is probably the most important thing to understand.

Things I'm going to be discussing in future blogs (as and when I get the time and energy)

• LabVIEW Anti-Patterns (code smells).
• Coupling and Cohesion with regards to state machines.
• Dynamic Design consequences.
• Ways to simplify your code.
• anything else I can think of..

Lots of Love

Steve Watts

Sales pitch....I'm always interested in really really easy work with large budgets