20 Sep
2011
20 Sep
'11
1:28 p.m.
Thanks doru I will start to fix the 122 users of property:
and continue documenting the classes
Stef
On Sep 20, 2011, at 9:21 AM, Tudor Girba wrote:
Hi Stef,
First, the pragma should be:
<MSEproperty: #afferentCoupling type: #Number>
It's like an identifier in code.
Then the only thing different here is what will be saved in the MSE file. So, instead of
AFFC, we will have afferentCoupling.
The only real problem is in the case where we rely on looking up the property in the
dictionary before trying to compute it.
Let me give you an example:
FAMIXBehavioralEntity>>numberOfLinesOfCode
<MSEProperty: #numberOfLinesOfCode type: #Number>
<MSEComment: 'The number of lines of code in a method.'>
^ self lookUpPropertyNamed: #LOC computedAs: [...]
In this case, there is a mismatch between what gets looked up in the implementation
(#LOC), and what is described (#numberOfLinesOfCode). This is because the current external
parsers export the LOC property, but when we are inside Moose, we want to see
numberOfLinesOfCode (it reads better, and it scales better given that we tend to have a
tone of metrics and acronyms become confusing).
So, after loading a model with LOC properties from MSE, by default, these will get stored
in the properties dictionary. Now, we still have the problem that after we save the model
and load it again, we will lose the LOC information because now it will be stored with the
numberOfLinesOfCode. So, until we fix the external parsers, we can have the following
workaround:
FAMIXBehavioralEntity>>numberOfLinesOfCode
<MSEProperty: #numberOfLinesOfCode type: #Number>
<MSEComment: 'The number of lines of code in a method.'>
^ self privateState propertyAt: #LOC ifAbsentPut: [
"this is to make sure we get #LOC"
self privateState propertyAt: #numberOfLinesOfCode ifAbsentPut: [
"this is to deal with the Moose #numberOfLinesOfCode"
...] ]
Cheers,
Doru
On 19 Sep 2011, at 19:40, Stéphane Ducasse wrote:
Doru now I understand what I do not understand
When we define afferentCoupling the following way we make sure that the acronym can be
used to look for the value?
afferentCoupling
"Afferent coupling for a class group is the number of classes that depend upon this
class group"
<property: #AFFC longName: 'Afferent Coupling' description: 'Afferent
Coupling of a class group'>
| cgClasses cgTypes |
cgClasses := self allClasses select: [:c | c isInstanceSide].
cgTypes := cgClasses flatCollect: [:c | c allRecursiveTypes].
^ (cgClasses flatCollect: [:aClass | aClass invokingClasses select: [: c | (cgClasses
contains: [:each | each = c]) not and: [(cgTypes contains: [:each | each = c]) not and: [c
isInstanceSide]]]]) asSet size
Now if we rewrite it
afferentCoupling
"Afferent coupling for a class group is the number of classes that depend upon this
class group"
<MSEproperty: 'Afferent Coupling' type: #Number>
| cgClasses cgTypes |
cgClasses := self allClasses select: [:c | c isInstanceSide].
cgTypes := cgClasses flatCollect: [:c | c allRecursiveTypes].
^ (cgClasses flatCollect: [:aClass | aClass invokingClasses select: [: c | (cgClasses
contains: [:each | each = c]) not and: [(cgTypes contains: [:each | each = c]) not and: [c
isInstanceSide]]]]) asSet size
We do not get the fact that this metrics is associated with the #AFFC acronym
So this was my question before rwriting everything.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev