3.4 Examples of Coupling, Cohesion, and Information Hiding

   

---

Something to keep in mind when looking at the examples and when considering your own designs is that coupling, cohesion, and information hiding are related . By improving information hiding you will generally be improving the coupling and cohesion.

The following examples should help in clarifying the concepts when applied to LabVIEW.

3.4.1 Bad (Tight) Coupling

The Front Panel in Figure 3.4 has many different controls and indicators, and their attributes and values will all need changing. The test and logging software behind this front panel was large and complex (1,000+ VIs). The graphing was user -definable and it also had to accommodate all the customers' off-line analyses. The wiring diagram could have ended up like that shown in Figure 3.5.

Figure 3.4. Coupling front panel.

Figure 3.5. Spaghetti code.

The term spaghetti code was first used before LabVIEW was developed. One advantage of graphical programming is that it becomes obvious if your program is heading down this route.

In LabVIEW 6i National Instruments tackled this problem by introducing the control reference. This is essentially a means of helping with the real estate issues caused by tightly coupled Front Panel controls and indicators.

Figure 3.6 demonstrates another good indicator of tight coupling, the amount of wires going in and out of a VI. If a component is strongly cohesive and exhibits good information hiding, it will generally not need more than four or five inputs and a similar amount of outputs.

Figure 3.6. An indicator of tight coupling.

A question worth asking is, Is the data we're passing essential to the problem domain? There are numerous examples of references and pointers being passed around the software for no better reason than to tie the VIs together.

3.4.2 Good (Loose) Coupling

Going back to the example of the Front Panel as shown in Figure 3.4, another fly in the ointment on this particular project was that the customer wanted the data handling and User Interface done by us off-site (actually we wanted to be off-site). We suggested decoupling the display using message sending through a queue. We implemented a display controller VI that was continuously polled by the Main Display VI. Display updates and attribute changes were sent to the Display Controller and queued in local memory.

This gave us the following benefits:

• It allowed us to design, test, and implement the User Interface off-site.

• It simplified testing since each state of the display was defined and known.

• It allowed a change of Display State to be triggered from almost anywhere within the software.

• It allowed changes to be easily and robustly implemented.

A fuller discussion of these User Interface techniques can be found in Chapter 6 on complimentary techniques.

Another example of loose coupling could be a measurement system component. This component conducts all of the measurement functions in a test system. Its interface could be as simple as the example shown in Figure 3.7. Stripped down all you want to do is tell the component what measurement you want and for it to output a number and its status.

Figure 3.7. Loose coupling example.

3.4.3 Bad (Weak) Cohesion

The classic example of weak cohesion is if you take a diagram and ring-fence it with your Create SubVI tool, but you do it in a completely haphazard way. If you show no regard at all for the operations that you are ring-fencing, you will have a system that is coincidentally cohesive. From a maintenance point of view a system partitioned like this would be a complete nightmare!

Think about the test system that we discussed earlier. It consists of an oscilloscope and a signal generator. It needs to conduct 30 individual tests. We create 30 VIs (named Test1.vi to Test30.vi). Each one has the GPIB calls to the scope and sig.gen. inside them. A reasonable test of your design is to consider the implications of change. For example a change of test frequency could involve changing specific calls in each one of the test VIs. Missing one call could invalidate the test.

You can improve cohesion simply by collecting like functionality. In this case you could make an Oscilloscope VI, Sig Gen VI, and a Test System VI. The Oscilloscope and Sig Gen VIs encapsulate all the functionality of their respective pieces of equipment. The Test System VI encapsulates all of the states of the test system. Essentially, it would become a wrapper for Oscilloscope and Sig Gen VIs.

3.4.4 Good (Strong) Cohesion

The VI shown in Figures 3.8 and 3.9 contains all the functionality required to simply control Word 97's basic functions using ActiveX. Figure 3.10 demonstrates how it is used.

Figure 3.8. Word Control connector.

Figure 3.9. Word Control Front Panel.

Figure 3.10. Word Control usage.

This is an example of strong cohesion because the component only deals with Word 97 and completes all of its functions single-mindedly. If you have any problems with Word 97 you know where to look. If you want to test the component, its functionality is all in one place, and the tests can be easily defined. Adding functionality is purely a matter of adding a command and a new case, none of the existing functionality is changed.

3.4.5 Bad Information Hiding

In this example we have a system that uses a Digital Input and Output (DIO) card to control lights and relays. Usually DIO cards work by ports and bytes, so here is one implementation that is used to switch a relay on and a light off (to add to the confusion let's put in a bit of negative logic for the light [true = off, false = on]). The relay will switch power to a unit under test, and the light will tell the user that the unit has power.

We'll be using the NI DIO-XX card that hasn't been newly developed.

Figure 3.11 doesn't look too bad, maybe a little bit of confusion with the negative logic. Now let's multiply it 100-fold. The system is much bigger, there are a lot of switches, actuators, and lights, and the person who wrote the above innocent-looking software has left. They've changed some of the driver hardware and some of the logic of the drivers. You've now got to go wading through the code changing channels and line settings to suit. If your predecessor has been somewhat lax in his or her comments, it could be a bit of a job.

Figure 3.11. Bad information hiding.

DIO drivers shouldn't be complex, they are only 1s and 0s. If all the software has been written like this, there may be some real complexity in the system.

3.4.6 Good Information Hiding

When thinking about information hiding in components , we need to think about the job that the component is doing and not the way it is going to do it. So revisiting the previous example, let's think about what the component will do.

• Switch Power to unit X on.

• Switch unit X Power indicator on.

• Switch Power to unit X off.

• Switch unit X Power indicator off.

The initialize function doesn't have anything to do with the problem domain, the component should decide for itself whether it needs initializing.

Let's redesign the DIO-XX component as shown in Figures 3.12 and 3.13.

Figure 3.12. DIO Component Panel.

Figure 3.13. DIO Component commands.

Don't worry too much about how this will be implemented for now, all will be revealed later. The implementation is less important than understanding that the component has been redesigned to be more in terms of the system than in terms of the hardware. We are not worried about ports and channels because these are implementation details. What we are interested in is the problem domain (i.e., what actually needs to happen). The redesigned diagram to complete the functions of switching a unit and its indicator on will now look like Figure 3.14.

Figure 3.14. Good information hiding.

---

Top