[News.eclipse.technology.mddi] Re: ModelBus White Paper

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

> The project proposal has been updated and a white paper about ModelBus 
> is now available at the following address: 
> http://www.eclipse.org/proposals/eclipse-mddi/main_data/ModelBusWhitePaper_MDDI.pdf 

'MDA Scenario Program'

I think it is slightly confusing to describe the MDA Scenario as 'programmed'.
'Configured' would be more accurate. I would hope that the required execution
sequence would be automatically deduced from appropriately declared tool
interfaces, the available input models and the required output models. This
deduction might result in a program (command script/makefile/QVT transformation/
XSLT/Java program/interpreted XML) behind the scenes, but when MDDi is working properly
the user should not need to know what or how intermediate models were produced.

MDDi should therefore be configured declaratively and just work. When it doesn't,
then MDDi should provide helpful graphical browsers to view dependencies so that
inappropriate/missing services can be resolved.

I would recommend pursuing a 'make' analogy. Where in make, we could write
a .x to .y rule and not know when or why it was invoked, with MDDi we should be
able to register a 'UML-with-use-cases' to 'UML-without-use-cases' service
and again not know when or why it was used.

Repositories

It may be confusing to present just a ModelBus white paper for the MDDi project.
I agree that ModelBus should not provide repositories in the conventional sense,
since they can be treated as Modeling Services. But there are some services that
are so fundamental that they must form part of MDDi. MDDi probably needs the
same repositories that have evolved for OMELET. Realising each service as an
extensible plug-in would be very much in accord with Eclipse philosophy.

The model registry maintains known models (user data, defined meta-models,
transformation programs), so that a requirement for the UML 1.4 meta-model
can be resolved, possibly by requesting some Proprietary repository to provide it
after conversion to a suitable representation. This almost duplicates the EMF
packaged models extension point.

The executor registry maintains a registry of transformation executors with
respect to the meta-model of the programming language they execute. ANT, Java,
XSLTC, Saxon, ATL, Tefkat, all have execution capability. The registry maps
from program meta-model type to executor adaptor.

So, given a requirement to transform a 'UML-with-use-cases' model to a
'UML-without-use-cases' model, the model registry can be 'searched' for
appropriate direct transformations or indirect sequences of transformations.
Each of these has an associated programming language that can be used to
select the appropriate executor, or possibly to invoke additional conversions
so that e.g. a QVT 2.3 transformation program can be executed by a
QVT 1.4 executor or compiled to run on a C++ executor.

The namespace registry maintains an indirection so that I can choose whether
to use the UML 1.4 meta-model resolved in the Rational Rose Namespace or in the
Objecteering namespace. This indirection also provides a hook for the future. A
meta-model has both a structural definition now and a semantic definition in the future.
Once defined, the semantic definitions will allow e.g. UML 1.4 to be transformed
to UML 2.0 with integrity. I suspect that these semantic definitions have much
in common with some of the UML profile standardisation efforts.

The representation format registry maintains known model representation physical
formats such as File, Stream, XML, JMI, DOM, EMF, ... In practice this registry
is never used as a registry in OMELET, since any given conversion knows that it is
from XMI encoded DOM to Stream, and uses the generic Java adaptor classes
for DOM and Stream directly.

A transient representation cache (a model content in OMELET) is useful for each model
transfer through the bus. The content is typed by its meta-model, and has as many
representations as the one writer and many readers may require. As each reader
requests another format, another representation is cached as an appropriate
conversion generates the content in the additional representation format.

	Regards

		Ed Willink