Casos de Uso 1 Slides extrados do livro

Casos de Uso 1

Slides extraídos do livro: Princípios de Análise e Projeto Orientados a Objetos com UML Eduardo Bezerra Editora CAMPUS n. Com adaptações feitas pelo professor 2

Antes de fazer, decida o que você quer fazer. 3

Introdução n O modelo de casos de uso é uma representação n n das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com o mesmo. n O modelo de casos de uso modela os requisitos funcionais do sistema. 4

Introdução n O diagrama da UML utilizado na modelagem de casos de uso é o diagrama de casos de uso. n Técnica de modelagem idealizada por Ivar Jacobson, na década de 1970. n Mais tarde, incorporada ao método Objectory. n Posteriormente, a notação de casos de uso foi adicionada à UML. 5

Introdução n O modelo de casos de uso força os desenvolvedores a moldar o sistema de acordo com o usuário. 6

Componentes do modelo n O modelo de casos de uso de um sistema é composto de: n n n Casos de uso Atores Relacionamentos entre os elementos anteriores n Relacionamentos podem ser de: § Generalização § Associação 7

Casos de uso n Um caso de uso n n é a especificação de uma seqüência de interações entre um sistema e os agentes externos. é uma seqüência de ações que um sistema executa para produzir um resultado de valor observável por um ator n Define parte da funcionalidade de um sistema n sem revelar a estrutura e o comportamento internos deste sistema. n Um modelo de casos de uso típico é formado de vários casos de uso. 8

Casos de uso Um caso de uso representa quem faz o que (interage) com o sistema, sem considerar o comportamento interno do sistema. 9

Descrições narrativas n Cada caso de uso é definido através da descrição narrativa das interações que ocorrem entre o(s) elemento(s) externo(s) e o sistema. 10

Exemplo de descrição contínua n O Cliente chega ao caixa eletrônico e insere seu cartão. O Sistema requisita a senha do Cliente. Após o Cliente fornecer sua senha e esta ser validada, o Sistema exibe as opções de operações possíveis. O Cliente opta por realizar um saque. Então o Sistema requisita o total a ser sacado. O Sistema fornece a quantia desejada e imprime o recibo para o Cliente. 11

Exemplo de descrição numerada 1. 2. 3. 4. 5. 6. 7. 1. Cliente insere seu cartão no caixa eletrônico. 2. Sistema apresenta solicitação de senha. 3. Cliente digita senha. 4. Sistema exibe menu de operações disponíveis. 5. Cliente indica que deseja realizar um saque. 6. Sistema requisita quantia a ser sacada. 7. Cliente retira a quantia e recibo. 12

Exemplo de descrição numerada Cliente Sistema Insere seu cartão no caixa eletrônico. Apresenta solicitação de senha. Digita senha. Exibe operações disponíveis. Solicita realização de saque. Requisita quantia a ser sacada. Retira a quantia e o recibo. 13

Detalhamento n O grau de detalhamento a ser utilizado na descrição de um caso de uso também pode variar. n Um caso de uso sucinto descreve as interações sem muitos detalhes. n Um caso de uso expandido descreve as interações em detalhes. 14

Cenários n Um caso de uso tem diversas maneiras de ser realizado. n Um cenário é a descrição de uma das maneiras pelas quais um caso de um pode ser realizado. n Um cenário também é chamado de instância de um caso de uso. n Normalmente há diversos cenários para um mesmo um caso de uso. 15

Cenário Principal n Descreve um seqüência de ações que serão executadas considerando que nada de errado ocorrerá durante a a execução da seqüência. n É o cenário perfeito 16

Cenário Principal Trecho do caso de uso “Emitir Saldo em um terminal de caixa eletrônico” Ator: Correntista n 1. O sistema faz a leitura do cartão magnético. n 2. O sistema solicita a digitação da senha. O correntista informa sua senha. n 3. O sistema valida a senha, verificando se é a mesma senha que está associada ao correntista. n 4. O correntista seleciona a opção de saldo n 5. O sistema questiona o tipo de saldo: conta corrente, poupança, investimentos n 6. O sistema processa e mostra o saldo solicitado pelo cliente netc 17

Cenários Cenário Perfeito: É impossível tudo ocorrer sem problemas ! n O mundo não é perfeito, muito menos as transações de um sistema. Então, como podemos representar as exceções? Desenvolver os Cenários Alternativos ! 18

Cenários Alternativos n Permite uma seqüência diferente de eventos em relação ao cenário principal n Para cada um destes cenários atípicos será definido o fluxo de eventos correspondente. n São os casos onde podem ocorrer exceções, erros ou qualquer outra ação possível e diferente. 19

Cenários Alternativos n 1. O sistema faz a leitura do cartão magnético n Alternativa: Problemas na leitura do cartão magnético n 1 a) Se o sistema não conseguir ler os dados do cartão magnético, tentar novamente por, no máximo, mais duas vezes. Caso persista o problema, encerrar o caso de uso. 20

Atores n Elemento externo que interage com o sistema. n n “externo”: atores não fazem parte do sistema. “interage”: um ator troca informações com o sistema. n Casos de uso representam uma seqüência de interações entre o sistema e o ator. n no sentido de troca de informações entre eles. n Normalmente um agente externo inicia a seqüência de interações como o sistema, ou um evento acontece para que o sistema responda. 21

Atores n Categorias de atores: n n pessoas (Empregado, Cliente, Gerente, Almoxarife, Vendedor, etc); organizações (Empresa Fornecedora, Agência de Impostos, Administradora de Cartões, etc); outros sistemas (Sistema de Cobrança, Sistema de Estoque de Produtos, etc). equipamentos (Leitora de Código de Barras, Sensor, etc. ) 22

Atores n Um ator corresponde a um papel representado em relação ao sistema. n O mesmo indivíduo pode ser o Cliente que compra mercadorias e o Vendedor que processa vendas. n Uma pessoa pode representar o papel de Funcionário de uma instituição bancária que realiza a manutenção de um caixa eletrônico, mas também pode ser o Cliente do banco que realiza o saque de uma quantia. 23

Atores n O nome dado a um ator deve lembrar o seu papel, ao invés de lembrar quem o representa. n Um ator pode participar de muitos casos de uso. n Um caso de uso pode envolver vários atores 24

Identificação dos elementos do modelo de casos de uso 25

Identificação dos elementos do modelo de casos de uso n Os atores e os casos de uso são identificados a partir de informações coletadas na fase de levantamento de requisitos do sistema. n Durante esta fase, os analistas devem identificar as atividades do negócio relevantes ao sistema a ser construído. n Não há uma regra geral que indique quantos casos de uso são necessários para descrever completamente um sistema. n A quantidade de casos de uso a ser utilizada depende completamente da complexidade do sistema. 26

Identificação de atores n Fontes e os destinos das informações a serem processadas são atores em potencial. n uma vez que um ator é todo elemento externo que interage com o sistema. n O analista deve identificar: n n as áreas da empresa que serão afetadas ou utilizarão o sistema. fontes de informações a serem processadas e os destinos das informações geradas pelo sistema. 27

Identificação de atores n Perguntas úteis: n n Que órgãos, empresas ou pessoas irão utilizar o sistema? Que outros sistemas irão se comunicar com o sistema a ser construído? Alguém deve ser informado de alguma ocorrência no sistema? Quem está interessado em um certo requisito funcional do sistema? n O desenvolvedor deve ainda continuar a pensar sobre atores quando passar para a identificação dos casos de uso. 28

Identificação de casos de uso n A partir da lista (inicial) de atores, deve-se passar à identificação dos casos de uso. n Nessa identificação, pode-se distinguir entre dois tipos de casos de uso n n Primário: representa os objetivos dos atores. Secundário: aquele que não traz benefício direto para os atores, mas que é necessário para que sistema funcione adequadamente. 29

Casos de uso primários n Perguntas úteis: n n Quais são as necessidades e objetivos de cada ator em relação ao sistema? Que informações o sistema deve produzir? O sistema deve realizar alguma ação que ocorre regularmente no tempo? Para cada requisito funcional, existe um (ou mais) caso(s) de uso para atendê-lo? n Outras técnicas de identificação: n n Caso de uso que precede a outro caso de uso. Caso de uso relacionado a uma condição interna. Caso de uso que sucede a outro caso de uso. Caso de uso temporal. 30

Casos de uso secundários n Estes se encaixam nas seguintes categorias: n n n Manutenção de cadastros. Manutenção de usuários. Manutenção de informações provenientes de outros sistemas. n Importante: Um sistema de software não existe para cadastrar informações, nem tampouco para gerenciar os seus usuários. n O objetivo principal é produzir algo de valor para o ambiente no qual ele está implantado. 31

Casos de Uso Trabalhando com um caso real Sistema de Contas a Pagar 32

Casos de Uso No levantamento de dados. . . Desejo um pequeno sistema que controle minhas contas a pagar. Deve emitir relatórios gerais ou por tipo de conta, para contas vencidas e a vencer. No futuro, gostaria de total integração desse sistema com um conjunto de outros sistemas que vou pedir, além de exportação e importação de arquivos para Palm. 33

Casos de Uso Pensando nos Casos de Uso. . . Quais são os atores ? Micro-Empresário Secretária 34

Casos de Uso Existe relacionamento entre os atores? herda de Micro-Empresário Secretária Veremos isto com mais calma nas próximas aulas 35

Casos de Uso Quais as responsabilidades de cada ator ? * Secretária: - Relatório de contas a vencer - Relatório de contas vencidas - Cadastrar tipo de conta 36

Casos de Uso Quais as responsabilidades de cada ator ? * Micro-empresário: todas as tarefas da Secretária + - Lançar conta a pagar - Registrar pagamento de conta - Emitir extrato de lançamentos por período 37

Casos de Uso n Descrição dos Casos de Uso . Cenário Principal fluxo perfeito, no qual nada ocorre de errado. Cenários Alternativos alternativas do fluxo ; exceções 38

Casos de Uso Caso de Uso Lançar Conta a Pagar. Cenário Principal Ator: Micro-empresário 1. O usuário informa um tipo de conta. 2. O sistema busca e exibe a descrição do tipo de conta. 3. O usuário informa: 3. 1. data de vencimento 3. 2. descrição da conta 3. 3. valor total a pagar 3. 4. valor parcial a pagar 39

Casos de Uso. Cenários Alternativos. . . 2. O sistema busca e exibe a descrição do tipo de conta. . . Tipo de Conta Inexistente Tipo de Relacionamento entre Casos de Uso 3 a. Se o tipo de conta não existir, carregar a consulta de tipos de contas. Extends (Consultar tipos de contas). 40

Exercício n Caso de uso n Escreva um caso de uso que mostre uma solicitação de reserva em um restaurante. 41

n Caso de Uso: n Ator: n Cenário principal n 1. . n Cenários Alternativos 42

Diagrama de casos de uso 43

Diagrama de casos de uso (DCU) n Representa graficamente os atores, casos de uso e relacionamentos entre os elementos. n Tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema. n Uma espécie de “diagrama de contexto”. n Apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam. n Todo diagrama de casos de uso tem pelo menos um ator 44

Relacionamentos n Casos de uso e atores não existem sozinhos. Pode haver relacionamentos entre eles. n A UML define diversos tipos de relacionamentos no modelo de casos de uso: n n Comunicação Associação n n n Inclusão Extensão Generalização n VEREMOS MAIS ADIANTE 45

Notação n A notação para um ator em um DCU é a figura de um boneco n com o nome do ator definido abaixo desta figura. n Cada caso de uso é representado por uma elipse. n O nome do caso de uso é posicionado abaixo ou dentro da elipse. n Um relacionamento de comunicação é representado por um segmento de reta ligando ator e caso de uso. n Pode-se também representar a fronteira do sistema em um diagrama de casos de uso. 46

Relacionamentos de Comunicação n É a relação de um ator com o caso de uso com o qual ele está interagindo. n É representada por uma linha sólida que conecta o símbolo de ator ao símbolo de caso de uso. 47

Exemplo (Notação) 48

Exemplo (Notação) n Ator: é alguém ou alguma coisa que interage com o sistema n Um ator é representado graficamente por um ícone de um “homenzinho” (stickman) 49

Exemplo (Notação) 50

Relacionamentos n Casos de uso e atores não existem sozinhos. Pode haver relacionamentos entre eles. n A UML define diversos tipos de relacionamentos no modelo de casos de uso: n n Comunicação Associação n n n Inclusão Extensão Generalização 51

Relacionamentos de Comunicação n É a relação de um ator com o caso de uso com o qual ele está interagindo. n É representada por uma linha sólida que conecta o símbolo de ator ao símbolo de caso de uso. 52

Relacionamento de Inclusão n É uma simples relação de inclusão, ou seja, os cenários ou situações possíveis detalhados em um caso de uso estão incluídos em outro caso de uso. n Quando dois ou mais casos de uso têm comportamento comum - uma seqüência comum de interações - esse comportamento pode ser modelado ou descrito em um caso de uso separado, que é utilizado por outros casos. 53

Relacionamento de Inclusão n Na elaboração de um sistema é comum que a mesma funcionalidade do sistema seja acessada por vários casos de uso. n Por exemplo, a funcionalidade de “Validar Cliente” pode ser acessada quando: n n n um novo cliente estiver sendo cadastrado; um novo pedido estiver sendo feito; ou uma consulta dos pedidos de um cliente for solicitada, etc. 54

Relacionamento de Inclusão n Esta relação serve para evitar a repetição deste caso de uso nos outros casos de uso, onde é necessário também “Validar Cliente”. n Podemos ler da seguinte maneira: o caso de uso “Consultar pedidos de um cliente” usa o caso de uso “Validar Cliente”. n Além disso, o roteiro de um caso de uso pode ser alterado por outro caso de uso. 55

Relacionamento de Inclusão n Este conceito não é novo, podendo ser comparado ao conceito de sub-rotina ou subprograma e estas são algumas características das relações de uso: n n n Aparecem como funcionalidade comum ao invés de especificar vários casos de uso; Os casos <<include>> usados são casos de uso por si só, isto é, existem primariamente como um caso de uso; O caso de uso <<include>> é usado sempre que o caso de uso principal é executado. Isto faz a diferença com as extensões, que são opcionais. 56

Criar Pedido <<inclui>> Validar Pedido Cliente <<inclui>> Alterar Pedido 57

Relacionamento de extensão n Utilizado para modelar situações onde diferentes seqüências de interações podem ser inseridas em um caso de uso. n Sejam A e B dois casos de uso. n n n Um relacionamento de extensão de A para B indica que um ou mais dos cenários de B podem incluir o comportamento especificado por A. Neste caso, diz-se que B estende A. O caso de uso A é chamado de estendido e o caso de uso B de extensor. 58

Relacionamento de extensão n Cada uma das diferentes seqüências representa um comportamento opcional, que só ocorre sob certas condições ou cuja realização depende da escolha do ator. n Quando um ator opta por executar a seqüência de interações definida no extensor, este é executado. n Após a sua execução, o fluxo de interações volta ao caso de uso estendido, recomeçando logo após o ponto em que o extensor foi inserido. n Importante: não necessariamente o comportamento definido pelo caso de uso extensor é realizado. 59

Relacionamento de extensão n Exemplo: considere um processador de textos. Considere que um dos casos de uso deste sistema seja Editar Documento. n No cenário principal deste caso de uso, o ator abre o documento, modifica-o, salva as modificações e fecha o documento. n Mas, em outro cenário, o ator pode desejar que o sistema faça uma verificação ortográfica no documento. n Em outro, o ele pode querer realizar a substituição de um fragmento de texto por outro. 60

62

Relacionamentos entre casos de uso «extends» «include» 63

Relacionamento de generalização n Relacionamento no qual o reuso é mais evidente. n Este relacionamento permite que um caso de uso (ou um ator) herde características de um caso de uso (ator) mais genérico. n O caso de uso (ator) herdeiro pode especializar o comportamento do caso de uso (ator) base. n Resumo: Pode existir entre dois casos de uso ou entre dois atores. 64

Relacionamento de generalização n Vantagem: comportamento do caso de uso original é reutilizado pelos casos de uso herdeiros. n Somente o comportamento que não faz sentido ou é diferente para um herdeiro precisa ser redefinido. 65

Relacionamento de generalização n A generalização entre atores significa que o herdeiro possui o mesmo comportamento que o ator do qual ele herda. n Além disso, o ator herdeiro pode participar em casos de uso em que o ator do qual ele herda não participa. n Um exemplo: considere uma biblioteca na qual pode haver alunos e professores como usuários. n n Ambos podem realizar empréstimos de títulos de livros e reservas de exemplares. No entanto, somente o professor pode requisitar a compra de títulos de livros à biblioteca. 66

Relacionamento de generalização Resumo n Relacionamentos: n Generalização entre casos de uso: significa que um caso de uso filho herda o comportamento e o significado do caso de uso pai n O caso de uso filho deverá acrescentar ou sobrescrever o comportamento do caso de uso pai • A generalização é representada graficamente por uma linha sólida com um triângulo numa das extremidades • O triângulo aponta para o caso de uso pai 67

Notação n Os relacionamentos de inclusão, extensão e herança são representados por uma seta direcionada de um caso de uso para outro. n A seta (tracejada) de um relacionamento de inclusão recebe o estereótipo <<inclui>>. n A seta (tracejada) de um relacionamento de inclusão recebe o estereótipo <<estende>>. n A seta (sólida) de um relacionamento de herança não recebe estereótipo. 68

Notação 69

Notação 70

Generalização - Atores Notação 71

Generalização - Atores Notação n Atores podem ter relacionamentos de generalização entre eles (uma vez representam classes) que 72

Notação 73

n Desenvolva um diagrama de casos de uso para o problema a seguir: n Quando um cliente compra um eletrodoméstico ele se dirige ao caixa da loja para efetuar o pagamento do que foi comprado. O cliente pode pagar à vista, no crediário da loja ou com cartão de crédito. Para qualquer forma de pagamento a loja realiza uma consulta no SPC para depois emitir a NF de venda. 74

Cenários n Um caso de uso tem diversas maneiras de ser realizado. n Um cenário é a descrição de uma das maneiras pelas quais um caso de um pode ser realizado. n Um cenário também é chamado de instância de um caso de uso. n Normalmente há diversos cenários para um mesmo um caso de uso. 75

Cenário Principal n Descreve um seqüência de ações que serão executadas considerando que nada de errado ocorrerá durante a a execução da seqüência. n É o cenário perfeito 76

Cenário Principal Trecho do caso de uso “Emitir Saldo em um terminal de caixa eletrônico” Ator: Correntista n 1. O sistema faz a leitura do cartão magnético. n 2. O sistema solicita a digitação da senha. O correntista informa sua senha. n 3. O sistema valida a senha, verificando se é a mesma senha que está associada ao correntista. n 4. O correntista seleciona a opção de saldo n 5. O sistema questiona o tipo de saldo: conta corrente, poupança, investimentos n 6. O sistema processa e mostra o saldo solicitado pelo cliente netc 77

Cenários Alternativos n Permite uma seqüência diferente de eventos em relação ao cenário principal n Para cada um destes cenários atípicos será definido o fluxo de eventos correspondente. n São os casos onde podem ocorrer exceções, erros ou qualquer outra ação possível e diferente. 78

Tratamento de Exceções no Caso de Uso n Depois de descrever o fluxo principal do caso de uso, deve-se imaginar o que poderia dar errado em cada um dos passos descritos n Uma exceção é um evento que se não for devidamente tratado impede o prosseguimento do caso de uso n A exceção em um processo não é necessariamente algo que impede que o processo seja iniciado, mas normalmente algo que impede que ele seja concluído 79

Cenários Alternativos n 1. O sistema faz a leitura do cartão magnético n Alternativa: Problemas na leitura do cartão magnético n 1 a) Se o sistema não conseguir ler os dados do cartão magnético, tentar novamente por, no máximo, mais duas vezes. Caso persista o problema, encerrar o caso de uso. 80

Partes de um tratamento de exceção (sugestão) n Identificador – número da linha no FP e código da exceção n Descrição da exceção – uma frase n Ações corretivas – um fluxo alternativo n Finalização – se e como retorna-se ao FP 81

Formas de Finalizar um Fluxo Alternativo n Voltar ao início do passo que causou a exceção n Ir para algum passo posterior n Voltar ao início do caso de uso n Abortar o caso de uso 82

Forma a ser evitada no Fluxo Principal n Se o cliente possui cadastro então o funcionário registra. . . 83

Níveis de Detalhamento n Alto Nível n Expandido 84

Exemplo de Caso de Uso de Alto Nível 85

Exemplo de Caso de Uso Expandido 86

Passos em um Fluxo n Obrigatórios n Complementares n Não Recomendados 87

Passos Obrigatórios n Indicam as entradas e saídas de informação do sistema necessárias para realizar o caso de uso. n Na falta de qualquer um desses passos o caso de uso pode ficar sem sentido. 88

Exemplo de caso de uso onde falta uma entrada de informação 89

Um diálogo impossível baseado no caso de uso anterior 90

n. O que faltou? 91

Uma solução mais adequada 92

Tipos de passos obrigatórios n Eventos de sistema – entradas. n Respostas de sistema – saídas. n Obs. Não são respostas de sistema retornos do tipo “ok”. Deve ser enviada ao mundo externo algum tipo de informação que o sistema armazena. 93

Identificação de passos obrigatórios em um Caso de Uso 94

Passos Complementares n Não possuem uma entrada ou saída do sistema, mas ajudam a compreender o contexto. n Estes passos têm pouca ou nenhuma influência na complexidade do software a ser desenvolvido. 95

Exemplos de passos complementares n “o cliente chega ao balcão com as fitas que deseja locar” n “o cliente vai embora com as fitas” n “o funcionário pergunta o nome do cliente” n “o sistema informa que a reserva foi concluída com sucesso” 96

Passos Não Recomendados n São os processos internos ao sistema. n O caso de uso deve descrever a interação entre o sistema e os atores externos, não o processamento interno. 97

Exemplos de passos que não deveriam constar em um caso de uso n “o sistema registra o nome do cliente no banco de dados” n “o sistema calcula a média das vendas” 98

Um exemplo de caso de uso com passos não recomendados 99

Consultas no caso de uso n Evite: n “o sistema verifica se o usuário está cadastrado” n Prefira: n n “o funcionário informa a identificação do cliente” “o sistema informa os dados do cadastro do cliente” 100