大学にいたとき、コード開発におけるUMLの利点とその将来について教育を受けました。

しかし、業界での経験から、ERダイアグラム、クラスダイアグラム、状態ダイアグラムからワークフローダイアグラムに至るまで、ダイアグラムを使用している間は、すべてコミュニケーション用であることがわかりました。

つまり、ダイアグラムからコードを自動的に生成したことは一度もありません。また、通信の観点から、通常はダイアグラムをできるだけシンプルで理解しやすいものにしようとしています。

しかし、VisioとEnterprise Architectを見ると、多くの異なる種類のグラフ、図形、プロパティオブジェクトがあり、そのほとんどは使用していません。

UMLを使用して、コードやデータベースの生成など、より洗練された処理を実行しますか？

はい、UML CASEツールは90年代の注目アイテムの1つでしたが、その後配信に失敗しました。

このための基本的な理由は、UML（またはほとんどの他の種類の）問題を理解するために助けを図及び/またはプログラムは、それが唯一の図である限り解決することで、実装の詳細抽象化実際のコードのを。したがって、（些細なコードではない）理解しやすい図は、必要な詳細が欠けているため、コード生成には本質的に役に立ちません。逆に、コード生成に直接使用できる図は、コード自体よりもプログラムを理解するのにあまり役立ちません。実稼働コードからリバースエンジニアリングされたUMLクラス図を見たことがあるなら、おそらく私が言っていることを知っているでしょう。

私が知っているこれの唯一の潜在的な例外は、エンティティ関係図です。これは、コード自体を含まず、データの一部（およびその名前が示すように）の関係のみを含みます。しかし、私は実際のコード生成のためのUMLダイアグラムの任意の種類を使用するには成功した試みのことを聞いたことがありません[更新]のように証言し、ORMのような特別な目的のツール/場所以外、 -すなわち複数のクラスのスケルトンとゲッター/セッターのような些細なコードよりもを- Doc Brown以下[/ Update]、これは偶然ではないと思います。

私は個人的にUMLを嫌いではありません-UML図はコミュニケーションの素晴らしいツールになると思います-設計の議論中にあなたの意図やアイデアを示したり、アプリのアーキテクチャを視覚化したりします。しかし、これを維持し、得意でないものに使用しようとしないことが最善です。

だから、私が大学にいたとき（少し前）、UMLが未来であり、UMLがプログラミングを置き換え、ダイアグラムなどからコードを生成するだけだと言われました。

彼らは間違っていました。それは、人々がスピーチを放棄して洞窟絵画に戻る頃に起こります。

現実世界の問題、およびそれらを解決するプログラムには、削減できない本質的な複雑さがあります。実用的なプログラムを作成するには、その複雑さをキャプチャして、何らかの実行可能言語で表現する必要があります。問題は、図式プログラミング言語がテキストプログラミング言語よりも効果的かどうかです。私たちは約30年にわたって図式プログラミングを実験してきましたが、これまでのところ、証拠はテキストプログラミングを圧倒的に支持しています。私は、ダイアグラムからのコード生成によって作成された重要なアプリケーションを知りません。

いや

凡例は、以下の記述が失敗したという仮定に基づいています。

class ClassName extends SomeThing
{

}

...それは難しく、自動化が必要です。

あなたはまだ時折信者、または信者の群衆を見つけるかもしれません。
しかし、それは宗教やカルトに当てはまる方法です。

そこに行って、それがあまりにも有用であることがわかりませんでした。

一般に、それらからいくつかのコードを生成するのに十分な特定の図、主にクラス図は、実際にプログラムを理解する方法をあまり追加せず、ユースケースや概要レベルのアクティビティなどの概要図からコードを生成することはできませんドキュメンテーションにとって重要です。理解に役立ち、コードを生成できるダイアグラムの1つにステートチャートがあります。これは、本当にステートマシンが必要なときに役立ちます。ただし、これらは本質的にエラーが発生しやすいため、通常はこれらを避けるようにしてください。

あるプロジェクトでは、UMLモデラー（Rhapsody）でコードを設計し、そこから生成する必要がありました。それは一種の働きで、おそらくヘッダー（C ++）とプロトタイプを手で入力するよりも非常に簡単だったでしょう。これら2つの一貫性を自動的に維持する機能は、いくらか便利でした。

ステートマシンのスケルトンを除き、図では実際に表現できないため、メソッドの本体は手動で入力する必要がありました。

一方、それはかなり複雑であるため、多くの余分なことを学ぶ必要があり、さらに重要なことに、マージするのが苦痛でした。マージはテキストファイルについてよく研究されており、それらと連携しますが、ダイアグラムに変更をマージする簡単な方法をまだ誰も発明していません。Rhapsodyは、生成されたコード内の情報の一部を実際に保持し、それを解析します。そのため、完全に使用不可能ではありませんでしたが、依然として深刻な問題でした。

コード（およびシステム全体）をUMLモデルから直接生成することは確かに可能ですが、この方法で使用されていることは一度もありません。

私の経験では、ほとんどの企業はそれを要件のコミュニケーションツール、または「ダイアグラムを描くためのMSペイント」として使用しているようです。

重要な違いの1つは、ほとんどのUMLモデリングツールを使用して、システムの単一モデルを構築できることです。たとえば、VisioはUMLがどのように機能するかをかなりよく理解しており、図に直接関係しないものを追加できます。実際の図は、モデルの各部分の異なる視点にすぎず、システムのさまざまな側面を強調できます。

すべて（モデリング図）はコミュニケーションを目的としています

モデリングには、ソフトウェア開発プロセスで4つの重要な用途があります。

1. 統合設計ツール

2. コミュニケーションツール

3. ソフトウェア生成の支援

4. 実際の問題の複雑さを軽減する方法（上記の@kevin clineの応答からこれを学びました）

5. モデリングのプロセスにより、一部の設計者はコーディング中に考慮されない詳細について考えるようになります（逆も同様です）。設計時のモデリングを使用すると、言語のメソッドまたはクラスをコーディングするよりも大きな全体像を考慮することができます。

私の意見では、モデリングはデータベースの構築（ER図）、プロセスフローの理解（アクティビティ図）、ユーザーとシステムの相互作用の理解（ユースケース図）に不可欠です。

UMLを使用して、コードやデータベースの生成など、より洗練された処理を実行しますか？

はい、そうです。ERD（UMLダイアグラムではない）およびクラスダイアグラムを使用して（ツールの機能に応じて）、以下を生成できます。

1-データ定義言語（DDL）

2-好みの言語でのCRUDおよびクラス図のストアドプロシージャ（ORMツールがこれについてさらに行うため、あまり有用ではありません）

モデリングツールの最も価値のある機能は次のとおりです。

1-モデルの整合性を維持する機能。変更を行うと、モデルに伝播します

2-使用済みの質問に回答する機能（モデルで使用される「アカウント」はどこですか？）

3-同時ユーザーがモデルで作業できるようにする機能

4-グラフィカル表現内で検索

5-印刷制御

6-一度にレイヤーに集中できるように、レイヤー化（ダイアグラム要素をレイヤーに整理）

7-いくつかのデータベースシステムのデータベースコード生成

8-モデル検証（整合性、欠落キー、サイクルなどをチェックします）

したがって、モデリングツール、特に優れたツールは、ペイントよりもはるかに多くのことを行います。

ソフトウェアアーキテクトを使用して、高レベルの設計を行い、スタッフのより複雑なコンポーネントの相互作用のいくつかを文書化します。ダイアグラムからアプリのスケルトンを生成することもありますが、それが完了したら、両方を個別に維持し、完了後にコードをリバースエンジニアリングしてダイアグラムに戻そうとはしません。以前は、Rational XDEという名前のツールを使用していましたが、これは小さなプログラムではかなりうまく機能していましたが、Swingイベントハンドラーの追加を開始するか、Strutsを使用しようとすると失われます。

人々がUMLで書かない理由の大部分は、UMLですべてを完全に指定してからダイアグラムからコードを生成するために、より多くの作業が必要だからだと思います。US DoDがOMGと協力して、正しいと検証された図から「実証済み」コードを生成するツールを開発していることは知っていますが、私の印象では、実際のコードよりも桁違いに多くのメタデータを取得します。これはおそらく良いことです（結局ドキュメントです）が、メタデータの生成はコードを書くよりも速くないため、比例して多くの時間を費やすことになります。

UML自体は表記システムであるため、コミュニケーションと文書化の原因となります。UMLモデルからコードを生成することはまれですが、そうする人もいます。Rhapsodyユーザーは、Roseよりも頻繁にそれを行います。難しい部分は、モデルとコードの同期を保つことです。実際のプロジェクトのほとんどでは、コストが高すぎます。

私の最新のプロジェクトでは、UML-Lab（https://www.uml-lab.com）を使用しています。これは、モデルのリバースエンジニアリングも可能にする優れたツールです。このツールは、Javaコードを生成し、かなり正確なJPAアノテーションも生成します。

それへの挑戦はチームで働くときです。モデルは静的であり、単一のリソース内にあるため、複数の開発者の変更との同期を維持するのが少し難しくなります。1か月間利用できる試用版があります。これは、調査している場合に他の人と調べたり比較したりするのに適した時間です。

コード生成とともにオブジェクトモデリングとデータモデリングをワンショットで実行する製品を見たのは初めてです。

それ以外の場合、過去のプロジェクトでは、不正確または詳細すぎる陳腐なモデルを見てきました。

過去のプロジェクトでは、リバースエンジニアリングによってダイアグラムを生成することがありました。ほとんどの場合、図は散らかっていて、手動ですべてのノイズをフィルタリングして描画することを好みました。

UMLを使用してコードを生成できると思います。ビジネスロジックは標準ではなく、アプリケーションごとに異なるため、ビジネスロジックではありません。クラス図とER図は、インターフェース、クラス、休止状態エンティティ、基本的なdaoメソッドなどの生成に使用できます。ファサード実装、データ型コンバーター（オブジェクトを転送するエンティティなど）などの他の定型コードも、オブジェクト図を使用して生成できます。 。

また、前のコメントで述べたように、データベーススキーマ、DDLスクリプトなどはモデルを使用して生成できます。

OAW、およびEnterprise Architectなどのモデリングツールを使用して、強力なコードジェネレーターを作成できます。これは、構成ファイル、ステレオタイプとタグ付き値を使用したファクトリコードの生成にも役立ちます。

私はまだビジネスオブジェクトのようなツールを備えたビジネスインテリジェンスがすべての企業情報を分析して活用できる理由を理解していませんが、技術レベルではまだコードレベルでのみ、またはUMLで抽象的なレベルで作業しています!!

問題はUMLではなく、UMLとMOF間のモデル変換、およびテンプレートを使用したクラス図またはxmiからのコード生成です。UMLは現実世界の抽象的なビューを提供すると言われているため、本当に重要なものだけを見ることができます。UMLダイアグラムが現実世界の単なるビューである場合に、正確なコードを生成する方法を述べましたか？それは不可能であるため、モデルからコードを生成するモデル駆動型開発は失敗しました。

解決策は、現実の世界とすべてのプロジェクトコードを単一のUMLモデルにマッピングするように変換することです。単一のモデルとプロジェクトの完全なロジックを使用すると、毎回コードからではなくモデルからビューを生成できます。Java / Jeeテクノロジー内でOmondoによって行われた勇気あるイニシアチブがあります。コンセプトは、コードとORMを直接使用したライブ同期MOFとUMLです。UMLダイアグラムは、プロジェクト全体をマッピングしているモデルの単なる高レベルのビューになりました。プロジェクトの理解を深めるために、100個のビューを作成したり、100個のメモを追加したりできます。コードは、要素が変更または作成された場合にのみ生成されます。MOFとUMLの間の従来の変換ブリッジなしで、Java IDがUML IDにマップされる素晴らしいテクノロジー。

また、素晴らしいことは、UMLレベルでドメインをモデル化し、コードでORM注釈を直接取得できることです。したがって、Hibernateを使用すると、データベースを作成、消去、作成、展開な​​どを永続的な継続的インテグレーションで行うことができますUMLは、すべてのアーキテクチャの一部であり、プロジェクトのアーキテクチャ自体ではありません。

コードとライブ同期する場合、UMLにハイレベルビューアーとしてがっかりすることはありませんでしたが、モデル駆動型開発テンプレートのコード生成でMDAを使用する従来の方法では絶対に破壊されました。モデルからのコード生成は、ワードドキュメントからのHTMLページのようなものです。生成された後、どのように変更しますか？更新するのは不可能であり、コードを一から書くよりもコードをきれいにするのに多くの時間を費やします！