7.9 Pictures Tell a Thousand Words

   

One way of keeping a check on how much you write is to draw pictures. There is no more common form of language than pictures. Which do you use? Pretty much whatever is going to get the message across the best. Unified Modeling Language (UML) does not convey a menu hierarchy as well as a good old-fashioned flowchart. However, a flowchart cannot convey the complexities of a detailed overall design. Use what works. The most common diagrams we use are data flow diagrams (DFDs), flowcharts, and STDs.

7.9.1 Diagrams ”Data Flow Diagrams (DFDs)

Steve Watts writes ”"From the mid-1980s to the early 1990s I only knew of one graphical notation to use with software, the flowchart. I found that flow charts were fine for certain aspects of design, but they were too detailed for more complex systems. They were also inefficient for mapping systems with many conditions and their branches. It seemed that this was a good enough reason to do no design at all."

In the late 1960s Edsger Dijkstra and associates launched an influential attack on unstructured programming, stating that unconditional branching (GOTOs) caused software to become unwieldy, error-prone , and difficult to maintain. They asserted that "Sequence," "Condition," and "Repetition" were the only constructs required when creating software. These three constructs are fundamental to structured programming. The diagrammatic notation for structured programming is called the data flow diagram (DFD) and is very simple. The main symbols for the data flow diagram are shown in Figure 7.4. This simplicity is one of the great advantages of this method.

Figure 7.4. DFD symbols.

graphics/07fig04.gif

Structured design is about processes, inputs, and outputs. The top-level diagram (context diagram) describes the system in relationship to its inputs and outputs. The external inputs originate from input terminators, and any external outputs from the system end up at output terminators. A typical top-level DFD would look like that shown in Figure 7.5. It's useful to make a list of the data flow contents (e.g., Sensor Data[sensor1mA,sensor2mA,sensor3Vdc]).

Figure 7.5. Test system context diagram.

graphics/07fig05.gif

Another advantage of DFDs is that the diagrams can be decomposed to more detail. Let's look at the next level, "Test System," as shown in Figure 7.6.

Figure 7.6. Test System DFD.

graphics/07fig06.gif

All of this is very applicable to LabVIEW, being a data flow language, but you may be wondering why bother? LabVIEW already has a graphical notation. Why introduce another? We find it good discipline to separate the initial design and not to pollute it with any actual programming (plus, I can sit in the garden and do it). This allows us to concentrate on the design and not clutter up our minds with the implementation (syntax). We use it to identify top-level components , or as a communication tool for large, complex multideveloper systems.

7.9.2 State Transition Diagrams

State transition diagrams are very useful for modeling the states of a system and illustrating the actions of a state machine. We mentioned them previously in our discussion of state machines, with the washing machine example.

The notation is simple: a labeled box is used to signify a steady state, labeled arrows are used to signify the transition to another state, and small circles indicate the start and stop states. Looking at a real-world example may help the explanation.

This system was used to control the operation of a complex piece of equipment. For each state certain buttons and conditions need to be monitored and certain ones ignored.

So looking at Figure 7.7 we can see that there is a direct transition from the Start state to the Initialize state. The Initialization Complete transition then moves the system to the Idle state. Here we set the valves and indicators to their idle condition and wait for a press of the "Enable Vacuum" button. A press of the "Enable Vacuum" button causes a transition to the next state that pulls a vacuum on a mold. The valves and indicators are now set for this state, and it sits and waits for conditions to trigger new transitions.

Figure 7.7. State machine example.

graphics/07fig07.gif

This diagram was invaluable in the design of the system because we could present and discuss it with customers and when agreed map it easily to a state machine structure in LabVIEW.

7.9.3 Homemade Diagrams

Can't find a notation that you like, then make one up. As long as it's not so cryptic that no one else can understand it, then use what works for you. We have a number of homegrown diagrams that we use, one of which we call the Component Interaction Diagram. When we are breaking down our design, we will often show the components that interact to give a better grasp of what components are needed and how they will be coupled together. See the real-life example in Figure 7.8.

Figure 7.8. Example component interaction diagram.

graphics/07fig08.gif

This diagram shows all the top-level components for a system we designed. The system was for calibration. Each circle denotes a component, and the connecting lines show their interaction with other components in the system. It looks remarkably like other diagrams, but because it's ours we can dictate the rules. Some might say that this is a waste of time because so many notations already exist, which is a fair point, but always use what works for you.

We try to make our component interaction diagram reusable. For example, to aid estimation. The diagram could also be used in the quotation and then to form part of the architecture document.


   
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