モデル駆動型開発のためのツール（ベストプラクティス？）

StackOverflow https://stackoverflow.com/questions/262279

質問

モデル駆動型ソフトウェア開発。

私が理解しているように、設計の抽象化レベルを上げて、ソフトウェアが実行しようとするドメインをよりよく反映します。

この方法論を機能させるには、ドメインの専門家（顧客）と開発者の間のコミュニケーションが不可欠です。私が知りたいのは、MDSDの最初の推進に役立つツールスイートまたはベストプラクティスのセットがあるかどうかです。ドメインが具体化されたら、そのモデルをORM（またはその他）にマッピングすることについてはどうでしょうか。

MDSDとDSLの領域に飛び込んでいるので、建設的なアイデアやコメントが認められます。

役に立ちましたか？

解決

Microsoftプラットフォームで開発している場合は、Osloも確認してください。ここに概要があります： http：// www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx

Chris Sellからのリンクは以下のとおりです。 http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic= 2197

ドメイン駆動設計をモデル駆動開発と同一視する準備がまだできていません。

モデルドリブンアーキテクチャ（OMG MDA）についても、視点を確認してください。

Model-driven-anythingの大きな問題は、モデルから実装を導き出す専門知識がどこから来たのか、そしてどのレベルのメンテナンス（およびデバッグ）が行われるかに関係しています。利用可能な本の私のテストは、パイプラインをどのように理解できるようにするか、モデリングから展開、そして元に戻すまでのパスをどれだけうまく理解できるかです。

他のヒント

.netでプログラミングしている場合は、「ドメイン駆動設計とパターンを適用する」をお読みください。ジミー・ニールソン。また、ORM（NHibernate）、SOA、および依存性注入に関するセクションもあります。

いずれの場合でも、「ドメイン駆動設計」をご覧ください。エリック・エヴァンス。これは、ドメイン駆動設計のパターンとベストプラクティスに関する貴重な情報を見つけることができるクラシックです

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

MDSDはまだコード生成にあまりにも関連していると思います。

コード生成は、コードに多くのノイズが含まれていたり、繰り返しが非常に多い場合にのみ役立ちます。言い換えれば、コードが主に本質的な複雑さに焦点を合わせることができず、偶然の複雑さに汚染されている場合。

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

これらの新しいプラットフォーム/フレームワークは、MDSDムーブメントの帆から多くの風を取り去ります。

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

これをもっと単純化できるとは思わない。また、ボックスとラインを使用したグラフィカルな表現は単純化されず、それ以上の利便性は提供されません（レイアウト、リファクタリング、検索、差分について考えてください...）。

MDDは非常に複雑な場合も比較的単純な場合もあります。

さまざまなモデル（UMLなど）からコード化およびラウンドトリップエンジニアリングなどへの変換を自動化する場合は、かなり洗練されたツールを入手できます。

または

一方向（モデルからコード）変換を使用して、モデルを描画し、コードを多少とも手作業で構築できます。

最初にモデルを構築するという考え方は、確立されたベストプラクティスです。多くの場合、「デザイン」と呼ばれます。設計と仕様を混同するときに問題が発生します。構築されるもののモデルはプログラミング仕様ではありません。これは、正確性の評価、テストケースの定義、仕様の記述などに使用できる抽象化です。

すべてをモデル化する必要はありません。特定の実装とは無関係に、データモデルを持つことでMDDを開始できます。

  1. UMLを使用してモデルを描画します。

  2. UMLをクラス定義に変換します。

  3. ORMレイヤー（またはODBMS）を使用して、モデルを何らかの種類のストレージにマッピングします。

これ以上のものは必要ありません。あなたがする必要があるのは、他の多くの問題に取り組む前にモデルを正しく取得することに集中することです。

問題は通常、ソフトウェア開発中に発生するあらゆる種類の早期最適化から発生します。 RDBMSの物理設計に早くから飛躍します。 Webページの設計に早期に跳躍し、それを使用してデータモデルを駆動します。サーバーアーキテクチャの定義とストレージの割り当てに早くから跳躍します。

Markus VoelterのMDSDベストプラクティスに関する次の優れた論文を読む必要があります。 http： //www.jot.fm/issues/issue_2009_09/column6.pdf

MDSD / DSLオプションに関して、EMFエコシステム（ https://www.eclipse.org / modeling / emf / ）は多くの便利な構成要素を提供します：

  • メタモデルとモデルエディター（EMF）を実装する
  • モデルエディター（EMF、Sirius、Xtext ...）を実装します
  • コラボレーションとスケーラビリティ（EMFトランザクション、CDO）を管理します
  • 実装モデル検証ルール（EMF-検証）
  • コードジェネレーターの実装（Acceleo、Xtend / Xpand、Mwe ...）
  • ドキュメントジェネレーター（pxDoc、m2doc ...）を実装します

ツールへの投資を削減する興味深いオプションとして、拡張可能なUMLモデラーを使用し、再利用されたモデラーの上に独自のUMLプロファイルとカスタムツールを定義することもできます（UMLモデラーがベースの場合は、前のリストでも十分です） UML2 / EMF実装で）。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top