18 Sep
2011
18 Sep
'11
5:14 p.m.
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:
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.
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.
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.
model allClasses select: [:each | each isInterface ]
I am not sure I understand the background. What package model are you referring to?
--
www.tudorgirba.com
"We are all great at making mistakes."
On Sep 18, 2011, at 2:50 PM, Marianne Huchard 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
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>)
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 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 ?
I do not know what that is :). Could you explain in more details?
Cheers,
Doru
-
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev