Serialising vs modelling

[Gerard Lemson]

On Thu, 13 May 2004, Alberto Micol wrote:

> Thanks a lot Gerard,
> 
> I think your message makes crystal clear what we have to do now, that is:
> 
> - Analysis (English)
> - Design (UML)
> - Serialiasation (XML)
Actually this is not quite according to standard terminology.
The analysis phase produces a model of the general problem domain, also
called the "universe of discourse". This can be in UML. The model is
generally based on "interviews" with domain experts, i.e. people who know
about the problem domain, for exaple astronomy, or registries. These
people do not "speak" UML, so a modeler needs to try to interpret their
english and turn it in a model. 

What distinguishes the analysis-design-implementation phases is a level of
generality. The first phase is aimed at giving a comprehensive model 
that is implementation and application neutral. It contains all the
concepts that are important. 
The design phase is translates parts of this model into a model that is
aimed at certain functional requirements for a certain application. The
resulting model is in general less comprehensive, often denormalized if
you wish (a bunch of views expressed in terms of the original
model, see my reply to Francois last week or so!). 
Finally in the implementation phase one creates a binding of the design
model to a particular computational environment. This can be serialization
into XML messages, or creation of Java classes or database tables.

I believe that for interoperability between different functional
components, it is useful to create bindings already from the analysis
model, as these can corrspond to the single common language in which
application specific design models can be translated.

This is not meant to support that we should *not* continue with models
that are more implementation oriented already. They are required to start
building prototypes. We may have to redesign some of these at some time if
we find out later that different specific models do not fit well together
and hinder interoperability for example.

Gerard