18 Sep
2011
18 Sep
'11
4:36 p.m.
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