Dr. Damien's Development - Object Based File I/O III - Top Level Design

[DFGray]

Data attributes (e.g. XML attributes) are usually scalars so would be read as DataScalar.Get.  The Location for the data would specify where they are in the file.  The format of Location is still a large topic for discussion.  I envisioned something similar to XPath or the HDF5 syntax (which are very similar).

[F._Schubert]

If you would like interim posts, let me know.

Yep. Short updates on the progress would fuel the debate and increase the learning curve.

Felix

[Ben]

---

@f. Schubert wrote:

Ben, you're right. The asterixes * should be on the opposing ends.

I think the multiplicity on that side of file should be [0..1] (like the error object can be passed to an instance of an error handler class).

On termini: The 'relationship line' is called an Association. But this specializes the meta-class Relationship (and Classifier), so that term is not wrong. BTW: The Generalizations are also Relationships.

Felix

---

Thanks Felix!

For those that are reading along (well maybe some day in the future) the diagrams help us develop the LVOOP classes we need and tell us what form they should take. So in this case...

We know that inside of the class data (it is just a fancy cluster) for "File" we will find one or more instances (copies? versions) of the class (cluster) of type "Location". So when we design the relationships using UML we are actually designing what our clusters classes will look like.

THis not only helps before we start coding but it makes it easy to review a large app and understand how the various clusters classes are related.

So the design above indicates that we will have either an array of type "Location" or there will be one or more instance of that class.

The array version may be more flexible since LVOOP allows inserting different classes into an array (unlike non-LVOOP clusters).

Done with my pre-lunch break update.

Thanks!

Ben

[F._Schubert]

Ben, I think your explanation is a bit too simplified, but it might help the beginner of both uml and LVOOP.

A bit formal uml (the uml meta-classes in italic, I link to my blog):

Associations end at Properties. The Properties can either be owned by the Association or the Class. Dia (the uml editor) lacks the feature to show the ownership. But the AssociationKind=shared indicates (maybe it even implies it, it didn't dig this far yet) the ownership.

In addition, a Property can be derived. This is denoted using a slash '/' in front of the Property name.

LVOOP:

One thing I really like in the LVOOP implementation is, that you are forced to create accessors to your properties. This makes an implementation of derived properties very native: You don't have them in your private data cluster, but the code in the Accessor vi 'computes' the value. I think that the file class could be 'lazy' and only create the location objects that are requested during run-time.

Also on the diagram is another Relationship, the Generalization. This directly translates into the inheritance of our classes in LVOOP.

About Multiplicity, LabVIEW in general doesn't really support this concept. We basically only have three different subsets of all possible Multiplicities:

[1]: a scalar

[*] {isOrdered, non-unique}: an array

[n] {isOrdered, non-unique}: a cluster with n elements.

Others will require some extra code, like implementing a bag (Daklu is working on this in the LapDog project; sorry for not providing the link -> search on LAVA).

Felix

[F._Schubert]

Correction + Addition to above:

It's called AggregationKind not 'AssociationKind', and is an attribute of Property. There is no implication of ownership.

Felix

[DFGray]

Get the next installment here.