DIAGRAMA DE CASO DE USOANÁLISE E PROJETO DE SISTEMAS

DIAGRAMA USE CASEOs requisitos que um sistema possui muitas vezes são complexos, não estou falando aqui de requisitos simples, como o usuário pedir "Faça um programa que controle a média de um boletim escolar". Temos na verdade que lidar com dezenas de páginas de "desejos do usuário". Sim, o usuário deseja que o sistema realize determinadas tarefas, deseja que o sistema realize seus sonhos e muitas vezes deseja que ele faça milagres. A espectativa dos usuários 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 solução para os seus problemas. Sabemos que isto não é verdade e que algumas tarefas não podemos modelar e passar para dentro do software.

DIAGRAMA USE CASEA Língua Portuguesa, assim como outras, é ambígua, por natureza. Portanto, necessitamos de um padrão que permita o uso de linguagem natural, mas em um formato que reduza as ambiguidades. Além disso, que permita com facilidade converter essa estrutura para os diagramas e implementações do sistema. Para isto então temos os diagramas de Caso de Uso na UML.

O Início, entendendo os RequisitosA UML e a modelagem de casos de usos não interfere nas técnicas usadas pelos desenvolvedores para o levantamento de requisitos. Pelo contrário, o caso de uso torna-se o "braço direito" do desenvolvedor, auxiliando-o a validar os requisitos extraídos junto ao usuário.

O levantamento de requisitos de um sistema não é uma tarefa fácil, mas também não é impossível. O problema reside no fato de que estamos lidando com um ser humano que expressa suas idéias, geralmente fora de ordem e sem muita explicação e temos que entender e levantar os requisitos

O Início, entendendo os RequisitosSabemos que os problemas existem, mas com as técnicas, ferramentas e paradigma adequados, tudo pode correr tranqüilamente. Temos que ter em mente que o usuário não é o nosso inimigo, pelo contrário, se conseguirmos estabelecer com ele uma comunicação sem ruídos, certamente a validação ocorrerá sem problemas e o nosso software conseguirá então satisfazer os desejos do usuário.

Durante este processo de levantamento de requisitos através de conversas com os usuários é preciso mostrar para o usuário que devemos formar um time para alcançarmos o mesmo objetivo. É importante que durante este processo haja muita troca de informações entre os usuários e analistas. Esta troca de informações é que irá garantir o sucesso desta etapa de levantamento de requisitos.

O USE CASEUm caso de uso (Use Case) descreve uma seqüência de ações que representam um cenário principal (perfeito) e cenários alternativos, com o objetivo de demonstrar o comportamento de um sistema (ou parte dele), através de interações com atores.

Uma vez que o desenvolvedor levante os requisitos com o usuário, há a necessidade de documentá-los, não só para entendimento e validação de ambas as partes, como para servir de base não ambígua para toda a equipe de desenvolvimento. A documentação dos requisitos evita que informações importantes se percam, sendo descobertas apenas ao apresentar o produto final ao usuário.

O USE CASEUtilizando a modelagem de casos de uso, o primeiro passo do desenvolvedor é separar as funcionalidades do sistema. Destas funcionalidades, devemos agrupar um conjunto de ações que tenham um objetivo bem definido.

O caso de uso, por expressar os requisitos do sistema - nada mais do que a essência deste -, é utilizado durante todo o processo de desenvolvimento. Os requisitos além de serem a base para a criação dos modelos de análise, projeto e implementação, também são usados como base para a criação 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 construção dos demais, sendo muito importante estar bem definido expressando os desejos do cliente.

O USE CASEAo modelarmos um sistema, necessitamos saber até que ponto devemos nos preocupar. Estes pontos-limites são a fronteira do sistema.

Um caso de uso é representado por uma elipse contendo o seu nome. O nome do caso de uso também pode ser colocado abaixo da elipse, que pode conter ou não compartimentos referentes a pontos de extensão

AtoresNa 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 papéis. Um caso de uso pode se relacionar com mais de um ator.

Um ator representa um conjunto de papéis exercido por um usuário do sistema ao interagir com um determinado caso de uso. Um ator é, portanto, um papel que um usuário desempenha em relação ao sistema.

AtoresOs atores não precisam ser humanos, embora sejam representados como bonecos humanos nos diagramas de caso de uso. Um ator também pode ser um sistema externo que necessita de alguma informação do sistema atual. Existem diversas variações 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 estereótipo padrão para um ator é a figura de um "stick man", contendo seu nome abaixo da figura. Outra representação consiste num retângulo de classe, com o estereótipo. E, ainda, é permitido ao desenvolvedor utilizar outros ícones que identifiquem mais precisamente o tipo de ator.

AtoresÉ responsabilidade do caso de uso demonstrar com quais atores o sistema interage. Essa identificação na fase de análise fornece ao projetista, no futuro, base para a criação dos perfis de acesso ao sistema. O caso de uso especifica como alcançar a realização de um procedimento sem relacionar detalhes de implementação. Portanto, mostramos o que executar sem definir a forma como é feito.

Vamos Analisar um exemplo que incluímos um cenário principal e cenários alternativos para um caso de uso referente a sua reserva de um carro popular:

Caso de uso – Reserva de um carro

CenáriosCenáriosalternativosalternativos

CenárioCenárioprincipalprincipal

Ator: Atendimento ao clienteCenário Principal

1. O cliente informa ao atendente a data da reserva, que é repassada ao sistema;

2. O sistema mostra o veículo, indicando as opções. O sistema calcula e exibe o número de reservas ainda disponíveis.

3. Um ou vários veículos disponíveis é (são) escolhido(s) para reserva.

4. O sistema solicita o CPF do cliente, para identificação do mesmo no sistema. O sistema pesquisa o cliente e mostra nome e telefones de contato, para confirmação.

5. Após confirmação, a reserva é efetuada em nome do cliente.

Cenários alternativos

Alternativa: Data não disponível para reserva

1ª) O sistema verifica se para a data informada é possível efetuar reservas. Caso negativo, uma nova data deve ser solicitada.

Alternativa: Reservas esgotadas

1ª) O sistema verifica se para o dia informado, as reservas estão esgotadas. O sistema deve possibilitar que seja informada nova data ou que se encerre a solicitação de reserva.

Alternativa: Cliente não cadastrado

4ª) Se o cliente não for cadastrado: Cadastrar Cliente de Reserva

AtoresImportante salientar que não existe um padrão da UML que determine uma forma única de se escrever casos de uso. As ações podem ser descritas em parágrafos ou através de enumerações, identificadas (por letras ou números) ou não. Outra forma é criar um texto com seções de pré e pós-condições. O importante é que cada caso de uso deve relacionar o suficiente para seu entendimento e que seja compreensível 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 não podem trabalhar sozinhas no contexto do sistema. Portanto, esses casos de uso precisam se relacionar com outros casos de uso e com atores que enviarão e receberão mensagens destes.

*Relacionamentos entre casos de uso: generalização/herança, extensão e inclusão.

*Relacionamentos entre atores: generalização/herança *Relacionamentos entre atores e casos de uso: associação

Associação

Representa a interação do ator com o caso de uso, ou seja, a comunicação entre atores e casos de uso, por meio do envio e recebimento de mensagens. As associações entre casos de uso são sempre binárias, ou seja, envolvem apenas dois elementos. Representam o único relacionamento possível entre atores e casos de uso.

Por exemplo: O ator Correntista envia e recebe mensagens do Caso de Uso Calcular Empréstimo Pessoal, por um relacionamento de associação.

Generalização

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 extensão, com uma variação do comportamento normal sendo descrita sem muito rigor. Segue o mesmo conceito da orientação a objetos. Podemos dizer também que este relacionamento é conhecido como herança.

Por exemplo: podemos criar um ator genérico Aluno e especializá-lo nos atores Aluno Matriculado e Aluno Ouvinte.

Extensão (extends)

Um relacionamento de extensão entre casos de uso indica que um deles terá seu procedimento acrescido, em um ponto de extensão, de outro caso de uso, identificado como base. Os pontos de extensão são rótulos que aparecem nos cenários do caso de uso base. É permitido colocar diversos pontos de extensão num mesmo caso de uso, inclusive repetir um mesmo ponto de extensão.

Inclusão (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 inclusão, dentro da descrição de um caso de uso base, é representado com o termo Include seguido de seu nome.

Inclusão (Include)

Por exemplo:

Cenário Principal

1. O aluno digita sua matrícula. O sistema verifica se a matrícula é válida e ativa. Include (Validar Matrícula). (...)

Mais do que evitar a cópia de trechos idênticos, ganhamos tempo de modelagem e também de implementação ao trabalhar com casos de uso de inclusão. Perceba ainda que teremos um ganho significativo quando depois formos fazer a manutenção do sistema.

Modelando requisitos com casos de uso

Não existe uma ordem pré definida que determine quais diagramas devem ser modelados primeiramente. A ordem é determinada pela preferência do desenvolvedor e/ou processo que esteja sendo usado. Sabemos que a UML é independente de processo.

Alguns desenvolvedores iniciam a modelagem do sistema pela criação 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 métodos.

Modelando requisitos com casos de uso

Outros desenvolvedores começam 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 deverão ser consideradas quando for elaborado o sistema e somente depois deste diagrama partem para a definição das classes através 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 também documentar as principais atividades do sistema antes de começar 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 pacotesEm sistemas de media/alta complexidade é comum termos dezenas de casos de uso. Nesse caso, a representação de todos eles em um único diagrama é uma tarefa impossível. A fim de minimizar a visualização 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 genérico e adaptável).

Casos de uso e pacotesGraficamente, o pacote é representado como um grande retângulo com um pequeno retângulo 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 conteúdo seja mostrado. Caso contrário, o nome do pacote deve vir no seu interior.

Casos de uso e pacotesMuitas vezes nos perguntamos quando usar isto tudo, inicialmente pode parecer um pouco burocrático e não necessário este processo todo, mas veremos ao passar do tempo que ele é fundamental para uma boa análise.

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

Casos de uso e pacotesAs vezes nos perguntamos, quantos casos de uso você deve ter? Não existe uma resposta exata para isto. Depende do tamanho do sistema e também dependerá da equipe e tipo de sistema que está sendo feito. Lembre-se que você terá vários cenários e que em cada cenário podem existir vários casos de uso e um caso de uso pode ter casos alternativos. Com isto você já viu que o número de casos de uso será medido pelo seu bom senso de modelagem e que você deverá fazer quantos achar necessário para levantar todos os requisitos. Não tem um número e nem uma fórmula para calcular isto.

Exemplos de uma descrição textualUse Case: Criar base de conhecimento para Help Desk

Atores:

Gerente

Exemplos de uma descrição textualCenário principal de Sucesso ( Perfeito ):

1 - Gerente fornece usuário e senha para login2 - Sistema valida usuário e senha3 - Sistema redireciona Gerente para sua página home4 - Gerente seleciona no menu a opção para criar base5 - Sistema redireciona o Gerente para uma tela de criação da base6 - Gerente seleciona em uma lista o curso para o qual quer criar base7 - Gerente seleciona em uma lista de instrutores habilitados o responsável pelas informações8 - Gerente informa data prevista para resolução do problema9 - Gerente confirma a criação da base10 - Sistema valida os dados da interface fornecidos pelo Gerente11 - Sistema envia email para o Instrutor comunicando que a base foi criada

Exemplos de uma descrição textualCenários alternativos (Exceções):

1- Sistema não consegue validar usuário e senha:

2 - Sistema avisa o Gerente através de uma mensagem na tela e solicita novamente

3- O login e senha para novamente validar. Validar no máximo 3 vezes o usuário e senha. Se não for possível validar então bloquear a conta deste usuário.

4- Erro ao validar dados da tela, falta preencher campos ou as informações estão em formato incorreto.

5 - Sistema sinaliza o campo com problema e solicita correção.

EXERCÍCIOS1- Como é representado o Ator no UML?2- Porque o caso de uso por tornar-se o braço direito do desenvolvedor?3- O que é um caso de uso?4- Num determinado sistema acadêmico, a rotina de atualizar a freqüência dos alunos pode ser executada por quem? Pelos funcionários da Secretaria, pelo próprio Professor ou pelo Sistema de Avaliação on-line. Esses papéis são representados por Atores. Faça o diagrama mostrando esta comunicação sistema-ator (e vice-versa) consiste da interação entre sistema e atores.5- O que são pontos de extensão (extends)6- Qual a função principal dos Pacotes?7- Pensando de Maneira contextual, faça um use case simulado a entrega do material didático, tendo como ator o instrutor, visualize em um cenário perfeito e tente pensar em cada fase.8- Pensando no exercício acima, com as mesmas características pense nas excessões que podem ocorrer?