Serialising vs modelling

[Gerard Lemson]

>
> Thank you Martin!
> We have to separate design and implementation as much as we can.
>
>...
>
> I love the RM document (Bob's one for the registry), it is plain english
> you can take it, read it, understand it, and implement it the way
> you want.
> And in 50 years, you will take it, you will be still able to read it,
> understand it
> and, being a good archeologist, implement it to see how those chaps worked
> so many years ago.
>
>...
>
> But the point is that DMs should be designed first,
> and without any particular programming flavour in mind.
> Otherwise design and implementation get quite intertwined
> (and indeed this is the impression I sometimes get on this mailing list).
>
Alberto

I very much agree with your sentiments.
In the (to quote Pat) "much maligned and misunderstood "unified domain model
for astronomy" ",
we actually make a point of this separation between design and
implementation.

However, this does not mean that we have to resort to plain English as our
language
for data modeling. There are implementation independent formal languages out
there
that are able to describe data models, that were even specially designed for
it.
Examples are Entity-Relationship, UML, Object Role Modeling.
To claim that we have to use plain English is somewhat too close for comfort
to claiming that we
should not use mathematical notation in describing maths equations.
In the DM group we decided on using UML. I think that it can not be too
great of an effort to understand the few constructs in that language that
are required for *data* modeling.
Definitly not for those who want to participate in the DM discussions.

The advantage of UML for example is that there are tools available that can
translate UML
design into standard computer languages, or XML. We may have to wait indeed
50 years before
an English language document can be translated this way.

This in no way is meant to say that plain English documents such as Bob's
are useless.
They are an essential part in the modeling process, listing and describing
the concepts
that need to be modeled. In the DM group meeting in Cambrdige last year it
was agreed that
such a document should accompany or preceed the UML model.
But such a document is not a replacement for a data model.
Part of the actual data modeling task is precisely to translate such
documents into a formal
data modeling language. This is often called the analysis phase of the
sofware development
process. After this phase, and building on its results come the design and
then implementation
phases. Each produce their own set of data models, more and more tailored to
specific functional
requirements and implementation environments.
I do think with you that all of these have gotten mixed up in the current
process and that many
of the discussions on the mailing list stem form this fact.

Gerard