「言語コンバーター」を使用した経験はありますか?

StackOverflow https://stackoverflow.com/questions/3027705

質問

ある言語から別の言語へのコンバーターについて言及した記事をいくつか読みました。

私はそのようなツールの使用には少し懐疑的です。Visual Basic から Java、または vs コンバータについて知っているか、経験のある人はいますか?ほんの一例を取り上げます

http://www.tvobjects.com/products/products.html, 、その面では「世界のリーダー」かそこらであると主張していますが、これを読んだ場合は次のようになります。

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

そこで著者は次のように述べています。

「MySQL ユーザーの一致した意見は、MS Access 用の自動変換ツールは機能しないということです。たとえば、既存の Access アプリケーションを Java に変換するツールでは、80% が完成したソリューションが得られることがよくありますが、作業の最後の 20% を完了するには、最初から開始するよりも時間がかかります。」

最初の 80% の機能を実装するには 80% の時間が必要で、残りの 20% にはさらに 80% の時間が必要であることはわかっています。

では、そのようなツールを試して価値があると感じた人はいるでしょうか?

役に立ちましたか？

解決

：ほとんど常に私のように読んで答える人々がここで重要な質問が不足していることを、より広いStackOverflowの人口を誘致タグを持つMS-ACCESSの質問、の場合と同様に、

これは、私には思えます

に成功し、他のプラットフォームにAccessアプリケーションを変換することができますが任意のツールはありますか？

と答えている。

絶対にありません。

その理由は、UIオブジェクトのための同様のモデルを使用するのと同じ家族の中のツールは、（例えば、VB6は）あなたはVB6としないようにアクセス連続サブフォームを変換しない方法（アクセスはデフォルトで提供することを非常に多くのものを欠いていることだけです失う機能？）。そして、他のプラットフォームでもVB6とアクセスと同じコアモデルを共有していないので、これらはクリアしても、より多くのハードルがあります。

引用MySQLの記事は非常に興味深いですが、それは実際に開発ツールを使用しているが付属して問題の対incompetently、先進のアプリケーションが付属して問題を混乱させる。不正なデータスキーマは、Accessに固有ではありません - それは[ほとんど]初心者のデータベース・ユーザーに固有です。しかし、記事がアクセスするには、この問題を帰するようです。

完全に

とはるかに問題に対する最も簡単な方法で、スキーマを修正MySQLへそれを大型化し、アクセスフロントエンドを維持する可能性を見渡す。

これはまさに私がアクセスを得ることはありません人々から期待するものである - 彼らも、アクセスが確保可能な、大容量サーバーデータベースエンジンのフロントエンドとして問題に優れたソリューションであることを考慮していません。

その記事であっても、実際にアクセスアプリの変換を考慮しないと、そのための良い理由があります。 、または盲目的フロントエンド構造を変換 - （低能！彼らはすべてのアプリを変換しない場合には）私は請求がAccessアプリケーション（どんなプラットフォームへの）変換は何もなく、データのいずれかを変換することを見てきたことをすべてのツール、1：UIの間に1対応は、Accessアプリケーションで、ターゲットアプリケーション内のオブジェクト

。

この仕事をしません。

アクセスのアプリケーションの設計は、それ自体に固有のものであり、他のプラットフォームは、同じ機能セットをサポートしていません。このように、変換されたアプリケーションでは、元の機能のための作業を代わりにアクセス機能の翻訳が存在しなければなりません。これは私の意見では、自動化された方法で行うことができるものではありません。

Webブラウザでの展開のためのAccessアプリケーションを変換する考えたときに、第二に、アプリケーション全体のモデルはステートフルからステートレスに、すなわち、異なっており、それだけでサポートされていないいくつかのアクセス機能の問題ではありませんので、しかし、のUIは、データと対話するオブジェクトがどのように完全に別の基本的なモデル。おそらく、100％結合していないアクセスアプリは、比較的容易に、ブラウザベースの実装に変換することができますが、どのように多くの人々のがあるのですか？それは（それが結合していないことができないので）全くサブフォームを使用しないアクセスアプリ、およびアプリを意味するであろうその用途豊富なイベントモデルからのイベントのほんの一握り（ほとんど唯一のバウンドフォーム/コントロールとその作品の）。要するに、100％結合していないアクセスアプリは1になり、その全体のAccess開発パラダイムと戦います。アクセスの全体のポイントは、バインドされたフォーム/コントロールであるとして、彼らは本当にAccessで結合していないアプリを構築したいと考えて誰もが、最初の場所でAccessを使用すべきではありません！あなたはそれを排除する場合は、他の開発プラットフォームを超えるアクセスのRADの利点の大部分を捨て、そして（巨大なコードの複雑さ以外の）お返しにほとんど何も得られないました。

Accessアプリケーションから-地上アップアプリケーションUIとワークフローの再設計が必要ですと同じタスクを達成したWebブラウザでの展開のためのアプリケーションを構築するには、

。成功したAccessアプリケーションモデルが成功したウェブアプリケーションモデルと正反対であるため、動作します何の変換や翻訳はありません。

もちろん

は、Access 2010とSharePointのSerと、この変更のすべてアクセスサービスで2010年版その場合、あなたは（Webオブジェクトを使用して）Accessでアプリケーションを構築することができ、ユーザーがブラウザでそれを実行するためにSharepointの上で展開します。結果は、機能（視覚、90％）を100％と同等であり、すべてのブラウザ（ここでないIE固有の依存関係）上で実行されます。

だから、今年6月に開始し、ブラウザでの展開のためのAccessアプリケーションを変換する最も安い方法は非常によく、A2010にアップグレードするすべてのWebオブジェクトを使用するように設計を変換して、SharePointと展開することであってもよいです。アクセスWebオブジェクトは、クライアントオブジェクトと比較して機能の限定セット（無VBAを持っているとしてそれは、些細なプロジェクトではありません、例えば、あなたがはるかに強力で安全な古いものよりも新しいマクロを、学ばなければならないので、そのためには、それが）アクセスの遺産マクロに精通している人のために見えるかもしれませんがひどい苦難はありませんが、それはおそらくウェブ上で展開するための本格的な再設計よりもはるかに少ない作業となります。

他の事は（ウェブ・オブジェクト・バージョンは、元のクライアントのバージョンと同じである限りにおいて）、それはウェブのように、Accessクライアントで同じになるように、それは、任意のエンドユーザーのための再訓練を必要としないということですブラウザます。

だから、要するに、私は変換が努力の価値キメラであり、ほとんど常にではないと思います。私は（私はそのソースから他のコメントと多くの問題を持っていても）実際には、引用した感情に同意しています。しかし、私はまた、変換のための欲求はしばしば見当違いと上から下へのアクセスアプリの卸売交換を必要としない安く、より簡単に、より良い解決策に出てミスしていることを警告するだろう。彼らは同様Accessアプリケーションを交換する必要が思考へのデータストアの混乱の人々のようにジェット/ ACEと非常にしばしば不満。そしてそれは多くのユーザーが開発したアクセスのアプリはひどい、unmaintainable妥協で満たされており、チューインガムや救済ワイヤーと一緒に保持されていることは事実です。しかし、ひどく設計されたAccessアプリケーションは、データスキーマのバックエンドのアップサイジングandrevisionと一緒に改善することができる - それが破棄されている必要はありません。

。 それのを意味しないことは容易の - それは非常に頻繁ではありません。私は、クライアントのすべての時間を教えてくれたように、古いものを改造するよりも、新しい家を建てるために、通常は簡単です。彼らは我々が失いたくないというかけがえのない特性を持っているので、しかし、我々は古い家を改造理由の一つです。これは、Accessアプリが暗黙のうちに新しいアプリ（旧ネットスケープの難問、ペースジョエル・スポルスキ）に失われてはならないビジネスルールとワークフローのモデリングの多くが含まれていることを非常によくあるケースです。これらのことは、別のプラットフォームに移植しようと外、開発者には自明ではないかもしれないが、アプリが古いアプリと比較してペニーでオフになっていた結果を生成する場合、エンドユーザーのために、彼らは不幸になるだろう（そしておそらくそれはどちらか、信頼性の高い結果を生産していないアプリの他の側面を意味するかもしれないので）、である必要があります。

とにかく、私は長すぎるためにrambledましたが、私の意見は、その変換が最も些細なアプリケーション（または変換するように設計されたもののために、例えば、100％結合していないアクセスアプリ）を除いて動作することはありません。私はreplacmentのの代わりに、改正のためのすべてをしています。

しかし、当然のことながら、アクセスのアプリを固定、すなわち、私は私の生活を作る方法です。

他のヒント

試してみましたか？いいえ、実際には (複数の) 言語コンバーターが構築されています。

これは私 (および私の同僚) がこのために構築したものです。 B2 スピリット ステルスボンバー レガシー言語 JOVIAL でコーディングされたミッション ソフトウェアを、100% 自動変換で保守可能な C コードに変換します。要件の 1 つは、実際のソース コードを見ることは許可されていないということでした。冗談抜き。

あなたが正しいです：中程度の高いコンバージョン率 (例: 70 ～ 80%) しか得られない場合でも、実際に変換を完了できるとしても、変換を完了するまでの労力は依然として非常に重要です。私たちは 95% 以上を目標にしており、B2 の場合と同様に、もっと頑張れと言われたときはより良い結果を出します。人々が中高レートのコンバーターを受け入れる唯一の理由は、より良いコンバーターが見つからない（または資金を提供しない！）からであり、開始することに固執しているからです。 今, 、そして、この方法で変換するのは苦痛かもしれませんが（通常、どの程度かわかりません）、実際には最初から再構築するよりも苦痛が少ないという事実を受け入れます。(私はたまたまこの評価に同意します:一般に、大規模なシステムを最初から再コーディングしようとするプロジェクトは通常失敗し、中程度の変換率のツールを使用した変換の失敗率はそれほど高くありません)。

世の中には、テキスト文字列に対して正規表現を実行する山ほどの PERL コードを組み合わせたものや、コンパイル単位のステートメントごとに基本的に 1 対 1 でコードを生成する YACC ベースのパーサーなど、悪質な変換ツールがたくさんあります。前者は、空から改宗を与えられた人々によって建てられました。後者は、多くの場合、まともなコンパイラの経験を持たない善意のエンジニアによって構築されます。

非常に悪い例については、COBOL 移行に関するこの SO の質問に対する私の回答を参照してください。 従来の Cobol/PL1 を Java に移行した経験, 、これはまさに直接的なステートメントの翻訳です...「JOBOL」という言葉の由来となったものを生み出しました。

このような高精度の変換率を実現するには、高品質のパーサーと、セマンティクスを保持し、ターゲット言語のプロパティと特殊なケースに合わせて最適化する高品質の翻訳ルールを構築する手段が必要です。本質的には、構成可能なコンパイラ テクノロジに相当するものが必要です。私見ですが、私たちが成功する理由は、 DMS ソフトウェア リエンジニアリング ツールキット, 、この仕事を行うために設計されました。(私は建築家です。私の SO アイコン/プロフィールをチェックしてください)。

慎重にテストを行うことも役立ちます。

DMS は、対象の言語に対してコンパイラのようなフロント エンドを備え、AST、シンボル テーブル、制御およびデータ フロー、呼び出しグラフを構築する機能を備えているため、コンパイラがコードについて何を知っているかを「知っています」。これは、コンパイラ コミュニティが過去半世紀をかけて発明したコンパイラ テクノロジの多くを使用しています。 それは翻訳に役立つことが証明されているからです。

DMS は知っています もっと ほとんどのコンパイラーが知っている以上に、アプリケーション全体を一度に読み取り、分析、変換できるためです。ほとんどのコンパイラは単一のコンパイル単位に固執します。したがって、現在のステートメントだけではなくアプリケーション全体に依存する変換ルールをコーディングできます。翻訳を改善するために、問題またはアプリケーション固有の知識を追加することがよくあります。これは、言語の特殊な機能やライブラリの呼び出しを変換するときによく発生します。この場合、ライブラリの呼び出しを特別なイディオムとして認識し、ターゲット ライブラリと言語構造の構成の呼び出しに変換する必要があります。

この機能は、トランスレーター (JOVIAL トランスレーターなど) またはドメイン固有のコード ジェネレーターを構築するために使用されます。

多くの場合、プログラム分析ツール (無効なコード、重複コード、スタイルが崩れたコード、メトリクス、アーキテクチャ抽出など) や一括変更ツール (プラットフォーム [言語ではありません] 移行、データ層の挿入、API の置き換えなど)

言語間変換の成功または失敗に影響を与えるいくつかの問題は、言語の相対的な意味論の豊富さとその意味論モデルです。

  • C++ から C への変換は比較的簡単ですが、C から C への変換は 慣用的な C++ では、手続き型プログラムを OO プログラムに自動的に変換することはほぼ不可能であるため、ほぼ不可能です。

  • Java から C への変換は比較的簡単ですが、ストレージ管理の処理は面倒になります。C プログラムがファンキーなポインター演算を行ったり、整数とさまざまな種類のポインターの間でキャストを行ったりする場合、C を Java に変換することはほぼ不可能になります。

  • 関数型言語を命令型言語に変換するのは非常に簡単ですが、その結果は非効率的で非慣用的なものになる可能性があります。命令型言語から関数型言語への翻訳は、おそらく最先端技術を超えています。ただし、関数型言語で命令型言語のインタプリタを実装する場合は除きます。

これが意味するのは、一部の翻訳者は 必然的に 次の点で他の人よりも成功するでしょう。

  • 翻訳の完全性と正確性、および
  • 結果として得られるコードの可読性と保守性。
あなたは、おそらくこの種のものの単純な例の一つだろう望んでいるだろうどの -

私はVB.NetにVB6のプロジェクトを変換するためのツールを使用しました。私の経験では、そのすべてが細部に、確認されなければならなかった、と半分のものが欠けていた/間違っていました。

確かに私は手で移行をお勧めします、またはこれはあなたのコードベースに大きな改善を行うためにチャンスを与える場合は言語に応じて、あなたがしている標的化、私は完全な書き直しを検討する。

マーティン

私は自由とコンバータのために支払った基本を試してみました。しかし、主な問題は、変換が完全に成功したことを自信を持っていることは非常に非常に困難であるということです。

は通常、彼らは最高のあなたは、コードの各部分を見直す時、手元のコンバートコードセクションに使用されています。多くの場合、私の経験では代わりに変換の書き換えは、より良い選択肢であることが判明します。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top