ENGENHARIA

DE SOFTWARE

Aline Zanin

Izabelly Soares
de Morais
 Revisão técnica:

Jeferson Faleiro Leon

Desenvolvimento de Sistemas
Especialista em Formação Pedagógica de Professores

M827e Morais, Izabelly Soares de.

Engenharia de software [recurso eletrônico] / Izabelly
Soares de Morais, Aline Zanin ; revisão técnica : Jeferson
Faleiro Leon. – Porto Alegre : SAGAH, 2017.

ISBN 978-85-9502-253-9

Engenharia. 2. Engenharia de software auxiliada por

computador. I. Zanin, Aline. II. Título.

CDU 004.41

Catalogação na publicação: Karin Lorien Menoncin CRB-10/2147

Conhecer e construir
diagrama de casos de uso
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

„„ Explicar o objetivo do diagrama de casos de uso.

„„ Aplicar os elementos do diagrama de casos de uso.
„„ Realizar a análise do diagrama de casos de uso.

Introdução
O diagrama de casos de uso descreve a funcionalidade proposta para um
novo sistema que será projetado e é uma excelente ferramenta para o
levantamento dos requisitos funcionais do sistema. Este diagrama não é
utilizado apenas para o time interno de desenvolvimento de um software,
mas também para apresentar ao cliente as funcionalidades que terão no
sistema. Sua forma de criação é bastante simples, tendo poucas formas
geométricas para representar um caso de uso.
Neste capítulo, você vai adquirir conhecimentos fundamentais para
avançar no aprendizado sobre os diagramas de casos de uso. Você vai
ver, também, os objetivos e os elementos do diagrama, as informações
importantes e os cuidados ao criar um diagrama.

Diagrama de casos de uso

A UML, Linguagem de Modelagem Unificada (do inglês Unified Modeling
Language), traz para o contexto computacional a padronização de uma lingua-
gem utilizada para representar informações referentes a um sistema, ou seja, a
sua aplicação pode estar ligada a diversas etapas que contemplam o processo
de desenvolvimento de um software. Cada diagrama traz um conjunto de
possibilidades, em que essas informações são mostradas de maneiras distintas.
2 Conhecer e construir diagrama de casos de uso

Conforme Larman (2007, p. 87), casos de uso são narrativas em texto,

amplamente utilizadas para descobrir e registrar requisitos. Eles influenciam
muitos aspectos de um projeto, inclusive a POO (programação orientada a
objetos), e servem de entrada para vários artefatos subsequentes nos estudos
de caso. Metas de alto nível e diagramas de casos de uso são utilizados como
entrada para a criação do texto do caso de uso. Os casos de uso, por sua vez,
influenciam muitos outros artefatos de análise, projeto, implementação, gestão
de projeto e teste.
Este capítulo aborda o diagrama de caso de uso, o qual “identifica os atores
envolvidos em uma interação e dá o nome ao tipo de interação. Essa é, então,
suplementada por informações adicionais que descrevem a interação com o
sistema. A informação adicional pode ser uma descrição textual ou um ou mais
modelos gráficos. Os casos de uso são documentados por um diagrama de casos
de uso de alto nível. O conjunto de casos de uso representa todas as possíveis
interações que serão descritas nos requisitos de sistema” (SOMMERVILLE,
2011, p. 74). O próximo tópico traz as particularidades de um caso de uso.

Existem softwares com a finalidade de possibilitar a construção de diagramas, dentre

os diversos existentes podemos destacar o Astah, o qual pode ser gratuito, ter alguma
limitação de uso ou exigir alguma assinatura ou compra de licença para uso. Porém,
permite que os diagramas sejam construídos de forma organizada e clara.

Outras ferramentas que podem ser utilizadas para modelagem de caso de uso são:
„„ Omondo: Plugin para Eclipse (http://www.omondo.com/)
„„ Jude (https://jude.change-vision.com/jude-web/)
„„ Together (http://www.borland.com/products/downloads/download_together.html)
„„ IBM Rational Rose (http://www.ibm.com/software/rational)
 Conhecer e construir diagrama de casos de uso 3

Elementos do diagrama de caso de uso

Os casos de uso trazem narrativas que englobam as funcionalidades do sistema,
mais precisamente os requisitos funcionais, em que alguns elementos são
fundamentais para a construção do diagrama. Dentre eles, Larman (2007),
destaca:

„„ Um ator é algo com comportamento, tal como uma pessoa (identificada

por seu papel), um sistema de computador ou uma organização; por
exemplo, um caixa. A representação do ator está exposta na Figura 1
a seguir.

Figura 1. Representação do ator, no caso

de uso.
4 Conhecer e construir diagrama de casos de uso

„„ Um cenário é uma sequência especifica de ações e interações entre

atores e o sistema. É também chamado de instância de caso de uso. É
uma história particular de uso de um sistema ou um caminho através do
caso de uso; por exemplo, o cenário de efetuar com sucesso a compra
de itens em dinheiro, ou o cenário de não consumar a compra de itens
por causa da recusa de uma autorização de crédito (Figura 2).

Figura 2. Representação de um cenário, no caso de uso.

 Conhecer e construir diagrama de casos de uso 5

Os casos de uso podem ter três tipos de relacionamento: associação, ge-

neralização e dependência (inclusão ou extensão). A Figura 3 traz, além do
cenário e do ator, a representação gráfica determinada pela UML, para o
próprio caso de uso, em que o “traço” que liga o ator ao caso de uso representa
a associação entre o ator e o caso de uso.

Figura 3. Representação da associação e caso de uso.

Devemos estar cientes de que todo caso de uso deve ter um nome, o qual
deve vir descrito em seu interior, o que remete a sua funcionalidade, como
pagar, registrar, dentre outras possibilidades. O caso de uso busca expor o
que o sistema faz, e não como ele executa determinada funcionalidade. Por
este motivo, utilizamos verbos nos casos de uso, os quais indicam uma ação
a ser executada.
6 Conhecer e construir diagrama de casos de uso

Na generalização, o caso de uso filho herda o comportamento e o significado

do caso de uso pai, em que o caso de uso filho pode incluir ou sobrescrever
o comportamento do caso de uso pai ou o caso de uso filho pode substituir o
caso de uso pai em qualquer lugar em que ele apareça (LABORATÓRIO DE
ENGENHARIA DE SOFTWARE, [2017]), como mostra a Figura 4 a seguir.

Figura 4. Representação de uma generalização.

Fonte: adaptada de Laboratório de Engenharia de Software [2017].

De acordo com Schach (2010, p. 542), “na UML, um estereótipo é uma

forma de estender a UML, isto é, se precisarmos definir uma construção que
não exista na UML, podemos fazê-lo. A relação include é tratada em UML
como um estereótipo, daí a notação «include», a qual é utilizada para denotar
funcionalidade comum. Outra relação é a relação extend, em que um caso
de uso é uma variação do caso de uso padrão”. A Figura 5 a seguir traz um
exemplo prático.
 Conhecer e construir diagrama de casos de uso 7

Figura 5. Representação de um caso de uso.

Utilizamos include para definir que um caso de uso precisa obrigatoriamente

do outro para ser executado, como mostrado na Figura 4, que traz algumas
funcionalidades de um sistema bancário, em que um cliente só poderá “sacar
dinheiro” caso o cadastro dele seja conferido. Ele também tem a opção de
retirar o extrato, essa funcionalidade pode ser executada apenas se alguma
condição for atendida, ou seja, ela não é uma funcionalidade obrigatória, por
isso traz o extend. Observe que, ao utilizar esses recursos, você deve utilizar
uma linha pontilhada e uma seta, para indicar qual caso tem dependência do
outro. Veja no Quadro 1 a seguir os detalhes e o gabarito para elaborar um
caso de uso.
8 Conhecer e construir diagrama de casos de uso

Quadro 1. Gabarito para elaborar um diagrama de caso de uso.

Seção do caso de uso Comentário

Nome do caso de uso Começar com um verbo

Escopo O sistema em projeto

Nível “Objetivo do usuário” ou “subfunção”

Ator principal Chama o sistema para

fornecer os serviços

Interessados e interesses Quem se importa com este caso

de uso e o que eles desejam?

Pré-condições O que precisa ser verdade de início

e vale a pena dizer ao leitor?

Garantia de sucesso O que precisa ser verdade quando

da finalização bem sucedida e
se vale a pena dizer ao leitor

Cenário de sucesso principal Um caminho típico, incondicional

e otimista do cenário de sucesso

Extensões Cenários alternativos de sucesso

Requisitos especiais Requisitos não funcionais relacionados

Lista de variantes Métodos de entrada e saída e

tecnológicas e de dados formatos de dados variáveis

Frequência de ocorrência Influencia a investigação, teste e

oportunidade da implementação

Diversos Como, por exemplo,

pontos em aberto

Fonte: Larman (2007, p. 93).

 Conhecer e construir diagrama de casos de uso 9

Análise de um diagrama de caso de uso

Casos de uso são uma boa maneira de manter “a coisa” simples e de tornar
possível a especialistas no domínio ou a fornecedores de requisitos escrever
eles mesmos (ou participar da escrita de) casos de uso. Outro valor dos casos
de uso é que eles enfatizam os objetivos e perspectivas do usuário. Formulamos
a questão “quem está usando o sistema, quais são seus típicos cenários de uso
e quais são os seus objetivos?”. Essa é uma ênfase mais centrada no usuário,
comparada a simplesmente solicitar uma lista de características do sistema
(LARMAN, 2007, p. 91).
Para Sommerville (2011, p. 75), cenário e casos de uso são técnicas eficazes
para elicitar requisitos dos stakeholders, ou seja, dos envolvidos no processo
de desenvolvimento do software (clientes, equipe de desenvolvimento), que
vão interagir diretamente com o sistema, em que cada tipo de interação pode
ser representado como um caso de uso. No entanto, devido a seu foco nas
interações com o sistema, eles não são tão eficazes para elicitar restrições
ou requisitos de negócios nem funcionais em alto nível ou para descobrir
requisitos de domínio.
A análise de um caso de uso deve ser realizada tendo como base as especifi-
cações do sistema, ou seja, eles devem estar de acordo com as funcionalidades
estabelecidas provavelmente no documento de requisitos, tendo em vista que
ele trará os requisitos funcionais de maneira gráfica, utilizando a representação
gráfica de um caso de uso.
10 Conhecer e construir diagrama de casos de uso

No exemplo a seguir, podemos visualizar um diagrama de caso de uso no qual todos

os elementos gráficos estão sendo utilizados.

Fonte: Schach (2010, p. 357).

Podemos notar que o cenário apresentado retrata um contexto escolar, no qual

os atores são: funcionário, usuário, aluno e professor, e os casos de uso são: cadastrar
exemplares, cadastrar usuários, fazer empréstimos e fazer consulta. Nota-se que, além
de fazer parte de um contexto escolar, contempla funcionalidades de um sistema de
biblioteca.
 Conhecer e construir diagrama de casos de uso 11

Conforme Leite (2000), para modelar os requisitos de software de um

sistema, podemos seguir as seguintes regras:

„„ Estabeleça o contexto do sistema identificando os atores (usuários e

sistemas externos) associados a ele.
„„ Para cada ator, considere o comportamento que cada um deles espera
ou requer que o sistema tenha, para que as suas metas sejam satisfeitas.
„„ Considere cada um destes comportamentos esperados como casos de
uso, dando nomes para cada um deles.
„„ Analise os casos de uso tentando identificar comportamentos comuns a
mais de um deles. Defina essa parte comum como caso de uso genérico,
estabelecendo um relacionamento de generalização. Tente identificar
outros relacionamentos, como a dependência entre casos de uso que
incluem o comportamento de outros.
„„ Modele esses casos de uso, atores e seus relacionamentos em diagramas
de casos de uso.
„„ Complemente esses casos de uso com notas que descrevam requisitos
não funcionais.

Além destas regras básicas, algumas dicas ajudam a construir diagramas

mais claros:

„„ Dê nomes que comuniquem o seu propósito.

„„ Quando existirem relacionamentos, distribua os casos de uso de maneira
a minimizar os cruzamentos de linhas.
„„ Organize os elementos espacialmente de maneira com que aqueles que
descrevem comportamentos associados fiquem mais próximos.
„„ Use notas para chamar a atenção de características importantes – as
notas não são apenas para os requisitos não funcionais.
„„ Não complique o diagrama, coloque apenas o que é essencial para
descrever os requisitos. O diagrama deve ser simples sem deixar de
mostrar o que é relevante.

Apesar de as regras serem elencadas para a construção de um caso de

uso, elas são úteis também para sua análise, tendo em vista que precisamos
conhecer essas etapas de desenvolvimento de um caso de uso para que pos-
samos analisá-lo.
12 Conhecer e construir diagrama de casos de uso

LABORATÓRIO DE ENGENHARIA DE SOFTWARE. UML: Caso de uso.. Rio de Janeiro:

PUC Rio. s/d. Disponível em: http://www.les.inf.puc-rio.br/wiki/images/6/61/Aula01-
-diagrama_casos_uso.pdf. Acesso em: 07 set. 2017.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orien-
tados a objetos e ao desenvolvimento iterativo. 3.ed.Porto Alegre: Bookman, 2007.
LEITE J. C. Análise e Especificação de Requisitos. Notas de aula de Engenharia de Sof-
tware, Natal, 2000. Disponível em: <https://www.dimap.ufrn.br/~jair/ES/c4.html/>.
Acesso em: 04 set. 2017.
SCHACH, S.R. Engenharia de software: os paradigmas clássicos e orientado a objetos.
7. ed. Porto Alegre: AMGH, 2010.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.

Leituras recomendadas
PFLEEGER, S. Engenharia de Software: teoria e prática. 2. ed.  Upper Saddle River:
Prentice-Hall, 2004.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional.
8. ed. Porto Alegre: AMGH, 2016.
 Encerra aqui o trecho do livro disponibilizado para
esta Unidade de Aprendizagem. Na Biblioteca Virtual
da Instituição, você encontra a obra na íntegra.
Conteúdo: