20 Sep
2011
20 Sep
'11
10:49 a.m.
Hi,
(trying to follow the discussion here)
Isn't it a mistake to design the whole pragma thing to patch a problem with a few
metrics that the exporter computes?
Wouldn't it be simpler to do it "the right way" (whatever it is, but
independently of this issue) and them implement a work-around for this specific problem?
How many metrics are they?
How often do they change?
(just asking)
The work-around could be in the mse-importer, or a small processing of the mse before
importing it ...
nicolas
----- Mail original -----
De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 20 Septembre 2011 09:21:45
Objet: [Moose-dev] Re: about <MSEProperty: #propertySignature type: #Number>
<MSEComment: 'ZZZ'>
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