10

モデル駆動型アーキテクチャとは、解決する必要がある問題を表現するモデルを作成し、実装テクノロジをまったく (または少なくともほとんど) 使用しない方法で作成し、1 つまたは複数の特定のプラットフォーム用の実装を生成するという考え方です。主張は、より高いレベルの抽象化で作業することは、はるかに強力で生産的であるということです. さらに、モデルはテクノロジーよりも長生きします (そのため、最初の言語/プラットフォームが時代遅れになっても、次世代のソリューションに使用できるものがあります)。主張されているもう 1 つの重要な利点は、ボイラープレートと「単調な作業」の多くを生成できることです。コンピューターが状況のセマンティクスを理解すると、さらに役立つ可能性があります。

このアプローチは生産性が 10 倍高く、10 年後にはこの方法でソフトウェアを構築していると主張する人もいます。

ただし、これはあくまで理論上の話です。ゴムが路面に出くわしたときの結果はどうなるのだろうか。また、MDA の「公式」バージョンはOMGのもので、非常に重いようです。これはUMLに大きく基づいており、誰に尋ねるかによって良いか悪いかを判断できます（私は「悪い」方に傾いています）。

しかし、これらの懸念にもかかわらず、より高いレベルの抽象化で作業し、問題と解決策のセマンティクスを理解するようにコンピューターに「教える」という考えに異議を唱えることは困難です。単純に真実を表現する一連の ER モデルを想像してください。次に、それらを使用してソリューションの重要な部分を生成することを想像してください。最初は 1 つのテクノロジ セットで、次に別のテクノロジ セットで再び生成されます。

ですから、現在 MDA を実際に行っている (「公式」であろうとなかろうと) 人々の意見を聞きたいと思います。どのようなツールを使用していますか? それはどのように機能していますか？理論上の約束をどの程度達成できましたか? 真の 10 倍の有効性の向上が見られますか?

4

6 に答える 6

6

この質問への回答の欠如はやや不吉です...多分私はDijkstraにそれを解決させます。

...コンピュータは、科学技術の進歩と健全性への信頼が事実上無制限であった10年に登場したため、その当初の目的に照らして、人類の科学的努力は、たとえば過去5世紀にわたって行われたことを思い出すのが賢明かもしれません。壮大な失敗でした。

ご存知のように、最初のそして最も重要な目的は、それを飲んだ人に永遠の青春を与えるエリクサーの開発でした。しかし、永遠の貧困にはあまり意味がないため、科学の世界はすぐに2番目のプロジェクトに着手しました。賢者の石は、必要なだけの金を作ることができます。

..。

ソフトウェアの危機を太陽の雪のように溶かす理想的なプログラミング言語と理想的なマンマシンインターフェースの探求には、ElixirとStoneの検索のすべての特徴がありました。この検索は、奇跡の働きがコンピューターに期待できるものが最も少ないという事実から、そして次にエリクサーとストーンを常に求めてきた社会からの財政的および政治的支援から、2つの側面から強力な支持を受けています。そもそも。

ストーンのクエストとエリクサーのクエストの2つの主要なストリームを区別できます。

ストーンの探求は、私たちの「プログラミングツール」が弱すぎるという仮定に基づいています。一例は、現在のプログラミング言語には必要な「機能」が欠けているという信念です。PL / Iは、生産された石の中で最も壮観なものの1つでした。Datamation、1968の広告を今でも覚えています。この広告では、笑顔のSusie Mayerが、PL/Iに切り替えることでプログラミングの問題をすべて解決したことをフルカラーで発表しています。数年後、貧しいスージー・メイヤーがもはや微笑むことはありませんでした。言うまでもなく、探求は続き、やがて次の石がエイダの形で生産されました（知覚的にはPL / IIと呼ばれる鉄のカーテンの後ろ）。

..。

「プログラミングツール」の形をした別の一連の石は、「ソフトウェアエンジニアリング」の旗印の下で生産されます。これは、時が経つにつれて、現在その憲章として受け入れられている範囲で、知的規律を管理規律に置き換えることを目指してきました。 「できない場合のプログラミング方法」

于 2009-04-01T01:11:57.570 に答える
4

モデル駆動型ソフトウェア開発はまだニッチな分野ですが、ケース スタディが公開されており、手作業でコーディングした方法よりも成功していることを示す他の文献が増えています。

OMG の MDA は 1 つのアプローチに過ぎず、ドメイン固有言語 (モデリングに UML を使用しない) を使用して成功を収めている人もいます。

重要なのは、モデルからコードを生成し、ジェネレーターが必要なものを生成しない場合はジェネレーターを更新することです。コードを変更するのではありません。これを行うのに役立つ専門ツールは何年も前から存在していますが、このアプローチへの関心は、Microsoft がこの分野に参入し、Eclipse の世界の openArchitectureWare などのオープンソース プロジェクトを通じて、過去 5 年ほどで大きくなりました。

私はいくつかのサイトを運営しています: www.modeldrivensoftware.netとwww.codegeneration.netでは、これらのトピックに関するディスカッション、インタビュー、記事、およびツール オプションを入手できます。

于 2009-05-04T12:48:20.990 に答える
4

私は 1999 年以来、モデル駆動型ソフトウェア開発分野で独自の研究を行っています。最終的に 2006 年に汎用モデリング手法を開発し、それを ABSE (Atom-Based Software Engineering) と名付けました。

したがって、ABSE は次の 2 つの基本的な側面に基づいています。

  • プログラミングは問題の分解に関するものです
  • すべてをツリーで表すことができます

いくつかの ABSE 機能:

  • 従来のファイル指向の方法から、コンポーネントベースの開発、アスペクト指向プログラミング、ドメイン固有のモデリング、ソフトウェア製品ライン、ソフトウェア ファクトリまで、他のすべての形式のソフトウェア エンジニアリングをサポートできます。

  • エンタープライズ ソフトウェア、組み込み、ゲーム、アビオニクス、インターネットなど、実際にはあらゆるドメインに適用できる汎用性があります。

  • 効果的に使用するためにロケット科学者である必要はありません。ABSE は「単なる開発者」がアクセスできます。oAW/MDA/XMI/GMF などのツール チェーンに見られるような複雑さはありません。

  • そのメタメタモデルは、モデルからの 100% コード生成をサポートするように設計されています。往復不要。カスタム/生成されたコードの組み合わせは、メタモデルによって直接サポートされます。

  • モデルは同時に操作できます。ワークフローとバージョン管理を適用できます (ツールのサポートが必要)。

理想郷のように聞こえるかもしれませんが、実は私は研究段階を離れ、上記のすべてを実践するIDEの実装段階に入っています。数週間後（4月末頃）に基本的なプロトタイプが完成すると思います。IDE (AtomWeaver という名前) は ABSE を通じて構築されているため、AtomWeaver は ABSE 方法論の最初の概念実証となります。

したがって、これは MDA ではありませんが (ありがたいことに!)、少なくとも非常に扱いやすいアプローチです。ABSE の発明者として、当然のことながら興奮していますが、モデル駆動型ソフトウェア開発が 2009 年に勢いを増すことは間違いありません。

乞うご期待...

于 2009-04-02T09:13:19.807 に答える
0

一度試してみました。プロジェクトのおよそ半分くらいで、自分のモデルがどうしようもなくコードから古くなっていることに気付きました。また、非常に複雑であるため、モデルを最新の状態に保つことは非常に困難であり、速度が低下していることに気付きました。

問題は、ソフトウェアがエッジケースでいっぱいだということです。モデルは全体像を把握するのに優れていますが、実際に実装をコーディングし始めると、これらのエッジ ケースをすべて見つけ続けると、やがてモデルが細かすぎることに気づき、モデルを維持するか取得するかの選択をしなければなりません。いくつかのコードが書かれています。ボイラープレート生成は起動時の利点かもしれませんが、その後すぐに利点がなくなり、生産性が大幅に低下することがわかりました。モデルは最終的にそのプロジェクトから姿を消しました。

于 2009-04-01T02:31:37.363 に答える