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
