OOP Design Challenge #1

[Daklu]

I've been thinking about starting an Object Oriented Design Challenge as a way to foster discussion about different ways to tackle problems in OOP applications. Lack of time has prevented me from contriving a simple problem to kick off the series, so I'll start with a fairly complex problem I'm facing.

Background:

We have an (incomplete) test sequencer that by fortunate coincidence mostly works. Our application is set up with an abstract Test Case parent with the execution details encapsulated in child classes. We have an internal class library for our devices. The specific device to be tested (Dev1a, Dev2b, etc) is selected by the operator when setting up the test sequence. The device object is passed into each test case before executing it.

The station has been designed now needs to test devices in any one of four test positions. We have internally built switch boxes to control the communication path and signal path to each of the test positions. I wrote drivers (CommMux and SigMux) to control the switch boxes.

The problems:

1. When starting a test case, the initial switch box settings depend on the test case, the device being tested, and the test position. If any one of those changes it requires a different settings for the switch boxes. Switch box settings may also be changed as part of the test case. (There is more to them than just a mux.) New test cases and new devices will be added in the future. No new test positions will be added to the station. (So they say...)
2. It turns out that we also have to communicate with the devices before any test cases are started, or have even been selected. This communication path can be determined based on the device and test position--it doesn't depend on the specific test case.

The questions:

With 37 test cases, 12 devices, and 4 test positions, how would you add this functionality into the application in a way that promotes the expected extendability, without creating a separate case for each combination? How do you structure this in a way that the functionality is available to solve problem 1 and problem 2?

I have some thoughts on ways to go about this, but I'll withhold them for now so I don't pollute the idea space.

[K-node]

I've been thinking about starting an Object Oriented Design Challenge as a way to foster discussion about different ways to tackle problems in OOP applications. Lack of time has prevented me from contriving a simple problem to kick off the series, so I'll start with a fairly complex problem I'm facing.

Background:

We have an (incomplete) test sequencer that by fortunate coincidence mostly works. Our application is set up with an abstract Test Case parent with the execution details encapsulated in child classes. We have an internal class library for our devices. The specific device to be tested (Dev1a, Dev2b, etc) is selected by the operator when setting up the test sequence. The device object is passed into each test case before executing it.

The station has been designed now needs to test devices in any one of four test positions. We have internally built switch boxes to control the communication path and signal path to each of the test positions. I wrote drivers (CommMux and SigMux) to control the switch boxes.

The problems:

1. When starting a test case, the initial switch box settings depend on the test case, the device being tested, and the test position. If any one of those changes it requires a different settings for the switch boxes. Switch box settings may also be changed as part of the test case. (There is more to them than just a mux.) New test cases and new devices will be added in the future. No new test positions will be added to the station. (So they say...)
2. It turns out that we also have to communicate with the devices before any test cases are started, or have even been selected. This communication path can be determined based on the device and test position--it doesn't depend on the specific test case.

The questions:

With 37 test cases, 12 devices, and 4 test positions, how would you add this functionality into the application in a way that promotes the expected extendability, without creating a separate case for each combination? How do you structure this in a way that the functionality is available to solve problem 1 and problem 2?

I have some thoughts on ways to go about this, but I'll withhold them for now so I don't pollute the idea space.

OK, Daklu, time for some fun. How is your solution to this going?

If I understand this correctly...

SwitchBoxSettings_Initial = f(TestCase, TestDevice, TestPosition)

SwitchBoxSettings_Changed = f(TestCase)

and

CommunicationPath = f(TestDevice, TestPosition)

Is the SwitchBoxSettings_Changed also a function of SwitchBoxSettings_Initial and does it change over the duration of the TestCase? Would it need to notify a client that it is time for a change?

I am leaning toward a SwitchBoxSetting class and probably a SwitchBoxSettingManager. Each SwitchBoxSetting instance would retain the trio that defines it along with all of the settings native to the SwitchBox. The SwitchBoxManager could return a SwitchBoxSetting for the trio of TestCase, TestDevice and TestPosition. It would run through it's internal collection of SwitchBoxSettings and return the one (or perhaps set) that qualifies.

I have created my own ISerializable interface and SerializationInfo class that allows me to write the structure of a class to an XML file and later read it in. It would be possible to add new SwitchBoxSetting instances by editing the XML. You just have to know what the fields mean and the valid values. In my implementation, reconsituting the XML into LabView requires a 'factory' that can map class name to class instance. This eliminates the need to change any LV code if a new SBS is required or an existing one needs to be altered.

Right now I am avoiding the issue of SBS_Changed. It can be implemented via a Manager approach, but I am not completely sure how it works.

[Daklu]

OK, Daklu, time for some fun. How is your solution to this going?

Geez Kugr, this was six months ago... you expect me to remember?

Okay. Umm... we have a solution that is working so I must have addressed my concerns, but to be honest I have no idea what that solution is. I'll have to go back and look at the code. I'm also not sure why I thought I'd have to create a separate case for each combination of test case, device, and position, or what I was thinking for a solution when I posted this question. I need to dredge the depths of my brain...

(No wonder nobody responded to this post. Looking at it now I have no idea what I'm talking about.)

If I understand this correctly...

SwitchBoxSettings_Initial = f(TestCase, TestDevice, TestPosition)

SwitchBoxSettings_Changed = f(TestCase)

and

CommunicationPath = f(TestDevice, TestPosition)

That much, I recall, is correct.

Is the SwitchBoxSettings_Changed also a function of SwitchBoxSettings_Initial

I don't think so, all the switches that are changed during a test case reroute the signals through attenuators and to different instruments. If I'm running test case x the internal switching isn't different if the device is in slot 3 as opposed to slot 2.

and does it change over the duration of the TestCase?

Switching does need to occur at any arbitrary (but well-defined) point while the test case is executing.

Would it need to notify a client that it is time for a change?

Nope. In our implementation the switching takes place on the test case execution thread.

I am leaning toward a SwitchBoxSetting class and probably a SwitchBoxSettingManager. Each SwitchBoxSetting instance would retain the trio that defines it along with all of the settings native to the SwitchBox. The SwitchBoxManager could return a SwitchBoxSetting for the trio of TestCase, TestDevice and TestPosition. It would run through it's internal collection of SwitchBoxSettings and return the one (or perhaps set) that qualifies.

I'll review my code when I get some time and let you know what I find.

[K-node]

Geez Kugr, this was six months ago... you expect me to remember?

LOL. I had some time (procrastinating on the documentation), so I was reviewing old posts.

I'll review my code when I get some time and let you know what I find.

That's OK. It is not important. I'd rather press ahead on new problems.

kugr