OOP for sequential test application

[Frabto]

Hi All,

I have a application where in 3 types of boards has to be tested.

Board A - 12 tests

Board B - 7 tests

Boars C - 5 tests

All these 24 tests has to be done sequentially.The user can disable certain tests.So the number of tests are not fixed.What would be the best LVOOP architecture(Pattern) to be used for this application.

Should I use Factory pattern with Classes for each tests which means 24 + classes.I welcome suggestions or any examples.

Edited April 7, 2011 by Niju Michael

[crelf]

I welcome suggestions...

Use TestStand.

[ShaunR]

+1 for test-stand.

However. There is an example of board testing using using OOP shipped with labview that will give you a good start (just put "object-oriented " in the examples finder)

[Yair]

There is an example of board testing using using OOP shipped with labview that will give you a good start

I see that Daklu has finally managed to hack into Shaun's account.

[jgcode]

I see that Daklu has finally managed to hack into Shaun's account.

Lol

I think ShaunR is safe here given that he responded based on the thread title as opposed to recommending it as a prefferred solution.

[Daklu]

I see that Daklu has finally managed to hack into Shaun's account.

Too obvious for my first ninja post?

What would be the best LVOOP architecture(Pattern) to be used for this application.

Assuming you're going to be developing and supporting the application, the "best" architecture is one you understand that satisfies the requirements. There are far too many unknown requirements for us to suggest one for you. I prefer loosely coupled code, so I tend to use a lot of messaging and parallel loops. It may or may not work for your situation.

Should I use Factory pattern with Classes for each tests which means 24 + classes.I welcome suggestions or any examples.

Can't answer that without knowing more about the tests. If the tests are similar, it's possible you could have one test class that takes different runtime parameters for each test. However, one class for each test is easier to understand if you're just starting in OOP. Whether or not you should use the factory pattern is an entirely different question. Personally I'll use a factory if I have to gather or process a lot of data prior to creating a new object. Otherwise I don't get much benefit out of it.

Assuming Test Stand isn't an option for you, I've attached a simple sequencer component I've been working on and planning on releasing through LapDog. Sequencer.lvlib is the reuse component. SampleApp.lvlib is the start of an example showing how to use it, though it is incomplete and not functional yet. You do need to install the LapDog Message Library before opening the project. You can get it from SourceForge.

[Edit Apr 8 2011 - Attached correct zip file.]

[Edit Apr 10 2011 - Added project with working example. (LapDog.SimpleSequencer v0.8.zip)]

Simple Sequencer with incomplete Sample App.zip

LapDog.SimpleSequencer v0.8.zip

[Frabto]

Yes,Test Stand isn't a option for me.

Daklu,

Can you please post ' SampleApp.lvlib'.I don't find it in the above attachment.Thanks for the Sequencer library

[Daklu]

Can you please post ' SampleApp.lvlib'.I don't find it in the above attachment.

Whoops, sorry. I've replaced the incorrect zip file in the post above with the correct zip file.

A couple notes about the sequencer:

* Each step you create must be a child of SequenceStep.lvclass. A step can contain as much or as little functionality as you want.

* SequenceSlave supports Start, Stop, Pause, and Unpause out of the box. (Pause will take effect after the current step finishes executing.)

* This sequencer doesn't support nested sequences, though I am also working on another version that does.

* It is the library user's (that's you) responsibility to build the user interface allowing end users to select which steps will be run.

* Once you know which steps should be executed, create an array of steps and pass it to SequenceSlave.Start().

[Daklu]

There is an example of board testing using using OOP shipped with labview that will give you a good start

Huh... that example has been completely rewritten since the last time I looked at it. I think this version (in LV 10) is much more useful than the previous version. Thanks for pointing it out.

[Frabto]

Whoops, sorry. I've replaced the incorrect zip file in the post above with the correct zip file.

Thanks again .I will take few days/weeks!! to understand this as Iam new to OOP concepts

Edited April 9, 2011 by Niju

[Daklu]

Thanks again .I will take few days/weeks!! to understand this as Iam new to OOP concepts

Feel free to post any questions you have. People are always willing to help.

[Daklu]

FYI, I added a project with a working sample application to my post above.

[MikaelH]

Hi

This is my normal solution for this type of problem.

Cheers,

Mikael

[Frabto]

Mikael, your UML diagram really gave me some good idea

Daklu,

Lapdog library is very useful.

Sequencer lib example provided more insights on OOP programming.Your threads are very useful for a OOP novice like me.

However in Seq library , it appears more importance is given to the handling of messages rather than the tests to be done.A new developer will little knowledge in OOP (like me ) would find it hard to debug.

[MikaelH]

Mikael, your UML diagram really gave me some good idea

I suggest that every time you create a new Method in your class, check if it can be placed in the generic base class or if it belongs to the Real test class.

I normally create these methods in a Test Case class:

The Main VI could be called stand alone or be a sub VI in a top level application.

If the Main VI is runs stand alone I normally make sure the TestCase Base constructor creates all instruments needed for the test case.

You can use Symbio's UML modeller to create your LabVIEW classes direct from the UML class diagram.

Cheers,

Mike

[Daklu]

However in Seq library , it appears more importance is given to the handling of messages rather than the tests to be done.

The messaging infrastructure is definitely more visible, but it's not more important to the application's purpose. The messaging system is the glue that ties all the different functional pieces (loops) together, so it's going to be very visible.

A new developer will little knowledge in OOP (like me ) would find it hard to debug.

Yep, that doesn't surprise me. Object-oriented programming is very different than procedural programming. It takes time to make the shift from procedural programming to the thought processes, patterns, and debugging techniques of OO developers. There's really no way around that, but the more you do it the easier it becomes.