どのUML図がまだ広く使用されていますか？
私は学部レベルでソフトウェア工学を教えており、UML実践者に質問があります。
ほとんどのソフトウェアエンジニアリングの教科書は、UML図のカバーに真剣に取り組んでいます。しかしその一方で、UMLはもはや塹壕で使用されているようには見えないという多くの卒業生から聞いた。
どのようなUML図がまだ専門家の練習で広く使用されていますか、そしてなぜですか？使用されなくなった図はありますか、またその理由は何ですか？
N.B：意見に基づく議論や議論を避けるために、事実と客観的な要素（可能な場合は検証可能）または個人的な経験に関する中立的な見解で回答を説明してください
UMLによって提案された多くの図から、クラス図とシーケンス図はまだ広く使用されており、確かに状態図がそれに続きます。
- ホワイトボードで簡単に使用して、コードに飛び込む前にデザインを詳しく説明したり議論したりできます。
- それらはコードだけでは簡単に与えられない概要を非常に迅速に伝えることを可能にし、それに代わる実行可能なものはありません。
実生活でのユースケースは、たまに使われると思います。数百のユースケースがある大きなプロジェクトでは、図を描くのは面倒であり、表形式の場合に比べて利点がほとんどありません。 [〜＃〜] bpmn [〜＃〜] プロセス設計の場合 ユーザーストーリーマッピング 、または Cockburn スタイルのイベント表分解より使用されます。どうして ？要件を効率的に解決するためにビジネスユーザーと簡単に共有できるからです。
UMLが今なお多用され、体系的に使用されている場所だと思います。 航空宇宙ソフトウェア または原子力発電所の制御システムがUMLドキュメントの完全なセットなしで作成されるとは思いません。しかし、私はそれが規則よりも例外であると信じています。
書店を見ていると、私はこの発言で確認しました。数年前、UML 2.0に関する本をたくさん見つけることができました。現在、UML 2.5を探している場合、選択はかなり制限されています。さらに悪いことに、多くの著者は、以前の本を最新の状態に保つために改訂する努力さえしていません（例：Fowler's Nice " ML蒸留済み "導入は、2003年からUML 2.0および Ambler の「UML 2.0スタイルの要素」と同じです！）。
アジャイル の一般化と「包括的なドキュメントを介したソフトウェアの動作」の促進を見ても、この減少傾向は変化するとは思わない。
最後に、私は非常に挑発的に、モデリング手法がダーウィン主義のスキームに従っているように見えると主張します：最も適切なダイアグラム作成手法だけが生き残り、非公式なアプローチ（例：ナプキンのイラスト）および詳細なコード（例：対応するコードがA4シートに収まるのに、なぜA1アクティビティ図を描くのですか？）;-)
一方、UMLはもはや塹壕で使用されているようには見えないという多くの卒業生から聞いた。
それらはすべて実際に使用されています。しかし、誰もがそれらを使用するわけではありません。一部の人々は設計を完全に避け、コーディングにまっすぐ飛躍します。 「全員」が何をするかを知るのに、事例証拠に頼ることはできません。
UMLのようなツールは値が追加された場合;例えば.
- 大規模プロジェクトの場合
- プロジェクトの複雑な部分
- プロジェクトの設計に複数の人からの入力が必要な場合
それらを実行するためだけに（またはプロセスで必要とされるため）作成することは、生産的ではありません。ベストプラクティスは、ダイアグラムの内容と使用する種類を選択することです。役立つときに、どこでUMLを使用するか...そして、使用するUML図の種類を選択することも含まれます。
また、UMLは主に設計ツールとして設計されました。文書化ツールとしてはあまり効果的ではありません（最近）。典型的なIDEは、コードベースの構造がその場で変化する場合、多くの側面を視覚化するのに役立ちます。これは、多くの場合、古くなったり不正確になったりした可能性のあるUML図に依存するよりも優れています。
UMLはまだトレンチで使用されています。しかし、いつものように、人々はそのサブセットを使用します。現在の問題の対象となっているサブセット。
UMLには多くのバージョンがあります。しかし、いつものように、人々はそれを非公式にそして不規則に使用します。
UMLは、書籍のパターンの多くを理解する方法です。また、ホワイトボードでのコミュニケーション方法の1つでもあります。それはなくなっていません。しかし、コードのように正式に使用されることは決してありません。
UML図を修正して MLバージョン2.5 、または最新のものに準拠する学生を作成するのではなく、図が完全に一貫していなくても、通信しようとしている内容を理解できる学生を作成します。特定のUMLバージョンでは、それがUMLがトレンチで使用される方法だからです。それは他のシステムと混合された奇妙な地方の方言で来て、そして時々私達は私達自身のシンボルを単に作る。
何が意味するのか尋ねるのは大丈夫であることを彼らに教えます。想像上のルールに違反している他の人を正すように教えないでください。ここでコミュニケーションをとろうとしているだけです。
私がUMLを使用するのを見た中での最良の用途は、新しいプログラマーに問題を解決するための彼らの計画を見せてもらうことです。それは、彼らが無視している、または存在していないことに気付いていないシステムの部分をすぐに私たちに示しました。
また、UMLが必要ない場所でも、UMLが必要な場所で働いています。私たちはいつも同じパターンを使用していたので、それは単なる形式的なものでした。古い名前の図に新しい名前を写真で保存しただけです。このような使用を奨励しないでください。
しかし、通常の矢じりと開いた矢じりの間に違いがあることは誰もが知っていると思います。正しい？
私の経験に応じて具体的に説明します。-配置図-シーケンス図-クラス図これらの3つはどのプロジェクトでも最も使用されており、さまざまなレベルのチームとの実際のコミュニケーションの価値を提供します。