[QUANTITY] Data Model for Quantity v0.5 - more on Quantity vs assembly
Martin @ ROE
mch at roe.ac.uk
Mon May 10 09:22:20 PDT 2004
Brian Thomas wrote:
>>- Don't have a Q container model at all, every piece of data is its
>>own class with a corresponding definition in the schema. (Hill)
> To be clear, this approach means to throw away doing any quantity at all.
Er well that's a little misleading... To be clear it means that
quantities are assembled from re-used components with a specific purpose
in mind. ie, a quantity that describes a radio flux will be related to
one that describes an x-ray flux, but is not related (in a class
diagram) to a quantity that describes the size of my shoe.
> In the end, this will be very complex model with no reusable parts. The supporting
> library is likely to be quite large and complex and difficult to implement and
> understand and maintain.
No! We are now in the area of computer science rather than software
development, and the impact of decisions we make on object models do not
always have the 'common sense' results.
The issue is about how things are 'reused' not whether we reuse them.
Using assembly/aggregation rather than inheritance means we 'free up'
the ways we can develop things from existing things. We need this if
we can be sure we can cope with things we haven't thought of yet. Our
supporting libraries can then be sets of packages, rather than being
large monolithic codesets that have to be created in a single step to be
of any use at all.
> I don't see how this will be extensible either as it amounts to proscibing a universal model
> (or set of models) for all, from which nobody can extend without breaking the functionality
> of the VO as a whole.
In fact it is the other way around. Single inheritance models are
extremely restricting - if down the road we find we need to change
something in Frame for example, we risk breaking every single VO
quantity in the whole model...
> I vote "no!" for this. Proponents: please outline how you can satisfy
> VO needs with this kind of approach.
In contrast to my comments above: any particular assembly is not an
attempt to solve the whole VO needs. This is its strength and
Quantity's weakness; we can build quantities for particular purposes.
This makes agreement much easier and code libraries relatively
independent. Where models overlap, we share models - such as the STC.
The STC is a classic example of something already happening this way; we
have a common representation & model, and we *include* it in our model.
This is the reuse I would like to see, and without which it is going to
be harder, not easier, to build an interoperating VO.
Software Engineer, AstroGrid (ROE)
07901 55 24 66
More information about the dm