ユースケース図とアクティビティ図、鶏が先か卵が先か？
私はUML行動図についての考え方に疑問を投げかけたり、おそらく挑戦したいと思っています。
まず、最初に何が最初に来るのかを尋ねたいと思います：ユースケースまたはアクティビティ？
ユースケース図が最初に来て、次に各ユースケースについて、成功した代替フローを表す1つ以上のアクティビティ図があることを教えられました。アクティビティ図から、クラスを確立するための名詞を識別できます。
ただし、エンドツーエンドプロセスのアクティビティ図を作成し、そこからユースケースを特定できるという他の記事を読んだことがあります。
私は両方のシナリオが機能しているのを見ることができ、私にはそれが階層の場合のように思われるので混乱しています。たとえば、「学生の成績の採点」という高レベルのビジネスプロセスがあるとします。それをアクティビティ図としてマップすると、その中にスイムレーンが表示されます。 「成績の境界を決定する」、「結果を送信する」、「結果を成績に変換する」などのユースケースを選択することができます。
それらは同じものであると主張することができます。つまり、両方の図がこのプロセスモデリングのニーズを満たします。次に、次のレベル、たとえば「結果の送信」方法をモデル化します。
誰かがベストプラクティスについてアドバイスできますか：ユースケース図がアクティビティ図の前に来るのか後に来るのか？
最初：
「最初の図」となるUML図の間に競合はありません。一部の図を同時に繰り返し作業する方がよい場合もあります。
2番目：
各図は、さまざまなコンテキストでさまざまな目的に使用できます。
ユースケース図とアクティビティ図
「ユースケース」は、ユーザーがシステムを使用して目標を達成する方法を示すシナリオです。
そう：
この「シナリオ」を書面によるユースケースで示す代わりに、アクティビティ図でそのステップを視覚化できます。
ただし、ユースケースを見つけるには、システム要件を発見するある程度（範囲、幅広い機能セット、優先度、コストなど）にする必要があります。
自動化プロジェクトなどの一部のビジネスドメインでは、要件/ユースケースを見つけるために、現在のビジネスフローを調査する必要がある場合があります。このビジネスフローは複雑な場合があるため、アクティビティ図を使用して調査することをお勧めします。
そう：
アクティビティ図を使用してビジネスプロセスを調査できますフローを理解して発見し、要件をより適切に発見します。
そう：
アクティビティ図は、さまざまな目的のために、ソフトウェア開発段階のさまざまなレベルで使用できます。
他の図と同様に、アクティビティ図は、適切な質問をしたり、目的に関連する問題を理解して調査したりするのに役立つとすぐに、いつでもどこでも使用できます。
アクティビティ図の目的の概要は次のとおりです。
アクティビティ図の目的は、より大きなアクティビティの一部であるアクションの手続きフローをモデル化するです。ユースケースが存在するプロジェクトでは、アクティビティ図は特定のユースケースをより詳細なレベルでモデル化できます。ただし、アクティビティ図は、ビジネスレベルの機能をモデル化するためのユースケースとは関係なく使用できますコンサートチケットの購入や大学のクラスへの登録など。アクティビティ図システムレベルの機能のモデル化にも使用できますチケット予約データマートが企業の販売システムのデータウェアハウスにデータを入力する方法など。 MLの基本：Donald Bellによるアクティビティ図
どの図をどの目的に使用できるかをすばやく把握するには、Scott W. Amblerのミニブックを確認することをお勧めします。 The Elements of UML（TM）2.0 Style
アクティビティ図は、UMLで最も抽象化範囲が広いものの1つです。アクティビティは、ビジネスプロセス（非常に抽象的で、ソフトウェアシステムと比較して）と単一メソッドアルゴリズム（コードレベル、実質的に青写真、一種の抽象化グラウンドレベルを意味する）の間のあらゆるものに使用できます。
ユースケース反対側では、実際には抽象化が非常に制限されています。これらは、ユーザーとシステム間の相互作用を示しており、抽象化スケールの中間にあります。ビジネスプロセスほど抽象的ではなく、実装図よりもはるかに抽象的です。
ソフトウェアプロジェクトは、非常に抽象的なレベル（たとえば、ビジネス目標）で作業を開始し、抽象化0（実装されたシステム）で終了する傾向があります。プロジェクトアナリストの間、アーキテクトと開発者は協力してこの抽象化を徐々に下げます常に抽象度の低いアーティファクト/モデルを生成します-ビジネスプロセス、ユースケース、アーキテクチャ、設計、コード。
この紹介の後、あなたの質問に答えるのは難しくありません-それらのどれでも最初に使うことができます、そしてそれはあなたのプロジェクトのタイプとそのサイズに依存します。いくつかの例：
- 大規模な開発プロジェクトERPシステム。この種のプロジェクトで最初にモデル化するのはビジネスプロセスであることはほぼ確実です。その機能について考えるずっと前に、チームはビジネスの背景を理解します。これに最適なUMLダイアグラムは、当然、アクティビティダイアグラムです。しばらくして、プロセスが明確になり、高レベルの要件がわかったときに、ユースケース =モデリングを開始できます。
- バックグラウンドで複雑なプロセス（モバイルアプリ開発など）がない中規模の比較的小さなプロジェクトは、直接開始できますユースケースを使用、ユーザーとその機能を識別します。後で、これらはactivitiesを使用してさらに改良できます。
- いくつかのインターフェースの非常に小さな開発、通信ゲートウェイのドライバー、高度に技術的で、ユーザーの操作さえ最小限である場合、モデリングは再びactivitiesで開始でき、具体的なアルゴリズムも実装されていることを示します。ユースケースは完全にスキップできます。
要約すると、ソフトウェア開発にはこの種の破られないルールはないと結論付けます。各プロジェクトは独自のものであり、各開発方法論は独自のものであり、各開発チームも特別で独自のものです。最初に行う「どの図」について考えることは、まっすぐで単純に間違っています。特定の瞬間に必要な分析または仕様の種類について考えてください。モデル化するのに最も簡単で最も役立つものは何ですか。これが明らかな場合、目的を最適に達成するためにピックアップする13のUML図があります。
UML図の選択は「方法」です。それよりも重要なのは、多くの場合、「何」です。
ユースケース図は機能を示すためのものであり、アクティビティ図は操作を示すためのものです（1つの機能は多くの操作を持つことができます）。例えば。ユースケース診断。 Moher（多くの子供を持つことができます）とActivitydiagです。母の子を説明するようなものです。つまり、ユースケース診断です。