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 comunicação entre o analista e o cliente podendo ser usado para descrever o cenário em que a aplicação irá funcionar e suas funcionalidades.

Um diagrama de casos de usos é composto por componentes de notação como: Ator e Caso de Uso e entre estes componentes pode existir relacionamentos como: Associação, generalização, comunicação, includes e extends, que explicarei depois como e quando utilizá-los.

Bom, no segundo post sobre meu TCC eu utilizei um formulário de Modelo de Requisitos (Caso não tenha visto o formulário, está aqui), como foi dito, apesar de não ter visto utilidade naquele momento e ter passado varias aulas arrumando desculpas para não fazer, acabei fazendo. Pois bem aqui é que encontrei a utilidade dele.

Para este post estarei utilizando um modelo que fiz pro meu estágio. Nele uma das funcionalidades é Gerenciar Vendas,  ficando representada no modelo da seguinte funcionalidade:

Usuário

Funcionalidade Regra de Negócio Pré-Requisito Ações Pós-Requisito
Supervisor de vendas ou funcionários autorizados. Gerenciar Vendas Setor de vendas é responsável por liberação de ordem de produção Obter relação de pedidos aguardando aprovação Confirmar o pedido junto ao cliente caso for necessário

Emitir Ordem de produção

Lançar Contas a Receber

Analisando a tabela observamos o seguinte:

Somente o Supervisor de Vendas e Funcionários autorizados possuem acesso a funcionalidade.

O setor de venda é responsável por liberar às ordens de produção da empresa, para isso é necessário que tenha sido efetuado um pedido e que este não tenha sido aprovado até o momento.

Se necessário este pedido precisa ser confirmado junto ao cliente.

Após isso é emitida a ordem de produção e  efetuado o lançamento da venda no contas a receber.

A confirmação destas contas a receber é feita em outra funcionalidade do sistema, deixei somente  estes requisitos para não estender o post.

Agora vamos passar isso pro caso de uso.

Primeiro passo e saber quando usar cada componente:

Ator: Representa um usuário do sistema, podendo este ser um ser humano ou um outro sistema.

Entre atores pode ocorrer dois tipos de relacionamentos:

Comunicação: Representação em que ocorre a troca de mensagens entre atores.

Generalização: Representação em que um ator herda as características de outro ator. O mesmo conceito de Herança em Orientação a Objetos.

Caso de uso: Seu objetivo é especificar funcionalidades do sistema.

Entre casos de uso podemos encontrar os  relacionamentos de extend, include e generalização.

Include: Ao utilizar o relacionamento de include, dizemos que uma funcionalidade está incluída em outra funcionalidade. Para que seja executada, obrigatoriamente é necessário passar pela funcionalidade em que ela está incluída.

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 exceção, 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 preço, porém também podemos consultar o preço sem a necessidade de efetuarmos uma compra, por isso utilizamos o extend para representar este relacionamento.

Generalização: O relacionamento de generalização é usado para representar uma herança de um caso de uso genérico para um mais específico.

No exemplo dizemos que podemos Cartão de Crédito e Duplicata herdam o caso de uso Efetuar pagamento, ou seja, que cartão de crédito e duplica também são formas de efetuar pagamento.

Uma observação em que devemos estar sempre atentos é o nível de abstração. Alguns casos um caso de uso não necessariamente precisam aparecer, pois ficam implícitos dentro de outro caso de uso. O interessante é deixar à mostra somente casos de uso que representam funções que realmente interessem ao programador e ao cliente, caso uma funcionalidade interesse somente a um dos dois, não 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 são Supervisor e Funcionário autorizado. Como temos dois tipos de usuário e cada um tem um nível de acesso diferente do outro, faremos uma generalização para representar isso, ficando da seguinte forma.

No exemplo temos,  Supervisor herda as funções do Funcionário podendo ter mais funções especificas. Por exemplo, somente o supervisor pode ter acesso a relatórios, desta forma criariamos um caso de uso pra relatório e fariamos um relacionamento diretamente com Supervisor, mais neste caso de uso não será usada esta representação.

Dando sequência, temos o nosso pré-requisito da funcionalidade que é obter a relação de pedidos não aprovados.

Criamos uma funcinalidade Consultar Pedido, e relacionamos ela a Funcionário, desta forma tanto Funcionário quanto Supervisor terão acesso a ela.

No caso de uso ficaria representado dessa forma.

 

Agora temos mais dois pós-requisitos na tabela que são: Emitir Ordem e Lançar Contas a Receber. Porém temos uma ação que é Confirmar o Pedido se Necessário.

Primeiro vamos para a ação. Como a ação já diz que só vai ocorrer necessário, entendemos que ela é um extend.


Já com o emitir ordem de produção observamos o que é um comportamento que poderá ocorrer independente de consultar o pedido.

Por exemplo, caso o usuário queira emitir a ordem de produção sem consultar, ele poderá fazer, portanto entendemos como outro extend.

Porém o lançar contas a pagar, só poderá ocorrer se realmente forem emitidas ordens de produção. Neste caso um include relacionado com ordem de produção.

Este Caso de uso está em um nível de abstração que pode ser facilmente compreendido, logicamente poderíamos abstrair ainda mais, porém ficaria complicado para explicar ao cliente suas funcionalidades.

Uma frase que um amigo chamado Igor me falou uma vez e que acho bastante válida, é que não existe caso de uso mal feito e sim caso de uso mal compreendido.

Portanto, não poupe esforços para deixar seu caso de uso com as funcionalidades bem definidas e claras, isso influência muito no produto final, e lembre-se também que em algum momento será necessario dar manutenção neste sistema e com certeza depois de um tempo você não irá se lembrar como foi implantada tal funcionalidade.

Como visto, à tabela de modelo de requisitos é bastante útil para a criação dos casos de uso, uma vez que as informações estarão descritas ali, basta passarmos para o diagrama.

Terminado nosso Diagrama de caso de uso da funcionalidade Gerenciar Venda e termino este post por aqui também.

Até o próximo.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s