On Jul 24, 2012, at 4:54 PM, Andre Hora wrote:
On Tue, Jul 24, 2012 at 3:38 PM, Mircea Filip Lungu <mircea.lungu(a)gmail.com>
wrote:
Hi guys,
Some small observations:
Reduced Models
- Having reduced (partial) models is a nice idea.
Yes. You can have reduced models either by:
- (1) exporting a reduced (MSE) version from VerveineJ (I guess this is implemented);
- (2) or, importing your full model in Moose and then exporting the entities you want
(this is also implemented, not sure if this integrated);
Andre you did not implement a filter at loading time?
I thought that you or cyril did it.
An even nicer one would be to have partial loading of
the model.
I think that using the MooseImportingContext we could do that easily.
With this idea, you need to be aware that you will lose (a lot of) data. You will lose
data because several (derived) properties are calculated by Moose and you don't have
access to such information directly in your MSE. For instance, suppose you want to load
only the entities FAMIXPackage and FAMIXClass. Then your classes you will not have
information about the attributes, since FAMIXClass>>attributes is derived (in fact,
you need to have FAMIXAttribute in your model). Then, AFAIK this is not good and also
option (1) above is not so good. Then, option (2) is better.
But until that happens, I guess the partial models could be a solution... And still,
having the full Qualitas Corpus loaded even with partial models is impossible. I guess
this is what Stef proposed to address by having the Project be just a proxy and loading it
on demand, only that this might be too expensive.
In my experience, loading a MSE file for an average system takes between 3 and 5 minutes.
Imagine that you want to collect the number of classes in each of the systems in the QC.
you have 150 systems * 3 minutes each for loading the model = 7.5 hours. And imagine that
after that you want to count the number of methods in each of the systems... This is why
with Andrea we thought about caching Moose images preloaded with the systems in the
Qualitas Corpus. In this way I could run a new analysis on the entire corpus in 10
minutes: I open an image, load the latest version of my analysis package if needed, run
the analysis, return the results and close.
On the other hand, maybe the alternative to this an image per system could be to
serialize the FAMIX models with Fuel and hope that loading an entire system with it would
be waaay faster than when loading an MSE file.
Evolutionary Analysis
- I seem to remember talking at some point with Andy Kellens and him mentioning that they
had an incremental model of FAMIX for modeling evolutionary analysis. This would allow
them to only represent the deltas between two versions. We had this discussion last year
at Sattose. Does anybody know anything about that? That would be the right solution for
doing evolutionary analysis. Otherwise we should just be happy with analyzing at most a
dozen versions at once, as many as fit in memory. Or loading things on demand if we find a
fast way.
If you need just class and package data, then I think Hismo will work pretty well. Model
with just classes and packages are very small, and you load hundreds small models in
Hismo.
Memory
Did anybody look into using Gemstone...?
Server
Jannik I guess we could use one of the servers at SCG if needed for serving this
information.
Cheers,
M.
On Tue, Jul 24, 2012 at 11:40 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote:
Does anybody have any idea about any possible usage of such kind of information ?
you are talking about meta information
In famix 1.0
in the file header there was one entity describing the model.
what we could do is either
- have a separate file in use format (= reuse of parser) containing
information and the file name of the model to which they refer
- or have the information inside the mse model by having an entity
representing the model (we did that in some old moose versions).
I would prefer a separate file. If the idea is to setup a repository of projects the meta
info are about a project together with its mse file not just about the mse.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev