モデル駆動型ソフトウェア開発についてどう思いますか？

Question

Javaおよび/または.NET用のモデル駆動型ソフトウェア開発についてのご意見を本当にお聞きします。

時間が節約できますか？それは品質を向上させるか？

Answer 1

IBM Rational Rhapsody for C++のプロジェクトでMDSDを使用しています。モデルはUMLにかなり近いので、ドメイン固有言語は実際にはありません。しかし、私はMDSDを使用すると主張します。私の経験から、MDSDには多くの利点があります。

a）MDSDを使用すると、SWアーキテクチャを洗練されたレベルにすることができます。あなたはいつも非常に抽象的なレベルで作業し、大きな画像について考えます。カウボーイコーディングソフトウェアは、通常、開発者が細部にこだわるため、優れたアーキテクチャを欠いています。 MDSDでは、私は自分の仕事で、適切なサイズのクラス、素敵なパターン、または単にコードを改善する傾向を見ます。

b）SWの大きな画像ドキュメントは、MDSDの方が優れている傾向があります。もちろん、コードから自動的にクラス図を生成するツールがあります。しかし、これらの図は1000のクラスで構成されており、関心のある側面は見えません。 MDSDでは、特にシステムの1つの側面を描画し、まったく同じダイアグラムを使用してコードの一部を生成します。

c）モデリングは、固有のシステムの複雑さに対処するのに役立ちます。私は、コンピュータ支援設計からのサポートなしに構築するには複雑すぎるシステムもあると言います。巨大なSWツールの助けを借りずにCPUを設計する人は誰もいません。 SWを使用すると、さらに複雑なSWを書くのに役立ちます。

d）MDSDを使用すると、コーディングスタイルのガイドラインに準拠するのに役立ちます。ルールセットによってコードを生成させるよりも、一貫したコードスタイルを得るための良い方法はありません。

もちろん、MDSDの弱点もあります。 d）モデルをお持ちの場合は、コードのすべての行をそのモデルから取得します。また、プロジェクトに外部ライブラリを組み込むのは難しいかもしれません。だからあなたは、あなたのシステムが外付けコンポーネントに基づいているか、ホイールをモデルに取り入れるために作り直すかのどちらかで生きています。

e）モデリングツールでは、バージョン管理ツールを使用する際に問題が発生する可能性があります。ソースコードは通常、モデルダイアグラムよりもマージするほうが簡単です。これにより、チームはコピー編集 - マージからロック - 編集 - マージワークフローに移行します。

Answer 2

確かに素晴らしいですが、私はそれが実際に動作する方法で実装されていることをまだ見ていません。

私はこれを次のように保持します：コードはモデルです。そうすれば、あなたのモデルとコードは常に最新のものになります:-)

Answer 3

MDAは少しオーバーロードされた概念です。時にはUMLや他のタイプのダイアグラムを実行可能コードに変換することを意味します。私は、このツールが今日利用可能なツールでうまくいくのを見たことがありません。利用可能なツールがビジュアルダイアグラムを扱う大きなチームを本当にサポートしておらず、人々が生成されたコードと同様にダイアグラムで作業を開始するので、プロジェクトは結果を本当に速くしてから維持管理の悪夢を引き起こします。私はあなたが私は通常、内部のビジネスルールを統合する困難に

Answer 4

MDA :-)それについてのすべてだという意味であれば、ドメイン駆動設計などの多くは、MDAと呼ばれているに見えた何かを見てきました

モデル・ビュー・マッピングは生成されたコードによって処理され、機能フックはイベント応答者として提供されるため、サーバー側レイヤー。

まだMDAツールはForté（またはUDS、現在死んでいる）+ Expressだったほど強力ではありませんでした。私はForteの機能を備えたMDAと、独立したサービス層（ActiveRecord、EntityTransactionManagerのパターンなど）を実現するためのより良いパターンが、どんなプラットフォームのキラーアプリケーションであろうと想像しています。

3段階のMDAアプローチを目指す実際のアプリケーションの問題は、特定の要件を設定して適用することが非常に難しいことです。 ABAPとSAPの料金を考えると

Answer 5

私はそれが望ましいと思います。それは私がMVCではなくMVC-ARSについてthis questionを暗示しようとしていたものです。 ARS（アクション/表現/状態）は、設計によってモデル内に含まれ、コントローラまたはビューの過負荷を防ぎます。

Answer 6

私は上記のようにMDAを理解するのに役立つと判明した2冊の本を投げ捨てるのは広範なテーマです。

• MDA Distilled - Model-Driven Architectureの原則。 （メラー）
• 実生活MDA：あなたはケーススタディが退屈としてアイデアを得るためにグットマンのすべてを読む必要はありませんモデル駆動型アーキテクチャ（グットマン）

とビジネスの問題を解決するが、イントロは読むのが楽しいです。

Answer 7

バズ。

私が信じることは、OTOHは実行時にモデリングしています。コードを生成する代わりに、実行時にモデルを有効にし、アプリケーションをこれらのモデルの実行時インタープリタにすることができます。

これがJava用に行われたかどうかはわかりません。スモールトークについては、シーサイドで使用されているMagritteを参照してください。

Answer 8

モデル駆動型ソフトウェア開発はMDAだけではなく、おそらくより一般的なドメイン固有言語アプローチを含む他のアプローチがあります。

もちろん、コードは 'a'モデルですが、DSLでより高いレベルのモデルをキャプチャすることは、同じ意図を表現するさらに簡潔な方法です。キーはに常に生成コードの独立した変更を許可するのではなく、モデルからコードを生成することです。

多くのツールが用意されています。既製の発電機を購入するのが苦手な場合は、独自の発電機を構築する方法を説明する、ケーススタディを含む多くの出版物があります。おそらくこれは、汎用プログラミング言語を扱うよりも、より多くの制御を可能にします。