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 como 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 analista e o cliente podendo ser usado para descrever o cenrio em que a aplicao ir funcionar e suas funcionalidades.Um diagrama de casos de usos composto por componentes de notao como: Ator e Caso de Uso e entre estes componentes pode existir relacionamentos como: Associao, generalizao, 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 Requisitos (Caso no tenha visto o formulrio, est aqui), como foi dito, apesar de no ter visto 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 funcionalidade:UsurioFuncionalidade Regra de Negcio Pr-Requisito Aes Ps-RequisitoSupervisor de vendas ou funcionrios autorizados. Gerenciar Vendas Setor de vendas responsvel por liberao de ordem de produo Obter relao de pedidos aguaraprovao Confirmar o pedido junto ao cliente caso for necessrioEmitir Ordem de produoLanar Contas a ReceberAnalisando a tabela observamos o seguinte:Somente o Supervisor de Vendas e Funcionrios autorizados possuem acesso a funcionalidade.O setor de venda responsvel por liberar s ordens de produo da empresa, para isso necessrio que tenha sido efetuado um pedido e que este no tenha sido aprovado at o momento.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 receber.A confirmao destas contas a receber feita em outra funcionalidade do sistema, deixei 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 mesmo 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 generalizao.Include: Ao utilizar o relacionamento de include, dizemos que uma funcionalidade est includa em outra funcionalidade. Para que seja executada, obrigatoriamente necessrio passar pela funcionalidade em que ela est includa.No exemplo estamos dizendo repesentamos que o acesso ao sistema somente pode acontecer caso o login tenha sido executado.Extend: O relacionamento de extend representa uma exceo, ou seja, representa um comportamento que pode ocorrer separadamente do caso de uso que o estende.No exemplo estamos dizendo que para efetuar a compra podemos consultar o preo, porm tambm podemos consultar o preo sem a necessidade de efetuarmos uma compra, por isso 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 Efetuar pagamento, ou seja, que carto de crdito e duplica tambm so formas de efetuar pagamento.Uma observao em que devemos estar sempre atentos o nvel de abstrao. Alguns casos um caso de uso no necessariamente precisam aparecer, pois ficam implcitos dentro de outro caso de uso. O interessante deixar mostra somente casos de uso que representam funes que realmente interessem ao programador e ao cliente, caso uma funcionalidade interesse somente a um dos dois, no necessariamente precisa ser criado um caso 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 temos dois tipos de usurio e cada um tem um nvel de acesso diferente do outro, faremos uma generalizao para representar isso, ficando da seguinte forma.No exemplo temos, Supervisor herda as funes do Funcionrio podendo ter mais funes especificas. Por exemplo, somente o supervisor pode ter acesso a relatrios, desta forma criariamos um caso de uso pra relatrio e fariamos um relacionamento diretamente 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 pedidos no aprovados.Criamos uma funcinalidade Consultar Pedido, e relacionamos ela a Funcionrio, desta 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 ela um extend.J com o emitir ordem de produo observamos o que um comportamento que poder ocorrer independente 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 produo. Neste caso um include relacionado com ordem de produo.Este Caso de uso est em um nvel de abstrao que pode ser facilmente compreendido, logicamente poderamos abstrair ainda mais, porm ficaria complicado para explicar ao cliente suas funcionalidades.Uma frase que um amigo chamado Igor me falou uma vez e que acho bastante vlida, que 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 em algum momento ser necessario dar manuteno neste sistema e com certeza depois de um 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 uso, 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 termino este post por aqui tambm.At o prximo.