Hi
for certain metrics we need to compute the total amount of lines of code for the complete project. FAMIXClass >> calculateARLCOMUnderstand "Class LCOM LOC C1 12 1000 C2 2 50 For C1 1000/1050 * 12 For C2 50/1050 * 2 " self halt. ^ self TR_LoC / self mooseModel TR_totalNumberOfLinesOfCode * self TR_LCOM Now I have a question because totalNumberOfLinesOfCode does exist on Model but on TypeGroup I wrote it like that on FAMIXTypeGroup TR_totalNumberOfLinesOfCode <MSEProperty: #TR_totalNumberOfLinesOfCode type: #Number> <derived> <MSEComment: 'Total number of lines of code from Understand'> ^ self lookUpPropertyNamed: #TR_totalNumberOfLinesOfCode computedAs: [ (self sumNumbers: [ :each | each TR_LoC ]) asFloat ] How can I access for example totalNumberOfLinesOfCode at the model level? Stef -------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Hi,
The way I see it you need to compute a metric in a class that depends on the context of all classes in the system. I would implement it like this: FAMIXClass >> calculateARLCOMUnderstand "Class LCOM LOC C1 12 1000 C2 2 50 For C1 1000/1050 * 12 For C2 50/1050 * 2 " self halt. ^ self TR_LoC / self mooseModel allModelClasses TR_totalNumberOfLinesOfCode * self TR_LCOM Cheers, Doru On Sep 12, 2017, at 11:58 AM, Stéphane Ducasse <[hidden email]> wrote: -- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
In reply to this post by Stéphane Ducasse
self allModelClasses TR_totalNumberOfLinesOfCode ? (self = model) On Tue, Sep 12, 2017 at 11:58 AM, Stéphane Ducasse <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
In reply to this post by Stéphane Ducasse
Tx you guys for the answers!!
I cannot reply directly Now we found a crazy in Pharo. Believe or not And I’m curious if you can reproduce it We wrote this method in FamixClass FAMIXClass >> TR_LCOM <MSEProperty: #TR_LCOM type: #Number> <MSEComment: 'lack of cohesion in methods from Understand'> <derived> ^ self propertyNamed: #TR_LCOM And since it is about Understand metrics FAMIXClass >> Und_LCOM <MSEProperty: #Und_LCOM type: #Number> <MSEComment: 'lack of cohesion in methods from Understand'> <derived> ^ self propertyNamed: #Und_LCOM And this looks forever….. when we use Und_ :) Crazy no. Can you reproduce it?
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
On Tue, Sep 12, 2017 at 12:17 PM, Stéphane Ducasse <[hidden email]> wrote:
So when you prefix your selector with Und_, it takes forever to get executed? I tried it on Pharo 6.1 64 bits (Ubuntu) i.e. created a class and a selector with Und_ prefix. And I could not reproduce the behavior/problem. I didn't try it in moose though because I couldn't make Pharo 32-bit work on Linux 64-bit.
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
probably a compilation problem.
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
In reply to this post by Stéphane Ducasse
On 12/09/2017 11:58, Stéphane Ducasse
wrote:
HiWe had the problem at Synectique and it is a complex issue (and no, we did not find a satisfactory solution) For LOC specifically, in Smalltalk your solution can work, but not in Java, since classes and methods can contain inner/anonymous classes and you don't want to count them twice The problem also exist in Ada (not with classes) Second, there is also the larger problem of aggregation of a metric at some higher abstraction level - some times you want to sum (e.g. LOC) ; - sometimes it seems more reasonable to average (e.g. cyclomatic complexity at the level of classes) ; - sometimes you want to recompute (e.g. coupling between 2 classes can often not be aggregated from the results of couplings between their methods) ; - and also averaging is not always a good solution in itself and you want something more sophisticated (http://dx.doi.org/10.1002/smr.1558) nicolas -- Nicolas Anquetil -- MCF (HDR) Project-Team RMod _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
On Fri, Sep 22, 2017 at 10:15 AM, Nicolas Anquetil <[hidden email]> wrote:
SourceLanguage object can't manage this info? I think we already discussed it in the context of C/CPP (Modules vs. Class) and this is how we started to manage variations amongst these two. Ideally, one would want to create several metrics computation strategies so that these can be shared amongst languages. usman
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Free forum by Nabble | Edit this page |