15 Jul
2011
15 Jul
'11
10:57 p.m.
I discussed a bit with Andre, and we came to the following conclusion:
- the meta-model already acts as a context for the Fame import/export. Thus we do not
need to pass another context to the basic mechanism
I do not think it does. And we should pass the information at least up to
the FMrepository because else we cannot sort it out.
No. FMRepository works with a meta-model, which is nothing but a description of what you
want to manipulate. This is the context of the import/export mechanism. - the
MooseImportingContext can be used to produce a sub-meta-model that can easily be passed to
the export
It looks a bit too meta for me. so we will have to filter meta model before filtering
model :( The next step would be to have the
MooseImportingContext work directly with Fame and use this filtering mechanism directly.
yes I know.
Now this is clear that linked MooseContext to
fame is ugly. It would be good that FAME take this idea of context a bit better.
Because right now there is no dependencies checks done so we could filter out
inconsistent model.
Still the question was also about passing another param vs. storing the context in a
moose object.
Finally the FMmodel serialization has a problem because it does not have any idea of the
model. so we cannot simply
save a model with for example a version number that is passed by the model. so the API of
basing everything on elements
and not on a holder of elements which can have extra properties is not really good
because we lose the opportunity to hook more information in it.
So I was thinking to add
addModel: to FMRepository and to be able to query this model to get extra information.
I think that tracability is important.
A model is an entity. Currently we just do not pass it to the Fame export and this is why
it is not serialized:
MooseModel class>>export: aModel withMetamodel: aMetamodel to: aStream
...
tower model: (repository := (FMRepository with: aMetamodel) addAll: aModel entities).
tower model exportOn: aStream If you add aModel, it will get exported as well.
not necessarily we do not have to add it to the elements, just have it around.
This is what we had in VW, but then we decided to
change it because it was not so nice from the point of view of the meta-model. Now,
VerveineJ takes FAMIX which is independent of the way Moose is implemented and it exports
based on this information. So, VerveineJ does not really know about MooseModel. If you add
MooseModel to the file, it gets messy because the meta-model will have to know about
MooseEntity and MooseModel which are not quite at the same level as FAMIX entities.
This is not what I meant.
More passing the holder of elements instead of a collection of entities so that we can
attach extra info to the exporter that can do what it wants with it.
We can change that, but before I want to think of the
impact. For example, for SourceLanguage we now have a proper FAMIX entity that describes
that. And this is stored in the file. It works quite well. We can something similar for
other kinds of entities. Including some FAMIXExtraInformation that can store a dictionary
of properties.
Ok this is the idea.
now does the sourceLanguage encodes
name of the extracting tools
version
date
actions run on the model?
because I think that it would be good to have such information in model.
Stef
Cheers,
Doru
--
www.tudorgirba.com
"What we can governs what we wish."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Cheers,
Doru
On 15 Jul 2011, at 18:14, Andre Hora wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev we could add an extra parameter to a lot of
methods (exportingContext:...) or we could just set the context in the moose model
and the exporter ask the model for its exportingContext.
What do you think is the best?
We have the impression that the second is better.
we will implement it like that and write tests of course :) so this can be changed if
necessary.
On Fri, Jul 15, 2011 at 6:12 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Hi guys
We are implementing a way to export a model and filter some entities.
Now we have a question:
--
Andre Hora
stef and andre
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev