コードは一般にUMLから生成されますか？
したがって、私は大学にいたときに、UMLの利点とコード開発におけるその将来について教育を受けました。
しかし、業界での経験から、ERダイアグラム、クラスダイアグラム、ステートダイアグラムからワークフローダイアグラムに至るまで、ダイアグラムはすべて使用しているものの、すべてコミュニケーションの目的であることがわかりました。
つまり、ダイアグラムからコードを自動的に生成したことがなく、コミュニケーションの観点から、通常はダイアグラムをできるだけシンプルで理解しやすいものにするよう努めています。
しかし、VisioとEnterprise Architectを見ると、さまざまな種類のグラフ、図形、プロパティオブジェクトがあり、それらのほとんどは使用していません。
人々はUMLを使用して、コードやデータベースの生成など、より高度なことをしていますか？
はい、UML CASEツールは90年代の人気アイテムの1つでしたが、提供できませんでした。
これの根本的な理由は、UML（または他のほとんどの種類の）ダイアグラムが問題を理解するのに役立つこと、および/またはダイアグラムが実際のコードの実装の詳細を抽象化するである限り、それを解決するプログラムであることです。したがって、（重要でないコードの場合）理解しやすい図は本質的にコード生成には役に立ちません必要な詳細がないためです。逆も同様ですコード生成に直接使用できる図は、プログラムを理解するのにあまり役立ちませんコード自体よりも優れています。プロダクションコードからリバースエンジニアリングされたUMLクラス図を見たことがある場合は、おそらく私が何を意味しているのかご存知でしょう。
私が知っている唯一の潜在的な例外は、エンティティ関係図であり、これはコード自体を含まず、（名前が示すように）データの一部とそれらの関係のみを含みます。しかし、実際のコード生成にあらゆる種類のUMLダイアグラムを使用する試みが成功したことは聞いたことがありません[Update]-つまり、クラスのスケルトンとゲッター/セッターのような些細なコード以上-専用ツールを除く以下のDoc Brownが証言しているように、ORMのような/ areas [/ Update]、そしてこれは偶然ではないと思います。
私は個人的にUMLを嫌いではありませんMLダイアグラムはコミュニケーションの優れたツールになる可能性があります-デザインのディスカッション中に意図やアイデアを示したり、アプリのアーキテクチャを視覚化したりします。しかし、彼らをこれに留めておくことが最善であり、彼らが得意ではないものにそれらを使用しようとしないでください。
それで、私が大学にいたとき（少し前のことです）、UMLが未来であると言われました。UMLはプログラミングに取って代わり、図などからコードを生成するだけです。
彼らは間違っていました。それは人々がスピーチを放棄して洞窟壁画に戻る頃に起こります。
現実の問題とそれを解決するプログラムは、本質的に複雑であり、減らすことはできません。動作するプログラムを作成するには、その複雑さをキャプチャして、いくつかの実行可能言語で表現する必要があります。問題は、図式プログラミング言語がテキストプログラミング言語よりも効果的であるかどうかです。私たちは約30年間図式プログラミングを実験してきましたが、これまでのところ、証拠は圧倒的にテキストプログラミングを支持しています。ダイアグラムからのコード生成によって生成された重要なアプリケーションについては知りません。
番号
凡例は、次のように書くという失敗した仮定に基づいています。
class ClassName extends SomeThing
{
}
...それはhardおよびオートメーションが必要です。
あなたはまだ臨時の信者、または信者のcrowdsを見つけるかもしれません。
しかし、それはそれが宗教やカルトとどう関係するかです。
そこに行ったが、それはあまりにも便利だとは思わなかった。
一般に、それらからいくつかのコードを生成するのに十分具体的な図、主にクラス図は、プログラムを実際に理解する方法に多くを追加せず、ユースケースや概要レベルのアクティビティなどの概要図からコードを生成できませんドキュメンテーションにとって重要です。理解に役立ち、コードを生成できる1つの図は状態チャートです。これは、本当に状態マシンが必要なときに役立ちます。ただし、本質的にエラーが発生しやすいため、一般的にはそれらを回避するようにしてください。
あるプロジェクトでは、UMLモデラー（Rhapsody）でコードを設計し、そこからコードを生成する必要がありました。それは一種の働きをし、おそらくヘッダー（C++でした）やプロトタイプを手で入力するよりもわずかに簡単でした。これら2つを自動的に一致させる機能は、多少便利でした。
状態マシンのスケルトンを除いて、ダイアグラムは実際にそれを表すことができないため、メソッドの本体は依然として手動で入力する必要がありました。
一方で、それはかなり複雑であるため、多くの追加のことを学ぶ必要があり、さらに重要なことに、マージするのは苦痛でした。マージはテキストファイルについて十分に調査されており、テキストファイルで機能しますが、ダイアグラムへの変更をマージする簡単な方法はまだ誰も発明していません。 Rhapsodyは実際には生成されたコードに情報の一部を保持し、それを解析して戻すため、完全に使用できなくなったわけではありませんが、それでも深刻な問題でした。
UMLモデルから直接コード（およびシステム全体）を生成することは確かに可能ですが、このように使用されたことはありません。
私の経験では、ほとんどの企業が要件のコミュニケーションツールとして、または「図を描画するためのMSペイント」として使用しているようです。
私が作成したい重要な違いの1つは、ほとんどのUMLモデリングツールでシステムの単一モデルを構築できることです。たとえば、VisioはUMLのしくみをかなりよく理解しており、図に直接関係しない追加できるものがたくさんあります。実際の図は、モデルの一部を単純に異なる視点から見たものであり、システムのさまざまな側面を強調することができます。
そのすべて（モデリング図）はコミュニケーションのためのものです
モデリングには、ソフトウェア開発プロセスで4つの重要な使用法があります。
統合設計ツール
コミュニケーションツール
ソフトウェア生成の支援
実際の単語の問題の複雑さを軽減する方法（上記の@kevin clineの応答からこれを学びました）
モデリングのプロセスでは、一部の設計者はコーディング中に考慮されない詳細（およびその逆）について考えるようになります。設計時のモデリングでは、言語でメソッドまたはクラスをコーディングするよりも全体像を考慮することができます。
私の意見では、モデリングはデータベースの構築（ER図）、プロセスフローの理解（アクティビティ図）、ユーザーとシステムの相互作用の理解（ユースケース図）に不可欠です。
人々はUMLを使用して、コードやデータベースの生成など、より高度なことをしていますか？
はい、そうです。 ERD（UMLダイアグラムではない）とクラスダイアグラムを使用して（ツールの機能に応じて）、以下を生成できます。
1-データ定義言語（DDL）
2-お好みの言語のCRUDおよびクラス図のストアドプロシージャ（ORMツールはこれについてより多くのことを行うため、あまり役に立ちません）
モデリングツールの最も価値のある機能は次のとおりです。
1-モデルの整合性を維持する機能。変更を行うと、モデルに反映されます
2-使用されている質問に答える能力（私のモデルで使用されている「アカウント」はどこですか？）
3-同時ユーザーがモデルで作業できるようにする機能
4-グラフィック表現内で検索
5-印刷制御
6-レイヤー化（ダイアグラム要素をレイヤーに編成）して、一度に1つのレイヤーに集中できるようにする
7-複数のデータベースシステムのデータベースコード生成
8-モデルの検証（整合性のチェック、欠落したキー、サイクルなど）
したがって、モデリングツール、特に優れたツールは、ペイントよりもはるかに多くのことを行います。
Software Architectを使用して、高レベルの設計を行い、より難解なコンポーネントの相互作用の一部を文書化します。ダイアグラムからアプリのスケルトンを生成することもありますが、それが完了したら、両方を個別に維持します。完成後、コードをリバースエンジニアリングしてダイアグラムに戻すことはしません。私は以前、Rational XDEと呼ばれるツールを使用していましたが、これは小さなプログラムではかなりうまく機能しましたが、Swingイベントハンドラーを追加し始めたり、Strutsを操作しようとしたりすると失われます。
人々がUMLで書かない理由の大部分は、UMLですべてを完全に指定してから、ダイアグラムからコードを生成するのに多くの作業が必要になるためだと思います。米国国防総省がOMGと協力して、正しく検証された図から「実証済み」のコードを生成するいくつかのツールを開発していることを知っていますが、実際のコードよりも桁違いに多くのメタデータが必要になると思います。これはおそらく良いことです（結局のところ、それはドキュメントです）が、メタデータの生成はコードを書くよりも速くないため、比例してより多くの時間を費やすことになります。
UML自体は表記システムであるため、コミュニケーションと文書化の原因となります。 UMLモデルからコードを生成することはまれですが、そうです。 Rhapsodyユーザーは、Roseよりも頻繁に使用します。難しいのは、モデルとコードの同期を維持することです。ほとんどの実際のプロジェクトでは、コストが高すぎます。