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

Question

私は約350人の従業員を抱える会社で働いており、成長の途上にあります。現在のコードベースはあまりよく構造化されておらず、すぐに改善する方法（オブジェクトを名前空間に整理したり、関心の分離など）と、モデル駆動型アーキテクチャのアプローチに移行する方法の両方を検討しています。このアプローチでは、最初にすべてをumlでモデル化して設計します。 、次にそのモデルからコードを生成します。私たちはSparxSystemsEnterprise Architect（EA）（UML 2.0対応）をよく調べており、VS 2010のツールも検討しています。他にもツールがあることは知っていますが（Rational XDEが1つです）、実際にはそうではありません。この時点で、ライセンスごとに$1500以上を費やすことができると思います。

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

Answer 1

3 mlocのロジスティクスプランナーシステムを使用してこれを1回実行しましたが、うまく機能しました。しかし、UMLでは不十分であることに早くから気づきました。仕様に必要な詳細レベルを把握するのは、単純に鈍すぎました。最善の方法は、実際に擬似コードを使用することでした（とにかく誰もがアイデアを伝えるためにそれを使用していました）！それが実現された方法です。UMLを使用することは、明快さから一歩離れたように感じました。

アイデアが解決策に絞り込まれ始めたとき、擬似コード（およびユースケースなど）の変更を追跡するためにバージョン管理システムが採用されました。そのため、グループの全員が変更に従いました。少しずつの部分は、ドキュメントや動機や議論への参照とともに実際のコードに翻訳されました。

結局、モデルからコードへの移行は非常にスムーズでした。本当に素晴らしい部分は、imho、環境を切り替えることなく元の疑似コードさえ見ることができるvcsの使用でした。

Answer 2

私はモデル駆動型ソフトウェア開発についての学士論文を書きましたが、あなたの会社が意図していることを行うために良いアプローチを使用することが本当に重要であることを警告したいと思います。生成されたコードを直接編集する、1回しか生成できない、手動で編集されたコードは生成後に消去されるため、ドメイン分析を行って適切なメタモデルを作成し、適切に使用するなど、問題が発生する可能性のあることが多くあります。コード生成フレームワーク...私を間違って理解しないでください。MDSDは素晴らしいと思いますが、それをどのように行うか注意してください。オリジナルのMDAとそれに関する本は、コストがかかりすぎて脆弱すぎる、本当に悪いアプローチを示唆しています。voelter.deのWebサイトをご覧になることをお勧めします。このサイトでは、この分野で非常に経験豊富なコンサルタントであるMarkus Voelterの論文、プレゼンテーション、ポッドキャストを見つけることができます。

Answer 3

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

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

Answer 4

現在のコードベースはあまりよく構造化されておらず、すぐに改善する方法と、モデル駆動型アーキテクチャのアプローチに移行することの両方を検討しています。最初にumlを使用してすべてをモデル化および設計し、次にそのモデルからコードを生成します。

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

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

次に、MDAに関しては、ある程度の規律が必要であることに注意することが重要です。チームによっては、最初の部分は、MDAを導入する次のステップを準備する方法で、最初にそれに取り組むことをお勧めします。私はあなたが「カウボーイ」プロセスを持っていると言っているので、それはおそらく人々が彼らが望むことを何でもすることに慣れていることを意味します-それはMDAにとってはダメです。

次に、MDA自体の紹介があります。MDAを実行するにはさまざまな方法があります（ここではこれについては詳しく説明しません）が、それを実行するための依然として主な方法は、いわゆるラウンドトリップエンジニアリングです。その場合の最大の問題は、モデルとソースの同期を維持することです。

（私の考えでは、MDAは、モデルを複数のプロジェクトで再利用できる場合にのみ、投資収益率を向上させます。つまり、何度も行うことを特定し、問題について十分に明確な見解を持っている必要があります。プロジェクト全体で再利用できる十分に完全なモデルと変換を作成できる。各プロジェクトが完全に異なる場合、MDAが機能するとは思わない。モデルを正しくするために費やされる時間や変換などは、コードとドキュメントのみを操作します。）

もう1つのアプローチは、MDAを完全に実行するのではなく（モデルからコードを生成しない）、モデリングや設計の問題について人々の意識を高めることです（UMLなど）。このようにして、ラウンドトリップの問題に直面することはありませんが、ソフトウェア開発プロセスの成熟度を向上させることができます。