9

Java や .NET のモデル駆動型ソフトウェア開発についてどう思うか、非常に興味があります。

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

4

8 に答える 8

8

MDA は少しオーバーロードされた概念です。場合によっては、UML または別の種類の図を実行可能コードに変換することを意味します。現在利用可能なツールでこれがうまく機能するのを見たことがありません。これは通常、プロジェクトが非常に迅速に結果を取得し、メンテナンスの悪夢を引き起こします。利用可能なツールは、視覚的な図で作業する大規模なチームを実際にはサポートしていないためです。また、人々は図と生成されたコードで作業を開始するためです。

ドメイン駆動設計によく似たものが MDA と呼ばれているのを見たことがあります。

于 2008-09-16T09:47:20.500 に答える
8

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

a) MDSD を使用すると、SW アーキテクチャを洗練されたレベルに引き上げることができます。全体像を考えながら、常に非常に抽象的なレベルで作業します。カウボーイ コーディング ソフトウェアには、通常、優れたアーキテクチャが欠けています。開発者は細部にこだわるからです。MDSD を使用すると、適切なサイズのクラス、優れたパターン、または単により優れたコードを使用して問題を解決する傾向が私の仕事に見られます。

b) SW の全体像の文書化は、MDSD の方が優れている傾向があります。もちろん、コードからクラス図を自動的に生成するツールもあります。しかし、これらの図は 1000 のクラスで構成されており、関心のある側面は見られません。MDSD では、具体的にシステムの 1 つの側面を描画し、まったく同じ図を使用してコードの一部を生成します。

c) モデリングは、固有のシステムの複雑さに対処するのに役立ちます。一部のシステムは複雑すぎて、コンピューター支援設計のサポートなしでは構築できません。巨大なソフトウェア ツールの助けなしに CPU を設計する人はいません。SW を使用すると、さらに複雑な SW を作成できます。

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

もちろん、MDSD にはいくつかの欠点もあります。 d) モデルがある場合、コードのすべての行をそのモデルから取得する必要があります。また、外部ライブラリをプロジェクトに含めるのは難しい場合があります。したがって、システムが外部コンポーネントに基づいているという事実を受け入れるか、車輪を再発明してモデルに組み込むかのいずれかです。

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

于 2009-06-24T22:44:27.830 に答える
2

バズ。

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

これがJavaで行われたかどうかはわかりません。Smalltalk については、Seaside で使用されているMagritteを参照してください。

于 2008-11-10T10:00:33.240 に答える
1

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

確かに、コードは「モデル」ですが、より高いレベルのモデルを DSL に取り込むことで、同じ意図をより簡潔に表現できます。重要なのは、生成されたコードを個別に変更できるようにするのではなく、常にモデルからコードを生成することです。

市販のジェネレーターを購入することに満足できない場合に、独自のジェネレーターを構築する方法を説明するために、利用可能なツールがたくさんあり、ケース スタディを含む多くの公開資料があります。おそらく、これにより、汎用プログラミング言語で作業するよりも多くの制御が可能になります。

于 2009-05-04T14:33:20.050 に答える
1

好ましいと思います。それが、MVC ではなく MVC-ARSに関するこの質問で私が暗示しようとしていたことです。ARS (アクション/表現/状態) は設計上モデル内に含まれており、コントローラーまたはビューのオーバーロードを防ぎます。

于 2008-09-30T23:00:13.077 に答える
0

確かに良さそうに聞こえますが、実際に機能する方法で実装されているのをまだ見ていません。

私は次のように考えています。コードはモデルです。そうすれば、モデルとコードは常に最新の状態になります:-)

于 2008-09-16T09:44:24.080 に答える
0

上で述べたように、MDA を理解するのに役立つ本を 2 冊紹介するだけでも、MDA は幅広いテーマです。

  • MDA Distilled - モデル駆動型アーキテクチャの原則。(メラー)
  • 実際の MDA: モデル駆動型アーキテクチャによるビジネス上の問題の解決 (Guttman)

ケーススタディは退屈なので、アイデアを得るために Guttman をすべて読む必要はありませんが、イントロは楽しく読めました。

于 2008-11-10T03:47:03.820 に答える
-1

モデル ビュー マッピングは生成されたコードによって処理され、関数フックはイベント レスポンダーとして提供されるため、MDA では通常、サーバー側レイヤー内のビジネス ルールの統合が困難になります。

それでも、Forté (または UDS、現在は死んでいます) + Express ほど強力な MDA ツールは見たことがありません。Forté 機能に加えて、独立したサービス層 (ActiveRecord または EntityTransactionManager パターンなど) を実現するためのより優れたパターンを備えた MDA は、どのプラットフォームでもキラー アプリになると思います。

3 層 MDA アプローチを目指した実際のアプリケーションの問題は、それらをセットアップして特定の要件に適応させることが非常に難しいことです。ABAP と SAP のレートを考えてみてください

于 2008-09-30T22:51:55.780 に答える