2

私は Java ソフトウェア開発者/アーキテクトであり、UML が好きです。

Javaで生成されたコードも嫌いだと言っています。

アプリケーションのスケルトンを生成しようとする価値はありません。

  • 空のクラスを作成するのはとても簡単で、それを行うためのツールは必要ありません
  • また、生成されたコードが再利用できないため、生成されたコードを再利用できません

私にとってのジレンマは、要件が急速に変化したため、新しい要求を既存のコードにすぐに実装できるようにする必要があることです。

私の問題は、モデルからコードを生成し、生成されたコードベース内で手動で開発すると、変更が消去されるため、モデルを使用してコードを再度生成できないことです。

変更を前後にコピー/貼り付けすることを除いて。それはあまりにも少ない結果のための途方もない努力です。そのため、私は MDD を使用していませんが、UML を多く使用しています。

MDD コード生成のないプロジェクトで UML は成功するでしょうか?

この質問をするのは、IBM RSA で完全な MDD プロセスを導入したい新しい上司がいて、現在はコードとモデルのライブ同期または Omondo とのマージを希望しているためです。

  • 稼働中の実績のあるシステムを変更する理由は何ですか?
  • モデルからコードを体系的に生成するのに、コード内で直接コードを生成し、後でモデルとマージするのはなぜですか?
  • Java アノテーションを取得し、休止状態でそれらを使用してデータベースを生成するためにステレオタイプを追加できるのに、デプロイすることさえできないがらくたデータベース コード生成を取得するのはなぜですか?

上司の変更の理由の 1 つは、HTML 形式のより優れたプロジェクト ドキュメントを入手することです。私はこれを非常に疑っており、彼は配信をより細かく制御しようとしており、他に何を発明すればよいかを知りません!

その他の議論の理由:

  • 大規模で安定した会社の製品を使用してください。
  • 他の言語で展開できる完全なモデルを用意します。
    （これが私にとってMDDがばかげている理由です。モデルからだけでどのプラットフォーム、どのサーバー、どのデータベースにも展開することは不可能だからです。では、なぜ私の時間を無駄にするのですか？）

次の会議で戻ってきて、今日の働き方を再編成したいと考えているこの愚かな新しい MDD ファンをぶちのめすために、いくつかの議論をお願いします!

4

3 に答える 3

2

あなたの投稿には答えがあると思います。

MDD には 2 つの根本的な問題があります。

  1. 問題全体を把握するには表現力が不十分な入力 (モデリング言語)。結果: 別の言語 (コード) で仕様を完成させる必要があります。
  2. ジェネレーター (つまり、モデルをコードに変換するルール) は、一般的に不完全であるか、開発チームが変更できるように開かれていないか、品質の低いコードを生成します。

これら 2 つのことを一緒にすると、あなたが言及した恐ろしい混乱が発生します。結果: 手書きのコードと低品質の生成コードをつなぎ合わせようとする。結果：美しくない。

でも。私が抗 MDD であると上から推測しないでください。私はそうではありません - 実際にはその逆です。ただし、ツールとプロセスは、上記の 2 つの基本的な問題に対処する必要があります。

私は/非常に/少数に出くわしました。私は数年前に RSA を使用していましたが、間違いなくその 1 つではありませんでした。（ただし、改善するまでの時間があったため、現在は存在する可能性があります）。

簡単な「温度チェック」の質問は、ツールが完全なアクション言語を提供しているかどうかを尋ねることです。そうでない場合は、問題 (1) に違反します。それが失敗した場合、チャンスはあなたが苦しんでいるということです.

上司が本当に望んでいるのは優れた HTML ドキュメントだけである場合は、UMLGraph または apivizをビルドに統合するだけです。

特定の質問に答えるには：

UML は MDD なしで正常に使用できますか? はい。一般的には次の 2 つの方法があります。

  1. 問題や解決策を見つけながらホワイトボードにスケッチするための非公式または半公式の表記として (Martin Fowler がUML を Sketchと呼んでいるもの)
  2. ビルド プロセスの一部としてコードから自動生成されたドキュメントとして。

非生産的な時間を費やすことになるのは、コードに直接リンクしていない正式な UML ダイアグラムを (多くの場合、高価なツールを使用して) 作成することです。

h番目。

于 2011-01-29T23:39:23.357 に答える
1

生成を制御できない場合は、おそらく間違ったツールを使用しています。

生成するもの (スケルトンまたはフレームワーク固有のコード) もツールに依存します。独自のテンプレートを作成できるツールを使用します。

ラウンドトリップ エンジニアリングが機能すると仮定するのは誤りです。詳細度の低いモデルをより詳細なコードに変換してから、情報を失うことなく元に戻すことはできません。これを解決する 1 つの方法は、コードと同じレベルの詳細をモデルに持たせることですが、これは素晴らしいことではありません。

より良いアプローチは、生成されたコードと手動で記述されたコードを結合するためのいくつかの優れたプラクティスと組み合わせたモデルからの一方向の生成を使用することです。

手動で記述されたコードに保護領域を使用できます。

  • テンプレートの場所で指定します-たとえば、再生成時に上書きされるべきではないメソッド本体

またはジェネレーションギャップパターン：

  • 具象クラスのスケルトンを使用して抽象クラスとコードを生成し、手動で完成させます)。

これにアプローチするもう 1 つの方法があります。完全なコード生成です。

モデルを使用したコーディングの悪い習慣に似ているように見えるかもしれませんが、要点は、特定の種類のアプリケーション (Web アプリ、組み込みアプリ) の生成に特化することです。生成するものは、基本的にフレームワーク固有のコードであり、多くの場合、モデルを使用して表現および維持できます。

モデリングは図だけでなく、テキスト DSL も使用できることを忘れないでください。

あなたの質問に対して - UML はもともと MDD 用に開発されたものではありません (多くの MDD 実践者は UML をまったく使用していません...)。

上司と RSA に関して言えば、上司が本当に必要としているものと望んでいるものを見つけ出し、より良いツールやプラクティスを提供するようにしてください。

他の回答で述べたように、ドキュメント用のツールはたくさんあります。

于 2011-01-30T01:31:56.503 に答える
0

MDD を使用すると、設計の変更がより安価になることが期待されます。要件が変更された場合、アプローチでは UML ベースのドキュメントとコードを更新する必要があります。ここで、コードが自動的に生成される場合、コードへの変更はモデルへの変更に自動的に従う必要があり、手動で行う必要はありません (少なくとも、新しいものを追加したり、ビジネス ロジックを変更する必要があります)。

MDD が機能すると仮定すると (ええ、そうです;)、モデル (ドキュメントと設計のため) とコードを維持するための 2 倍のコストを正当化できますか?

あなたに有利な議論の 1 つは、プロジェクトが大きすぎない場合 (それが何を意味するにせよ)、すべてのオーバーヘッドを負担する価値がないということです。

于 2011-01-29T15:59:41.987 に答える