本当に役立つUML図
UMLにはダイアグラムのジャングルがあります。
プロファイル図、クラス図、パッケージ図... 
ただし、（IMHであり、かつ経験不足ではない）Oでは、すべての図を実行するのはやり過ぎです。
したがって、どのUML図がWebコンテキスト、より具体的にはブログに適しているか（ゼロから作成したい）。
私がUMLダイアグラムを使用したからといって、コードが素晴らしくて見事であるとは限らないことを理解しています...
一般的なガイドラインとして：
- アーキテクチャの概要を示す1つの配置図（すべてのシステムに適しています）
- ユーザーがシステムを使用して行うことの概要を示す1つのユースケース図（dito）
- データモデルの1つのクラス図
- 個々のユースケースが複雑な場合のフローのアクティビティ図
- ブログエントリの作成/レビュー/公開ワークフローがある場合は、おそらく状態マシン図
一部の図の種類（タイミング図など）はかなり特殊な用途があり、他の種類は、実際のコードがより適切に機能する詳細レベル（傾向図など）になりがちなものや、巨大なプロジェクトを意図しているように見えるが、そこにも実用性に疑問がある（パッケージ図？IDEはパッケージを表示できます）。
この図は、プロジェクトのさまざまな利害関係者間で概念をやり取りする場合の会話ほど重要ではありません。何年にもわたってソフトウェアを開発してきた結果、情報を図式的に捉えようとするのは、始めたばかりの頃よりも近年少なくなっています。最近では、コンセプトについて話し合うときにホワイトボードにいくつかの単純なユースケースを作成する場合があります。顧客がシステムの動作を望んでいることについて理解を深めようとする場合は、シンプルでクラシックなフローチャートに頼ることがよくあります。特に気になる場合は、スマートフォンのカメラを使用してホワイトボードに画像をキャプチャし、特定のことを思い出します。
大量に文書化された事前設計はあまり無駄がありません。それは変更を思いとどまらせ、プロジェクト全体にとって完全に間違っているかもしれない単一の攻撃計画に関するあなたの考えを固定します。大きな変更によって設計やスケジュールが台無しになる可能性を減らすために、できるだけ多くの設計を最後まで延期できるようにしたいと考えています。これは、UMLを使用するべきではないということではなく、概念の伝達を改善するための手段として、および構築しようとしているシステムを定義するための手段としてではなく、慎重に使用する必要があるということです。
UMLは関係者間のコミュニケーション言語として設計されました。 （プログラマー-プログラマー、プログラマー-ビジネスマン、ビジネスマン-ユーザー）人々は誰でも理解できるシンプルで統一された言語でメンタルモデルを表現します。
必要なコミュニケーションの量を自問する必要があります。
- ドキュメントと一緒に販売したい内部ソフトウェアまたは製品ですか？
- ソフトウェアをどのくらいの期間維持しますか？それを維持するためにプログラマーを雇いますか？
- どれだけ機敏になりたいですか？詳細な計画を立てすぎると、時間を無駄にする可能性があります。
- どのように奇妙なことをしたいですか？通常、登録の詳細なユースケースやブログの全体的なアーキテクチャなどの一般的なパターンを文書化する必要はありません。
経験則では、高レベルの図を作成してoverviewを提供し、複雑な、またはそれほど一般的でないものに時間を費やします。 UMLでメンタルモデルを書き下ろすと、1行のコードを書く前にそれを完全に理解し、多くのバグを解決する必要があります。
サーバー、レイヤー、または大きなモジュールの観点からアプリケーションの全体的なアーキテクチャーを伝えるために使用されるいくつかの全体像の図は別として、どの図が事前に必要かを予測することはできないと思います。
最後の責任ある瞬間まで待ちます。 必要なときに表示されます。通常、どちらかです
- 顧客/ドメインエキスパート/アナリストとの会話中に、ユースケースを明確にする
- または、コードを書き始める直前に、デザインの最初のバージョンを具体化します。
とにかく、数行のコードを書いたり、最初の顧客からのフィードバックを受け取ったりするとすぐに、モデルはおそらく古くなるので、事前にすべてを計画したり、ダイアグラムをそれほど洗練したりしないでください。
システムを理解して通信するには、必要な数だけ必要です。ブログソフトウェアについては、あなたが多くを必要とするとは思わないでしょう。システムを理解するために必要なだけモデル化します。理解を深めるのが止まったら、モデリングを停止します。
UMLを初めて使用する場合は、いくつかの図を詳しく見て、図の理解を深めることができます。ダイアグラムのタイプを十分理解して、頭の中でそれを実行できるようになると、実際のダイアグラムの必要性は少なくなります。
ダイアグラムのバージョンに日付を記入すると、それらが最新であるかどうかを判断するのに役立ちます。現在の設計を古い図と比較すると、プロジェクトのどの領域が元の設計と大きく異なっているかを判断するのに役立ちます。
図からコードを生成したり、図の仕様をコードに埋め込んだりするツールを使用していない限り、コードとの同期が失われる可能性があります。詳細な図は、時間の経過とともに著しく不正確になる傾向があります。概要図より。また、概要図を最新に保つために必要なメンテナンスも少なくなります。
次のようなダイアグラムを生成すると便利です。
- アクターの概要とシステムの使用方法。
- システム内のパッケージの構造の概要を説明します。再利用可能なコンポーネントが含まれているパッケージに注意してください。
- データベース構造をモデル化します。
- シーケンス図は、標準コンポーネントの設計に役立ちます。同様のコンポーネントが多数ある場合は、1つをモデル化し、それを他のコンポーネントのパターンとして使用します。このような場合のコードの再利用を検討してください。
プロジェクトの計画に役立つ図を生成します。プロジェクトについて何かを理解したり、伝えたりするために図が必要ない場合は、時間を無駄にしないでください。理解に役立つ場合は、UML以外の図を使用してください。 UMLは、データベースをモデル化する最良の方法ではない場合があります。
私は、UML図をすべての利害関係者のモデリングレベルとプロジェクトを完了するために必要な時間に適合させる必要があると思います。
チームがUMLを知らず、時間がない場合、リバースされたコードからのクラス図のみが可能です。各メンバーは、クラス図にコメントを追加できます。これは、すでにドキュメントの優れたソリューションです。この場合、モデルはコードのグラフィカルビューにすぎません。これにより、モデリングの必要性のほぼ90％がカバーされ、プロジェクトに余分な時間が追加されることはありません。
ステークホルダーに関する高度な知識がある場合は、すべての図がプロジェクトに真の価値をもたらし、モデリングプロジェクトの完全なニーズに対応できます。これはプロジェクトの配信にかなりの時間を追加する可能性がありますが、配信品質は向上すると予想されます。
UMLはクールで見事なものであり、適度に使用すれば、あらゆるプロジェクトに適応できます。たとえば、飲酒と運転を同時にしないでください:-)