Certification
CLA Attempt - ATM
Dear NI Community,
Following on from my previous attemt at the Elevator CLA past paper, I attempted the ATM CLA past paper today and was looking for some further feedback and help with how to pass the exam. Based on the feedback from the Elevator I have tried to plan how I went about the exam more wisely.
Enjoy, and once again - any feedback would be greatly received 🙂
Thanks in advance,
MUCH better. Just some more comments though.
1. Do not show the label for EVERY function, especially the primitives. The context help can tell you what those are. You are just wasting time by actually showing the labels.
2. You can GREATLY simplify your Communications Action Engine simply by getting rid of the queues. You have comments that the developer needs to be careful and only use the User Event to communicate between modules. So do not even give them the opportunity to mess it up. Create the queues directly on the modules that will use them. Only pass the User Event around in the Action Engine.
3. For the Display Console, you do not need to call the User Event just to update the screen for EVERY case. Do the update inside of the message handler loop by unbundling directly off of the shift register (still inside of the loop). This will help the other modules as well since they will have to process the User Event as well (even if they are not doing anything with it).
I only made mods to the Display Console and the Action Engine so you can see what I am talking about (at least for points 2 and 3).
Thank you for the feedback, and good luck with your CLA. I use the user event to pass global messages around. Which each module is registered to listen to, and each module itself is a queued message handler.
Might not be the best way, since the default case in the case structure for the user event is just wired through but it gets the job done.
Thanks,
Rob
Hi Prithviraj,
Q1. This architecture was something I had seen from a sample solution and seemed to be what I was after for a more complex application I was working on. It seems like the CLD is more concerned with how you code up one module and the CLA is how you would code up several modules that can communicate with each other. Hence why the user event brings everything together through inter-process communication 🙂
The reason why I describe it as a model-view-controller is because all the controls AND indicators can exist in the event stucture (view) and be updated by user events. This allows me to pass global updates to modules running in separate independent threads and handle the event accordingly e.g. start/pause/stop etc. It would be quite easy to swap the data cluster for an object (model) and bring all the advantages of OOP e.g inheritance into the module. The Queued Message Handler in the consumer loop (controller) is then the action engine that can execute the relevant methods in the class.
Please see https://decibel.ni.com/content/docs/DOC-31625
When I develop code nowadays I have since found a love for sub-panels as it allows me to have several modules running in asynchronous threads independently of one another in the background and I can just display the relevant module to my user as and when required.
Q2. I would let the developer build the cluster, but it wouldn't harm to think about what data types might go into it (or if you are in OOP speak then what properties & methods the class has). If you comment it as per the requirements document then this would be a good idea.
Q3. I don't code my queues up in this way anymore in reality mainly because I want to have multiple instances of modules running asynchronously so need to dynamically create queues. I would have the obtain queue and enqueue (initialise) inside the module itself now.
I hope this isn't information overload and don't forget that simpler architectures can still solve complex problems (occam's razor) - but hope this helps.
Thanks,
