From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-03-19 06:29:42
> Hi John,
>
> here are some quick comments and opinions on what is missing in your
> design. I hope you find them useful:
Always Useful. :-)
> * I think some of these class names, such
> as "Interface", "Device", "FileReader", "USB", "Sensor" etc are too
> generic. They should be more descriptive and perhaps use a common
I agree but I didn't want to complicate things right away. :-)
Yes I do agree. :-)
> prefix to group them together, avoiding name-clashes as the program
> grows in size. Examples: BioSensor and BioInputDevice. "Bio" is just
> a suggestion, something else might sound better.
I like the BIO prefix!
> * Some names can't be written in code (Java or C++ anyway). ("HAL-4"
> and "Modular EEG")
No worries just remove the spaces and - :-)
> * Opinion: Shouldn't "respiration" and "temperature" sensors have
> three letter designators as well?
Yes they should BUT I didn't know what they are.
> A device that logs temperature is called "thermograph" and a device
> that measures breathing rate is called "pneumograph".
> Using the same "E" as in EEG, ECG and EMG, we would
> get "electrothermograph" and "electropneumograph" (ETG and EPG).
OK DONE. :-)
> * You need to define a class for managing data in memory. It may also
> encapsulate (control) a file manager object.
Yes that is the MAIN I spoke about in the E-mail!
> * The sensor objects produce data. How about defining some data
> streams for that data? Perhaps EEGDataStream, EMGDataStream etc.
> inheriting from BioDataStream, inheriting from a standard class.
I left this out untill I find out HOW the others that have been writing code
have solved the problem.
Last time I asked there was differing views on weather a DataStream or
shared memory was the best way to go....
I'd prefer NOT to have an EEG, EMG, etc stream as the processing layer would
have to be customised for each stream type.
For example the triggers would be usable no matter what type of DataStream
it gets feed with.
(Question to those that have already coded!)
Is it possible create a data stream that can accommodate all possibilities
(eeg, ecg, etc) ?????????
> * I miss error management strategies and execption handling classes.
> How will errors (such as "file not found" and "out of memory") be
> handled? (Find a book on patterns...there should be something there.)
I've intentionally left them out at this early stage (before coding).
> * As for the user interface and signal-processing sections: I have
> not given them much thought yet ...
I await your responses......I love feedback!!!
> It might be beneficial to limit the design scope for now, to include
> only data types, input, management and file storage as it forms the
> foundation of our "house". The feedback and signal processing parts
> can be saved for later. Focusing on one thing at a time usually
> produces better results too.
I agree BUT without at least showing them It's hard to give an over all
view.
The device stage of course is the best place to start once we have it
working.
Saving and reading data back we have a great base to start from. :-)
But we still have to think about the data stream to the next stage.
> By the way, we should find some coding standard to follow. I suggest
> this one: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
Hay very nice never run across that one before.
Most of the ones I've seen don't cover everything
> Regards,
>
> Andreas
Thanks Andreas
I've made some changes to the UML take a look and tell me what else needs to
be changed!
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:43 BST