モデル主導のアーキテクチャアプローチに移行することの利点とリスクは何ですか？

Question

私は約350人の従業員を抱える会社で働いており、私たちは成長の過程にあります。現在のコードベースはあまりうまく構造化されておらず、すぐにそれを改善する方法（名前空間にオブジェクトを整理し、懸念を分離するなど）とモデル駆動型のアーキテクチャアプローチに移動する方法を検討しています。 、そのモデルからコードを生成します。 Sparx Systems Enterprise Architect（EA）（UML 2.0対応）をよく見てきました。また、2010年のVSのツールも検討しています。この時点でライセンスごとに1500ドル以上を費やすことができると思います。

私は、どのツールが他のツールよりも優れているかについての答えを探していませんが、カウボーイのコーディング環境（つまり、計画とデザインがほとんどなく、ジャンプしてコーディングを開始するだけ）からモデル駆動型のアーキテクチャに移行する経験については探しています。振り返ってみると、それはあなたの組織に役立ちましたか？痛みは何ですか？リスクは何ですか？利点は何ですか？

Answer 1

現在のコードベースはあまりうまく構造化されておらず、すぐにそれを改善する方法[...]とモデル駆動型のアーキテクチャアプローチに移行する方法を検討しています。

第一に、あなたとあなたの会社があなたのソフトウェア開発プロセスにいくつかの欠陥があること、そしてあることがあることを認識していることは素晴らしいことです 改善する意欲.

しかし、目の前にはかなりの仕事があり、さまざまな方向に改善する多くのことがあるようです。私の最初のアドバイスは、変えようとしないことです すべての すぐに。人々は一般に変化に消極的であり、誰もが新しい変化を消化するためにある程度の時間を必要とします。また、設定する必要があるものについて共通の理解を作成することも非常に重要です。この一般的な理解は、1日で作成されません。このような変更にはaが必要です 中期または長期的なコミットメント.

それから、MDAに関しては、それがいくつかを必要としていることに気付くことが重要です 規律. 。チームに応じて、最初の部分は、次のステップを準備する方法で最初に作業する必要があります。これはMDAを導入することです。あなたは「カウボーイ」プロセスを持っていると言っているので、人々はおそらく彼らが望むことを何でもするために慣れていることを意味します - それはMDAにとってノーゴーです。

その後、MDA自体の導入が登場します。 MDAを行うにはさまざまな方法があります（ここではTHSATについて拡張しません）が、それを行うためのまだ主要な方法はいわゆるものです 往復エンジニアリング. 。最大の問題は、モデルとソースを同期させることです。

（私の見解は、MDAがモデルをいくつかのプロジェクトに再利用できる場合にのみ、投資収益率に積極的につながるということです。これは、あなたが何度も何度も行っていることを特定し、問題について十分な明確な見解を持っている必要があることを意味します。プロジェクト全体で再利用できる十分に完全なモデルと変換を作成できます。各プロジェクトが完全に異なる場合、MDAが機能するとは思いません。コードとドキュメントでのみ作業しています。）

別のAppraochは、MDAを完全に行わないことです - モデルからコードを生成するのではなく、Modeling and Designの問題についての人々の認識を高めることです。これにより、往復の問題に直面することはありませんが、ソフトウェア開発プロセスの成熟度を改善します。

Answer 2

3 MLOCロジスティクスプランナーシステムで一度それを行いましたが、うまくいきました。しかし、私たちは早い段階でUMLが十分ではないことに気付きました。仕様に必要な詳細レベルをキャプチャするには、単に鈍感でした。最良の方法は、実際に擬似コードを使用することでした（とにかく誰もがアイデアを伝えるためにそれを使用していました）！それが実現の方法です。 UMLを使用すると、明確さから一歩離れたように感じました。

アイデアがソリューションに絞り込まれ始めたため、擬似コード（およびユースケースなど）の変更を追跡するためにバージョン制御システムが採用されました。そのため、グループの全員が変更に従いました。ビットバイビットパーツは、ドキュメントと動機とディスカッションへの参照に沿って実際のコードに翻訳されました。

最終的に、モデルからコードへのトレジションは非常にスムーズでした。本当に素晴らしいのは、環境を切り替えることなく元の擬似コードさえも見ることができる使用VCSです。

Answer 3

私はモデル駆動型ソフトウェア開発について学士論文を書きましたが、あなたに警告したいだけです。 Generaled Codeが直接編集され、1回しか生成できないように、間違っている可能性のあるものがたくさんあります。コード生成フレームワーク...私が間違っていることを理解してはいけません。MDSDは素晴らしいと思いますが、どうすればよいか気をつけてください。オリジナルのMDAとそれに関する本は、非常に悪いアプローチを示唆しています。 voelter.deのウェブサイトを見ることをお勧めします。ここでは、その地域で非常に経験豊富なコンサルタントであるMarkus Voelterの論文、プレゼンテーション、ポッドキャストを見つけることができます。

Answer 4

私にとって、重要な側面は時々実用的であることです。モデリングはブールアクティビティであってはなりません（モデルでもモデルもしないものでもありません）。モデリングレベル/精度をプロジェクトの特性に適応させることができるはずです（たとえば、アジャイルモデリングに取り組んでいる人々が行うものを参照）。モデリングが少なすぎるか、あまりにも多くのモデリングが問題になる可能性があります（メリットが少なすぎる可能性があります。特に、移行を開始している場合、または必要なツールがない場合は、会社にあまりにも過剰になる可能性があります）

私のポータル/ブログで（http://modeling-languages.com）モデリングの利点や、モデリングの使用方法についてよく説明します。あなたはそれが面白いと思うかもしれません