なぜデータベースに二次アクターがユースケース図に含まれていないのですか？
二次アクターは、一次アクターの目標を達成するためにシステムが支援を必要とするアクターです。
建設中のシステムの外部プリンターシステムが建設中のシステムのユースケースを定義するときにセカンダリアクターとして一般的に示されている場合、データベース（建設中のシステムの外部にもある）がなぜそうでないのですか？.
このコンテキストでデータベースとプリンターの唯一の違いは、データベースサービスがシステム要求の下でデータをCRUDし、プリンターがシステム要求の下で紙を印刷することです。
データベースがセカンダリアクターでない場合、コンテンツマネージャー/エンジンまたは外部ファイル共有システム（ドロップボックスなど）として使用される他の外部システムがセカンダリアクターとして一般的に表示されるのはなぜですか？
それはすべて、設計中のシステムの境界に依存します。
個人的には、システムのユースケースをモデル化するときに、印刷システムをアクターとして含めたことはありません。印刷に関するユースケースをモデル化するとき、システムに接続された利用可能なプリンターがない場合やエラー応答などのケースを処理します。しかし、私は俳優として俳優を呼ぶつもりはありません。ファイルシステム、入力デバイス（キーボードとマウス）、その他の種類の出力デバイスについても同様です。
特に理由がない限り、私はこれらすべてを設計中のシステムの一部と見なす傾向があります。私が作成しているソフトウェアは、これらのリソースを含むより大きなシステム内のサブシステムとして常駐しています。
俳優が人間ではない場合もあるかもしれませんが、私は、プリンターシステムのようなリソースが1つのものになる時代を考えるのに苦労しています。
私はこの結論で出てきました：
要件を書くとき
クライアントがセカンダリアクター（既存のサードサービス、データベースなど）の使用を要求しない場合
次に、セカンダリアクターを使用することは設計上の決定事項であり、要件を作成するときにこれを考慮すべきではありません。ユーザーがシステムをどのように使用するか（その目標）だけをモデル化し、この相互作用の詳細を示す必要があります。
設計段階では、適切な担当者が、要件を提供するためにどのツールと外部サービスを使用するかを検討します。
クライアントが一部のセカンダリアクター（一部の既存のサードサービス、データベースなど）の使用を要求する場合
システムがプライマリアクターと対話する方法にセカンダリアクターの動作が影響する場合は、セカンダリアクターをユースケース図に追加して、ユースケース仕様に含めます。
あるユースケースの実現中にシステムがセカンダリアクターにイベントを通信する必要がある場合（プライマリアクターによってトリガーおよび実行される）、この要件をユースケース仕様のメモとして書き込みます。
システムがプライマリアクターと相互作用する方法にセカンダリアクターが影響しない場合、システムは既存の3番目のサービス/システム（クライアントから要求されるため）を非機能要件として使用する必要があると記述しますが、このアクターをユースケース図またはユースケース仕様。
デザインを書くとき
UMLダイアグラムを使用してユースケース仕様（RUPアクティビティ）を設計する場合、建設中のシステムが使用する関連する外部システムと、システムがこのセカンダリアクターとどのように統合されるかを説明します。
ほとんどの場合、データベースはセカンダリではありません。
これは設計の不可欠な部分であり、その属性と構造は構築されるシステムの一部です。
したがって、データベースが外部システムの制御下にない限り（たとえば、人事システムデータベースから従業員の名前と連絡先の詳細を取得する場合）、それは二次的なものではありません。
ファイルシステム、CPU、またはネットワークカードをセカンダリアクターとして含めないのと同じように、基盤となるDBMSソフトウェアをセカンダリアクターとして含めません。