複数のアクターが関与するプロセスをユースケースに分割することに関するアドバイス

Question

2人の俳優間の会話または交換を含むプロセスをモデリングしているとしましょう。この例では、簡単に理解できるものを使用します：-

1. サプライヤーは価格表を作成します
2. 購入者が購入するアイテムを選択して購入注文を送信します
3. サプライヤーは注文書を受け取り、商品を送ります。
4. サプライヤーは請求書を送信します
5. 購入者は請求書を受け取り、支払いを行います

もちろん、これらの各ステップ自体は、すぐに複雑になります。要件文書でこれをどのようにユースケースに分割しますか？

このプロセスが単一のユースケースとして扱われた場合、本を埋めることができます。

別の方法として、上記の各ステップからユースケースを作成すると、キャプチャする必要のある重要な相互作用とフローの一部が隠されます。 「発注書を受け取った」から始まるユースケースがあるのは理にかなっていますか？ 「請求書の送信」で終了します。次に、「請求書を受け取る」で始まる別の＆quot; Makes a Payment＆quot ;?で終了しますか？

何かアドバイスはありますか

Answer 1

通常、このようなタスクにアプローチする方法は、プロセスのUMLユースケースと高レベルのアクティビティ図の作成を開始することです。詳細については気にせず、ベストショットを与えてください。

ドラフトが作成されると、ドラフトの改善方法がすぐにわかります。その後、リファクタリングを続けることができます-ユースケースを小さくし、大規模なアクティビティを構成します。あるいは、ユースケースが小さすぎる場合は、いくつかのユースケースをまとめてまとめることもできます。

プロジェクトの詳細がわからない場合は、各ステップを個別のユースケースにします。すべて自己完結型であり、相互参照なしで説明できます。その間に依存関係が見つかった場合は、常にアプローチを再考できます。

また、ロギング、セキュリティなどの一般的な要素には「extend」ブロックと「include」ブロックの使用を検討してください

Answer 2

はい、ここには多くの可能性があります。上記の例では、購入者が請求書を支払うために複数回の部分支払いを行うことにより、さらに複雑になる可能性があります。

おそらく、完全なワークフローのユースケースを作成する必要があります。上記の各ステップを独自のユースケースに分割しても、一部のステップには事前＆amp;投稿条件。

私はQuickBooksのソースコードに取り組んでおり、トランザクションがシステムを介して流れることができる多くの方法は困難です。 QAチームがすべての組み合わせをテストすることはほとんど不可能です。