https://fernandogodoy.wordpress.

com/2011/07/06/tcc-casos-de-uso/
Para este post, estarei falando um pouco sobre Diagrama de Casos de Uso, tendo c
omo exemplo um caso de uso criado para representar uma das funcionalidade do meu
projeto do TCC.
O diagrama de casos de uso tem como finalidade facilitar a comunicao entre o anali
sta e o cliente podendo ser usado para descrever o cenrio em que a aplicao ir funcio
nar e suas funcionalidades.
Um diagrama de casos de usos composto por componentes de notao como: Ator e Caso d
e Uso e entre estes componentes pode existir relacionamentos como: Associao, gener
alizao, comunicao, includes e extends, que explicarei depois como e quando utiliz-los
.
Bom, no segundo post sobre meu TCC eu utilizei um formulrio de Modelo de Requisit
os (Caso no tenha visto o formulrio, est aqui), como foi dito, apesar de no ter vist
o utilidade naquele momento e ter passado varias aulas arrumando desculpas para
no fazer, acabei fazendo. Pois bem aqui que encontrei a utilidade dele.
Para este post estarei utilizando um modelo que fiz pro meu estgio. Nele uma das
funcionalidades Gerenciar Vendas, ficando representada no modelo da seguinte fu
ncionalidade:
Usurio

Funcionalidade Regra de Negcio

Pr-Requisito Aes Ps-Requisito
Supervisor de vendas ou funcionrios autorizados.
Gerenciar Vendas
Setor de
vendas responsvel por liberao de ordem de produo
Obter relao de pedidos agua
aprovao
Confirmar o pedido junto ao cliente caso for necessrio
Emitir Ordem de produo
Lanar Contas a Receber
Analisando a tabela observamos o seguinte:
Somente o Supervisor de Vendas e Funcionrios autorizados possuem acesso a funcion
alidade.
O setor de venda responsvel por liberar s ordens de produo da empresa, para isso nec
essrio que tenha sido efetuado um pedido e que este no tenha sido aprovado at o mom
ento.
Se necessrio este pedido precisa ser confirmado junto ao cliente.
Aps isso emitida a ordem de produo e efetuado o lanamento da venda no contas a rece
ber.
A confirmao destas contas a receber feita em outra funcionalidade do sistema, deix
ei somente estes requisitos para no estender o post.
Agora vamos passar isso pro caso de uso.
Primeiro passo e saber quando usar cada componente:

Ator: Representa um usurio do sistema, podendo este ser um ser humano ou um outro
sistema.

Entre atores pode ocorrer dois tipos de relacionamentos:

Comunicao: Representao em que ocorre a troca de mensagens entre atores.

Generalizao: Representao em que um ator herda as caractersticas de outro ator. O mesm

o conceito de Herana em Orientao a Objetos.

Caso de uso: Seu objetivo especificar funcionalidades do sistema.

Entre casos de uso podemos encontrar os relacionamentos de extend, include e ge
neralizao.

Include: Ao utilizar o relacionamento de include, dizemos que uma funcionalidade

est includa em outra funcionalidade. Para que seja executada, obrigatoriamente ne
cessrio passar pela funcionalidade em que ela est includa.
No exemplo estamos dizendo repesentamos que o acesso ao sistema somente pode aco
ntecer caso o login tenha sido executado.

Extend: O relacionamento de extend representa uma exceo, ou seja, representa um co

mportamento que pode ocorrer separadamente do caso de uso que o estende.
No exemplo estamos dizendo que para efetuar a compra podemos consultar o preo, po
rm tambm podemos consultar o preo sem a necessidade de efetuarmos uma compra, por i
sso utilizamos o extend para representar este relacionamento.

Generalizao: O relacionamento de generalizao usado para representar uma herana de um

caso de uso genrico para um mais especfico.
No exemplo dizemos que podemos Carto de Crdito e Duplicata herdam o caso de uso Ef
etuar pagamento, ou seja, que carto de crdito e duplica tambm so formas de efetuar p
agamento.
Uma observao em que devemos estar sempre atentos o nvel de abstrao. Alguns casos um c
aso de uso no necessariamente precisam aparecer, pois ficam implcitos dentro de ou
tro caso de uso. O interessante deixar mostra somente casos de uso que represent
am funes que realmente interessem ao programador e ao cliente, caso uma funcionali
dade interesse somente a um dos dois, no necessariamente precisa ser criado um ca
so de uso para represent-la.
Agora que j sabemos quando e quanto utilizar os casos de uso, voltaremos tabela.
Temos nossos atores j definidos, que so Supervisor e Funcionrio autorizado. Como te
mos dois tipos de usurio e cada um tem um nvel de acesso diferente do outro, farem
os uma generalizao para representar isso, ficando da seguinte forma.

No exemplo temos, Supervisor herda as funes do Funcionrio podendo ter mais funes esp
ecificas. Por exemplo, somente o supervisor pode ter acesso a relatrios, desta fo
rma criariamos um caso de uso pra relatrio e fariamos um relacionamento diretamen
te com Supervisor, mais neste caso de uso no ser usada esta representao.
Dando sequncia, temos o nosso pr-requisito da funcionalidade que obter a relao de pe
didos no aprovados.
Criamos uma funcinalidade Consultar Pedido, e relacionamos ela a Funcionrio, dest
a forma tanto Funcionrio quanto Supervisor tero acesso a ela.
No caso de uso ficaria representado dessa forma.

Agora temos mais dois ps-requisitos na tabela que so: Emitir Ordem e Lanar Contas a
Receber. Porm temos uma ao que Confirmar o Pedido se Necessrio.
Primeiro vamos para a ao. Como a ao j diz que s vai ocorrer necessrio, entendemos que
la um extend.

J com o emitir ordem de produo observamos o que um comportamento que poder ocorrer i
ndependente de consultar o pedido.
Por exemplo, caso o usurio queira emitir a ordem de produo sem consultar, ele poder
fazer, portanto entendemos como outro extend.

Porm o lanar contas a pagar, s poder ocorrer se realmente forem emitidas ordens de p
roduo. Neste caso um include relacionado com ordem de produo.

Este Caso de uso est em um nvel de abstrao que pode ser facilmente compreendido, log
icamente poderamos abstrair ainda mais, porm ficaria complicado para explicar ao c
liente suas funcionalidades.
Uma frase que um amigo chamado Igor me falou uma vez e que acho bastante vlida, q
ue no existe caso de uso mal feito e sim caso de uso mal compreendido.
Portanto, no poupe esforos para deixar seu caso de uso com as funcionalidades bem
definidas e claras, isso influncia muito no produto final, e lembre-se tambm que e
m algum momento ser necessario dar manuteno neste sistema e com certeza depois de u
m tempo voc no ir se lembrar como foi implantada tal funcionalidade.
Como visto, tabela de modelo de requisitos bastante til para a criao dos casos de u
so, uma vez que as informaes estaro descritas ali, basta passarmos para o diagrama.
Terminado nosso Diagrama de caso de uso da funcionalidade Gerenciar Venda e term
ino este post por aqui tambm.
At o prximo.