Diagramas de Casos de Uso Não diga pouco em muitas palavras, mas sim, muito em poucas. Pitágoras
Casos de uso O modelo de casos de uso modela os requisitos funcionais do sistema. É uma técnica de modelagem idealizada por Ivar Jacobson, na década de 70. Mais tarde a notação de casos de uso foi adicionada à UML. O diagrama da UML utilizado na modelagem de casos de uso é o diagrama de casos de uso.
Casos de Uso Um caso de uso descreve um conjunto de funcionalidades do sistema modelando o diálogo que ocorre entre algo que está fora do sistema, uma entidade externa chamada de ator e o sistema.
Casos de Uso Um caso de uso especifica o comportamento de um sistema ou parte dele. É uma descrição do conjunto de passos que o sistema executará para desempenhar suas funções Um caso de uso é baseado em um cenário que descreve como o ator interage com o sistema. Ele identifica eventos que podem ser solicitados e descreve a resposta do sistema para esses eventos
Diagrama de Casos de Uso O diagrama de casos de uso representa todas as formas de uso do sistema. Todas as funcionalidades. Casos de uso fornecem uma visão do sistema focada nas funcionalidade. Deixamos claro em que CASOS podemos USAR o sistema.
Diagrama de Casos de Uso Além das funcionalidades definimos como o software interage com o usuário para prover esse tipo de serviço. Podemos definir quem tem acesso ao que no contexto do sistema.
Diagrama de Casos de Uso Possibilitam um formato de apresentação compreensível que pode ser utilizado para aprimorar a comunicação, especialmente entre os projetistas da aplicação e os clientes. Também são úteis para outras fases, ajudando na quantificação, identificação de objetos e desenvolvimento de estratégias de teste (principalmente pelas descrições dos casos de uso)
Diagrama de Casos de Uso Objetivos: Delimitação do contexto de um sistema Documentação e o entendimento dos requisitos Descrição dos requisitos funcionais Principal saída da etapa de especificação de requisitos Principal entrada da etapa de análise Facilitam a comunicação entre os stakeholders São a base para a definição do cronograma Auxiliam na elaboração dos casos de teste
Casos de Uso Análise Tradicional O que o sistema deve fazer? Análise por Casos de Uso O que o sistema deve fazer... E para quem?
Atores São entidades do meio ambiente (externas ao sistema) que interagem com o sistema para solicitar algo ou informar algo. Atores podem dar inicio a eventos ou interagir com o sistema em decorrência do resultado de eventos ocorridos.
Categorias de atores: Atores Pessoas (Empregado, cliente, gerente, aluno, professor); Organizações ( Empresa Fornecedora, Administradora de cartões); Outros Sistemas ( Sistema de estoque, Sistema de cobrança); Equipamentos (Leitora de cartões, Sensores, Alarmes);
Atores Um ator corresponde a um papel representado em relação ao sistema O mesmo indivíduo pode ser o cliente que efetua compras na loja e pode ser o vendedor que processa vendas; Uma pessoa pode representar o papel de Funcionário de um banco, mas também pode ser Cliente do banco. O nome dado a um ator deve lembrar o seu papel.
Atores Atores se comunicam com o sistema por muitas razões, incluindo: Iniciar um caso de uso. Os casos de uso sempre são iniciados por atores. Pedir alguns dados armazenados no sistema, os quais então o caso do uso apresenta ao ator. Mudar os dados armazenados no sistema por meio de um dialogo com o sistema. Informar que ocorreu algo que o sistema deve estar ciente.
Atores Um ator inicia um caso de uso. Entretanto, depois que o caso de uso começou, ele pode se comunicar com vários outros atores. Considera-se às vezes, erradamente, que a associação de comunicação representa o fluxo de dados. Não é isso. A associação de comunicação representa um diálogo entre o ator e o sistema, um tipo de canal de comunicação sobre o qual podem fluir dados em ambas as direções durante o diálogo.
Casos de Uso Caso de uso é um requisito que será automatizado. É usado para representar as funcionalidades de um sistema. Representa o que o sistema faz (não como). O como está associado à descrição do caso de uso. À partir dessa descrição partimos para as atividades de projeto. Cadastrar produto
Casos de Uso Casos de uso se comunicam com atores por muitos motivos: Se algo especial aconteceu no sistema, um ator pode ter de ser informado. Um caso de uso pode necessitar da ajuda de um ator para tomar uma decisão. Um caso de uso pode delegar responsabilidade a um ator.
Conectando atores e casos de uso: Os atores e os casos de uso com os quais eles interagem são ligados pela associação de comunicação. A seta é opcional, mas, quando usada, ela indica qual elemento começa a interação. Para entender plenamente o papel definido para um ator, você deve saber em que casos de uso o ator está envolvido. Para entender plenamente o alcance de um caso de uso, você deve saber os atores com os quais ele se comunica.
Diagrama de Casos de Uso Associação entre ator e caso de uso Descrição de um conjunto de passos que é o detalhamento do caso de uso
Exemplo Cliente de banco pode usar um caixa automático para: Sacar dinheiro Transferir dinheiro Consultar saldo
Exemplo
Relacionamentos Os relacionamentos que ocorrem com mais freqüência quando trabalhamos com casos de uso são: Extend Include
Extensão É um tipo de relacionamento que só pode ocorrer entre casos de uso. Não existe um relacionamento de extensão entre um ator e um caso de uso. Define uma extensão de um relacionamento para um caso de uso a partir de outro caso de uso e essa extensão é opcional, ou seja é um comportamento que poderá ou não ser usado pelo caso de uso de origem.
Extensão Nesse relacionamento de extensão estou definindo que ao acessar a funcionalidade encerrar conta pode ser necessário ou não sacar dinheiro (Se a conta tem saldo positivo, vou sacar dinheiro) mas essa funcionalidade não é obrigatória, caso a conta tem saldo igual a zero não ocorrerá a funcionalidade de sacar dinheiro.é opcional. De forma semelhante, ao acessar a funcionalidade encerrar conta pode ser necessário ou não depositar dinheiro (Se a conta tem saldo negativo vou depositar dinheiro) mas essa funcionalidade não é obrigatória, caso a conta tem saldo positivo ou igual a zero não ocorrerá a funcionalidade de depositar dinheiro.
Extensão Pode ser usada para: Simplificar fluxos de eventos complexos Representar comportamentos opcionais Lidar com exceções Por exemplo, em uma descrição de um caso de uso temos fluxos básicos e fluxos alternativos, quando um fluxo alternativo é complexo e opcional podemos modelá-lo como um caso de uso, ligando-o ao caso de uso de origem por um relacionamento de extensão.
Extensão As seguintes situações podem dar margem à utilização do extend: Descrições de características que são opcionais ao comportamento básico do sistema, por exemplo, características que podem ser adquiridas ou não. Descrições complexas de erros ou tratamentos de exceções que, de outra forma, iriam obscurecer o comportamento primário do sistema. Exemplos disso são fluxos alternativos de tamanho significativo, especialmente aqueles cujo tamanho é maior do que o do fluxo principal.
Extensão Mais situações que podem dar margem à utilização do extend: Customização do modelo de requisitos para atender a necessidades específicas do usuário. Exemplos disso são fluxos alternativos que especificam como usuários específicos tratam diferentes condições que ocorrem dentro de um mesmo caso de uso. Gerência de escopo e versão. Um exemplo disso são características que não serão introduzidas até as últimas versões.
Extensão Podemos concluir então que o relacionamento de extensão me permite definir relações entre casos de uso onde existe uma adição de comportamentos opcionais ao caso de uso que está sendo estendido.
Inclusão Também é um tipo de relacionamento que só pode ocorrer entre casos de uso. Não existe um relacionamento de inclusão entre um ator e um caso de uso. Defini a inclusão de comportamentos presentes em outro caso de uso e essa inclusão será obrigatória. Sempre irá utilizar essas funcionalidades presentes no caso de uso incluído ao caso de uso de origem
Inclusão Identificar usuário é uma funcionalidade que poderia ser interna de sacar dinheiro e de depositar dinheiro mas sendo comum a vários casos de uso, é mais interessante modelar identificar usuário em um caso de uso que permita o reuso do mesmo. Assim, todos os casos de uso que necessitem identificar usuário de forma obrigatória é ligado ao caso de uso Identificar usuário através do relacionamento de inclusão.
Inclusão Pode ser usada para: Representar comportamentos reutilizáveis Simplificar fluxos de eventos complexos Quando existe uma dada função dentro do sistema que aparece em vários casos de uso, ou seja ela é utilizada por várias funcionalidades, podemos modelar essa função em um caso de uso uma única vez e ligá-la a todos os casos de uso que incluem essa função comum, dizendo que essa função é usada em diferentes partes do meu software.
Especialização Um caso de uso pode especializar outro caso de uso: Adicionando o fluxo de eventos original Refinando o fluxo de eventos original Especialização permite modelar comportamento diferenciado entre um caso de uso base e casos de uso filhos. Pouco utilizado. Pode existir entre atores também
Generalização de casos de uso Quando o usuário acessar a funcionalidade consultar saldo, essa funcionalidade vai se dar de uma maneira específica: ou consultar saldo na tela ou consultar saldo impresso.
Relacionamentos Relação Função Notação Associação O caminho de comunicação entre um ator e o(s) caso(s) de uso em que participa Inclusão Generalização Extensão A inserção de um comportamento adicional em um caso de uso base que explicitamente descreve a inserção Um relacionamento entre um caso de uso geral e um mais específico que herda e adiciona propriedades à aquele A inserção de um comportamento adicional em um caso de uso base que não sabe sobre o comportamento adicional
Sentido da seta Na inclusão partimos do caso de uso base para o caso de uso que será incluído Sacar dinheiro <<include>> Identificar usuário
Sentido da seta Na extensão parte do caso de uso opcional para o caso de uso base Inscrever Aluno <<extend>> Atualizar cadastro Secretária
Regras Não existe ligação entre atores. Atores são entidades externas do sistema, portanto a comunicação entre eles está fora do escopo do sistema, não devendo ser modelada no diagrama de caso de uso, um vez que ele modela apenas as funcionalidades do sistema.
Herança de Atores Alguns casos de uso são utilizados por vários atores, para simplificar o diagrama e diminuir o número de associações, cria-se um ator genérico. Além disso alguns casos de uso são exclusivos de apenas um ou alguns atores, mas não de todos. Generalização pode simplificar a representação gráfica do sistema.
Sem Generalização x Com Generalização
Exemplo
Estudo de Caso Locadora de Veículos O diagrama de caso de uso é criado com base em um cenário descrito a partir da especificação de requisitos. Assim, vamos construir o diagrama de caso de uso para a locadora de veículos descrita no cenário a seguir. É importante ressaltar que a partir de um conjunto de requisitos definidos podemos ter diferentes diagramas de casos de uso modelados pois estes diagramas refletem a solução que cada analista dá para o problema.
Cenário Locadora de Veículos Uma locadora de veículos deseja um sistema para facilitar o atendimento a seus clientes. O processo de aluguel de carros atual é confuso e está gerando insatisfação entre os clientes. A locadora é composta basicamente pelos seus funcionários e carros para aluguel. Os funcionários são identificados por cpf, nome, endereço, telefone. Já os carros estão divididos em diversos tipos: popular, luxo, utilitário, etc. As informações importantes sobre os carros a serem armazenadas são: código (placa do carro), tipo, modelo, ano, cor, chassis, km e valor do aluguel (diárias e semanais).
Cenário Locadora de Veículos Os funcionários serão responsáveis pelo cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o aluguel de um carro para o cliente e dar baixa no aluguel. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um quilometragem extra para seus aluguéis. Qualquer cliente é identificado por rg, nome, cpf, telefone, endereço, cidade. Desta forma, o cliente poderá solicitar o aluguel de carros a um funcionário da locadora.
Funcionalidades do Sistema Alugar Carro: cliente deve solicitar ao funcionário o aluguel do carro. O sistema verifica se o carro solicitado pelo cliente está disponível. Caso esteja, o processo de locação é concluído e o carro passa a estar indisponível. A data de aluguel deve ser guardada para calculo do valor do aluguel na devolução. Dar Baixa: cliente faz devolução do carro para o funcionário e solicita nota fiscal (recibo) com a quilometragem percorrida e o valor do aluguel. O funcionário coloca o status do carro novamente como disponível, solicita ao sistema para calcular o valor a ser pago e emite o recibo para o cliente. Cadastrar Cliente: cliente solicita ao funcionário que o cadastre na locadora. O funcionário recebe os dados e cadastra-o. Cadastrar Carro: funcionário cadastra o carro adquirido.
Funcionalidades do Sistema Na funcionalidade Alugar Carro temos descrito um conjunto de passos que serão executados no contexto desta funcionalidade. Essa descrição de passos servirá para descrever o caso de uso e não gerar outros casos de uso. Assim, solicitar aluguel, verificar disponibilidade do carro, alterar disponibilidade etc não serão casos de uso, mas passos que serão executados dentro do caso de uso Alugar Carro. O mesmo ocorre para Dar baixa, Cadastrar Cliente e Cadastrar Carro
Solução - Locadora de Veículos
Estudo de Caso II Sistema de reserva de passagem aérea Para esse estudo de caso trabalharemos com a lista de requisitos definidos durante a engenharia de requisitos. Importante deixar claro que nem todo requisito listado será um caso de uso. Ele pode ser simplesmente um passo interno de algum caso de uso que represente uma funcionalidade mais abrangente.
RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF9 RF10 RF11 RF12 RF13 RF14 RF15 RF16 RF17 RF18 Sistema deve permitir o cadastro do usuário Sistema deve permitir que o usuário se identifique Sistema deve consultar a classe vôo Sistema deve consultar o trecho da viagem Sistema deve permitir consulta aos aeroportos Sistema deve permitir consulta as datas disponíveis de ida e volta Sistema deve permitir que usuário consulte as formas de pagamento Sistema deve enviar para os usuários cadastrados e-mails promocionais Sistema deve permitir que o usuário consulte CEP no sistema dos correios Sistema deve permitir que o usuário solicite a reserva on-line Sistema deve gerar código de reserva Sistema deve emitir e-mail ao usuário confirmando a reserva com dados Sistema deve permitir que usuário cancele a reserva Sistema deve permitir que administrador emita relatório de reservas confirmadas Sistema deve permitir que administrador emita relatório de reservas canceladas Sistema deve validar o pagamento junto com a operadora de cartão Sistema deve permitir que o administrador emita relatório de usuários cadastrados Sistema deve permitir que usuário edite seus dados pessoais
RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 Sistema deve permitir o cadastro do usuário Sistema deve permitir que o usuário se identifique Sistema deve consultar a classe vôo Sistema deve consultar o trecho da viagem Sistema deve permitir consulta aos aeroportos Sistema deve permitir consulta as datas disponíveis de ida e volta Sistema deve permitir que usuário consulte as formas de pagamento Sistema deve enviar para os usuários cadastrados e-mails promocionais O RF1 será modelado como caso de uso. Importante percebermos que os RF de 2 até o 7 são passos internos da funcionalidade mais abrangente efetuar reserva, portanto eles não se tornarão casos de uso. Essas funcionalidades farão parte da descrição do caso de uso efetuar reserva. O RF8 será um caso de uso, uma vez que representa uma funcionalidade específica do sistema.
RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF9 RF10 RF11 RF12 Sistema deve permitir o cadastro do usuário Sistema deve permitir que o usuário se identifique Sistema deve consultar a classe vôo Sistema deve consultar o trecho da viagem Sistema deve permitir consulta aos aeroportos Sistema deve permitir consulta as datas disponíveis de ida e volta Sistema deve permitir que usuário consulte as formas de pagamento Sistema deve enviar para os usuários cadastrados e-mails promocionais Sistema deve permitir que o usuário consulte CEP no sistema dos correios Sistema deve permitir que o usuário solicite a reserva on-line Sistema deve gerar código de reserva Sistema deve emitir e-mail ao usuário confirmando a reserva com dados Os RFs 9, 11 e 12 também são passos internos da funcionalidade mais abrangente efetuar reserva, portanto eles não se tornarão casos de uso. Já o RF10 é exatamente a funcionalidade efetuar reserva, que engloba todos estes outros RFs citados, assim ele será um caso de uso.
RF13 RF14 RF15 Sistema deve permitir que usuário cancele a reserva Sistema deve permitir que administrador emita relatório de reservas confirmadas Sistema deve permitir que administrador emita relatório de reservas canceladas O RF 13 será modelado como um caso de uso, visto que cancelar reserva é um ato a parte do sistema onde o usuário vai solicitar cancelamento da reserva, o sistema exibe as reservas desse usuário para que ele possa selecionar aquela que ele deseja cancelar. O RF14 e o RF15 serão modelados como um caso de uso emitir relatório de reservas, já que o que muda é apenas o status da reserva que será incluída no relatório. Essa diferença pode ser interna ao caso de uso, detalhada na descrição.
RF16 RF17 RF18 Sistema deve validar o pagamento junto com a operadora de cartão Sistema deve permitir que o administrador emita relatório de usuários cadastrados Sistema deve permitir que usuário edite seus dados pessoais O RF 16 também é um passo interno da funcionalidade mais abrangente efetuar reserva, portanto não se tornará caso de uso. O RF17 será caso de uso novo pois embora seja um relatório, este é totalmente diferente dos outros (RF14 e RF15). O RF18 será modelado como um caso de uso pois a edição dos dados do usuário será desvinculada do efetuar cadastro. Para edição ele tem que efetuar o login, abrir sua ficha cadastral já existente para então fazer a alteração. São ação desvinculadas do ponto de vista do usuário. Não estamos modelando um manter usuário nesse sistema on-line.
Casos de uso definidos Cadastrar Usuário Enviar e-mail promocional Efetuar reserva Cancelar reserva Emitir relatório de reservas Emitir relatório de usuários cadastrados Atualizar dados pessoais.
Definição de Atores Os RF14, RF15 e RF17 são efetuados pelo administrador do sistema. Os RF2, 7, 8, 10, 12, 13 e 18 citam um ator usuário O RF9 diz que haverá interação com um sistema externo (Sistema dos correios), como um sistema externo que troca informação com o sistema é considerado um ator, teremos o ator Sistema do Correio. Da mesma forma que o RF16 cita interação com a operadora de cartão, definindo assim o ator Operadora de Cartão
RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF9 RF10 RF11 RF12 RF13 RF14 RF15 RF16 RF17 RF18 Sistema deve permitir o cadastro do usuário Sistema deve permitir que o usuário se identifique Sistema deve consultar a classe vôo Sistema deve consultar o trecho da viagem Sistema deve permitir consulta aos aeroportos Sistema deve permitir consulta as datas disponíveis de ida e volta Sistema deve permitir que usuário consulte as formas de pagamento Sistema deve enviar para os usuários cadastrados e-mails promocionais Sistema deve permitir que o usuário consulte CEP no sistema dos correios Sistema deve permitir que o usuário solicite a reserva on-line Sistema deve gerar código de reserva Sistema deve emitir e-mail ao usuário confirmando a reserva com dados Sistema deve permitir que usuário cancele a reserva Sistema deve permitir que administrador emita relatório de reservas confirmadas Sistema deve permitir que administrador emita relatório de reservas canceladas Sistema deve validar o pagamento junto com a operadora de cartão Sistema deve permitir que o administrador emita relatório de usuários cadastrados Sistema deve permitir que usuário edite seus dados pessoais
Funcionalidades do Administrador
Funcionalidades do Usuário Podemos perceber que o usuário (internauta) pode se cadastrar mas que para Efetuar reserva, Cancelar reserva e Atualizar dados pessoais, ele tem que ser um usuário logado, ou seja um tipo especial de usuário que vamos chamar de cliente.
Ator Correio O sistema de correios é consultado durante o cadastro do usuário, para consultar o CEP, assim esse ator está ligado ao caso de uso Cadastrar usuário
Ator Operadora do Cartão A operadora do cartão é um sistema externo que será acessado durante a validação do pagamento que ocorre durante o caso de uso Efetuar reserva
Diagrama de caso de uso finalizado
Módulo de Gestão de Usuário RF1 O software deve ident. e validar todos os usuários que desejarem acessá-lo, identificando seu perfil RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF9 O software deve disp. ao usuário identificado as func. associadas ao seu perfil e ao seu papel no sist. (coordenador, bolsista, etc). As func. de acesso restrito e as func. de acesso público. O software deve disp. ao usuário não identificado somente as func. Públicas. O software deve permitir ao usuário recuperar a sua senha, caso esqueça O software deve permitir que o adm. inclua, altere ou exclua usuários O software deve permitir que o adm. inclua, altere ou exclua perfis de acesso O software deve permitir que o adm. associe as func. disponíveis nos módulos aos perfis cadastrados ou exclua dos perfis as funcionalidades previamente associadas. O software deve permitir que o adm. associe um usuário a um único perfil de acesso O software deve permitir ao adm. consultar as funcionalidades associadas a um perfil RF10 O software deve permitir ao adm. consultar os usuários associados a um determinado perfil RF11 O software deve permitir ao adm. indicar se um determinado usuário pode administrar seus substitutos ou não RF12 O software deve permitir que os usuários devidamente autorizados designem um ou mais substitutos com os respectivos períodos de substituição (data inicial e final) e selecionem um subconjunto das suas funcionalidades as quais os substitutos terão acesso.
Módulo de Gestão de Usuário RF13 O software deve permitir que todos os usuários façam a manutenção de seus dados pessoais:email, localização, senha e telçefones. RF14 O software deve permitir que os administradores reenviem a senha de qualquer usuário e que os usuários reenviem a própria senha RF15 O software deve gerar senhas temporárias, válidas somente no primeiro login, quando as senhas forem reenviadas pelos administradores ou pelos próprios usuários RF16 O software deve solicitar a troca de senha, após o login, para todas as senhas que já expiraram RF17 O software deve, caso o usuário corrente seja um substituto, apresentar a lista de usuários que ele está substituindo na data corrente. RF18 O software deve, caso o usuário corrente seja um substituto, permitir que ele selecione o usuário com o qual vai atuar, caso ele seja substituto de mais de um usuário.
Estudando cada RF RF1- O software deve identificar e validar todos os usuários que desejarem acessá-lo, identificando seu perfil Caso de Uso: Autenticar Usuário Ator: Usuário RF2- O software deve disponibilizar ao usuário identificado as funcionalidades associadas ao seu perfil e ao seu papel no sistema (coordenador, bolsista, etc). As funcionalidades de acesso restrito e as funcionalidades de acesso público. Passo que ocorre dentro do autenticar usuário RF3- O software deve disponibilizar ao usuário não identificado somente as funcionalidades de acesso público. Passo que ocorre dentro de autenticar usuário, podendo ser modelada como um fluxo alternativo. RF4- O software deve permitir ao usuário recuperar a sua senha, caso esqueça Se quiséssemos modelar a possibilidade de recuperação de senha a qualquer momento através de um menu daí seria um caso de uso, mas neste caso vamos optar por só poder recuperar senha dentro do efetuar login, então essa funcionalidade será um fluxo alternativo de efetuar login.
Estudando cada RF RF5- O software deve permitir que o administrador inclua, altere ou exclua usuários Caso de uso: Administrar usuário Ator: Administrador RF6- O software deve permitir que o administrador inclua, altere ou exclua perfis de acesso Caso de uso: Administrar perfis de acesso Ator: Administrador RF7- O software deve permitir que o administrador associe as funcionalidades disponíveis nos módulos aos perfis cadastrados ou exclua dos perfis as funcionalidades previamente associadas. Passo da funcionalidade Administrar perfil de acesso. RF8- O software deve permitir que o administrador associe um usuário a um único perfil de acesso Passo da funcionalidade Administrar perfil de acesso.
Estudando cada RF RF9- O software deve permitir ao administrador consultar as funcionalidades associadas a um perfil Passo da funcionalidade Administrar perfil de acesso RF10- O software deve permitir ao administrador consultar os usuários associados a um determinado perfil Passo da funcionalidade Administrar perfil de acesso RF11- O software deve permitir ao administrador indicar se um determinado usuário pode administrar seus substitutos ou não Passo da funcionalidade Administrar usuário RF12- O software deve permitir que os usuários devidamente autorizados designem um ou mais substitutos com os respectivos períodos de substituição (data inicial e final) e selecionem um subconjunto das suas funcionalidades as quais os substitutos terão acesso. Caso de uso: Administrar substitutos Ator: usuário autenticado
Estudando cada RF RF13- O software deve permitir que todos os usuários façam a manutenção de seus dados pessoais: e-mail, localização, senha e telefones. Caso de uso: Manter dados pessoais Ator: usuário autenticado RF14- O software deve permitir que os administradores reenviem a senha de qualquer usuário e que os usuários reenviem a própria senha Passo presente em administrar usuário e em administrar perfil RF15- O software deve gerar senhas temporárias, válidas somente no primeiro login, quando as senhas forem reenviadas pelos administradores ou pelos próprios usuários Passo presente em casos de uso do sistema RF16- O software deve solicitar a troca de senha, após o login, para todas as senhas que já expiraram Regras associadas a autenticar usuário
Estudando cada RF RF17- O software deve, caso o usuário corrente seja um substituto, apresentar a lista de usuários que ele está substituindo na data corrente. Regra interna ao autenticar usuário RF18- O software deve, caso o usuário corrente seja um substituto, permitir que ele selecione o usuário com o qual vai atuar, caso ele seja substituto de mais de um usuário. Caso de uso: Selecionar perfil de uso Ator: Usuário autenticado
Solução - Caso de Uso
Descrição Casos de Uso UC1 Nome do Caso de Uso Objetivo: Breve descrição do que o caso de uso deverá fazer Requisitos: A qual RF do doc de requisitos ele se refere Atores: Quem acessa esse caso de uso Prioridade: É prioritário ou não (cliente define) Pré-condições: quais as condições necessárias antes de disparar o caso de uso Freqüência de uso: a frequencia me dá idéia de criticalidade (risco) Criticalidade (risco): importância do caso de uso Condição de entrada: o que dispara esse caso de uso Fluxo Principal: descrever ações normais que ocorrem Fluxo Alternativo: desvios do cenário principal Extensões: descrevem os extends Pós Condições: o que deve ser verdade depois de executado o caso de uso Regras de Negócio: que pode ser definido agora ou em doc à parte.
Prioridade e Risco Devemos considerar os casos de uso mais importantes primeiramente. Para identificar os mais importantes verificamos os parâmetros: risco de desenvolvimento(criticalidade) e prioridade estabelecidas pelo usuário. Dessa forma, cada caso de uso se encaixa em uma das categorias a seguir: 1. Risco alto e prioridade alta: casos de uso nesta categoria são os mais críticos. Devem ser considerados o quanto antes. 2. Risco alto e prioridade baixa: embora os casos de uso nesta categoria tenham risco alto, é necessário, antes de começar a considerá-los, negociar com o cliente em relação a sua verdadeira necessidade. 3. Risco baixo e prioridade alta: embora os casos de uso tenham prioridade alta, é necessário ter em mente que os casos de uso de mais alto risco devem ser considerados primeiro. 4. Risco baixo e prioridade baixa: em situações em que o desenvolvimento do sistema está atrasado, estes casos de uso são os primeiros a serem "cortados".
Exemplo de descrição UC1 Consultar Clientes Objetivo: O sistema deve permitir que o setor de atendimento ao cliente consulte clientes cadastrados Requisitos: RF1 Atores: Setor de atendimento ao cliente Prioridade: - Pré-condições: - Freqüência de uso: diária Criticalidade: - Condição de entrada: o ator seleciona a opção consultar cliente
Fluxo Principal: 1. O sistema apresenta tela de busca de clientes contendo as informações: - Nome (campo editável) - Status (lista contendo os itens: Em dia, Inadimplente) - As opções: * Buscar * Cancelar 2. O ator informa dados de busca e seleciona a opção Buscar [A1] 3. O sistema apresenta tela com informações dos Clientes de acordo com o filtro especificado: - Nome (somente leitura) - Status (somente leitura) - CPF (somente leitura) - Data de Nascimento (somente leitura) - A opção Detalhar 4. O sistema apresenta ao final a opção Voltar
Fluxo Principal: 5. O ator seleciona a opção Detalhar [A2] 6. O sistema apresenta tela de detalhes para o cliente contendo as informações: - Nome (somente leitura) - CPF (somente leitura) - Status (somente leitura) - Data de Nascimento (somente leitura) - Endereço (somente leitura) - Motivo [RN1] (somente leitura) - A opção Ok 7. O ator seleciona a opção ok 8. O sistema retorna ao passo 3 do fluxo principal. Se o cliente estiver com status em dia não aparece, se estiver em atraso, mostra o motivo de acordo com regra negócio 1
Fluxo Alternativo: Fluxo Alternativo: [A1] O ator selecionou a opção Cancelar 1. Sistema retorna para a tela inicial. 2. O caso de uso é encerrado. [A2] O ator selecionou a opção Voltar 1. Sistema retorna ao passo 1 do fluxo principal. Extensões: - Pós Condições: - Regras de Negócio: [RN1] O campo Motivo será apresentado apenas se o Status do cliente for inadimplente
Descrições independentes de Interface Alteração na Interface alteração descrição Considere a situação de uma parte da interface estar sendo continuamente modificada, por alguma razão. O fato da interface ser modificada possivelmente resultará na modificação da descrição do caso de uso. Assim, casos de uso devem ser independentes do desenho da interface pelo fato de que os requisitos do sistema não devem estar associados a detalhes de interface. A atenção deve estar na essência das interações entre atores e o sistema, em vez de como cada interação é realizada fisicamente. Por exemplo, usar o termo "envia uma requisição" ao invés de "duplo clique sobre o botão de envio de requisições".
Caso de Uso Incluir Cliente UC1 Incluir Clientes Objetivo: O sistema deve permitir que o administrador efetue o cadastrado de cliente Requisitos: RF2 Atores: Administrador Prioridade: - Pré-condições: - Freqüência de uso: - Criticalidade: - Condição de entrada: o ator seleciona a opção incluir cliente
Fluxo Principal: 1. O sistema apresenta tela de cadastro de clientes contendo as informações: (Dados Pessoais) - Nome (campo editável) - CPF(campo editável) - RG (campo editável) -Data de Nascimento (campo editável) -Sexo (lista contendo as opções feminino e masculino) (Informações de Contato) - Endereço (campo editável) - Telefone de contato (campo editável) - e-mail (campo editável) - As opções: * Incluir Cliente * Cancelar
2. O ator informa os dados do cliente e seleciona a opção incluir Cliente [A1] 3. O sistema valida os dados informados [RN1] 4. O sistema efetua o cadastro do cliente [RN2] 5. O sistema exibe a mensagem Cliente cadastrado com sucesso com a opção OK no final. 6. O ator seleciona OK Fluxo Principal: 7. O sistema retorna para a tela inicial 8. O caso de uso é encerrado.
Fluxo Alternativo Fluxo Alternativo: [A1] O ator seleciona a opção Cancelar 1. Sistema retorna para a tela inicial. 2. O caso de uso é encerrado. [A2] Dados para cadastro do cliente inválidos 1. O sistema exibe mensagem de erro Existem informações obrigatórias que não foram preenchidas com a opção OK no final. 2. O ator seleciona a opção 3. O sistema retorna ao passo 1 do fluxo principal. Extensões: - Pós Condições: - Regras de Negócio: [RN1] Todos os campos do cadastro de clientes são obrigatórios. [RN2] Ao efetuar o cadastro do cliente, um número de matrícula deve ser gerado para o cliente.
Extensão ou Fluxo Alternativo Conceitualmente, o mecanismo de extensão é idêntico aquele dos fluxos alternativos. Um caso de uso de extensão, assim como um fluxo alternativo, insere a si próprio no fluxo do caso de uso que ele estende. Somente o caso de uso de extensão conhece o ponto no caso de uso base onde o comportamento será inserido. Em conseqüência, freqüentemente um caso de uso de extensão começa sua vida como um fluxo alternativo.
Extensão ou Fluxo Alternativo Nem todo fluxo alternativo deve virar um caso de uso de extensão. As regras para os fluxos alternativos são mais frouxas do que aquelas para os casos de uso de extensão. Devido ao fato de que os fluxos alternativos são parte do caso de uso, eles podem explorar seu conhecimento do estado do caso de uso, suas pré-condições, e outros fluxos de eventos para terminar o caso de uso ou para continuar o fluxo do caso de uso em pontos de extensão diferentes daquele onde eles assumiram o controle. Tudo o que os casos de uso de extensão conhecem a respeito do caso de uso original é o ponto de extensão onde eles introduziram a si próprios no fluxo de eventos do caso de uso estendido.