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

["Xavier Blanc" <Xavier.Blanc@xxxxxxx>]

Hi Ed,



> 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.



The idea behind was to explain how hard it is to develop an MDA scenario 
when tools are very heterogeneous.

ModelBus offers a homogeneous vision of the tools. They appear as modeling 
services providers.

ModelBus has then the charge of managing the communication between consumers 
and providers.





> 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.


I like the analogy with 'make'. For me ModelBus is useful then for writing 
rules that are executed by heterogeneous tools.



> 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.
Yes, what about trying to identify mandatory services and then define them 
as modeling service?



 > 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.

Ok, this will be the 'model registry' mandatory modeling service.



> 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.

Yes, and this will be the 'executor registry' mandatory modeling service.

But can you explain what do you mean by 'the meta-model of the programming 
language ther execute'?

Do you mean the meta-model of the transformation language or the meta-model 
of the language of the engine?



> 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.
Ok now, I think I can understand.

But do you think that one transformation will really have several associated 
programming languages?





> 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.
Yes, very interesting. But when do you think we will have semantic 
definitions for meta-models?



> 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.
The goal of ModelBus is to make those conversions transparent.





> 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.
Ok good. We should look at it.



Thank you again



Xavier Blanc