Diretrizes para a descoberta de atores em casos de uso a partir do framework i*

Conforme descrito na seção 3.1, normalmente o primeiro passo na construção de Diagramas de Casos de Uso é a descoberta dos atores do sistema. Neste sentido, detectamos que o ator (atores) é um elemento importante e fundamental em ambas as técnicas i* e Casos de Uso. No entanto, existem algumas diferenças nos conceitos associados a um ator nas duas técnicas. É importante observar estas diferenças no momento do mapeamento de atores em i* para atores em casos de uso. A tabela 1 apresenta de forma resumida, alguns conceitos relacionados a atores em ambas as técnicas.

Tendo em vista algumas diferenças de conceitos de ator nas técnicas estudadas (ver tabela 1), é necessário estabelecer algumas diretrizes para auxiliar no processo de mapeamento/relacionamento de atores em i* com Casos de Uso. A seguir, apresentamos as diretrizes que permitem identificar candidatos a atores em Casos de Uso a partir dos atores definidos em i*. Estas diretrizes constituem o primeiro passo da nossa proposta.

Características de um Ator nas Técnicas i* e Casos de Uso

Ator em i* Ator em Caso de Uso

Um ator é qualquer entidade que possua intenções em um ambiente organizacional. Define-se dependências de vários tipos entre atores, para representar “como” e “porque” atores dependem uns dos outros no ambiente organizacional. Tipicamente, um ator em i* espera obter algo relevante de sistemas computacionais pretendidos.

Um ator pode incluir pessoas, sistemas ou máquinas que interagem com o sistema a ser desenvolvido;

Pode-se modelar um ator “genérico” ou “social” tendo relacionamentos estratégicos com outros atores.

Um ator desempenha um papel específico em relação ao sistema.

Atores podem representar partes/componentes do

sistema ou o próprio sistema computacional. Atores são sempre partes externas ao sistema. Eles nunca são partes componentes (internas) do sistema. Objetiva-se modelar as dependências estratégicas

entre atores bem como as razões estratégicas internas de cada ator que motivam suas ações.

Objetiva-se descrever as ações de um ator interagindo com o sistema.

Visando facilitar a leitura das diretrizes, estamos repetindo a seguir o Modelo de Dependências Estratégicas (figura 18) e o Modelo de Razões Estratégicas (figura 19), do exemplo de agendamento de reuniões apresentado no capítulo 4.

X

Figura 18. Modelo de Dependências Estratégicas para agendamento de

reuniões.

1o Passo: Descoberta de Atores

Diretriz 1: todo ator, no modelo em i*, deve ser analisado em um possível mapeamento para ator em Casos de Uso;

Para um melhor entendimento das diretrizes, analisemos, por exemplo, o ator Participante de Reunião, apresentado no Modelo de Dependências Estratégicas da figura 18;

Diretriz 2: inicialmente, deve-se verificar se o ator escolhido é externo ao sistema computacional. Atores em casos de uso nunca são partes do sistema. É necessário observar este aspecto, pois na modelagem organizacional pode-se incluir atores representando partes do sistema ou até mesmo uma abstração do software como um todo, o que na técnica de Casos de Uso não caracteriza um ator;

Observando a figura 18, verificamos que o ator Participante de Reunião participa do processo de agendamento de reuniões que considera a existência de um sistema computacional denominado Agendador de Reunião para auxiliar neste processo. Claramente o ator Participante de Reunião pode ser considerado externo ao sistema, já que o mesmo interagirá com o sistema computacional a ser desenvolvido, fornecendo informações importantes para o processo de agendamento. Sob este prisma, o ator em questão é um candidato potencial a ator em Casos de Uso.

Diretriz 3: se o ator sendo avaliado é considerado externo ao sistema computacional, conforme passo anterior, é necessário garantir o seu mapeamento para ator no Diagrama de Casos de Uso, através da seguinte análise:

Diretriz 3.1: deve-se garantir que o ator interagirá com o sistema pretendido - isto pode ser observado, se existir pelo menos uma dependência entre o ator sendo analisado e o ator que representa o sistema computacional pretendido.

Observando novamente o ator Participante de Reunião (figura 18), verificamos que existem várias dependências entre este ator e o ator Agendador de Reunião (tarefa EntrarDatasDisponíveis, recurso Concordância, etc) o que caracteriza-o como importante em um contexto de interação com o sistema pretendido. Portanto, o mesmo possui características que permitem que Participante de Reunião seja um ator no Diagrama de Casos de Uso.

Diretriz 4: em relacionamentos do tipo ISA entre atores genéricos tais como: o ator1 é (ISA) do tipo ator2, ambos os atores devem ser avaliados conforme diretrizes anteriores. Normalmente, ambos os atores são considerados atores em um Diagrama de Casos de Uso. Deve-se observar também que este tipo de relacionamento é modelado no Diagrama de Casos de Uso através do relacionamento <<generalization>> (generalização), enquadrando-se o ator 2 como uma especialização do ator 1. A notação no diagrama de casos de uso para este tipo de relacionamento entre atores foi apresentada na seção 3.2.

Por exemplo, na figura 18, o relacionamento ISA entre Participante Importante e Participante de Reunião indica que ambos os atores são candidatos a atores no diagrama de caso de uso. Conforme diretrizes anteriores já aplicadas na avaliação do ator Participante de Reunião, o mesmo pode ser considerado como ator em Caso de Uso. Da mesma forma, aplicando-se as mesmas diretrizes ao ator Participante Importante, pode-se apontar o mesmo como ator no Diagrama de Caso de Uso. O relacionamento entre ambos deve ser do tipo <<generalization>>. O ator Participante Importante deve ser anotado como uma especialização de Participante de Reunião.

As diretrizes acima permitem a elaboração de uma lista de atores para o modelo de casos de uso. Portanto, tendo os atores do sistema definidos devemos então encontrar os casos de uso do sistema associados com os mesmos. Assim, o próximo passo no processo de integração i* e Casos de Uso é encontrar possíveis candidatos a casos de uso dos atores definidos, seguido das descrições dos seus fluxos (cenário) principal e alternativos. Na próxima seção, descrevemos algumas diretrizes que podem auxiliar nesta tarefa.