- les avantages du transcodage iso-fonctionnel
- l'architecture de l'outil nécessaire à sa réalisation
- l'apport du Logiciel Libre par utilisation importante de divers projets Open Source, en particulier ceux de la fondation Apache mais aussi Eclipse et CVS
L'article se termine par le potentiel de rénovation et d'extension qu'offre un passage à une architecture Java sous-jacente et très fortement orientée objets alors que la cinématique et la structure des programmes transcodées restent les plus conformes possible à leur version Cobol originale pour permettre une poursuite de la maintenance par les développeurs applicatifs sans perturbation pour eux. Introduction
Cet article fait partie d'une série qui décrit le projet NACA ayant conduit au remplacement d'un mainframe IBM sous MVS/OS390 par des serveurs Intel sous Linux. Le projet a été lancé en Janvier 2003 et s'est terminé avec succès au 30 Juin 2007. Il a été réalisé volontairement de manière 100% iso-fonctionnelle (i.e. sans aucune modification pendant et par le transcodage) pour l'application et a engendré la conversion automatisée de 4 millions de lignes de Cobol vers leur équivalent Java. L'économie en cash-outs - paiements externes - est de plus de 85% de leur montant annuel = initial d'environ 3 millions d'euros annuels
L'enjeu majeur du projet NACA était sans aucun doute le transcodage de l'applicatif "maison" de PubliGroupe appelée PUB 2000 (4 millions de lignes de Cobol - applications transactionnelles sous CICS + programmes batches - base de données relationnelles DB2 + procédures stockées sous DB2 en Cobol - 750 000 transactions/jour).
Pour les développeurs qui veulent juger par la structure, la palette d'outils développés pour le projet et décrits dans la suite représente:
- transcodeur lui-même (NacaTRANS) : 83 000 lignes de code source Java; 688 classes.
- environnement d'exécution (NacaRT) des programmes transcodés: 153 000 lignes; 890 classes.
- outils de test automatiques (NacaTools): 16 000 lignes; 128 classes.
À cela, il faut ajouter les codes sources suivants: Java lui-même, Apache Tomcat, l'IDE Eclipse, Berkeley Db java Edition, quelques composants de l'immense librairie Apache Commons, Apache Xerces comme parser XML, Apache XSLTC, quelques petits composants de Apache Struts , Apache Log4J, Apache Ant, CVS.
Pourquoi transcodage = enjeu majeur ? Parce que, finalement, quand on passe d'un système à l'autre, on retrouve en général les mêmes composants (couches de télécommunications, système de contrôle de la machine, gestionnaire de sécurité, moniteur transactionnel, séquenceur des travaux batches, etc…) : les nouveaux composants sont sur base de technologies modernes avec des concepts plus récents et efficaces ; mais à la fin on finit toujours par imprimer, sauvegarder et gérer le système de manière similaire à la génération précédente.
Ce qui pose problème, ce ne sont donc pas les composants systèmes, ni les ingénieurs qui les pilotent (habitués à ces générations successives de systèmes). Le point d'achoppement d'une migration technologique, c'est toujours l'applicatif. Quand il est fait "maison", il faut toujours l'adapter de manière importante. Et comme ce chef d'½uvre (en tout cas, vu comme tel…) a naturellement la vertu d'être unique, tous les coûts de migration d'un système à l'autre sont exclusivement à la charge de l'entreprise propriétaire.
Comme expliqué dans l'épisode [1], la pierre angulaire du projet NACA, c'est le Logiciel Libre (OSS - "Open Source Software") avec Linux comme fondation de l'édifice. Nous ne voulions pas déroger à ce principe pour l'applicatif. Aussi, un choix comme le Cobol Microfocus (qui fonctionne sous Linux) aurait peut-être permis un chemin peut-être plus facile mais a été abandonné car il n'est pas Open Source. Il est de plus (fort) coûteux et ne nous aurait pas permis de restructurer / instrumenter notre application comme la couche objet (Java) que nous avons intercalée nous a permis de le faire [J'y reviens plus bas]
Des premiers essais - en quelques semaines par un prototype interne - nous ont montré que le transcodage automatisé de Cobol à Java était "jouable". Sur le bon principe "Buy before Make", nous avons donc passé un appel d'offres à plus de 20 sociétés (quel que soit leur pays d'origine) susceptibles de répondre: beaucoup de sociétés en liens offshore avec l'Inde mais personne capable de faire un transcodage 100% automatique.
Doté d'un groupe de développeurs-experts, PubliGroupe à pu se permettre de poursuivre en interne la voie du transcodeur (i.e une sorte de compilateur Cobol vers Java) développé "maison" parce que le transcodage 100% automatique était un "must" dans la stratégie NACA développée dans le premier billet.
Les objectifs que nous nous sommes fixés pour ce transcodage :
- Fonctionnement 100% automatique: le transcodeur reçoit les fichiers source de l'application Cobol : programmes, définitions des zones de données (les fameuses COPY CLAUSE de Cobol), les ordres SQL (souvent séparées en fichiers INCLUDE isolés), les définitions d'écrans (BMS Maps pour un mainframe IBM) et génère à partir de tout cela une application Java structurée en servlets Tomcat accédant à la base de données relationnelles via JDBC et assurant le dialogue vers les écrans par une interface http/HTML native.
- Lisibilité du nouveau code source Java : certains des répondants à notre appel d'offres généraient du Java mais ce Java avait l'aspect d'un langage machine (une sorte d'assembleur pour ceux qui connaissent encore ce langage). Ce Java était certes opérationnel et sans faute mais absolument illisible et non maintenable pour un être humain. L'objectif de notre transcodeur (tenu par la suite…) de générer un Java totalement lisible par un programmeur standard. La motivation en est très simple : à la sortie du transcodage, nous voulions un code pouvant vivre encore 10 ans au moins. Une nouvelle génération de PUB 2000 "from scratch" est maintenant mise en chantier mais on connaît la durée de ce genre de chantier ! Il faut donc que le programmeur qui connaissait la version Cobol ne soit pas noyé dans la nouvelle mouture transcodée. Sinon gare aux coûts de maintenance…
- Maintenabilité du nouveau code source Java : encore une fois, il s'agit de pouvoir poursuivre l'évolution fonctionnelle de l'application transcodée. Nous avons donc pris l'option de générer des servlets Java copiant le plus fidèlement possible le Cobol initial. Le Java généré n'est ensuite pas dans le plus pur style orienté objet mais si vous êtes prêts (nous l'étions à 100%) à des concessions dans la pureté théorique du code généré, le résultat obtenu est un programme Java calqué quasiment ligne pour ligne sur le programme Cobol originel. Un vrai bonheur pour les programmeurs applicatifs qui à la fois connaissait parfaitement leur "poésie" Cobol et ne sentent pas encore tout à fait à l'aise avec les dernières subtilités OO de Java.
- Homogénéité du code produit : comme personne ne met ces "petites mimines délicates" dans le code Java nouveau, ce dernier est incroyablement homogène car le code est généré à partir de l'analyse syntaxique du Cobol selon un algorithme, toujours le même. On efface donc les touches personnelles de poésie d'un code maintenu pendant longtemps par des personnes différentes.
- Nettoyage du code : le Cobol est structurellement simple. Il est donc possible de détecter puis de retirer certaines zones de code mort. Nous en avons encore sûrement laissé derrière nous, mais pas mal ont quand même été purgées.
- Iso-fonctionnalité du code : c'est une conséquence naturelle du transcodage automatique. Mais, elle est importante : en ne travaillant jamais à la main, on n'introduit pas d'erreurs et on ne met pas en danger le projet par "l'ajout en passant de ces quelques petites fonctions que tout le monde attend depuis longtemps" qui finissent par s'avérer fatales car, par leurs bugs, elles troublent tout le planning du projet.
- Découpage du code transcodé en 2 niveaux : nous avons découpé notre code généré en 2 couches,
- (a) la partie visible: un objet par verbe Cobol et un objet par variable du programme. Ces objets s'utilisent mutuellement pour exécuter le programme. Dans cette partie du code se trouve la correspondance ligne à ligne entre Cobol et Java. Ce sont donc ces 4 millions de lignes Java que les programmeurs applicatif maintiennent désormais chez nous
- (b) une bibliothèque d'exécution ("runtime"), appelée NacaRT - développée spécifiquement pour émuler Cobol et son environnement d'exécution (CICS ou batch). Cette bibliothèque est elle très (très) fortement orientée objet. Elle est le pilier d'appui des objets verbes et variables du (a).
- L'intérêt de cette architecture est multiple:
- (1) on préserve visuellement l'ordre et la structure du programme Cobol initial
- (2) la très forte orientation objet avec une hiérarchie d'héritage très profonde permet de faire évoluer de manière fondamentale le comportement du programme (performances, répartition de charge, etc…) par modification de l'implémentation des objets sous-jacents de la hiérarchie. Une hiérarchie profonde permet ensuite de circonscrire ces modifications de comportement à des zones plus ou moins vastes de l'application en fonction de l'endroit où l'on place la modification
Les conséquences d'un tel choix d'architecture de transcodage :
- Transcodage répétable autant que nécessaire : le processus est 100% automatique. L'absence d'intervention manuelle permet de refaire l'opération autant que nécessaire à coût nul ou presque.
- Stratégie de test devient encore plus critique : puisque l'on peut transcoder sans effort, on a envie de le faire souvent (voir les 2 points ci-dessous). Par contre, il faut alors pouvoir tester facilement le résultat effectif du transcodage. On arrive donc très vite à la conclusion qu'un outil de test automatique va de pair : nous avons donc développé cet outil de test (NacaTools) autant pour le batch que le transactionnel. Il s'agit de comparer une base de données résultant d'une batterie de transactions-tests en Java sur une base de départ connue à une copie de la même base de données résultant de la même série de transactions-tests faites depuis les transactions CICS. En plus bien sûr, on compare chaque champ de chaque écran de chaque transaction-test afin de vérifier que les 2 extrémités de l'application (les données permanentes et l'interface utilisateur) sont bien identiques. Nous avons ainsi développé plusieurs centaines de tests de nos applications que nous avons repassé des dizaines de fois pendant la mise au point du transcodeur et du runtime. L'objectif était de ne déranger les utilisateurs qu'une seule fois et pas chaque semaine pour tester les bugs corrigés durant la semaine (….et vivre de pleins fouets les nouveaux) : ils sont venus pour nous constituer la batterie de tests. Et ensuite, on ne les a revus que lors des tests finaux. Même si la migration est terminée, vous vous doutez sûrement que nous continuons à utiliser cette batterie de test comme outil d'assurance-qualité de la maintenance applicative faite maintenant manuellement par nos développeurs sur le nouveau-code Java.
- Continuité de l'évolution fonctionnelle applicative : le transcodage et les tests afférents étant sans douleur, on peut continuer à faire évoluer son application en Cobol pendant toute la période de bascule. En effet, on intègre les nouvelles fonctions en Cobol, on transcode et on teste automatiquement. Et hop, la nouvelle fonction fonctionne aussi en Java. Une telle migration entre le 100% des utilisateurs sur Cobol - 0% sur Java vers 0% sur Cobol - 100% sur Java dure forcément plusieurs mois, Il est impensable d'interrompre la maintenance fonctionnelle sur une telle durée.
- Possibilité de migration progressive : comme nous disposons, d'après ce qui précède, d'un moyen d'avoir une application identique dans le monde mainframe/COBOL et dans le monde Linux/Java sans peine ni coûts excessifs : nous avons pu prendre le temps de passer nos utilisateurs de l'ancien environnement au nouveau par "petits paquets" au début puis par paquets plus gros au fur et à mesure de la confiance croissante. Cela s'est ainsi fait sans douleur ni retour arrière. Encore aujourd'hui, je recommanderais exactement la même approche à tout projet de migration similaire. Cette souplesse de migration est le bon (meilleur ?) moyen de ne pas trop faire monter la pression. Dans une migration "big bang", on ne dispose que de quelques heures pour réagir quand un problème important survient sinon c'est retour arrière et le nombre des allers-retours est en général limité avant que le projet ne s'arrête définitivement… Dans une migration douce où les 2 applis cohabitent aussi longtemps que nécessaire, une telle pression n'existe jamais : on voit les goulets de performances arriver en ajoutant les paquets d'utilisateurs et en voyant leur impact. Quand le "mur" approche, on met la bascule en pause, on révise l'implémentation des objets du runtime qui posent souci et puis on repart. Pas de stress inutile !
- Possibilité de cohabitation de versions Cobol & Java à long terme : ce point ne nous concerne pas directement. Mais la stratégie NACA est intéressante pour un éditeur de logiciel qui aurait à faire cohabiter 2 versions de son application pendant la durée de migration d'un portefeuille de licences placées chez des clients : la méthode migration douce rend une mutation technologique quasiment transparente (… et très économique) car il dispose en permanence d'une application identique dans "l'ancien et le nouveau monde".
- Extension transparente des fonctionnalités de l'application originelle : la logique business est préservée lors du transcodage par la couche supérieure clonant le Cobol (cf. plus haut). Ensuite, l'extension des objets de la bibliothèque d'exécution permet d'ajouter des fonctions supplémentaires à forte valeur ajoutée avec un minimum d'effort. Pour donner quelques exemples (déjà réalisées dans NACA ou dans nos plans d'améliorations complémentaires) :
- Techniques: par ex: introduction de messages de logging partout où nécessaire, profiling de l'application, instrumentation automatique de l'application pour récupérer des données plus fine sur son utilisation, etc…
- Fonctionnelles: par ex
- lien "live" (par RPC) avec d'autres applications pour leur transmettre des en temps des données nouvelle / modifiées au sein de l'application commerciale
- génération automatisée d'hyperliens vers d'autres applications en fonction de la donnée affichée (ex.: l'affichage d'un code client est agrémenté d'un hyperlien vers le système de CRM externe ou vers une autre transaction de la même application utilisant le code client en entrée
- lien "live" (par RPC) avec d'autres applications pour leur transmettre des en temps des données nouvelle / modifiées au sein de l'application commerciale
- Techniques: par ex: introduction de messages de logging partout où nécessaire, profiling de l'application, instrumentation automatique de l'application pour récupérer des données plus fine sur son utilisation, etc…
Afin de ne pas faire trop long, je réserverai les détails d'architecture technique du système de transcodage à un prochain billet de la série promise sur le projet NACA.
J'espère par ce qui précède vous avoir convaincu de l'intérêt d'une migration progressive combinée à (… ou permise par) un transcodage automatique. En synthèse, on pourrait dire que c'est sûrement un peu plus long et coûteux qu'une migration "big bang" parfaitement menée. Mais, encore faut-il que le "parfaitement menée" soit une réalité sinon, pour le projet, c'est la trappe quasi-assurée ! Et chacun sait que la perfection n'est pas de ce monde….
Note (cf. début d'article) pour les (très) férus de détails technologiques: en plus de nos propres packages, nous avons fait appel aux composants Open Source suivants :
- Java lui-même qui est maintenant un vrai Open Source alors qu'il ne l'était pas au début du projet NACA
- Apache Tomcat comme conteneur des servlets représentant les clones des transactions CICS originelles. JBoss a été envisagé au début. Mais, n'ayant pas trouvé de réelle utilité à la lourde mécanique des EJBs ("Enterprise Java Beans") et ayant discuté avec d'autres les ayant mal vécus (performances et complexité, nous avons décidé de rester avec le très efficace (et incroyablement stable...) Tomcat jusqu'à ce qu'il ne suffise plus. Et, il a suffi jusqu'au bout ;-)
- l'IDE Eclipse avec divers plug-ins dont un spécifique développé "maison" sur lequel je reviendrai ultérieurement
- Berkeley Db java Edition pour ses fonctions de tris massifs dans les batches. C'est un moteur complet de fichiers ISAM mais nous n'avons pris que le tri car toutes nos données sont 100% relationnelles. Il a par ailleurs fallu l'enrichir pour supporter le très propriétaire format EBCDIC d'IBM.
- Quelques composants de l'immense librairie Apache Commons pour l'implémentation de certaines structures de données et fonctions très standards à toute application
- Apache Xerces comme parser XML dans le transcodeur lui-même et dans NacaRT pour le passage des XMLs générés par l'application à l'HTML envoyé par le navigateur
- Apache XSLTC comme compilateur XSLT pour les transformations successives des XMLs utilisés à l'exécution : enrichissements /modifications successifs du XML initial pour arriver à du HTML finalement envoyé au navigateur
- Quelques petits composants de Apache Struts pour une meilleure gestion des URLs, des servlets et de leur correspondance
- Apache Log4J pour assurer la journalisation (logging) de tous les messages émis par le transcodeur, l'application initiale et par les objets "instrumentés" de la biblliothèque NacaRT
- Apache Ant comme outil de transcodage / compilation / construction de l'ensemble de l'application ( NacaTrans, NacaRT, Nacatools + 4 millions de lignes de source Java de l'application transcodée. En fait, nous avons utilisé AntHill un dérivé commercial de Ant qui ne nous a pas donné entière satisfaction durant le projet: aujourd'hui, on prendrait Ant natif ou carrément autre chose dans le même domaine de la construction d'applications.
- CVS pour la gestion de tous ces sources. Aujourd'hui, ce serait vraisemblablement Subversion (SVN) qui était encore très / trop jeune quand nous avons commencé.
PS : (pour ceux arrivés jusque là dans la lecture...) : tout n'est pas aussi idyllique que cela pourrait en avoir l'air. J'ai demandé à nos développeurs / experts de faire un inventaire des "points durs" du transcodage. Ils feront l'objet d'un prochain billet.
# transcodage ?
Posté par IsNotGood . Évalué à 3.
[^] # Re: transcodage ?
Posté par Sylvain Sauvage . Évalué à 5.
— on passe d’un code à un autre, donc c’est du transcodage (http://atilf.atilf.fr/dendien/scripts/fast.exe?transcodage ) ;
— la traduction implique une interprétation (sémantique), c’est plus complexe que du transcodage, ce n’est pas ce qui est fait.
[^] # Re: transcodage ?
Posté par IsNotGood . Évalué à 2.
Un compilateur C va passer du C à l'assembleur. On dit (il me semble) qu'il fait une traduction du C vers l'assembleur (puis de l'assembleur vers de l'objet mais dans ce cas c'est assez proche de la définition de transcodage que tu donnes)
> — la traduction implique une interprétation (sémantique)
Ça me semblait nécessaire pour traduire/transcoder du Cobol vers du java.
> http://atilf.atilf.fr/dendien/scripts/fast.exe?transcodage
Selon ce lien, utiliser transcodage pour, par exemple, de la conversion de bmp à gif est sensé. Pour Cobol à Java ça ne me parait pas évident. M'enfin, je ne connais pas Cobol, très peu Java et je ne sais pas ce que fait le projet NACA.
[^] # Re: transcodage ?
Posté par Antoine . Évalué à 1.
Ben non, on appelle ça de la compilation.
[^] # Re: transcodage ?
Posté par IsNotGood . Évalué à 1.
[^] # Re: transcodage ?
Posté par Didier DURAND (site web personnel) . Évalué à 8.
J'ai utilisé transcodage plutôt que compilation car il y a dans "transcodage" l'idée de passer d'un code compréhensible par l'être humain (COBOL) à un autre code compréhensible (Java). Pour moi dans compilation, il y a finalement passage à un code machine incompréhensible par l'homme.
Par ailleurs, comme le niveau sémantique des 2 codes est similaire, je n'ai pas utilisé "traduction" car effectivement comme dit plus haut par IsNotGood, il n'y a pas d'apport sémantique dans le transcodeur. Pas mieux avant qu'après. donc pas de traduction.
Voilà, j'espère que cela tient debout à vos yeux! ;-)
cordialement
didier
[^] # Re: transcodage ?
Posté par IsNotGood . Évalué à 2.
Ça tient debout. Merci.
[^] # Re: transcodage ?
Posté par Pol' uX (site web personnel) . Évalué à 2.
Humm ... moi je ne suis pas informaticien, mais après avoir rapidement jeté un oeil là dessus (http://fr.wikipedia.org/wiki/Cobol#Exemple_de_programme_.28B(...) ), je me demande si on ne devrait pas parler de décompilation ;-)
Parce que niveau compréhension, je m'en sort mieux en assembleur ...
Le bon point, c'est que je comprend désormais l'intérêt du projet ;-)
PS : avis perso, heureusement que vous avez les sources de vos programmes, imaginez si vous aviez des solutions Bricosoft ...
Adhérer à l'April, ça vous tente ?
[^] # Re: transcodage ?
Posté par Ontologia (site web personnel) . Évalué à 3.
Donc, si je comprend bien, le transcodeur effectue un parsing produisant un arbre syntaxique représentant le code COBOL. Cet arbre syntaxique génère du code Java qui, à l'exécution, instancie les classes qui mettront l'arbre syntaxique en mémoire.
L'application Java, émulant la plateforme, exécute cette représentation du code.
Ca va jusqu'où ? Cela signifie qu'un test est un objet en Java ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: transcodage ?
Posté par Didier DURAND (site web personnel) . Évalué à 3.
Oui, nous avons une représentation objet très poussée: chaque instruction est un objet et même chaque partie d'une instruction (condition d'un test) est un objet
cordialement
didier
[^] # Re: transcodage ?
Posté par Antoine . Évalué à 5.
Non, c'est la compilation en entier :
- passage C -> assembleur : compilation
- passage assembleur -> binaire : assemblage (terminologie courante à l'époque où on écrivait des programmes entiers en ASM)
[^] # Re: transcodage ?
Posté par IsNotGood . Évalué à 1.
Et aujourd'hui tu dis quoi quand tu compiles^Wje_ne_sais_quoi un fichier C avec gcc pour avoir du code object ?
Moi je compile. Et toi ? Tu compiles-assembles ?
[^] # Compile "plus de bruit"
Posté par Antoine . Évalué à 5.
Et ? Si tu fais "gcc toto.c" tout court, l'édition de liens est implicite aussi. Cela ne veut pas dire que l'édition de liens fait partie de la compilation. De même pour le préprocessing. D'ailleurs toutes ces tâches sont effectuées par des exécutables séparés ("gcc" est une façade masquant l'enchaînement des différentes phases). Bref...
Et si tu ne me fais pas confiance, tu te remues un peu et tu vas lire Wikipédia :
« En pratique, un compilateur sert le plus souvent à traduire un code source écrit dans un langage de programmation en un autre langage, habituellement un langage d'assemblage ou un langage machine. » (note le "habituellement" et le "ou")
[à propos de l'assembleur] « Ce langage symbolique doit être assemblé (et non compilé) et lié pour obtenir une version exécutable. »
http://fr.wikipedia.org/wiki/Compilateur
« La transformation du code assembleur en langage machine est accomplie par un programme nommé assembleur, dans l'autre sens par un programme désassembleur. Les opérations s'appellent respectivement assemblage et désassemblage. »
http://fr.wikipedia.org/wiki/Langage_assembleur
Donc voilà, le passage de C à assembleur s'appelle compilation et le passage de l'assembleur au code machine s'appelle assemblage.
[^] # Re: Compile "plus de bruit"
Posté par IsNotGood . Évalué à -2.
J'ai dit "blabla ... pour avoir du code objet ?".
Je n'ai pas dit "blabla .. pour avoir un exécutable ?".
L'exécutable est la forme que l'OS peut charger et lancer l'exécution.
> De même pour le préprocessing.
Le préprocessing peut faire parti de la compilation (et en général il fait parti de la compilation).
> D'ailleurs toutes ces tâches sont effectuées par des exécutables séparés
Ce qui est un "détail" d'implémentation.
> http://fr.wikipedia.org/wiki/Compilateur
L'article ne me parait par clair.
http://fr.wikipedia.org/wiki/Compilation (c'est un résumé)
http://fr.wikipedia.org/wiki/Compilateur
Pour moi, la compilation c'est partir d'un fichier source (généralement comprehensible par un humain) qui ne peut être "exécuté" vers un code objet qui peut être exécuté (compréhensible par un cpu typiquement). Code objet natif (par exemple il peut être exécuter directement par un i386) ou code objet qui sera exécuté par une "machine virtuelle" (typiquement java, etc).
Notons que le compilateur java gcj peut produire du natif ou pour machine virtuel (quoique je n'en suis pas sûr ; quelqu'un pour confirmer ou infirmer ?).
L'édition de lien ne fait pas parti de la compilation car l'édition de lien ne produit pas de code machine. L'édition de lien donne des informations (comment lancer le code objet, à quelle adresse est la fonction bidule, etc).
Le language assembleur est compréhensible par un humain (OK, ils ne sont pas nombreux :-)). L'assembleur n'est pas compréhensible par le cpu (ou une machine virtuelle) et donc n'est pas du code object. On trouve de l'assembleur dans Linux. Cette assembleur doit être compilé (le terme assemblé me convient aussi). L'assembleur, pour un compilateur C par exemple, est généralement une étape intermédiaire lié à l'implémentation du compilateur. Un compilateur pourrait produire du code object directement et ça resterait un compilateur. Un "compilateur" (notez les guillements) qui ne fait que traduire du C (par exemple) à l'assembleur n'est pas un compilateur. Ce qui est produit ne peut être exécuté (lu par un cpu typiquement).
> « La transformation du code assembleur en langage machine est accomplie par un programme nommé assembleur, dans l'autre sens par un programme désassembleur. Les opérations s'appellent respectivement assemblage et désassemblage. »
Ça OK. Mais ce qui fait le passage de assembleur à code objet peut aussi est appelé un compilateur.
Mais la dénomination assembleur est bonne car, comme tu le pointes, on peut désassembler (avec quelques perte d'info comme les noms de variable). Il est rare qu'on puisse remonter au C depuis le code objet.
Notons qu'il y a (avait) des compilateurs C++ qui générait du C puis compilait le C.
Mais ce qui permet de passer de C++ à code objet, qu'il passer ou non par les languages intermédiaires C et assembleur, est un compilateur. Les formes intermédiaires sont des "détails" d'implémentations.
Un programme qui ne produit que de l'assembleur (et jamais de code objet) n'est pas un compilateur (selon moi).
[^] # Re: Compile "plus de bruit"
Posté par Antoine . Évalué à 2.
Tout ce verbiage inutile pour refuser d'admettre que, contrairement à ce que tu disais, le passage de C à assembleur était bien une "compilation" et non une "traduction".
Tout le reste, c'est hors sujet, ce n'est que ton perpétuel affichage narcissique sur ces forums.
(et en passant, va poster tes remarques sur Wikipédia si tu penses que les articles sont mal fichus et mensongers)
[^] # Re: Compile "plus de bruit"
Posté par IsNotGood . Évalué à -1.
Ok avec toi, je t'accorde trop d'importance.
> si tu penses que les articles sont mal fichus et mensongers
J'ai dit "pas clair".
Je t'accorde beaucoup trop d'importance.
[^] # Re: Compile "plus de bruit"
Posté par IsNotGood . Évalué à 1.
Et je ne suis pas le seul à le penser (aucun commentaire n'est de moi :-) ; pas encore) :
http://fr.wikipedia.org/wiki/Discuter:Compilateur
[^] # Re: Compile "plus de bruit"
Posté par Antoine . Évalué à 4.
« DESCRIPTION
When you invoke GCC, it normally does preprocessing, compilation, assembly
and linking.»
Et voici l'explication de l'option -S (celle qui permet de s'arrêter avant l'assemblage).
« -S Stop after the stage of compilation proper; do not assemble. »
# SVN vs CVS
Posté par Mimoza . Évalué à -5.
Pourquoi ont ils utilisé CVS au lieu de SVN? CVS même si il est un très bon outil épprouvé, souffre de quelques défauts de conception que SVN essaye de palier.
[^] # Re: SVN vs CVS
Posté par Nico C. . Évalué à 9.
Encore faut il tout lire...
[^] # Re: SVN vs CVS
Posté par Xavier Poinsard . Évalué à 2.
[^] # Re: SVN vs CVS
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Je l'utilise depuis plus de 2 ans et je ne vois vraiment pas ce qui lui manque...
[^] # Re: SVN vs CVS
Posté par deluxe . Évalué à 2.
# Bravo...
Posté par windu.2b . Évalué à 6.
Je ne peux que saluer l'effort fait pour expliquer au néophyte que je suis, les contraintes qui peuvent exister lors de la migration d'un projet aussi imposant (4 millions de lignes COBOL, ça n'est pas rien, je suppose...).
Donc bravo pour avoir été aussi détaillé, aussi précis. Je dois avouer que je n'avais vraiment pas idée que cela pouvait être aussi complexe (même si je me doute bien que ce genre de migration ne se fait pas en 5 minutes)
[^] # Re: Bravo...
Posté par Didier DURAND (site web personnel) . Évalué à 5.
Cela nous a fait aussi plaisir de livrer tous ces détails pour partager les résultats de notre travail.
cordialement
didier
# Approche MDA ?
Posté par benoar . Évalué à 3.
Sinon, je voulais savoir si une approche de type Model_driven_architecture n'avait pas été envisagée ? Parce que ce modèle de transcodage automatique, c'est un peu le principe de MDA, sauf que là votre représentation de base c'est le Cobol. Pour une vision à encore plus long terme (ce n'est peut-être pas votre but), la conversion en un modèle indépendant, puis la génération d'un modèle en Java, aurait pû être sympa. (je ne suis pas du tout un expert en MDA, c'était juste pour savoir si ça avait été évoqué, car ça m'y fait penser sous certains aspect)
Enfin, bravo pour ces articles très intéressant.
PS: ha si, je vais lancer un troll : l'appli interne (le transcodeur, le runtime) qui a servi à générer tout ça, ça restera interne ? Ce sera diffusé ? Sous quelle licence ? ...
[^] # Re: Approche MDA ?
Posté par Didier DURAND (site web personnel) . Évalué à 4.
L'approche MDA était trop complexe: le PIM (Platfom Indépendent Model) était très dur à "retro-enginieré". Nous sommes donc "seulement" passéss d'un PSM (Platform Specific Model) [Cobol] à un autre [Java].
Le PIM , ce sera pour la prochaine fois ! ;-)
Merci pour votre appréciation
Concernant le PS, on regarde toutes les éventualités mais une release OSS "interroge" beaucoup nos juristes. Il faut laisser un peu de temps au temps...
cordialement
didier
[^] # Re: Approche MDA ?
Posté par arnaudus . Évalué à 2.
[^] # Re: Approche MDA ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
La vente du logiciel aurait quelques effets négatifs :
1 - frais de commercialisation
2 - Nécessité de mettre en place une structure de support
3- Très peu d'utilisateurs
Il serait très étonnant que cela puisse être rentable, surtout que la vente de logiciels n'est pas votre c½ur de métier.
La mise sous licence GPL ou Cecill aurait un effet très positif sur l'image de marque de votre entreprise sans que cela lui coûte.
Je ne pense pas qu'un concurrent en bénéficie vraiment car vous avez un train d'avance et c'est un retard très difficile à rattraper. De plus, comme vous en possédez l'expertise, vous êtes les seuls experts.. Vendre (très cher) cette expertise ne demande aucune mise de fonds et ne présente aucun risque financier.
[^] # Re: Approche MDA ?
Posté par Anonyme . Évalué à 5.
Ca dépend, il est possible que la maintenance java libère des ressources humaines, et il peut être intéressant de vendre a la fois des licences très chères et une expertise très chère, avec les gens qui ont travaillé dessus. Peu de clients certes, mais des client riches (du moins ayant de très gros pour leur infrastructure informatique), et sur ce genre de plateforme, il y a plus de monde qu'on pourrait le penser.
Beaucoup des grands éditeurs actuels de logiciels métier sont des entreprises ayant développé leur propres solutions dans les années 80, exactement comme le cas de PubliGroup.
PubliGroup a potentiellement de l'or dans les mains, a condition de trouver le moyen, s'il y existe et qu'il est a leur disposition, de commercialiser la bête avec succès. J'espère que les dirigeants en ont conscience. Pour ma part, je trouverais triste que le fruit d'un projet d'une telle envergure ne soit utilisé qu'une seule fois. D'où l'intérêt du libre si une commercialisation maison ne se fait pas, mais dans ce cas, j'aurais peur que mes employé se barrent pour monter une SSLL autour de ce projet :)
# Et dotNET alors ?
Posté par Victor STINNER (site web personnel) . Évalué à -2.
[^] # Re: Et dotNET alors ?
Posté par IsNotGood . Évalué à 6.
[^] # Re: Et dotNET alors ?
Posté par windu.2b . Évalué à 3.
Et dire qu'on n'est que lundi... Qu'est-ce que ça sera vendredi prochain ?
[^] # Re: Et dotNET alors ?
Posté par Dring . Évalué à 5.
[^] # Une question
Posté par Antoine . Évalué à 5.
Est-ce que c'est possible avec COBOL.NET ? Ou est-ce qu'un instancieur de marshalling basé sur la POA est nécessaire pour bridger les deux environnements et ce, de manière transversale (i.e. commune à l'ensemble des composants de l'application) (*) ?
(*) là je verrais bien des fichiers de configuration en XML auto-documentants par un engine XSLT + Nuxeo Enterprise Platform, mais peut-être que je m'avance un peu
[^] # Re: Et dotNET alors ?
Posté par IsNotGood . Évalué à 2.
Surtout que tu vas être quasi obligé d'utiliser Windows. C'est une garantit supplémentaire à ne pas négliger sans compter toutes les innovations brevetés qu'apportent MS.
[^] # Re: Et dotNET alors ?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
[^] # Re: Et dotNET alors ?
Posté par François LEIBER (site web personnel) . Évalué à 2.
# Libérez ! Libérez! Libérez !
Posté par djainette . Évalué à 3.
La question qui me brûle les lèvres est la suivante : où en es-tu de ta réflexion sur la libération du code de ce projet ?
Je précise que je ne demande pas ça du tout par intéret, mon client ayant sa propre stratégie de migration... Je trouve juste ce procédé d'intéret général.
[^] # Re: Libérez ! Libérez! Libérez !
Posté par Didier DURAND (site web personnel) . Évalué à 2.
on y pense mais il y a encore qq questions en suspend.
didier
# Le jeu de la plus grosse?
Posté par PasRPasS . Évalué à -7.
Elle est énOooOrme celle là.
Bref... cobol vers java... pas brilliant. Obsolète vers obsolète. Bravo.
700 classes: Wouhahou! Je te parie que tout ça va être maintenable comme un airbus A380 avec une clé de 12.
Bon au moins ce sont des serveurs tournant avec GNU/Linux. Une lueur d'espoir dans un océan de...
[^] # Re: Le jeu de la plus grosse?
Posté par Anonyme . Évalué à 4.
Enfin c'est dommage que tu ne puisse pas voir l'étendue de la prouesse.
Sans compter que java est loin d'être obsolète, il n'y a pas eu d'avancée majeure des langages depuis, seulement des implémentation plus épurée de concepts presque tous aussi vieux les uns que les autres.
Et comparé a COBOL que l'on voie encore beaucoup trainer dans les rues salles serveurs de sous sol, java est très loin d'être pourri jusqu'à la moelle, et ce depuis sa naissance.
[^] # Re: Le jeu de la plus grosse?
Posté par Didier DURAND (site web personnel) . Évalué à 10.
C'est juste ce que l'on appelle une vraie appication. L'informatique professsionnelle ne se limite pas à des mashups de 100 lignes....
J'écris cela parce que je connais aussi des appllications natives OO encore nettement plus grosse que celle-ci.
Et le but n'est pas d'avoir la plus grosse, c'est juste de répondre aux vrais besoins.
didier
[^] # Re: Le jeu de la plus grosse?
Posté par PasRPasS . Évalué à -4.
Rooooh! qu'elle est belle! Je peux la citer sur le site d'e-consultant.
[^] # Re: Le jeu de la plus grosse?
Posté par Pierre Tramonson . Évalué à 1.
Très petit.
Quant à l'argument anti-Java, c'est sur que pour favoriser la maintenabilité il aurait mieux valu utiliser C++ ou PHP, des langages d'avenir robustes, eux.
[^] # Re: Le jeu de la plus grosse?
Posté par Antoine . Évalué à 3.
Mais non, pour faire de l'objet l'idéal c'est Perl.
(en attendant un hypothétique binding bash-gobject)
[^] # Re: Le jeu de la plus grosse?
Posté par PasRPasS . Évalué à -1.
La solution ultime: l'objet(TM).
C'est connu que l'objet(TM) n'est jamais sale et c'est LA solution(TM) de tous vos problèmes et pour "tous les projets qui se veulent en adéquation avec votre métier"(TM)
Allez! Maintenant t'achète mon gros kludge STP! Et que ça saute!
[^] # Re: Le jeu de la plus grosse?
Posté par PasRPasS . Évalué à -8.
Tu veux dire que tu en as une plus grosse? Noooooooooooon! C'est pas possible. Dis combien!
Ils auraient pu tout faire en C/C++/CGI(pour le web). Mais bon... y sont pas doués, peu rien faire contre ça... par contre ils savent se faire mousser sur linuxfr... là ils sont doués.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.