17 May
2009
17 May
'09
9:45 a.m.
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