MDA/MDD/MDSD などのモデル駆動型アプローチを使用していますか?それは未来でしょうか？

https://stackoverflow.com/questions/21091

09-06-2019
|

質問

プログラミング言語には、その歴史の中でいくつかの (r) 進化段階がありました。モデル駆動型のアプローチが次の大きなものになると主張する人もいます。openArchitectureWare、AndroMDA、Sculptor/Fornax Platform などのツールがあります。驚くべき生産性の向上を約束します。ただし、最初は比較的簡単に始めることもできますが、予想外のことに挑戦したときにある時点で行き詰まったり、プロジェクトの開始方法を説明する十分な情報を見つけるのが非常に困難になったりすることを経験しました。考慮すべきことはたくさんあるかもしれません。

モデル駆動型の何かから何かを得るための重要な洞察は、モデルが必ずしも一連の素晴らしい画像やツリーモデル、UML である必要はなく、テキストによる説明 (例:ステートマシン、ビジネスルールなど）。

あなたはどう思いますか、そしてあなたの経験はあなたに何を伝えますか？モデル駆動開発 (あるいは、何と呼んでもいいでしょう) に未来はありますか?

アップデート： この話題にはあまり関心がないようです。モデル駆動型アプローチに関する (良いまたは悪い) 経験がある場合、またはモデル駆動型アプローチがまったく面白くないと思う理由があれば、教えてください。

解決

ツールがより洗練され、より多くの人が MDD の経験を積むまでには時間がかかると思います。現時点では、MDD から何かを得たい場合は、かなりの金額を投資する必要があるため、その用途は依然として限られています。

たとえば、openArchitectureWare を見ると、次のようになります。これは非常に堅牢で基本的なドキュメントは存在しますが、内部の仕組みに関するドキュメントが欠落しており、ドキュメント化されていないスケーラビリティに関する問題がまだ残っています。おそらく、Xtext と Xpand が書き直されると、この問題は改善されるでしょう。

しかし、これらの制限を無視して、oAW を使用すると生成自体は非常に簡単です。Xtend と Xpand では魔法のようにモデルをナビゲートでき、複数のワークフローを組み合わせてより大きなワークフローにすることで、非常に複雑なことも実行できます。必要に応じて Java に頼ることができるため、モデルでできることは非常に柔軟です。oAW で Xtext を使用して独自の DSL を作成することもすぐに完了しますが、メタモデル、パーサー、および非常に優れたエディターが基本的に無料で入手できます。また、モデルは基本的にどこからでも入手できます。データベースをメタモデルに変換できるコンポーネントと、それに対応するモデルを大きな労力なしで作成できます。

つまり、MDD は、ツールや経験が増えるにつれて、まだ構築され続けていると言えます。必要な専門知識があり、社内に導入する準備ができていれば、すでに問題なく使用できます。結局のところ、これは非常に良いことだと思います。なぜなら、大量のグルーコード (別名コピーペースト) が生成される可能性があり、生成されるべきだからです。私の意見では、MDD を使用してこれを行うことは、非常に優れた構造化された方法であり、再利用が容易になります。

他のヒント

免責事項:私はビジネスアプリケーションの開発者です。以下の見解は、確かにエンタープライズ IT の最前線での私の経験によって形作られています。ソフトウェア開発には他の領域があることは承知しています。特に産業システムや組み込みシステムの開発では、世界が違って見えるかもしれません。

MDSD は依然としてコード生成に結びつきすぎていると思います。

コード生成は、コードに多くのノイズが含まれている場合、またはコードの繰り返しが非常に多い場合にのみ役立ちます。言い換えれば、コードが本質的な複雑さに主に焦点を当てることができず、偶発的な複雑さによって汚染されている場合です。

私の意見では、現在のプラットフォームとフレームワークの傾向は、まさに偶発的な複雑さを排除し、アプリケーションコードが本質的な複雑さに集中できるようにすることです。

したがって、これらの新しいプラットフォーム/フレームワークは、MDSD 運動の帆から多くの風を奪います。

DSL (テキスト形式) は、本質的な複雑さのみに焦点を当てようとするもう 1 つのトレンドです。DSL はコード生成のソースとして使用できますが、主にコード生成に関連付けられているわけではありません。DSL (特に内部 DSL) では、基本的に、実行時に解釈/実行できるようにオープンします。[実行時コード生成はその中間にあります]。

したがって、DSL は MDSD と一緒によく言及されますが、実際には MDSD の代替手段であると私は考えています。そして、現在の誇大宣伝を考えると、彼らは MDSD 運動の勢いを奪うことにもなります。

コードから偶発的な複雑さを最終的に取り除くという目標に到達した場合 (これが架空であることは承知しています)、ビジネス上の問題のテキストモデルに到達したことになります。これ以上単純化することはできません。

優れたボックスや図は、さらなる単純化や抽象化レベルの向上を提供するものではありません。視覚化には良いかもしれませんが、それさえも疑問です。複雑さを理解するには、必ずしも絵が最適な表現であるとは限りません。

さらに、MDSD に関連するツールの現在の状態により、さらに別のレベルの偶発的な複雑さが追加されます (次のように考えてください)。同期、差分/マージ、リファクタリング ...) これは基本的に単純化という最終目標を無効にします。

私の理論を説明するために、次の ActiveRecord モデルを見てください。

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

これ以上単純化できないと思います。また、ボックスや線を使用したグラフィック表現は単純化にはならず、利便性も向上しません (レイアウト、リファクタリング、検索、差分などを考えてください)。

モデル駆動開発は非常に長い間存在しています。

初期の試みで最も成功したのは、「James Martins Integrated Engineering Facility」で、現在も存在しており、非常にダサい「Coolgen」というブランド名で CA によって販売されています。

では、これほど優れているのになぜ世界を席巻しなかったのでしょうか?

これらのツールは、単純なことを簡単にするのには優れていますが、難しいことをさらに簡単にするわけではなく、多くの場合、難しいことを難しくしてしまいます。

Java/C/SQL などで正しいことをコーディングするのが簡単だとわかっていても、グラフィック 4GL モデリング言語に「正しいことをする」ように説得するのに何時間も費やすことができます。

おそらく決定的な答えはないと思います。したがって、この質問には「関心」が欠けています。

しかし、私は個人的に MDA に関してさまざまな経験をしてきました。良い経験ができたのは、優れたツールを使用したときだけです - 私は TogetherSoft を使用していました (最終的にはどういうわけか borland に行き着いたと思います) - 彼らは、「コード生成」ではなく実際にコードを編集する編集を導入した最初の 1 つでした。モデルを直接編集できます (コードまたはモデルを編集できるため、すべてが 1 つでした)。また、リファクタリングも行われていました (smalltalk 環境以降、リファクタリングが行われたのを覚えているのはこれが初めてでした)。

それ以来、少なくとも主流においては、MDA の人気がこれ以上高まっているのを私は見たことがありません。そのため、人気という観点から見ると、それは未来ではないようです (つまり、そのような答えになります)。

もちろん、人気がすべてではありませんし、人気が戻ってくる傾向はありますが、今のところ、MDA+ツールは多くの人に「ウィザードベースのコード生成」ツールとして見られていると思います（それが実際に何であるかは関係ありません）。それが本格的に始まるには、しばらく時間がかかるか、おそらく永遠にならないと思います。

MDD の問題の 1 つは、MDD はより高い抽象レベルで動作するため、より高い抽象レベルにも対応できる開発者が必要になることです。そのため、そのような方法論を理解して使用できる開発者の数が大幅に減少します。

モデル駆動型アプローチに関する (良いまたは悪い) 経験がある場合、またはモデル駆動型アプローチがまったく面白くないと思う理由があれば、教えてください。

ここの寄稿者は「特効薬はない」派だと思います（私も間違いありません）。MDA が機能した場合 (「大幅な節約」に相当)、私たちはそれを知っているでしょう、それは確かです。質問は：システムを管理しやすい状態に保ちながら、どこまで「メタ」を実現できるでしょうか?これが UML 2.0 の転換点となり、より正式なメタメタモデルが導入されました。これまでのところ、UML 2.0 のモデル化機能が実際に使用されているのを見たことがありません (ただし、私の世界はかなり限られています)。さらに、モデル駆動型アプローチには 2 つの選択肢しかありません。コードを生成するか、モデルを利用するランタイムを使用します。究極の制約のないコードジェネレーターは「ヒューマン」と呼ばれますが、究極のランタイムは 4GL にあります (現在の数字は何ですか?)。おそらくそれが熱意の欠如を説明するでしょう。

私たち itemis (www.itemis.com) では、モデル駆動型ソフトウェア開発を多用しています。これまでのところ、私たちは本当に良い経験をさせていただきました。Shure は特効薬ではありませんが、ソフトウェアの品質を向上させるのに役立ち、顧客にとってより多くの利用が可能になります。

モデル駆動開発は、使用するモデルが、生成されるはずのコードを記述するのと同じくらい柔軟である場合に限り、未来になります。現在それほどうまくいっていない理由は、テキストベースのプログラミング言語が何十年も行ってきたのと同じ「ラウンドトリップ」を行うのが難しいからだと思います。

テキストベースのプログラミング言語では、数行のコードを変更するだけでモデルを変更できます。グラフィカルプログラミング言語 (UML などの MDD ダイアグラムとも呼ばれる) を使用する場合、そのモデルをテキストベースの相当物 (そもそもすでに表現的に効率的でした) にまで翻訳する方法を見つける必要があります。とても、とても乱雑になる。

私の意見では、MDD が役に立つ唯一の方法は、テキストベースの対応物と同じくらい表現力と柔軟性を備えたものをゼロから構築した場合です。本質的に階層化された抽象化 (プログラミング言語など) を使用してボトムアップで構築されるツールに、既存のトップダウングラフィカル設計言語 (UML など) を使用しようとすると、大きなインピーダンスの不一致が生じます。私にはそれを正確に特定することはできませんが、MDD を人々が主張しているのと同じくらい便利にするためには、MDD にはまだ何かが欠けています...

返信が大変遅くなりましたが、残念ながら Rhapsody に取って代わられつつある Rose RT に代わる MDD ツールを現在探しています。私たちはリアルタイムの組み込みおよび分散 C++ スペースにいて、MDD から多くのことを得ています。私たちはより良いツールに移行し、非常に大規模な会社でそのツールをより広く使用できるようにしようとしています。ここで述べたいくつかの優れた理由により、これは困難な戦いです。

コンパイラがアセンブリの上にあるのと同じように、MDD はコンパイラの 1 つ上のレベルであると考えています。私は、アーキテクトとしてアプリケーションフレームワークを開発し、そのフレームワークやメッセージパッシングに使用しているミドルウェアを使用するためにコード生成 (スクリプト) を大幅に編集できるツールが必要です。開発者には、アプリケーションやライブラリの生成に必要なすべてのコードを含む完全な UML クラスと状態図を作成してもらいたいと考えています。

コードを使えば何でもできるのは事実ですが、MDD の利点を大まかにまとめると次のようになります。

数人がアプリケーションフレームワーク、ミドルウェアアダプターを作成し、それを MDD ツールに接着します。彼らは「家」を建てます。
完全なクラス、図、ステートマシン遷移コードを作成する人もいます。これにより、ユーザーは「家」ではなくアプリケーションに集中できるようになります。
図はコードなので、人々が奇妙なデザインをしているかどうかは簡単にわかります。私たちには専門の開発者が全員いるわけではないので、このように若手を育てるのは素晴らしいことです。
ほとんどの場合、モバイルロボットプロジェクトなどで発生する可能性のある厄介なステートマシンコードです。私が理解し、批判し、一緒に取り組むことができる状態図を作成してくれる人が欲しいです。
操作や属性を継承チェーンや他のクラスにドラッグするなど、優れたリファクタリングも可能です。ファイルを掘り下げるよりもその方が好きです。

これを入力していても、コードですべてを実行できることに気づきました。私は、均一性を強化し、設計を文書化し、リファクタリングを少し容易にするために、コードの上に薄いツールを置くのが好きです。

私が遭遇した主な問題は、適切な答えがありませんが、そのようなモデルには機能とファイル形式の標準セットが存在しないことです。人々は、ベンダーがいなくなって行き詰まるのではないかと心配しています。(Rose RT では基本的にそのようなことが起こりました。) ソースコードではそのようなことはありません。ただし、最新バージョンのツールと最後に生成したコースコードは存在します:)。私は利益がリスクを上回ることに賭けたいと思っています。

私はまだこのようなツールを見つけていませんが、いくつかのベンダーに私の意見を聞いてもらい、おそらくこれを実現するためにお金を受け取ってもらえるように努めています。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow