4.1 Components

   

4.1 Components

The idea of components is not new to LabVIEW or many other languages. There are three parts to LCOD: cohesion, coupling, and information hiding. All of these will be used in constructing components. These terms are as old as the ark as far as software engineering is concerned , but there is precious little discussion of them in the LabVIEW arena.

Some of you will notice similarities with Object Oriented Analysis (OOA). We feel we should clarify the point that LabVIEW is not an OO language and we're not trying to make it into one. The techniques described here predate OO and are methods for good modular design. When applied to LabVIEW these techniques improve an already powerful paradigm, data flow.

The idea of software components is far from new, they were first proposed in the NATO conference on software engineering in 1968 by Doug McIlroy. He realized that using libraries of commonly required utilities gave many of the benefits associated with reuse. These early software engineers were in spired by other industries that used components, and they put forward the proposal that an application could be built from software Integrated Circuits (ICs). Software components are similar to electronic components that are wired together to form larger components, with wires corresponding to the connection of data in software. This corresponds nicely with the wiring metaphor in LabVIEW. These points of interconnection between components can be thought of as the interface to the component. The interface is the only way of doing anything with the component. This interface should be explicit enough to ensure that no assumptions could be made about its implementation.

This gives us a set of requirements for what constitutes a component.

  • A component must provide a clear specification of what services it is prepared to offer.

  • The only way a component can interact with other components and the rest of the application is through its declared interfaces. It must encapsulate all of its data and processes behind this interface.

  • The component should be independent enough to be tested in isolation.

  • The components and software that use a component must rely only on their defined interfaces and specified operations.

To summarize, a good component does its duties clearly and concisely, has a simple interface, and hides its complexity from the outside world.

4.1.1 So What Is a Component?

It proved very difficult to provide a definitive answer to this, so we'll make up our own. In our terms a component is made up of VIs that provide a service or services through a simple interface. A component will exhibit the following features:

Strong cohesion ” This is provided by the collection of VIs.

Information hiding ” The functions of the subVIs are hidden from the outside world.

Loose coupling ” This is through the simplistic interface provided for the rest of the system to realize the services.

Figure 4.1 illustrates a typical component interface. Using messages to command the component actions and optionally taking inputs and delivering outputs. Why are components better than what you are doing now? For a small application the payoff from LCOD is small (perceived). However, for medium- sized projects and larger the rewards are enormous , if not critical to the success of the project.

Figure 4.1. Component.

graphics/04fig01.gif

A common current method of ignoring the design and concentrating on churning out a working system usually ends up with large diagrams, lack of structure, and spaghetti code, all of which lead to a complexity explosion and unpleasant amounts of stress. Side effects to this are a lack of reuse and a lack of analysis of what has been done.

Also, think how many times that you've written and rewritten routines. Add to that everyone else in the world doing the same thing. Wouldn't it be a more productive world to select and use an already written and tested component?

By talking about components we are forcing the software engineer to consider coupling, cohesion, and information hiding (even though he or she may not know it). What we are also doing is enabling a large task to be broken down into meaningful " chunks ." This aids the design process, simplifies estimation, and is the first step toward breaking a complex task into more manageable parts. The abstraction of the problem into the top-level components gives us the starting point from which the rest of the project will proceed.


   
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