From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-03-20 14:12:49
Happy Flights!!!
I've had a quick look over your stuff and THANKS it will add a lot of flesh
to the UML.
The inheritance was set up that way (i.e. HW to BIOdevice) so that it
didn't get too confusing.
I may even separate them completely and get the Protocol/Main class to
instantiate the HWinterface subclass and pass it to the BIOdevice subclass.
That way if the Biodevice got a new type of interface in the future it
wouldn't need to be reprogrammed.
Anyway I'll have a look through and make some changes and your additions.
:-)
THANKS
John
> -----Original Message-----
> From: Dave [mailto:dfisher_at_pophost.com]
> Sent: Wednesday, 20 March 2002 11:57 PM
> To: buildcheapeeg_at_yahoogroups.com
> Subject: RE: [buildcheapeeg] Re: Bodysoft
>
>
> 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.
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> buildcheapeeg-unsubscribe_at_egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:43 BST