documentation - UML で図を作成する順序はどのようなものですか?

Question

私たちが知っているように、UMLには13種類の図（構造図と動作図）が含まれています

ソフトウェア開発を始める前は、要件と設計の段階にあるので、どの図をいつ作成する必要がありますか? .. 要件および設計段階での UML での図作成の順序はどうあるべきですか?

実際、厳密なシーケンスがない場合は、最初に構造図を厳密に作成する必要がありますが、アクティビティ図のような動作はユーザー エクスペリエンスに応じて変化する可能性があります。

配置図とコンポーネント図を一体で作成することはできますか?

Answer 1

このような図の順序に関する規則は絶対にありません。

データの構造とドメイン モデルの動作が簡単に定義されているか、十分に文書化されている場合、クラス図を最初に作成すると、意味のあるシーケンス図の作成に役立つ明確な抽象化が可能になります。

また、ドメイン モデルの性質が不明または不明な場合は、最初にシーケンス図を作成し、そこからクラスを収集する方が理にかなっています。

私が確信しているのは、これらの図の改訂が相互に並行して行われることです (たとえば、シーケンス図は、クラス図では考慮されていなかった何かを明らかにする可能性があり、その逆も同様です)。

同様に、ソフトウェア開発を開始した後、これらのダイアグラムは、ユニット テストやユーザー エクスペリエンス テストなどを通じて、より直感的で保守しやすい抽象化と設計が明らかになるため、再び変化する可能性があります。

これらのダイアグラムはどのような点でも固定的であり、作成の順序が必要であるという考えに決して夢中にならないでください。私を信じてください。それらを厳格で間違いのないものとして扱うと、自分の足を撃ち、ソフトウェア開発の努力で片腕を後ろに縛ることになります.

更新コメントに反映されているように、最初にどの図を使用すればよいか本当に迷っている場合は、要件収集フェーズの早い段階でユース ケース図が非常に重要になります。

さらに、上に書いたことが当てはまります。

Answer 2

私はJonとPeteに同意しますが、UMLは何であり、どのように変化するかを敬意を表して付け加えます。UMLとは何かを説明するOOAやOOD（OOAD）のようなプロセスがあります。wikiの記事は役に立ちますが、このように機能します。開発された多くのRUPプロセスには、UMLの方法も含まれます。

ユーザーが関与するプロジェクトの標準的な注文セット（ここでも必要なものを使用）：1。ユースケース（ユーザー/システムの相互作用に焦点を当てます。2。ユースケースにドリルダウンするアクティビティ/シーケンス。3。コンポーネント/インターフェース図システムを接続しています。4。大規模なOOビルドを実行している場合はパッケージ/クラス。5。インフラストラクチャのどこに何が行われるかを示すための展開。

上にリストしたモデル/図の要素について魔法のようなものは何もありませんが、これは一般的なセットのようです。

Answer 3

実際、厳密なシーケンスがない場合は、最初に構造図を厳密に作成する必要がありますが、アクティビティ図のような動作はユーザーエクスペリエンスに応じて変わる可能性がありますか？

形態は機能に従う。動作を変更する必要がある場合は、その動作が発生する構造を変更する必要がある可能性があります。

Answer 4

ユースケース分析は、要件から目標を把握する効果的な方法です。ユースケースの説明を使用して、ドメイン オブジェクトを識別し、ドメイン モデルを作成します。CRC は公式の UML ではありませんが、この段階では有用だと思います。ドメイン モデルを作成したら、ユースケースごとにシーケンス図を作成します。ただし、アクティビティ図も便利な代替手段です。ドメイン モデルをより詳細なクラス モデルに解決しました。この段階では、展開モデルを簡単に作成できます。