なぜまだモデル駆動型開発を行っていないのですか？
私はモデル駆動型開発の真の信奉者であり、生産性、品質、予測可能性を向上させる可能性があると思います。 MetaEdit を見ると、結果は驚くべきものです。 Mendix オランダは非常に急速に成長しており、素晴らしい結果をもたらしています。
私はまた多くの問題があることを知っています
- ジェネレーター、テンプレート、フレームワークのバージョン管理
- モデル駆動型開発に適さないプロジェクト（十分な繰り返しがない）
- リスクが高い（最初のプロジェクトが失敗した場合、従来の開発よりも結果が少ない）
- 等
しかし、これらの問題は解決可能であるように見え、その利点は必要な労力を上回るはずです。
質問：モデル駆動型開発を考慮しない最大の問題は何だと思いますか？
私はこれらの回答を自分自身の理解のためだけでなく、これから書こうとしている一連の社内記事の可能な情報源としても使用したいと考えています。
金槌はありません。あるドメインでうまく機能するものは、別のドメインではほとんど役に立ちません。ソフトウェア開発には固有の複雑性があり、それを取り除く魔法のツールはありません。
また、コードの生成は、言語自体（またはフレームワーク）が、MDDを比較的無意味にする強力な抽象化を可能にするほど高レベルでない場合にのみ役立つと主張する人もいます。
興味深い質問です！確かに、私はファンではありませんが、あなたが提起したいくつかの問題に適合するプロジェクトで、モデル駆動型開発を何度か使用しようとしました。
これが私の理由リストです：
- 学習曲線-モデリングツールは急速に進化しているため、ツールを深く理解しているエンジニアを見つけるのは難しいです。私はまだあなたがあなたのモデリングツールと同じくらい優れていると思います。確かに、以下の問題の多くは、この1つの問題にまでさかのぼることができます。ツールの制限が高すぎると思うときはいつでも、十分に把握していない可能性があります。
- 構造化されすぎている-個人的には、モデリングツールが構造化されすぎて、説明に必要なすべてを説明できない状況にありました。そして、モデルの一部をツールの外側に描画するように切り替えると、人々がツールの外側をドリフトして情報を見つけ始めると、事態は急速に衰退します。
- ツールの調整にかかるコスト-コードを自動生成しようとするたびに、ツールの考えが正しいとわかったら、手動でコードを作り直す必要がありました。数回の移動でこの問題は減少することはわかっていますが、それは最初の数回のラウンドを生き残る必要があることを意味します。私は一般的に私たちがモグラを叩いて遊んでいると感じました-モデルを作成する->コードを生成する->コードを修正する->モデルを更新する->モデルを修正する、リンスして繰り返す。
- モデル構成管理-モデルはプロジェクトの大部分を記述するため、あるレベルでは、モデルCMはビルドされたコードよりも横断的なものになります。モデリングファイルのコンパートメント化はそれ自体が芸術です。間違ってしまうと、開発者のデッドロックや、モデルをあきらめてコードに取り掛かるときに古いモデルになってしまうことがよくあります。
- 市場投入までの時間-機能するソフトウェアの必要性が緊急である状況で、明確な問題を経験しました。プロジェクトとチームが十分に小さい場合、コーディングとテストに時間を費やすことができるのに、モデリングツールに時間を浪費する理由はありません。すべてのプロジェクトがそのような投資を必要とするほど大きいわけではありません。
- 失敗のコスト-プロジェクトがモデリングツールから逃げるのを見たとき、それは失敗のコストが高いためです-ツールを使用するには、すべての開発者が関与する必要があります。これはトレーニングとハンズオンラーニングへの大きな投資であり、誰かがモデルを不適切に設定した場合、非常にコストのかかる間違いとなります。私の経験では、モデルが正しくなるまでに2〜3回のリリースが必要になる可能性があります。そのため、多くのプロジェクトは、利点を実現するのに十分なほどモデリングのミスを乗り越えられません。
すでに引用されていますが、 No Silver Bullet はこの点にかなりよく対応しています。
ソフトウェアエンティティの本質は、データセット、データアイテム間の関係、アルゴリズム、関数の呼び出しなど、連動する概念の構成要素です。この本質は、そのような概念的な構成が多くの異なる表現の下で同じであるという点で抽象的です。それにもかかわらず、それは非常に正確で豊かな詳細です。
ソフトウェア構築の難しい部分は、この概念構成の仕様、設計、およびテストであり、それを表現して表現の忠実度をテストする労力ではないと信じています。確かに、構文エラーはまだあります。しかし、ほとんどのシステムの概念的なエラーと比較すると、それらはあいまいです。
これが本当なら、ソフトウェアの構築は常に難しいでしょう。 本質的に銀の弾丸はありません。
後にブルックスは、「自動プログラミング」の概念について次のように指摘しています。
約40年前から、人々は「自動プログラミング」、つまり問題の仕様の記述から問題を解決するためのプログラムの生成について予測して書いてきました。今日の何人かは、彼らがこのテクノロジーが次のブレークスルーを提供することを期待するかのように書いています。
パルナスはこの用語が意味的な内容ではなく魅力的な意味で使用されていることを示唆し、「要するに、自動プログラミングは常に高級言語でのプログラミングの冒涜であるプログラマが現在利用できるよりも。」
本質的に、仕様を指定する必要があるのはほとんどの場合、問題ではなく解決方法であると彼は主張します。
基本的に、MDDは、以前に利用可能だった言語よりも高級言語でプログラミングするための単なるもう1つの婉曲表現だと私は主張します。
だからといって、高級言語でのプログラミングが役に立たないわけではありません。しかし、問題の本質は同じままです。1日の終わりに、ツールがどれほど優れていても、使用している言語がどれほど優れていてもあなたはすべての問題を熟考し、問題を解決する必要があります。ツールやプロセスで実行できる最善の方法は、「ファズ」を削除することです。これにより、ブルックスが言ったように、「仕様、design、およびtestingthis概念的な構成 "。
すべてのプログラミングがオブジェクト指向であるとは限らないため、すべてのMDDツールが期待しているようです。 UML自体は、オブジェクトの推定に基づいています。シーケンス図を使用して関数をモデル化できることは確かですが、多くの場合、不便です。
私のようなプログラマーがMDDよりもTDDからより多くの進歩と結果を得ているからです。
モデリング！=プログラミングだからです。
コスト/ベネフィットがコスト面で高すぎて、ベネフィット面では不十分だったからです。これは恐らく私が最後にMDDを見たときから変わっているでしょう。当時は、MDDを中程度に実行できるツールに対して> $ 6000 /シート（USD）を支払う必要があります。
コードを生成するための関数を十分に記述しているモデルは、もはやモデルとしては役に立たないからです。
私のように、高レベルでのみモデルを使用し、コードで詳細を理解するプログラマーがいるからです。モデリングソフトウェアとはコードの見方が異なります。
これらが私が個人的にMDDをしない理由のいくつかです。私はそれに触れたことはありますが、私を改宗させることはできませんでした。たぶん私は古すぎる学校です。おそらく、私はあまりにも新しい学校です（それが何であれ）。それは私が自分のためにお金を稼ぐことができたツールではありません。
これらすべてのモデリングツールに影響を与えた単純な法則により、CASE、UMLなどがわかります。
プログラマーと彼のコードの間を行き来することは非常にコストがかかります。
その場合、適切なコンパイラ/インタプリタを構築する必要があります。コードジェネレータは、ワークフローへの悪影響とプログラマへのフィードバック（エラーメッセージなど）につながります。
ドメイン駆動設計の優れた洞察の1つは、モデルはコードの外部にあるのではなく、コード内にある必要があるということです。
最終的に問題は、モデルがコードに適合しないのはなぜですか？組み込み開発を行っていて、Cで立ち往生している場合、または異なるプラットフォーム用のコードを生成する必要がある場合、コード生成はコストに見合う価値があるかもしれません。他のすべての人にとって、より強力なプログラミング言語とより良いコード設計は、通常、コード以外のものでコードを設計するよりも優れています。
Microsoft/Apple/Googleはそれを押していません:)
どのような開発が普及するかは、ツール、後援者、伝道に大きく関係しています。大きな支援者なしで何かを突破するのは非常に困難です（Ruby on Rails例外かもしれませんが、Java/C＃/ Pythonと比較するとまだ小さいです）
- メリットがほとんどないため、非常に面倒なようです。
- 私はいつもEdgeのケースや奇妙なことを楽しんでいるようですが、魔法のものは本当に正しく機能しているようには見えません。
- OOは特効薬ではありません。ソフトウェア生成方法論をOOに当てはめても、それがシルバーになるわけではありません。
しかし、私は一般的にエンタープライズソリューションが好きではありません。
私は話し合いをしてMDAをやりたいと思っていますが、最大の欠点は今のところツールのサポートです。私は「ランタイムモデル評価」と呼ぶMDAの派生を使用していますが、それについては後で詳しく説明します。
MDAの欠点は、私が知っているとおりです。
- 欠落しているリファクタリングのサポート：データモデルのエンティティをMDA（典型的なユースケースNo. 1）でモデル化したいと思います。私のモデルがUMLダイアグラムにあり、それを変更した場合、それによってコードはまったく変更されず（少なくとも生成されたクラス）、より適切な名前の属性を持つ作業中のアプリが存在する代わりに、多くのエラーは手動で修正する必要があります。
- デバッグサポートの欠如：通常、モデルからコードへの変換は、何らかの変換言語を手元に置くことによって行われます。これは通常は問題になりませんが、デバッグするときは、生成するコードを心配する必要はなく、デバッガは変換モデルにステップインする必要があります。代わりに、生成されたコードにステップインします。誰もが知っているように、変換は生成されたコードではなく、見栄えがするはずです。わかりました、かなり出力できますが、最適な世界では、生成されたコードはコンパイラのアーティファクトであり、デバッグセッションのためにエディタで開く必要はありません（私はそれと共存することができ、この引数は理論的には少しですが、 MDAに対する1つの理由です）
- コード化されたモデルは簡単です。他の例では、モデルはドメインの側面をモデル化し、それをコードにコンパイルします。はい、それはMDAですが、ほとんどのMDAモデルは洗練された構成ファイルであり、実行時に簡単に処理できます。
- 変換はテストが難しい：特殊なIDEで変換を使用する場合、変換はIDEの「コンパイラ」によって行われます。ただし、変換はアプリケーションのコードの一部と見なす必要があるため、アプリのテストとコードカバレッジの要件も満たす必要があります。
私が現在好んで使用しているのは、「ランタイムモデルの評価」です（誰かがこれに使用できる名前を知っている場合は、教えてください）。私のエンティティは通常のJava=クラスに保存されており、「モデル化」するために必要なものはすべて、アプリの起動時に読んだ注釈によって作成されます。変換は必要ありません。私のメタモデルを正しくしてください。
それ以外はすべて、プロパティファイルまたは階層データのXMLのいずれかで行われます。モデルがある場合、それは常に階層的であるため、XMLでは表現できないモデルを作成することはできません。特別なモデルエディターが必要な場合は、おそらくこれも作成する必要がありますが、アプリの実行時にも機能するエディターを構築して、モデル化できるすべてのものよりもアプリを構成しやすくすることができます。
フレッド・ブルックスのNo Silver Bulletを使用してMDDを行っていない理由を説明するほとんどの人は、ブルックスの主張が欠けているように感じます。確かに、最終的な結論は、ソフトウェア開発における実際の本質的な複雑さは解消されないため、MDDはこれを解決しないということです。
しかし、ブルックスがこの本質的な複雑さについてさえ話している理由の1つは、言語、ライブラリ、ツールとの戦いに通常費やしている大量の時間と比較することです。つまり、解決しようとしている問題の本質的な複雑さに対処していません。つまり、これがMDDの強みです。ファズをすべて取り除き、調整された言語、モデル、またはその他の形式を作成して、実際の複雑さに対処します。
したがって、この観点から、No Silver BulletはMDDに投資する優れた理由です。つまり、問題がなければMDDの採用を妨げると考えています。解決しようとしている問題の本質的な複雑さに完全に集中できるモデル駆動環境の実際の開発は、汎用言語で問題を直接解決するだけです。ほとんどの場合、既存のMDDツールは非常に複雑です。
次のように比較してください。Cコンパイラを書くよりも、Cでプログラムを書く方がはるかに簡単です。問題を解決して汎用言語で問題を処理するのではなく、他の開発者向けのMDD環境を作成するには、基本的に問題空間で起こり得るすべての問題に関連する問題を解決するプログラムを作成する必要があります。それはかなり挑戦的です。
これはコードアプローチのトップダウンモデルであるため、モデル駆動型開発は意味がありません。モデルから完全に実行するアプリケーションを作成することは不可能であるため、MDDは役に立ちません。
私がやっていることは、抽象化のより高いレベルでUMLのみを使用して、アプリケーションのスケルトンを作成することです。つまり、パッケージ、クラスなどを作成し、すぐにJava言語でコーディングを開始します。
2004年に初めてモデリングを開始したとき、Togethersoft、Omondoなどのツールとのライブ同期が非常に便利であることがわかりました。最近、Omondoによって、Java、モデル、データベースID間の一種のマッピングである新しいステージが導入されました。本当に強力で、私のプロジェクトでうまく機能します。
私のUMLダイアグラムはプロジェクトのスピードアップに役立ち、もはや役に立たなくなりました:-)
私の知る限りでは、MDEとMDAは組み込みコントローラー開発者のニーズに十分に対応していません。モデルは確かにシステムの記述に使用できますが、組み込みの開発者がモデルを信頼して最高の、または正しいソースコードを提供する準備ができているとは思いません。
開発者がモデルを使用してJavaコード、またはJavaコードを作成/更新/モデルを更新します。これは便利なツールのようです。残念ながら、私の開発はすべてANSI/ISO Cで行われており、同じことを実行できるプラグインはありません。
さらに、開発者は、他の設計パターン（またはアンチパターン）よりもコードをイベント駆動型HSMまたは他の設計パターンとして実装するようにモデルにどのように指示できますか？未知のデザインパターンを使用するようにコードを手動で更新した場合、モデルはそれを正確に表現できますか？
モデルに適合しない関数をどのように実装しますか？
簡単に言えば、モデル駆動型はコード生成に関連することが多く、コードは壊れやすいためです。私たちが必要としているのは、コードの排除とモデル駆動です。
一部の人は、金槌はなく、ソフトウェア開発は本質的に複雑であると主張する質問を却下しました。
金色のハンマーがないことは完全に同意しますが、モデル駆動が金色のハンマーや銀の弾丸の探求であるとは思いません！
さらに複雑にしていきたいと思います。 2種類の複雑さがあります。1つは有機的または自然な複雑さ、ビジネスとそのプロセスに固有の複雑さですが、儀式的な複雑さもあります。
毎日、命令ごとにシステムの命令に忍び込んでいく複雑さ。儀式の複雑さ-不必要な複雑さ-は、基本的には、ビジネス指向のコードによるテクニカルコードの制御されていないマングルから生じますが、システムの構造と均一性の欠如からも生じます。
今日、情報システムの開発を悩ませ、失敗と腰を引き起こす全体の複雑さは、儀式的な複雑さです。排除できる複雑さ。
儀式の複雑さは無駄であり、コードによって引き起こされる無駄であり、価値が低く、変更が不利で不変のコードです。厳密な最小値に削減する必要があるコード。
どうやってするか？簡単です。そもそも記述せず、生成しないでください。
必要な不変の技術コード;読み取り/書き込み、表示、通信に使用されるコード…データの論理構造を記述することにより、モデルが入ります-リレーショナルな方法で追加します-モデルは、標準の読み取り/書き込み、表示、および通信の一般的な処理を可能にしますデータ。
これはオペレーティングシステムのようなもので、使用するすべてのプロジェクトで書き換える必要はありません。したがって、必要なのは、モデルが与えられたソフトウェアの不変の側面を処理する技術エンジンです。私はそれをAaaS（Architecture as a Service）エンジンと呼んでいます。
不必要なコードについては、まあそれは不必要なコードなので、書かないでおくのもいいかもしれません。
これにより、必要なビジネス指向のコードを記述し、必要なビジネス指向のデータを設計し、必要なユーザーインターフェイスとエクスペリエンスを設計および想像する必要があります。
壊れやすいコードを排除することで、コードよりもモデリングと設計に基づいたソフトウェア開発の新しいパラダイムとして、サービスとしてのアーキテクチャを採用できます。
理由はいくつかあると思いますが、MDDが大学のカリキュラムに含まれていないことは確かです。通常、最も近いのはモデリングを教えるコースで、モデルはスケッチのままです（チェック、コード生成、モデルレベルでのデバッグはありません）。この「モデリング」コースでは、UMLを紹介することも多いため、作成されたモデルの価値が低い場合に、学生がなぜそんなに大きくて複雑な表記法を学ぶのか困惑します。
これを、組み込みハードウェア開発者や制御エンジニアなど、学生がまったく異なる経験をする他の工学分野と比較してください。 SimulinkやLabviewなどのツールを使用して、生徒はモデルを描画し、コードを生成するか、少なくともシミュレーションで実行できます。
過去の大学ではコンパイラとパーサーを教えていましたが、今では、ジェネレータの作成方法やDSLの実装方法などを教える必要があります。
MBSE-モデルベースのソフトウェアエンジニアリングがより適切な用語です。
効果的なポイントソリューションにあるさまざまなツールの問題を取り上げると、MBSEには別のプロジェクトワークフローが必要です。 DSML（ドメイン固有のモデリング言語）は、レビューの要件を利害関係者と効果的に伝えるために必要な抽象化のレベルである必要があります。次に、最終的にコードを生成するために、絶え間なくレベルを上げてモデルを変換する必要があります。
DSMLと変換/生成プロセスを完全かつ適切に実装すると、アーティファクトの生成が非常に低コストになります。しかし、デバッグされたツールのその段階に到達するまで、それは非常に苦痛です。
MDDのサクセスストーリーのほとんどは、確立されたツールを使用して一連の類似製品が生成される製品ラインエンジニアリング（PLE）の領域にあります。もちろん、Javaコードジェネレーターの多くは、MDDの非常に簡略化されたバージョンです。XMLの一部および生成されたコードの一部です。
実行可能なビジネスプロセスモデルを作成することは非常に喜ばしいことです。理論的には、そのためのプログラマーはまったく必要ありません。 MDEでは、実際のモデルが機能するようにするのは、コードを書くのと同じくらい複雑です。
経験豊富な開発者にとっては、たとえばExecutableUMLを使用するよりも、UMLから生成されたクラスに入力する方がはるかに簡単だと思います。一方、ExecutableUMLにはかなりのコンピューターサイエンスの知識が必要なので、ビジネスマネージャーが自分で作成することはできません。理論的には、準備ができたブロック（クラス）を組み合わせるだけですが、実際には「接着剤」が問題を引き起こしています。
また、MDEの有用性は、コンポーネントの再利用が多いシステムに限定されます。
MDDは、開発プロセスに別のステップを追加します。これは、良いモデルがなく、市場への最初の予測できない、またはほぼ壊れた部分的なソリューションが最も多くの成功を収める可能性がある場合のマイナス面です。
あなたが書いた：
私はまた、多くの問題があることも知っています...モデル駆動型の開発には適さないプロジェクト（繰り返しが不十分）
コードが反復的である場合、貧弱なプログラミング言語を選択したか、それをひどく使用しています。より良い言語では、繰り返しの必要はありません。 Ruby Active Recordライブラリを検討してください。データベーステーブルは、マイグレーションを作成することによって作成されます。他の場所でスキーマ定義を繰り返す必要はありません。データメンバーを持つクラスを定義する必要はありません。テーブルの列に対応します。1行のコードでクラスをテーブルに接続します。
私は、モデル駆動型開発を、弱いプログラミング言語の複雑で非効率的な回避策と見なしています。