A class questions about my system

[Maxwell_Peng]

Hello, everybody.I'm new to the LVOOP and I meet a problem in my wafer auto-test system about the class responsibility.

 

    the wafer auto-test system uses many instruments to measure the wafer parameters such as Vbr, Vf... Firstly, I want build class for every instrument. For example, I have create a app class named WaferTester, and many instrument classes such as Keithy 2600B class, EXFO PM1600 class, etc. The WaferTester class contains these instrument classes. However, I also want to create parameter class such as Vbr class, Vf class. These parameter class have many properties such as test delay time, upper limit, lower limit etc. Most importantly, the parameter class have a method to get parameter measurement result. For example, when calling the measure method of Vbr class, it use instrument to measure the Vbr parameter of the wafer and return it to the caller. My question is about the relationship the instrument class and the parameter class. The method of parameter class will use different instrument classes, so the instrument classes is a part of the parameter class. For example, the Vbr class will contain Keithy 2600B class. However, different parameter class may use the same instrument and I think the instrument is a static part of the test system. I have no idea to achieve a reasonable relationship about the parameter class and the instrument class.

[PaulL]

My first piece of advice is to create a UML model of your system.  This will help you and others understand it better.

Second, it's not clear to me what your "parameter classes"  actually are.  It sounds to me like they are actually tests, but also include test configurations.  Perhaps you can clarify.

[MikaelH]

If you are new to OO, NI's GOOP Development tool, will make life easier fot you, BTW it's free.

Check out the videos at the community page to see if this tool is for you.

https://decibel.ni.com/content/message/44088#44088

[Maxwell_Peng]

My first piece of advice is to create a UML model of your system.  This will help you and others understand it better.

Second, it's not clear to me what your "parameter classes"  actually are.  It sounds to me like they are actually tests, but also include test configurations.  Perhaps you can clarify.

 

Thanks for your advice！

 

The "Parameter Class" is a abstract class, it has many properties. For example, a parameter class has properties named "upper limit" and "lower limit" to judge the parameter test value is pass or fail. Many child class will inherit from the "Prameter Class", For example, the Vbr class is a child class of the "Parameter Class". The difference between these child parameter classes is the way to get its parameter test value. For example, when call the GetParameterTestValue() mehod of Vbr class(Child class of Parameter Class), it will make Keithley 2635A to output a current and measure a voltage, then return the voltage measure value to the caller. For the Cj class which is also inherit from the "Parameter Class", it will use Agilent E4980A to measure the capacity of the UUT. 

 

My actual question is about the relationship between the "Parameter Class" and the "Instrument Class". In LabVIEW, the class object is a instance, if the Vbr class want to use a instrument, it must contain a Instrument class object instance. For example, if I want to measure three parameters and they use Keithley 2635A both, so every parameter class will contain a Keithley 2635A class instance. However, a test system only have one Keithley 2635A and it should be shared by multi paramter class. If LabVIEW approve for using "class reference" which is similar to the pointer in C language or reference type in Java, the instrument share problem can be solved. But everything in LabVIEW is a "Value" which occupies some memory.

[PaulL]

Thanks for your advice！

 

The "Parameter Class" is a abstract class, it has many properties. For example, a parameter class has properties named "upper limit" and "lower limit" to judge the parameter test value is pass or fail. Many child class will inherit from the "Prameter Class", For example, the Vbr class is a child class of the "Parameter Class". The difference between these child parameter classes is the way to get its parameter test value. For example, when call the GetParameterTestValue() mehod of Vbr class(Child class of Parameter Class), it will make Keithley 2635A to output a current and measure a voltage, then return the voltage measure value to the caller. For the Cj class which is also inherit from the "Parameter Class", it will use Agilent E4980A to measure the capacity of the UUT. 

 

My actual question is about the relationship between the "Parameter Class" and the "Instrument Class". In LabVIEW, the class object is a instance, if the Vbr class want to use a instrument, it must contain a Instrument class object instance. For example, if I want to measure three parameters and they use Keithley 2635A both, so every parameter class will contain a Keithley 2635A class instance. However, a test system only have one Keithley 2635A and it should be shared by multi paramter class. If LabVIEW approve for using "class reference" which is similar to the pointer in C language or reference type in Java, the instrument share problem can be solved. But everything in LabVIEW is a "Value" which occupies some memory.

1) LabVIEW does have some sort of native object reference support.  I (somewhat controversially) don't recommend that you use that, however, since a) it is neither clean nor pretty, and b) the better thing to do in most or all cases is to clean up the design.

2) Take a closer look at your design.  I think it would be preferable if the Parameter Class didn't know about the instrument at all, but it is hard to tell that for sure from your description.  (I can actually see why you might have such a relationship, but without knowing more details about the system it is impossible to offer a recommendation here.)  Again, I recommend creating a UML model of your system, both to clarify the issues in your mind, and to facilitate sharing your vision with your interlocutors.  It is essential to understand the relationships between the different classes here.  There may be a more appropriate way to relate these items.

Paul

OK, you wrote that that "different parameter class may use the same instrument and I think the instrument is a static part of the test system."  So, why not make a test system class that has an instrument as one of its attributes, and a collection of parameter classes (that do not have references to the instrument!) as another attribute?  The answer will get slightly more complicated if, as I suspect is the case, multiple instruments may be present within an application.  I don't think this will be difficult to accommodate, though.  (As a first approach, for instance, you can have a an array of clusters, where each cluster contains an Enum indicating the instrument, and a set of measurement parameters.  Or something like that.)  Let's establish what you need, though, first.