Requisitos do Sistema - Caso de uso e atores
Casos de uso
Um instrumento muito útil no desenvolvimento de sistemas é o caso de uso.
Os casos de uso são escritos em um documento que serve para orientar a construção dos demais elementos do projeto. Vamos examinar agora os casos de uso com mais detalhes.
Vamos conhecer os elementos e conceitos a eles ligados.
- Caso de uso: É uma descrição detalhada de um conjunto de interações entre um usuário e o sistema.
- Ator: É alguém ou alguma coisa que participa do caso de uso e é externo ao sistema.
Atores
Na definição de casos de uso encontramos o termo “usuário”. Nos casos de
uso o “usuário” é chamado de ator.
Temos dois tipos de atores:
a) Ator iniciador: é ele que inicia o caso de uso, geralmente, sendo o seu
ator principal. Por exemplo, se estamos fazendo um sistema bancário,
o caso de uso “retirar dinheiro” terá como ator iniciador o ator cliente;
b) Ator participante: é aquele que de alguma forma participa do caso de
uso. Por exemplo, no caso de uso “comprar itens”, existe um ator atendente que “atende” o ator cliente.
Um ator não precisa, necessariamente, ser uma pessoa. Um ator pode
representar:
a) um grupo de pessoas. Por exemplo, clientes, estudantes, etc.;
b) uma função de uma pessoa. Por exemplo, estudante representante da turma;
c) outro sistema externo;
d) um conceito abstrato como hora, data, etc. Por exemplo, o ator data
pode iniciar um caso de uso chamado “cancelar pedidos” para pedidos
feitos há mais de seis meses.
Um ator geralmente participa de mais de um caso de uso e representa papéis.
Dê um nome ao ator de forma que fique claro seu papel no sistema. Os
nomes devem ser condizentes com aqueles já usados na empresa. Dessa
forma, nossos clientes compreenderão mais facilmente o significado desse
elemento do caso de uso.
Vamos precisar encontrar todos os atores envolvidos no sistema?
A resposta a essa pergunta é SIM. E, se quiser, utilize as perguntas a seguir
para auxiliá-lo nessa tarefa:
a) Qual o principal usuário do sistema?
b) Quem fornece as informações para o sistema?
c) Quem obtém as informações do sistema?
d) Quem instala o sistema?
e) Quem opera o sistema?
f) Quem desativa o sistema?
g) Que outros sistemas interagem com o sistema?
h) Algum processo acontece automaticamente em horas predeterminadas?
i) Quem fornecerá, utilizará ou removerá informações do sistema?
j) De onde o sistema obtém informações?
Tipos de casos de uso e sua descrição
Já sabemos que um caso de uso é um documento narrativo que descreve
uma sequência de eventos de um ator (um agente externo) que usa um sistema para completar um processo.
Com relação ao nível de detalhes dessa descrição, podemos dividir os casos
de uso em dois grupos:
a) caso de uso de alto nível: descreve um processo de forma muito breve, usualmente, em duas ou três sentenças. Contém os dados: nome do
caso de uso, atores, tipo, descrição.
Exemplo de caso de uso de alto nível:
Caso de uso: Comprar itens.
Atores: Cliente, caixa.
Tipo: Primário.
Descrição: Um cliente chega a um ponto de pagamento, com vários itens
que deseja comprar. O caixa registra os itens de compra e recebe o pagamento. Ao término, o cliente deixa a loja com os itens.
b) caso de uso expandido: descreve um processo com mais detalhes que
um caso de uso de alto nível. Contém uma seção chamada sequência
típica de eventos, que descreve os eventos passo a passo. Os casos de uso
no formato expandido são muito úteis para uma melhor compreensão
dos processos e requisitos, já que eles descrevem com detalhes todos os
passos de uma operação do sistema.
Observe que a descrição da operação é bem simples e direta.
1. nome: Identificador do caso de uso: deve ser escrito em formato de verbo
+ substantivo e ser suficiente para se perceber a que se refere o caso de uso;
2. descrição geral: curto resumo do caso de uso (um ou dois parágrafos,
no máximo);
3. precondições: listagem das condições que se devem verificar quando se
inicia o caso de uso. Não incluem triggers;
4. triggers (em português: “gatilhos”): eventos que ocorrem dando início
ao caso de uso;
5. cenário de sucesso principal (linha de eventos): descreve o curso por
uma sequência de eventos numerados;
6. percursos alternativos (extensões): descrição de percursos alternativos à linha de eventos principal;
7. pós-condições: descrição do estado do sistema após a execução do
caso de uso;
8. regras de negócio: reservadas para informação adicional relativa à política da empresa ou restrições impostas pelo tipo de negócio;
9. listas de variações tecnológicas: especificações dos métodos de entrada e saída de dados e quais formatos podem ser utilizados no caso de uso;
10.frequência de ocorrência: frequência de ocorrência do caso de uso por
dia, mês, hora, etc. (Influencia no projeto, desenvolvimento ou implantação do sistema?);
11.notas: informações adicionais relativamente ao caso de uso, não cobertas pelos dados anteriores;
12.autor e data: listagem dos autores e datas das várias versões revistas.
Ao longo de nossa disciplina veremos vários exemplos desses dois tipos de
casos de uso.
a) Identificação dos casos de uso
Os casos de uso são encontrados e descritos por meio de entrevistas e
brainstorms. O roteiro mais indicado para a aplicação dessas técnicas é:
1. identificação de todos os atores;
2. identificação de todos os casos de uso;
3. descrição simples de cada caso de uso;
4. desenho de um diagrama de casos de uso.
Não espere encontrar todos os casos de uso e atores na primeira sessão. É
natural aparecerem casos de uso e atores nas fases seguintes do desenvolvimento, isto é, durante o processo de construção do software.
Para ajudar nessa tarefa, as seguintes perguntas podem ser úteis:
a) Quais as principais tarefas desse papel (ou ator)?
b) O que os usuários nesse papel precisam ser capazes de realizar?
c) Por que os usuários nesse papel precisam realizar essa tarefa?
d) Quais informações os usuários nesse papel necessitam examinar, criar
ou alterar?
e) Quais informações os usuários nesse papel necessitam saber pelo sistema?
f) Quais informações os usuários nesse papel precisam informar ao sistema?
Um erro comum na identificação de caso de uso é representar como casos
de uso passos individuais, operações, ou transações. Um caso de uso é uma
descrição completa de um processo relativamente grande, que inclui, tipicamente, muitos passos ou transações.
Exemplo de levantamento
Suponha que você estivesse levantando as informações sobre os casos de
uso de um sistema acadêmico usado por funcionários da secretaria de uma
escola. Para isso, você escolheu a técnica de entrevista. Quais perguntas você
colocaria no roteiro dessa entrevista? Formulando apenas cinco perguntas,
poderiam ser utilizadas as seguintes:
1. Quais informações sobre estudantes e professores vocês precisam guardar na secretaria desta escola?
2. Quais as principais tarefas desempenhadas pelo funcionário responsável
pela matrícula de estudantes?
3. Quais as informações o diretor da escola precisa ter sobre professores
e estudantes?
4. Por que a secretária escolar precisa cadastrar estudantes novatos apenas
no início de cada ano letivo?
5. Quais as informações os professores precisam saber sobre suas turmas
pelo sistema?
b) Granularidade dos casos de uso
Um aspecto que pode ser complicado para o iniciante é decidir a granularidade dos casos de uso, ou seja, a qual nível de detalhamento devemos
descer ao definirmos uma funcionalidade.
Exemplo de levantamento:
Em um sistema de Caixa Eletrônico, temos uma funcionalidade chamada
Retirar Dinheiro. Essa funcionalidade irá requerer as seguintes interações:
a) entrar cartão;
b) entrar senha;
c) selecionar quantia desejada;
d) confirmar quantia;
e) remover cartão;
f) retirar recibo.
Cada uma dessas interações deve ser um caso de uso?
A resposta é NÃO. Esse é um erro clássico na construção de casos de uso. Os
casos de uso devem ser definidos para as funcionalidades do sistema e não para
as interações. Dessa foram, mantemos a complexidade do caso de uso baixa.
Uma boa regra é: um caso de uso deve satisfazer a um objetivo do usuário.
Aplicando essa regra simples ao exemplo acima, podemos fazer a seguinte
pergunta: Retirar Recibo (item 6) é um objetivo do usuário? Ou seja, o objetivo do usuário desse sistema é apenas Retirar Recibo? A resposta é NÃO.
Então, Retirar Recibo não será um caso de uso.
Aplicando essa regra aos outros itens da lista, vemos que a resposta é NÃO para
todos eles. O objetivo real do usuário é retirar dinheiro, logo, Retirar Dinheiro
deve ser o caso de uso, isto é, o nome do caso de uso será Retirar Dinheiro.
c) Relação entre casos de uso e funções do sistema
As funções do sistema representam o que o sistema deve realizar. Assim,
devemos ter casos de uso que implementem essas funcionalidades.
Algumas vezes uma função resultará em um único caso de uso; outras vezes,
várias funcionalidades resultarão em um único caso de uso.
d) Ordem de implementação dos casos de uso
Com o desenvolvimento iterativo vamos implementar um caso de uso em
cada ciclo de desenvolvimento. Com casos de uso muito complexos, podemos implementar versões simplificadas dele. Com casos de uso muito simples, podemos implementar mais de um caso de uso em um único ciclo.
Então surgem as perguntas: Que casos de uso devemos implementar primeiro? Qual ordem de implementação dos casos de uso é melhor?
Recomendamos que você implemente primeiro os casos de uso mais
importantes.
Para classificar os casos de uso, considere:
a) Causa impacto significativo no projeto da arquitetura?
b) Possui quantidade significativa de informações e compreensão?
c) Possui quantidade significativa de funções de alto risco?
d) Envolve pesquisa significativa ou tecnologia nova e com riscos?
e) Contém representação de processos primários da linha de negócios?
f) Possui influência direta no aumento da receita ou na diminuição de custos?
Quanto mais respostas “SIM” você obtiver nessas perguntas, mais importante será o caso de uso em questão. Assim, podemos criar uma lista de caso
de usos numa ordem decrescente de importância. Os primeiros casos de uso
listados serão os primeiros a ser implementados.
e) Diagrama de casos de uso
Um diagrama de casos de uso é uma representação gráfica dos casos de uso
e dos atores envolvidos no sistema em análise.
Um diagrama de casos de uso mostra os atores e casos de uso de forma
gráfica. Seu objetivo é dar uma visão geral dos casos de uso necessários ao
sistema de forma a facilitar a compreensão por todos os envolvidos na equipe de desenvolvimento do novo software.
Os símbolos que utilizamos são: Elipse, retângulo, linha e seta como mostrados na Figura 3.1:
O diagrama de casos de uso é muito interessante para dar uma visão geral
do sistema, com seus atores, casos de uso e a relação entre eles.
