Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Moose/Mondrian question
by Johan Brichau 23 Oct '07

23 Oct '07

Hi everyone, As some of you know, I am working on a FAMIX importer for Eclipse java source files, written in Smalltalk (using our JavaConnect system). At this moment, the importer creates a FAMIX model with classes, methods, namespaces and inheritance relations. Now, I experience some strange behaviour of the Mondrian 'Screen filling system complexity' visualisation. If you take a look at the screenshot below, you can see the 'Event' class hierarchy. Well, that is: a list of 'Event' classes and a hierarchy. The strange thing is that the nodes in the flat line represent exactly the same entities as the nodes in the hierarchy. Maybe it's supposed to be this way? But this only appeared after I added 'implements' relations to the model using FamixInheritanceLinks. I verified if the model does not contain duplicate entities for those classes (which would be an obvious explanation). Inspecting the entities in the flat line did also reveal they do have outgoingInheritance links. So, I'm confused and hope you can shed some light on this :-) ps: Tudor, I hope you got the importer to work now in Mac Intel? ps2: For those interested in trying this: http://www.info.ucl.ac.be/ ~jbrichau/penumbra.html . We're having trouble making JavaConnect run on Windows, so any help to make it work is appreciated. The problem is mainly in finding the correct java libraries to load. Idem for Linux. Or if you can wait long enough, we will be working on an integration with JNIPort too ;-) ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

4 4

Re: [Moose] a question about MOOSE
by Tudor Girba 22 Oct '07

22 Oct '07

Hi Sergio, Nice to hear from you. We use MOF as a meta-meta-model. FAMIX is an instance of MOF and it is used as a meta-model. So, when you analyze a program you will get a model that conforms to FAMIX. FAMIX is a language independent meta-model, meaning that it is basically a common denominator of various languages. For example, you will not get all details of the AST in it, but you will get invocations (calls between methods) and accesses (from methods to variables). A UML-like diagram of the current FAMIX 2.2 can be found at: http://smallwiki.unibe.ch/moose/famixcore2.2metamodel/ So, if you want to define transformations and generate code, you will probably need a more detailed model than FAMIX. But, if you just want to reason about the code without caring much about the AST, than FAMIX is more suitable. However, given that Moose works at the level of the meta-meta-model, it can accommodate other meta-models as well. For example, we have a meta-model for analyzing dynamic information (Dynamix), historical information (Hismo) or CVS information (Chronia). We are now working on FAMIX 3.0. With this occasion we will redefine some terms. For example, what is now known as FAMIX will become FAMIX- Core, and we will explicitly define extensions to this Core. For further questions, we strongly advise to join our moose-dev mailing list at: https://www.iam.unibe.ch/mailman/listinfo/moose-dev Cheers, Doru On Oct 22, 2007, at 10:57 AM, Sergio Castro wrote: > Dear MOOSE team, > > I am interested in understanding if I can used MOOSE for my research, > but I am currently a bit confused about a couple of things. > > My idea was to use a language independent model of an object oriented > program, and querying this model for obtaining Intensional Views of > the > software. After, I would like to make transformations on this model > if I > detect that some constraints over these software views do not hold, > and > finally generate source code that reflect the transformations > accomplished in the model. > > My question is if the program representation used by MOOSE is rich > enough to define over it any kind of software views based on the > structural relationships of the source code elements the model was > built > from. Or in other words, which information from the source code I lost > when I build my model in MOOSE? > > Another issue that confuses me is about FAMIX, from the "The Story of > Moose" paper written by Nierstrasz, Ducasse and G?rba, it seemed to me > that the FAMIX model was replaced with a MOF like meta model, but I > found in the Moose wiki (http://smallwiki.unibe.ch/moose) a comment > about the development of Famix 3.0. Is then FAMIX still part of MOOSE? > or I misunderstood and the new MOF like meta model is a reengineered > version of FAMIX? > > > thanks in advance for any comment or orientation, > > Sergio Castro > > _______________________________________________ > Moose mailing list > Moose(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "Being happy is a matter of choice."

1 0

Bug in FAMIX 2.2
by A. Kuhn 20 Oct '07

20 Oct '07

Please find attached bugs in FAMIX 2.2 - Chronia.CvsFileVersion.comment has type Smalltalk.Core.Text instead of primitive String - Chronia.CvsFileVersion.timestamp has type Smalltalk.Core.Timestamp instead of some primitive - Chronia.Author has both name and Name as property, which fucks up code generation - Smalltalk.CvsModelRoot should be in package Chronia - Smalltalk.Hapax package should be top level, not nested - Smalltalk.Dude package should be top level, not nested - Opposites do not match: DynaMoose.Alias.variable - Opposites do not match: FAMIX.Method.activation - Container must be single-values: Moose.Model.entity - Opposites do not match: Moose.Model.mooseModel - Container must be single-values: FAMIX.Package.definedClass - Missing type: Chronia.Commit.startTime - Missing type: Chronia.Commit.endTime - Opposites do not match: FAMIX.AbstractStructuralEntity.accessedByList - Opposites do not match: DynaMoose.Activation.argument - May not have more than one container: FAMIX.Namespace - Container must be single-values: FAMIX.Namespace.class - Container must be single-values: FAMIX.Namespace.namespace - Opposites do not match: FAMIX.InheritanceDefinition.superclass - Opposites do not match: FAMIX.InheritanceDefinition.subclass - May not have more than one container: FAMIX.Class - Container must be single-values: FAMIX.Class.attribute - Opposites do not match: FAMIX.Class.incomingInheritance - Opposites do not match: FAMIX.Class.accessedByList - Opposites do not match: FAMIX.Class.outgoingInheritance - Container must be single-values: FAMIX.Class.method cheers, AA

4 6

should closures be in the meta-model?
by Adrian DOZSA 18 Oct '07

18 Oct '07

Hi everybody, I have a question, more of an idea: should closures (or Smalltalk blocks) be included in the meta-model? You could see closure as a anonymous function, but with some special properties. They are becoming a very used feature in programming languages: Smalltalk, Lisp, Scheme, Python, Ruby, Javascript and others have closures and even the next versions of both Java and C# it's announced to have closures. Any opinions? Adrian Dozsa

1 0

Updated MSE specification
by Adrian Kuhn 12 Oct '07

12 Oct '07

Please note that we updated the grammar of MSE format. Toon helped me to fix flaws and improve the grammar, see change log on http://smallwiki.unibe.ch/moose/mse/msespecification/ cheers, AA

3 2

design disharmonies
by Richard Wettel 10 Oct '07

10 Oct '07

Hi Doru, I wanted to use the design disharmonies detection implemented in Moose. Since my trials on both Java and Smalltalk systems failed, I would like to know what is the development status here. I saw that most of the identity and collaborative disharmonies rules are implemented, at least for Java. However, almost none of them returned a valid result (the metrics that they are based on seem to return nil instead of a value). Could you give me some hints on how to use them? Maybe I'm doing something wrong here, I just tried something like: aMooseModel allClasses select: [:each | each isBrainClass] Thanks, Ricky

2 2

October 77% OFF
by VIAGRA � Official Site 06 Oct '07

06 Oct '07

1 0

Behavior >> instanceMethodsChanges
by Adrian Kuhn 02 Oct '07

02 Oct '07

There is a nice method in Behavior that is invoked when ever the annotations of a class's methods change, would be nice to use that to make Meta more causally connected. Would be nice if someone has time to do that, refer to > instanceMethodsChanged > "One of the receiver's instance methods which has meta > annotations changed. The method may have been removed, > or may be about to be added. Because this action may be > invoked many times, and because the change it reflects > may not be completed yet, the receiver's response should > probably be fairly limited (such as flushing a cache) rather > than something more proactive, such as actively repopulating > a data structure that records the state of things." > > ^self Maybe that is also useful for you, Andrea. cheers, AA

1 0

Re: [Moose] Re: summary of the discussion with Adrian
by Adrian Kuhn 27 Sep '07

27 Sep '07

Oops, forgot reply all. On 26 Sep 2007, at 23:53 , Adrian Kuhn wrote: > On 26 Sep 2007, at 18:30 , Tudor Girba wrote: > >> As for Meta and Hapax, Adrian said that he reserves the right to >> license them and that we should discuss about it after we get the >> agreement with the Unibe. But, in a follow up mail he changed his >> mind and said that "if we come to some nice agreement with Univ its >> okay to license these two bundles under BSD". I must admit that I am >> a bit confused, but perhaps this was just another misunderstanding :) > > It is the same I wrote in my mail back then > >> All these are issues I'd like to be addresses and taken into account >> when officially (re)licensing Moose now. Personally I would prefer to >> have a license that allows us to be more specific about what we >> consider to be fair use. But I am not strictly against BSD as well, >> it would be even okay for me to license Meta as such if we find to >> some agreement that ensures fairness for all involved parties > > and that still applies. > > AA > > >

1 1

Fwd: [Moose] Re: summary of the discussion with Adrian
by Adrian Kuhn 26 Sep '07

26 Sep '07

On 26 Sep 2007, at 16:33 , Orla Greevy wrote: >>> In my opinion we should aim to be as flexible as the Java world >>> tools >>> e.g. Checkstyle, tomcat, etc. >> >> I do not understand. >> > In the case of the above mentioned tools, they can be used by > anyone in any context, i.e. commerical or non commerical. Which are usually under GPL or compatible. GPL has the nice property that any non-commercial contributer can be sure no one will ever commercialize his contributions; but still any commercial user can use it or sell services on top of it, and in case of LGPL even build products on top of it. My concern as researcher is that BSD does fully satisfy the interest of non-commercial contributers in the same way. Maybe that got lost in all the rant with Doru. AA

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev