While trying to map Delphi to FAMIX, we ran into some issues: - Delphi has definitions of a.o. methods split over the interface and the implementation part of a unit. Where do I put the second sourcetextanchor? This might be similar to the situation with c header files. - Being a hybrid of structured and oo, functions seem to be best modeled as scopingentities too. What does it mean that scopingentities represent an entity defining a scope at a global level? Units in Delphi can be local to another unit. - The class comment of behaviouralentity is a bit sloppy in describing which metrics we should provide: is cylomatic complexity, numberOfStatements & numberOfConditionals enough? I am not sure I like the deep inheritance hierarchy of FAMIX. It seems rather brittle. Is Delphi a special case?
Stephan
Hi,
On Thu, Aug 29, 2013 at 1:12 AM, Stephan Eggermont stephan@stack.nl wrote:
While trying to map Delphi to FAMIX, we ran into some issues:
- Delphi has definitions of a.o. methods split over the interface and the implementation part of a unit. Where do I put the second
sourcetextanchor? This might be similar to the situation with c header files.
The source anchor should point to the implementation, not the definition. Perhaps for the definition, you can add a FAMIXDelphiMethodDefinition and link it with a FAMIXMethod. This one then can have its own source anchor.
- Being a hybrid of structured and oo, functions seem to be best modeled as scopingentities too. What does it mean that scopingentities represent an
entity defining a scope at a global level? Units in Delphi can be local to another unit.
I do not understand this part. Could you provide more details and maybe an example?
- The class comment of behaviouralentity is a bit sloppy in describing
which metrics we should provide: is cylomatic complexity, numberOfStatements & numberOfConditionals enough?
You should provide those metrics that are not marked as derived. To find this out you can evaluate: FAMIXBehaviouralEntity asMooseDescription allAttributes select: [ :each | each isDerived not and: [ each type = FM3 number ] ] ==>
an Array( a FM3PropertyDescription[FAMIX.BehaviouralEntity.numberOfParameters] a FM3PropertyDescription[FAMIX.BehaviouralEntity.numberOfStatements] a FM3PropertyDescription[FAMIX.BehaviouralEntity.cyclomaticComplexity] a FM3PropertyDescription[FAMIX.BehaviouralEntity.numberOfConditionals] a FM3PropertyDescription[FAMIX.BehaviouralEntity.numberOfLinesOfCode] a FM3PropertyDescription[FAMIX.BehaviouralEntity.numberOfComments])
I am not sure I like the deep inheritance hierarchy of FAMIX. It seems rather brittle. Is Delphi a special case?
FAMIX was first built in VW, and we only relied on single inheritance. Since a long while we have the plan of moving towards Traits. More recently Nicolas expressed an interest in working on such a topic, and Alain Plantec extended Fame with the concept of Traits. However, until now, nothing really moved but it would definitely be great to have more energy spent there.
Cheers, Doru
Stephan
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 08/29/2013 06:56 AM, Tudor Girba wrote:
I am not sure I like the deep inheritance hierarchy of FAMIX. It seems rather brittle. Is Delphi a special case?
FAMIX was first built in VW, and we only relied on single inheritance. Since a long while we have the plan of moving towards Traits. More recently Nicolas expressed an interest in working on such a topic, and Alain Plantec extended Fame with the concept of Traits. However, until now, nothing really moved but it would definitely be great to have more energy spent there.
Cheers, Doru
It is still on my todo list, but I just don't have the time to do it.
nicolas