Graphical Object-Oriented Programming

silkthrilledΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

65 εμφανίσεις

ADV2A-1Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Graphical Object-Oriented
Programming
Jörgen Jehander - ENDEVO
Stepan Riha - LabVIEW Software Engineer
Thu 10:15a, 12:45p, and 3:30p
Red River (4B)
Jörgen Jehander is the Vice President of Research and Development and co-
founder of ENDEVO in Sweden. He has 10 years of experience in object-
oriented technology and has worked with LabVIEW since 1993.
Stepan Riha is a Senior Software Engineer in the LabVIEW R&D department
at National Instruments. He has worked on LabVIEW since 1991.
ADV2A-2Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Overview
Overview
 Problems with monolithic applications
 Conventional development
 Component-based development
 Using components in LabVIEW
 Implementing OOP in LabVIEW
 Problems with monolithic applications
 Conventional development
 Component-based development
 Using components in LabVIEW
 Implementing OOP in LabVIEW
ADV2A-3Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Problems with Monolithic Applications
Problems with Monolithic Applications
 Difficulties we face:
Design can quickly become confusing
Numerous developers increase problems
Testing is not straightforward
Difficulty finding and correcting bugs
Expensive to add functionality
 Difficulties we face:
Design can quickly become confusing
Numerous developers increase problems
Testing is not straightforward
Difficulty finding and correcting bugs
Expensive to add functionality
LabVIEW is a very powerful tool for developing applications. However, as
the size of your application grows, it often becomes difficult to manage the
growing complexity. The design or architecture of a large application can
become confusing and hard to understand.
When several developers work on the same project, it is difficult to coordinate
their work and make sure that the parts of the application they are working on
fit together.
A complex application is also more difficult to test. It may be hard, if not
impossible, to design test cases for all the possible execution scenarios.
When a problem is discovered, it is sometimes very difficult to narrow down
and find the bug in your code. Once discovered, correcting the bug may
introduce other problems into the application if all the dependencies are not
carefully examined.
The more complex an application becomes, the more difficult is is to add
additional functionality. Often adding new features affects a large number of
existing virtual instruments (VI), potentially breaking existing functionality.
ADV2A-4Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Conventional Development
Conventional Development
 Top-down design
Functionality abstracted into subVIs
 GUI often designed first
SubVIs often created from sections of virtual
instruments (VI)
 State information stored in global variables
Data dependencies
Race conditions
 Top-down design
Functionality abstracted into subVIs
 GUI often designed first
SubVIs often created from sections of virtual
instruments (VI)
 State information stored in global variables
Data dependencies
Race conditions
The conventional approach to designing LabVIEW applications is the top-
down design. In this design, the application is first viewed at a very high level
and is then broken down into more specific and detailed parts. Each part is
then further refined into smaller parts. The VIs that implement this application
often reflect this top-down design.
Sometimes this functional abstraction does not happen at logical boundaries
and for the right reasons. Often, the top-level VI is the user interface VI, and
its subVIs are created from sections of the top-level VI. Although the UI VI
must necessarily reside at the top of your VI hierarchy, it does not always best
represent the problem you are solving at its highest level.
Another difficulty that many conventional LabVIEW applications share is how
state information is used. Often state information is stored in local or global
variables that lead to race conditions and hard dependencies.
Using global variables can lead to race conditions if several VIs try to read and
write to the global variable at the same time. These types of problems are very
difficult to identify, because they may occur only sporadically.
If an application relies on global variables, it may become impossible to reuse
some of its subVIs, both within the same application or in other projects.
ADV2A-6Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Conventional Development
Conventional Development
 Case study  climate control system
Maintain a desired temperature using a heater,
cooler, fan, and temperature sensor
 Case study  climate control system
Maintain a desired temperature using a heater,
cooler, fan, and temperature sensor
In this case study, we want to implement a climate control system whose task
it is to maintain a specified temperature.
The system detects the current temperature using a temperature sensor.
Based on the measured temperature, it controls a heater, cooler, and fan in
order to reach the desired temperature.
ADV2A-7Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Conventional Development
Conventional Development
 Climate control system
 Climate control system
Diagram of a conventional Climate Control System
This is a traditional approach to implementing the system. However, there are
several potential problems with this solution.
For one, the controller logic is inside the top-level VI. Should you implement
another control strategy, for example a PID controller, the diagram of the top-
level UI VI needs modification.
The tight coupling to the UI VI could cause other problems. For example,
changing the rate of the display update (left sequence structure) directly affects
the response behavior of the controller.
ADV2A-10Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Component-Based Development
Component-Based Development
Monolithic Program
Component A
Component B
Component C
Component D
Component E
Component Program
ADV2A-12Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Component-Based Development
Component-Based Development
 Design begins by identifying components
Look at the problem description
Think in higher level terms
Decide on responsibility and behavior of each
component
Test each component on its own
 Application is built up from components
They snap together like Lego blocks
You can add new pieces in the future
 Design begins by identifying components
Look at the problem description
Think in higher level terms
Decide on responsibility and behavior of each
component
Test each component on its own
 Application is built up from components
They snap together like Lego blocks
You can add new pieces in the future
Your component-based design begins by identifying the components from
which your application will be built. The best start is to look at a problem
description to see if it can be divided in parts (not functions) that can stand
independently on their own. Identifying the nouns in the problem description
is often a very good way of finding the parts that constitute the problem. At
this point, think in high-level terms and do not worry about implementation
details.
While you are determining which components to develop, also decide on the
behavior of each of the components. The behavior is defined by all the
methods that belong to the component interface. Document any assumption
that you make.
Once you have implemented the components, you should thoroughly test each
component on its own. This simplifies the type of testing that you have to do
in your final application.
The actual application is constructed from your well tested components. The
individual pieces should snap together like Lego blocks. These components
should also be reusable for other applications and straight forward to add
additional components to your current application.
ADV2A-13Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Component-Based Development
Component-Based Development
 Case study  climate control system
 Case study  climate control system
Heater
Cooler
Fan
Temp
Controller
You should begin the design of the climate control system by determining
which components to use.
We can use physical aspects of the system to guide us in selecting which
components to use. In this case, we may want to use a control component that
contains the logic of the control algorithm (it could be a PID or a fuzzy logic
controller), we would have a heater component add heat to the system, a
cooler component that removes heat from the system, a fan component that
moves air, and a temperature sensor component that reports the current
temperature.
Note that the main application is not exposed to all of these components; in
fact, it only needs to know of the controller component.
Also, some components may exist more than once. For example, we might
have a fan for the heater and another fan for the cooler.
ADV2A-14Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Component-Based Development
Component-Based Development
 Climate control system
 Climate control system
Diagram of a component-based Climate Control System
In this diagram, the behavior of the temperature controller is de-coupled from
the GUI, and the lower-level components (heater, etc.) do not appear in the
GUI diagram at all. At the top of the diagram, you create the controller (using
the new constructor method) and start (using the run method). The
controller now continues its operation until someone stops it. When it is
stopped, it is released (using the delete destructor method).
The user interface loop does not affect the behavior of the controller. This
loop simply updates the desired temperature (using the wanted temperature
method) and queries the current status of the controller (using the status
method). When the user stops the loop by clicking on the Stop button, the
controller is stopped (using the stop method), which in turn terminates the
run method (at the top of the diagram).
Changing the update rate of the GUI loop (from 100 ms to 500 ms) does not
affect the rate at which the controller is changing the temperature. In fact, you
could completely remove the UI loop and the controller would function the
same.
Similarly, implementing a new controlling algorithm in the run method does
not affect the diagram of the GUI VI.
ADV2A-16Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Designing Components
Designing Components
 Responsibility first
Determine component behavior
Decide on component responsibilities
 Interface second
Select which functions you should use to control
the component
 Implementation third
Test component
 Responsibility first
Determine component behavior
Decide on component responsibilities
 Interface second
Select which functions you should use to control
the component
 Implementation third
Test component
When you design a component, you should always start by thinking about its
behavior and responsibilities. You should also document any prerequisites
that you need meet in order for the component to function properly. A
component that deals with external devices may have to initialize these
devices to function correctly.
After you have decided on the responsibility, you specify the component
interface. These are functions through which the application uses the
component. The interface of the component is constituted by the selected
methods (functions). During the lifetime of a component (when it is used by
applications), the interface should not change so you do not break existing
applications.
ADV2A-18Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Using Components in LabVIEW
Using Components in LabVIEW
 Queue VIs
Responsibility
Passing data between diagrams running in parallel
Using FIFO buffer for string data
Interface
Create queue
Insert queue element
Remove queue element
Destroy queue
 Queue VIs
Responsibility
Passing data between diagrams running in parallel
Using FIFO buffer for string data
Interface
Create queue
Insert queue element
Remove queue element
Destroy queue
Another example of a component in LabVIEW are queue VIs found in the
synchronization palette.
Again, they have a well-defined responsibility, behavior, and interface.
As with files, you can use several queues at the same time without one queue
affecting the behavior of another queue.
ADV2A-19Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Classes, Methods, and Objects
Classes, Methods, and Objects
 Classes
Implementation of components
 Methods
Public interface to component
 Objects
Instances of class data
 Classes
Implementation of components
 Methods
Public interface to component
 Objects
Instances of class data
When you talk about components in an object-oriented programming (OOP)
environment, you usually talk about classes, methods, and objects. These are
standard terms for describing components.
A Class defines the behavior of a component. It describes its interface
(methods) and it implements the component behavior. If a component
maintains state information (a queue needs to know which elements it
contains, for example) the state information data is defined by the class as
private, encapsulated data members.
ADV2A-23Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Implementing OOP in LabVIEW
Implementing OOP in LabVIEW
 Should use the same as built-in components
 No direct language support in LabVIEW
Object management implemented on diagram
 Class Wizard
Automatically generates class and method VIs
 Should use the same as built-in components
 No direct language support in LabVIEW
Object management implemented on diagram
 Class Wizard
Automatically generates class and method VIs
When you implement components in LabVIEW, you should use them in a
similar manner as the built-in components (File I/O, queues).
Because LabVIEW does not have automatic support for components, all the
object management code (creating objects, managing object references,
releasing object data) are implemented on the diagram.
You can use the Class Wizard to easily create new component classes. The
wizard steps you through the process of creating a class and the methods that
implement it. The wizard generates VIs that take care of creation, deletion,
and management of objects.
ADV2A-25Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Implementing OOP in LabVIEW
Implementing OOP in LabVIEW
Class New
Creates an object
Class Delete
Destroys the object
Class Get Data
Reads object state information (read-only)
Class Get Data to Modify
Class Set Modified Data
Reads and writes object state information
Class New
Creates an object
Class Delete
Destroys the object
Class Get Data
Reads object state information (read-only)
Class Get Data to Modify
Class Set Modified Data
Reads and writes object state information
Besides the two class typedefs, the wizard also generates the following VIs,
described in the next slides:
Class New
Class Delete
Class Get Data
Class Get Data to Modify
Class Set Modified Data
ADV2A-30Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Implementing OOP in LabVIEW
Implementing OOP in LabVIEW
 Class Methods
Implemented using Get Data or Get Data to
Modify and Set Modified Data VIs
 Class Methods
Implemented using Get Data or Get Data to
Modify and Set Modified Data VIs
Other Class Methods implement the actual behavior of your class. On their
diagram they use either the Class Get Data VI to access the data, or the Class
Get Data to Modify and Class Set Modified Data VIs to modify the object
data.
When you create a new method in the Class Wizard, you can specify whether
it is a read-only or a read/write method.
ADV2A-31Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Class Wizard Demo
Class Wizard Demo
ADV2A-32Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Graphical Object-Oriented
Programming Conclusion
Graphical Object-Oriented
Programming Conclusion
 GOOP and Components improve:
Reusability
Testability
Maintenance
Scaleability
Team development
 GOOP is built on:
Classes, objects, and methods
 GOOP and Components improve:
Reusability
Testability
Maintenance
Scaleability
Team development
 GOOP is built on:
Classes, objects, and methods
GOOP gives you to ability to implement components using the class and
object concepts from object-oriented programming languages.
By defining the components based on their behavior, you can think about your
problems. You also avoid having hard code dependencies between the
components and the applications that use them.
This abstraction leads to better reusability and it simplifies the testing and
maintenance of your application.
Applications built on top of components also become more scaleable.
Finally, because an application consists of several components, it makes team
development more successful, because most components do not depend on
each other, and those that do only use a well-specified interface.
The Class Wizard makes it easy to quickly create new classes and to add new
methods to existing classes.
ADV2A-33Graphical Object-Oriented Programming
www.natinst.com
www.natinst.com
Questions?
Questions?