本当に役立つUML図

UMLにはダイアグラムのジャングルがあります。
プロファイル図、クラス図、パッケージ図...

ただし、（IMHであり、かつ経験不足ではない）Oでは、すべての図を実行するのはやり過ぎです。

したがって、どのUML図がWebコンテキスト、より具体的にはブログに適しているか（ゼロから作成したい）。

_{私がUMLダイアグラムを使用したからといって、コードが素晴らしくて見事であるとは限らないことを理解しています...}

一般的なガイドラインとして：

• アーキテクチャの概要を示す1つの配置図（あらゆるシステムに適しています）
• ユーザーがシステムを使用して行うことの概要を示す1つのユースケース図（dito）
• データモデルの1つのクラス図
• 個々のユースケースが複雑な場合のフローのアクティビティ図
• ブログエントリの作成/レビュー/公開ワークフローがある場合は、おそらく状態マシン図

一部の図の種類（タイミング図など）はかなり特殊な用途があり、他の種類は、実際のコードがより適切に機能する詳細レベル（例：シーケンス図）に向かう傾向があります。パッケージ図？どのIDEでもパッケージを表示できます）。

この図は、プロジェクトのさまざまな利害関係者間で概念をやり取りするときの会話ほど重要ではありません。何年にもわたってソフトウェアを開発してきた結果、私は、始めたばかりの頃に比べて、近年では情報を図式的に捉えようとすることが少なくなっています。最近では、概念について話し合うときにホワイトボードにいくつかの単純なユースケースを作成する場合があります。顧客がシステムの動作を望んでいることについて理解を深めようとする場合は、単純でクラシックなフローチャートに頼ることがよくあります。特に気になる場合は、スマートフォンのカメラを使用してホワイトボードに画像をキャプチャし、特定のことを思い出します。

大量に文書化された事前設計はそれほど無駄のないものではありません。それは変更を思いとどまらせ、プロジェクト全体にとって完全に間違っている可能性のある単一の攻撃計画に関するあなたの考えを修正します。大きな変更によって設計やスケジュールが台無しになる可能性を減らすために、できるだけ多くの設計を最後まで延期できるようにしたいと考えています。これは、UMLを使用してはならないということではなく、概念の伝達を改善するための手段として、および構築しようとしているシステムを定義するための手段としてではなく、慎重に使用する必要があるということです。

UMLは関係者間のコミュニケーション言語として設計されました。（プログラマー-プログラマー、プログラマー-ビジネスマン、ビジネスマン-ユーザー）人々は、誰もが理解できるシンプルで統一された言語でメンタルモデルを表現します。

あなたは自分にどれだけのコミュニケーションが必要かを自問する必要があります。

• ドキュメントと一緒に販売したい内部ソフトウェアまたは製品ですか？
• ソフトウェアをどのくらいの期間維持しますか？それを維持するためにプログラマーを雇いますか？
• どのくらい機敏になりたいですか？詳細な計画を立てすぎると、時間を無駄にする可能性があります。
• どのように奇妙なことをしたいですか？通常、登録の詳細な使用例やブログの全体的なアーキテクチャなどの一般的なパターンを文書化する必要はありません。

経験則としては、概要図を作成して概要を示し、複雑な、またはそれほど一般的でないものに時間を費やすことです。UMLでメンタルモデルを書き下ろすと、1行のコードを書く前にそれを完全に理解し、多くのバグを解決しなければなりません。

システムを理解して伝達するには、必要な数だけ必要です。ブログソフトウェアについては、あなたが多くを必要とするとは思わないでしょう。システムを理解するために必要なだけモデル化します。理解を深めるのをやめたらモデリングを停止します。

UMLを初めて使用する場合は、いくつかの図を詳細に表示して、図の理解を深めることができます。ダイアグラムのタイプを十分理解して、頭の中でそれを実行できるようになると、実際のダイアグラムの必要性は少なくなります。

ダイアグラムのバージョンに日付を記入すると、それらが最新であるかどうかを判断するのに役立ちます。現在の設計を古い図と比較すると、プロジェクトのどの領域が元の設計と大きく異なっているかを判断するのに役立ちます。

図からコードを生成したり、図の仕様をコードに埋め込んだりするツールを使用していない限り、コードとの同期が失われる可能性があります。詳細な図は、時間の経過とともに著しく不正確になる傾向があります。概要図より。また、概要図を最新に保つために必要なメンテナンスも少なくなります。

次のような図を生成すると便利です。

• アクターの概要とシステムの使用方法。
• システム内のパッケージの構造の概要を説明します。再利用可能なコンポーネントが含まれているパッケージに注意してください。
• データベース構造をモデル化します。
• シーケンス図は、標準コンポーネントの設計に役立ちます。同様のコンポーネントが多数ある場合は、1つをモデル化して、他のコンポーネントのパターンとして使用します。このような場合のコードの再利用を検討してください。

プロジェクトの計画に役立つ図を生成します。プロジェクトについて何かを理解したり伝達したりするために図が必要ない場合は、図に時間を浪費しないでください。理解に役立つ場合は、UML以外の図を自由に使用してください。UMLは、データベースをモデル化する最良の方法ではない場合があります。

私は、UML図をすべての利害関係者のモデリングレベルとプロジェクトを完了するために必要な時間に適合させる必要があると思います。

チームがUMLを知らず、時間がない場合、リバースされたコードからのクラス図のみが可能です。各メンバーは、クラス図にコメントを追加できます。これは、すでにドキュメントの優れたソリューションです。この場合、モデルはコードのグラフィカルビューにすぎません。これにより、モデリングの必要性の約90％を注意深く行うことができ、プロジェクトに余分な時間が追加されることはありません。

ステークホルダーに関する高度な知識がある場合は、すべての図がプロジェクトに真の価値をもたらし、モデリングプロジェクトの完全なニーズに対応できます。これはプロジェクトの配信にかなりの時間を追加する可能性がありますが、配信品質は向上すると予想されます。

UMLはクールで華麗であり、適度に使用すれば、あらゆるプロジェクトに適応できます。たとえば、飲酒と運転を同時にしないでください:-)

サーバー、レイヤー、または大きなモジュールの観点からアプリケーションの全体的なアーキテクチャーを伝えるために使用されるいくつかの全体像の図は別として、どの図が事前に必要かを予測することはできないと思います。

最後の責任ある瞬間まで待ちます。必要なときに表示されます。通常はどちらかです

• 顧客/ドメインエキスパート/アナリストとの会話中に、ユースケースを明確にする
• または、コードを書き始める直前に、デザインの最初のバージョンを具体化します。

とにかく、数行のコードを書いたり、最初の顧客からのフィードバックを受け取ったりするとすぐに、モデルはおそらく古くなるので、事前にすべてを計画したり、ダイアグラムをそれほど洗練したりしないでください。