Erfahrungen mit „Sprache-Wandler“?

https://stackoverflow.com/questions/3027705

26-09-2019
|

Frage

Ich habe ein paar Artikel zu erwähnen Wandler von einer Sprache in eine andere zu lesen.

Ich bin ein bisschen mehr als skeptisch, was die Verwendung solchen Art von Werkzeugen. Hat jemand wissen oder Erfahrungen sagen wir mal über Visual Basic auf Java oder vs-Wandler? Um nur ein Beispiel wählen

http://www.tvobjects.com/products/products.html , Ansprüche der „Weltmarktführer“ oder so in diesem Aspekt zu sein, aber diese, wenn lesen:

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

Der Autor stellt fest:

"Der Konsens von MySQL-Anwender ist, dass automatisierte Konvertierungs-Tools für MS Access nicht funktionieren. Zum Beispiel Werkzeuge, die oft vorhandenen Access-Anwendungen auf Java übersetzen führen zu 80% abgeschlossen Lösungen, bei denen die letzten 20% der Beendigung der Arbeit dauert länger als von vorne anfangen. "

Nun, wir wissen, dass wir 80% der Zeit müssen die ersten 80% Funktionalität und weitere 80% der Zeit für die anderen 20% ....

zu implementieren

So hat jemand versucht, solche Werkzeuge und fand sie interessant zu sein?

Lösung

Es scheint mir, wie fast immer der Fall ist mit MS-ACCESS Fragen Tags aufweisen, die die breitere Bevölkerung Stackoverflow anziehen, dass die Menschen, die Beantwortung sind hier die Schlüsselfrage fehlen, die wir lesen, wie:

Gibt es irgendwelche Werkzeuge, die erfolgreich eine Access-Anwendung auf einer anderen Plattform umwandeln kann?

Und die Antwort ist

ABSOLUT NICHT

Der Grund dafür ist einfach, dass Werkzeuge in der gleichen Familie, die für die UI-Objekte ähnliche Modelle verwenden (zB VB6) fehlen so viele Dinge, dass Access standardmäßig bietet (wie Sie ein Access-kontinuierliches Formular auf VB6 konvertieren und nicht lose Funktionalität?). Und andere Plattformen nicht einmal das gleiche Core-Modell wie VB6 und Zugang zu teilen, so dass diejenigen, haben noch mehr Hürden zu löschen.

Die zitierte MySQL Artikel sind recht interessant, aber es verwirrt wirklich die Probleme, die im Vergleich zu den Problemen mit inkompetent entwickelten Anwendungen kommen, die mit der Entwicklung kommen Werkzeuge verwendet werden. Ein schlechtes Datenschema ist für den Zugriff nicht angeboren - es ist inhärent [meisten] Anfänger Datenbankbenutzer. Aber die Artikel scheint dieses Problem zu Zugang zuschreiben.

Und mit Blick auf ganz die Möglichkeit, das Schema der Festsetzung es zu MySQL Upsizing und das vordere Ende in Access zu halten, die bei weitem die einfachste Lösung des Problems ist.

Das ist genau das, was ich von den Leuten erwarten, die gerade nicht Zugang bekommt - sie sind nicht der Ansicht, dass auch Access als Frontend zu einem festlegbar, großer Kapazität Server-Datenbank-Engine eine bessere Lösung für das Problem sein kann.

Dieser Artikel ist nicht einmal wirklich Umwandlung von einer Access-App betrachten, und es gibt gute Gründe dafür. Alle Werkzeuge, dass ich Anspruch auf convert Access-Anwendungen gesehen, dass (auf das, was Plattform) entweder konvertieren nichts anderes als Daten (in diesem Fall werden sie wandeln die App nicht auf allen - morons) oder die vordere Endstruktur konvertieren sklavisch , mit einer 1:. 1 Korrespondenz zwischen UI-Objekten in der Access-Anwendung und in dem Ziel App

Das funktioniert nicht.

Zugriff des Anwendungsdesign ist spezifisch für sich selbst und andere Plattformen nicht den gleichen Satz von Funktionen unterstützen. So hat es Funktionen für die ursprüngliche Funktion in der konvertierten Anwendung in eine Arbeits Ersatz Übersetzung des Zugangs sein. Dies ist nicht etwas, das in einer automatisierten Weise durchgeführt werden kann, meiner Meinung nach.

Zweitens, wenn eine Access-App Umwandlung für den Einsatz im Web-Browser betrachten, das gesamte Anwendungsmodell ist anders, das heißt von Stateful zu staatenlos, und so ist es nicht nur eine Frage von wenigen Access-Funktionen, die nicht unterstützt werden, sondern von ein ganz andere grundlegende Modelle, wie die UI-Objekte interact mit den Daten. Vielleicht ist ein 100% ungebundenen Zugang App relativ leicht zu einem Browser-basierte Implementierung umgesetzt werden könnte, aber wie viele von denen gibt es? Es wäre eine Access-App bedeuten, die keine subforms nutzt auch immer (da sie nicht ungebunden sein kann), und eine App, dass Anwendungen nur eine Handvoll von Ereignissen aus dem reichen Event-Modell (die meisten davon arbeiten nur mit gebundenen Formen / Kontrollen). Kurz gesagt, ein 100% ungebundener Zugang App ein, die Kämpfe gegen das gesamte Access-Entwicklungsparadigma wäre. Wer glaubt, sie bauen wollen sein ein ungebundenes App in Access sollte wirklich nicht Zugang in erster Linie verwendet wird, wie der ganze Sinn des Zugangs ist die gebundenen Formen / Kontrollen! Wenn Sie, dass zu beseitigen, haben Sie die Mehrheit des Zugangs von RAD Vorteile gegenüber anderen Entwicklungsplattformen hinausgeworfen, und fast im Gegenzug nichts (außer enorme Komplexität des Codes) gewonnen.

eine App für den Einsatz im Web-Browser erstellen, die die gleichen Aufgaben wie eine Access-Anwendungen erreicht erfordert von-der-Boden-up Neugestaltung der Anwendung UI und Workflow. Es gibt keine Konvertierung oder Übersetzung, die funktioniert, weil das erfolgreiche Access-Anwendung Modell für das erfolgreiche Web-Anwendung Modell gegensätzlich ist.

Natürlich all diese Änderungen mit Access 2010 und Sharepoint Server 2010 mit Access Service. In diesem Fall können Sie Ihre Anwendung in Access (mit Web-Objekten) und Bereitstellen von auf Sharepoint aufbauen für Benutzer im Browser ausgeführt werden. Die Ergebnisse sind in ihrer Funktion 100% entspricht (und 90% visuell) und laufen auf allen Browsern (keine IE-spezifische Abhängigkeiten hier).

So, beginnend im Juni dieses Jahr, der billigste Weg, einen Access-App für den Einsatz im Browser kann sehr gut zu konvertieren sein A2010 zu aktualisieren, konvertiert das Design alle Web-Objekte zu verwenden, und dann mit Sharepoint bereitstellen. Das ist kein triviales Projekt, als Access-Web-Objekte eine begrenzte Anzahl an Funktionen im Vergleich zu Client-Objekte (und keine VBA, zum Beispiel, so haben Sie die neue Makros zu lernen, die sind viel leistungsfähiger und sicherer sind als die alten, so dass nicht die schreckliche Not ist es für diejenigen, die mit Access-Vermächtnis Makros scheinen mag), aber es wahrscheinlich viel weniger Arbeit als ein Full-Scale-Redesign für den Einsatz im Web.

sein würde

Die andere Sache ist, dass es nicht erforderlich wird jede für Benutzer Ende Umschulung (soweit das Web-Objekt-Version die gleiche wie die ursprüngliche Client-Version ist), da sie die gleiche in der Access-Client sein wird, wie im Web Browser.

Also, kurz gesagt, ich würde sagen, Umwandlung eine Chimäre ist, und fast immer nicht die Mühe wert. Ich bin einverstanden mit dem zitierten Gefühl, in der Tat (auch wenn ich viele Probleme mit den anderen Kommentaren aus dieser Quelle habe). Aber ich würde warnen auch, dass der Wunsch nach Umwandlung oft fehlgeleitet wird und verpaßt billiger, einfache und bessere Lösungen, die nicht benötigen Großhandel Ersatz der Access-App von oben nach unten. Sehr oft ist die Unzufriedenheit mit Jet / ACE als Daten speichern verwirrt die Leute zu denken, sie die Access-Anwendung als auch zu ersetzen. Und es ist wahr, dass viele Benutzer entwickelten Access-Anwendungen gefüllt sind mit schrecklich, wartbaren Kompromisse und zusammengehalten werden, mit Kaugummi und Ausschöpfen Draht. Aber eine schlecht gestaltete Access-Anwendung kann mit der Back-End-upsizing andrevision des Datenschemas in Verbindung verbessert werden. - es nicht verworfen werden muß

Das bedeutet nicht, es ist leicht - es ist sehr oft nicht. Wie ich Kunden die ganze Zeit sagen, dann ist es in der Regel einfacher, ein neues Haus zu bauen, als eine alte neu zu gestalten. Aber einer der Gründe, warum wir alte Häuser umzubauen, weil sie unersetzlich Eigenschaften haben, dass wir nicht wollen, zu verlieren. Es ist sehr oft der Fall, dass ein Access-App implizit eine Menge von Geschäftsregeln und Modellierung von Workflows enthält, die nicht in einer neuen App (die alten Netscape conundrum, Tempo Joel Spolsky) verloren werden sollte. Diese Dinge können nicht nach außen Entwickler versucht, in den Hafen einer anderen Plattform, aber für den Endverbraucher klar sein, wenn die App Ergebnissen führt, die von einem Cent im Vergleich zu der alten App ausgeschaltet sind, werden sie unglücklich sein (und wahrscheinlich sein sollte, da es sich, dass andere Aspekte der App kann bedeuten zuverlässige Ergebnisse nicht produzieren, entweder).

Wie auch immer, ich habe zu lange streifte, aber meiner Meinung nach ist, dass die Umwandlung funktioniert nie außer den trivialsten Apps (oder für diejenigen, die konvertiert wurden entwickelt, um beispielsweise eine 100% ungebundenen Zugang app). Ich bin für die Revision anstelle von replacment.

Aber natürlich, das ist, wie ich mein Leben zu machen, das heißt, Zugang Apps fixieren.

Andere Tipps

versucht das? Nein, eigentlich gebaut (mehr als ein) Sprache-Wandler.

Hier ist ein ich (und meine Mitarbeiter) gebaut für den B2 Spirit Stealth Bomber die Mission Software, codiert in einem Legacy-Sprache, JOVIAL, in wartbar C-Code, mit 100% automatische Konvertierung zu konvertieren. Eine der Anforderungen war, dass wir den eigentlichen Quellcode nicht erlaubt zu sehen waren. Kein Witz.

Sie haben Recht: Wenn Sie nur eine mittlere hohe Conversion-Rate erhalten (zum Beispiel 70-80%), die Bemühung um die Konvertierung zu beenden ist immer noch sehr wichtig, wenn in der Tat Sie es überhaupt tun kann. Wir haben das Ziel 95% + und besser tun, wenn gesagt schwieriger zu versuchen, wie es der Fall für die B2 war. Der einzige Grund, die Menschen akzeptieren Medium hohe Rate-Wandler ist, weil sie nicht (oder wird nicht Fonds!) Einen besseren finden können, bestehen Sie auf Start jetzt , und die Tatsache akzeptieren, dass es auf diese Weise zu konvertieren kann schmerzhaft sein (in der Regel wissen sie nicht, wie viel), aber ist in der Tat weniger schmerzhaft, als es von Grund auf neu zu erstellen. (Ich zufällig mit dieser Einschätzung einverstanden sind: in der Regel Projekte, die versuchen, ein großes System von Grund auf neu zu codieren in der Regel und Conversions scheitern hohe Conversion-Rate-Tools Medium haben nicht so hohe Ausfallrate.)

Es gibt viele schlechte Konvertierungs-Tools da draußen, etwas schlug zusammen mit einem Berg von PERL-Code Regexes auf Textstrings oder einige YACC basierte Parser mit Code-Generierung zu tun im wesentlichen eine Eins-zu-eins für jede Anweisung in der Übersetzungseinheit . Erstere werden von den Menschen gebaut, die eine Umwandlung hatte auf sie fiel vom Himmel aus. Letztere werden oft von gut gemeinten Ingenieuren gebaut, die keinen anständigen Compiler Hintergrund.

Für ein außerordentlich schlechtes Beispiel, siehe meine Antwort auf diese Frage SO über COBOL-Migration: DMS Software Reengineering Toolkit , das war entwickelt, um diese Arbeit zu tun. (Ich bin der Architekt, check out my SO Symbol / bio)

Viele sorgfältigen Prüfung hilft auch.

DMS „weiß“, was der Compiler über Code kennt, durch ein Compiler-Frontend wie für die Sprache von Interesse, und die Fähigkeit zu bauen Ästen, Symboltabellen, Steuerung und Datenflüsse, Call Graphen. Er verwendet viel von der Compiler-Technologie, dass die Compiler-Gemeinschaft des letzte halbes Jahrhundert Erfinden verbracht, , weil das Material in der Übersetzung als nützlich erwiesen hat!

DMS weiß mehr als die meisten Compiler wissen, weil sie lesen können / analysieren / verwandeln die gesamte Anwendung auf einmal; die meisten Compiler halten Sie sich an einzelne Übersetzungseinheiten. man kann Codeübersetzungsregeln So, die auf der gesamten Anwendung ab, im Gegensatz zu nur die aktuelle Anweisung. Wir fügen häufig problem- oder applikationsspezifische Wissen, um die Übersetzung zu verbessern. Diese oft zeigt sich, wenn Besonderheiten einer Sprache umwandelt, oder Anrufe auf Bibliotheken, in denen man die Bibliothek Anrufe als besondere Idiome erkennen müssen, und übersetzen sie auf Anrufe auf Kompositionen von Ziel Bibliotheken und Sprachkonstrukte.

Diese Fähigkeit zu bauen Übersetzer verwendet wird (beispielsweise die JOVIAL Übersetzer) oder domänenspezifische Code-Generatoren.

Häufiger bauen wir komplexe automatisierte Software-Engineering-Tools, die Probleme zu lösen SPECIFic an Kunden, wie beispielsweise Programmanalysewerkzeuge (toter Code, Code-Duplikat, Stil-gebrochen-Code, Metriken, Architektur Extraktion, ...), und die Massenänderung Werkzeuge (platform [nicht Langauge] Migrationen Datenschicht Insertion, API-Ersatz, ...)

Ein paar Fragen, die Wirkung des Erfolg oder Misserfolg von sprachübergreifende Umwandlung ist die relative semantische Vielfalt der Sprachen und ihre semantischen Modelle.

Die Übersetzung aus der C ++ C sollte relativ einfach sein, aber Übersetzung von C idiomatischen C ++ würde so gut wie unmöglich sein, weil das so gut wie unmöglich sein würde automatisch ein prozedurales Programm in eine verwandeln OO-Programm.
Die Übersetzung von Java auf C wäre relativ einfach sein, obwohl das Speichermanagement Umgang mit unordentlich sein würde. Übersetzung von C in Java würde so gut wie unmöglich, wenn das C-Programm hat flippige Zeigerarithmetik oder Gießen zwischen ganzen Zahlen und verschiedenen Arten von Zeigern.
Die Übersetzung einer funktionalen Sprache zu einer imperativen Sprache wäre sehr einfach sein, wenn das Ergebnis wahrscheinlich ineffizient wäre, eine nicht-idiomatische. Die Übersetzung einer imperativen Sprache zu einer funktionalen Sprache ist wahrscheinlich über den Stand der Technik .... es sei denn Sie einen Dolmetscher für die imperative Sprache in der funktionalen Sprache umzusetzen.

Das bedeutet, dass einige Übersetzer sind unbedingt gehen, erfolgreicher zu sein als andere in Bezug auf:

Vollständigkeit und Richtigkeit der Übersetzung und
Lesbarkeit und Wartbarkeit des resultierenden Codes.

Dinge, die Sie nie tun, Teil I von Joel Spolsky

“.... Sie taten es, indem Sie den einzigen schlimmsten strategischen Fehler zu machen, dass jede Software-Unternehmen machen:

Sie beschlossen, den Code von Grund auf neu zu schreiben. "

habe ich eine Liste von MS Access-Konverter auf meiner Website . Ich habe nie etwas Gutes über jede von ihnen in allen Publikationen in den Access-Newsgroups hörte ich auf einer täglichen Basis zu lesen. Und ich habe viele Nachrichten auf täglicher Basis.

Beachten Sie auch, dass es eine erhebliche Menge an Funktionalität in Access, wie gebundenen Endlosformularen oder Unterformen, die mehr Arbeit zu reproduzieren, in anderen Systemen sind. Nicht unbedingt eine Menge Arbeit, aber mehr Arbeit. Und mehr Probleme, wenn es darum geht, Zeit, um die App zu verteilen und zu installieren.

Ich habe einen automatisierten Konverter von C # Visual Basic.NET verwendet. Es funktionierte ziemlich gut, außer für einige unnötige If True Anweisungen hinzufügen.

Ich habe auch Shed Haut konvertieren Python-to-C ++ zu verwenden versucht, aber es hat wegen seiner fehlenden Unterstützung nicht Arbeit für neuen Stil Division.

habe ich Werkzeuge zur Umwandlung eines VB6-Projektes in VB.Net verwendet - die Sie vielleicht einer von dieser Art der Sache der einfacheren Beispiele wären würden hoffen. Meine Erfahrung war, dass alles überprüft werden musste, bis ins kleinste Detail, und die Hälfte der Sachen fehlte / falsch.

Sicherlich würde ich eine Migration von Hand empfehlen, oder in Abhängigkeit von der Sprache, die Sie Targeting, würde ich ein komplett neu geschrieben betrachten, wenn diese Ihnen die Möglichkeit, erhebliche Verbesserungen an Ihre Code-Basis zu machen.

Martin

Ich habe nur frei und Grund bezahlt für Konverter versucht. Aber das Hauptproblem ist, dass es sehr, sehr schwierig ist, Vertrauen zu haben, dass die Umwandlung vollständig erfolgreich ist.

In der Regel werden sie am besten an Hand convert Codeabschnitt zu einer Zeit verwendet, in dem Sie jedes Stück Code überprüfen. Oft in meiner Erfahrung eine Rewrite statt einer Umwandlung stellt sich heraus, eine bessere Option sein.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow