34 replies to this topic

[ShaunR]

Lava is obviously a great place to pick the brains of the Labview community elite. It is also more LVOOP centric than other labview sites and has some awsome LVOOP talent. However. Most of the LVOOP concepts discussed are very advanced for the average LabVIEW programmer and centered around a few personal projects with no real focus on deliverable code, rather frameworks and eosoteric concepts.

Quite often we see potential CLDs posting their code, for comment, as a prelude to taking the exams. All of these are written in classical LabVIEW. If the LVOOP community is adamant that LVOOP is the future, then maybe some of the LVOOP gurus could post unofficial, demonstrative LVOOP implementations of the example exams (ATM, traffic lights etc). This would then give a focus on using LVOOP to achieve specific end goals, with well defined specifications and exisiting solutions for comparison - it would allow those using classical LabVIEW techniques to comparitively understand LVOOP in context with the classical solutions.

Is anyone up to the challenge? To provide (unofficial, demonstration) LVOOP solutions of CLD example exams for the benefit of potential CLDs? We see many different approaches in classical LabVIEW to solving the examples. Would we see a similar plethora of innovative LVOOP solutions? Perhaps it could even be a collaborative effort to produce them and maybe , once refined they could be proffered to NI as a candidate for an official NI solution along side the classical one!

[Daklu]

Just curious... are you looking for a sample CLD solution, or a sample real-world application based on the requirements of a sample exam? They have different requirements and will result in different source code. (For me anyway.)

For example, the car wash example uses a slider to indicate the car position. That is complete inadequate for building a real world system. In the real world the sensors are independent of each other; you can have multiple sensors signalling the presense of a car, or you can have no sensors signalling the presense of a car. With the slider, one sensor--and only one sensor--is always signalling the presense of a car.

Given the time constraints of the exam I'm going to take every shortcut I can and use the slider. If a customer gave me that requirement document I'd point out the flaw and encourage a better solution, like checkboxes for each sensor.

[ShaunR]

Just curious... are you looking for a sample CLD solution, or a sample real-world application based on the requirements of a sample exam? They have different requirements and will result in different source code. (For me anyway.)

I'm thinking of sample CLD solutions. (i.e to the spec in the example exams). The point is to show that identical results can be achieved with both methodologies using the exisiting classical solution as a reference to understanding the LVOOP.

However. I don't descriminate between the two. The CLD exam IS a real world application (it has a spec and a deliverable).

Edited by ShaunR, 12 February 2012 - 05:50 PM.

[Daklu]

I'm thinking of sample CLD solutions. (i.e to the spec in the example exams). The point is to show that identical results can be achieved with both methodologies using the exisiting classical solution as a reference to understanding the LVOOP.

Fair enough. Personally I find the LVOOP implementation of the strict Car Wash requirements document uninteresting and... mostly pointless I guess.

The CLD exam IS a real world application (it has a spec and a deliverable).

No it isn't. Real world applications projects (I should have said project in my original post) have something the CLD does not--a customer that is going to use the code. Yes, the CLD and real world projects both have a spec and a deliverable. The spec is only useful as a mechanism for communicating the customer's desires. Unless you're willing to spend NASA-like time and money on a spec document, no spec will accurately convey all of those desires. Writing code strictly to satisfy a spec will (imo) lead to an unsatisfied customer.

Real world projects with real world customers need to address things like:
- Does the requirements document provide solutions to the customer's intended use cases?
- How will the software accomodate hardware changes, such as updating obsolete hardware?
- What is the testing strategy and does it provide enough coverage?
- What happens when the software is installed on multiple platforms with different hardware configurations?
- What are the expectations for ongoing sustainability?

The CLD spec document is fine for an exam. As a spec for a real world project it leaves a lot to be desired. It doesn't address any of the questions above. In many places the spec document is defining implementation details instead of user requirements. (That's a huge red flag for me.) Many of the requirements just flat out don't make sense from a real-world point of view.

"The controller should disable the Wash Options buttons [when the Start button is pressed.]"
No it shouldn't. The car wash controller is a business component, not a UI component. It shouldn't know anything about Wash Options buttons. On top of that, in the real world mechanical buttons often can't be disabled. Disabling a button on the simulated entry console as a way to control inputs to the car wash controller opens a huge hole for bugs when the simulated input panel is replaced with real world hardware. Not only is that requirement defining an implementation, it's defining a particularly bad implementation.

"The controller should check if the vehicle is at the appropriate stations for the first step in the selected wash type by monitoring the Car Position Slider."
This has the same problem of not separating the business logic and user interface as above. It also makes the slider problem I mentioned in my first post a *requirement* of the application. How are we going to test how the controller handles sensor failures? Obviously the "customer" hasn't even considered the possiblity of a sensor failure. That's another huge hole for bugs when the controller is deployed on a real system.

The document is littered with requirements like that. It's fine for a timed exam, but it has far too many flaws and unanswered questions to be the basis for a real-world project. Without a customer to discuss these issues with, my real-world solution for this example would include many things that are not in the spec document because they are the better long-term decision. Those things take time to design and implement, but pay off down the road. With the exam there is no "down the road," so it ends up looking like pointless overhead.


[Note: I'm pretty sure there are at least two versions of the Car Wash sample example floating around. Broadly speaking they are the same but I believe there are significant differences in the requirements.]

[drjdpowell]

I am reminded of one of my first posts on NI.com:

I haven't done the CLD myself, but this conversation prompted me to look at the Traffic Light example exam, along with the NI-supplied sample solution. Although I'm sure it follows standard "style", IMHO it is a pretty poor attempt at the described problem, at least if this were to have any connection to a real-world problem of programing a traffic intersection.

1) Real-world intersections come in many different configurations, but the solution presented is inherently specific to only one very-specific configuration with no thought applied to producing software that can be customized. Every different intersection type would require a different version of the code. A fully general solution is too big for a four-hour test, but one could at least set the groundwork by having some "intersection configuration" constants feeding into a more generalized intersection state machine. It would be easy to write code that could be configured with an arbitrary number of lights and states by using arrays, for example, allowing easy generalization to a five-way intersection.

2) The solution ties together the implementation of the intersection state machine and the implementation of the specific type of light. If traffic engineers were to start using four-bulb lights (Red, Y, G, and Left Turn Arrow) then the entire intersection code would have to be modified. The code should be more "modular"; there is no reason why a programmer implementing a new type of light needs to delve into the details of the intersection, nor does the intersection programmer need to know which specific light bulb signals "Left Turn".

The clean coding and extensive documentation is nice, but useless if the code becomes obsolete the instant it confronts the first real-world complication. Admittedly, this is just a test question constructed from a predetermined answer, and the test-taker should be able to guess what the test makers really want in place of an actual scalable design.

This was pre-OOP for me, but you can see how LVOOP might help in points (1) and (2). Problem is, it’s an exam question; any kind of investment up front for pay off in future development is a waste of time because there is no future.

— James
BTW, what about CLA exams? I tried out the practice ATM exam for that and used LVOOP.

[ShaunR]

Think of it this way guys.

An architecture astronought has designed the system (no matter how crap it is) and supplied a spec for a contractor code-monkey to code against. It's not the code-monkeys remit to re-design the system and re-write the spec (that's what the astronought is paid for) - just code to spec. If you (not you specifically, but generally) cannot code to spec, then your not much use within a team of coders lead by an astronought (you could be considered argumentative). That's the first rung you have to master before you can climb to where the oxygen is thinner. That is where the CLD sits - can you follow instruction and documentation. It may not be glamorous, or exercise your artistic/thought provocative nature, but it can be hard and daunting for many-even in classical LabVIEW. When it comes to OOP, it's harder by 10-fold if you aren't of that mind-set and those that are, maybe unsure of how to achieve it in LabVIEW. Whether it is close to real or not is irrelevent. It's to help those at that level by giving examples (in LVOOP) that they can analyse and compare.

I'm just suggesting (with all the super-guru LVOOP talent in Lava) that perhaps if examples of the CLD practise exams where demonstrated with LVPOOP, then maybe a lot more people would grok and maybe ken the advantages/disadvantages and methods. Maybe on your efforts you might see all submissions in the future in LVOOP rather than classical. But if the thread goes in the direction of "it's too simple and uninteresting for LVOOP" or "it's not a real project therfore LVOOP isn't applicable" then those are just weasel words and LVOOP has already failed.

James.
The CLA exams don't target code (you can use the same UML for both right?) and I'm not sure what you could take away from it. But sure, if you have an example, post it.

Edited by ShaunR, 12 February 2012 - 10:13 PM.

[Daklu]

I'm just suggesting (with all the super-guru LVOOP talent in Lava) that perhaps if examples of the CLD practise exams where demonstrated with LVPOOP, then maybe a lot more people would grok and maybe ken the advantages/disadvantages and methods... Whether it is close to real or not is irrelevent. It's to help those at that level by giving examples (in LVOOP) that they can analyse and compare.

It's still not clear to me what the overall goal is.
a. To give examples of how to pass the CLD using LVOOP?
b. To give examples on how to build an application using LVOOP?
c. To compare various LVOOP techniques such as Actors and Observers?
d. To compare traditional Labview vs LVOOP?

Writing a LVOOP solution strictly to the given spec might be useful if the goal is to show how to pass the CLD, but even then it won't be a good way to illustrate good LVOOP practices. The given spec doesn't have value if the goal is any of the other three items.

But if the thread goes in the direction of "it's too simple and uninteresting for LVOOP" or "it's not a real project therfore LVOOP isn't applicable" then those are just weasel words and LVOOP has already failed.

Funny, but the evidence suggests LVOOP has already succeeded. Furthermore, the implied assertion that "LVOOP must be applicable to all situations for it to be successful" is flawed. Sometimes business priorities take precendence over good software design decisions. The CLD exam scenarios are examples of that... all sorts of good practices are sacrificed for the sake of getting done in 4 hours. A bad application spec is not a good foundation on which to compare different techniques.

[ShaunR]

It's still not clear to me what the overall goal is.

Well. I really can't think of any other ways to phrase it that I haven't already.....

then maybe some of the LVOOP gurus could post unofficial, demonstrative LVOOP implementations of the example exams (ATM, traffic lights etc).

To provide (unofficial, demonstration) LVOOP solutions of CLD example exams

for the benefit of potential CLDs

[Daklu]

To provide (unofficial, demonstration) LVOOP solutions of CLD example exams for the benefit of potential CLDs

That doesn't answer my question. How do you want potential CLDs to benefit from the example? What form does the benefit take? What is the potential CLD supposed to take away from the example? Is the goal to get them to pass the test, or is it to show them how to structure a LVOOP application?

The only reason I can think of for posting a minimal (meaning nothing added to accomodate stuff not specifically in the requirements) example LVOOP implementation of the requirements document is to help someone design a solution to the problem. If a potential CLD doesn't know LVOOP well enough to already have a good idea of how to solve the CLD exam problem, they probably shouldn't be using LVOOP in their solution. Traditional LV programming will likely be faster to write and produce simpler source code. Anyone who is knowledgable enough to be using LVOOP on the CLD isn't going to get much value from looking at someone else's minimal implementation since it doesn't reflect reality.

If you wanted to use a sample exam as the starting point, scrub the requirements to make them a little more real-world, and build a solution to that I think there could be a lot of value. But a minimal solution to the given requirements... *shrug*... that's just bad design.

The intent may be for the CLD to be a code monkey working under an astronaut architect. I know of exactly one place where I think that *might* happen... VI Engineering. (And I only say that because Chris is an architect and I know they have lower level developers writing at least some code.) JKI is stocked with CLA's already. There aren't that many big LV development houses around. I believe most CLDs are in fact creating their own designs with little to no architectural oversight. Giving them examples that reinforce a bad design isn't going to help anyone.

[Aristos Queue]

Here you go:
http://lavag.org/top...abview-classes/

[ShaunR]

Here you go:
http://lavag.org/top...abview-classes/

Great.

Traffic lights, car wash anyone?

Edited by ShaunR, 13 February 2012 - 07:02 AM.

[drjdpowell]

James.
The CLA exams don't target code (you can use the same UML for both right?) and I'm not sure what you could take away from it. But sure, if you have an example, post it.

I’m afraid I’ve lost the code itself (computer failure and I never checked it in to my code repository), but I have an image:



This is the CLA practice exam, rather than CLD; those subVIs are mostly empty but for a single comment on what needs to be coded in them.

[SteveChandler]

I posted the sprinkler controller here a while ago.

[ShaunR]

I posted the sprinkler controller here a while ago.

Sweet.
I wonder if we could get an "area" on Lava for these so they are all in one place and easy to find

[jgcode]

Sweet.
I wonder if we could get an "area" on Lava for these so they are all in one place and easy to find

I suggest starting a document in the new knowledge base section - it would definitely suit this use case.

You can turn a thread into a document but I would recommend creating a new document that contains links to these posts.

[asbo]

I was thinking we could just make a new category in the code repository? That's essentially what we're talking about, after all, it just happens to be a specific implementation instead of reuse code.

[jgcode]

I was thinking we could just make a new category in the code repository? That's essentially what we're talking about, after all, it just happens to be a specific implementation instead of reuse code.

I guess the choice will depend on if you want to track the code and related posts (comments etc...) or just the code.

[ShaunR]

I was thinking we could just make a new category in the code repository? That's essentially what we're talking about, after all, it just happens to be a specific implementation instead of reuse code.

I guess the choice will depend on if you want to track the code and related posts (comments etc...) or just the code.

Hmm.
The CR seems a bit "formal" to me but has the "pro" that each submitter is responsible for their submission so no centralised maintenance.

Not keen on the document idea which would basically be just a list of links that someone has to maintain.

I was thinking of just an extra category in the forums (like the Object-Oriented Programming, User Interface, Remote Control, Monitoring and the Internet, etc) that would just pull together the current posts and people could add theirs as and when they were created. People could also use that area for requests for code reviews of examples they want people to comment on.

[asbo]

The upside (IMO) to the CR is the support for versioning. It'd be a little messier as forum posts, but discourse would be a little more complicated.

[Val Brown]

I'm for the CR approach.