A simple example.

If you create a model with the package Fame-Util, then, inspect such package:

"1"
(self classes flatCollectAsSet: [ :each | each queryOutgoingDependencies atPackageScope ]) size " = 7"

"2"
(self queryOutgoingDependencies atPackageScope asSet) size " = 12"

What in a first moment is strange. At least when we are implementing metrics..
We would expect the same outgoing references (same size) bor both class level (1) and package level (2).
I know that the second one is bigger because it checks all methods, including extensions....but....


On Thu, Aug 2, 2012 at 9:32 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,

I still do not understand :).

Let's be more specific. As I understand we could use the following example:
- package A = FAMIX-Core
- package B = Mondrian
- package C = Moose-Finder

The Moose-Finder extends FAMIX entities with visualization methods
that depend on Mondrian. This decision was taken exactly so that FAMIX
does not depend on Mondrian. So, why would you want to see FAMIX-Core
depend on Mondrian?

Cheers,
Doru


On Thu, Aug 2, 2012 at 9:24 AM, Nicolas Anquetil
<Nicolas.Anquetil@inria.fr> wrote:
>
> we work on coupling metrics that measure how much a package depends on other
> packages (can you reuse it without the others).
>
> Even if it is trough a method added by extension, if package A use something
> in package B, then A needs B (or if you prefer A+C needs B)
> The current semantic does not show this because the extending method will be
> part of package C (the one that introduces the extension) and therefore C
> will depend on B (which seem correct to me), but A will not depend on B ...
>
> So with extensions, we can consider that both A and C depend on B.
> This is something that the coupling metrics do not consider.
> So we have to make a choice.
> For coherence with the same experiment on Java systems, we prefer to say
> that only A depends on B.
>
> But tis is not how famix and moose chef see things ...
>
> Additionaly, we have a metric whose results are useless in the presence of
> extensions.
>
> nicolas
>
>
> On 01/08/12 20:39, Tudor Girba wrote:
>>
>> Hi Nicolas,
>>
>> The current semantics for both methods and queryOutgoingReferences are
>> quite fine.
>>
>> As I understand you want to count the amount of references that the code
>> inside a package induces. So, this includes both the extension methods and
>> the defined methods. Why do you see this as a problem?
>>
>> Cheers,
>> Doru
>>
>>
>> On 31 Jul 2012, at 16:21, Nicolas Anquetil wrote:
>>
>>> Another MooseChef decision:
>>>
>>> aPackage queryOutgoingReferences
>>>
>>> returns all the FamixReferences made from aPackage.
>>>
>>> this is implemented by taking all methods (self methods) in the package
>>> and asking them what reference they make.
>>>
>>> And we have
>>>   FAMIXPackage>>methods
>>>   ^ self localMethods union: self extensionMethods
>>>
>>> So when asking a package what external references it makes, we get
>>> references stemming from methods that extend classes of other packages.
>>>
>>> We found this while computing a coupling metric for packages.
>>>
>>> So the solution would be easy to implement, but we are not sure what is
>>> the best solution ?
>>>
>>> - we could change FAMIXPackage>>methods (methods belong to the package
>>> that owns their class)
>>> - we could change queryOutgoingReferences (references/invocation/accesses
>>> stem from the methods in the classes in the package, not from the methods in
>>> the package)
>>> - or we could change our metric
>>>
>>> nicolas
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev@iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Yesterday is a fact.
>>   Tomorrow is a possibility.
>>   Today is a challenge."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev@iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev



--
www.tudorgirba.com

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



--
Andre Hora