Re: Famix 3.0

On Sep 18, 2011, at 2:50 PM, Marianne Huchard wrote:

> Bonjour tous les deux,
>
> J'ai lu le document du méta-modèle, j'ai installé Moose maintenant si vous pouvez me donner une indication pour ouvrir le méta-modèle, ça m'aidera car j'ai travaillé sur papier seulement.


si tu ouvres un browser de code apres tu peux chercher FamixClass par exemple et sur le code class.
Si tu cliques sur le menu principal (fond d'ecran)
        Moose
        MooseMetaBrowser
                tu obtiens un outil pour parcourir les metamodeles.


> Pour le rapport, il faudra que l'on rédige un texte descriptif général du méta-modèle qui en donne les orientations principales avant de se lancer dans le détail classe par classe. Je peux faire ça si j'ai un schéma.

Oui on doit faire cela.


> Voici ce qui m'a sauté aux yeux dans cette première lecture.

Marianne cela serait bien d'utiliser la mailing list moose car doru et simon la lise

>
> - les associations sont seulement binaires
>
> - je note qu'il y a un certain nombre d'attributs qui ne stocke pas "le modèle" lui-même mais plutôt des statistiques sur l'élément (ex nombre de lignes de code dans un namespace)
> Donc sur les paquetages, on pourrait ajouter d'autres métriques plus précises que le nombre de paquetages clients (ex. nombre de classes clientes, type de client - par quelle relation on est client) ?
> Cela va nous demander une petite analyse, à moins que ce ne soit assez facile ?


Il y a un package Cook et un autre chef (these hani) qui calcule plein de metriques sur les pacjage

> - Est-ce que si on veut modéliser des relations entre paquetages on pourra utiliser des instances d'"Association" ?

je ne sais pas mais a priori pourquoi pas.
>
> - en Java, est-ce supposé être exhaustif ?
par forcement car pour nos analyses il se peut que l'on en ait pas besoin.

> -- dans les types paramétrés, on ne voit pas les bornes (comme pour <A extends Comparable>)
> -- je n'ai pas vu les types interfaces, la relation implements

les interfaces sont gerees comme des classes abstraites

> Ensuite les questions qui se posent sont :
> - dériverons-nous de Famix-core notre modèle de package si on veut y ajouter des choses (je suppose que oui) et dans ce cas, comment cette dérivation se situe-t-elle par rapport au modèle Java par exemple ou Smalltalk (elle va rester parallèle ?).

en fait tu peux faire cela dans un package que l'on charge ou pas.
Normalement (mais on ne l'a jamais vriament utiliser) FAME permet la definition incremental d'elements (c'est pour cela qu'il y a un tag package)
car on pourrait groupe dans un package fame (au metamodel) les extensions que l'on veut faire.
Maintenant dans la pratique on code cela en Smalltalk et le mecanisme d'extension des packages Smalltalk est utilise.

> Y a-t-il dans Famix une relation "merge" entre packages semblable à celle du méta-modèle UML ?


> - qu'ajouterons-nous : j'en discute avec Roland puisque nous devons faire le délivrable
> "Model for modular abstractions in current languages"

je ne sais pas.
Notre objectif est
        - ameliorer la documentation de famix dans moose
        - creer un document de references (tech report)  sur famix 3.0
        apres on peut faire des plugins

Bon j'ai fait une passe sur mon budget et mardi andre revient et on va planifier une ou deux dates pour venir vous voir.



Stef

       


>
> A suivre !
> Marianne
>
>
>
>
>


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Marianne,

Please feel free to send mails on this mailing list. It is the best place to talk about the details of Moose and Famix.

I provide some answers inlined below.

On 18 Sep 2011, at 16:36, Stéphane Ducasse wrote:

No. The abstract Association does provide abstract from and to properties, but specific implementations can have multiple ends and properties. For example, FAMIXInvocation has:
- sender: the behavior entity that sends the message
- receiver: the structural entity that receives the message
- candidates: the list of potential behavioral entities that are actually being called. This is particularly useful for dynamic languages

>> - je note qu'il y a un certain nombre d'attributs qui ne stocke pas "le modèle" lui-même mais plutôt des statistiques sur l'élément (ex nombre de lignes de code dans un namespace)
>> Donc sur les paquetages, on pourrait ajouter d'autres métriques plus précises que le nombre de paquetages clients (ex. nombre de classes clientes, type de client - par quelle relation on est client) ?
>> Cela va nous demander une petite analyse, à moins que ce ne soit assez facile ?
>
>
> Il y a un package Cook et un autre chef (these hani) qui calcule plein de metriques sur les pacjage

FAMIX is meant to be extended, and there are many such extensions. Furthermore, we extend Famix by extending the entities directly with properties (rather than provide an external set of services). This results in a simpler object-oriented model.

>> - Est-ce que si on veut modéliser des relations entre paquetages on pourra utiliser des instances d'"Association" ?
>
> je ne sais pas mais a priori pourquoi pas.

Again, FAMIX is meant to be extended. By default, the importers extract one-to-one what exists in the code, further associations and entities can be added as well.

For example, when we compute duplication, we create a Duplication association between two entities to denote that there is a duplication. In the same way, you can model other relationships.

>> - en Java, est-ce supposé être exhaustif ?
> par forcement car pour nos analyses il se peut que l'on en ait pas besoin.

The model and importers cover all details up to the control flow. That means that you do not have the information about loops or conditionals.

>> -- dans les types paramétrés, on ne voit pas les bornes (comme pour <A extends Comparable>)

I am not sure I understand. This information is part of the model.

>> -- je n'ai pas vu les types interfaces, la relation implements
>
> les interfaces sont gerees comme des classes abstraites

model allClasses select: [:each | each isInterface ]

>> Ensuite les questions qui se posent sont :
>> - dériverons-nous de Famix-core notre modèle de package si on veut y ajouter des choses (je suppose que oui) et dans ce cas, comment cette dérivation se situe-t-elle par rapport au modèle Java par exemple ou Smalltalk (elle va rester parallèle ?).
>
> en fait tu peux faire cela dans un package que l'on charge ou pas.
> Normalement (mais on ne l'a jamais vriament utiliser) FAME permet la definition incremental d'elements (c'est pour cela qu'il y a un tag package)
> car on pourrait groupe dans un package fame (au metamodel) les extensions que l'on veut faire.
> Maintenant dans la pratique on code cela en Smalltalk et le mecanisme d'extension des packages Smalltalk est utilise.

I am not sure I understand the background. What package model are you referring to?

>> Y a-t-il dans Famix une relation "merge" entre packages semblable à celle du méta-modèle UML ?

I do not know what that is :). Could you explain in more details?

Cheers,
Doru



--
www.tudorgirba.com

"We are all great at making mistakes."








_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev