Re: [Eugene-devel] [veille] SnakeYAML, modèle EUGene en YML
Le 13/02/2012 10:41, fdesbois a écrit :
- [veille] SnakeYAML : poc pour créer des modèles en yaml lus par EUGene tu nous en dis plus ? L'idée est double, je voulais tester SnakeYAML pour lire des fichier YML
On 13/02/2012 10:56, Brendan Le Ny wrote: permettant généralement de représenter des données comme XML mais en plus simple/lisible. A savoir que le Json est une sous-partie du Yaml, c'est juste une représentation simplifiée. La deuxième partie, c'était pour voir si il y aurait un intérêt à écrire des modèles textuels pour EUGene en YAML. Les + : - pas d'argoUML - versionning - plus lisible qu'en XMI ou XML - simple à écrire Les - : - pas de représentation graphique des relations - parsing un peu spécifique au besoin, pas de réelle norme A savoir que d'autres frameworks, comme l'ORM Doctrine en PHP utilise le Yaml pour décrire les modèles de données (plus précisément les bases). D'où mon idée de départ. A priori le YAML est aussi intéressant pour gérer des données de tests, toujours un peu lourdent à écrire (soit en SQL, soit avec DAO...), mais j'ai pas encore essayé. Voir intégration avec DBUnit. Je pense continuer un peu pour voir où cela mène avec EUGene, voir aussi essayer avec d'autres sources comme le KM3 ou même pourquoi pas directement en Java. Un ptit exemple de modèle en Yaml (pour EUGene) : ---------------------------------------------------------------------- name: wao fr.ifremer.wao.model: ElligibleBoat: stereotypes: [entity] attributes: globalActive: boolean companyActive: boolean boat: Boat Boat: stereotypes: [entity] attributes: immatriculation: int name: String boatLength: int buildYear: int active: boolean staffSize: Double elligibleBoat: 0..* ElligibleBoat company: 0..* Company Company: stereotypes: [entity] attributes: name: string phoneNumber: String address1: String address2: String active: boolean email: String city: String postalCode: int boat: 0..* Boat
On Sun, 19 Feb 2012 19:46:28 +0100 Florian Desbois <fdesbois@codelutin.com> wrote:
Le 13/02/2012 10:41, fdesbois a écrit :
- [veille] SnakeYAML : poc pour créer des modèles en yaml lus par EUGene tu nous en dis plus ? L'idée est double, je voulais tester SnakeYAML pour lire des fichier YML
On 13/02/2012 10:56, Brendan Le Ny wrote: permettant généralement de représenter des données comme XML mais en plus simple/lisible. A savoir que le Json est une sous-partie du Yaml, c'est juste une représentation simplifiée.
La deuxième partie, c'était pour voir si il y aurait un intérêt à écrire des modèles textuels pour EUGene en YAML.
Oui, il y a un interet. Historiquement (10ans) avant que ca s'appelle eugene, il n'y avait qu'une representation textuelle mais XML (rebarbatif a pour certain utilisateur). Mais la representation textuelle est toujours tres utile pour le developpeur, pouvoir etre a plusieurs sur le modele. Ne pas avoir besoin d'un 'gros' outil pour editer un modele. Eugene a d'ailleurs ete ecrit dans ce sens, pouvoir avoir plusieurs representation du modele memoire, en implantant le lecteur qui va bien. Actuellement seul le lecteur XML existe. Par contre, il faut pouvoir genere une image du diagramme de classe a partir du modele textutelle. Mais le plus simple pour ca est de pouvoir generer une image a partir de la representation memoire. Ce qui permettra de faire une image quelque soit le moyen pour arriver au modele memoire (xml->memoire, textuelle->memoire, xmi->xml->memoire, code java->memoire) J'ai donc recherche s'il existait des outils qui permettent de faire ca et en libre. Le seul que j'ai trouve avec ces deux conditions est plantuml. Mon idée aussi en faisant le tour de ces outils etait de voir s'il y avait des representation textuelle reutilisable (jolie a lire). Mais tous ces outils ont des syntaxes plus ou moins déplaisantent. Par contre j'ai recherche aussi (mais moins) s'il y avait deja une 'norme' pour ca, mais j'ai rien trouvé. Recherche a creuse peut-etre ? Donc je pense qu'il faut qu'on fasse notre propre syntaxe qui soit reellement lisible 'humainement'. Puis generer a partir du modele memoire via un template de generation la syntaxe qui va bien pour l'outil qui generera l'image.
Les + : - pas d'argoUML - versionning - plus lisible qu'en XMI ou XML - simple à écrire
Oui :)
Les - : - pas de représentation graphique des relations
sauf, si on couple avec un outil qui genere l'image comme explique au dessus
- parsing un peu spécifique au besoin, pas de réelle norme
oui, mais c'est toujours un bonne exercice de faire un parseur ;) ...
Je pense continuer un peu pour voir où cela mène avec EUGene, voir aussi essayer avec d'autres sources comme le KM3 ou même pourquoi pas directement en Java.
Je me suis aussi interrogé sur le directement en Java. Mais ca me gene. Je prefererais avoir une syntaxe un peu comme celle qui est en dessous. A voir si on peut bien tout exprimer, de facon simple et que ca reste lisible et intuitif.
Un ptit exemple de modèle en Yaml (pour EUGene) : ---------------------------------------------------------------------- name: wao fr.ifremer.wao.model:
ElligibleBoat: stereotypes: [entity] attributes: globalActive: boolean companyActive: boolean boat: Boat
Boat: stereotypes: [entity] attributes: immatriculation: int name: String boatLength: int buildYear: int active: boolean staffSize: Double elligibleBoat: 0..* ElligibleBoat company: 0..* Company
Company: stereotypes: [entity] attributes: name: string phoneNumber: String address1: String address2: String active: boolean email: String city: String postalCode: int boat: 0..* Boat
C'est plutot un bon depart (compréhensible, lisible et facilement ecrivable) Par contre les stereotypes je les mettrais bien sur la meme ligne que le nom de la classe. il manque ici: - l'heritage - les relations bi-directionnelles - et plein de petite option possible (ordered, unique, ...) Pour l'heritage et le stereotype ca pourrait-etre: QuatreRoues [interface, entity] Vehicule [entity] Voiture: Vehicule, QuatreRoues [entity] Pour les relations bi-directionnelles: Person: attributes: parent: Person[0-2] reverse=enfant enfant: Person[0-*] reverse=parent Pour les autres options, de simple tag/value apres le champs ou la classe: Person: attributes: name: String notnull=true unique=true activity: ActivityMonth[12] ordered=true Mais bon tout ca n'est pas tres yaml compatible :( La meme chose en yaml Pour l'heritage et le stereotype: QuatreRoues: stereotype: [interface, entity] Vehicule: stereotype: [entity] Voiture: inherits: [Vehicule, QuatreRoues] stereotype: [entity] Pour les relations bi-directionnelles: Person: attributes: parent: {type: Person[0-2], reverse=enfant} enfant: {type: Person[0-*], reverse=parent Pour les autres options: Person: attributes: name: {type:String, notnull:true unique:true} activity: {type:ActivityMonth[12] ordered:true} C'est bof :(. Mais forcement pour parser c plus simple (yaml) Par contre si on veut ajouter la visibilite sur les attributs/methodes genre public ou privé avec des +/-/~/# on va avoir des problemes car ce sont des signes reconnus par yaml :(. Donc syntaxe a creuser, et choix du parser aussi (est-ce la syntaxe qui s'adapte ? ou le parser ?) -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Vous connaissez Kermeta ? http://www.kermeta.org/ Bon, c'est essentiellement basé sur les outils eclipse (donc un peu lourd), par contre il y a une approche de synchronisation text et model assez intéressante, le tout avec une représentation textuelle assez sympa. On s'éloigne un peu du sujet initial et de yaml mais çà peut vous servir dans la réflexion :) au plaisir, -- Guillaume.
participants (3)
-
Benjamin POUSSIN -
Florian Desbois -
Guillaume Dufrêne