どのUMLダイアグラムがまだ広く使用されていますか？[閉まっている]

私は学部レベルでソフトウェア工学を教えており、UML実践者に質問があります。

ほとんどのソフトウェアエンジニアリングの教科書は、UMLダイアグラムのカバーに真剣に取り組んでいます。しかし一方で、多くの卒業生から、UMLはもはやトレンチで使用されていないようだと聞きました。

どのUMLダイアグラムが現在でも専門的な実践で広く使用されていますが、その理由は何ですか？使用されなくなった図はありますか？その理由は？

NB：意見に基づく議論や議論を避けるために、事実と客観的な要素（可能であれば、検証可能）または個人的な経験に関する中立的な観察で答えを説明してください

UMLが提案する多くの図から、クラス図とシーケンス図は依然として広く使用されており、その後に状態図が続きます。

• ホワイトボードで簡単に使用して、コードにジャンプする前に設計を詳しく説明し、議論することができます。
• これらは、コードだけではそれほど簡単に説明できない概要を非常に迅速に伝えることができ、それに代わる実行可能な代替手段はありません。

私は、実生活でのユースケースはもっとたまに使われると思います。数百のユースケースがある大規模なプロジェクトでは、図を描くのは苦痛であり、表形式よりも利点はほとんどありません。 プロセス設計、ユーザーストーリーマッピング、またはCockburnスタイルのイベント表形式分解のためのBPMNがはるかに使用されています。どうして ？要件をビジネスユーザーとより簡単に共有して、要件を効率的に解決できるためです。

それらは、UMLが依然として大量かつ体系的に使用されている場所であると確信しています。航空宇宙ソフトウェアや原子力発電所の制御システムが、UMLのドキュメント一式なしで生産されるとは思いません。しかし、私はそれが規則よりも例外だと信じています。

本屋で見たとき、私はこの声明で確認されたと感じます。数年前、UML 2.0に関する本をたくさん見つけることができました。現在、UML 2.5を探している場合、選択はかなり制限されています。さらに悪いことに、多くの著者は以前の本を改訂して最新の状態に保つ努力さえしていません（例：Fowlerの素晴らしい「UML蒸留」の紹介は、2003年からUML 2.0で、Amblerの「Elements」と同じですUML 2.0スタイルの！」）。

この減少傾向は、アジャイルの一般化と「包括的なドキュメントを介したソフトウェアの動作」の促進を見れば変わるとは思わない。

最後に、モデリング手法はダーウィニズムのスキームに従っているように見えると非常に挑発的に主張します。最も適切なダイアグラム手法のみが生き残ります。対応するコードがA4シートに収まるのに、なぜA1アクティビティ図を描くのか？）;-)

一方、多くの卒業生から、UMLはもはやトレンチで使用されていないようだと聞いた。

それらはすべて実際に使用されます。しかし、誰もがそれらを使用するわけではありません。一部の人々は、設計を完全に避け、コーディングに直行します。「全員」が何をするかを知るために事例証拠に頼ることはできません。

UMLのようなツールは、価値を追加するときに使用すると最適に機能します。例えば

• 大規模プロジェクト向け
• プロジェクトの複雑な部分用
• プロジェクトの設計に複数の人からの入力が必要な場合

それらを実行するためだけに（またはプロセスが必要だと言っているために）それらを作成することは生産的ではありません。ベストプラクティスは、ダイアグラムの種類と使用する種類を選択することです。UMLを使用するのは、いつ、どこで役立つか、そして使用するUMLダイアグラムの種類を選択することも含まれます。

また... UMLは主に設計ツールとして設計されました。ドキュメントツールほど効果的ではありません（最近）。典型的なIDEは、コードベース構造がオンザフライである場合に多くの側面を視覚化するのに役立ちます。これは、古くなったり不正確になったりしたUMLダイアグラムに依存するよりも良い場合がよくあります。

UMLは今でもトレンチで使用されています。しかし、いつものように、人々はそのサブセットを使用します。どのサブセットが目前の問題の影響を受けやすいか。

UMLには多くのバージョンがあります。しかし、いつものように、人々はそれを非公式かつ不定期にシンボルを使用しています。

UMLは、そこにある本の多くを理解する方法です。また、ホワイトボードでコミュニケーションする方法の1つでもあります。なくなっていません。しかし、コードのように正式に使用されることは決してありません。

UMLバージョン2.5または最新のUMLに準拠するようにUML図を修正できる生徒を作成するのではなく、特定のUMLバージョンと完全に一貫していない場合でも、図が伝えようとしていることを理解できる生徒を作成しますUMLがトレンチでどのように使用されるか。それは他のシステムと混ざり合った奇妙な地域の方言で来ており、時々私たちは自分のシンボルを作り上げるだけです。

物事が何を意味するのかを尋ねても大丈夫だと教えます。いくつかの想像上のルールを破っている他の人を修正することを教えないでください。ここで通信しようとしています。

私がumlを使用した最も良い使い方は、新しいプログラマーに問題を解決する計画を見せることです。それは、彼らが無視したか、存在することに気づかなかったシステムの部分をすぐに示しました。

また、不要な場合でもUMLを必要とする場所で作業しました。私たちは常に同じパターンを使用していたので、それは単なる形式です。新しい名前を古い図に写真を撮っただけです。この種の使用を奨励しないでください。

しかし、私たちは皆、普通の矢じりと開いた矢じりの間に違いがあることを知っていると思います。右？

私の経験に応じて具体的に説明します。-配置図-シーケンス図-クラス図