ユースケースケースベースユースケースユースケース（インクルード関係）がある場合は基本フローユースケースシナリオに含めます。例：ユースケースシナリオを書くときに、拡張ポイントがある場合はどうすればよいですか？
UC name : Pay Bill
Actor : Customer
Basic Flow : 1. Include ::(Validate User Login).
2. Press View Unpaid bills button.
3. System show list of unpaid bills.
etc...
拡張ポイントとの拡張関係がある場合はどうなりますか？ユースケースのシナリオでどこで言及する必要がありますか？
<<extends>>リレーションは、何らかの条件にバインドされている点を除いて（無条件）<<include>>と同じです。だからあなたはあなたのやり方と同じように書くことができます。
どこに書きますか？基本的な流れで？または別の流れで？ –
心配しないでください。ありがとう。 –
私はあなたがそれを推測したと思います;-)もちろん、それは晴れた日か代替シナリオのいずれかになることができる流れの条件付き部分にあります。これは、拡張が条件付きインクルードであることだけです。 –
基本フローには、UC実行時に最も頻繁に発生する手順が記載されています。あなたはオプションを置くことはありません。前提は簡単です。すべてが正常であれば、基本フローで説明した手順を実行します。
任意の偏差（かなり頻繁に起こっていても）が代替フローに配置されます。基本フローとは異なるステップだけが一覧表示されます。代替フローは、トリガーされた後に代替フローのステップが続く条件で開始されます。最後のステップは、ある種の全体フロー終了か、基本フローへの復帰（必ずしも同じ場所を離れたわけではありません）のどちらかです。
代替フローは、1つの可能なフローのみを示しています。さらなる偏差が可能であれば、新しい代替フローが発生します（代替は代替となる可能性があります）。
代替フローでは、UCの拡張が自動的に行われるわけではありません（逆に、1つのUCに複数のフローが存在する可能性がありますが、まれに一部のフローUCを拡張する）。
次のように代替フローがある可能性がありますあなたの場合は：
3a No unpaid bills
3a1 System shows pop-up message "No unpaid bills"
3a2 User clicks OK button
3a3 System returns to main screen
はいを、拡張して。しかし、それは "名目上の"シナリオではない。 –