CLD sample exam organized using LabVIEW classes

[Aristos Queue]

If you want to see a Certified LabVIEW Developer sample exam written using LabVIEW classes, I am uploading one here. I built this over the last four hours in response to comments in another LAVA thread which correctly pointed out that a sample CLD written with classes was not available for review.

• If you wish to comment on improving this class-based sample exam or ask questions about how it works, please post them here.
  
• If you wish to debate whether LabVIEW classes are worth using or whether they are overkill for real apps (including for the CLD exam itself), or any other philosophy, please post in the original thread that spawned this.
  

The sample exam that I did was ATM version 2 (I am attaching the PDF to this post for ease of reference). After 4 hours, I have the solution posted below. It is not a fully fleshed out app -- it is exactly what I have finished after 4 hours and would have turned in on the exam. It is very similar to what I turned in for my actual exam, although I will note that for my actual CLD, I specifically brushed up on file handling and had that working. Tonight, I was unable to recall my cramming, so that just got dropped (but documented as a TODO!).

Top level VI is ATM UI.lvclass:Main.vi. This VI takes an ATM UI object as input in case configuration options are added to this application in the future -- those options are already part of the UI loop.

Issues that I know of:

• File I/O is not done, as I mentioned above.
  
• The display strings are placeholders ... I didn't type out all the proper strings.
  
• There's no way for the user's name to be displayed when they put in their card.
  
• Although I documented the VIs, I did not fill in documentation into the classes themselves and probably should have.
  

Other than that, I think it all works given the limited testing I was able to do within the 4 hours.

I have no idea why I felt the need to make setting the display message go through an event instead of just setting the local variable every time. I think i had it in my head to bottleneck the localization, but that doesn't work, of course, because you have to be able to format information into the strings. That should probably be removed entirely.

I did build a message abstraction from ATM UI to ATM, but I didn't build a messaging abstraction from ATM to ATM UI. Why? Because I thought the data needed to respond was always the same. It wasn't until later that I decided that was a mistake, but I figured I should finish out this way. Building a true abstraction layer for completely isolating the ATM from the ATM UI is probably more than can be done in the 4 hour block unless you've got some scripting tools to back you up -- we'll have to see if it's reasonable in LV 2012 (without going into detail, assuming the beta testing goes well, there will be tools to help this exact problem in 2012).

100928-01.pdf

AQ_ATM2.zip

Edited February 13, 2012 by Aristos Queue

[Amir_Y]

Hi Aristos Queue,

First of all, thank you for posting your solution. At last we can see some simple examples of LVOOP.

There are two things I would have done differently, one major the other minor:

1. The (action wrapper VI) would be a method of the "ATM.lvclass".

The "ATM Massage.lvclass" would only be used for transfering the massage, not for doing the action. The massage would contain typedef enum named "Action" as private data. see here.

Inside the case structure I would put dynamic dispatch VIs for handling the actions, so ATMs that will inherit from a more generic ATM would override these actions if needed. The massages will remain the same for all ATMs.

So, my point here is: The action should done by the ATM not by the Massage.

2. I would make the massage event data type a typedef enum. It will be more strict and readable then free text.

Regards,

Amir Y.

Edited February 14, 2012 by Amir_Y

[Aristos Queue]

Regarding 1: I strongly disagree. That puts you right back to an enum which is what we are trying to eliminate . The current solution I posted has the message carry with it the instructions to perform so the set of actions possible is open ended.

[Amir_Y]

Two things here:

1. Strictly thinking you are right about eliminating enums and case structures, but in my opinion, you should sometimes use them to improve readability and access. Enum is easy to read. Case structure is easy to access. When you open the action wrapper VI, you know which action you are looking for. Finding it in the case structure is much easier (and readable) than than double-clicking a dynamic dispatch VI which open a dialog where you have to look for the desired action.

2. "Do Core" VIs as part of the message seems a mix-up to me. The action should be done by dynamic dispatch methods of the ATM, so each inherited ATM could preform the action differently. Message object should only transfer the message (and it will be the same to all ATMs).

Amir.

[Daklu]

Amir, remember the goal is to pass the exam, not create a well-designed application. I'm not saying AQ's submission isn't well-designed, but the design is secondary to the functionality. (Incidentally, this is exactly why I resisted so much in the other thread. It's impossible to justify a design based on a bad spec document.)

Finding it in the case structure is much easier (and readable) than than double-clicking a dynamic dispatch VI which open a dialog where you have to look for the desired action.

Personally I agree. However, people place different values on the various tradeoffs. AQ tends to favor code that is verifiably correct. He's willing to give up a bit of readability to achieve that. I can't see that either approach is objectively better than the other. They each have their pros and cons.

2. "Do Core" VIs as part of the message seems a mix-up to me. The action should be done by dynamic dispatch methods of the ATM, so each inherited ATM could preform the action differently. Message object should only transfer the message (and it will be the same to all ATMs).

What inherited ATM? The spec doesn't say anything about multiple types of ATMs. I agree it's a natural extension point an alert developer should discuss with the customer, but it's not in the spec and (presumably) isn't going to gain you any points.

(The spec does say "Be easily scalable to add more states / features without having to manually update the hierarchy." Unfortunately that's way too vague to be a helpful guideline when making detailed design decisions.)

[jdebuhr]

Thnaks for doing this, It is helping me to understand more of how the classes work..