Issue 811 in moose-technology: Create more virtual association in MooseChef
by moose-technology@googlecode.com
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Milestone-4.7
New issue 811 by anquetil...(a)gmail.com: Create more virtual association in
MooseChef
http://code.google.com/p/moose-technology/issues/detail?id=811
Famix recognizes 4 types of associations (reference, access, inheritance,
invocation) and Moosechef was built upon these dependencies
(queryAllOutgoingReferences, ...)
But this will miss a good deal of actual dependencies, because many of them
are not expressed by associations:
- exceptions caught, thrown
- parameter types in parameterized classes
- use of annotations
- other?
10 years, 12 months
To a unified software model repository for Moose.
by jannik.laval
Hi guys,
Each time we need to do case studies in Moose, we have to select the software application, in a certain version and probably without all the source code needed. This results on evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e' (http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems. The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
11 years
Issue 762 in moose-technology: VerveineJ keeps the history of old entities, when invoked from the Moose interface
by moose-technology@googlecode.com
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium
New issue 762 by usman.bh...(a)gmail.com: VerveineJ keeps the history of old
entities, when invoked from the Moose interface
http://code.google.com/p/moose-technology/issues/detail?id=762
First, I invoke VerveineJ from Moose menu to analyse a program A. It
analyses the program and imports its entities in a moose model. I invoke VJ
once more from moose menu to analyse another program B. When VJ is executed
and the entities of program B are imported, I also find in the same model
the entities related to the program A. So, VerveineJ keeps the history of
old entities, when invoked from Moose interface.
I think the problem can be resolved by deleting output.mse once VJ has
finished its analysis and the entities are imported in a moose model.
11 years
Issue 746 in moose-technology: VerveineJ should create parameters for methods with different signatures
by moose-technology@googlecode.com
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.6
New issue 746 by tu...(a)tudorgirba.com: VerveineJ should create parameters
for methods with different signatures
http://code.google.com/p/moose-technology/issues/detail?id=746
In some cases, calls to external libraries get reified as methods with
proper signatures, but without parameters.
I am trying to reproduce this using the following example (in
ad_hoc/MultipleSignatures.java):
package ad_hoc;
import java.io.PrintWriter;
import java.io.StringWriter;
public class MultipleSignatures {
public void callToRegularPrintStackTrace(Throwable t) {
t.printStackTrace()
}
public void callToPrintStackTraceWithParam(Throwable t) {
t.printStackTrace(new PrintWriter(new StringWriter()))
}
}
I encountered a similar code in a case study. However, in this case, I
cannot even get the parser to recognize both printStackTrace calls.
11 years
Issue 809 in moose-technology: Glamour selection should happen through an action
by moose-technology@googlecode.com
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.7
New issue 809 by tudor.gi...(a)gmail.com: Glamour selection should happen
through an action
http://code.google.com/p/moose-technology/issues/detail?id=809
Right now, selecting an item in the user interface will directly populate
the #selection port. However, this is less than ideal because it does not
allow the developer to intervene in this process.
One possibility would be to introduce a selectionAction that is triggered
by the ui, and to provide the default behavior is simply setting the
#selection port.
11 years