Dear Moosers, I was pondering over Famix and found that it only uses 20% of EMOF's features. As it seems, the E in EMOF is not really standing for essential :) What I came up with when porting MSE to Java, is a much simpler mmmodel. I documented it on the wiki http://smallwiki.unibe.ch/moose/mse/msemmmodel/ would be nice to make this the new mmmodel of moose and get rid of all the EMOF bloat. by the way, a Java implementation is in its first draft, if you are interested contact me. cheers, AA _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I'm confused why are you talking about famix? I thought you were talking about Meta.

Now about msemmmodel, why don't you have operation (or something related that would be useful to hook behavior)?

On 10 Oct 2007, at 16:28 , Stéphane Ducasse wrote: Famix is meta-described in EMOF, but does only use 20% of what EMOF can do. For example, we do not use - multiple inheritance - other multiplicity than 0..1 or 0..* - the set and unqiue property of properties - the id property - parameters (hence all our operations are equivalent to derived properties) - etc... - ... The design decision behind MSE mmmodel is very simple: if a EMOF feature was not used anywhere in any extensions of Famix, I removed it. As none of the operations in Famix had any Parameter, all are equivalent to properties. cheers, AA _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi, actually I am using EMOF to generate Glorp descriptor in my MetaDB, but it is also true that I don't use any of the listed EMOF properties. I am just wondering why moving to a more simple (but I guess less general) mmmodel... cheers Marco Adrian Kuhn wrote: _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

We would like it to become a strong standard in reengineering, and that is why we want it to be a group effort. Currently several groups participate (see the webpage). If you want to participate, you can send us the description of PADL.

On 10 oct. 07, at 12:55, Adrian Kuhn wrote: > <PADLMetaModel.png>

----- Original Message ----- From: "Tudor Girba" &lt;girba(a)iam.unibe.ch&gt; @Doru, Yann sent me that already, you should also have a copy AA _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Why oddity? In java you cannot have a field pointing to a class?

will you change the name because I always hated this accesses for non collection. even in statically type ones just cast to Object.

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Yann-Gael, Excellent! I answered your questions below. Please feel free to ask more of them. We actually welcome them :). You can find a UML diagram of the current FAMIX implementation: Please note that a FAMIX 3.0 is in the works: http://smallwiki.unibe.ch/moose/famix3.0/ We would like it to become a strong standard in reengineering, and that is why we want it to be a group effort. Currently several groups participate (see the webpage). If you want to participate, you can send us the description of PADL. "stub" denotes entities that are in the model, but that are not part of the system under analysis. However, this makes more sense for structural entities, like FAMIX.Class, and less for relationships. In Moose, there is no analysis that takes stub relationships into account. A FAMIX.Access represents how a variable is accessed by a method/ function. So, if you have something like "method() { ... anObject ... }", then you will get a FAMIX.Access that has anObject variable as "accesses" and method as "accessedIn". In dynamically typed languages, it happens that we not know for sure which method is actually invoked. So, in this case, we compute several "candidates". So, the "candidate" property is a collection of pointers to FAMIX.Method / Function. "invokes" on the other hand represents just the string of the call. There are two possibilities. Either the parser did not work for some reason, or the call is to a function, and not to a method. In any case, our analyses hardly depend on the receivingVariable information. hasClassScope corresponds with "static" in Java. FAMIX.FormalParameter represents parameters of a method/function. As variables, they can be the receivingVariable of an invocation. FAMIX.LocalVariable represents a variable that is defined locally in a method or a function, so LocalVariable "belongsTo" a FAMIX.Method/ Function. Cheers, Doru -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "It's not what we do that matters most, it's how we do it." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev