Hi
in FAMIX2>>Method>>accesses
accesses
<MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn>
<multivalued>
"all variable accesses contained in receiver"
accesses isNil ifTrue: [ accesses := OrderedCollection new ].
^ accesses
what is the equivalence in FAMIX30?
The fact that Squeak streams does not support collection other than
OrderedCollection is a problem for flatCollect:
So I will try to use Nile to see how I can solve this problem.
stef
just two lines summary of what we did today.
- Now there is a mooseLoader :)
- instanceSide and classSide now working FAMIX30.
- Added some method to RBVariableNode to support isSuper identification
- Fixed the parsetree metric calculator.
Now we get number of statements and friends on Famix20 and Famix30
- Fixed some tests for importer.
Normally when I'm done with some pending documents I will do fix the
merging behavior
for FAMIX30.
Thursday we organise a Moose sprint.
Stef
Hi,
I thought that it might represent a class reference.
But if you want to represent a class reference with an FAMIXAccess, why not
change the type of the accesses attribute from FAMIXAbstractStructuralEntity
to FAMIXNamedEntity? This would fix the issue. Right?
Adi D.
>Hi,
>
>Indeed this is correct. We knew this was a hack, and that is why we
>tried to solve this in FAMIX 3.0.
>
>Cheers,
>Doru
>
>
>On Jan 21, 2009, at 10:04 PM, St?phane Ducasse wrote:
>
>> I do not remember but I guess that
>> the problem is that in famix2 there is no way to express class
>> references (class A refers to class B).
>>
>> so we used that because if in your code you have
>>
>> A>>foo
>>
>> ^ B zork
>>
>> Now in FAMIX30 this is different.
>> You can have reference between classes.
>>
>> Doru am I correct? I'm dead this evening.
>>
>> Stef
>>
>> On Jan 20, 2009, at 11:27 PM, Adrian DOZSA wrote:
>>
>>> Hi everybody,
>>>
>>> Playing around with the FAMIX 2 specs and the LAN model I found
>>> something very strange:
>>> - I found an FAMIXAccess that accesses a FAMIXClass. According to
>>> the FAMIX 2 meta-model and also the annotations from Moose the
>>> accesses attribute of FAMIXAccess should be of type
>>> FAMIXAbstractStructuralEntity. But the FAMIXAccess instance with id
>>> 71 from LAN model accesses a FAMIXClass
>>> (Root::Smalltalk::LAN::LANInterface.initialize() ->
>>> DependentList_class).
>>> There are other examples too.
>>> How were those accesses build? It is correct?
>>>>
>>> Thanks,
>>> Adi D.
I'm looking at the moose website and I think we could improve it a bit
by making some categories/facets for the tools section: like core,
utils, importer, visualization, analysis...
Right now if I want to know which languages can be imported in moose,
I have to go in the FAQ section, which is cumbersome.
--
Simon
Hi everybody,
Playing around with the FAMIX 2 specs and the LAN model I found something
very strange:
- I found an FAMIXAccess that accesses a FAMIXClass. According to the FAMIX
2 meta-model and also the annotations from Moose the accesses attribute of
FAMIXAccess should be of type FAMIXAbstractStructuralEntity. But the
FAMIXAccess instance with id 71 from LAN model accesses a FAMIXClass
(Root::Smalltalk::LAN::LANInterface.initialize() -> DependentList_class).
There are other examples too.
How were those accesses build? It is correct?
Thanks,
Adi D.
------------------------------
dipl.ing. Adrian DOZSA
Programming Engineer
mail: adi.dozsa(a)gmail.com
web: http://adi.dozsa.googlepages.com/
Sorry, it's gonna be very specific.
I'm running and debugging the tests of
FamixPropertiesTest>>testAttributeMetrics, which tests the computation
of basic metrics on Famix entities (like numberOfAccesses).
In many cases, the value against which the model is tested seems
outdated.
For example:
attribute1 := self model entityNamed:
#'Smalltalk::LANInterface.nextNode'.
self assert: attribute1 numberOfAccesses = 4.
attribute1 numberOfAccesses returns 3 and I checked with the model,
LANInterface.nextNode, it is correct (nextNode is only accessed in its
accessor)
So I wonder where the value 4 comes from?
--
Simon
Doru
I thought that we renamed outgoingInheritances into
superclassInheritances
so that we can write to get the superclasses
self superclassInheritances collect: [:each | each superclass]
is it true?
Hi Doru,
I only asked because I would need FAMIX to extend it to an JEE meta-model.
And FAMIX 3.0 looks nicer that v2.0. But I don't think I could implement
FAMIX 3.0 (because of time and knowledge constraints).
Adi D.
> Hi Adrian,
>
> At this moment, there is not a working FAMIX 3.0 in VW. However, the
> mechanism is very much in place. If you are interested in investing a
> little effort it should be not difficult to make it work.
>
> Cheers,
> Doru
>
------------------------------
dipl.ing. Adrian DOZSA
Programming Engineer
mail: adi.dozsa(a)gmail.com
web: http://adi.dozsa.googlepages.com/
