Hi Martin,
At FAMOOSr you mentioned that you performed renamings on FAMIX?
Could you summarize them?
The current names of the elements can be found in the UML diagram: http://smallwiki.unibe.ch/moose/famixmetamodel/
Cheers, Doru
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"Every thing should have the right to be different."
Hi, Here is our FAMIX core model for representing Java source code. http://seal.ifi.unizh.ch/wiki/swiki/show/FamixCore
There are some differences in naming that can be easily fixed, such as we use "parent" instead of "belongsTo". The other main difference concerns modifiers of entities. We use an integer to represent the scope, static, abstract, etc. modifier of classes, methods, and attributes instead of having extra attributes. Furthermore, we added an abstract "Conext" class to indicate container entities (i.e., entities that can contain other famix entities).
Feel free to use and comment.
--Martin.
On Jun 28, 2007, at 12:48 AM, Tudor Girba wrote:
Hi Martin,
At FAMOOSr you mentioned that you performed renamings on FAMIX?
Could you summarize them?
The current names of the elements can be found in the UML diagram: http://smallwiki.unibe.ch/moose/famixmetamodel/
Cheers, Doru
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"Every thing should have the right to be different."
Dr. Martin Pinzger University of Zurich, Department of Informatics http://seal.ifi.uzh.ch/pinzger
Thank you, Martin!
May you also provide the metamodel as .ecore file? Dot-ecore is the EMF fileformat, as I understand, right?
Also I saw you have association subclasses for class cast and instance of checks. I like that approach, do you also have done or thought about extending the model for annotations and generics?
cheers, AA
On 28 Jun 2007, at 11:52 , Martin Pinzger wrote:
Hi, Here is our FAMIX core model for representing Java source code. http://seal.ifi.unizh.ch/wiki/swiki/show/FamixCore
There are some differences in naming that can be easily fixed, such as we use "parent" instead of "belongsTo". The other main difference concerns modifiers of entities. We use an integer to represent the scope, static, abstract, etc. modifier of classes, methods, and attributes instead of having extra attributes. Furthermore, we added an abstract "Conext" class to indicate container entities (i.e., entities that can contain other famix entities).
Feel free to use and comment.
--Martin.
On Jun 28, 2007, at 12:48 AM, Tudor Girba wrote:
Hi Martin,
At FAMOOSr you mentioned that you performed renamings on FAMIX?
Could you summarize them?
The current names of the elements can be found in the UML diagram: http://smallwiki.unibe.ch/moose/famixmetamodel/
Cheers, Doru
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"Every thing should have the right to be different."
Dr. Martin Pinzger University of Zurich, Department of Informatics http://seal.ifi.uzh.ch/pinzger
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 28 juin 07, at 11:52, Martin Pinzger wrote:
Hi, Here is our FAMIX core model for representing Java source code. http://seal.ifi.unizh.ch/wiki/swiki/show/FamixCore
There are some differences in naming that can be easily fixed, such as we use "parent" instead of "belongsTo". The other main difference concerns modifiers of entities. We use an integer to represent the scope, static, abstract, etc. modifier of classes, methods, and attributes instead of having extra attributes.
Indeed this would be an idea. Do you have a way to say that a value is unknown For example I want to say that a method is a getter but I could also want to say that it is not known that it is a getter that is different from it is not a getter.
Furthermore, we added an abstract "Conext" class to indicate container entities (i.e., entities that can contain other famix entities).
Feel free to use and comment.
--Martin.
On Jun 28, 2007, at 12:48 AM, Tudor Girba wrote:
Hi Martin,
At FAMOOSr you mentioned that you performed renamings on FAMIX?
Could you summarize them?
The current names of the elements can be found in the UML diagram: http://smallwiki.unibe.ch/moose/famixmetamodel/
Cheers, Doru
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"Every thing should have the right to be different."
Dr. Martin Pinzger University of Zurich, Department of Informatics http://seal.ifi.uzh.ch/pinzger
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
That is nice, because we ended up with a similar solution, but instead of an integer we use a string. When the data is unknown, we do not specify it.
Doru
On Jun 28, 2007, at 5:16 PM, Stéphane Ducasse wrote:
There are some differences in naming that can be easily fixed, such as we use "parent" instead of "belongsTo". The other main difference concerns modifiers of entities. We use an integer to represent the scope, static, abstract, etc. modifier of classes, methods, and attributes instead of having extra attributes.
Indeed this would be an idea. Do you have a way to say that a value is unknown For example I want to say that a method is a getter but I could also want to say that it is not known that it is a getter that is different from it is not a getter.
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
To our saving, I'd like to precise that this string is in fact a Symbol, which is (more or less) the same as an Enumeration in EMF. Hence my question @Martin, could you also live with an Enumeration instead of an Integer?
cheers, AA
On 28 Jun 2007, at 17:33 , Tudor Girba wrote:
Hi,
That is nice, because we ended up with a similar solution, but instead of an integer we use a string. When the data is unknown, we do not specify it.
Doru
On Jun 28, 2007, at 5:16 PM, Stéphane Ducasse wrote:
There are some differences in naming that can be easily fixed, such as we use "parent" instead of "belongsTo". The other main difference concerns modifiers of entities. We use an integer to represent the scope, static, abstract, etc. modifier of classes, methods, and attributes instead of having extra attributes.
Indeed this would be an idea. Do you have a way to say that a value is unknown For example I want to say that a method is a getter but I could also want to say that it is not known that it is a getter that is different from it is not a getter.
Hi Martin,
I have some questions/remarks regarding the picture:
- What does Association.statement point to?
- Is there any particular purpose for the Context class?
- Should File and Directory have modifiers?
- It seems to me that to model the Associations uniformly, you deliberately do not use real static typing for from and to :). The same goes for parent. Am I right?
- Instead of parent, I propose container, because parent is overloaded with respect to inheritance (e.g., parent class).
- Instead of from and to, would you mind having full names (e.g., sender, accessor) or do you have a particular reason for having them like this?
Cheers, Doru
On Jun 28, 2007, at 7:14 PM, Adrian Kuhn wrote:
To our saving, I'd like to precise that this string is in fact a Symbol, which is (more or less) the same as an Enumeration in EMF. Hence my question @Martin, could you also live with an Enumeration instead of an Integer?
cheers, AA
On 28 Jun 2007, at 17:33 , Tudor Girba wrote:
Hi,
That is nice, because we ended up with a similar solution, but instead of an integer we use a string. When the data is unknown, we do not specify it.
Doru
On Jun 28, 2007, at 5:16 PM, Stéphane Ducasse wrote:
There are some differences in naming that can be easily fixed, such as we use "parent" instead of "belongsTo". The other main difference concerns modifiers of entities. We use an integer to represent the scope, static, abstract, etc. modifier of classes, methods, and attributes instead of having extra attributes.
Indeed this would be an idea. Do you have a way to say that a value is unknown For example I want to say that a method is a getter but I could also want to say that it is not known that it is a getter that is different from it is not a getter.
-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/
"Problem solving efficiency grows with the abstractness level of problem understanding."