2つのユースケースを同時に拡張または含めることはできますか?A拡張/インクルードBおよびB拡張/インクルードA
7 に答える
答えは「NO」だと確信しています。
ニワトリが先か卵が先かという問題のデジタル版を説明しましたね。
循環参照は [ほぼ] 常に悪いこと (tm) です。恐ろしくないと私が知っている唯一の場所は、リンクされたリストのコンテキストであり、各エントリには独自のタイプの別のエントリへのポインタがあります。
(A が B を含む/拡張し、B が A を含む/拡張する) 場合、A = B
A が B を拡張/含む場合、A >= Bであることを認める
まれですが、一般的なケースでは、ユースケースが相互に包含/使用することを妨げるものは何もありません。
答えはいいえだ。extendsとincludeは、相互に排他的な関係タイプです。ほとんどの場合、ユースケースが誤って因数分解/分離されているか、拡張/包含関係の定義を誤解しているか、またはその両方です。
あなたが投稿した例を考えると(元の質問に答えない回答を投稿するよりも、質問を編集する方が良いです)どちらの場合もAとCの追加の修理があるので、BはAを拡張しBはCを拡張します(ケースB)が識別される場合があります。
あるいは、ユースケースAとCには、条件付きでユースケースBを含めることができます。
オフハンドでは、これをWork On Vehicleとしてモデル化します。これは、2つのユースケース、顧客承認の取得、およびサービス車両の構成であり、後者にはあらゆる種類のサービスまたは修理が含まれ、作業を開始する前に前者の出力が必要です。 。「追加の修理」の概念は、WorkOnVehicleの単なる別の例です。
しかし、私は完全なビジネスコンテキストを知らないので、あなたのマイレージは変わるかもしれません;-)
編集:あなたは「しかしこの場合:作業が行われており、作業の過程でさらなる承認が必要です」と書いたが、それが実際にどのように重要であるかはわかりません。
最初のステップは、インクルードとエクステンドに関する混乱を排除することです。各ユースケースを完全かつ独立してモデル化してから、インクルード/エクステンドが必要かどうかを確認するために一般的なものを確認してください
「はい」-仕様を確認しました。
ユースケースについては、UML仕様のセクションを読んだばかりです 。http ://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ これを妨げるルールはありませんでした。多くの人が概念的にこれに問題を抱えているかもしれませんが、ユースケースを論理的に客観化または構造化しようとしているだけなので、それは問題ありません。ユースケースは動作(またはセット)であり、クラス/「オブジェクト」とは異なります。Javaオブジェクトについて話しているのではありません。
Rational Software Modeler(IBM)でも、この「循環参照」が可能です。
実際には、これをJavaまたは他のオブジェクト言語にマップしようとすると、意味がないか、混乱する可能性があります。
そうではないように思えますが、十分に一般的な[そして役に立たない]場合は、それを行うことができると確信しています。具体例はありますか?規則には常に例外があり、それを見てみたいと思います。
以下は、システム ユース ケースではなく、ビジネス ユース ケース (ビジネス モデリング) のシナリオです。
追加の修理は、初期修理中に確認できます。または修理がサービス中に新しい修理として識別される可能性があります。どちらの場合も、顧客の承認が必要ですか?
A 拡張 B およびB 拡張 C (サービス中に識別された承認および修理の開始)
C エクステンド B (修理中に特定された追加修理の承認)