From: Dave (dfisher_at_pophost.com)
Date: 2002-03-20 13:56:58
John--I had hoped to have more comprehensive feedback (in the form of a UML
diagram), but I am going to have to resort to typed descriptions, as I am
running out of time today. I also found out yesterday that I misunderstood
some out-of-town flight arrangements, and I am leavning tomorrow morning, which
is not when I thought I would. So I will be out-of-pocket from tomorrow (20th)
to Monday (the 25th).
Sooo..... input on your class structures. I am not going to include parameters
to methods or data types at this time, but will flesh that out if you like when
I get back next week.
Class:
HWInterface
Purpose:
Controls the physical hardware interface (such as USB or COM ports) used
to communicate with the biosensory device.
Inheritance: none (base class)
Methods:
Constructor and/or Init() - Initializes/Opens the device
ReadData() - reads a block of characters from the device
WriteData() - writes a block of characters to the device
Destructor and/or Close() - closes device
Data:
name of physical device (string)
Notes:
The ReadData() and WriteData() methods will need to be pure virtual functions
in order to force implementation of them in the inherited classes. Now, with
that in mind, a class with pure virtual functions cannot be instantiated, as
you have in BioDevice, because you don't know what kind of device this is (is
it InterfaceSerial, is it IntefaceUSB?). I think what you need to do is move
the HWInterface class as in instantiation in the DevModularEEG/DevProComp
classes, or have those classes inherit the actual sub-classes InterfaceSerial,
interfaceUSB, etc., depending on what kind of device interface they use.
For example, currently there is a serial version of the ProComp, and a USB one
being developed. Thus, in the class structure you have, you might want to have
DevProComp inherit InterfaceSerial, and perhaps name it something like I did in
my Linux code, such as DevProCompSerial to distinguish it from a ProComp
attached to a different interface. Does that make sense, or is there a better
way to do this?
And some comments on the BioDevice. We are going to need a means to read the
capabilities of a biosensory device from a file, kind of like a "termcap" file
for biodevices. I guess that would make it a "biodevcap" file. This file
would have a name for each device supported by the API and it's capabilities,
such as biosensors supported, etc. Right now, this can be hard-coded in the
Device class (such as DevModularEEG), but for manipulation purposes (though a
GUI or somesuch) when someone is going to want to select a sensor and attach it
to a protocol or do something else with it, it might make more sense to grab
that information a file. 'Course, some of this stuff might not ever change
(such as supported sensors, baud rate for serial interfaces, etc.), so maybe it
makes sense to have this hard-coded for the device? If you think this is a
good idea, then we would have something like a BioDevCap class which can be
either be instantiated in the BioDevice class, or inherited by it.
A related issue would be the configuration of the device -- such as just what
each sensor is. For example, if a device has 10 channels, any of which can
have various sensor's attached (where Channel 1 might be EEG, Channel 2 might
be EEG, Channel 3 termparature, etc.), we would need to be able tell the
BioDevice just what *kind* of sensor was attached to the channel. On some
devices this is going to be fixed, such as the BrainMaster and hardware being
developed here in this group. For other devices, this is not fixed. This is a
prime candidate for information that can reside in a BioDevCap file -- listing
out just what sensors can be attached to the available channels of the device.
Perhaps the BioDevCap text format can be something like this:
BioDeviceName BrainMaster
NumChannels 2
// List of all possible modalities for this device
SensorType EEG
// List of all channels, and what modalities each channel can support
Channel 1 EEG
Channel 2 EEG
BioDeviceName ProComp
NumChannels 8
SensorType EEG
SensorType ECG
SensorType SC
SensorType Temperature
SensorType Respiration
SensorType EMG
Channel 1 EEG
Channel 2 EEG
Channel 3 ECG, SC, Temperature, Respiration, EMG
Channel 4 ECG, SC, Temperature, Respiration, EMG
Channel 5 ECG, SC, Temperature, Respiration, EMG
...
Channel 8 ECG, SC, Temperature, Respiration, EMG
I did not list out all the modalities, but you get the idea.
Thus, some additions to BioDevice might be:
Class:
BioDevice
Purpose:
Defines and manages the biosensory device and data streams.
Inheritance: BioDevCap?
Methods:
Data:
name of entry in BioDevCap (string)
number of channels (int)
array/vectored list of *possible* modalities (vector)
list of channels with connected BioSensors (vector)
I guess it would be up to the controlling UI to make sure that a modality did
not get connected to an incorrect channel, unless everyone thinks that should
be error-checked in the BioDevice class. Ok; in that regard, the BioDevice
class is going to need a control/setup mechanism. This is going to get tough,
because there are a variety of devices out there, all with different
capabilities. It's almost like having an unknown quantity of features, like
for printers. For example, you would never send information *to* the ProComp.
It is a "send only" device. However, you would for the BrainMaster, to put it
in one or two channel mode. Some devices will provide extra information, such
as serial numbers, battery levels, or what mode they are in. So I guess all
this other stuff gets relegated to the sub-class defining the particular device
itself.
I've also been thinking about the Model-View-Controller pattern, and now it
would relates to this design, and I am fuzzy on how it would be implemented for
the following reasons:
1. We will need views into the data for various BioSensors
2. We will need controllers for the various BioDevices
Thus, who inherits the Model class? Would this be done in BioDevice? That
would make some sense, except that when another class wants to register a view
to the data stream, it will have to add itself as an observer to a BioSensor,
and not the BioDevice. And if a controller wants to effect some changes, it
would have to do this through the sub-classed BioDevice (BioDevProComp,
BioDevModularEEG, etc.) since some of that control information will be device
specific.
Can someone shed some clarity on how to implement MVC here? Thanks!
Ok; with that, I have to close. My intent was to send this out yesterday to
get some feedback, but my time really got crunched because I misunderstood some
travel plans. Good thing I've got people around me to keep me on the
straight-and-narrow. :) So I hope this is helpful, and at least gives some
food for thought as the design structure clarifies.
All the best,
Dave.
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:43 BST