ユースケース図にシステムをアクターとして含める必要があるのはいつですか？
新しいシステムのユースケース図を作成しています。システムをユースケース図のアクターとしていつ含める必要があるのでしょうか。
ありがとう。
別の回答で述べたように、アクターは開発中のシステムと相互作用するシステムまたは役割です。開発中のシステムの外部にあり、開発中のシステムと直接対話する場合は、ユースケースにシステムをアクターとして含める必要があります。
システムの境界、つまりそのスコープとインターフェースを定義する必要があるため、これは重要です。システムをアクターとして含めると、開発中のシステムがそのアクターシステムに適切なインターフェースを提供するための要件が明確に示されます。
UMLで正しくモデル化する方法については、人々によって考え方が異なります（UMLが委員会によって標準化されたため、これは当然のことです）。
私は、アクターを使用して、設計しているシステムと対話できるすべての「もの」（人のタイプ、システムのタイプ）をキャプチャし、新しいシステムがどのように対話されるかについてすべての利害関係者の間で共通の理解を生み出すのに役立ちます。
私は、システムと対話することがわかっているすべてのものに対してアクターを作成し、そのアクターが実行できるすべてのユースケースまでそのアクターを追跡することをお勧めします。これにより、誰が何をできるかを完全に理解できます。
システムはユースケースモデルのアクターにはなりません。プロセスを実行するには、調査中のシステムをトリガーしているものについて考える必要があります。システム自体は馬鹿げており、行動を起こすことはできません。これは、ユーザーまたは時間によってのみトリガーできます。システムがアクションをトリガーしていると思われる場合は、おそらくTimeがアクターです。たとえば、電子メッセージを受信すると、プロセスがトリガーされて実行されます。このプロセスは完全に自動化されており、ユーザーがシステムにメッセージが到着したため、誰が俳優であるかをシステムに伝えることによってトリガーされませんか？システムではなく時間です。あなたが想像しなければならないのは、電子メッセージの到着を探すプロセスがあり、これは特定の時間間隔、例えば1秒ごと、1分ごと、または1か月に1回などです。したがって、電子メッセージの受信時に実行されるプロセスをトリガーするのは時間です。