210 likes | 402 Views
Graphical Object-Oriented Programming. Jörgen Jehander - ENDEVO Stepan Riha - LabVIEW Software Engineer Thu 10:15a, 12:45p, and 3:30p Red River (4B). Overview. Problems with monolithic applications Conventional development Component-based development Using components in LabVIEW
E N D
Graphical Object-Oriented Programming Jörgen Jehander - ENDEVO Stepan Riha - LabVIEW Software Engineer Thu 10:15a, 12:45p, and 3:30p Red River (4B)
Overview • Problems with monolithic applications • Conventional development • Component-based development • Using components in LabVIEW • Implementing OOP in LabVIEW
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
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
Conventional Development • Case study – climate control system • Maintain a desired temperature using a heater, cooler, fan, and temperature sensor
Conventional Development • Climate control system
Component Program Component A Component B Component C Component D Component E Component-Based Development Monolithic Program
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
Component-Based Development • Case study – climate control system Controller Heater Cooler Fan Temp
Component-Based Development • Climate control system
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
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
Classes, Methods, and Objects • Classes • Implementation of components • Methods • Public interface to component • Objects • Instances of class data
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
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
Implementing OOP in LabVIEW • Class Methods • Implemented using Get Data or Get Data to Modify and Set Modified Data VIs
Graphical Object-Oriented Programming Conclusion • GOOP and Components improve: • Reusability • Testability • Maintenance • Scaleability • Team development • GOOP is built on: • Classes, objects, and methods