I could use some help with the model for our lab's measurement software. I'm an electrical engineer most of the time but I am also the software developer since we are small and I'm the most qualified. I have migrated our code from VB6 to VB.NET and finally to C# after learning generics with C# examples and became tired of VB syntax. I've read books on design patterns and but it's still a bit ambigous to me.
In a nutshell, the software basically talks to a device which performs a measurement on a widget, and then exports the results. Most often, another device(s) will 'perturb' the setup for additional measurements. We have a variety of measuring devices, perturbing devices, and exporting targets. The original software was procedural with a heavy GUI. It severely lacked reusability and extensibility becase each device had unique capabilities.
After analyzing the trends, I narrowed the model down to four primary classes: Measurement, MetrologyDevice, Permuter, and Exporter. Each device could be configured before the measurement and a handful of required properties/methods could be handled through a common interface. PropertyGrids are used for everything, so the code for the GUI is inside each class as a TypeDescriptor/TypeConverter and not tied to a specific GUI. Here's a list of the primary classes and their interfaces:
Exporter -Takes data and exports it to a file, UI, another app, or database, etc.
IExporter
Export(data)
Permuter -Implements a change to be measured. An example of a Permuter is a motion control axis or a furnace temperature controller.
IPermuter
DoSomething()
event StatusUpdate(status) (Waiting, Done, Finished, Error)(Done signifies a completed a permutation while finished signifies it has completed all of its permutations defined by start/stop/step or a list of values)
MetrologyDevice -Performs the measurement which generates a dataset to be stored. Spectrum analyzer, digital I/O, A/D, variety of electronic gauges, etc.
IMetrologyDevice
DoSomething()
event StatusUpdate(status) (Waiting, Done, Error)
Measurement -Primary interface between user/gui & devices. Implementation of either 'chain of responsibility' or 'mediator'
IMeasurement
Start()
Stop()
Pause()
event StatusUpdate(status) (Ready, Measuring, Done, Error)
List(of IMetrologyDevice)
List(of IPermuter)
List(of IExporter)
There can be any number of Permuters, typically a combination of others in parallel and serial. I currently have the model using a mediator, PermuterMaster, which governs when each permuter should DoSomething(). It would poll each Permuter to see if it's done, tell the MetrologyDevice to measure, get the data, and send it to the Export object.
As an alternative, I could implement a chain of command, where the Measurement class sets up event delegations so that each object notifies the appropiate peer/parent. A permuter would tell the parent permuter it's done, which would then tell the MetrologyDevice it's done, which would send the data to the Exporter, which would tell the Permuters to permute again. Both methods will work fine but I can't figure out which is best. I'm leaning towards chain of command the more I think about it. As I look at what I just typed above, I also noticed that IPermuter and IMetrologyDevice only differ in the fact that IPermuter has one extra status, 'completely done'. Would combining both be logical? Any insight would be greatly appreciated!![[glasses]](/data/assets/smilies/glasses.gif "[glasses] [glasses]")
In a nutshell, the software basically talks to a device which performs a measurement on a widget, and then exports the results. Most often, another device(s) will 'perturb' the setup for additional measurements. We have a variety of measuring devices, perturbing devices, and exporting targets. The original software was procedural with a heavy GUI. It severely lacked reusability and extensibility becase each device had unique capabilities.
After analyzing the trends, I narrowed the model down to four primary classes: Measurement, MetrologyDevice, Permuter, and Exporter. Each device could be configured before the measurement and a handful of required properties/methods could be handled through a common interface. PropertyGrids are used for everything, so the code for the GUI is inside each class as a TypeDescriptor/TypeConverter and not tied to a specific GUI. Here's a list of the primary classes and their interfaces:
Exporter -Takes data and exports it to a file, UI, another app, or database, etc.
IExporter
Export(data)
Permuter -Implements a change to be measured. An example of a Permuter is a motion control axis or a furnace temperature controller.
IPermuter
DoSomething()
event StatusUpdate(status) (Waiting, Done, Finished, Error)(Done signifies a completed a permutation while finished signifies it has completed all of its permutations defined by start/stop/step or a list of values)
MetrologyDevice -Performs the measurement which generates a dataset to be stored. Spectrum analyzer, digital I/O, A/D, variety of electronic gauges, etc.
IMetrologyDevice
DoSomething()
event StatusUpdate(status) (Waiting, Done, Error)
Measurement -Primary interface between user/gui & devices. Implementation of either 'chain of responsibility' or 'mediator'
IMeasurement
Start()
Stop()
Pause()
event StatusUpdate(status) (Ready, Measuring, Done, Error)
List(of IMetrologyDevice)
List(of IPermuter)
List(of IExporter)
There can be any number of Permuters, typically a combination of others in parallel and serial. I currently have the model using a mediator, PermuterMaster, which governs when each permuter should DoSomething(). It would poll each Permuter to see if it's done, tell the MetrologyDevice to measure, get the data, and send it to the Export object.
As an alternative, I could implement a chain of command, where the Measurement class sets up event delegations so that each object notifies the appropiate peer/parent. A permuter would tell the parent permuter it's done, which would then tell the MetrologyDevice it's done, which would send the data to the Exporter, which would tell the Permuters to permute again. Both methods will work fine but I can't figure out which is best. I'm leaning towards chain of command the more I think about it. As I look at what I just typed above, I also noticed that IPermuter and IMetrologyDevice only differ in the fact that IPermuter has one extra status, 'completely done'. Would combining both be logical? Any insight would be greatly appreciated!
There may be other insights we could provide, but for now that's all I got.