シーケンス図のデータベースは、アクターまたは境界として表現されますか？
Webアプリケーションとデータベースで構成されたシステムを設計しています。 <<Entity>>-<<Control>>-<<Boundary>> UML図のステレオタイプ。
次のシーケンス図では、すでにクラウド内のシステムとのやり取りがあります。 （同じサーバー上の）内部データベースも表示したいと思います。私はそれを俳優または<<Entity>>？また、データベースから情報を取得する必要がある場合、データベースとエンティティの間に境界オブジェクトを配置しますか（cloudBoundaryとStudentとクラウドシステムの間に）？
短縮版：
データベースは、サーバー上でローカルであっても、技術的にはクラウドシステムと同じ役割を果たします。したがって、俳優でそれを表すことができます（実際に何かを選択する必要がある場合）。
データベースはシステムの外部にあるため、他のオブジェクトが相互作用できるように、いくつかの境界オブジェクト（例： gateways ）が必要です。
解説
Entity-Control-Boundary アプローチは、ユースケースモデリングと密接に関連しています。
- 彼らの発明者であるIvar Jacobsonのアイデアは、特定されたユースケースを実装するためにシステムで必要なクラスを体系的に導出することでした。
- したがって、哲学は、境界クラスがアクターとユースケース間のリンクを表し、制御クラスがいくつかのユースケースにマッピングされ、エンティティクラスがドメインオブジェクトを表すことです。
ユースケースモデルでは、アクターは、ユースケース（アクターの意図またはビジネス要件）を達成するためにシステムと対話する人間または外部システムです。このため、通常、データベースはユースケース図の一部ではありません。
ユースケースサーフェスの下を掘り下げると、データベースが表示されます。データベース自体は、エンティティでもコントロールでも境界でもありません。ユースケースの観点から見ると、データベースは検討中のシステムの一部として理解できます（データベースはビジネス対話に関与する外部システムではないため）が、技術的には、システムの外部にある独立したコンポーネントのままです。開発中です。
<<Entity>>ステレオタイプは、完全にECBの理解に沿ってUMLで標準化されたほど一般的です。
<<Entity>>：ビジネスコンセプトを表す永続的な情報コンポーネント。
明らかに、この理解によると、データベースはエンティティではありません。システムの一部として独自のデータベースを一から開発する場合でも。
<<Boundary>>と<<Control>>は 非標準ステレオタイプ です。ただし、外部データベースにアクセスする必要がある場合は、コネクタ/ゲートウェイとして機能する境界オブジェクトが必要です。
システムの一部としてデータベースを最初から開発する場合、データベース自体は、他のコントロールやエンティティとの関連で情報の流れややり取りを管理する多数の<<Control>>オブジェクトで構成されます。および境界（特に、ファイルシステムへの境界を表すストリームオブジェクト）。