根据UML规范：
用例定义了主题提供的行为，而不参考其内部结构。这些行为涉及参与者与主体之间的交互，可能导致主体的状态以及与其环境的通信的改变。
这意味着，一旦你基于系统的内部设计分析用例或参与者，你就走上了错误的道路。
你的用例应该关注为用户增加的价值，而不是技术解决方案：
当一个用例应用于一个主体时，它指定了该主体执行的一组行为，这产生了一个可观察的结果，该结果对参与者或该主体的其他利益相关者有价值。
考虑到actor可以是system，如何检查FireBase是否是actor？

• 第一个问题是，这对用户来说很重要。您的应用的最终用户是否对此候选次要参与者感兴趣？最有可能的是，最终用户并不在乎。
• 第二个问题是，次要参与者是否独立，它是否有自己的业务目的，而您的系统正在帮助实现这些目的？
• 第三个问题是，次要演员是否可以切换到另一个次要演员？

Firebase不符合这些条件。所以走那条路可能不是个好主意。