Analisar Caso de Uso

1. Analisar Caso de Uso

2. Objetivos deste módulo • Apresentar os passos necessários para realizar a atividade analisar casos de uso e discutir seus artefatos • Apresentar os diagramas de seqüência, colaboração e classes de UML

3. Analisar Serviços Arquiteto de Software Projetar Serviços Projetar Arquitetura Revisor de projeto Prototipar Interface gráfica Arquiteto de Informação Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas/ componentes Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados

4. Analisar Serviços Arquiteto de Software Projetar Serviços Projetar Arquitetura Revisor de projeto Prototipar Interface gráfica Arquiteto de Informação Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas componentes Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados

5. Objetivos desta atividade • Encontrar as classes iniciais do sistema (classes de análise) e distribuir comportamento dos casos de uso entre elas • Para cada classe, descrever as responsabilidades, atributos e associações Esta atividade é realizada para cada caso de uso!

6. Visão geral dos artefatos Documento de Requisitos Diagrama de Classes Glossário Realização de Caso de Uso Documento da Arquitetura Modelo de Casos de Uso Diagrama de Colaboração Analisar Caso de Uso Analista de Sistemas Diagrama de Seqüência

7. Passos para Analisar Casos de Uso Para cada caso de uso: 1. Encontrar classes de análise 2. Identificar persistência Para cada classe: 3. Distribuir comportamento entre as classes 4. Descrever responsabilidades 5. Descrever atributos e associações 6. Revisar os Resultados

8. Passo 1. Encontrar classes de análise • O comportamento do caso de uso é distribuído em classes de análise dos seguintes tipos (estereótipos) • fronteira • controle • entidade • Estes estereótipos são uma conveniência de análise que desaparecem no projeto

9. Classes de análise: um primeiro passo em direção ao executável Classes de Análise Códigos Fonte Elementos de Projeto Executável Modelo de Casos de Uso

10. QIB - Diagrama de Casos de Uso • Usaremos o QIB como exemplo

11. Classes de Fronteira (boundary classes) <<boundary>> • Isolam o sistema de mudanças no ambiente externo • Atores devem se comunicar apenas com classes de fronteira • Exemplos de classes fronteira • GUI • Interface com outros sistemas • Interface com dispositivos Notação em UML Modelam a interação entre o sistema e seu ambiente

12. QIB – Efetuar Login • Regra geral para encontrar classes de fronteira: uma classe por cada par ator/caso de uso Efetuar Login ClienteAtor

13. QIB – Efetuar Pagamento do Qualiti Card • Descobrindo classes de fronteira Efetuar Pagamento do Qualiti Card ClienteAtor Operadora de Cartão de Crédito

14. Descrevendo Classes de Fronteira • GUI • Concentre-se nas informações que serão apresentadas, não em um projeto gráfico • Interface com outros sistemas ou dispositivos • Concentre-se em quais protocolos devem ser definidos, não como serão implementados • Concentre-se nas responsabilidades,não nos detalhes!

15. Classes de Entidade (entity classes) <<entity>> • Abstrações e conceitos chaves dos casos de uso • Fontes: • Conhecimento do negócio • Glossário • Modelo de negócios • Documento de requisitos • Especificação do Caso de uso Notação em UML Armazenam e controlam informação no sistema

16. QIB – Efetuar Login • Observe o fluxo de eventos do Efetuar Login Este caso de uso é responsável por autenticar um usuário do sistema. Pré-condição: nenhuma Pós-condição: um usuário válido é logado e sua sessão é registrada no sistema. Fluxo de eventos principal 1. O cliente informa login e senha. 2. O sistema verifica se o login e a senha são válidos(verifica-se se o login e senha pertencem a uma conta). 3. O sistema registra o início de uma sessão de uso. Fluxos secundários - No passo 2, se o login ou a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.

17. Orientações para encontrarClasses de Entidade • Usando a descrição do caso de uso, use a abordagem tradicional de filtrar substantivos • identifique substantivos no fluxo de eventos • remova candidatos redundantes e vagos • remova atores que apenas interagem com o sistema mas não fazem parte da modelagem • remova atributos (serão usados mais tarde) e operações

18. QIB – Efetuar Login • Classes de entidade • A classe Conta é uma classe que armazena o login e senha de um cliente. • Algumas classes levantadas podem ser eliminadas e novas serão adicionadas

19. QIB – Efetuar Pagamento do Qualiti Card • Descrição inicial Este caso de uso é responsável por realizar o pagamento do Qualiti Card com a operadora de cartão de crédito. Cada cliente possui apenas um cartão como titular, estando vinculado a apenas uma operadora. Pré-condição: O cliente deve estar conectado ao sistema (ter efetuado o login). Pós-condição: O valor do pagamento é debitado da conta do cliente, o pagamento é enviado à operadora do cartão de crédito e a transação é registrada no sistema.

20. QIB – Efetuar Pagamento do Qualiti Card • Fluxo de eventos principal 1. O cliente informa os dados necessários para efetuar o pagamento do cartão: - O código de barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar. 2. O sistema recupera a conta bancária do cliente logado. 3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar o pagamento. 4. O sistema debita da conta do cliente. 5. O sistema envia o pagamento à operadora de cartão de crédito. 6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento.

21. QIB – Efetuar Pagamento do Qualiti Card • Fluxo de eventos secundários • Fluxo Principal • O cliente informa os dados necessários para efetuar o pagamento do cartão:- O código de barras da fatura que deseja efetuar o pagamento.- O valor que deseja pagar. • O sistema recupera a conta bancária do cliente logado • 3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar o pagamento. • 4. O sistema debita da conta do cliente. • 5. O sistema envia o pagamento à operadora de cartão de crédito. • 6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento. Fluxo secundário - No passo 3, se o saldo disponível na conta do cliente for menor que o valor do pagamento, o sistema informa que o saldo é insuficiente e retorna para o passo 1. - No passo 5, se a operadora de cartão de crédito estiver inativa, o sistema exibe uma mensagem e cancela a operação. - Em qualquer momento o usuário pode cancelar a operação.

22. QIB – Efetuar Pagamento do Qualiti Card • Classes de entidade

23. Classes de Controle (control classes) • Coordenam o comportamento (lógica de controle) do caso de uso • Interface entre fronteira e entidade • Dependente do caso de uso, independente do ambiente • Permitem separação entre o uso da entidade (específico do sistema) do comportamento inerente à entidade Notação em UML Coordena o comportamento do caso de uso. Uma classe controle pode ter referência a vários objetos entidade. <<control>>

24. Orientações para encontrar Classes de Controle • Usualmente, uma classe de controle por caso de uso • Eventualmente mais de uma (comportamento complexo) ou nenhuma (manipulação simples de informações armazenadas)

25. QIB – Efetuar Login • Encontrando classes de controle Efetuar Login ClienteAtor

26. QIB – Efetuar Pagamento do Qualiti Card • Encontrando classes de controle Efetuar Pagamento do Qualiti Card ClienteAtor Operadora de Cartão de Crédito

27. QIB – Efetuar Login • Classes de análise descobertas até o momento

28. QIB – Efetuar Pagamento do Qualiti Card • Classes de análise descobertas até o momento

29. Exercício – Qualiti Internet Banking • Dado: • Artefatos de requisitos do Qualiti Internet Banking, especialmente o fluxo de eventos do caso de uso RealizarDoc (ver próximos slides) • Produzir: • Identificação das classes de análise, com seus estereótipos e breve descrição

30. QIB – Realizar Doc • Descrição inicial Este caso de uso é responsável por realizar a transferência de valores entre uma conta deste banco para uma conta de um outro banco. A transferência pode ocorrer entre contas com mesmo CPF ou CPFs distintos. Pré-condição: o cliente deve estar conectado ao sistema (ter efetuado o login). Pós-condição: o valor da transferência foi debitado da conta do cliente, o DOC foi enviado à operadora de DOC e a transação foi registrada.

31. QIB – Realizar Doc • Fluxo de eventos principal 1. O cliente informa os dados necessários para a realização do DOC: - Banco, agência e conta destino; - CPF do favorecido; - Valor do DOC. 2. O sistema recupera a conta bancária do cliente logado. 3. O sistema verifica se o saldo da conta do cliente é suficiente para a realização do DOC. 4. O sistema envia o DOC à operadora. 5. Debita-se o valor da conta. 6. O QIB registra a ocorrência desta transação (um DOC). 7. Emite-se um comprovante da mesma para o usuário, contendo os dados da conta de origem e destino, assim como a data e valor do DOC.

32. QIB – Realizar Doc • Fluxo de eventos secundários Fluxo Principal 1.O cliente informa os dados necessários para a realização do DOC: - Banco, agência e conta destino; - CPF do favorecido; - Valor do DOC. 2. O sistema recupera a conta bancária do cliente logado. 3. O sistema verifica se o saldo da conta do cliente é suficiente para a realização do DOC. 4. O sistema envia o DOC à operadora. 5. Debita-se o valor da conta. 6. O QIB registra a ocorrência desta transação (um DOC). 7. Emite-se um comprovante da mesma para o usuário, contendo os dados da conta de origem e destino, assim como a data e valor do DOC. • Fluxo secundário • No passo 3, se o saldo disponível na conta do usuário for menor que o valor do DOC, o sistema informa que o saldo é insuficiente e retorna ao passo 1 do fluxo principal de eventos. • No passo 4, se a operadora de DOC estiver inativa ou se ocorrer algum erro de comunicação que impeça a efetivação da transação, o sistema emite uma mensagem para o cliente e aborta a transação. • Em qualquer momento o usuário pode cancelar a operação.

33. Passo 2. Identificar persistência • Identificar que classes de análisedeverão ser persistentes • Criar, para cada classe persistente, uma classe de cadastro com estereótipo <<entity collection>>

34. QIB – Efetuar Login • Classes persistentes

35. QIB – Efetuar Pagamento do Qualiti Card • Classes persistentes

36. Exercício – Qualiti Internet Banking • Dado • Artefatos de requisitos do caso de uso realizar doc • Classes de entidade • Produzir • Identificação das classes que deverão ser persistentes

37. Contexto • Encontradas as classes de análise e identificadas as classes persistentes, vamos agora descrever o seu comportamento. • Lembrando que estas atividades são realizadas para cada caso de uso

38. Passo 3. Distribuir comportamento entre as classes • Para cada fluxo de eventos • alocar responsabilidades do caso de uso às classes de análise • modelar interações entre as classes através dos diagramas de interação

39. Distribuindo comportamento entre as classes Classes de Análise Caso de Uso Diagrama de Seqüência Classes de Análise (com responsabilidades) Diagrama de Colaboração

40. Alocando responsabilidades • Use estereótipos de análise como guia • Classes de fronteira • comportamento que envolve comunicação com um ator • Classes de entidade • comportamento que envolve informação encapsulada na abstração • Classes de controle • comportamento específico ao caso de uso (lógica de controle do caso de uso)

41. Alocando responsabilidades • Identificar que classe tem a informação necessária para realizar a responsabilidade • isso pode envolver apenas uma classe, pode ser preciso criar nova classe ou relacionamento entre classes

42. Modelando interações • Diagramas de interação (colaboração e seqüência) modelam interações do sistema com seus atores • A interação é iniciada por um ator e envolve instâncias (objetos) das classes • Diagramas de interação capturam a semântica do fluxo de eventos do caso de uso • Auxiliam a identificar classes, responsabilidades e relacionamentos

43. Forma Geral dos Diagramas de Seqüência Objeto fornecedor Objeto cliente :Cliente :Fornecedor Mensagem reflexiva 1: Realize responsabilidade 1.1: Realize outra responsabilidade Mensagem Numeração hierárquica para as mensagens Foco de controle

44. QIB – Efetuar Login

45. Forma Geral de Diagramas de Colaboração Objeto cliente Mensagem reflexiva Link 1.1: Realize outra responsabilidade :Cliente :Fornecedor 1: Realize responsabilidade Mensagem Objeto fornecedor

46. QIB - Efetuar Login

47. QIB – Efetuar Pagamento do Qualiti Card • Exercício: diagramas de seqüência e colaboração do caso de uso Efetuar Pagamento do Qualiti Card

48. Quantos diagramas de interação fazer? • Quantos forem necessários para modelar o comportamento do caso de uso! • Pelo menos o fluxo principal deveria ser modelado • Não é necessário modelar todos os fluxos • Os fluxos secundários geralmente não acrescentam muito à modelagem do principal • O importante é exemplificar o uso de todas as responsabilidades

49. Que diagramas de interação fazer? • Diagramas de colaboração x diagramas de seqüência • Colaboração • Melhores para visualizar os relacionamentos e responsabilidades de um dado objeto • Mais fáceis de desenhar - úteis em sessões de brainstorm • Seqüência • Melhores para visualizar a seqüência do fluxo no tempo • Melhores para visualizar o fluxo completo • Mais adequados para cenários complexos Use o que gostar mais!!

50. Contexto Para cada caso de uso encontramos as classes de análise identificamos classes persistentes descrevemos o seu comportamento através de diagramas de interação Agora, para cada classe vamos descrever suas responsabilidades