ユースケースは、システムが行う「何」を定義する主なものであり、場合によってはステートマシンとアクティビティ図が続きます（どちらの方法でも見ることができます。通常、アクティビティ図は「何」に関するものであり、ステートマシンは「どのように」、しかし私はそれぞれの反例を見てきました）; クラス図とシーケンス図、さらにはコンポーネント図とデプロイメント図（総称して「物理的」）は、システムがどのように機能するかについてますます重要になっています。逆の順序はほとんど意味がないので、私は間違いなく「何」から「どのように」に行きます-「何」を定義していない場合、「どのように」が意味をなすことができますか？
したがって、大まかに要約すると、ユースケース、アクティビティ、ステートマシン、クラス、シーケンス、コンポーネント、デプロイメントです。この順序は、実装の側面に向かって深くなり、分析の側面から離れていくため、理にかなっています。たとえば、どのユースケースに対応し、どのビジネスルールを適用するか（アクティビティ図）を正確に理解することに関心のある人は、「読むのをやめるかもしれません」 「展開戦略の完全な詳細なロジックを理解する必要がある人よりも早く。
クラス、シーケンス、およびユースケース図は、プロジェクト内で通常作成される図の90％以上を表しています。クラス図自体は、他のすべての図よりも多くの図を表す場合があります。
最善の解決策は、それをシンプルに保ち、モデリングをチームのレベルに適合させることです。
UMLの経験がない場合は、アプリケーションのスケルトンを表すクラス図を作成するだけです。
初心者レベルの場合は、ユースケース、シーケンス、クラス図から始めます。
中レベルの場合は、すべての図を使用します。各図は、Javaでコーディングできるとは限らない別のビューをカバーしているためです。つまり、Javaはクラスとシーケンス図にのみ関連しています。
物理的な図は、おそらくどこからでも始めるのに適した場所です。アクティビティ図は、デザインのねじれを解決するのに非常に役立ちます。シーケンスも同じ理由で優れています。ステートマシン図を気にすることはめったにありません。
現実的には、とにかく最初に行うデザイン（繰り返しのデザイン、うーん！）を再検討したいと思うので、プロジェクトに最も明確なものをもたらすものから始める価値があります。
UMLダイアグラムは、設計のさまざまなモデルを表したものです。あなたが説明するように、それらをきれいにシリアル化できるかどうかはわかりません。多くの場合、クラス図は、プロセスの分析フェーズと設計フェーズの両方で使用されます。同様に、他の図は複数のフェーズで使用されます。
適切な図を使用して設計のモデルを「表示」するのは、いつでも設計のどの側面に関心があるかによって異なります。
「クラス図から始める」と「ユースケースモデルから始める」の両方が提案されているのを見てきました。私はそれが本当に問題ではないことに気づきました。
いくつかの図を使用してシステムの高レベルの動作から始めて、同じ図のセットを使用してより詳細な設計に徐々に進んでいきたいと思います。