なぜ私たち全員がまだモデル駆動型開発をしていないのですか？[閉まっている]

私はモデル駆動開発を真に信じており、生産性、品質、予測可能性を高める可能性があると思います。MetaEditを見ると、結果は驚くべきものです。オランダのメンディックスは非常に急速に成長しており、素晴らしい結果をもたらしています。

私は多くの問題があることも知っています

• ジェネレータ、テンプレート、フレームワークのバージョン管理
• モデル駆動型開発に適していないプロジェクト（繰り返しが不十分）
• より高いリスク（最初のプロジェクトが失敗した場合、従来の開発で得られるよりも結果が少なくなります）
• 等

しかし、それでもこれらの問題は解決可能であるように思われ、必要な労力を上回る利点が得られるはずです。

質問：モデル駆動型開発を考慮しない最大の問題は何ですか？

これらの回答は、自分自身の理解だけでなく、執筆予定の一連の内部記事のソースとしても使用できます。

黄金のハンマーはありません。あるドメインでうまく機能するものは、別のドメインではほとんど役に立たない。ソフトウェア開発には固有の複雑さがあり、魔法のツールはそれを削除しません。

また、コードの生成は、言語自体（またはフレームワーク）がMDDを比較的無意味にする強力な抽象化を可能にするほど高レベルでない場合にのみ有用であると主張するかもしれません。

興味深い質問です！私はファンではありませんが、あなたが提起した問題のいくつかに適合するプロジェクトでモデル駆動型開発を数回使用しようとしました。

これが私の理由リストです。

• 学習曲線-モデリングツールは急速に進化しているため、ツールを深く理解しているエンジニアを見つけるのは困難です。私はまだあなたがあなたのモデリングツールと同じくらい良いだけだと思います。確かに、以下の問題の多くはこの1つの問題にまでさかのぼることができます。ツールがあまりにも制限的だと思うときはいつでも、それを十分に知らない可能性があります。
• あまりにも構造化されている-個人的には、モデリングツールが構造化されすぎて、説明するのに必要なものすべてを記述できないという状況に陥りました。そして、モデルの一部をツールの外部に描画するように切り替えた後、情報を見つけるためにツールの外部に人々が漂い始めると、物事はすぐに崩壊します。
• ツールのチューニングにかかる​​コスト-コードを自動生成しようとするたびに、ツールが正しいと思うものを見つけたら、手動でコードをやり直すことになりました。何度か回った後、この問題は減少することはわかっていますが、それは最初の数回のラウンドを生き延びなければならないことを意味します。私は一般的に、モグラを叩く-モデルを作成->コードを生成->コードを修正->モデルを更新->モデルを修正、すすぎ、繰り返しを実行していると感じました。
• モデル構成管理-モデルはプロジェクトの大部分を記述するため、あるレベルでは、モデルCMはビルドされたコードよりも横断的です。モデリングファイルのコンパートメント化はそれ自体が芸術です。間違っていると、開発者のデッドロックや、人々がコードをあきらめてコードが古くなると、モデルが古くなってしまいます。
• 市場投入までの時間-稼働中のソフトウェアの必要性が急務だったときに明確な問題が発生しました。プロジェクトとチームが十分に小さい場合、コーディングとテストに時間を費やすことができるのに、モデリングツールで時間を無駄にする理由はありません。すべてのプロジェクトがそのような投資を必要とするほど大きいわけではありません。
• 失敗のコスト-プロジェクトがモデリングツールから逃げるのを見たとき、失敗のコストが高いためです-ツールを使用するには、すべての開発者が関与する必要があります。これは、トレーニングと実践的な学習への大きな投資であり、誰かがモデルを不適切にセットアップした場合、非常にコストのかかる間違いです。私の経験では、モデルを正しくするために2つまたは3つのリリースが必要な場合があります。そのため、多くのプロジェクトは、メリットを実現するのに十分なほどモデリングのミスを乗り切ることができません。

すでに引用されていますが、No Silver Bulletはこの点にかなりうまく対処しています。

ソフトウェアエンティティの本質は、データセット、データ項目間の関係、アルゴリズム、関数の呼び出しなど、連動する概念の構造です。このエッセンスは抽象的であり、そのような概念的な構成は多くの異なる表現の下で同じです。それにもかかわらず、それは非常に正確で豊かに詳細です。

ソフトウェアを構築する上で難しいのは、この概念的な構成要素の仕様、設計、およびテストであり、それを表現し、表現の忠実度をテストする労力ではないと考えています。確かに、構文エラーは引き続き発生します。しかし、それらはほとんどのシステムの概念的なエラーと比較してあいまいです。

これが当てはまる場合、ソフトウェアの構築は常に困難です。本質的に特効薬はありません。

後に、ブルックスは「自動プログラミング」の概念について次のことを指摘しています。

ほぼ40年間、人々は「自動プログラミング」、または問題仕様の記述から問題を解決するためのプログラムの生成について予想し、書いてきました。今日、一部の人々は、このテクノロジーが次のブレークスルーを提供すると期待しているように書いています。

パルナスは、この用語がセマンティックコンテンツではなくグラマーに使用されることを意味し、「要するに、自動プログラミングは、現在プログラマーが利用できるよりも高いレベルの言語でプログラミングするためのe曲表現である」と主張する。

彼は本質的に、ほとんどの場合、仕様を提示する必要があるのは問題ではなく解決方法であると主張しています。

基本的に、MDDは、以前に利用可能だったよりも高レベルの言語でプログラミングするための別のe曲表現であると主張します。

それは、高水準言語でのプログラミングが役に立たないと言っているわけではありません-実際、それはしばしばできます。しかし、本質の問題は同じまま：どんなに偉大Aツールまたはどのように偉大なあなたは一日の終わりに、使用している言語あなたはすべての問題を通して考え、問題を解決する必要があります。ツールやプロセスができる最善の方法は、「ファズ」を削除することです。これにより、Brooksが述べたように、「この概念構成の仕様、設計、およびテスト」という重要な問題に集中できます。

すべてのプログラミングがオブジェクト指向ではないため、すべてのMDDツールが期待しているようです。UML自体は、オブジェクトの推定に基づいています。シーケンス図を使用して関数をモデル化することはできますが、何度も不器用です。

私のようなプログラマーがMDDよりもTDDからより多くの進歩と結果を得ているからです。

モデリング！=プログラミングだからです。

費用/便益は費用面では高すぎ、便益面では十分ではなかったからです。これはおそらく私が最後にMDDを調べてから変更されたと思われます。当時は、MDDに適度に対応できるツールに対して1人あたり6,000ドル以上を支払う必要がありました。

コードを生成する関数を十分に記述しているモデルは、モデルとしてはもはや有用ではないためです。

私のように、高レベルのモデルのみを使用し、コードで詳細を作成するプログラマーがいるからです。コードでは、モデリングソフトウェアで見ているものとは異なって見えます。

これらは、私が個人的にMDDを行わない理由の一部です。私はそれに触れましたが、何も私を改宗者にすることができませんでした。おそらく私はあまりにも古い学校です。おそらく私はあまりにも新しい学校です（それが何であれ）。それは私がそれ自体のために支払うことができたツールではありません。

Microsoft / Apple / Googleはプッシュしていません:)

どのような開発が普及するかは、ツール、支援者、伝道に大きく関係しています。大きな支援者なしで何かを突破することは非常に難しいです（おそらくRuby on railsは例外ですが、Java / C＃/ Pythonと比較するとまだ小さいです）

これらすべてのモデリングツールに影響を与えた単純な法則のため、CASE、UMLなどは次のとおりです。

プログラマーと彼のコードの間のやり取りは非常に費用がかかります。

その場合、適切なコンパイラ/インタープリターを構築する必要があります。コードジェネレーターは、ひどいワークフローとプログラマーへのひどいフィードバック（エラーメッセージなど）をもたらします。

ドメイン駆動設計の優れた洞察の1つは、モデルはコードの外部にあるのではなく、コードにあるべきだということです。

最終的には、モデルがコードに適合しないのは問題です。組み込み開発を行っており、Cで動けない場合や、異なるプラットフォーム用のコードを生成する必要がある場合は、コード生成に費用をかける価値があります。他のすべての人にとって、より強力なプログラミング言語と優れたコード設計は、通常、コード以外の何かでコードを設計するよりも優れています。

• ごくわずかな利益のために巨大な面倒のようです。
• 私はいつもエッジケースや奇妙なことを楽しんでいるように見えますが、魔法のようなものは実際には正しく機能しないようです。
• オブジェクト指向は特効薬ではありません。ソフトウェア生成方法論をオブジェクト指向にブロブしても、それはシルバーになりません。

しかし、私は一般的に企業向けソリューションが好きではありません。

私は議論し、MDAをやりたいと思っていますが、最大の欠点は今のところツールのサポートです。「ランタイムモデルの評価」と呼ぶMDAの派生を使用していますが、これについては後で詳しく説明します。

私が知っているように、MDAの欠点は次のとおりです。

• 欠落しているリファクタリングのサポート：MDAを使用してデータモデルのエンティティをモデル化したいと思います（典型的なユースケース1）。モデルをUMLダイアグラムに入れて、それを変更しても、コードは何も変更されません（少なくとも生成されたクラス）。そして、より良い名前の属性を持つ機能するアプリがまだあるのではなく、多くのエラーは手動で修正する必要があります。
• 不足しているデバッグサポート：通常、モデルからコードへの変換は、変換言語を手元に置いて行われます。通常、これは問題になりませんが、デバッグするとき、生成するコードを心配する必要はなく、デバッガーが変換モデルにステップインする必要があります。代わりに、生成されたコードにステップインします。すべての人が知っているように、変換は生成されたコードではなく、見栄えが良いはずです。オーケー、かなり印刷できますが、最適な世界では、生成されたコードはコンパイラーアーティファクトであり、デバッグセッションのためにエディターで開く必要はありません（私はそれと一緒に生きることができ、この引数は少し理論的には、しかし、それはMDAに対する1つの理由です）
• コード化されたモデルは簡単です。他の例では、モデルはドメインの側面をモデル化し、それをコードにコンパイルします。はい、それはMDAですが、ほとんどのMDAモデルは洗練された構成ファイルであり、実行時に簡単に処理できます。
• 変換はテストするのが困難です。特殊なIDEで変換を使用する場合、それらはIDEの「コンパイラ」によって実行されます。ただし、変換はアプリケーションのコードの一部と見なされる必要があり、そのため、アプリのテストおよびコードカバレッジ要件も満たす必要があります。

私が現在好んでいるのは「実行時モデル評価」です（誰かがこれに受け入れられた名前を知っているなら、教えてください）。エンティティは通常のJavaクラスに格納され、「モデル化」するために必要なものはすべて、アプリの起動時に読んだ注釈によって作成されます。変換は必要ありません。メタモデルを正しくするのは少し困難でした。

それ以外はすべて、プロパティファイルまたは階層データ用のXMLを使用して行われます。モデルがある場合、それは常に階層的であるため、XMLで表現できないモデル化できるものは何もありません。また、特別なモデルエディターが必要な場合は、おそらく作成する必要がありますが、アプリの実行時でも動作し、モデル化できるすべてのものよりもアプリを構成しやすいエディターを構築することもできます。

Fred BrooksのNo Silver Bulletを使用してMDDを実行していない理由を説明するほとんどの人は、Brooksが指摘する点を見逃していると思います。確かに、最終的な結論は、ソフトウェア開発の実際の本質的な複雑さがなくなることはないため、MDDはこれを解決しないということです。

しかし、ブルックスがこの本質的な複雑さについて議論する理由の1つは、言語、ライブラリ、およびツールとの戦い、つまり解決しようとしている問題の本質的な複雑さを扱っていない通常の時間と比較することです。これがまさにMDDの輝かしいところです。すべてのファズを取り除き、調整された言語、モデル、またはその他の形式を作成して、実際の複雑さに対処します。

したがって、この観点から、No Silver BulletはMDDに投資する優れた理由です。つまり、MDDの採用を妨げると考えられる問題がなければ、解決しようとしている問題の本質的な複雑さに完全に集中できるモデル駆動型環境の実際の開発は、汎用言語で直接問題を解決するだけです。ほとんどの場合、既存のMDDツールは非常に複雑だからです。

次のように比較してください。Cコンパイラを作成するよりもCでプログラムを作成する方がはるかに簡単です。他の開発者向けにMDD環境を作成するには、単に問題を解決して汎用言語でクラフを処理するのではなく、基本的に問題スペースで発生する可能性のあるすべてのクラフ関連の問題を解決するプログラムを作成する必要があります。それは非常に困難です。

私の知る限り、MDEとMDAは組み込みコントローラー開発者のニーズに十分に対応していません。システムを記述するためにモデルを使用することは確かに可能ですが、組み込み開発者はそのモデルを信頼して、最高の、または正しいソースコードを提供する準備ができているとは思いません。

開発者がモデルを使用してJavaコードを作成/更新するか、Javaコードを使用してモデルを作成/更新できるEclipse用のプラグインがいくつかあります。これは便利なツールのようです。残念ながら、私の開発はすべてANSI / ISO Cで行われ、同じことを行うことができるプラグインはありません。

さらに、他のデザインパターン（またはアンチパターン）よりも、イベント駆動型HSMまたは他のデザインパターンとしてコードを実装するように、開発者はモデルにどのように指示できますか？未知のデザインパターンを使用するようにコードを手動で更新した場合、モデルはそれを正確に表現できますか？

モデルに収まらない関数をどのように実装しますか？

簡単な答え...モデル駆動型は多くの場合コード生成に関連しており、コードは脆弱です。必要なのはコードの削除であり、モデル駆動型が確実に進むべき道です。

黄金のハンマーは存在せず、ソフトウェア開発は本質的に複雑であると主張する質問を却下した人もいます。

私は彼らに金色のハンマーがないことに完全に同意しますが、私はモデル駆動型が金色のハンマーまたは銀の弾丸の探求だとは思いません！

複雑さをさらに高めたいと思います。私は有機的または自然の複雑性と呼ばれる2種類の複雑性があります。これはビジネスとそのプロセスに固有の複雑さですが、儀式的な複雑さもあります。

毎日、命令ごとにシステムの命令に忍び込む複雑さ。儀式的な複雑さ-不要な複雑さ-は、ビジネスコードと技術コードの制御されていないマングリングから本質的に発生しますが、システムの構造と均一性の欠如からも発生します。

今日、情報システムの開発に悩まされ、障害と腰を引き起こす複雑さ全体が儀式的な複雑さです。排除できる複雑さ。

儀式の複雑さは、無駄、コードによる無駄、価値の低さ、不利な変更、不変のコードです。厳密な最小値に減らす必要があるコード。

どうやってするか？簡単です！そもそも、それを書いたり、生成したりしないでください！

必要な不変の技術コード。読み取り/書き込み、表示、通信に使用されるコード...それは、データの論理構造を記述することにより、モデルが取得する場所です-リレーショナルな方法で追加します-モデルは、標準の読み取り/書き込み、表示、および通信の一般的な処理を可能にしますデータ。

これはオペレーティングシステムのようなもので、使用するプロジェクトごとに書き換える必要はありません。したがって、必要なのは、モデルが与えられたソフトウェアの不変の側面を処理する技術的なエンジンです。私はそれをAaaS（サービスとしてのアーキテクチャ）エンジンと呼びます。

不要なコードについては、不要なコードであるため、未記述のままにしておくこともできます。

これにより、必要なビジネス指向のコードを作成し、必要なビジネス指向のデータを設計し、必要なユーザーインターフェイスとエクスペリエンスを設計および想像することができます。

脆弱なコードを排除することで、コードよりもモデリングと設計にはるかに基づいたソフトウェア開発の新しいパラダイムであるArchitecture as a Serviceを採用できます。

いくつかの理由があると思いますが、1つはMDDが大学のカリキュラムに含まれていないことです。通常、最も近いのはモデリングを教えるコースで、モデルはスケッチのままです（チェック、コード生成、モデルレベルでのデバッグは行われません）。この「モデリング」コースではUMLも紹介されることが多く、作成されたモデルの価値が低い場合に、なぜこのように大きく複雑な表記法を学ぶのか、学生は困惑します。

これとは対照的に、学生がまったく異なる体験を得る組み込みハードウェア開発者や制御エンジニアなどの他の工学分野とは対照的です。SimulinkやLabviewのようなツールを使用すると、学生はモデルを描画してコードを生成できます。または、少なくともシミュレーションで実行できます。

過去の大学ではコンパイラとパーサーを教えていましたが、今ではジェネレーターの作成方法、DSLの実装方法などを教える必要があります。

これはトップダウンのモデルからコードへのアプローチであるため、モデル駆動型開発は無意味です。モデルだけから完全に実行中のアプリケーションを作成することは不可能であるため、MDDは役に立ちません!!

私がしていることは、UMLをより高い抽象化レベルでのみ使用して、アプリケーションのスケルトンを作成することです。つまり、パッケージ、クラスなどを作成し、すぐにJava言語でコードを作成します。

Togethersoft、Omondoなどのツールとのライブ同期は、2004年に初めてモデリングを開始したときに非常に便利であることがわかりました。本当に強力で、私のプロジェクトではうまく機能します。

私のUMLダイアグラムは、プロジェクトを高速化するのに役立ち、もう役に立たなくなりました:-)

MDDは開発プロセスに別のステップを追加します。これは、良いモデルがなく、市場への最初の予測不可能な、またはほぼ壊れた部分的なソリューションが、ほとんどの大理石を獲得する可能性がある状況での欠点です。

実行可能なビジネスプロセスモデルを持つことは、ひどい目標です。理論的には、プログラマーはまったく必要ありません。MDEを使用すると、実際のモデルを機能させることはコードを書くのと同じくらい複雑であることを実践が示しています。

経験豊富な開発者にとっては、たとえばExecutableUMLを使用するよりも、UMLから生成されたクラスを入力する方がはるかに簡単だと思います。一方、ExecutableUMLには大量のコンピューターサイエンスの知識が必要なので、ビジネスマネージャーが自分で作成することはできません。理論的には、彼は準備ができたブロック（クラス）を組み合わせますが、実際には「接着剤」が問題の原因です。

また、MDEの有用性は、コンポーネントの再利用が多いシステムに限定されます。

MBSE-モデルベースのソフトウェアエンジニアリングは、より適切な用語です。

効果的なソリューションであるさまざまなツールの問題を言えば、MBSEは異なるプロジェクトワークフローを必要とします。DSML（ドメイン固有モデリング言語）は、レビューの要件を利害関係者と効果的に伝達するために必要な抽象化レベルである必要があります。次に、最終的にコードを生成するために、ますます洗練されたレベルでモデルを変換する必要があります。

DSMLおよび変換/生成プロセスが完全かつ正しく実装されている場合、アーティファクトの生成は非常に低コストで実現します。しかし、デバッグされたツールのその段階に到達するまで、非常に苦痛です。

MDDのサクセスストーリーのほとんどは、製品ラインエンジニアリング（PLE）の領域にあり、確立されたツールを使用して同様の製品が連続して生成されます。もちろん、Javaコードジェネレーターの多くは、MDDの本当に単純化されたバージョンです。一部のXML入力および生成されたコード出力。

あなたが書いた：

私はまた、多くの問題があることを知っています...モデル駆動型開発にちょうど向いていないプロジェクト（十分な繰り返しではありません）

コードが反復的である場合、貧弱なプログラミング言語を選択しているか、不適切に使用しています。より良い言語では、繰り返しの必要はありません。Ruby Active Recordライブラリーを検討してください。データベーステーブルは、移行を記述することで作成されます。他の場所でスキーマ定義を繰り返す必要はありません。テーブルの列に対応するデータメンバーを持つクラスを定義する必要はありません。1行のコードでクラスをテーブルに接続します。

私は、モデル駆動型開発を、弱いプログラミング言語の複雑で非効率的な回避策と見なしています。