3.5 Abstraction

   

---

Dictionary Definition

Abstraction ” A mental concept used to simplify a complex problem

You will come across this term a lot with regard to software design, so it is worth exploring it further.

When you save some text to a file, you will think of it in the terms of sending a string to the "Save to File.vi," instead of thinking about placing the 1s and 0s onto spare sectors of your hard drive. You are using abstraction to visualize the problem at a manageable level of complexity. The "Save to File.vi" method is at a far more abstract level than the 1s and 0s method.

In software design there are two types of abstraction.

Functional Abstraction : LabVIEW provides the facility to break up your design into subVIs. This hierarchical structure provides functional abstraction. A top-level function can consist of many subfunctions, and these subfunctions can have subfunctions of their own. This is the main way of breaking down the complexities in a problem.

Data Abstraction : Computers deal in 1s and 0s. Programming languages provide a level of abstraction beyond that by giving us more elaborate data types like Integers, Real Numbers , and Strings. LabVIEW also gives you facilities to define your own data types using clusters. Clusters allow you to group related items together, simplifying the moving of data around your application.

By encapsulating and hiding data within our VI we can take abstraction to similar levels as that provided by Object Oriented Programming (OOP). Using message sending as the only way to access and change the data allows us to implement abstract data types. Abstract data types are the basis for good modular design. The following example should help illustrate the advantage of correctly using abstraction in your designs.

We want a component that controls the switching for a measurement system. The underlying technology is a hardware card that turns relays on or off. A low level of abstraction would be the subVIs used to initialize and set or clear the ports on the card. These subVIs could be used as is, and every operation in the measurement system could have the relevant subVI being called to set and clear the required relays. This is shown in Figure 3.15.

Figure 3.15. Low-level abstraction.

A higher level of abstraction is to wrap the relay VI in a component that abstracts the details of relays and channel numbers. We are now talking in terms of the connection made from a system perspective. The Switch VI is used to wrap the relay VIs. All of the relay VIs are now encapsulated in one VI. There should be no way to access the relay VIs from outside the Switch interface. The usage of these new VIs is shown in Figure 3.16.

Figure 3.16. Higher level abstraction.

So how does all this benefit our design? Well, let's compare the hierarchy diagrams in Figure 3.17.

Figure 3.17. Abstraction hierarchy.

The higher level of abstraction will allow you to make changes to the switching system without actually changing the Switch VI interface. You could swap for a different relay card, for example, or change the switching configuration or the relays called. But the underlying structure of the software will remain the same. The extra layer of abstraction protects the software design from changes. Also, the higher level of abstraction makes your program easier to read. There is no ambiguity about what you want to happen to the switches when you send a command. Ambiguity in software is bad; ambiguity breeds bugs !

---

Top