Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Gründung des Moose Vereins
by Tudor Girba 24 Jun '07

24 Jun '07

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

1 0

Essential MOOSE exporter features
by Usman Bhatti 21 Jun '07

21 Jun '07

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.

1 0

ReceivingVariable and invocations
by Usman Bhatti 21 Jun '07

21 Jun '07

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

1 0

FAMOOSr news
by Tudor Girba 21 Jun '07

21 Jun '07

Hello everyone, We have updated the webpage of FAMOOSr with: - proceedings: http://tinyurl.com/ypcx5v - schedule: http://tinyurl.com/2ftss4 Cheers, Tudor and Adrian

1 0

moose-pub keyword in scgbib
by Tudor Girba 20 Jun '07

20 Jun '07

Hi, Please use moose-pub keyword for any publication related to Moose that you add to scg.bib. Like this, it will appear in the following list that summarizes all Moose publications: http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi?query=moose-pub Thanks, Doru -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "What we can governs what we wish."

1 0

The sale you don't want to miss: Hot Summer Clearance!
by moose-dev＠iam.unibe.ch 20 Jun '07

20 Jun '07

1 0

Mondrian suggestions
by ? 19 Jun '07

19 Jun '07

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

3 3

Accesses and invocations example
by Usman Bhatti 16 Jun '07

16 Jun '07

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

2 1

Class Model
by Usman Bhatti 15 Jun '07

15 Jun '07

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

3 2

Code Generation
by sellossa＠ensieta.fr 13 Jun '07

13 Jun '07

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

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev