J
Joris Dobbelsteen
I'm having a slight design/modeling problem and hopefully someone can
provide me with some good advice or hints.
The problem is that I have a sensor that captures the time period of an
object passing.
The software has a communication layer capable of correctly filtering frames
(just like a packet filter). Each frame has a command code and a fixed
amount of data.
On top of this layer their must be an abstraction of the sensors functions.
This is where the problem arises.
A key problem is to keep the software extendible with minimal future effort.
Currently there exists only a single sensor, which is capable of capturing
from a single source.
A future model would extend this functionality with a secondary channel to
capture a signal from a very accurate time source, including several other
properties.
Probably the most simple way would be to implement each sensor into a
distinct class. This would be simple, but very bad practice. On the long run
it does not work.
My second idea was to provide a fixed interface for a sensor, where each
sensor has different distinct modules. Each module would provides some
functionality, where one is used for the captured signal, a second for the
accurate time source. The hardware should advertise these capabilities and
the software would copy these. This demand only a modification in order to
a) provide new functionality
b) correct problems that arise
- Joris
provide me with some good advice or hints.
The problem is that I have a sensor that captures the time period of an
object passing.
The software has a communication layer capable of correctly filtering frames
(just like a packet filter). Each frame has a command code and a fixed
amount of data.
On top of this layer their must be an abstraction of the sensors functions.
This is where the problem arises.
A key problem is to keep the software extendible with minimal future effort.
Currently there exists only a single sensor, which is capable of capturing
from a single source.
A future model would extend this functionality with a secondary channel to
capture a signal from a very accurate time source, including several other
properties.
Probably the most simple way would be to implement each sensor into a
distinct class. This would be simple, but very bad practice. On the long run
it does not work.
My second idea was to provide a fixed interface for a sensor, where each
sensor has different distinct modules. Each module would provides some
functionality, where one is used for the captured signal, a second for the
accurate time source. The hardware should advertise these capabilities and
the software would copy these. This demand only a modification in order to
a) provide new functionality
b) correct problems that arise
- Joris