Moose-groups
Locked
 
|
When working on eclipse, I discovered the necessity to represents things like plugins or components which are not directly handled in Famix. It is important if we want to be able to deal with real world cases. May be we should consider introducing them as Moose Entities? Or may be not: I used Moose-Groups (of class because one package can be spread over different plugins) and it is not that bad. the main issue, in my case, was that classes don't know to what group they have been assigned... So computing dependencies could be very lengthy. I solved that by creating a dictionary on the side, but maybe we should think on a better solution. And then of course integrate this with all the tools... nicolas _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Nicolas,
On 10 Jun 2011, at 14:06, Nicolas Anquetil wrote: > > When working on eclipse, I discovered the necessity to represents things like plugins or components which are not directly handled in Famix. > > It is important if we want to be able to deal with real world cases. I am not sure I understand. Could you be more specific? > May be we should consider introducing them as Moose Entities? FAMIX is meant to be extended. For example, to model JEE systems, we added entities like EntityBean or SessionBeans. > Or may be not: I used Moose-Groups (of class because one package can be spread over different plugins) and it is not that bad. > the main issue, in my case, was that classes don't know to what group they have been assigned... Groups are not meant to work bidirectionally. But, perhaps it would be an interesting addition to try to add this information. > So computing dependencies could be very lengthy. > I solved that by creating a dictionary on the side, but maybe we should think on a better solution. > > And then of course integrate this with all the tools... Interesting. I would be interested in hearing the actual cases. Cheers, Doru > nicolas > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not how it is, it is how we see it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
+ 1
On Jun 10, 2011, at 3:06 PM, Tudor Girba wrote: > FAMIX is meant to be extended. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
> > When working on eclipse, I discovered the necessity to represents > > things like plugins or components which are not directly handled in > > Famix. > > It is important if we want to be able to deal with real world cases. > I am not sure I understand. Could you be more specific? > > May be we should consider introducing them as Moose Entities? > FAMIX is meant to be extended. For example, to model JEE systems, we > added entities like EntityBean or SessionBeans. If I works with Eclipse project, at some point I will want to handle plugins as entities. For example, if the application is very big, or if I want to think about the architecture, I will want to work with plugins (components) rather than packages. So now I want plugins in Moose. Of course, I can extend the metamodel, but this means I have to think where to put it, may be implement metrics, create the MooseChef queries, ... Whereas by using MooseGroup I can instantly prototype components without changing Famix, so I have some guarantee that things will just work. Except that to work, many things require bidirectional navigation (from group to members and members back to its group(s) ) ... > > Or may be not: I used Moose-Groups (of class because one package can > > be spread over different plugins) and it is not that bad. > > the main issue, in my case, was that classes don't know to what > > group they have been assigned... > Groups are not meant to work bidirectionally. But, perhaps it would be > an interesting addition to try to add this information. > > So computing dependencies could be very lengthy. > > I solved that by creating a dictionary on the side, but maybe we > > should think on a better solution. > > And then of course integrate this with all the tools... > Interesting. I would be interested in hearing the actual cases. Two concrete cases that are cited above: - when computing metrics on eclipse, I wanted the metrics at the level of plugins. Instead of defining a FamixEclipsePlugin entity, I created each plugin has a class group, and implemented the few metrics I needed on that (which required bidirectional navigation). - we are supposed to look soon at a big eclipse "application" where the guy is interested in looking at the dependences between plugins because there are too many classes and packages to work at that level. This implies having bidirectional navigation. If DSM, metrics, MooseChef where already working on MooseGroups, I would have an instant poor man component ... - It could be used to define application layers and reason about them. We had the issue recently for a paper, where we wanted to look at dependencies between a package and itself, the package with its application, and the package with the underlying layer(s) (e.g. a framework on which the application is defined). For this we had to hack some dependency queries ... - I could also maybe test various possible system decomposition using groups (somehow similar to what Orion can do). nicolas _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
>> If I works with Eclipse project, at some point I will want to handle plugins as entities.
> For example, if the application is very big, or if I want to think about the architecture, I will want to work with plugins (components) rather than packages. > > So now I want plugins in Moose. Yes now I would just extend FAMIX for that > Of course, I can extend the metamodel, but this means I have to think where to put it, may be implement metrics, create the MooseChef queries, ... Yes which to me is good no? How do you identify a plugin? > Whereas by using MooseGroup I can instantly prototype components without changing Famix, so I have some guarantee that things will just work. > Except that to work, many things require bidirectional navigation (from group to members and members back to its group(s) ) ... > >>> Or may be not: I used Moose-Groups (of class because one package can >>> be spread over different plugins) and it is not that bad. >>> the main issue, in my case, was that classes don't know to what >>> group they have been assigned... > >> Groups are not meant to work bidirectionally. But, perhaps it would be >> an interesting addition to try to add this information. > >>> So computing dependencies could be very lengthy. >>> I solved that by creating a dictionary on the side, but maybe we >>> should think on a better solution. > >>> And then of course integrate this with all the tools... > >> Interesting. I would be interested in hearing the actual cases. > > Two concrete cases that are cited above: > - when computing metrics on eclipse, I wanted the metrics at the level of plugins. Instead of defining a FamixEclipsePlugin entity, I created each plugin has a class group, and implemented the few metrics I needed on that (which required bidirectional navigation). :) > - we are supposed to look soon at a big eclipse "application" where the guy is interested in looking at the dependences between plugins because there are too many classes and packages to work at that level. > This implies having bidirectional navigation. > If DSM, metrics, MooseChef where already working on MooseGroups, I would have an instant poor man component ... Yes that too :) > - It could be used to define application layers and reason about them. We had the issue recently for a paper, where we wanted to look at dependencies between a package and itself, the package with its application, and the package with the underlying layer(s) (e.g. a framework on which the application is defined). For this we had to hack some dependency queries ... > > - I could also maybe test various possible system decomposition using groups (somehow similar to what Orion can do). > > > nicolas > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |