Ciao Alex, Currently an extended method has its own packagedIn which is different than its class's packagedIn. So the informatoin about the package in which the extension resides is there, just not explicit. What you propose with the association is a step further towards clarity by making the relationship an entity. What I was thinking about was a step even further. Making both the 'relationship' and the 'class extension' entities. Like this: FAMIXClass subclass: #FAMIXClassExtension instanceVariableNames: '' classVariableNames: '' and FAMIXAssociation subclass: #FAMIXExtensionRelationship instanceVariableNames: 'extended extension' classVariableNames: '' poolDictionaries: '' category: 'Famix-Core' - extended would point to a FAMIXClass - extension would point to a FAMIXClassExtension This former approach sees a class extension as a class-like entity which contains the extended methods. The advantage is that this makes dependency analysis more uniform. We then can treat extended methods just like normal methods when aggregating invocations from the method level to the package level. For example: aMEthod belongsTo packagedIn will give us the package in which the method was defined, independently of wether it is an extension or not. One thing which I think will be easier this way is visualizing extension relationships. Generating a polymetric view of the dependencies between two packages like the one in the figure will be straightforward since we have entities for both the extensions and the original classes. Does my point make sense? Cheers, Mircea.

Hi Mircea Do you have some doc on the principles behind Software Naut/way to use it. Because I always found it obscure yet I'm interested. Actually I have been playing with Mondrian in the past few days to get something more or less similar (at least in goal terms) with software naut. So I stumble upon the same problem as you when dealing with dependencies between packages. Sure the possibility of having ClassExtension and ExtensionRelationship is interesting in the long term. In particular it could simplify some viz as you noticed (Jannik had this problem in DSM, where we want to show class extensions too). Meanwhile, I will explain the short-term solution in Famix3 with the Pharo importer. FamixMethod has a #parentPackage attribute (should be #packagedIn in Famix2) which points to the most specific package it belongs to. If it's an ordinary method, it points to the same package as its parent class (might be room for space optimization here). If it's a class extension, then it points to the package which makes the extension. This is detected and done by the Smalltalk importer in Pharo. I dont know whether this is the case in VW with Famix2, but it should be possible to do the same (since FAMIX2Method also has a packagedIn attribute) When looking for dependencies, I start from the packages down to the methods, hence easily check whether a method is part of the package or part of a class extensions. This is enough for the task at hand, but might be cumbersome for other things (where having first-class class extensions would help). In the near time, two areas which need improvement: - the way the importer currently works, it takes into account class extensions made by other packages to explicitly imported packages, but does not import class extension made by the imported packages to external packages. - refine the Famix-Smalltalk API to easily access class extension from/ to FamixClass and FamixPackage (this is partially done, but only as a bi-relation between packages and extended classes, we dont have the methods) So if you have time to do a clean improvement of Famix for extensions, do it (there might be some gotcha points as Alex notices). I believe it is possible to find a work around with the current model. On 27 mai 09, at 13:19, Alexandre Bergel wrote: -- Simon

I am glad to see your fixes. Your tests go green for me. Cheers, Alexandre On 28 May 2009, at 11:53, Simon Denier wrote: -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

I couldn't easily spot the tests related to your extension. I manually identified few of them. Luckily, I found only the green ones. Alexandre On 29 May 2009, at 05:35, Simon Denier wrote: -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nice work Mircea! It's in the news :) http://moose.unibe.ch/news/first-softwarenaut-screentcast Cheers, Doru On 30 May 2009, at 20:23, Mircea Lungu wrote: -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

On 30 mai 09, at 20:23, Mircea Lungu wrote: Perhaps I missed the thing, but there is one item which the screencast did not answer, and this is the very first item I ask myself when looking at a snaut viz :) So, how is the box representing a package built? What does it represent? I understood represents the size, and the inner schema looks like a treemap (but is not?), perhaps with subpackages, and some labels are chosen to decorate this box? Another remark which came immediately viewing the cast, it's difficult to see which node you expand, -- Simon