Se crio um modelo de casos de uso, com um ator “Usuário” e um caso de uso qualquer. Suponha que quero guardar alguma informação sobre esse usuário, por exemplo o nome, e para isso vou querer criar uma classe “Usuário”. Vou precisar criar uma nova classe para representar o usuário ou a UML subentende que o ator “Usuário”, a partir do momento em que é criado como ator, já é uma classe que faz parte do sistema? Nesse caso, posso então simplesmente atribuir o atributo “nome” ao ator “Usuário”? Posso atribuir, também, métodos? Se for assim, um ator pode implementar uma interface (por exemplo, o ator “Sistema de pagamento PagSeguro” pode implementar a interface “Sistema de pagamento”)? O exemplo pode ser implementado como herança de classes, mas fica a pergunta: um ator pode implementar uma interface?
Em UML, caso de uso não tem ligação direta com modelo de classes. Atores são apenas representação de pessoas/equipamentos/outros sistemas/etc que interagem com o seu caso de uso/sistema.
Agora se você está dizendo que você está usando um programa que representa atores como classes, dai é coisa específica do seu programa.
O que geralmente faço é mapear atores como os perfis que vou criar para acessar o sistema, mas sem uma ligação direta com classes.
Um ator é quem usa o sistema, ou seja um usuário. Mas, um ator não é uma classe, você deve criar um caso de uso para o usuário (uma classe e os outros diagramas), com os seus respectivos atributos e ações.
Definitivamente não. Atores de maneira geral são agentes externos ao sistema que está sendo modelado, podem ser pessoas, equipamentos ou até mesmo outros sistemas, mas tenha em mente que eles são externos.
Como o camarada já disse, Use Case não enxerga as classes ainda.
É uma abstração dos núcleos funcionais, aquilo que irá conter classes.
Eventualmente, na evolução do design/análise, pode ser que o usuário venha a ser representado por uma classe (no diagrama de classes), lifetime (diagrama de sequência) ou pode constar no diagrama de estados, se houver alteração em seu estado, durante a execução de determinado use case. Como exemplo, um sistema gerenciador de emails, o ator que interage com o caso de uso é o próprio objeto da classe que faz o logon e lê os seus emails (que são outros objetos de outra classe).
Via de regra, não misture as coisas, irá apenas dificultar o entendimento.
Esta mistura de “camadas” pode levar à outros erros comuns, tentar abstrair os pacotes para os use cases, por exemplo.
Ator é ator, interage com casos de uso. Classes são classes, interfaces, abstracts, etc que se relacionam com classes e packages.