Dear Friends of Moose,
We are pleased to announce the founding of the "Moose Verein/
Association".
The founding assembly (Gründungsversammlung) will talke place in
parallel to the FAMOOSR Workshop on Monday June 25, 2007, 17:30 at
the ETH Zurich.
The purpose of the association is to support and promote the Moose
open-source analysis platform both as a technology and as a community.
Membership is open to any researcher or professional with in interest
in Moose, Mondrian, Famix, or software analysis in general.
Membership is open to Swiss and foreigners alike. There will be three
levels of membership: executive board, advisory board and normal
membership.
Please spread the word and let us know your feedback,
sincerely,
in the name of the founding committee,
Tudor Girba
Hi once again,
What are the main features of a system to be extracted for MOOSE in order to
have a fair idea of its functioning?
For the meantime, I have my exporter which extracts:
- Namespaces present in the system
- Classes and their association to each namespace (name, belongsTo, NOM stub
information)
- Methods (name, signature, belongsTo, LOC, isAbstract)
- Attributes (name, belongsTo)
-Invocation (candidate, invokedBy, invokes, stub information)
- Accesses (accessedIn, accesses, readWriteAccess, stub information)
Well, at least this helps me to have a blueprint of the system complexity.
Does this information suffice to perform a concept analysis?
One more thing, could someone help explaining the
readWriteAccess information for attribute access because most of the
attributes have both?
Thanx in advance
Usman
P.S: Attached to this mail is an image of blueprint complexity for my .NET
exporter.
Hi all,
I think "receivingVariable" attribute is no longer used by the MOOSE system
since when I generated my MSE file along with the receiving variable, it
generates an exception:
"Unhandled exception: Import error: unknwon EMOF class 'defaultInstance'."
where "defaultInstance" is the value of my receiving Variable.
Do I need to report the bug generated?
Usman
Hello.
I apologize in advance if this is the wrong list for suggestions for
Mondrian, or if what I suggest has been implemented and I just haven't
been able to find it.
Missing layout: Rectangle packing. There have been quite a few times
when it would be -really- convenient to have the smallest possible
rectangle, but all of the layouts seem to waste space to some degree,
unless the data really -should- be stored in a straight line.
Missing feature: a way to have labels which are always visible, but
perhaps only legible on the larger nodes. [What inspires this is
trying to look at a callgraph using SugiyamaLayout, which works very
nicely, but not being able to label the nodes without it suddenly
being several times wider; the visual information gets entirely lost
in the sprawl.]
Regards;
Katerina Barone-Adesi
Hi,
I was just starting to compute invocations and access information for
my methods and attributes. Could someone provide an examplary file for this
purpose or could point to a possible explanation? I am just looking at the
meta model present on the web site but couldn't understand enough to start
my implementation.
Do I make one entry for each invocation and access?
Secondly, I would like to know the difference between namepaces and packages
as they are seen by MOOSE. Because, as i understand, namespace is an
equivalent to a package as far as their different use at the level of
programming languages is concerned (Java vs C#). Therefore, my MSE file only
contains namespaces but no packages.
usman
Hello all,
I successfully extracted all the informationr related to all the classes in
the system but when I visualize these classes in the "Spaced System
Complexity" in MOOSE, all my classes which are parent or so-called "root"
classes of the system appear to inherit from the "Object" class of .NET
Framework. This is ok since if a class doesn't have a parent, I assign it to
inherit from object and whose stub parameter is set to true.
What really bothers me is that inheritance from the Object class should be
implicit in the visualization to emphasize the existance of lone classes or
classes without any hierarchy (therefore absence of encapsulation and
abstraction). But the relation with the object is explicit, that is, all the
classes are shown to inherit from the object class in the visualization. I
am attaching a screenshot of the visualization. Can someone please point
where I am getting it wrong?
Secondly, how do I represent the enumerated types present in the system?
.NET framework considers them as classes so they are reported as classes.
Usman
P.S if the screenshot is not readable, then the topmost class of all classes
is System.Object
Hello,
we are still working on an ecore file importer in Moose and we have some
questions concerning the code generation.
When the BasicCodeGenerator generates a class that inherits from nothing,
its super class is by default Core.Object.
However, I believe that the superclass may depend on the type of the model
we want to load. Indeed, if you load a model, or a meta model, or a meta
meta model, the superclass can be different
Do you think that SCG.Moose.CallingInitializeObject or
SCG.Moose.MooseElement could be sometimes good candidates for the
superclass instead of Core.Object ?
Thank you for your help.
Sara
Hi Guys,
I have seen that MooseDevelopment is set as a prerequisite to
MooseStore even if there seems to be no obvious reason for it.
I would like to use the model defined in MooseStore also for the
Project Observatory but it seems awkward to ask the user to load all
moose when all that is actually needed is the MooseStore package...
Can you see a solution? :)
Mircea.
Hi,
Is there a way in Moose to get from the name of a method to the name
of the property defined with a pragma inside that method?
For example, having #numberOfMethod, how do I get to #NOM?
Thanks,
Ricky
New submission from Tudor Girba <girba(a)iam.unibe.ch>:
The underlying NetClientBase parcel that comes with 7.5 has changed with respect
to 7.4.1, and because of that Chronia does not work.
----------
assignedto: girba
component: Chronia
messages: 109
nosy: girba
priority: Bug
status: unread
title: Chronia is broken in 75 due to changes in NetClientBase
________________________________________________
Moose Bugs <moose-dev(a)iam.unibe.ch>
<http://macamis.unibe.ch/trackers/moose/issue73>
________________________________________________
Dear Receivers,
hereby a call for participation to FAMOOSr 2007 in Zurich. Please
forward this mail to anyone in your network who may be interested in
this venue.
Please apologize multiple copies.
Early registration is until June 5, 2007
cheers,
Tudor Girba and Adrian Kuhn
***********************************************************************
CALL FOR PARTICIPATION FOR FAMOOSr 2007 in ZURICH
***********************************************************************
FAMOOSr – 1st Workshop on FAMIX and Moose in Reengineering
Location co-located with TOOLS Europe 2007
Date June 25 in Zurich, Switzerland
-----------------------------------------------------------------------
The increasing amount of data available about software systems poses
new challenges for re- and reverse engineering research, as the proposed
approaches need to scale. In this context, concerns about meta-modeling
and analysis techniques need to be augmented by technical concerns about
how to reuse and how to build upon the efforts of previous research.
The goal of this one-day workshop is to strengthen the community of
researchers and practitioners who are working in re- and reverse
engineering, by providing a forum for building future research using
or interested in Moose and Famix as shared infrastructure.
For more information, please refer to
http://smallwiki.unibe.ch/moose/famoosr2007/
!! Workshop program
09:00-09:45 Kick-off presentation.
10:00-10:50 Presentations, 5-10 minutes each.
11:00-11:50 Presentations, 5-10 minutes each.
12:00-12:30 Creating topics for focus groups.
12:30-14:00 Lunch break
14:00-15:00 1st iteration of work in focus groups
15:00-15:30 Preliminary presentation of results
15:30-16:30 2nd iteration of work in focus groups
16:30-17:00 Final presentations and wrap-up
!! Registration
Special pricing for early registration till June 5, 2007.
Registration page http://tools.ethz.ch/register.html
-----------------------------------------------------------------------
Hi,
I'm facing a very strange problem with my Ecore importer :
I implement the EMOF.Enumeration and EMOF.EnumerationLiteral this morning
and use them in my importer.
I wrote some tests and all of them run perfectly.
But when I try to replay my test scenario in a workspace :
|importer repository|
importer := EcoreMetaModelImporter withActiveMetaMetamodel.
importer importEcoreMMFile:
'F:\Cours\EclipseWorkbench\essaiEditor2\test.ecore' .
repository := importer asRepository.
self halt.
I encounter an error :
"Import error: unknwon EMOF class EMOF.EnumerationLiteral "
however, when I inspect my importer's metaRepository, EMOF.Enumeration and
EMOF.EnumerationLiteral appear in the metaRepository elements, but not in
its pathMap.
I don't understand why during the test EMOF.Enumeration and
EMOF.EnumerationLiteral are added to the pathMap of the metaRepositrory
and not during a execution in the workspace.
I 've tried to understand when the pathMap is initialized, but did not
find anything that helps me.
Any idea of what can happen ?
Thank
Pierrick.
PS : I have published my bundles : Meta-Ecore-Importer 0.1bouazza and
Meta-EMOF-Model 0.239e.2bouazza this afternoon.
Hi,
I'm still working on the ecore importer with sara.
Today, I convert a metamodel conform to Ecore in a model conform to EMOF
and then Sara generates the SmallTalk code associated with this model.
Concerning the Enumerations, I planned to implement them into the EMOF
Model (according to the OMG spec I found at
http://www.omg.org/docs/formal/06-01-01.pdf p31
but when I thought at how to convert it in SmallTalk, I found it better to
assimilate Enumeration and EnumLiteral to a class (the enumeration) and
subclasses (the enumLiterals) because they are nothing but types.
Do you think my idea is good, or should I implement Enumeration in the
EMOF Model and let Sara deal with them to generate SmallTalk code?
Thank you for your advices.
Pierrick
Hi Doru,
I have a slight problem with Hismo. I have a bundle with name
CodeCity and in that bundle I have several packages, one of which is
also called CodeCity.
After creating a History from several versions of the system, I
realized that somehow Hismo is not able to distinguish between the
two. Although in the MooseModels of the versions there are 2
FAMIXPackages that are related to each other (one of them belongsTo
the other), after creating a history I end up having one single
PackageHistory called CodeCity. Somehow, Hismo flattens the two...
I guess this is also because the bundles and packages in Smalltalk
are both modeled by the FAMIXPackage in Moose, but I would expect it
to take the mooseID into account on this one. Could you please fix this?
Thanks,
Ricky
New submission from Tudor Girba <girba(a)iam.unibe.ch>:
Submitted by Ricky Wettel.
I have a bundle with name CodeCity and in that bundle I have several packages,
one of which is also called CodeCity. After creating a History from several
versions of the system, I realized that somehow Hismo is not able to distinguish
between the two. Although in the MooseModels of the versions there are 2
FAMIXPackages that are related to each other (one of them belongsTo the other),
after creating a history I end up having one single PackageHistory called
CodeCity. Somehow, Hismo flattens the two...
I guess this is also because the bundles and packages in Smalltalk are both
modeled by the FAMIXPackage in Moose, but I would expect it to take the mooseID
into account on this one.
----------
assignedto: girba
component: Van
messages: 106
nosy: girba
priority: Bug
status: deferred
title: Wrong historical identities for FAMIXPackage
________________________________________________
Moose Bugs <moose-dev(a)iam.unibe.ch>
<http://macamis.unibe.ch/trackers/moose/issue71>
________________________________________________
Hi,
I want to add a outer margin for a rectangle shape.
So we can add space between 2 figures.
What do you think about it?
Do you have any hint for how to do it?
Mth
___________________________________________________________________________
Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire.
http://fr.mail.yahoo.com
Hi,
I have a mse file that contains only files and folders. It loads correctly
into Moose but when i want to browse AllFiles or AllFolders it freezes and
starts to eat a lot of memory (250MB and more) until i have to kill
VisualWorks. Could you take a look and see what could be wrong with this
model.
Thanks.
Adrian D.
--
Adrian DOZSA
Politehnica University of Timisoara
Computer Science Department
mail: adi.dozsa(a)gmail.com
web: http://adi.dozsa.googlepages.com/
hi!
I am still working on the code generator in Moose.
With the BasicCodeGenerator class, you generate a metamodelling protocol
for each attribute of a EMOF class
What is the use of these "metamodel methods" ?
thanks
Sara
Hi,
I'm dealing with comments in my importer. A comment can be defined in an
element and not contain this element in its annotedElements.
Do you think I should include by default the parent element in the
annotedElements ?
Futhermore, I have assimilated the Enumeration to an EMOF.Class and its
litterals to property : but this is not really satisfactory. Do you want I
implement Enumeration in the Meta-EMOF-Model according to the OMG spec ?
Pierrick
