From: Dave (dfisher_at_pophost.com)
Date: 2002-03-06 18:44:29
On Wed, 6 Mar 2002 23:06:54 +1000, John Morrison wrote:
> OK I should be out from under the mountain I'm under in about a week and I
>intend to start writing a data logger.
>
> It will actually be a wrapper for the input stage of the design we've been
>working on
> Consisting of -
> Interface class - Serial (USB and IR to come latter)
> Device Class - For ever wants to test this!
> Sensor Class - EEG (ECG, etc to com latter)
> File Class - To save the data
Well, what you propose is what I've got now, sans the File class (easy to add,
though). So if you want to do it for your own experience, great; but otherwise
it would be a duplication of effort. Here's a very old UML drawing of my early
ideas:
http://home.stny.rr.com/webconnections/linuxeeg.gif
I have been doing more design work on whiteboard and paper than using the UML
software, but when I finish up, I'll diagram what I have like I did above for
the group, because it gives a nice conceptual view of the classes. As I said
before, it comes out close to what has been discussed here, except for the
Sensor class. Methinks I overlooked the obvious in my early OO designs by
focusing on the data stream as an object instead of the sensor itself.
I also echo Andreas' sentiment that what we need is a document that organizes
the decisions which have been made to date, including current design ideas,
feature needs that we have identified, areas that we know are missing (such as
biofeedback practitioner's input), and so on. This would mean digging through
scores of message threads to mine the information, and fold them into a
document. John--you had started one which touched on some of these aspects in
your Requirement Specification document. I think we need to continue with work
on that, but rigorously add content based on all the voices from this list.
However, your document was in MS Word format. A think a better solution would
be something that is a little bit more portable. The first thing that comes to
mind is TeX/LaTeX. This would have various benefits:
1. Since the format is text based, the document could be worked on by multiple
people (a sub-sectioned document such as this lends itself to easy division of
labor) via CVS.
2. LaTeX documents can be translated to other forms of output -- such as
postcript files for printing, PDF for graphical viewing, HTML for the web, etc.
Oh, and it is much more cross-platform friendly than... Word. :)
A very good overiew of text processing in this way can be found at:
http://dsl.org/cookbook/cookbook_19.html
And specifically on TeX and LaTeX at:
http://dsl.org/cookbook/cookbook_19.html#SEC301
For Windows folks: http://www.miktex.org
For the Linux world: http://www.tug.org/tetex
While I am not a LaTeX guru (I've barely used it, actually, so I would have my
homework cut out for me), I would be willing to put time and effort into mining
the list for all the various design ideas and issues and organize it into a
LaTeX document. Is there anyone familiar with TeX or LaTeX? Are there other
documentation possibilities that everyone would like to use instead?
The only other alternative I can see is to designate one person as the tech
writer, let that person manage the document in whatever format he or she
chooses, and be able to produce it in readable format for the rest of us.
Comments/Suggestions?
Dave.
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST
