モデル駆動ソフトウェアエンジニアリング（MDSE）とは正確には何ですか？

今日、私はinfoqでMDSEという頭字語に出会いましたが、その情報は非常に不明確で、説明には流行語がたくさんありました。

MDSEは、要件、アーキテクチャー、および設計情報が（情報「エントロピー」の観点から）最大限に整理され、保持される抽象化のレベルでソフトウェアエンジニアが作業できるようにすることを目的としています。（これを「設計作業成果物」と呼びます）。さらに、MDSEは、主に「設計作業成果物」の用語を設計の検証および検証する手段をエンジニアに提供する必要があります

そして、どうやら、誰もがそれをやっています：（再び記事から）

MDSE時代の幕開けです。今後5〜10年で、MDSEへの大幅なシフトが見られます。この期間の終わりまでに、ソフトウェアの60〜80％がモデルベースの手法を使用して設計されると私は信じています。

MDSEとは何か、流行語のない具体的な説明をお願いします。90年代のRational Roseのように、UMLボックスを描画してコードを生成していますか？

（その間、誰かがそれらの技法を使用して生成されたソフトウェアの例を持っている場合、私は本当に具体的な例を見たいです）。

「モデル駆動型ソフトウェアエンジニアリング（MDSE）」は、ソフトウェアの重要な部分をソフトウェアモデルから「すぐに」生成できるというソフトウェアツールメーカーのマーケティングの約束です。

あなたが参照している記事のインタビューパートナー 、Robert Howeはツールメーカーです（詳細については、http：//www.verum.com/を参照してください）

しかし、ツールメーカーの約束に反して、mdseはまだ主流になっていません。

HYBRISインターネットショップシステムは、「MDSE」の実施例である：あなたのようにXMLモデル・ファイルを維持する開発者に対しソフトウェア（「* -items.xml」）とcodegenerators /通訳が生成DB-MODELL / javaのコードのための持続性/のGUIそれのうち。追加の属性が必要な場合は、それをxml-modelに追加するだけで、ジェネレーター/インタープリターがそれを実行した後、その属性を使用してビジネスロジックを実装できます。

IMHOの「モデル駆動型」は、特に「デザイン」や「ソフトウェアエンジニアリング」（「開発」ではなく）などの流行語と組み合わせて使用​​する場合、非常に誇張されます。それはおそらく、「ソフトウェア設計」という誤解を持っている一部の人々が発明したものであり、建築家が家の青写真を描くように、UMLでほとんどのグラフィカルモデルを描画することによって行われ、「コーディング」は、家のレンガを置くようなものです。青写真に従って。（私がここでこれが間違っている理由をここで説明する必要がないことを願っています。別の意見がある場合は、私を投票する前に、まずジャックリーブスの「Code as Design」をお読みください。）

これは、「建築家」、「ビジネスアナリスト」、「デザイナー」、「ソフトウェアエンジニア」と名乗る人々にとって、5年間のコンピュータサイエンスを研究してきましたが、実際のプログラミング経験は半年しかありません（最大で） ）、現在はコーディングなしの「ソフトウェアの設計」を含むソフトウェア業界での仕事を探しています。これが、この「モデル駆動型」の流行語が非常に人気がある本当の理由だと思います。

誤解しないでください。ボイラープレートコードを手動で作成する必要性を減らすためのモデルとコードジェネレーターの大ファンです。たとえば、データベースなどの一部の制限された領域では、（データ）モデルはドメインの人々と通信するための優れた手段になる可能性があります。モデル間でコンポーネント間のデータフローをスケッチすることは、IMHOがソフトウェアシステムに構造を導入するための最も重要な手法の1つです（残念ながら、UMLの人々は、データフロー図を記法に含めることを忘れていました。代わりに、冗長で不要なものをたくさん追加しました）実際には誰も使用しません）。

しかし、私はこれを「モデル駆動型ソフトウェアエンジニアリング」ではなく「モデルサポートソフトウェア開発」と呼びます。これにより、モデリングはメインアクティビティそのものではなく、開発中のメインアクティビティのみをサポートすることが明確になります。

これは私に多くのファットモデル、細いコントローラーのコンセプトを思い出させます。
この概念の主なアイデアは、ビジネスロジックのできるだけ多くをモデルに入れ、コントローラーとビューを非常に単純化することです。
個人的には、これを使用する機会はありませんでしたが、これは非常に興味深いアイデアです。
驚いたことに、Google検索のトップリンク10件中8件がそれに反対しています。
ただし、モデルを単一のクラスではなく、複数の内部クラスのファサードと考える場合、ビジネスロジックをモデル内に保持することは完全に理にかなっています。