7

プログラミング言語の歴史には、いくつかの (r) 進化のステップがありました。モデル駆動型のアプローチが次のビッグ シングになると主張する人もいます。openArchitectureWare、AndroMDA、Sculptor/Fornax Platform など、信じられないほどの生産性の向上を約束するツールがあります。ただし、最初は簡単に始めることができますが、予期しないことをしようとしたときに行き詰まったり、プロジェクトの開始方法を説明する十分な情報を見つけるのが非常に困難であるという経験をしました。考慮すべきことがたくさんあるかもしれません。

モデル駆動型のものから何かを引き出すための重要な洞察は、モデルが必ずしも素敵な写真やツリー モデル、UML のセットであるとは限らず、テキストによる記述 (ステート マシン、ビジネス ルールなど) である可能性があることを理解することだと思います。等。）。

あなたは何を考え、あなたの経験は何を教えてくれますか? モデル駆動型開発 (またはあなたがそれを何と呼びたいか) に未来はありますか?

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

4

9 に答える 9

6

免責事項: 私はビジネス アプリケーションの開発者です。次の見解は、エンタープライズ IT の塹壕での私の経験によって確かに形作られています。私は、ソフトウェア開発の他の領域があることを認識しています。特に、産業用および/または組み込みシステムの開発では、世界が異なって見える場合があります。

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

コード生成は、コードに多くのノイズが含まれている場合や非常に反復的な場合にのみ役立ちます。言い換えれば、コードが本質的な複雑さに主に集中できず、偶発的な複雑さで汚染されている場合です。

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

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

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

そのため、DSL が MDSD と一緒に言及されることがよくありますが、実際には DSL は MDSD に代わるものだと思います。また、現在の誇大宣伝を考えると、彼らは MDSD 運動から勢いを奪っています。

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

素敵なボックスやダイアグラムは、抽象化レベルの別の単純化や昇格を提供しません! それらは視覚化には適しているかもしれませんが、それでも疑問です. 複雑さを把握するのに、絵は常に最良の表現であるとは限りません!

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

私の理論の実例として、次の ActiveRecord モデルを見てください。

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

これ以上単純化できないと思います。また、ボックスと線によるグラフィカルな表現は単純化されず、これ以上の利便性は提供されません (レイアウト、リファクタリング、検索、差分などについて考えてみてください)。

于 2008-11-26T11:04:35.110 に答える
5

モデル駆動型の開発は非常に長い間行われてきました。

初期の試みの中で最も成功したのは、ジェームズ・マーティンズ統合エンジニアリング施設でした。これは、CAによって、ひどくクールでない「Coolgen」ブランド名で販売されています。

それで、それがとても良かったのに、なぜそれは世界を引き継がなかったのですか？

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

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

于 2008-11-26T11:19:28.807 に答える
3

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

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

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

つまり、MDD は、ツールと経験が増えるにつれて、まだ構築されていると言えます。必要な専門知識があり、社内でプッシュする準備ができている場合は、すでに正常に使用できます。最終的には、これは非常に良いことだと思います。なぜなら、多くのグルー コード (別名コピー ペースト) を生成できるし、生成する必要があるからです。私の意見では、MDDでそれを行うことは、これを行うための非常に優れた構造化された方法であり、再利用性を容易にします。

于 2008-09-18T20:39:25.220 に答える
3

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

しかし、私は個人的に MDA について複雑な経験をしてきました。良い経験だったのは素晴らしいツールを使った時だけでした - 私は TogetherSoft を使っていました (彼らはどういうわけか borland になったと思います) - 彼らは「コード生成」ではなく、実際にコードを編集する編集を最初に導入した企業の 1 つでした。モデルを直接 (コードやモデルを編集できるように、すべてが 1 つのものでした)。また、リファクタリングもありました (smalltalk 環境を投稿したことを覚えているのはこれが初めてでした)。

それ以来、少なくともメインストリームでは、MDA の人気が高まっているのを見たことがないので、人気という点では未来ではないようです (そのような答えです)。

もちろん、人気がすべてではなく、また戻ってくる傾向もありますが、当面、MDA+tools は「ウィザードベースのコード生成」ツール (実際の内容に関係なく) として多くの人に見られていると思います。それが本当に離陸するのはいつか、あるいは決してないだろうと思います。

于 2008-08-21T23:23:41.143 に答える
2

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

于 2008-09-17T13:53:42.693 に答える
1

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

テキストベースのプログラミング言語では、モデルの変更は数行のコードを変更するのと同じくらい簡単です。グラフィカルプログラミング言語（別名UMLのようなMDDダイアグラム）を使用すると、そのモデルをテキストベースの同等のもの（最初からすでに表現効率が高い）に戻す方法を見つける必要があります。非常に、非常に乱雑になります。

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

于 2008-12-23T01:40:32.690 に答える
1

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

ここの貢献者は「No Silver Bullet」陣営の一部だと思います (私は間違いなくそうです)。MDA が機能した場合 (「大幅な節約」に相当)、それは確かです。問題は、システムを管理しやすくしながら、どこまで「メタ」を達成できるかということです。これは、UML 2.0 がより正式なメタメタモデルを導入したときの転換点でした。これまでのところ、UML 2.0 のモデル化機能が実際に使用されているのを見たことがありません (ただし、私の世界はかなり限られています)。さらに、モデル駆動型のアプローチでは、コードを生成するか、ランタイムでモデルを活用するかの 2 つの選択肢しかありません。究極の制約のないコード ジェネレーターは「人間」と呼ばれますが、究極のランタイムは 4GL に見られます (現在の数は何ですか?)。多分それは熱意の欠如を説明するでしょう.

于 2008-08-26T15:41:33.443 に答える
1

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

于 2008-09-16T09:45:19.613 に答える
0

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

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

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

  1. 少数の人々がアプリケーション フレームワーク、ミドルウェア アダプターを作成し、それを MDD ツールに接着します。彼らは「家」を建てます。
  2. 他の人は、完全なクラス、図、およびステート マシン遷移コードを作成します。これにより、「家」ではなくアプリケーションに集中できます。
  3. ダイアグラムはコードなので、人々が奇妙なデザインをしているときは簡単にわかります。私たちにはすべてのエキスパート開発者がいるわけではありません。このように後輩を育てるのは素晴らしいことです。
  4. ほとんどの場合、移動ロボット プロジェクトのようなもので発生する厄介なステート マシン コードです。私が理解し、批判し、一緒に作業できる状態図を作成してくれる人が欲しいのです。
  5. また、操作や属性を継承チェーンや他のクラスにドラッグするなど、優れたリファクタリングを行うこともできます。私はファイルを掘り下げるよりも好きです。

これを入力しているときでも、コードですべてを実行できることに気付きます。統一性を確保し、設計を文書化し、リファクタリングを少し簡単にするために、コードの上に薄いツール jsut を配置するのが好きです。

私が遭遇した主な問題は、そのようなモデルの機能とファイル形式の標準セットがないことです。人々は、ベンダーが去って立ち往生することを心配しています。(基本的には Rose RT で発生しました。) ソース コードでは発生しません。ただし、最新バージョンのツールと、最後に生成したコース コードを使用できます :)。利益がリスクを上回ることは間違いありません。

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

于 2009-11-05T18:42:29.190 に答える