I'm a slow adopter

My business is to deliver code to customers that is robust, easy to understand and reasonably priced. I've used LabVIEW for years now and have found it to be very helpful and intuitive to use. I've also found the graphic nature of it to be very useful when demonstrating and evangelizing it to customers. This makes me very protective, fairly conservative and sensitive to any developments that in my opinion reduce the comprehension of the block diagram. Many moons ago when LVOOP was introduced I was shown a demonstration in which I couldn't understand the block diagram, this worried me greatly. Bearing in mind I'm not a stranger to OOP having done Smalltalk and Java this was not a positive introduction.

I went back to my day job, wrote code and ignored it, but I don't like to just dismiss something without understanding the WHY....

My big problem was that I saw LVOOP as a replacement for our own methodology but didn't see it addressing the issues of poor design practices, in essence a badly designed OOP program is actually harder to work with than a traditional badly designed program.

Regarding cohesion for example, in LVOOP a method is a VI in a library. For us a method is a message you send to a component. It just wasn't cohesive enough to fit into our designs.

In seeing this as an issue I was completely wrong, National Instruments is a tools provider and as such need to provide tools that lack cohesion, we as designers need to take these non-cohesive tools and make them into cohesive designs. Once I got my head round this things began to drop into place.

LVOOP and LCOD

The things that make LCOD a successful methodology for us are ….

1. Message Sending.
2. Persistent Private Local Storage (not FGVs!!!!).
3. Cohesion... Collect together all like functionality and hide it behind a common interface.
4. Coupling... Unnecessary data is not passed around on the block diagram.
5. Information Hiding - the implementation is abstracted behind the common interface.
6. Clarity and simplicity.
7. Flexibility - changes to functionality are hidden behind the interface, additions are confined to updating the message to the component.

LVOOP can offer the following advantages

1. An object persistently holds its own data, this is kept private and can only be accessed through the objects methods.
2. Inheritance/dynamic dispatching can reduce maintenance for similar functionality.
3. UML offers a common diagrammatic language for communication of ideas and patterns. This is a huge and under-utilised advantage
4. Dynamic dispatching allows different functionality to be implemented without changing the block diagram (advantage and disadvantage it could be argued).
5. Abstraction is more formalised and therefore more likely to be considered early on in the design.

LVOOP can offer the following disadvantages

1. Implementation detail is too small/ non-cohesive. So a block diagram will be very deep with not much happening at each level. A method=1 VI.
2. Lots of references passed round the block diagram.
3. Implementation is FIDDLY! This could just be the learning curve, but simple things seem hard! (I did my initial work using LabVIEW 8.5.1 and prior to LabVIEW 2009 LVOOP was considerably harder to work with)

By combining the techniques we may be able leverage the advantages of both methodologies.

LCOD Implementation Improvements

One drawback of our implementation of LCOD is a component can have inputs and outputs that are not required by the message, this can lead to mistakes and confusion in the wiring. The solution so far has been to limit scope, use variants, clusters or strings, this can be seen as stamp coupling. Polymorphic VIs may be the solution using single element queues named to the main VI to store local data. Group commands together to common up inputs and outputs.

As the component is polymorphic I need to be able to store the object in a mechanism that can be accessed by multiple VIs. Naming queues is a bad thing (essentially it's a global variable if you know the naming mechanism), but in this case I went for simplicity and used the polymorphic parent vi name.

The other disadvantage of LCOD that I am sometimes presented with is that it lacks scaleability, as far as I'm concerned this is just another implementation detail. For example there is no reason that the data stored in the queue above shouldn't be an array of objects, referenced by an enumerated type.

The big and I mean BIG thing (why am I the only one who gets excited about this stuff) is that the most important thing is the interface, the implementation is hidden away behind it and that my dear friends is the difference between a design methodology and just writing code.

This is a very brief summary of what was a long journey, but now I'm pretty happy with where we are at.

Lots of Love

Steve

Anyone even peripherally involved with computers agrees that object-oriented programming (OOP) is the wave of the future. Maybe one in 50 of them has actually tried to use OOP – which has a lot to do with its popularity. Steve Steinberg, "Hype List", Wired, Vol. 1, No. 1, Mar/Apr 1993