デザインでのダイアグラム描画の順序は何ですか？
私はOOPとUMLで新しいので、ここで混乱があります。どこから始めればよいか知りたいのです。つまり、誰かがあなたのところに来て、何かをするように頼みます（ソフトウェアを含む）もちろん設計）、何をしなければならないかを決定したら、ソフトウェアアーキテクチャを開始する必要がある順序は何ですか？つまり、最初にユースケース図またはクラス図ですか、それともいくつかの図を描く必要がありますか並行して？
しかし、基本的には、どこから始めればよいでしょうか。どのUML図が最初に行くのですか？助けてくれてありがとう！
決まった順番はありません。それはすべて、あなた/あなたのチームにとって最も役立つと思うことに基づいています。
最初は、要件のコレクションがいくつかあるはずです。誰かがXのためのソフトウェアをやるように言われたらSWアーキテクチャから始めるなら、あなたはすでにそこで最も重要なステップを逃した。
要件エンジニアリング段階では、すべてのUML図がまだ意味をなさない場合があります。しかし、特にユースケース図のように、いくつかは非常に理にかなっています。私は、ユースケース図を、要件を決定するための議論の基礎としてよく見ました。
同様に、状態マシンも要件レベルですでに人気があります。
一連の要件があり、実際にアーキテクチャについて、そして後で設計について考え始めると、ますます多くの図が意味を持ち始めます。明らかに、クラスダイアグラムは詳細レベルが低い場合に役立ちますが、シーケンスダイアグラムのように、アーキテクチャに複雑なシーケンスがある場合にも役立ちます。
分散システムを開発していますか、それともコンポーネントが相互に多く通信する必要があるものを開発していますか？コミュニケーション図を試してください。
プロセスで何らかの方法で特定のUML図を使用する必要がある場合を除いて、そうするように強制する人はいません。自分のためにソフトウェアをUMLでモデル化しないことを常に覚えておいてください。それがあなたに役立つと思わない場合は、単にそれをしないでください。
明らかに、これを決定するにはある程度の経験が必要です。ステートマシン、クラス、アクティビティー、シーケンス図は、最も人気があるため、少なくとも時間をかけて試してみることをお勧めします。時間があれば、他の人も見てください。
厳格な規則はないことに同意しますが、UMLに関するMartin Fowlerの本を読んだ後、大まかな手順の概要を思いつきました。
1）アクターを最初に分析します（アクターのUML図とそれらがシステムとどのように相互作用するか）
2）ユースケース図
3）システムに影響を与える外部要因の分析（実際には、情報提供のみを目的とした図ではありません）
4）システムのリスクを分析し、その影響を推定します（これも実際には図ではありません）
5）シーケンス図（データフローを含む）
6）クラス図
この本から：「大きなシステムでは...最初に俳優のリストに到達し、次に各俳優のユースケースに到達する方が簡単です。」〜Martin Fowler- ML Distilled
この本を図表の素晴らしい紹介としてお勧めします。
本からのもう一つのアドバイス：最も更新されていない多くの図を用意するよりも、いくつかの図を更新しておく方がよい
厳密な規則はありませんが、いくつかのガイドラインがあります。
シナリオによっては、ほとんどの開発者/アナリストが開始します。
多くのアナリストは、「ユースケース」図から始めて、最終的にはパッケージやコンポーネントなど、他の図、通常はアーキテクチャ図を追加します。
そして、「クラス」、「アクティビティ」、「シーケンス」ダイアグラムを使用します。
乾杯。