En fait, existe-t-il un UML lite qui répondrait à ce genre de besoins ?
Guillaume :
Si le modèle est en REST… pourquoi pas ? Christophe, dans sa
conférence à Paris on Rails, parlait d’ActiveResource (basé sur
SimpleyRESTful)Autant que je sache, les 2 sont indépendants. Tu dois pouvoir
utiliser ARes (moyennant quelques adaptations peut-être) dans
une appli <= 1.1.6 (donc non Simply Restful), pour attaquer
une API Rest distante, qui suit les conventions de Rails
(nom de la ressource au pluriel).
Ah ?
Christophe a dit en préambule à sa conférence qu’il présentait
SimplyRESTful avant ActiveResource car cette dernière se base sur la
première (je n’ai perdu personne, là ?).
Les “quelques adaptations” sont peut-être dans l’écriture d’une
interface REST (routes & co.).
Christophe, ton avis ?
Zifro, Da Rest Man !
Huhu 
Le 23/11/06, François Elie [email protected] a écrit :
Heu je crois plutôt qu’un fois implémenté, il faut le jeter 
enfin
c’est
ce que j’ai compris de l’eXtreme Programming il ne faut pas hésiter,
et
jeté tout ce qui à plus d’un jour (enfin surtout pas les test, ni un
code
fait ce qu’on attend de lui). En fait même le code faut pas hésiter à le
jeter si ça correspond plus au besoin.
Enfin c’est ce que j’ai compris après je peut me tromper.
Heu je crois plutôt qu’un fois implémenté, il faut le jeter
ce que j’ai compris de l’eXtreme Programming
jeté tout ce qui à plus d’un jour (enfin surtout pas les test, ni un code
fait ce qu’on attend de lui). En fait même le code faut pas hésiter à le
jeter si ça correspond plus au besoin.
Enfin c’est ce que j’ai compris après je peut me tromper.
Oui, avec l’XP on fait la chasse permanente au code mort, on fait du
refactoring tout le temps, afin d’avoir un code au top.
Pire (façon de parler) : on peut et on doit écrire du code en sachant
qu’on le remplacera très certainement dans deux mois.
Ca nécessite un peu d’adaptation, mais c’est du pragmatisme pur.
Uml c’est juste une définition de vocabulaire. Au niveau des outils
existant, moi j’utilise DIA, c’est amplement suffisant pour mes besoins
Mais le papier et le crayon sont souvent sympa, voir le tableau blanc et
le
feutre, et pour les nostalgique la craie sur tableau noir 
2006/11/23, philippe lachaise [email protected]:
pour ROR to UML y a peut être ça :
http://blog.zmok.net/articles/2006/11/13/visualize-your-rails-schema
Guillaume “Zifro” DESRAT a écrit :
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.430 / Virus Database: 268.14.14/547 - Release Date: 22/11/2006 17:41
–
Guillaume BELLEGUIC
LES ACCORDEURS DE RESEAUX
e-ngoma / Ker data
4, cours Kennedy
35000 Rennes
[email protected]
http://www.e-ngoma.net
tèl : +33 (0)299 33 87 48
fax : +33 (0)299 33 97 31
RCS Rennes 487 799 892
En fait, existe-t-il un UML lite qui répondrait à ce genre de besoins
?Uml c’est juste une définition de vocabulaire.
Je voulais dire, connais-tu, officiel ou non, un subset codifié d’UML
qui
correspondent à 80 % des besoins et en particulier au besoins rencontrés
pour une appli type RoR.
Bref, un digest d’UML. J’ai des pavés à la maison mais pas le temps qui
va
avec.
philippe lachaise a écrit :
Je voulais dire, connais-tu, officiel ou non, un subset codifié d’UML
qui correspondent à 80 % des besoins et en particulier au besoins
rencontrés pour une appli type RoR.Bref, un digest d’UML. J’ai des pavés à la maison mais pas le temps
qui va avec.
Je ne suis pas sûr que le champ lexical et sémantique fourni par UML
soit justement adapté à une appli “type RoR”.
Si l’on veut fournir un moyen convivial et réellement efficace pour
modéliser graphiquement tel ou tel aspect de l’appli (i.e. : modèle type
“diagramme de classes UML” pour le squelette d’un contrôleur, modèle
type “diagramme de séquence UML” pour des interactions AJAX RJS & co,
…), il faut réfléchir à un métamodèle d’une appli Rails (de même qu’il
existe un métamodèle d’UML). Avoir son propre métamodèle peut paraître
fastidieux de prim’abord, mais peut aussi faciliter grandement
l’écriture des générateurs automatisés “modèle de contrôleur ==>
contrôleur rails” , “modèle d’interactions remote ==> fichier rjs”,
modèle où l’on peut dessiner des calques HTML graphiquement et
intuitivement ==> vue .rhtml, etc.
Le métamodèle pourrait par exemple spécifier le concept de Page,
contenant des Div. Des Requêtes ont des Paramètres, et leur résultat
agit sur des Div, etc etc etc…
Si le métamodèle est suffisamment riche et expressif (et ça, c’est pas
facile!), il nous permet d’écrire des modèles qui SONT le code. Point !
Par exemple, si l’on se restreint au cas d’un contrôleur, on peut tout à
fait arriver à l’écrire complètement sous forme d’un diagramme de
classes UML (nom de la classe=nom du contrôleur ; nom des méthodes=nom
des actions du contrôleur ; annotations UML associées à chaque
méthode=code Ruby associé à l’action ; etc etc) …
Comme je le disais précédemment, on s’en sort avec UML, mais on en vient
à passer par des “bidouilles” (cf. les corps de méthodes stockés dans
des annotations !) … Le vrai avantage à l’utilisation d’UML est le
fait qu’il existe pléthore d’outils pour éditer facilement et
graphiquement de l’UML ; ce qui n’est pas le cas si l’on conçoit son
propre métamodèle… Quoique … (mais j’arrête mon post là, j’ai du
boulot ! :s si la discussion continue sur sa lancée, j’expliciterai plus
sur l’édition graphique de son propre MM :-))
Benjamin.
Ma foi, tu n’es pas obligé d’utiliser tous les diagrammes qu’UML te
propose.
Mon set favori :
- diagramme des cas d’utilisation (qui va faire quoi ?)
- diagramme de classes (quelles sont les données de chaque acteur ?)
- diagramme de séquence (bon, comment ça s’agence ?)
- diagramme d’activité (hou, c’est complexe, il y a un plan pour se
rendre de A Ã B ?)
Comme l’a souligné Yannick FRANCOIS, UML est un vocabulaire, un
formalisme, pas une méthode (comme Unified Process, Rational Unified
Process, eXtreme Programming & co.).