[Article] D'UML à Cobol

[ego]

Désolé, ceci n'est pas une question mais simplement une information.

Pour les Cobolistes qui ont entendu parlé d'UML :

Article d'UML à Cobol

[gizmoeti]

Si ça te dit, dans le projet Acceleo (génération de code), on prépare une "ferme de modules" opensource, et ton exemple de génération UML vers Cobol serait le bienvenue.
On en a déjà pour du java, du jee, du python, bientot pour du C++, mais pas Cobol.

Si ça te dit ...

[ego]

je veux bien essayer de prendre du temps pour regarder.
Mais avant cela, petite question. J'avais regardé les qq générateurs MDA opensource à une époque, peut être un peu vite, mais il m'avait semblé que ces générateurs s'appuyaient sur un mapping classe->fichier or, dans mon cas avec Cobol, on peut (souvent) avoir plutôt le mapping Opération->fichier.
Est-ce donc possible de dire "Pour chaque opération, je veux générer ce fichier là" ?

Si c'est ok, je veux bien essayer de prendre le temps. D'autant plus que je pense que cela sera plus clean que mon propre générateur.

Ah oui, dernière question, puis-je d'une manière ou d'une autre faire du "log" dans un fichier autre (disons Excel), lors de la génération afin d'avoir un résumé de ce qui a été généré ?

Enfin, dans ma boite, on utilise RSM v7, est-ce ok de votre côté car je n'ai vu que RSA V6 et je sais, pour l'avoir expérimenté, que ce qui marche en V6 ne marche pas en V7 pour cause de métamodel/API (peut être n'est ce qu'un problème côté API IBM d'ailleurs ??).

Merci d'avance pour tes répônse et merci de ta proposition

[Gougou]

Il est possible de positionner la génération de fichier sur n'importe quel type d'élément (Classe, Opération, package ...) donc il n'y a aucun problème pour la première partie de ton message.

Pour ce qui est du log, il est possible de générer tout type de fichier texte, donc il par exemple de produire un document ODT ou même dans le format XML d'Excel.

Pour ce qui est de la compatibilité modeleur, du moment que RSM exporte ses modèle en EMF, il n'y a pas de soucis à utiliser Acceleo.

Voila

[ego]

Dernière petite question.

Le générateur que j'ai fait est totalement intégré à RSM car je travaille avec l'API de RSM (EMF + du IBM).
J'ai un peu peur du manque d'intégration avec des outils qui ne savent pas gérer nativement le format.
Pour te donner une idée, je créé un arbre d'erreur quand certaines propriétés ne sont pas renseignées et quand on clique sur une erreur, on est automatiquement positionné sur l'élément en question dans le browser de modèle...........

[Gougou]

Nativement Acceleo n'a pas cette fonctionnalité (par contre EMF permet de définir ses règles de validation et se positionne sur les éléments qui ne la passe pas). Par contre 2 méchanismes permettent de réaliser cela :
- les services java qui peuvent utiliser l'API RSM
- les customs actions qui sont également décrites en java.

À priori, toujours pas de problème

[ego]

je suis en cours de création d'un générateur IDL un peu particulier, lié à mon générateur Cobol.
Ensuite, je regarderai sérieusement Acceleo, promis

[neo22]

Bonjour,
je vous remercie M. Erik Gollot pour votre article qui a tenu mon attention sur un point particulier, en l'ocurrence de la notion d'héritage: vous n'avez cité que l'héritage des attributs et pas celui des méthodes ou traitements, car je ne vois pas de REDIFINES dans ce cas qui pourrais nous éviter une réecriture du programme correspondant à notre opération.

[ego]

je n'en ai effectivement pas parlé car cette notion peut paraitre relativement loin des habitudes des Cobolistes (j'imagine et donc peut être que je me trompe).
Ceci dit, pas de réel problème si on se limite un peu.

Par rapport aux méthodes, une idée peut être de mettre en place la gestion de la redéfinition d'une opération d'une classe de "mère" par des classes "filles"

Pour cette problématique, une solution peut être :

Prenons une classe nommée "Base" qui possède une opération "faire ceci" et 2 classes filles "A" et "B" qui ont redéfini "faire ceci" (avec les mêmes paramètres en entrée/sortie).
Chaque "faire ceci" des classes "A" et "B" donnent naissance, disons, à un programme Cobol "A_farie_ceci" et "B_faire_ceci".

Au niveau de la classe "Base", l'opération "faire_ceci" donne un programme "Base_faire_ceci".

Au niveau des 3 programmes "xxx_faire_ceci" on passe en paramètre, si ce n'est pas prévu dans les paramètres mentionnés dans le modèle UML, un paramètre "type". "type" représentera le type réel de l'objet pour lequel on veut voir exécuter l'opération "xxx_faire_ceci".

Dans le programme "Base_faire_ceci", on a plus qu'à faire un "switch" sur "type" et à faire le CALL approprié (soit A_faire_ceci soit B_faire_ceci).

Au final, on peut dire que la classe mère ("Base") a besoin de connaitre ses classes filles (mais un générateur de code gèrera cela pour nous).
Cette technique est utilisée sous Unix avec le système X-Windows qui est écrit en C.

Si vous avez d'autres questions, n'hésitez surtout pas.

NB : pour information, le générateur réalisé génère les "LINKAGE" des programmes, du code IDL pour un middleware type Corba et des "COPY" qui définissent des structures de données issues des classes ou graphes de classes.

[Luc Orient]

Envoyé par ego

...
NB : pour information, le générateur réalisé génère les "LINKAGE" des programmes, du code IDL pour un middleware type Corba et des "COPY" qui définissent des structures de données issues des classes ou graphes de classes.

C'est forcément des COPY avec en plus l'option du préprocesseur

Code :

COPY ... REPLACING ==(PREF)== BY == ... ==

parce que les déclarations de structures de données avec "(PREF)" c'est pas compilable en COBOL directement ...
Mais bon c'est du détail ...

[ego]

tu as absolument raison

[Luc Orient]

A noter que le compilateur COBOL d'IBM propose depuis quelque temps déjà des extensions objet principalement pour faciliter le coexistence de programmes écrits en Java et COBOL.

Par exemple, pour Enterprise COBOL (z/OS) :
COBOL class definition structure

Quant à savoir si c'est beaucoup utilisé ... je ne sais vraiment pas ...

[ego]

ben chez nous , je ne pense pas....