DIAGRAMA USE CASE (caso de uso)

Os requisitos que um sistema possui muitas vezes so complexos, no estou falando aqui de requisitos simples, como o usurio pedir "Faa um programa que controle a mdia de um boletim escolar". Temos na verdade que lidar com dezenas de pginas de "desejos do usurio". Sim, o usurio deseja que o sistema realize determinadas tarefas, deseja que o sistema realize seus sonhos e muitas vezes deseja que ele faa milagres. A espectativa dos usurios quanto aos sistemas sempre muito grande, eles imaginam que o mesmo possa realizar todas as coisas que eles precisam e que ir resolver todos os seus problemas. Acham no sistema a soluo para os seus problemas. Sabemos que isto no verdade e que algumas tarefas no podemos modelar e passar par dentro do software.

A Lngua Portuguesa, assim como outras, ambgua, por natureza. Portanto, necessitamos de um padro que permita o uso de linguagem natural, mas em um formato que reduza as ambiguidades. Alm disso, que permita com facilidade converter essa estrutura para os diagramas e implementaes do sistema. Para isto ento temos os diagramas de Caso de Uso na UML.

O Incio, entendendo os Requisitos A UML e a modelagem de casos de usos no interfere nas tcnicas usadas pelos desenvolvedores para o levantamento de requisitos. Pelo contrrio, o caso de uso torna-se o "brao direito" do desenvolvedor, auxiliando-o a validar os requisitos extrados junto ao usurio.

O levantamento de requisitos de um sistema no uma tarefa fcil, mas tambm no impossvel. O problema reside no fato de que estamos lidando com um ser humano que expressa suas idias, geralmente fora de ordem e sem muita explicao e temos que entender e levantar os requisitos

Sabemos que os problemas existem, mas com as tcnicas, ferramentas e paradigma adequados, tudo pode correr tranqilamente. Temos que ter em mente que o usurio no o nosso inimigo, pelo contrrio, se conseguirmos estabelecer com ele uma comunicao sem rudos, certamente a validao ocorrer sem problemas e o nosso software conseguir ento satisfazer os desejos do usurio.

Durante este processo de levantamento de requisitos atravs de conversas com os usurios preciso mostrar para o usurio que devemos formar um time para alcanarmos o mesmo objetivo. importante que durante este processo haja muita troca de informaes entre os usurios e analistas. Esta troca de informaes que ir garantir o sucesso desta etapa de levantamento de requisitos.

O USE CASE

Um caso de uso (Use Case) descreve uma seqncia de aes que representam um cenrio principal (perfeito) e cenrios alternativos, com o objetivo de demonstrar o comportamento de um sistema (ou parte dele), atravs de interaes com atores. Uma vez que o desenvolvedor levante os requisitos com o usurio, h a necessidade de document-los, no s para entendimento e validao de ambas as partes, como para servir de base no ambgua para toda a equipe de desenvolvimento. A documentao dos requisitos evita que informaes importantes se percam, sendo descobertas apenas ao apresentar o produto final ao usurio.

Utilizando a modelagem de casos de uso, o primeiro passo do desenvolvedor separar as funcionalidades do sistema. Destas funcionalidades, devemos agrupar um conjunto de aes que tenham um objetivo bem definido.

O caso de uso, por expressar os requisitos do sistema - nada mais do que a essncia deste -, utilizado durante todo o processo de desenvolvimento. Os requisitos alm de serem a base para a criao dos modelos de anlise, projeto e implementao, tambm so usados como base para a criao de testes do sistema. Podemos dizer que o modelo de casos de uso ser central para todas as demais etapas do desenvolvimento do sistema. Este diagrama ser sempre utilizado na construo dos demais, sendo muito importante estar bem definido expressando os desejos do cliente.

Ao modelarmos um sistema, necessitamos saber at que ponto devemos nos preocupar. Estes pontos-limites so a fronteira do sistema.

Um caso de uso representado por uma elipse contendo o seu nome. O nome do caso de uso tambm pode ser colocado abaixo da elipse, que pode conter ou no compartimentos referentes a pontos de extenso

Atores

Na modelagem de casos de uso, esse papel externo exercido por um ator (actor). Na realidade, esse ator, que pode ser tanto uma pessoa, como um grupo ou ainda um sistema, representa um conjunto de papis. Um caso de uso pode se relacionar com mais de um ator.

Um ator representa um conjunto de papis exercido por um usurio do sistema ao interagir com um determinado caso de uso. Um ator , portanto, um papel que um usurio desempenha em relao ao sistema.

Os atores no precisam ser humanos, embora sejam representados como bonecos humanos nos diagramas de caso de uso. Um ator tambm pode ser um sistema externo que necessita de alguma informao do sistema atual. Existem diversas variaes no que as pessoas mostram como atores. Algumas pessoas mostram cada sistema externo ou agente humano no diagrama de caso de uso; outras preferem mostrar o ativador do caso de uso.

O cone esteretipo padro para um ator a figura de um "stick man", contendo seu nome abaixo da figura. Outra representao consiste num retngulo de classe, com o esteretipo . E, ainda, permitido ao desenvolvedor utilizar outros cones que identifiquem mais precisamente o tipo de ator.

responsabilidade do caso de uso demonstrar com quais atores o sistema interage. Essa identificao na fase de anlise fornece ao projetista, no futuro, base para a criao dos perfis de acesso ao sistema. O caso de uso especifica como alcanar a realizao de um procedimento sem relacionar detalhes de implementao. Portanto, mostramos o que executar sem definir a forma como feito.

Vamos Analisar um exemplo que inclumos um cenrio principal e cenrios alternativos para um caso de uso referente a sua reserva de um carro popular, acompanhe:

Caso de Uso: Reserva De um Carro Popular Ator: Atendimento ao cliente Cenrio Principal 1. O cliente informa ao atendente a data da reserva, que repassada ao sistema; 2. O sistema mostra o veculo, indicando as opes. O sistema calcula e exibe o nmero de reservas ainda disponveis. 3. Um ou vrios veculos disponveis (so) escolhido(s) para reserva. 4. O sistema solicita o CPF do cliente, para identificao do mesmo no sistema. O sistema pesquisa o cliente e mostra nome e telefones de contato, para confirmao. 5. Aps confirmao, a reserva efetuada em nome do cliente.

Cenrios Alternativos Alternativa: Data no disponfvel para reserva 1) O sistema verifica se para a data informada possvel efetuar reservas. Caso negativo, uma nova data deve ser solicitada.

Alternativa: Reservas esgotadas 1) O sistema verifica se para o dia informado, as reservas esto esgotadas. O sistema deve possibilitar que seja informada nova data ou que se encerre a solicitao de reserva. Alternativa: Cliente no cadastrado 4) Se o cliente no for cadastrado: Extend Cadastrar Cliente de Reserva Importante salientar que no existe um padro da UML que determine uma forma nica de se escrever casos de uso. As aes podem ser descritas em pargrafos ou atravs de enumeraes, identificadas (por letras ou nmeros) ou no. Outra forma criar um texto com sees de pr e ps-condies. possvel, ainda, escrever o caso de uso como um pseudocdigo. O importante que cada caso de uso deve relacionar o suficiente para seu entendimento e que seja compreensvel para todos os envolvidos no processo de desenvolvimento.

Relacionamentos entre casos de uso e atores Os casos de uso representam conjuntos bem definidos de funcionalidades do sistema, que no podem trabalhar sozinhas no contexto do sistema. Portanto, esses casos de uso precisam se relacionar com outros casos de uso e com atores que enviaro e recebero mensagens destes.

Relacionamentos entre casos de uso: generalizao/herana, extenso e incluso. Relacionamentos entre atores: generalizao/herana Relacionamentos entre atores e casos de uso: associao

Associao Representa a interao do ator com o caso de uso, ou seja, a comunicao entre atores e casos de uso, por meio do envio e recebimento de mensagens. As associaes entre casos de uso so sempre binrias, ou seja, envolvem apenas dois elementos. Representam o nico relacionamento possvel entre atores e casos de uso.

Por exemplo: O ator Correntista envia e recebe mensagens do Caso de Uso Calcular Emprstimo Pessoal, por um relacionamento de associao.

Generalizao Ocorre entre casos de uso ou entre atores. considerado quando temos dois elementos semelhantes, mas com um deles realizando algo a mais. Costuma ser comparado ao relacionamento de extenso, com uma variao do comportamento normal sendo descrita sem muito rigor. Segue o mesmo conceito da orientao a objetos. Podemos dizer tambm que este relacionamento conhecido como herana.

Por exemplo: podemos criar um ator generico Aluno e especializ-lo nos atores Aluno Matriculado e Aluno Ouvinte.

Extenso (extends) Um relacionamento de extenso entre casos de uso indica que um deles ter seu procedimento acrescido, em um ponto de extenso, de outro caso de uso, identificado como base. Os pontos de extenso so rtulos que aparecem nos cenrios do caso de uso base. permitido colocar diversos pontos de extenso num mesmo caso de uso, inclusive repetir um mesmo ponto de extenso.

Incluso (Include) Indica que um deles ter seu procedimento copiado num local especificado no outro caso de uso, identificado como base. Voc deve estar se perguntando: Textualmente, um relacionamento de incluso, dentro da descrio de um caso de uso base, representado com o termo Include seguido de seu nome.

Por exemplo:

Cenrio Principal 1. O aluno digita sua matrcula. O sistema verifica se a matrcula vlida e ativa. Include (Validar Matrcula). (...)

Mais do que evitar a cpia de trechos idnticos, ganhamos tempo de modelagem e tambm de implementao ao trabalhar com casos de uso de incluso. Perceba ainda que teremos um ganho significativo quando depois formos fazer a manuteno do sistema.

Modelando requisitos com casos de uso No existe uma ordem pr definida que determine quais diagramas devem ser modelados primeiramente. A ordem determinada pela preferncia do desenvolvedor e/ou processo que esteja sendo usado. Sabemos que a UML independente de processo. Desta forma, o objetivo deste curso no apresentar um processo formal para trabalhar com a UML. Alguns desenvolvedores iniciam a modelagem do sistema pela criao das classes, outros pelos casos de uso. Se este for o caso, importante tomar cuidado com os nomes e os verbos utilizados, pois estes transformam em objetos, atributos e mtodos. Outros desenvolvedores comeam desenvolvendo o diagrama de casos de uso para fazer o levantamento dos requisitos do sistema, depois utilizam alguns diagramas de atividades para expressar atividades que j existem e que devero ser consideradas quando for elaborado o sistema e somente depois deste diagrama partem para a definio das classes atravs do diagrama de classes. Aconselho seguir sempre esta ltima abordagem pois melhor levantarmos todos os requisitos do sistema e document-los assim como descobrir e tambm documentar as principais atividades do sistema antes de comear a modelar as classes. O modelo de classes est bem focado na estrutura interna do software a ser desenvolvido e quando estamos levantando requisitos bem como as atividades.

Casos de uso e pacotes Em sistemas de media/alta complexidade comum termos dezenas de casos de uso. Nesse caso, a representao de todos eles em um nico diagrama uma tarefa impossvel. A fim de minimizar a visualizao e, principalmente, organizar esses casos de uso considerando uma mesma abordagem conceitual, podemos trabalhar com pacotes. Um pacote corresponde a um agrupamento de qualquer elemento de modelo, como casos de uso, classes, estados, outros pacotes, etc. (podemos imaginar como genrico e adaptvel).

Graficamente, o pacote representado como um grande retngulo com um pequeno retngulo como uma aba posicionada no topo do seu lado esquerdo - algo como o cone que representa uma pasta. O nome do pacote deve ser exibido na aba caso seu contedo seja mostrado. Caso contrrio, o nome do pacote deve vir no seu interior, Quando desejamos fazer referenda a um elemento que pertena a algum pacote, devemos usar a nomenclatura seguido de :: e , ficando assim pacote:: elemento

Muitas vezes nos perguntamos quando usar isto tudo, inicialmente pode parecer um pouco burocrtico e no necessrio este processo todo, mas veremos ao passar do tempo que ele fundamental para uma boa anlise.

A maioria dos seus casos de uso ser gerada durante est fase do projeto, mas voc descobrir mais a medida que avana. Fique alerta a eles o tempo todo. Cada caso de uso um requisito em potencial, e at que voc tenha capturado um requisito, voc no pode planejar como lidar com ele.

As vezes nos perguntamos , quantos casos de uso voc deve ter? No existe uma resposta exata para isto. Depende do tamanho do sistema e tambm depender da equipe e tipo de sistema que est sendo feito. Lembre-se que voc ter vrios cenrios e que em cada cenrio podem existir vrios casos de uso e um caso de uso pode ter casos alternativos. Com isto voc j viu que o nmero de casos de uso ser medido pelo seu bom senso de modelagem e que voc dever fazer quantos achar necessrio para levantar todos os requisitos. No tem um nmero e nem uma frmula para calcular isto.

Exemplos de uma descrio textual

Use Case: Criar base de conhecimento para Help Desk

Atores: Gerente

Cenrio principal de Sucesso ( Perfeito ):

1 - Gerente fornece usurio e senha para login 2 - Sistema valida usurio e senha 3 - Sistema redireciona Gerente para sua pgina home 4 - Gerente seleciona no menu a opo para criar base 5 - Sistema redireciona o Gerente para uma tela de criao da base 6 - Gerente seleciona em uma lista o curso para o qual quer criar base 7 - Gerente seleciona em uma lista de instrutores habilitados o responsvel pelas informaes 8 - Gerente informa data prevista para resoluo do problema 9 - Gerente confirma a criao da base 10 - Sistema valida os dados da interface fornecidos pelo Gerente 11 - Sistema envia email para o Instrutor comunicando que a base foi criada

Cenrios alternativos ( Excees ):

1- Sistema no consegue validar usurio e senha: 2 - Sistema avisa o Gerente atravs de uma mensagem na tela e solicita novamente 3- O login e senha para novamente validar. Validar no mximo 3 vezes o usurio e senha. Se no for possvel validar ento bloquear a conta deste usurio. 4- Erro ao validar dados da tela, falta preencher campos ou as informaes esto em formato incorreto. 5 - Sistema sinaliza o campo com problema e solicita correo.

EXERCCIOS

1- Como representado o Ator no UML?

2- Porque o caso de uso por tornar-se o brao direito do desenvolvedor? 3- O que um caso de uso? 4- Num determinado sistema acadmico, a rotina de atualizar a freqncia dos alunos pode ser executada por quem? Pelos funcionrios da Secretaria, pelo prprio Professor ou pelo Sistema de Avaliao on-line. Esses papis so representados por Atores. Faa o diagrama mostrando esta comunicao sistema-ator (e vice-versa) consiste da interao entre sistema e atores.

5- O que so pontos de extenso (extends) 6- Qual a funo principal dos Pacotes?

7- Pensando de Maneira contextual, faa um use case (caso de uso) simulado a entrega do material didtico, tendo como ator o instrutor, visualize em um cenrio perfeito e tente pensar em cada fase.

8- Pensando no exerccio acima, com as mesmas caractersticas pense nas excesses que podem ocorrer?