Yesterday the OpenG Class Template Framework together with a few OpenG class templates were released. I now try to explain shortly what these templates actually are and how do they function.

OpenG Class Templates are nearly normal LabVIEW classes that are stored under resource\OpenG\openg_object\class_templates folder under LabVIEW installation directory. To be used OpenG Class Templates require a separate tool that can create new classes from the templates and that can manipulate existing classes created from class templates.

The class file of LabVIEW classes is always an XML file with information of class properties, class private data and class item properties. OpenG Class Templates differ from regular LabVIEW classes in that additional information is added to the lvclass XML file of the templates. This additional information explains the template tool such as Endevo GOOP Development Suite how to work with the templates. Based on this additional information the template tool knows how to create new classed based on the templates, how to create new methods from method templates, how to rename class based on a template and how to update template changes to template based classes.

When user wants to create a new class that is based on a OpenG class template, he needs to do this via a tool that support OpenG class templates. In the process, the tool creates a copy of the template and manipulates the copy according to the template meta data written in the template XML file. The tool also adds additional attributes to the class file created from the template so that this class can be recongnized to be based on a tempalte and the template used can be located. When there are changes in the template, these changes can be applied to the classes based on the template using this metadata in the class files.

As the templates are more or less regular LabVIEW classes, they can also depdend on other templates in a very similar manner as LabVIEW classes inherit from parent classes. For example OpenG Active Object Template is based on OpenG Reference Object Template. Active object is actually a referece object with some extra features and with a few changes in some underlying mechanisms. The inter-template dependency means that changes to parent templates can propagate via the child templates to classes created from the templates. This of course requires support from the tool being used.

The tools that support OpenG Class Template specification should be able to recognize any template in the above mentioned template directory. This makes it possible for the developers to create their own class templates specific to their own needs. However OpenG Class Template specifications are quite complex yet capable and it is not very easy to create new class templates. The complexity of the template mechanism also means that it’s probable that in the beginning only tested templates will work with tools supporting OpenG Class Templates and actually the support for custom templates will see light only when the tools get more mature.

For the past few months I’ve been working on a very interesting project together with Endevo from Sweden with Jim Kring from JKI. I have had the opportunity to design open source OpenG Class Templates for LabVIEW Object-Oriented Programming. Endevo has developed a GOOP Development Suite that allows developers to create classes from these OpenG templates directly from LabVIEW user interface. OpenG templates together with Endevo GOOP Development Suite has the potential to fundamentally change the LabVIEW object-oriented development process.

OpenG Class Templates

When LabVIEW Object-Oriented Programming was released about a year ago, I had a lot of expectations. Unluckily the features of LabVIEW OOP didn’t meet with my development needs. I needed by-reference classes to be able to represent complex data structures and encapsulate storage interface to classes. I needed user definable constructor and destructor for my classes to guarantee initialization and clean-up. With these needs I started to think of the ways how I could best implement these features on top of native LabVIEW OOP.

The aim of the OpenG Class Templates is to overcome the above mentioned shortcomings of native LabVIEW object-oriented programming by including features lacking from native LabVIEW OOP to OpenG class templates. Two most interesting OpenG templates are without doubt a queue based by-reference class template and a class template for active asynchronous objects.

Queue based by-reference class template allows developers to create by-reference classes with user defined object construction and destruction steps and with asyncrhonous parallel data access and data locking. By-reference classes are the proper choice when one needs to create objects with indentity and lifetime. Numerous use cases include encapsulation of instrument drivers, file handling, database access, network interface and urser interface components.

Template for active asynchronous objects combine by-reference objects with a thread of their own. Each object includes a parallely executed VI that is started during object construction and closed when object is closed. This parallely executed VI can receive and reply-to asyncrhonous messages from other parts of the program. Active objects can be considered to provide an active state-machine based service that other parts of the program or external components can communicate with using the object methods.

OpenG class templates are based on OpenG class template specifications. These specifications define a standard which allows all developers to create new class templates either from scratch or based on existing class templates. Furthermore developers can use these templates with any LabVIEW tool that confroms with the template specifications. Currently the only tool available is Endevo GOOP Development Suite.

OpenG wiki provides instructions on how to get and install OpenG class templates.

Endevo GOOP Development Suite

Endevo GOOP Development Suite (GDS) has an opportunity to revolutionize LabVIEW object-oriented programming based development. Being integrated directly to LabVIEW project environment Endevo GDS makes it very easy and fast to work both with native LabVIEW classes and with template based LabVIEW classes. The speed-up of the development process is actually enormous when the development suite takes automatically care of things like creating method icons etc.

Endevo GOOP Development Suite supports three kinds of classes; native LabVIEW classes, classes based on OpenG templates and classes based on Endevo templates. All of these alternatives are based on native LabVIEW object-oriented programming. Actually Endevo GDS allows users to create and add their own class templates that meet OpenG class template specifications.

GOOP Development Suite comes in two editions, limited functionality free Community Edition and in Professional Edition. Both versions of GOOP Development Suite can be downloaded directly from Endevo web site.

Conclusions

OpenG Class Templates together with Endevo GOOP Development Suite have a lot of potential to change the way LabVIEW object-oriented programming is beign used. I’ll keep blogging on the usage the templates. Subscribe to the feed not to miss any of these future articles.

As the third topic in my article series Introduction to Object-Oriented Programming in LabVIEW I’ll talk about inheritance and conceptual hierarchies in object oriented programming.

Hierarchies of real-world objects

Object of the real world often form conceptual hierarchies. For example a bicycle, a motorcycle and a car are all examples of different kinds of vehicles. A bus, a truck and an SUV are examples of different kinds of cars. These relationships between similar objects can be visualized using diagrams similar to one below.

All vehicles share common properties and common functionality. For example all vehicles have one or more wheels and they are designed for transportation purposes. We can also fairly safely say that all vehicles have some sort of steering method.

All cars share even more common properties and common functionality. A steering wheel is used for steering the cars. An engine is used as a power source. All cars have at least four wheels and the wheels are symmetrically distributed on both sides of the car.

We can say that the word vehicle defines a class of real-world objects for transportation and so does the words car, bicycle and motorcycle. As cars, bicycles and motorcycles are all special kinds of vehicles as well we can say that words car, bicycle and motorcycle all define subclasses of class vehicle. In a similar way bus, truck and SUV can all be considered subclasses of class car as they are special kinds of cars.

Class hierarchies in object-oriented programming

It’s often the case that the building blocks of a software project form similar conceptual relationship hierarchies. Consider for example the following build-in LabVIEW types.

All of these build-in types are numeric types. Furthermore EXT, DBL, SGL, CXT, CDB and CSG are floating point numbers whereas I64, I32, I16, I8, U64, U32, U16 and U8 are integer numbers. We can divide integers to signed and unsigned integers and floating point numbers to real and complex numers. Indeed these numeric types can be considered to form a conceptual hierarchy similar to one below.

Object-oriented programming allows the developer to specify this kind of conceptual hierarchies in software architecture. Each box in the above image can be considered to be a class. Remember from my last article that classes are building blocks in object-oriented programming that encapsulate both data and functionality.

This concept of hierarchies is called inheritance in object-oriented programming. The word inheritance comes from the fact that the classes in the hierarchy inherit properties, functionality and interfaces of their parents and all other ancestors. The diagram itself is called a class diagram as it represents the relations between different classes.

Conclusions

In object-oriented programming developers can define class hierarchies that define the relations of classes. Decedent classes inherit the functionality, the interface and the data type of all the ancestor classes. Although it didn’t yet become clear, class hierarchies and inheritance is one of the key substances in object-oriented programming. Class hierarchies greatly enhance code reuse and allow creating more intuitive software architectures.

In my next article I’ll go into more detail what are the benefits of inheritance. Subscribe to the RSS feed so you will not miss it.

Although object-oriented programming has been a standard method of software development for decades, it’s fairly new concept to most of LabVIEW developers. I start my blog with a series of articles introducing LabVIEW users to the concepts and ideas behind object oriented programming as well as to using object oriented programming in LabVIEW.

You may wonder why you should consider learning object-oriented programming. Well, there are a number of good reasons. Perhaps the most important reason why object-oriented programming has been so successful in the software industry is the fact that people are not very good at mentally managing very complex things. Object-oriented programming allows software architects and developers to divide the problem into more manageable pieces. The advantage is especially clear when working in teams. Each member of the team can concentrate on their own pieces of a complex software entity.

Object-oriented programming allows more modular software design compared to conventional dataflow programming. As a result of modularity object-oriented programming simplifies the modeling of the software architecture. Modularity also makes the software maintenance and management easier and simpler tasks. The software is more manageable throughout the entire lifecycle of the software.

Abstraction

The achieve software modularity object oriented programming relies on the concept of abstraction. The idea is that the software is divided into abstract and independent pieces that are easy to comprehend. Then the actual programming problem is solved using these abstract pieces without the need to know what happens under the hood of these pieces. The abstract pieces help programmers to describe the problem in terms of the problem and not in terms of the solution.

Whereas in traditional LabVIEW programming the abstraction is achieved using subVIs, in object-oriented programming the abstraction is achieved using objects. An object is an entity that fully describes the functionality and the state of something you want to abstract. Consider you want to abstract the concept of a car. An object car would then fully describe the functionality available in the car as well as the state of the car such as color or velocity.

In traditional dataflow programming each wire is of certain type such as a number of type DBL or a cluster composed of a string and a boolean. In a similar way in object-oriented programming in LabVIEW each object is of a certain type, or to be more specific of certain class. Classes are complete definitions of object types in a similar way as typedefs are complete definitions of traditional types.

Interface

Each object in object-oriented programming has an interface that complitely describes the functionality of the object that is available to the user of the object. In LabVIEW the interface is provided with a set of VIs that belong to certain class. Consider for example that you have a class Light that is an abstraction for a light similar to the one on your office table. You can turn on and off the light as well as adjust the brightness of the light. To implement the Light class in LabVIEW, you would need to create a new class called Light.lvclass. You could then define the interface of the class by creating four VIs: on, off, brighten and dim.

Hiding the implementation

When projects become so large that a single person cannot be responsible for the whole project, object-oriented programming becomes a handy tool. In such projects certain developers or class developers can be given a responsibility of developing certain classes. Other developers or class users then use these classes to solve some programming problems.

The interface of the class completely determines how the class user sees the class. The class developer should hide every VI that belongs to the class but that doesn’t belong to the class public interface. The interface VIs should be the only thing exposed to the class user. This concept of hiding parts of the class that do not belong the interface is called hiding the implementation. LabVIEW provides a way to set the visibility of each item belonging to a class from class properties.

Why is hiding the implementation important. Internally very complicated classes can have very simple public interfaces. Hiding the implementation also hides the complicated implementation related issues from the class user and makes the class functionality easier to understand. The interface is something that the developers can agree on before the start of the actual development work allowing developers to work in parallel. Hiding the implementation also prohibits the class user from accidentally using internal parts of the class and this way allows the class developer to change and modify the implementation later on as long as the interface VIs stay the same.

Conclusions

In this article I have discussed the ideas and concepts behind the object-oriented programming and why it is a handy paradigm for software development projects. To summarize dividing the application into abstract pieces called classes make the software projects more manageable compared to subVI level abstraction. Objects are instances of classes and classes specify the type of objects. Each class has a set of public methods called interface that is exposed to the class user. All the rest of the class internal implementation should be hidden from the class user to allow changing the class implementation throughout the lifecycle of the class.

In the next article I’ll dive deeper into the world of object-oriented programming. I’ll talk about reusing classes and about inheritance. Please feel free to comment the article. You may consider signing up to the RSS feed to stay tuned with the forthcoming articles.