VerveineJ and InFusion

Hi,

1- thanks to the tutorial pointed by Tudor, I ran infusion. Don't know
what went wrong the other time
2- I am attaching a zip file with the infusion and verveine generated
mse files for the LanModel project (sources available with
verveine.extractor.java). I hope this is not contrary to the rules of
the list, the file is only 6K.
There are differences, you can look at it and decide for yourselves
which one you prefer.
And if something strikes you as clearly wrong in Verveine, it can be
changed to fit the expected behaviour. For example verveine creates
Namespaces with their full java name: moose.lan.server, which can
admittedly be less elegant when you nest them:
   moose :: moose.lan :: moose.lan.server
infusion creates a more concise:
  moose :: lan :: server
yet the name of the inner Namespace becomes "server", which does not
seem to fit exactly the eclipse understanding of packages where
packages are not nested ...
(I know, Eclipse is not Java)

I ran infusion and verveine on Eclipse v.3.1.
It took about 3 min. for infusion and 1min for verveine which is not
very significant given that you are suppose to do it only once. From
my part, it could take one hour and I would not be too much worried
(even if < 5 min is much better).

And of course, infusion does much more things than verveine: it's a
graphical tool, that computes metrics and does a bunch of other
things.
Verveine sole purpose is to generate MSE from java source.

Actually I prefer the batch oriented philosophy of verveine that
allows to call it in srcipt, and let Moose do all the fancy stuff. It
used to be called the Unix philosophy: small tools that are good at
what they do but don't try to do everything.
(Does it makes me an old geek ?)

I might be wrong, but infusion seems to accept only one root directory
for the java project. This can be an issue. For example if you
consider Eclipse that has code for Linux, Mac and windows, you may
want to analyse only one of the versions to avoid duplicate classes (3
implementations of the Button class).
VerveineJ allows to do this by specifying the source path (it is based
on a "compiler" so it has all these options)

That's about what I could see in the 10 minutes I devoted to it.

nicolas

--
Nicolas Anquetil        Univ. Lille1 / INRIA-equipe RMod

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Thanks Nicolas!
InFusion add the result of some metrics within the .mse, like the cyclomatic complexity. You basically need the AST to compute it. So it cannot be deduced from a FAMIX model. It would be cool to have it in Verveine

Alexandre


On 27 Oct 2010, at 05:23, [hidden email] wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi,

First of all, thanks for this.

> Hi,
>
> 1- thanks to the tutorial pointed by Tudor, I ran infusion. Don't know
> what went wrong the other time

Something seems to have gone wrong, because the model you produced with inFusion has significantly less entities than the verveine one. I have attached here a better version of the exported MSE.

> 2- I am attaching a zip file with the infusion and verveine generated
> mse files for the LanModel project (sources available with
> verveine.extractor.java). I hope this is not contrary to the rules of
> the list, the file is only 6K.

That is fine.

> There are differences, you can look at it and decide for yourselves
> which one you prefer.

The goal is to identify what can be improved in VerveineJ, not to choose between the two.

> And if something strikes you as clearly wrong in Verveine, it can be
> changed to fit the expected behaviour. For example verveine creates
> Namespaces with their full java name: moose.lan.server, which can
> admittedly be less elegant when you nest them:
>   moose :: moose.lan :: moose.lan.server
> infusion creates a more concise:
>  moose :: lan :: server

The thing is like this:
1. either you produce namespaces like moose.lan.server that do not belong to other namespaces
2. or you create nested namespaces that have simple names (like lan) that belong to other namespaces (like moose)

Right now, you do a combination of 1 and 2, which does not produce proper results. inFusion does 1, but actually we almost always infer the namespace nesting in Moose, so it would be best if the parser would produce 2.
The goal would also be to compare the amount and quality of the produced entities. I went quickly through the LAN example, and here is what I found:
(+) Inner classes are exported as nested to the parent class
(+) Anonymous classes are exported as nested in the parent method
(+) namespaces are nested
(+) Implicit variables like self and super
(+) receiver variables properly set in invocations
(-) VerveineJ does not produce annotation instances and annotation types.
(-) No exceptions
(-) classes like <Primitive Package>::void should be PrimitiveTypes
(-) namespace should have simple names
(-) References seem to be at the level of namespaces and it is unclear where they come from (it looks like they come from the nesting which should not be modeled as a reference)
(-) There are no source anchors
(-) There are no primitive metrics like lines of code, cyclomatic complexity, number of statements
(-) There are no entities marked as stub (for example java.lang.Object is not stub)
(-) Interfaces are exported as regular FAMIXClass (it would be better to have them as FAMIXInterface, or at least to have the isInterface flag set to true)
(-) The signature of the methods have an unwanted space between the name and the parentheses

(*) It would be cool to also have the next and previous values set for the associations (this would be useful to recover the order in which instructions appear in the code)
What we are comparing now are the exporters, not the ui. inFusion also offers a shell scripts specially for Moose: java2mse.bat and java2mse.sh.

> I might be wrong, but infusion seems to accept only one root directory
> for the java project. This can be an issue. For example if you
> consider Eclipse that has code for Linux, Mac and windows, you may
> want to analyse only one of the versions to avoid duplicate classes (3
> implementations of the Button class).

Yes, this is correct. That is why when there are multiple sources, I first have to write a small shell script that puts the sources together. This is indeed inconvenient.

> VerveineJ allows to do this by specifying the source path (it is based
> on a "compiler" so it has all these options)

Nice.

Cheers,
Doru
--
www.tudorgirba.com

"No matter how many recipes we know, we still value a chef."








_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Many thanks Doru for your analysis!

I need the source code anchors for AspectMaps, so I wont be able to use VerveineJ until these are added :-(

On 27 Oct 2010, at 17:42, Tudor Girba wrote:

> Hi,
>
> First of all, thanks for this.

--
Johan Fabry  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi,

thanks Doru for the detailed review.

I did some of the easy things.


> The thing is like this:
> 1. either you produce namespaces like moose.lan.server that do not belong to other namespaces
> 2. or you create nested namespaces that have simple names (like lan) that belong to other namespaces (like moose)

> Right now, you do a combination of 1 and 2, which does not produce proper results. inFusion does 1, but actually we almost always infer the namespace nesting in Moose, so it would be best if the parser would produce 2.

> The goal would also be to compare the amount and quality of the produced entities. I went quickly through the LAN example, and here is what I found:
> (+) Inner classes are exported as nested to the parent class
> (+) Anonymous classes are exported as nested in the parent method
> (+) namespaces are nested
> (+) Implicit variables like self and super
> (+) receiver variables properly set in invocations

> (-) VerveineJ does not produce annotation instances and annotation types.

I put this in the wish list of the project

> (-) No exceptions
I put this in the wish list

> (-) classes like <Primitive Package>::void should be PrimitiveTypes
Yes I know :-(
I was lazy

> (-) namespace should have simple names

done

> (-) References seem to be at the level of namespaces and it is unclear where they come from (it looks like they come from the nesting which should not be modeled as a reference)

They come from the "import" statements ...
Never was sure if it was a good idea or not, but I though it could be
nice to have the info ...

> (-) There are no source anchors

OK, I did it for Classes, Methods and Attributes.
I left out method parameters, implicit variables, local variables and
associations.
I am afraid that would result in a huge model ...
Actually it was implemented at some point for invocations for
debugging purposes but then I commented it out :-)

> (-) There are no primitive metrics like lines of code, cyclomatic complexity, number of statements

It is already in the wish list

> (-) There are no entities marked as stub (for example java.lang.Object is not stub)

There could be some entities marked as stub.
The point is JDT binding resolver is quite good (it is used as a
compiler front end after all)
So, if one specifies correctly the source path and class path and all,
we have precisely all the information on all the entities.
For example, this means we can find the attributes and methods of
classes that are not in the parsed source code, but in libraries.

Currently, the stub flag is only set when we don't have this
information (which means, a library or something was not properly
specified in the command line).
Apart from this VerveineJ fetches all the informations "upward": It
fetchs the container of the entities, and for classes their superclass
(recursively)

Two persons already told me that the stub should be for everything
that is not in the parsed source code, even if we have all the info on
it.
You are the third one.
When we reach the total of 741 people asking for it, I will put it in
the wish list :-)


OK, I will think about it, actually it should not be too difficult

> (-) Interfaces are exported as regular FAMIXClass (it would be better to have them as FAMIXInterface, or at least to have the isInterface flag set to true)

Yes I know
Did I mention I am lazy ?

"Implements" and "inherits" are both translated as "Famix.Inheritance", I guess?

> (-) The signature of the methods have an unwanted space between the name and the parentheses

This one was easy, I can do it any time

> (*) It would be cool to also have the next and previous values set for the associations (this would be useful to recover the order in which instructions appear in the code)

wish list
I will have to think a bit about it

So this is it for today

I will be looking at the other ones in the coming days (hopefully)

nicolas

--
Nicolas Anquetil        Univ. Lille1 / INRIA-equipe RMod

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi,

Great work. I looked over the changes in the LAN model. I list some issues below.

If you give me your Google account, I can add you to the Google Code page of Moose and we can handle the issues via this tracker.

I guess it should not be difficult.

>> (-) namespace should have simple names
>
> done

Great.

That is exactly what we need.

However, you are storing the absolute path. The problem should be relative to the input source I provided. Like this I can move the sources and the image around as I please.

Of course. This is what every reasonable parser does.

> Currently, the stub flag is only set when we don't have this
> information (which means, a library or something was not properly
> specified in the command line).
> Apart from this VerveineJ fetches all the informations "upward": It
> fetchs the container of the entities, and for classes their superclass
> (recursively)
> Two persons already told me that the stub should be for everything
> that is not in the parsed source code, even if we have all the info on
> it.

Exactly. This is the semantics of stub (everything I did not tell you to look at explicitly).

> You are the third one.
> When we reach the total of 741 people asking for it, I will put it in
> the wish list :-)

4 to: 741 do: [:i | nicolas pleaseUpdateTheMeaningOfStub ] :)

>
> OK, I will think about it, actually it should not be too difficult
>
>> (-) Interfaces are exported as regular FAMIXClass (it would be better to have them as FAMIXInterface, or at least to have the isInterface flag set to true)
>
> Yes I know
> Did I mention I am lazy ?
>
> "Implements" and "inherits" are both translated as "Famix.Inheritance", I guess?

Yes. The best thing would be to create a FAMIX.Interface which should be a subclass of FAMIX.Type. This does not exist yet, but I will add one in the Pharo FAMIX.

>> (-) The signature of the methods have an unwanted space between the name and the parentheses
>
> This one was easy, I can do it any time

I thought so :)

>> (*) It would be cool to also have the next and previous values set for the associations (this would be useful to recover the order in which instructions appear in the code)
>
> wish list
> I will have to think a bit about it
>
> So this is it for today
>
> I will be looking at the other ones in the coming days (hopefully)

Thanks for all the work. Please let us know if there are any new developments.

Cheers,
Doru

--
www.tudorgirba.com

"Live like you mean it."


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev