[Article] D'UML à Cobol

D'UML à COBOL
Ce que peut être une modélisation UML pragmatique dans un contexte Cobol

Non, non, il ne s'agit pas de faire un cours sur l'histoire de l'informatique ou de remonter le temps, mais bien de voir comment une application écrite en Cobol peut avoir été modélisée en UML.
Ce n'est pas non plus un article fumeux et commercial pour vous vendre un outil de modélisation UML, à vous les Cobolistes qui êtes persuadés que UML et Cobol c'est comme chien et chat.
Parler d'UML et Cobol dans un même article, autrement que pour les opposer, n'est pas très classique. Mais j'espère que si vous prenez un peu de temps pour lire la suite, vous serez convaincu(e) qu'il n'y a pas vraiment d'autre incompatibilité que celle que vous imaginez.

:fleche: Article d'UML à Cobol

Et vous ?
:arrow: Que pensez-vous de cet article ?

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 ...

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

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

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...........

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 :)

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

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.

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.

Citation:

---

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 ...

tu as absolument raison

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 ...

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

C'est pas un peu risqué le code auto-généré?

Avant d'être coboliste, j'étais développeur Web Symfony et le code auto-généré par Symfony est vraiment difficile à prendre en main.

Il était tiré de notions d'UML et de développement orienté objet mais niveau maintenance faut se tenir!

___________________________________
___________________________________
Skylyn,

Il suffit que le code réponde à tes modèles de code maison.
Il n'y a pas plus de problème qu'avec un mauvais codeur. Ça existe ça aussi, non ?

Citation:

---

Envoyé par ego

Il n'y a pas plus de problème qu'avec un mauvais codeur. Ça existe ça aussi, non ?

---

Je n'ai pas dit le contraire, mais le code auto-généré reste quand même peu facile à maintenir.

Je ne comprends pas cette remarque. C'est une affirmation qui s'appuie sur une longue expérience ?pour ce qui me concerne, je dirai totalement l'inverse, selon mon expérience perso