27 Oct
2010
27 Oct
'10
10:42 p.m.
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.
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).
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)
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 ?)
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
That's about what I could see in the 10 minutes I
devoted to it.
nicolas
--
Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
<LAN-mse.zip>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."