Jump to content

OOP for sequential test application


Recommended Posts

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 by Niju Michael
Link to comment

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

Too obvious for my first ninja post? :D

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

  • Like 1
Link to comment

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().

Link to comment

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.

Link to comment
  • 2 weeks later...

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 :angry:) would find it hard to debug.

Link to comment

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:

post-941-0-11404300-1303301283_thumb.png

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

  • Like 1
Link to comment

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 :angry:) 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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.