Professor Mário Dantas

1. Análise Orientada a Objetos Set/2010 Professor MárioDantas

2. Aula 04 - Agenda • Ator • Caso de uso • Associações • Entre atores e casos de uso • Entre casos de uso • Inclusão: estereótipo <<include>> • Extensão: estereótipo <<extend>> • Generalização • Diagrama de casos de uso • Especificação de casos de uso

3. Ator • É qualquer entidade que interage com o sistema • Pode ser um usuário, um hardware externo, outro sistema • Representa uma classe de usuários (papel), não um usuário específico • Algo sobre o que o sistema não tem controle

4. Ator • Várias pessoas podem ser representas por um único ator.

5. Ator • Um pessoa pode atuar como mais de um ator.

6. Como nomear um ator • Agrupe os indivíduos segundo a utilização do sistema • Identifique os papéis que eles assumem ao utilizar o sistema: cada papel é um ator em potencial • Cargo nem sempre é um papel • Escolha nomes conhecidos dos usuários: não invente!

7. Como nomear um ator

8. Caso de Uso “Um Caso de Uso é a relação de uma seqüência de ações que um sistema executa produzindo um resultado de valor observável para um ator específico.” RationalUnifiedProcess – RUP

9. Caso de Uso • Modela um diálogo entre ator e sistema • Define o comportamento de um sistema ou de parte dele • Descreve passo a passo como o sistema desempenha suas funções • Possui cenários (instâncias) • Define respostas que o sistema deve gerar para cada evento previsto • Deve possuir uma especificação

10. Caso de Uso

11. Descrição • Apresenta uma breve descrição do objetivo do caso de uso.

12. Pré-condição • É o estado do sistema requerido antes do caso de uso ser iniciado • Deve ser um estado de valor mensurável; • A pré-condição é uma restrição para o início do caso de uso e não o evento que inicia o caso de uso (um evento ter ocorrido pode ser uma pré-condição).

13. Pós-condição • Uma pós-condição é o estado no qual o sistema deve estar ao término da execução do caso de uso • Deve ser um estado de valor mensurável

14. Cenário • São os caminhos possíveis no diálogo ator-sistema durante a execução do caso de uso: instância de um caso de uso • Fluxo principal (ou básico) • Fluxo onde tudo “dá certo”; o mais freqüente • Fluxos alternativos • Variações na execução do fluxo básico • Fluxos de exceção • Erros que podem ocorrer nos fluxos básico e alternativo

15. Cenários

16. Fluxo principal • Exemplo: 1. O Cliente informa a opção de Saque. 2. O Sistema solicita o valor do saque. 3. O Cliente informa o valor e confirma a operação. 4. O Sistema verifica o valor informado. 5. O Sistema verifica o saldo do cliente. 6. O Sistema debita o valor sacado do saldo do cliente. 7. O Sistema entrega o dinheiro. 8. Fim do caso de uso.

17. Fluxo alternativo Exemplos: A1. Saldo insuficiente 1. No passo 5 do fluxo básico o Sistema verificou que o cliente não possui saldo. 2. O Sistema informa o saldo disponível. 3. O caso de uso volta para o passo 8 do fluxo básico. A2. Valor informado inválido 1. No passo 4 do fluxo básico o sistema verificou que o valor informado é inválido. 2. O sistema informa que o valor é inválido. 3. O sistema informa as regras para valores válidos. 4. O caso de uso volta para o passo 2 do fluxo básico.

18. Um caso de uso não contém • Detalhes da interface gráfica com usuário – GUI (útil apenas para protótipos) • Objetivos de performance (requisito não funcional) • Detalhes da arquitetura da aplicação: módulos, menus, componentes • Quaisquer requisitos não funcionais: eventualmente, podem ser inserido por meio de notas explicativas

19. Um caso de uso não contém • “... O ator clica no botão OK...” • “... O sistema exibe um JTable com os...” • “... A resposta deverá ser retornada em menos de 10 segs...” • “... O sistema inicia uma conexão com o servidor de aplicação...” • “... O usuário deverá informar os códigos por meio da caneta ótica ....”

20. Como encontrar casos de uso? • Identifique as interações do usuário: concentre-se nos objetivos do usuário: • “Sacar dinheiro...” • “Transferir dinheiro entre contas...” • “Cadastrar contas de débito automático...” • Descreva o quê o usuário espera do sistema • Descreva as operações que criam, lêem, atualizam e excluem informações (manter, CRUD, etc.); • Descreva como os atores são notificados sobre alterações de estado do sistema; • Descreva como o ator necessitará informar ao sistema eventos ocorridos.

21. Como encontrar casos de uso? • Crie listas de verificação e validação (V&V): • O sistema fornece o comportamento correto às necessidades do negócio? • Todas as necessidades são resolvidas pelos Casos de Uso que você identificou? • Quais Casos de Uso suportarão as principais funcionalidades do sistema? • Quais informações devem ser modificadas ou criadas no sistema? • Aplicar as Listas de V&V para os casos de uso encontrados

22. Como nomear casos de uso? • Use uma frase que especifique o objetivo do ator • Técnica “O ator usa o sistema para...” • Utilize verbos concretos, “fortes”, ao invés de verbos genéricos e fracos, exemplos: • Verbos fortes: criar, calcular, migrar, receber, arquivar, registrar e ativar • Verbos fracos: fazer, relatar, controlar, gerenciar, administrar, organizar e processar • Seja explícito • Use termos específicos: • Termos genéricos: formulário, dado e sistema • Termos específicos: propriedade, pagamento e conta

23. Como nomear casos de uso? • Boas escolhas • Depositar Dinheiro • Conferir Movimentação Bancária • Transferir Valores entre Contas Correntes • Escolhas ruins • Controle de Saque • Controle de Saldo • Transferência Bancária • Gerir Algo • Gestão Disso ou Daquilo

24. Exemplo • O cliente pode usar o caixa automático para sacar e transferir dinheiro e consultar o saldo • Ator: • Cliente • Casos de uso: • Sacar Dinheiro • Transferir Dinheiro • Consultar Saldo

25. Associações: Ator – Caso de Uso • Indicar que o ator participa e se comunica com o sistema, conforme descrito no caso de uso • A seta, quando houver, indica queminicia a comunicação, não demonstram fluxo e setas duplas não são usadas

26. Associações: Ator – Caso de Uso • Seta do ator para o caso de uso: • Ator dispara o caso de uso • Ator estimula o sistema • Ator principal

27. Associações: Ator – Caso de Uso • Seta do caso de uso para o ator: • Sistema solicita ou envia informações • Sistema sinaliza que espera uma ação do ator • Ator secundário

28. Associações: Ator – Caso de Uso

29. Associação entre Casos de Uso • Surgem da fatoração de casos de uso • Três tipos: • Inclusão <<include>> • Extensão <<extend>> • Generalização • Objetivos: • Reuso de parte do caso de uso • Especialização de comportamento • Descrição de procedimentos opcionais

30. Associação entre Casos de Uso

31. Inclusão – include • A execução do caso de uso incluído é obrigatória • O caso de uso base depende do caso de uso incluído • Nem o caso de uso base, nem o incluído, acessam os atributos um do outro (baixo acoplamento) • A inclusão é, na essência, um tipo de encapsulamento

32. Exemplo de Inclusão – include • No sistema de Caixa Bancário, os casos de uso “Sacar”, “Depositar” e “Transferir” precisam indicar que o cliente será identificado no sistema. Este comportamento pode ser fatorado em um caso de uso chamado “Identificar Cliente”, que os três casos de uso incluem. • Da perspectiva dos casos de uso base, não importa qual método é utilizado para a identificação, se senha, cartão, identificação de retina, mas apenas o resultado. • Da perspectiva do caso de uso incluído, não importa qual caso de uso o está utilizando (incluindo) ou como o resultado será processado.

33. Exemplo de Inclusão – include

34. Execução de caso de uso include • O comportamento incluído é inserido em uma localização específica do caso de uso base e é executado quando este passo é atingido.

35. Extensão - extend • Indica que uma parte do caso de uso é um comportamento opcional do sistema • Para mostrar que um comportamento é executado somente sob certas condições • Para mostrar que podem existir tipos de comportamento que serão inseridos no caso de uso dependendo da interação do ator com o caso de uso

36. Extensão - extend • O caso de uso de extensão é inserido no caso de uso base em locais específicos chamados “Pontos de extensão” • O caso de uso extensor depende do caso de uso estendido.

37. Exemplo Caso de Uso extend • No sistema de Caixa Bancário, quando o cliente for identificado, o sistema precisa saber se ele já adquiriu seguro contra roubo de cartão e, caso negativo, oferecer a aquisição do seguro. Podemos demonstrar isso com a criação de um caso de uso chamado “Adquirir Seguro” que estende a funcionalidade de “Identificar Cliente”.

38. Exemplo Caso de Uso extend

39. Execução de Caso de Uso extend • Quando a execução do caso de uso atinge o ponto de extensão, a condição do caso de uso é avaliada, e se for verdadeira o caso de uso é executado.

40. Fluxo alternativo ou extend? • Freqüentemente nos deparamos com a dúvida entre um fluxo alternativo e um caso de uso estendido. Considerar o seguinte: • O fluxo alternativo é complexo ao ponto de confundir o entendimento do caso de uso? • A condição para execução do fluxo é muito excepcional? • O valor semântico do modelo com extensão fica aprimorado?

41. Generalização • Destacar o comportamento comum a mais de um caso de uso, mas com algumas particularidades adicionais • Demonstrar formas mais específicas de comportamento do um caso de uso • Relacionamento do tipo é-umentre um caso de uso base (pai) com um ou mais casos de uso filhos

42. Generalização • Semelhante a herança entre classes • O filho herda toda a estrutura, comportamento e relacionamentos do pai; • O filho é totalmente dependente da estrutura do pai.

43. Exemplo de Generalização • No caso de uso “Cobrança de Pênalti”, podem ser representados: (1) a cobrança de pênalti em tempo regulamentar e (2) a cobrança de pênalti como desempate. • Esses dois casos de uso têm muito do seu comportamento em comum, mas com uma particularidade: a reposição da bola, que deve ser posta em jogo (1) ou não (2).

44. Exemplo de Generalização

45. Exemplo de Generalização

46. Exemplo de Generalização

47. Exemplo de Generalização • O caso de uso “pai” é executado quando, no fluxo do caso de uso “filho”, existe generalização • O caso de uso “filho” é executado quando, no fluxo do caso de uso “pai”, existe especialização

48. Diagrama de Casos de Uso • É criado para representar o conjunto de associações entre atores e casos de uso e entre casos de uso • São casos de uso associados que descrevem todas as formas de uso do sistema • Fornece uma visão das funcionalidades de um sistema: ajuda a capturar os requisitos funcionais • Constitui uma forma de comunicação bastante útil entre projetistas e clientes • Ajuda na identificação de objetos, na execução de testes e na documentação

49. Diagrama de Casos de Uso • Indica que tipo de usuário (ator, perfil) usa quais funcionalidades: oquê o sistema deve fazer e para quem • Deve ser completo: todas as funcionalidades devem estar presentes, mesmo que em diagramas separados que compõem o sistema • É uma visão de alto nível: perspectiva externa e dos atores • O mais informal dos diagramas da UML

50. Diagrama de Casos de Uso • Trata-se de uma representação dinâmica: é importante para a organização e modelagem de comportamentos do sistema • Não há decomposições funcionais (explosões) • Devem ter a complexidade controlada, podendo ser organizados de acordo com sua relevância, freqüência de utilização e valor para os usuários