アクションがサードパーティのシステムを通過するユースケース図
GitHubへのコミットが行われたときにコードの静的分析を行うシステムを作成しています。結果はGitHubレビューとして表示されます。
私の問題は、実際にはGitHubがこれを行うため、開発者（俳優）が私のシステムに関与しないことを意味します。開発者（俳優）はGitHubを使用しており、GitHubで私のシステムの結果を確認できるため、実際に私のシステムを直接使用することはありません。
以下の図では、これを実際にうまく捉えていないように感じます。
次に、別の図を作成しました。開発者（俳優）がGitHub（俳優）と通信し、GitHubが私のシステムと通信します。
しかし、これも間違っているように見えますが、それでも以前よりは優れています。これに関する私の大きな問題の1つは、GitHubが左側にあるということですが、GitHubは一種の主要な俳優なので、それも理にかなっています。これを行っているユースケース図の例を見たことがありませんが、これは実際に有効ですか？さらに重要なことに、それは意味がありますか？ 
副次的な質問：CTO（俳優）には、次のようなユースケースがあります。
CTOとして、ツールを実行しているサーバーにコードを保存しないようにしたいので、コードの漏洩を心配する必要はありません。
私にはこれは有効なユースケースのように聞こえますが、ユースケース図に入れると、これは実際にはアクションではないので、それ以上の要件です。これは機能要件の一部のようにすべきですか？
編集：だから私は皆さんからの推奨に基づいてそれを改善しようとしました。
機能的または機能的な要件が多かったため、多くのユースケースを削除することになりました。次に、コミットがプッシュされたときにツールがリモートで実行されていることを示すように変更しました。正しく実行されたかどうかはわかりません。 
これに関する私の大きな問題の1つは、GitHubが左側にあるということですが、GitHubは一種の主要な俳優なので、それも理にかなっています。これを行っているユースケース図の例を見たことがありませんが、これは実際に有効ですか？さらに重要なことに、それは理にかなっていますか？
主な俳優が人間でなければならないことはどこにも定義されていません。システムが認識できる限り、Githubがサービスを呼び出すことを自律的に決定している場合、Githubは間違いなく主要なアクターです。その場合、開発者をそのユースケースの二次ユーザーとして見ることが理にかなっています。
別の見方をすると、開発者はコミットされていないコードでローカルにツールを実行したり、コミットでリモートでツールを実行したりできます。その場合、開発者はユースケースの主要なアクターであり、コミットで実行するためのユースケースは、ユーザーがリポジトリにコミット/プッシュするアクションから始まります（そして、リポジトリが実行するように構成されているという前提条件があります）。コミット/プッシュアクションのツール）。次に、対象者に応じて、リポジトリは実際にはシステムの一部ではないが、システムが呼び出されるタイミング/方法を明確にするためにユースケースステップに含まれることを説明または説明します。
副次的な質問：CTO（俳優）には、次のようなユースケースがあります。
CTOとして、ツールを実行しているサーバーにコードを保存しないようにしたいので、コードの漏洩を心配する必要はありません。
私にはこれは有効なユースケースのように聞こえますが、ユースケース図に入れると、これは実際にはアクションではないので、それ以上の要件です。これは機能要件の一部のようにすべきですか？
これは有効な「ユーザーストーリー」ですが、有効なユースケースではありません。これは、アクターとシステム間の相互作用ではなく、そのため、ユースケースではありません。
ユーザーストーリーとしても、一度実装して完了マークを付けることができる機能要件ではないため、少し問題があります。これは実際には、システムの開発中に常に心に留めておくべき非機能的な要件です。