9

私は、UML 動作図に関する学派に疑問を呈したり、おそらく異議を唱えたりしたいと考えています。

最初に質問したいのは、ユースケースとアクティビティのどちらが先かということです。

ユースケース図が最初に来て、次に各ユースケースについて、成功した代替フローを表すために1つ以上のアクティビティ図があることを教えられました。アクティビティ図から、名詞を識別してクラスを確立できます。

ただし、エンド ツー エンド プロセスのアクティビティ図を作成し、そこからユース ケースを特定できるという他の記事を読みました。

両方のシナリオが機能していることがわかり、混乱しています。階層のケースのように思えます。たとえば、「学生の成績評価」という高レベルのビジネス プロセスがあるとします。それをアクティビティ図としてマッピングすると、その中にスイムレーンが表示されます。「成績の境界を決定する」、「結果を提出する」、「結果を成績に変換する」などのユースケースを選択できます。

これらは同じものであると主張することもできます。つまり、両方の図がこのプロセス モデリングのニーズを満たします。次に、たとえば「結果を送信する」方法など、次のレベルをモデル化したいと考えています。

誰かがベストプラクティスについてアドバイスできますか: ユースケース図がアクティビティ図の前か後か?

4

3 に答える 3

20

初め：

「最初の図」となる UML 図の間に競合はありません。いくつかのダイアグラムを同時に繰り返し処理した方がよい場合があります。

2番：

各ダイアグラムは、さまざまなコンテキストでさまざまな目的に使用できます。

ユースケース図とアクティビティ図

「ユースケース」は、ユーザーがシステムを使用して目標を達成する方法を示すシナリオです。

そう：

この「シナリオ」をユースケースで示す代わりに、アクティビティ図でそのステップを視覚化できます。

ただし、ユース ケースを見つけるには、システム要件をある程度把握する必要があります (範囲、幅広い機能セット、優先度、コストなど)。

自動化プロジェクトなどの一部のビジネス ドメインでは、要件/ユース ケースを発見するために、現在のビジネス フローを調査する必要がある場合があります。このビジネス フローは複雑な場合があるため、アクティビティ図を使用して調査することをお勧めします。

そう：

アクティビティ図を使用してビジネス プロセスを調査し、フローを理解して発見し、要件をより適切に発見することができます。

そう：

アクティビティ図は、ソフトウェア開発段階のさまざまなレベルでさまざまな目的に使用できます。

他の図と同様に、いつでもどこでもアクティビティ図を使用して、適切な質問をしたり、目的に関連する問題を理解して調査したりすることができます。

アクティビティ図の目的の概要は次のとおりです。

アクティビティ図の目的は、より大きなアクティビティの一部であるアクションの手順フローをモデル化することです。ユース ケースが存在するプロジェクトでは、アクティビティ図を使用して特定のユース ケースをより詳細なレベルでモデル化できます。ただし、アクティビティ図は 、コンサート チケットの購入や大学のクラスへの登録など、ビジネス レベルの機能をモデル化するためのユース ケースとは無関係に使用できます。アクティビティ図は、チケット予約データマートが企業の販売システムのデータ ウェアハウスに入力する方法など、 システム レベルの機能をモデル化するためにも使用できます。UML の基本 : Donald Bell によるアクティビティ図

どのダイアグラムをどの目的に使用できるかを簡単に把握するには、Scott W. Ambler のミニブック「The Elements of UML(TM) 2.0 Style 」を参照することをお勧めします。

于 2013-09-30T14:23:27.047 に答える
13

アクティビティ図は、UML で最も抽象化の範囲が広いものの 1 つです。アクティビティは、ビジネス プロセス (ソフトウェア システムと比較して非常に抽象的) と単一メソッド アルゴリズム (コード レベル、実質的に青写真、一種の抽象化の地上レベルを意味する) の間のあらゆるものに使用できます。

反対側のユースケースは、実際には抽象化が非常に制限されています。それらはユーザーとシステム間の相互作用を示し、抽象化スケールの中間のどこかにあります。ビジネス プロセスほど抽象的ではなく、実装図よりもはるかに抽象的です。

ソフトウェア プロジェクトは、非常に抽象的なレベル (たとえば、ビジネス目標) で作業を開始し、抽象化 0 (実装されたシステム) で終了する傾向があります。プロジェクト アナリストの間、アーキテクトと開発者は協力してこの抽象化を徐々に下げ、ビジネス プロセス、ユース ケース、アーキテクチャ、設計、コードなど、常に抽象度の低いアーティファクト/モデルを生成します。

この紹介の後、あなたの質問に答えるのは難しくありません。プロジェクトのタイプとそのサイズに応じて、最初にどれを使用してもかまいません。いくつかの例：

  1. ERPシステムを開発する大規模プロジェクト。この種のプロジェクトでは、最初にモデル化するのはビジネス プロセスであることはほぼ確実です。その機能について考えるよりずっと前に、チームはビジネスの背景を理解する必要があります。これに最適な UML 図は、もちろんアクティビティ図です。しばらくして、プロセスが明確になり、高レベルの要件が判明したら、ユース ケースのモデリングを開始できます。
  2. バックグラウンドで複雑なプロセス (モバイルアプリ開発など) がない中規模の比較的小規模なプロジェクトは、ユーザーとその機能を特定して、ユースケースから直接開始できます。後で、アクティビティを使用してこれらをさらに絞り込むことができます。
  3. いくつかのインターフェイスの非常に小さな開発、通信ゲートウェイのドライバー、非常に技術的で、ユーザーとのやり取りが最小限である場合、モデリングは再びアクティビティから開始でき、具体的なアルゴリズムも実装されることを示します。ユースケースは完全にスキップできます。

要約すると、ソフトウェア開発において、この種の破ることのできないルールは存在しないと結論付けます。各プロジェクトはユニークであり、各開発方法論もユニークであり、各開発チームも特別でユニークです。最初に「どの図」を作成するかを考えるのは、単純に間違っています。ある瞬間にどのような分析や仕様が必要かを考えてください。モデル化するのが最も簡単で最も有用なものは何かを考えてください。これが明確な場合、目的を最適に達成するために、13 の UML ダイアグラムからピックアップする必要があります。

UML図の選択は「HOW」です。それよりも重要なのは、多くの場合、「WHAT」です。

于 2014-05-22T17:52:04.950 に答える
0

ユースケース図は機能を示すためのもので、アクティビティ図は操作を示すためのものです (1 つの機能に複数の操作を含めることができます)。例えば。ユースケース診断 Moher (多くの子を持つことができます) と Activity diag です。Mother ie Use Case diag の子を記述するようなものです。

于 2016-08-31T04:06:22.987 に答える