Hi guys, Today I imported a smalltalk project in Moose/Softwarenaut. I have more than 3500 invocations with multiple candidates in the candidates list. I decided that I will ignore those dependencies. I would rather see fewer dependencies but be sure that the ones I see are for real (some kind of the lower-bounds of inter-package dependencies). The problem is that after removing the ambiguous invocations, I still have spurious invocations. Two examples: - In the project, there is a class which defines the #includes: method. In the resulting model, I have 64 invocations to this class's #include. However, if you look at the code, you see that the overwhelming majority of them are actually invocking List>>includes:. In fact, the model sais that several classes from the VisualWorks Base are depending on my code because they call includes:. - The same situation with the #with. I have it defined in one class, and all the invocations are attributed to the class although almost all are actually invoking the WATagBrush>>with: from Seaside. I am thinking that I should ignore the dependencies that have as target methods that I will define in a blacklist. I would put in there methods which are frequently used like: for: with: contains: etc... I guess I can remove a lot of noise this way. Then i could probably allow the user to further filter methods from the UI of S*naut. However, the user would have to know the system in order to be able to filter out these invocations. And the point of S*naut was that the user did not know the system... :) Does anybody have a better approach to making sure that the dependencies in the model are for real? Cheers, Mircea. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I ended up importing the BaseVisualWorks package and generating from it a list of all the methods names. I installed this list in a helper class in Softwarenaut (BaseVisualWorksMethods class>>names). I use this collection of methods to filter out the invocations that go to methods in my model that have the same name as methods that exist in the BaseVisualWorks package. When analyzing the SPO project, out of 2000 invocations going to 500 methods in the project's namespace, i filtered out in this way 600 invocations going to 40 methods. As a result, the #include: and #with: problems that I was mentioning in my last email were fixed. The other 38 methods that were filtered also pretty general method names (origin, height, day, menu) which at the first encounter with the system, I would say, are not that relevant. For now this approach is suffcient for me. If I come up with something better I'll let you know. Also if anybody is interested in discussing this further ping me. Cheers, Mircea. On May 15, 2009, at 9:09 PM, Stéphane Ducasse wrote: > Not really we would be really interested to a good heuristic > > Stef > > On May 15, 2009, at 4:15 PM, Mircea Lungu wrote: > >> Hi guys, >> >> Today I imported a smalltalk project in Moose/Softwarenaut. >> >> I have more than 3500 invocations with multiple candidates in the >> candidates list. I decided that I will ignore those >> dependencies. I >> would rather see fewer dependencies but be sure that the ones I >> see >> are for real (some kind of the lower-bounds of inter-package >> dependencies). >> >> >> The problem is that after removing the ambiguous invocations, I >> still have spurious invocations. Two examples: >> >> - In the project, there is a class which defines the #includes: >> method. In the resulting model, I have 64 invocations to this >> class's #include. However, if you look at the code, you see >> that the >> overwhelming majority of them are actually invocking >> List>>includes:. In fact, the model sais that several classes >> from >> the VisualWorks Base are depending on my code because they call >> includes:. >> >> - The same situation with the #with. I have it defined in one >> class, >> and all the invocations are attributed to the class although >> almost >> all are actually invoking the WATagBrush>>with: from Seaside. >> >> I am thinking that I should ignore the dependencies that have as >> target methods that I will define in a blacklist. I would put in >> there methods which are frequently used like: for: with: >> contains: >> etc... I guess I can remove a lot of noise this way. Then i could >> probably allow the user to further filter methods from the UI of >> S*naut. >> >> However, the user would have to know the system in order to be >> able >> to filter out these invocations. And the point of S*naut was that >> the user did not know the system... :) >> >> Does anybody have a better approach to making sure that the >> dependencies in the model are for real? >> >> Cheers, >> >> Mircea. >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Not really we would be really interested to a good heuristic Stef On May 15, 2009, at 4:15 PM, Mircea Lungu wrote: > Hi guys, > > Today I imported a smalltalk project in Moose/Softwarenaut. > > I have more than 3500 invocations with multiple candidates in the > candidates list. I decided that I will ignore those > dependencies. I > would rather see fewer dependencies but be sure that the ones I > see > are for real (some kind of the lower-bounds of inter-package > dependencies). > > > The problem is that after removing the ambiguous invocations, I > still have spurious invocations. Two examples: > > - In the project, there is a class which defines the #includes: > method. In the resulting model, I have 64 invocations to this > class's #include. However, if you look at the code, you see that > the > overwhelming majority of them are actually invocking > List>>includes:. In fact, the model sais that several classes from > the VisualWorks Base are depending on my code because they call > includes:. > > - The same situation with the #with. I have it defined in one > class, > and all the invocations are attributed to the class although > almost > all are actually invoking the WATagBrush>>with: from Seaside. > > I am thinking that I should ignore the dependencies that have as > target methods that I will define in a blacklist. I would put in > there methods which are frequently used like: for: with: contains: > etc... I guess I can remove a lot of noise this way. Then i could > probably allow the user to further filter methods from the UI of > S*naut. > > However, the user would have to know the system in order to be > able > to filter out these invocations. And the point of S*naut was that > the user did not know the system... :) > > Does anybody have a better approach to making sure that the > dependencies in the model are for real? > > Cheers, > > Mircea. > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev