Question about implementing a Delegation Pattern

[Daklu]

[iE mysteriously posted the message before it was finished. Stay tuned...]

[Phillip Brooks]

QUOTE (Daklu @ Feb 10 2009, 12:54 AM)

I test control panels for microwave ovens.* My testing thus far has been strictly on the module level--my test app communicates directly with the control panel module via I2C. To test devices at the system level, the design engineers are implementing a test mode where the device will copy all I2C data it receives from the control panel to a serial debug port. I have to figure out how to incorporate the new functionality into my current test app architecture. Furthermore, looking forward into the next couple years, it's not clear future control panels will be based on I2C. SPI and serial are real possibilities.

*Not true, but it's a better analogy than my previous toaster examples.

I have nothing to contribute to solving your problem, but since you use a toaster/microwave analogy I had to share this link that I Stumbled Upon last night.

http://www.danielsen.com/jokes/objecttoaster.txt

[Daklu]

QUOTE (Phillip Brooks @ Feb 10 2009, 03:41 AM)

I have nothing to contribute to solving your problem, but since you use a toaster/microwave analogy I had to share this link that I Stumbled Upon last night.

That was funny, but I can't help but have sympathy for the software developer. That advisor was in a no-win situation the moment the king found the toaster. Nobody in their right mind would ask the electrical engineer to "just tweak it so I can cook a ham and cheese omlet" after he shows them the prototype. It's plain by looking at the device that it's not suited for that task and would require extensive redesign.

Software developers aren't so fortunate. It's impossible for a person to get an intuitive understanding of the capabilities and limitations of the software prototype by glancing at the finished product, so they ask for unreasonable requests and expect them to be easily implemented. Eight years ago I was writing test software for an R&D engineer. Every time I sent him updated software, the following morning he was at my desk saying, "Your software is really good, but could you just change it so..." Lather, rinse, repeat. I left that job. Even software developers are guilty of it, as evidenced by the suggestions (mine included) on LAVA for ways to implement Labview fixes.

Moral of the story: Recognize that when your king finds his toaster your goose is cooked.

As an aside, I still haven't figured out how to address my problem.

[jdunham]

QUOTE (Daklu @ Feb 13 2009, 01:16 PM)

That was funny, but I can't help but have sympathy for the software developer. That advisor was in a no-win situation the moment the king found the toaster. Nobody in their right mind would ask the electrical engineer to "just tweak it so I can cook a ham and cheese omlet" after he shows them the prototype. It's plain by looking at the device that it's not suited for that task and would require extensive redesign.

Software developers aren't so fortunate. It's impossible for a person to get an intuitive understanding of the capabilities and limitations of the software prototype by glancing at the finished product, so they ask for unreasonable requests and expect them to be easily implemented. Eight years ago I was writing test software for an R&D engineer. Every time I sent him updated software, the following morning he was at my desk saying, "Your software is really good, but could you just change it so..." Lather, rinse, repeat. I left that job. Even software developers are guilty of it, as evidenced by the suggestions (mine included) on LAVA for ways to implement Labview fixes.

Geez, I hate to deconstruct a joke too far, but the point is that the software developer was the one who projected all the extra requirements by over-generalizing, while the king just wanted a toaster. It's a cautionary tale, to be sure.

[Daklu]

QUOTE (jdunham @ Feb 13 2009, 01:48 PM)

Geez, I hate to deconstruct a joke too far, but the point is that the software developer was the one who projected all the extra requirements by over-generalizing, while the king just wanted a toaster. It's a cautionary tale, to be sure.

Oh I understood the intended message. I just chose to look at the story from a different perspective.

[jdunham]

QUOTE (Daklu @ Feb 13 2009, 01:16 PM)

Software developers aren't so fortunate. It's impossible for a person to get an intuitive understanding of the capabilities and limitations of the software prototype by glancing at the finished product, so they ask for unreasonable requests and expect them to be easily implemented.

I don't believe this is an intractable problem. http://joelonsoftware.com/articles/fog0000000356.html' rel='nofollow' target="_blank">This article from joelonsoftware is somewhat helpful.

QUOTE (Daklu)

As an aside, I still haven't figured out how to address my problem.

I thought about your issue some, but I think there's not enough information for anyone to give you a sensible reply. Not that you didn't give it a good try, but I think if it were easy, you would have solved it on your own, and no one else can know what the really hard parts are.

Like when you said "The current architecture is also limited in that multiple connections to a device are not allowed. I could not control the panel via I2C and simultaneously monitor the microwave's serial output at the same time. " It sounds like your architecture is at fault, so then you should fix it, but it's not clear whether you meant that. Is the problem that your class's private data doesn't have the right information, or do you need to add some kind of locking mechanism to your I/O methods?

OK, you also wrote "What do I do when two independent Interfaces are competing for the same hardware, such as if the IDIO Device and II2C Device both use the same Aardvark? One could change the hardware settings and put the device in a state the other doesn't expect. I think the solution lay somewhere in the Aardvark Class implementation, but I haven't put my finger on it yet. (Maybe a "Lock Settings" property?)". It seems like you should use a mutex, which in LabVIEW is called a semaphore (near the queue palette, and at some point recently they were rewritten to use LV queues).

Maybe you should try to hire a local LabVIEW consultant (obviously you'd need a really good one) just to bounce your ideas off of for a day or so. Sometimes this can be hard to explain to your boss, but it's worth a try.

Good luck,

Jason

[Daklu]

QUOTE (jdunham @ Feb 15 2009, 10:40 PM)

I don't believe this is an intractable problem. http://joelonsoftware.com/articles/fog0000000356.html' rel='nofollow' target="_blank">This article from joelonsoftware is somewhat helpful.

Good article. The recent discussions on the importance of good specification documents also relate to this problem.

QUOTE

I thought about your issue some, but I think there's not enough information for anyone to give you a sensible reply. Not that you didn't give it a good try, but I think if it were easy, you would have solved it on your own, and no one else can know what the really hard parts are.

I appreciate you taking the time to think about it. Being essentially a single developer learning Labview by trial-and-error means I turn to LAVA as a primary resource when I run into problems. Sometimes I can state the problem clearly and concisely; sometimes the scope is broad enough I end up throwing chum in the water to see what surfaces. In this particular case my bait was no good. Reading my posts might leave others puzzled, but at least taking the time to type out a post describing the problem nearly always helps me understand it better.

QUOTE

Like when you said "The current architecture is also limited in that multiple connections to a device are not allowed. I could not control the panel via I2C and simultaneously monitor the microwave's serial output at the same time." It sounds like your architecture is at fault, so then you should fix it, but it's not clear whether you meant that. Is the problem that your class's private data doesn't have the right information, or do you need to add some kind of locking mechanism to your I/O methods?

The root problem is that the new requirements violate the assumptions used to create the original architecture. The original design assumed each control panel will always use a single type of communication. For example, we always use I2C communication to talk to the TouchMagic control panel. To give the TouchMagic child class the ability to talk to the hardware it contains an I2C Interface Base Class object as private data. Now I'm faced not only with supporting multiple communication methods for each device but the possibility of multiple simultaneous communication methods. (Such as sending data to the control panel via I2C and reading the response through the microwave's debug serial port.) One implementation is to create multiple TouchMagic child classes with each one containing a different combination of communication methods. (I2C only, serial uart only, I2C write-serial read, etc.) Following that path will quickly lead to unmaintainable code. There are other short-term hacks I could (and have) implement to provide the immediate functionality required, but it's a path that will get ugly quickly.

Since communication methods are subject to change and the communication hardware classes don't have a common ancestor class, I started looking at interfaces/delegates. Unfortunately there are not many examples of implementing delegates in Labview and I'm uncertain about what the tradeoffs are in implementing them. ("Chum, meet water.")

[Note - Read the end of the post before you spend any significant time thinking about this.]

QUOTE

OK, you also wrote "What do I do when two independent Interfaces are competing for the same hardware, such as if the IDIO Device and II2C Device both use the same Aardvark? One could change the hardware settings and put the device in a state the other doesn't expect. I think the solution lay somewhere in the Aardvark Class implementation, but I haven't put my finger on it yet. (Maybe a "Lock Settings" property?)". It seems like you should use a mutex, which in LabVIEW is called a semaphore (near the queue palette, and at some point recently they were rewritten to use

LV

queues).

My comment was a very poorly worded last minute addition that followed a lengthy line of thought I didn't lay out. Forget I ever mentioned it. (But yes, the semaphore is the solution to that immediate question.)

QUOTE

Maybe you should try to hire a local LabVIEW consultant (obviously you'd need a really good one) just to bounce your ideas off of for a day or so. Sometimes this can be hard to explain to your boss, but it's worth a try.

Been trying for over a year. Not going to happen. As a matter of fact, I just found out my manager is taking the development responsibility for this test system away from me and turning it over to a software test tools team to port the whole thing to c/c++/c#. :headbang: Due to my pointy-hair my questions have become largely academic, but I'll continue researching an answer anyway.