Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Re: Class clustering (Bug:Exceptions)
by Hani ABDEEN 15 Jul '07

15 Jul '07

thank you very much for your detailed answer. On Jul 13, 2007, at 19:52 PM, Toon Verwaest wrote: > On (13/07/07 18:23), Hani ABDEEN wrote: >> From: Hani ABDEEN <hani.abdeen(a)univ-savoie.fr> >> To: Toon Verwaest <tverwaes(a)infogroep.be> >> Subject: Re: [Moose-dev] Class clustering (Bug:Exceptions) >> Date: Fri, 13 Jul 2007 18:23:04 +0200 >> >> Hi, >> thank you, >> yes It works correctly now :-) and I try to understand and to >> discover what we can do with this plugin. >> Just somethings that I would point out: >> - I have seen that when the clustering algorithm take place, all the >> classes, the packages, and the namespaces in the model under- >> consideration will be considered in the same way by the algorithm. >> What about the classes and the packages which do not really belong to >> the system that we would analyze it (stubs entities)? Such entities >> are used (accessed) by the considered system, and we have this >> information in moose model, but we have not any information about >> what these entities access?. may be they access our system, and may >> be not!! > > It is true that we don't have information, but in the case that the > system would try to put such classes together with classes in our > system, this should probably fail since we don't want to find software > components in libraries. This is where the "Fixating" tab comes in > handy, were we can exclude results library classes. If we do this, > even while they were clustered together, we exclude those results. That was what I would tell you indirectly: It is the best simple solution... I understand perfectly the following of your mail, and I know that a clustering algorithm is not a kind of magic which could give us an ideal solution without any user's intervention!!! The objective was simply pointing out this point which does not occurs only in the case of -System under analysis and Platform library-. Ok I will not discus now the problem of inter-systems collaboration and system's plugins... > > Important is to think that most of the algorithms, just present the > basic results without automatically combining them, to the user, > who can then manually validate clustering information before merging > it. The reason why this is done like this, is because a lot of the > basic algorithms (for example the "By Reference") will definitaly > cause false positives because of the way the algorithm is adapted. > > Next to that, the ones which do already combine results, like the > hierarchical clustering based on delta-ic and interface, can > automatically be filtered for "false positives", be automatically > removing nodes in the hierarchies which only add information about > "ignored classes", which we can ignore in the "fixating tab". > > But well, it might be useful to already provide a checkbox which > automatically exludes these classes, so the user doesn't have to find > out which ones are part of the subject system and which ones aren't.. > >> >> - this is a very small thing that may be it does not cause any >> problem now, but it could do that latter: According to your >> implementation of FAMIXClass>>accessedByClasses and >> FAMIXClass>>allClassAccesses, a class could be accessed be it self. >> > > I guess you are right, that in some situations this could lead to a > problem. I will move the addition of the class itself to the > algorithms that use it. > > One of the basic things you can do with the program now, is using the > different visualizations to analyse user-defined clusters. In other > words how packages are organized in the system. Like this you can see > for example, that the package "Kernel-Objects" contains "green > classes" which are "ghostclasses" or classes which probably should be > in the cluster, but are not. Of course since it is a core package and > since the class causing the effect is the Object-class it might > not be that relevant, but it shows how easy you can find things like > this. again thank you very much for this details, and before all, for this useful plugin. Note that if I interest on this plugin is because that the next step of my work will be around clustering algorithms and software graphs. So surely such plugin to Moose will be very useful for me. bests, Hani > > regards, > Toon

1 0

Question about modrian
by Toon Verwaest 14 Jul '07

14 Jul '07

Hi, for one of the visualizations of clusters (DirectedHierarchical), it would be nice to show classes in a class hierarchy, and annotate that hierarchy with "accesses" between classes. However I don't seem to be able to just show the hierarchy (treeLayout) and then add the annotations (also edges), without the annotations being used to calculate the tree... Is there a way to tell the ViewRenderer not to use some "localEdges:" for the current layout? thanks, Toon

2 1

Class clustering
by Toon Verwaest 12 Jul '07

12 Jul '07

Hi, I have published my work up until now on classcluster detection in the scg store under the highly original bundle-name "Clustering". Like this you can play around a bit to see what it can do etc. Some notes: - In order to find clusters, the clustering plugin needs to be installed, by running "SCG.Moose.AbstractEntity initializeAllMofDescriptions". I am sure there is a clean way to do this automatically when loading packages, but since I have no clue how to install that... this is how it works for now :) Next if you open the moose browser, rightclick on a model, "Find Clusters in Model". - To get better results, make sure you merge instance and class part of classes when generating models - I have included Adrians dendrogram clustering, but have written a wrapper around it to be able to browse the hierarchy as such that "double information" is avoided. For example if a b and c are all at distance 1 of each other, their combination a,b,c has threshold 1 too, so it is not useful to see a,b,c with left a,b with distance 1 and right c, so this info just gets pruned away. Currently the Interface and DeltaIC plugins are hierarchical and the reasons prefixed by * are hierarchical reasons (are possibly browsable). Adrian: currently I have to do a bit of hacking to get similar results, but it might be cleaner if the algorithms would support items laying at Infinity+ from each other (if clustered their threshold is also Infinity+), so those results can be filtered easier... - I know parts of the code (especially the UI and the sorting of reasons) should be cleaned up a bit... but I don't have time for that for the moment, and like this at least you can already see some of the possibilities that it creates Best regards, Toon

2 2

Moose Browser
by sellossa＠ensieta.fr 12 Jul '07

12 Jul '07

hi! I have a question concerning the Moose browser. As you know, I managed to import models conformed to a personnal metamodel in Moose ( my personnal metamodel is not FAMIX). In myn metamodel, I decided to define my own entities Class, Attibute and Method. When I imported my models (that contains my personnal classes, my personnal attibutes and personnal methods) in Moose, something wrong annoyed me: when I selected "all classes" in the browser, Moose gave me the possibility to generate Mondrian views as BluePrintComplexity, MethodInvocations and so on... Of course, since my entities are not conformed to FAMIX, the visualisation cannot be applied to my model (they lead into a bug except from UML diagrams that work very well :) ) So, here is my question: I don't understand why Moose proposes Mondrian visualisations (such as BlueprintComplexity, Duplcation complexity, Method invocation ans so on) to my personnal classes knowing that they are not conformed to the Famix meta model. Where can I fix it? I had a look on MooseUI package but I didn't find what I wanted :( I hope that my question was clear:) thank you for your help sara

2 1

Have an application for this maze resolution browser?
by Klaus D. Witzel 08 Jul '07

08 Jul '07

Gentlefolks, I'm looking for applications which would benefit from maze resolution. The picture attached can give you an impression. It has 4 collections of objects and 4 collections of relations (all can be manipulated). The large center area holds multiple documents (code, text, multi media). Documents, objects and relations can be moved out of the way if desired. Resting the mouse over something tells you what it is. When selecting a relation it highlights the objects which it can see. Maze resolution can guarantee that no other non-empty relation exists from top left to bottom right and also not from top right to bottom left. So there can be nothing in the picture (nothing in the image!) which is hidden from you. Objects can be relocated and can actively help you to find another suitable location. I post in the hope to receiving application ideas from other people, i.e. what to put into the 8 selection areas. If the picture can be populated with things that make sense then a prototype would make sense (the example below could be a start). Thank you in advance for your feedback, all appreciated. Cheers Klaus P.S. an example: top-left classes, top-left-right #category, top-right system categories, bottom-left methods, top-left-bottom {#allSelectors. #class->#allSelectors}, bottom-right methods, bottom-left-right #messages. Then bottom-right shows the methods which are sent but not implemented (foreigners) by the top-left classes themselves. And top-right can optionally show the to bottom-right corresponding foreign system categories with bottom-right-top #methodClass->#category. P.P.S. thank you Doru for introducing me to your thesis and to Moose+Mondrian.

2 3

[famix 3.0] uml diagram of memoria
by Tudor Girba 06 Jul '07

06 Jul '07

Hi, I added to the wiki a reverse engineered UML diagram of the implementation of the Memoria meta-model: http://smallwiki.unibe.ch/moose/famix3.0/memoriametamodel/ Very interesting here is the part dealing with Templates. Cheers, Doru -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "Problem solving efficiency grows with the abstractness level of problem understanding."

1 0

Clustering
by Toon Verwaest 05 Jul '07

05 Jul '07

Hi, I am the student working with Gabriela on adopting the Koschke clustering algorithms to OO. Of the basic algorithms I have almost implemented all of them (type-based is not really possible, and have no idea yet if same-expression is adoptable using famix). Most of the algorithms can be adopted quite straightforward, but sometimes using them automatically as was the case, is out of the question. For that reason I have build a browsable interface around the basic steps of the clustering so the user has a bigger input. It's main task is helping the user to wade through the mass of information all the clustering techniques provide, as fast as possible. Most of the algorithms aren't based on distance metrics, but there are a few which are. I hadn't come around to implementing the hierarchical clustering on top of the basic steps yet, so those algorithms come quite in handy. I will check how I can incorporate them, thanks for that Andrian. Further questions are welcome... Best regards, Toon

4 4

Re: distribution map in 6 lines?
by Adrian DOZSA 05 Jul '07

05 Jul '07

------------------------------ Message: 9 Date: Sun, 1 Jul 2007 21:34:15 +0200 From: St?phane Ducasse <stephane.ducasse(a)univ-savoie.fr> Subject: [Moose-dev] distribution map in 6 lines? To: Moose-dev Bugs <moose-dev(a)iam.unibe.ch> Message-ID: <EA9BA9AA-35AF-4157-B64F-77C5E5E20381(a)univ-savoie.fr> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Andrea where can I find the distribution map code you show me (how to write a distribution map in 6 lines of code ------------------------------ Hi, Presuming you were referring to me, it's Adrian and not Andrea :) The code is in my bundle MoosLiDevelopment, but because it is only 3 lines i've extracted it below: | engine serializedCollection | engine := ClusterEngine with: aCollection using: distanceBlock. engine hierarchicalClusteringShowProgressUsing: #averageLinkage. serializedCollection := engine dendrogram collect: #yourself. where: aCollection: is your collection of elements you want to cluster distanceBlock: is a block that returns the distance between any 2 elements of your collection (eg. Euclidean distance for numerical proprieties of elements) serializedCollection := the result of the clustering, the serialized version of the collection Sorry for the late answer, but i was away for a few days. Ciao, Adi -- Adrian DOZSA Politehnica University of Timisoara Computer Science Department mail: adi.dozsa(a)gmail.com web: http://adi.dozsa.googlepages.com/

2 1

Doctor Alyson : Exclusive Offers
by moose-dev＠iam.unibe.ch 05 Jul '07

05 Jul '07

1 0

[Moose-dev] bug::"ViewRenderer>>sortNodes:" and "Group>>sort:"
by Hani Abdeen 04 Jul '07

04 Jul '07

Hi, In VW7.5 and the last version of Moose, I do not know why these two methods: "ViewRenderer>>sortNodes:" and "Group>>sort:" do not work well. In action, I think that they do not do any modification on the group/collection! Why? Thus, actually, for sorting a group, I was obligated to do: (aGroup asOrderedCollection sort: aBlock) [collection asOrderedCollection]. bests, Hani Hani ABDEEN Student Phd thesis (Remodularization of Architectural Elements in OO Softwares) Laboratory LISTIC - Them LSE Annecy - University de Savoie

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