Les expériences avec « convertisseurs de langue »?

Question

J'ai lu quelques articles mentionnant des convertisseurs d'une langue à l'autre.

Je suis un peu plus sceptique quant à l'utilisation de ce type d'outils. Quelqu'un sait-il ou ont des expériences nous allons dire sur Visual Basic pour Java ou vs convertisseurs? Juste un exemple pour choisir

http://www.tvobjects.com/products/products.html , prétend être le « leader mondial » ou si dans cet aspect, si toutefois lire ceci:

http://dev.mysql.com/tech-resources /articles/active-grid.html

l'auteur déclare:

"Le consensus des utilisateurs MySQL est que les outils de conversion automatique pour, par exemple, MS Access ne fonctionnent pas. Outils qui se traduisent par des applications d'accès existantes à Java aboutissent souvent à 80% des solutions complètes où la finition du dernier 20% du travail prend plus de temps que à partir de zéro. "

Eh bien nous savons que nous avons besoin de 80% du temps pour mettre en œuvre la première fonctionnalité de 80% et un autre 80% du temps pour l'autre 20% ....

a quelqu'un a essayé ces outils et nous les avons trouvés vaut la peine?

Answer 1

Il me semble, comme presque toujours le cas avec des questions MS-ACCESS ayant des étiquettes qui attirent la population StackOverflow plus large, que les personnes répondant manquent la question clé ici, que je lis comme:

Y a-t-il des outils qui peuvent convertir avec succès une application d'accès à une autre plate-forme?

Et la réponse est

ABSOLUMENT PAS

La raison est tout simplement que les outils de la même famille qui utilisent des modèles similaires pour les objets d'interface utilisateur (par exemple, VB6) manque tant de choses que l'accès fournit par défaut (Comment convertir un sous-formulaire d'accès continu à VB6 et non la perte de fonctionnalité?). Et d'autres plates-formes ne partagent même pas le même modèle de base comme VB6 et l'accès, donc ceux qui ont encore plus obstacles à surmonter.

La cité l'article MySQL est très intéressant, mais il confond vraiment les problèmes qui viennent avec des applications développées par rapport aux incompétents les problèmes qui viennent avec les outils de développement utilisés. Un mauvais schéma de données ne sont pas inhérents à l'accès - il est inhérent aux utilisateurs novices de la base de données [plus]. Mais les articles semble attribuer ce problème d'accès.

Et donne tout à fait la possibilité de fixer le schéma, upsizing à MySQL et de garder l'avant dans Access, qui est de loin l'approche la plus simple au problème.

Ceci est exactement ce que je pense de gens qui ne ont pas accès - ils ne sont même pas considérer que l'accès en extrémité avant à un moteur de base de données de serveur à grande capacité sécurisable, peut être une solution supérieure au problème.

Cet article ne considère même pas vraiment la conversion d'une application d'accès, et il y a de bonnes raisons pour cela. Tous les outils que je l'ai vu qui prétendent convertir des applications d'accès (à quelque plate-forme) soit rien converti, mais les données (dans ce cas, ils ne se convertissent pas l'application à tous - crétins), ou convertir la structure d'extrémité avant servilement , avec un mélange 1: 1. correspondance entre les objets de l'interface utilisateur dans la demande d'accès et dans l'application cible

Cela ne fonctionne pas.

La conception d'applications d'accès est spécifique à lui-même, et d'autres plates-formes ne supportent pas le même ensemble de fonctionnalités. Ainsi, il doit y avoir la traduction d'accéder aux fonctions en un substitut de travail pour la fonction d'origine dans l'application convertie. Ce n'est pas quelque chose qui peut être fait de façon automatisée, à mon avis.

En second lieu, quand on envisage la conversion d'une application d'accès pour le déploiement dans le navigateur Web, l'ensemble du modèle d'application est différent, à savoir de stateful aux apatrides, et il est donc pas seulement une question de quelques fonctionnalités d'accès qui ne sont pas prise en charge, mais un modèle fondamental complètement différent de la façon dont les objets interface utilisateur interagissent avec les données. Peut-être une application d'accès non consolidé à 100% pourrait être converti relativement facilement à une mise en œuvre par navigateur, mais combien d'entre eux sont là? Cela signifierait une application d'accès qui utilise aucun sous-formulaires que ce soit (car ils ne peuvent pas être non liée), et une application qui utilise seulement une poignée d'événements du modèle d'événement riche (dont la plupart ne travailler qu'avec les formes / des contrôles liés). En bref, une application d'accès non consolidé à 100% serait celui qui se bat contre tout le paradigme de développement d'accès. Tous ceux qui pensent qu'ils veulent construire une application non liée dans Access ne devrait vraiment pas utiliser l'accès en premier lieu, comme point d'accès est toute les formes / contrôles liés! Si vous éliminez, vous avez jeté à la majorité des avantages de RAD Access sur les autres plates-formes de développement, et presque rien gagné en retour (autre que la complexité du code énorme).

Pour construire une application pour le déploiement dans le navigateur Web qui accomplit les mêmes tâches en tant que demandes d'accès nécessite de-la-sol jusqu'à la refonte de l'interface utilisateur de l'application et de workflow. Il n'y a pas de conversion ou de traduction qui fonctionne parce que le succès du modèle d'application Access irait à l'encontre du modèle d'application web réussie.

Bien sûr, tous ces changements avec Access 2010 et Sharepoint Server 2010 avec les services d'accès. Dans ce cas, vous pouvez construire votre application dans Access (en utilisant des objets Web) et déployer sur Sharepoint pour les utilisateurs de l'exécuter dans le navigateur. Les résultats sont fonctionnellement équivalents à 100% (et 90% visuellement), et exécuter sur tous les navigateurs (pas de dépendances spécifiques IE ici).

Alors, à partir de ce Juin, le meilleur moyen de convertir une application d'accès pour le déploiement dans le navigateur peut très bien être de passer à A2010, convertir la conception d'utiliser tous les objets Web, puis déployer avec Sharepoint. Ce n'est pas un projet trivial, comme des objets Web Access ont un ensemble limité de fonctionnalités par rapport aux objets clients (et pas VBA, par exemple, vous devez apprendre les nouvelles macros, qui sont beaucoup plus puissants et sûrs que les anciens, de sorte que ce n'est pas la terrible épreuve que cela puisse paraître pour ceux qui sont familiers avec les macros héritées d'accès), mais il serait probablement beaucoup moins de travail qu'une refonte à grande échelle pour le déploiement sur le web.

L'autre chose est qu'il ne nécessite aucun recyclage pour les utilisateurs finaux (dans la mesure où la version objet Web est le même que la version client d'origine), comme ce sera le même dans le client d'accès comme dans le web navigateur.

Donc, en bref, je dirais que la conversion est une chimère, et presque toujours ne vaut pas l'effort. Je suis d'accord avec le sentiment cité, en fait (même si j'ai beaucoup de problèmes avec les autres commentaires de cette source). Mais je voudrais aussi mettre en garde que le désir de conversion est souvent erronée et manque sur des solutions moins coûteuses, plus faciles et meilleures qui ne nécessitent pas de gros remplacement de l'application d'accès de haut en bas. Très souvent, l'insatisfaction à l'égard Jet / ACE stocker des données embrouille les gens à penser qu'ils doivent remplacer l'application d'accès aussi bien. Et il est vrai que de nombreuses applications d'accès développées par les utilisateurs sont remplis de compromis terribles, et sont maintenus ingérable avec la gomme à mâcher et fil videur. Mais une application d'accès mal conçu peut être améliorée en liaison avec l'arrière-plan du upsizing andrevision schéma de données -. Il ne doit pas être mis au rebut

Cela ne veut pas dire qu'il est facile - il est très souvent. Comme je dis aux clients tout le temps, il est généralement plus facile de construire une nouvelle maison que de rénover un ancien. Mais l'une des raisons pour lesquelles nous RÉNOVATION vieilles maisons est parce qu'ils ont des caractéristiques irremplaçables que nous ne voulons pas perdre. Il est très souvent le cas qu'une application Access inclut implicitement beaucoup de règles métier et la modélisation des flux de travail qui ne doivent pas être perdus dans une nouvelle application (l'ancien Netscape conundrum, le rythme Joel Spolsky). Ces choses peuvent ne pas être évident pour le développeur extérieur essayant de port à une autre plate-forme, mais pour l'utilisateur final, si l'application produit des résultats qui sont hors d'un centime par rapport à l'ancienne application, ils seront malheureux (et probablement devrait être, étant donné que cela peut signifier que d'autres aspects de l'application ne produisent pas de résultats fiables, que ce soit).

Quoi qu'il en soit, je me suis promené pendant trop longtemps, mais mon opinion est que la conversion ne fonctionne jamais, sauf pour les plus applications triviales (ou pour ceux qui ont été conçus pour être convertis, par exemple, une application d'accès non consolidé à 100%). Je suis pour la révision à la place de replacment.

Mais, bien sûr, voilà comment je gagne ma vie, à savoir la fixation des applications d'accès.

Answer 2

essayées? Non, en fait construit (plusieurs) langue convertisseur.

Voici que je (et mes collègues de travail) construit pour le B2 Spirit bombardier furtif pour convertir le logiciel de mission, codé dans une langue héritée, jOVIAL, en code maintenable C, avec 100% de conversion automatisée. L'une des conditions était que nous ne pouvions pas voir le code source. Sans blague.

Vous avez raison: si vous obtenez seulement un taux de conversion moyen élevé (par exemple, 70-80%), l'effort pour terminer la conversion est encore très important si vous pouvez en effet faire du tout. Nous visons 95% + et faire mieux quand on lui dit d'essayer plus fort comme ce fut le cas pour la B2. Les seules personnes raison acceptent des convertisseurs moyen à haut débit est parce qu'ils ne peuvent pas trouver (ou ne financerons pas!) Un meilleur, insister sur le démarrage maintenant , et accepter le fait que la conversion de cette façon peut être douloureux (en général, ils ne savent pas combien), mais est en fait moins douloureux que le reconstruire à partir de zéro. (Je suis d'accord avec cette évaluation: en général, les projets qui tentent de recoder un grand système à partir de zéro échouent habituellement et les conversions en utilisant des outils de taux de conversion moyen élevé ne pas que le taux d'échec élevé.)

Il y a beaucoup de mauvais outils de conversion là-bas, quelque chose giflé ensemble avec une montagne code PERL faire regexes sur des chaînes de texte, ou d'un analyseur à base YACC avec la génération de code essentiellement un à un pour chaque énoncé dans l'unité de compilation . Les premiers sont construites par des gens qui avaient une conversion abandonné sur eux du ciel. Ces derniers sont souvent construits par des ingénieurs bien intentionnés qui n'ont pas arrière-plan du compilateur décent.

Pour un exemple singulièrement mauvais, voir ma réponse à cette question SO sur la migration COBOL: DMS Software Reengineering Toolkit , qui était conçu pour faire ce travail. (Je suis l'architecte, vérifier mon icône SO / bio)

.

Beaucoup de tests minutieux aide aussi.

DMS « sait » ce que le compilateur connaît le code, en vertu d'avoir un compilateur comme frontal pour la langue d'intérêt, et ayant la capacité de RSHS de construction, des tables de symboles, de contrôle et de flux de données, des graphiques d'appel. Il utilise une grande partie de la technologie de compilateur que la communauté du compilateur a passé la inventant depuis un demi-siècle, parce que ce genre de choses a été avéré utile dans la traduction!

DMS sait plus que la plupart des compilateurs savent, car il peut lire / analyser / transformer l'ensemble de l'application à la fois; la plupart des compilateurs collent à des unités de compilation unique. Ainsi une des règles de traduction du code de boîte qui dépendent de l'ensemble de l'application plutôt que de simplement l'instruction en cours. Nous ajoutons souvent des connaissances ou de problèmes spécifiques à l'application pour améliorer la traduction. Cela montre souvent lors de la conversion des caractéristiques particulières d'une langue, ou des appels sur les bibliothèques, où il faut reconnaître les appels bibliothèque comme idiomes spéciaux, et de les traduire aux appels sur des compositions des bibliothèques cibles et des constructions de langage.

Cette capacité est utilisée pour les traducteurs de construction (par exemple, le traducteur JOVIAL) ou des générateurs de codes spécifiques à un domaine.

Le plus souvent nous construisons des outils complexes d'ingénierie de logiciels automatisés qui permettent de résoudre des problèmes SPECIFic aux clients, tels que des outils d'analyse de programme (code mort, le code en double, le code de style cassé, les mesures, l'extraction de l'architecture, ...) et des outils de changement de masse (plate-forme [non langauge] migrations, l'insertion de la couche de données, le remplacement de l'API, ...)

Answer 3

Quelques questions qui influent sur la réussite ou l'échec de la conversion interlangage sont la richesse sémantique relative des langues et leurs modèles sémantiques.

• Une traduction C ++ à C devrait être relativement facile, mais la traduction de C idiomatiques C ++ serait presque impossible, car ce serait presque impossible de tourner automatiquement un programme de procédure en un programme OO.

• Traduction de Java à C serait relativement simple, que la manipulation gestion du stockage serait en désordre. Traduction de C en Java serait presque impossible si le programme C a fait arithmétique funky pointeur ou coulée entre les entiers et les différents types de pointeur.

• Traduction d'un langage fonctionnel à un langage impératif serait beaucoup plus facile que le résultat serait probablement inefficace, un non idiomatiques. Traduction d'une langue impérative à un langage fonctionnel est probablement au-delà de l'état de l'art .... à moins que vous mettre en œuvre un interprète pour la langue impérative dans la langue fonctionnelle.

Ce que cela signifie est que certains traducteurs sont nécessairement va avoir plus de succès que d'autres en termes de:

• exhaustivité et l'exactitude de la traduction, et
• la lisibilité et la maintenabilité du code résultant.

Answer 4

choses que vous ne devriez jamais faire, la partie I par Joel Spolsky

» .... Ils l'ont fait en faisant la pire erreur stratégique unique que toute entreprise de logiciel peut faire:

Ils ont décidé de réécrire le code à partir de zéro. "

J'ai un liste des convertisseurs MS Access sur mon site . Je ne l'ai jamais entendu quoi que ce soit bien dans aucun d'entre eux dans tous les messages dans les forums liés à l'accès que je lis sur une base quotidienne. Et je l'ai lu beaucoup de messages sur une base quotidienne.

Notez également qu'il ya une quantité importante de fonctionnalités d'accès, telles que les formes continues liées ou les sous-formulaires qui est plus de travail à reproduire dans d'autres systèmes. Pas nécessairement beaucoup de travail, mais plus de travail. Et plus de problèmes quand vient le temps de distribuer et installer l'application.

Answer 5

Je l'ai utilisé un convertisseur automatisé de C # à Visual Basic.NET. Il a très bien fonctionné, sauf pour ajouter quelques déclarations de If True inutiles.

J'ai aussi tenté d'utiliser Shed peau pour convertir Python à C ++, mais cela n'a pas fonctionné à cause de son manque de soutien à la nouvelle division de style.

Answer 6

Je l'ai utilisé des outils pour la conversion d'un projet VB6 en VB.Net - que vous espérez serait peut-être l'un des exemples les plus simples de ce genre de chose. Mon expérience était que tout devait vérifier, dans les détails fins, et la moitié des choses était manquant / faux.

Certes, je recommande une migration à la main, ou en fonction de la langue que vous ciblage, je considère une réécriture complète si cela vous donne une chance de faire des améliorations majeures à votre base de code.

Martin

Answer 7

je n'ai essayé libre et de base payé pour des convertisseurs. Mais le principal problème est qu'il est très très difficile d'avoir confiance que la conversion est tout à fait réussie.

Habituellement, ils sont mieux utilisés pour la section de code de conversion de la main à un moment où vous passez en revue chaque morceau de code. Souvent, dans mon expérience une ré-écriture au lieu d'une conversion se révèle être une meilleure option.