Experiências com “conversores de linguagem”?

Question

Li alguns artigos mencionando conversores de um idioma para outro.

Sou um pouco mais do que cético quanto ao uso desse tipo de ferramenta.Alguém conhece ou tem experiências, digamos, sobre conversores Visual Basic para Java ou vs?Apenas um exemplo para escolher

http://www.tvobjects.com/products/products.html, afirma ser o "líder mundial" nesse aspecto, no entanto, se ler isto:

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

Aí o autor afirma:

"O consenso dos usuários do MySQL é que as ferramentas de conversão automatizada para MS Access não funcionam.Por exemplo, ferramentas que traduzem aplicativos existentes do Access para Java geralmente resultam em soluções 80% completas, onde terminar os últimos 20% do trabalho leva mais tempo do que começar do zero."

Bem, sabemos que precisamos de 80% do tempo para implementar os primeiros 80% de funcionalidade e outros 80% do tempo para os outros 20%....

Alguém já experimentou essas ferramentas e descobriu que valem a pena?

Answer 1

Parece-me, como quase sempre acontece com perguntas do MS-ACCESS com tags que atraem a população mais ampla do StackOverflow, que as pessoas que respondem estão perdendo a questão principal aqui, que li como:

Existem ferramentas que podem converter com êxito um aplicativo do Access para qualquer outra plataforma?

E a resposta é

ABSOLUTAMENTE NÃO

A razão para isso é simplesmente que as ferramentas da mesma família que usam modelos semelhantes para os objetos de UI (por exemplo, VB6) carecem de muitas coisas que o Access fornece por padrão (como você converte um subformulário contínuo do Access para VB6 e não perde funcionalidade? ).E outras plataformas nem sequer compartilham o mesmo modelo básico do VB6 e do Access, portanto, elas têm ainda mais obstáculos a serem superados.

O artigo MySQL citado é bastante interessante, mas realmente confunde os problemas que surgem com aplicativos desenvolvidos de forma incompetente versus aplicativos desenvolvidos de maneira incompetente.os problemas que surgem com as ferramentas de desenvolvimento usadas.Um esquema de dados incorreto não é inerente ao Access - é inerente à [maioria] dos usuários novatos de banco de dados.Mas os artigos parecem atribuir esse problema ao Access.

E ignora completamente a possibilidade de corrigir o esquema, transferi-lo para MySQL e manter o front-end no Access, que é de longe a abordagem mais fácil para o problema.

Isso é exatamente o que espero das pessoas que simplesmente não obtêm o Access - elas nem sequer consideram que o Access como front-end para um mecanismo de banco de dados de servidor seguro e de grande capacidade possa ser uma solução superior para o problema.

Esse artigo nem sequer considera a conversão de um aplicativo do Access, e há um bom motivo para isso.Todas as ferramentas que eu vi que afirmam converter aplicativos do Access (para qualquer plataforma) ou convertem nada além de dados (nesse caso, elas não convertem o aplicativo - idiotas!) Ou convertem a estrutura do front-end servilmente , com uma correspondência 1:1 entre objetos de UI no aplicativo Access e no aplicativo de destino.

Isso não funciona.

O design do aplicativo do Access é específico e outras plataformas não oferecem suporte ao mesmo conjunto de recursos.Portanto, deve haver tradução dos recursos do Access em um substituto funcional para o recurso original no aplicativo convertido.Na minha opinião, isso não é algo que possa ser feito de forma automatizada.

Em segundo lugar, ao considerar a conversão de um aplicativo do Access para implantação no navegador da Web, todo o modelo do aplicativo é diferente, ou seja, de estado para sem estado e, portanto, não se trata apenas de alguns recursos do Access que não são suportados, mas de um sistema completamente diferente. modelo fundamental de como os objetos da UI interagem com os dados.Talvez um aplicativo Access 100% não vinculado possa ser convertido com relativa facilidade em uma implementação baseada em navegador, mas quantos deles existem?Isso significaria um aplicativo do Access que não usa nenhum subformulário (já que eles não podem ser desvinculados) e um aplicativo que usa apenas alguns eventos do modelo de evento rico (a maioria dos quais funciona apenas com formulários/controles vinculados).Resumindo, um aplicativo Access 100% livre seria aquele que luta contra todo o paradigma de desenvolvimento do Access.Qualquer pessoa que pensa que deseja construir um aplicativo não vinculado no Access realmente não deveria usar o Access em primeiro lugar, já que o ponto principal do Access são os formulários/controles vinculados!Se você eliminar isso, você jogará fora a maior parte da vantagem RAD do Access sobre outras plataformas de desenvolvimento e não ganhará quase nada em troca (além da enorme complexidade do código).

Para criar um aplicativo para implantação no navegador da Web que execute as mesmas tarefas que os aplicativos do Access, é necessário um redesenho completo da interface do usuário e do fluxo de trabalho do aplicativo.Não há nenhuma conversão ou tradução que funcione porque o modelo de aplicativo do Access bem-sucedido é a antítese do modelo de aplicativo da Web bem-sucedido.

É claro que tudo isso muda com o Access 2010 e o Sharepoint Server 2010 com Access Services.Nesse caso, você pode criar seu aplicativo no Access (usando objetos da web) e implantá-lo no Sharepoint para que os usuários o executem no navegador.Os resultados são funcionalmente 100% equivalentes (e 90% visualmente) e são executados em todos os navegadores (sem dependências específicas do IE aqui).

Portanto, a partir de junho deste ano, a maneira mais barata de converter um aplicativo do Access para implantação no navegador pode muito bem ser atualizar para o A2010, converter o design para usar todos os objetos da web e, em seguida, implantar com o Sharepoint.Esse não é um projeto trivial, pois os objetos web do Access possuem um conjunto limitado de recursos em comparação aos objetos cliente (e não possuem VBA, por exemplo, então você precisa aprender as novas macros, que são muito mais poderosas e seguras que as antigas, então essa não é a terrível dificuldade que pode parecer para aqueles familiarizados com as macros herdadas do Access), mas provavelmente daria muito menos trabalho do que uma reformulação em grande escala para implantação na web.

A outra coisa é que não será necessário nenhum retreinamento para os usuários finais (na medida em que a versão do objeto da web seja igual à versão original do cliente), pois será a mesma no cliente Access e no navegador da web.

Resumindo, eu diria que a conversão é uma quimera e quase sempre não vale o esforço.Na verdade, concordo com o sentimento citado (mesmo que tenha muitos problemas com os outros comentários dessa fonte).Mas eu também alertaria que o desejo de conversão é muitas vezes equivocado e perde soluções mais baratas, mais fáceis e melhores que não exigem a substituição em massa do aplicativo Access de cima para baixo.Muitas vezes, a insatisfação com o Jet/ACE como armazenamento de dados confunde as pessoas, fazendo-as pensar que também precisam substituir o aplicativo Access.E é verdade que muitos aplicativos Access desenvolvidos por usuários estão cheios de compromissos terríveis e insustentáveis ​​e são mantidos juntos com chicletes e arame farpado.Mas um aplicativo Access mal projetado pode ser melhorado em conjunto com o upsizing e a revisão de back-end do esquema de dados – ele não precisa ser descartado.

Isso não significa que seja fácil - muitas vezes não é.Como costumo dizer aos clientes o tempo todo, geralmente é mais fácil construir uma casa nova do que reformar uma antiga.Mas uma das razões pelas quais remodelamos casas antigas é porque elas têm características insubstituíveis que não queremos perder.É muito comum que um aplicativo do Access inclua implicitamente muitas regras de negócios e modelagem de fluxos de trabalho que não devem ser perdidas em um novo aplicativo (o antigo enigma do Netscape, segundo Joel Spolsky).Essas coisas podem não ser óbvias para o desenvolvedor externo que está tentando migrar para uma plataforma diferente, mas para o usuário final, se o aplicativo produzir resultados que estão um centavo abaixo do aplicativo antigo, ele ficará infeliz (e provavelmente deveria ser, pois pode significar que outros aspectos do aplicativo também não estão produzindo resultados confiáveis).

De qualquer forma, divaguei por muito tempo, mas minha opinião é que a conversão nunca funciona, exceto para os aplicativos mais triviais (ou para aqueles que foram projetados para serem convertidos, por exemplo, um aplicativo Access 100% não vinculado).Sou totalmente a favor da revisão em vez da substituição.

Mas, claro, é assim que ganho a vida, ou seja, consertando aplicativos do Access.

Answer 2

Tentou? Não, realmente construído (mais de um) conversor de idiomas.

Aqui está um que eu (e meus colegas de trabalho) construídos para o B2 Bomer furtivo Spirit Para converter o software da missão, codificado em um idioma herdado, jovial, em código C sustentável, com conversão 100% automatizada. Um dos requisitos era que não tivemos permissão para ver o código -fonte real. Não é brincadeira.

Você está certo: se você obtiver apenas uma taxa média alta de conversão (por exemplo, 70-80%), o esforço para concluir a conversão ainda é muito significativo, se você puder fazê-lo. Tivemos 95%+ e nos saímos melhor quando instruídos para se esforçar mais, como foi o caso do B2. A única razão pela qual as pessoas aceitam conversores de alta taxa média é porque não conseguem encontrar (ou não financiam!) agora, e aceite o fato de que convertê -lo dessa maneira pode ser doloroso (geralmente eles não sabem quanto), mas é de fato menos doloroso do que reconstruí -lo do zero. (Por acaso, concordo com esta avaliação: em geral, projetos que tentam recodificar um grande sistema do zero geralmente falham e as conversões usando ferramentas de taxa de conversão média alta não têm uma taxa de falha tão alta.)

Existem muitas ferramentas ruins de conversão por aí, algo que deu um tapa junto com uma montanha de código Perl fazendo regexes em seqüências de texto, ou algum analisador baseado em YACC com geração de código essencialmente individual para cada instrução na unidade de compilação. Os primeiros são construídos por pessoas que tiveram uma conversão caídas sobre eles para fora do céu. Estes últimos são frequentemente construídos por engenheiros bem-intencionados que não possuem fundo decente do compilador.

Para um exemplo singularmente ruim, veja minha resposta a isso, então pergunta sobre a migração de COBOL: Experimente migrando o legado COBOL/PL1 para Java, que é exatamente um tradutor de declaração direta ... produzindo as coisas que deram origem ao termo "Jobol".

Para obter taxas de conversão tão de alta precisão, você precisa de analisadores de alta qualidade e meios para criar regras de tradução de alta qualidade que preservam a semântica e otimizem para propriedades e casos especiais da língua-alvo. Em essência, você precisa de quais quantias para a tecnologia de compiladores configuráveis. A razão pela qual temos sucesso, IMHO, é o nosso DMS Software Reengeneering Toolkit, que foi projetado para fazer esse trabalho. (Eu sou o arquiteto; confira meu ícone/bio).

Muitos testes cuidadosos também ajudam.

O DMS "sabe" o que o compilador conhece sobre o código, em virtude de ter um front end do tipo compilador para a linguagem de interesse e a capacidade de criar ASTs, tabelas de símbolos, controle e fluxos de dados, chamam gráficos. Ele usa grande parte da tecnologia do compilador que a comunidade do compilador passou o último meio século inventando, Porque essas coisas provaram ser úteis na tradução!

DMS sabe mais O que a maioria dos compiladores sabe, porque pode ler/analisar/transformar todo o aplicativo de uma só vez; A maioria dos compiladores adere a unidades de compilação única. Assim, pode -se codificar regras de tradução que dependem de todo o aplicativo, em oposição a apenas a instrução atual. Costumamos adicionar conhecimento específico para problemas ou aplicativos para melhorar a tradução. Isso geralmente aparece ao converter recursos especiais de um idioma, ou exige bibliotecas, onde é preciso reconhecer as chamadas da biblioteca como idiomas especiais e traduzi -los para chamadas em composições de bibliotecas de destino e construções de idiomas.

Esse recurso é usado para criar tradutores (por exemplo, o tradutor jovial) ou geradores de código específicos de domínio.

Mais frequentemente, criamos ferramentas complexas de engenharia de software automatizadas que resolvem problemas específicos para clientes, como ferramentas de análise de programas (código morto, código duplicado, código quebrado de estilo, métricas, extração de arquitetura, ...) e ferramentas de mudança de massa (plataforma [ não Langauge] Migrações, inserção da camada de dados, substituição da API, ...)

Answer 3

Algumas questões que afetam o sucesso ou o fracasso da conversão entre idiomas são a riqueza semântica relativa dos idiomas e seus modelos semânticos.

• A tradução de C ++ para C deve ser relativamente fácil, mas a tradução de C para idiomático O C ++ seria quase impossível, porque isso seria quase impossível de transformar automaticamente um programa processual em um programa OO.

• A tradução de Java para C seria relativamente simples, embora o gerenciamento de armazenamento seja confuso. A tradução de C em Java seria quase impossível se o programa C fizesse aritmética de ponteiro descolado ou fundição entre números inteiros e diferentes tipos de ponteiro.

• A tradução de uma linguagem funcional para uma linguagem imperativa seria muito fácil, embora o resultado provavelmente fosse ineficiente, um não-ideal. A tradução de uma linguagem imperativa para uma linguagem funcional provavelmente está além do estado da arte ... a menos que você implemente um intérprete para a linguagem imperativa na linguagem funcional.

O que isso significa é que alguns tradutores são necessariamente vai ter mais sucesso do que outros em termos de:

• integridade e precisão da tradução e
• legibilidade e manutenção do código resultante.

Answer 4

Coisas que você nunca deve fazer, parte eu por Joel Spolsky

".... eles fizeram isso cometendo o pior erro estratégico que qualquer empresa de software pode cometer:

Eles decidiram reescrever o código do zero. "

eu tenho um Lista de conversores de acesso ao MS no meu site. Nunca ouvi nada de bom sobre nenhum deles em nenhuma postagem nos grupos de notícias relacionados ao acesso que li diariamente. E eu li muitas postagens diariamente.

Observe também que existe uma quantidade significativa de funcionalidade no acesso, como formas ou subforms contínuos ligados, que é mais trabalho para se reproduzir em outros sistemas. Não é necessariamente muito trabalho, mas mais trabalho. E mais problemas quando chegar a hora de distribuir e instalar o aplicativo.

Answer 5

Eu usei um conversor automatizado de C# para Visual Basic.net. Funcionou muito bem, exceto para adicionar alguns desnecessários If True declarações.

Eu também tentei usar Derramar pele Para converter o Python-C ++, mas não funcionou por causa de sua falta de apoio à divisão de novos estilo.

Answer 6

Eu usei ferramentas para converter um projeto VB6 em vb.net - que você espera que talvez seja um dos exemplos mais simples desse tipo de coisa. Minha experiência foi que tudo tinha que ser verificado, em detalhes, e metade das coisas estava faltando / errada.

Certamente, eu recomendaria uma migração manualmente, ou dependendo do idioma que você tem como alvo, consideraria uma reescrita completa se isso lhe der a chance de fazer grandes melhorias na sua base de código.

Martin

Answer 7

Eu tentei apenas conversores gratuitos e pagos básicos.Mas o principal problema é que é muito difícil ter certeza de que a conversão foi totalmente bem-sucedida.

Geralmente eles são mais usados ​​para converter manualmente uma seção de código por vez, onde você revisa cada parte do código.Muitas vezes, na minha experiência, uma reescrita em vez de uma conversão acaba sendo uma opção melhor.