まだUMLを使用していますか？どうやって？何のために？
数年前、当店の全員がMLに夢中でした。今、誰もが冷めたようです。
ソフトウェアプロジェクトでUMLがまだ広く使用されているかどうか知りたいです。
もしそうなら、この使用法はホワイトボードに限定されていますか？ドキュメントに使用しますか？ツールを使用してコードを生成していますか？
関連：
ウォーターフォール UMLの適応（Visioで描かれた精巧な図の過剰なドキュメントなど）よりも、アジャイル UMLの採用（ホワイトボードのスケッチなど）の方が好きです。
UMLは、他の人にデザインを説明するのに役立ちます。例えば。複合デザインパターンは、単純なクラス図で簡単に説明できます（つまり、これらの興味深い類推を終えた後）。
いくつかの手描きのクラス図とシーケンス図は、クラスがいたるところに散らばっていて、十分なドキュメントがない新しいまたは古いプロジェクトに直面したときに、すぐに始めるのに便利です。
私のチームは、データベーススキーマを生成するためにクラス図をうまく使用しています。おそらくもっと良い方法がありますが、それは別の質問です。
私は常にUML（またはUML ispired）グラフィックをサポートドキュメントとして使用してきました。ドキュメントは、「これはユーザーの元々の概念でした」などの時間のスライスを提供します。ドキュメントを最新の状態に保つことは困難であり、定義を変更する必要がある場合にのみ実行されます。次に、別のスナップショットが間に合います。 UMLは設計ではなく、設計プロセスの一部でした。
私はUMLを使用するいくつかのコード生成ツールを使用しましたが、初期スタブを生成するためだけに使用しました。通常、コードが生成されると、図から個別に進化します。
UMLの問題の1つは、多くの場合、図面が顧客、アナリスト、または開発者が概念を理解するのに役立つかどうかに集中するのではなく、適切なUML構文/スタイルについて議論が起こったことです。コード生成時に構文が重要であることは知っていますが、概念を理解するにはUMLが最適であることがわかりました。
このトピックに関するその他の回答については、 SO：UMLは実用的ですか？ を参照してください。 UMLは、概念やシステムを伝達するのにまだ役立つようです。人々はそれを定義ではなく説明として使用しているようです。 UMLを実装自体から分離すると、2つの同期を維持するのに問題が発生します。
私はUMLを初期設計に使用し、他の開発者と話すときの議論の助けとして使用します。しかし、最初の設計を超えて、UMLを最新の状態に保つために費やされた時間は努力する価値がありません。
生成されたUMLは、新入社員が非常に複雑で複雑なシステムを処理するのに役立つのを見てきました。 UMLはコードから自動的に生成されたため、常に最新であり、一部の人々はそれが役立つと感じました。
UMLは死んでいる、死んでいる、死んでいる： MLは本当に死んでいるのか、それともカタレプシーだけなのか？
ホワイトボード/ドキュメントは大丈夫です。それからコードを生成しますか？誰が何のためにそれを必要としますか？
私は実際にUMLを使用して、問題を視覚化し、考え抜くのに役立てています。この目的のために、シーケンス図、アクティビティ図、およびオブジェクト図が非常に役立ちます。
コンポーネント図は、ソフトウェア層を伝達しようとしているときに適しています。
配置図は、パッケージ化と展開、およびノード間の通信パスを理解するのに非常に役立ちます。
ほとんどのIDEは、構築されたままのクラス階層を非常に簡単に提供できるため、クラス図はあまり役に立ちません。
アジャイルを使用する場合は、UMLを使用する必要があります。
モデリングは重要です。もちろん、コードを書くほうが楽しい場合は、多くの時間を無駄にし、顧客の要件を満たしているかどうかわかりません。モデル化して、解決を求められている問題を理解し、開発時間を短縮し、有用な製品を顧客に出荷します。
高価なモンスターケーブルの金メッキを節約します。
私は他の開発者との議論でUMLを使用しています。写真を使って他の人に情報を伝えるほうがうまくいくと思うことが多いので、チームの他のメンバーとブレインストーミングするときは、ホワイトボードにクラス図やアクティビティ図を描きます。他のメンバーはそれを描いたり修正したりすることができます、そして私たち全員が私たちが話していることを知ったら、私たちはただそれで転がる傾向があります。私たちはそれから直接コードを生成することを気にしませんでしたが（ツールがひどいため）、一方で、そうすると、より制約を感じたかもしれません。これらのデザインは、ホワイトボード以降、大幅に変更されました。
描画する対象者と目的によって異なります（UMLを、あまり一般的ではない、より抽象的な形式ではなく、ビジュアルモデリング言語として使用していると仮定します）。
制御のシーケンスまたはクラス階層を他のエンジニアと通信している場合は、UML図が理想的です。
マクロアプリケーションアーキテクチャを顧客や上級技術マネージャーに伝えると、おそらくPowerPointが見つかるでしょうが、どんなに多くのことを考えれば、より効果的です。
アーキテクチャビューのいくつかの一般的に必要な図のUMLの弱点の概要については、 ソフトウェアアーキテクチャの文書化 を参照してください。
もう1つのヒント-優れたものなどのテキストツールを使用する PlantUml -学ぶのに非常に簡単なDSLがあり、Visioに直線を描画させたり、巨大な過剰設計を使用したりするのではなく、意味に集中できます。 CASEツール。 PlantUmlモデルをソース管理にチェックインし、SVGまたはPNGを自動的にビルドして公開するCIジョブを設定します。
Together/Jは、UMLを作成するための努力がなく、Javaコードの横にあるだけなので、良い参照ポイントです。UMLを使用したかどうかを確認するのは興味深いことです。 "自由"。
そこにあると便利でしたか？正直なところ、私が作成したデザインが形になっていることを視覚的に確認し、クロスチェックするため、および視覚的なカタログ作成ツールとして役立つことがわかりました。ダイアグラムに基づいた特定のロジックやスキーマについては考えていませんでした。まあ大丈夫多分時々私はしました。
それはお金の価値がありましたか？それは私にプロセスについて気分を良くさせました。それは他の人には印象的でした。それは私が行っていたものの在庫について考えることから少し時間を削りました。それは私に、画面の領域を占めるすべてのオブジェクトについて、一般的にすっきりとシンプルさについてもっと考えさせました。その属性が本当に必要なのか、それともすっきりさせることができるのか、と聞かれました。それは時々私が「UMLで考える」のを助けました。
追加の経験で、Together/Jを使用しますか？ UMLを最初から構築することに時間を費やすでしょうか？
私が実際にプロジェクトで行っていることを見ると、ユースケースとメモリの使用、帯域幅の使用とセキュリティを考慮して、UIデザイン、データベーススキーマ、通信プロトコルを作成することが含まれています。実際、オブジェクト指向/ UMLを除いて、考慮できるほとんどすべてのものがあります。そして、Together/Jは使用していません。
どうしてこれなの？
これは、UMLからの学習を内部化したためです。私は今、デザインのスピード、スペース、時間の効率を達成することに焦点を当てています。私の設計はUMLの原則によって非常に制約されているので、それらすべてを学ぶ価値がありましたが、実際の紙のUMLダイアグラムを使用したり、UMLで考えたりすることはもうありません。
UMLが想定されています。与えられた。というか、デザインへの影響です。
私が今画面に表示しているのは、純粋なコードとデータです。達成感もあります。 :-)
私は日常的にクラス図を使用して、オブジェクトとスキーマの両方のモデルについて話し合っています。これは、すべての矢印を線の反対側にスライドさせることでクラス図からERDを導出できることを指摘するまで、DBAを実際に破棄します...矢印は依然として同じ方向を指しています。そこで、今ではFKが描かれています。
2つのタイプの図の間で異なる構造的および意味的な詳細がたくさんありますが、矢印の変換は精神的なブロックをクリアしているようです。
まだUMLを使用しています。ここにいる他の人たちと同じように、彼らはコミュニケーションを大いに助けていると思います。視覚補助があると、人々のコミュニケーションがはるかに簡単になります（PowerPointの人気を入力してください）。これは、firebird84のようなシナリオが頻繁に発生するプロジェクトの初期段階で特に当てはまります。 UMLの骨の折れる側面は、プロジェクトの開発者がコーディングを開始した後の図の維持です。
ただし、それらからコードを生成することはありません。その程度までUMLを使用したことのある人とはまだ個人的に話していません。
初期設計にもUMLを使用しています。 reqsフェーズとユースケース（UMLとテキスト形式の両方）を実行した後、基本システムは、単一のコンポーネント、インターフェイス、およびサブシステムを識別するためのコンポーネント図としてレイアウトされます。
UMLクラス図は、主にプロジェクトの開始時のスクラッチにのみ使用しますが、他の開発者に独自のコードを説明する場合にも使用します。しかし、これは私たちのソフトウェアを文書化するためではなく、ひどいだけです。
私の考えでは、UMLについて（人々、雑誌によって）よく話題になっていますが、実際にUMLを使用している人はそれほど多くありません。
従来のUMLは死んでいると思います。私は静的UMLを意味し、要件のモデリングとモデルからのコード生成に数か月を費やします。プロジェクトをどんどん速く提供しなければならないので、コーディングを開始するまで1週間以上待つことはできません。モデル化してからコードを生成する場合、生成されたコードは通常非常に悪いため、修正する必要があります。クリーンな新しいコードを書くよりも、数年前にUMLで生成されたダーティなコードの修正に多くの時間を費やしました。
MDD（モデル駆動型開発など）は死んでいると思いますが、UMLグラフィカル表記ではありません。私は今でも毎日使っていますが、とてもうまく機能しています。新しい要件を取得したら、すぐにそれをクラス図にモデル化します。最初に既存のプロジェクトを元に戻し、次に新しい要素を作成して既存のコードとマージします。要件のスケルトンを既存のプロジェクトに作成するのに2時間もかかりません。より高いレベルの抽象化とコードが得られるので、クラス図を使用してスケルトンを作成するのが好きです。すごくかっこいい。私はOmondoEclipseUMLを使用しており、このツール用に作られています。他のベンダーには申し訳ありませんが、このツールは私の人生を変えました。プロジェクトをオフショアチームと1日2回マージし、新しい図を再作成します。コミットを受け入れる前にコードをチェックすることを好むので、これは自動ではありません。コンパイルとオブジェクトアプローチを確認すると、UMLだけが、新しい要件をサポートするために何が行われたか、どのように、どこに接着剤が追加されたかを確認できます。ダーティなMDDコード生成を使用しなくなったので満足していますが、UML表記と高品質のコードに集中できます。
ULMは私には役に立たない、それは私の創造性を損なう。私は、顧客が望む場合にのみ、文書化としてUMLを生成します。しかし、私はそれをクラスのモデル化には使用しません。建築は進化するプロセスであり、オフィスだけでなく、どこにいても何度も何度も考え、新しいアイデアを思いついたのです。私は常に最適に近づくためにリファクタリングを行っています。最初に念頭に置いてから、コードを作成します。私が何を意味するのか理解していただければ幸いです。
ユースケース図に使用します。しかし、他にはあまりありません。
Fowlerが「UMLDistilled」というタイトルの本で説明しているように、私はコックバーンスタイルのユースケースが好きだと判断しました。私はそれらを十分に気に入っているので、C＃名前空間に直接埋め込む実験的な方法を考案しました。
これを行うことで、ドメイン固有言語を記述しなくても、ユースケースの英語コンテンツの観点からビジネスロジックまたはUIロジックを無料でエンコードできました。最も直接的な利点は、コードの可読性を向上させたことです（非常に新しく難解な方法でアルビエット）。それはまだ実験的なアプローチです。しかし、私はそれが役に立つかもしれないと信じています。
ここ は、私がしたことを行う他の方法を見つけようとしているときに投稿した質問へのリンクです。