UNIVERSIDADE ESTADUAL PAULISTA “JÚLIO DE MESQUITA FILHO”

INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS

TRABALHO DE ENGENHARIA DE SOFTWARE I

Profº Allan de Godoi Contessoto

ESTUDO SOBRE CASOS DE USO

LORRAINE MARIA PEPE

lorraine.pepe@unesp.br

19 de abril de 2018
São José do Rio Preto, SP
 ESTUDO SOBRE CASOS DE USO

1) INTRODUÇÃO
Quando mencionamos a palavra caso na língua portuguesa geralmente
estamos associando a descrição ou narrativa de algum fato. Por exemplo, casos
de polícia, casos de família, etc.
Casos de uso, do inglês use case age na mesma linha de raciocínio, tem por
objetivo contar, descrever, mostrar as funcionalidades de um sistema a alguém
interessado no projeto, em sua maior parte desenvolvedores e seus clientes.
“Você pode imaginar um caso de uso como um conjunto de cenários, onde
cada cenário é uma sequência de passos a qual descreve uma interação entre
um usuário e o sistema”. [2]
Ocorre que, no ramo da Engenharia de Software, há um conjunto de regras
a ser seguido que padroniza o formato dos casos de uso a fim de que se tornem
de fácil compreensão a qualquer leitor. Veremos no decorrer do estudo como
são feitos.

1) ORIGEM

Desde a década de 80 especialistas da área de computação buscam acelerar

o processo de produção de sistemas, o que inclui o levantamento e validações
de requisitos.
A técnica de Engenharia de Software orientada a objetos (OOSE) proposta
por Ivan Jacobson usada até hoje para identificação de requisitos é o alvo desse
estudo: Casos de Uso. Tal técnica já foi aprimorada por diversas pessoas e
também incorporada à linguagem UML para representação gráfica desses casos
através de diagramas.

2) CARACTERÍSTICAS

Na construção de um caso de uso, deve-se descrever um cenário sobre

alguma parte de um sistema, indicando as interações entre usuários, partes
desse mesmo sistema ou integrações com outros softwares
O caso precisa ser claro, por motivos mencionados anteriormente, e por isso,
evitar a utilização de termos técnicos e de áreas específicas.
Sobre a nomenclatura, escolhe-se um nome intuitivo e curto que descreva a
funcionalidade do sistema que está sendo narrada, pois em sistemas complexos,
podem existir muitos casos de uso a fim de descrever, sem dúvidas, o projeto
em questão.
Já com relação ao nível de detalhamento, pode-se dizer que depende da
etapa em que se encontra o projeto e os riscos envolvidos. Quanto mais riscos,
mais detalhes necessita. Também, pode-se, inicialmente, fazer uma descrição
superficial que vá evoluindo com o passar de seu desenvolvimento, variando de
acordo com o sistema.
Cada caso diz respeito à uma característica do sistema e a fim de uni-los,
criamos um pacote desses agregando-os e utilizamos diagramas de casos de
uso para expor os relacionamentos.
 Para que um caso de uso seja bem elaborado, além da descrição e
diagramas há a possibilidade de se incluir outras seções relevantes para a
eficiência e agilidade do projeto, a gosto do projetista.

2.1) SEÇÕES COMUNS EM CASOS DE USO

Por padrão, toda seção geralmente apresenta os seguintes itens:

 Nome identificador, sendo um verbo ou substantivo;

 Iteração ou estado de desenvolvimento, mede a evolução do sistema
e, por conseguinte, seu caso;
 Sumário, resumindo brevemente cada caso. Pode ser usada como
apoio para todo o resto;
 Triggers, que são eventos que estimulam os acontecimentos dos
casos, pode ser um fator interno, externo ou temporal;
 Linha de eventos. Descreve a sequência com que os fatos ocorrem;
 Percursos alternativos, que são eventos que podem substituir algum
da linha de evento.
 Pós-condições, marca como se encontra o sistema depois que o caso
ocorre.
 Regras de negócio, seção para políticas e/ou restrições da empresa.
 Notas: adicional de informação que não esteja em nenhuma das
seções anteriores.
 Autor e data, além de enunciar as versões existentes

2.2) CENÁRIOS

O sistema deve ter pelo menos um cenário principal, normalmente é

uma sequência de passos. E pode conter cenários alternativos, por
exemplo, instruções para o que fazer quando o cenário principal não
ocorre, semelhante aos tratamentos de erro na programação. Um
exemplo será visto mais adiante.

2.3) VOCABULÁRIO

Em casos de uso algumas vezes usamos termos técnicos que serão

aqui definidos:
I) Atores: Entidade que interage com o sistema, seja uma pessoa
ou um outro sistema, sobre o qual o não é possível ter controle.
Agem externamente, iniciando o sistema em questão e/ou
respondendo a ele. É importante lembrar que “Cada ator
corresponde a um papel específico: uma mesma pessoa que
desempenha diferentes papéis nas interações com o sistema é
representada por diferentes atores; por outro lado, diversas
pessoas que desempenham o mesmo papel correspondem a
um único ator”. Os atores podem ser de forma primária, agindo
diretamente, ou secundária, indiretamente.

II) Interação: processo de comunicação de atores com o sistema.

 III) Relacionamento ou associações possíveis:
a. Inclusão (Include): “Quando o caso de uso A “inclui” o caso
de uso B, significa que sempre que o caso de uso A for
executado o caso de uso B também será executado. A
direção do relacionamento é do caso de uso que
está incluindo para o caso de uso incluído”. No diagrama a
seta aponta para o caso incluído, e a <<include>> é
colocado em uma linha tracejada. Usado quando um caso
de uso é usado dentro de outro. [1]
b. Extensão (Extend): “Quando o caso de uso B estende o
caso de uso A, significa que quando o caso de uso A for
executado o caso de uso B poderá (poderá – talvez não
seja) ser executado também. A direção do relacionamento é
do caso de uso extensor (aqui o caso de uso B) para o caso
de uso estendido (aqui o caso de uso A)”. Usado para
demarcar funcionalidades particulares, opcionais. No
diagrama é representado pela linha tracejada e <<extend>>
[1]
c. Generalização (Generalization): “Quando o caso de
uso B generaliza o caso de uso C isso significa que, além de
fazer tudo que nele está especificado (ele = B), ele também
executará tudo que está especificado no caso de uso C”.
[1]

3) DIAGRAMAS DE CASOS DE USO

É a representação gráfica dos atores, casos e o relacionamento entre os

elementos, ou ainda, é uma abstração para melhor visualização de quais
elementos externos interagem com que partes do sistema. Mostra o que
o sistema faz, não se preocupando com o como. Foi incorporado à UML
(Linguagem de Modelagem Unificada), sendo seu diagrama mais
abstrato, flexível e informal. São muito usados no início da modelagem do
sistema, no levantamento de requisitos. Nesses diagramas:

 Um ator é representado por um Stick Man, boneco de palito, e seu

nome deve ir abaixo. Interações entre atores não são exibidas nos
diagramas. Mas podem ser relacionados pelos itens 2.3 III.
 O caso de uso deve ser representado por uma elipse englobando o
nome do caso. Normalmente é um verbo + um objeto. Exemplo: Locar
filmes.
 A comunicação entre atores e funcionalidades do sistema é
representado por uma seta ligando-os. Um ator pode estar relacionado
a diversas funcionalidades, isto é, diversos casos de uso.

3.1) EXEMPLOS

Suponha um sistema bancário. Casos de uso podem ser: Abrir conta,

sacar, verificar saldo, tirar extrato, entre outros. Atores possíveis são
Cliente, caixa do banco, gerente.
 Figura 1: Especialização e Generalização em diagramas [7]

Figura 2: Extensão entre diagramas de casos de uso [7]

Figura 3: Inclusão entre diagramas de casos de uso [7]

4) RESULTADOS E CONCLUSÕES

Por serem simples e padronizados, os casos de uso se tornam de fácil

entendimento, sendo uma ótima ferramenta para exibição do que faz o
sistema analisado (requisitos funcionais).
Além disso pode servir de base para estimação, planejamento e validação
do projeto. São reutilizáveis e passíveis de evolução.
É como contar uma mesma história para pessoas de diferentes áreas e
com inteligências e grau de conhecimentos também distintos, mas que possa
ser entendida por todos, sem muitos esforços.
5) REFERÊNCIAS BIBLIOGRÁFICAS

[1] Até o Momento. Disponível em: http://www.ateomomento.com.br/o-que-

e-caso-de-uso/>. Acesso em: 14 de abril de 2018.

[2] iMastes. Disponível em: <https://imasters.com.br/artigo/3811/uml/casos-

de-uso-cenarios/>. Acesso em: 14 de abril de 2018.

[3] FunPar. Disponível em:

<http://www.funpar.ufpr.br:8080/rup/process/activity/ac_ucana.htm#Define%
20Attributes>. Acesso em: 16 de abril de 2018.

[4] Diretrizes para construção de casos de uso eficazes. Santos, A.L.;

Radael, E.M.; Pinhata, R.F.; Rossi, S.A.; Mendes, S. Faculdade de Filosofia,
Ciências e Letras – Centro Universitário Fundação Santo André. Revista de
Informática Aplicada, Vol. II - n0 02 - jul/dez 2006.

[5] G. Booch, J. Rumbaugh, I. Jacobson. UML, Guia do Usuário. 2ª Ed.,

Editora Campus, 2005.

[6] M. Fowler. UML Essencial, 2a Edição. Bookmann, 2000.

[7] Diagramas de Casos de uso. Figueiredo, E. Disponível em:

< http://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/uml-casos-de-
uso_v02-1.pdf>. Acesso em: 16 de abril de 2018.