10-01-2010 04:32 PM
Continue this time with updated design documents. Start with the top level diagram.
I added methods and few new classes, as well. After adding a few simple accessors, I realized that this was cluttering the diagram, so left them off the rest of the classes. The most significant change is the addition of the processing class and its subclasses. This creates a streaming pipeline which allows such things as encryption, compression, scaling, and filtering upon either read or write. I am still debating where to put functionality which allows reading a different format than is physically on disk. For example, to save space, digitizer data is stored as I16s with scaling, then read as an array of DBLs for analysis. I think I would like to put an apiType property in the Data class, with scaling being handled as a Processing option. Self–describing file formats, such as TDMS and HDF5, do not need this extra field, but other file types, such as flat binary and text, do.
There are two major points on the diagram which need further elucidation, and a bunch of minor ones. The first major point is the format of Location.path. My current thinking is to use a simple file path syntax modified with XPath syntax to handle multiple elements of the same type. Links to other files, local or networked, will require a different format, probably something based on SMB or NFS standards and which will support both.
The second major point is the Data.type format. I envision an XML string so that the hierarchical nature of datatypes could be fully realized. LabVIEW currently has a flatten to XML format, but it is too verbose as it contains data information, as well as type information. There is a typedef for datatype information (\vi.lib\Utility\VariantDataType\Type.ctl), as well, but it only gives the datatype of the top layer of the data. My plan is to use this datatype to supply text strings for hierarchy leaves in the datatype, allowing easy conversion to the typedef in the LabVIEW layer, as needed.
Here is a first draft of the hierarchy of the file types discussed in the first post.
I originally had a binary file type over most of the file types on the right, but did not think it added anything. I also grouped things by how LabVIEW code interacts with them. For example, although configuration and XML files are text files, they currently have a well–defined API which takes care of the low–level details that the text file object would provide. Therefore, I placed them in the hierarchical files group.
Let me know your thoughts. I will try to flesh out the type and path formats for next time. If I have enough time, I might start on a vertical slice down through the flat binary object.
10-04-2010 03:15 AM
A first set of comments on this work:
* Instead of using '[]' as notation for arrays, consider using the multiplicity notation of uml like: DataArray::dims U64 [1..*].
* What about operations with a visibility other than public. My suggestion would be an operation File.SetError with protected access scope.
* The thoughts about Location.path suggest to make the path a class itself. In the first version (and porpably this will be all that's done in this draft) it could just encapsulate the LV path prim.
* Usage of LVOOP features such as mustOverride. This could be done usig sterotypes. Dia doesn't support profiles, but allows to use stereotypes on operations. Example: Data::<<mustOverride>>Read()
* Also I'd like to see stereotypes on the classes to indicate if it's a by-val or by-ref implementation.
* On notation, I'd prefer the common writing for flags/queries as isOpen instead of open?
Felix
10-04-2010 08:03 AM
Excellent suggestions, Felix! My knowledge of UML is more than a bit rusty, and I appreciate your keeping me honest.
10-12-2010 05:39 PM
Thank you Damien for the positive reply.
I sometimes feel like a nerd in 'normal' social enviornments, but since opening the uml box (and I'm doing to much math in my job for an engineer as well) I started feeling nerdy in a LV-talking society as well.
As used by the LV community, I try to push 'best practices' on whatever my current technical expertise is. Sometimes this is too much (out of their scope) for the people I communicated with. And sadly I can't (or I have the feeling I can't) just say something the like: 'I'm not on a nobel prize, but a learner like you'.
Felix
10-19-2010 03:33 PM
Get the next installment here.