O conceito de casos de uso foi criado em 1986 por Ivar Jacobson, metodologista e um dos pais do Processo Unificado.

Transcrição

1 Modelagem de casos de uso Casos de uso O conceito de casos de uso foi criado em 1986 por Ivar Jacobson, metodologista e um dos pais do Processo Unificado. O que é Segundo Ivar Jacobson, um caso de uso é um "documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo". Um caso de uso é uma técnica de modelagem usada para descrever o que um novo sistema deve fazer. Como é construído Ele é construído através de um processo interativo no qual as discussões entre o cliente e os desenvolvedores do sistema conduzem a uma especificação do sistema da qual todos estão de acordo. O que faz Um caso de uso descreve as operações que o sistema deve cumprir para cada usuário. Ele vai ajudar a formalizar as funções que o sistema precisa fazer. Um caso de uso se apresenta como uma lista completa das interações entre um usuário e o sistema para cumprir uma tarefa. Lista completa significa que o caso de uso descreve as interações desde o início da tarefa, até o fim. Casos de uso têm que ser compreensíveis por usuários por que só eles sabem o que o sistema precisa fazer. Os casos de uso permitem verificar se o desenvolvedor e o usuário concordam sobre o que o sistema deve fazer. Isso é um problema importante no desenvolvimento de software. No mesmo tempo, casos de uso podem servir de "contratos'' entre os usuários e a equipe de desenvolvimento. Objetivos do caso de uso Decidir e descrever os requisitos funcionais do sistema. Fornecer uma descrição clara e consistente do que o sistema deve fazer. Permitir descobrir os requisitos funcionais das classes e operações do sistema. (Casos de uso NÃO são requisitos) Um modelo funcional Mostra como os valores são processados, sem preocupações com: ordenamento (seqüência) das ações; as decisões, ou; as estruturas dos objetos. Mostra a dependência de valores entre si e quais as funções que os relacionam. Etapas para Modelagem Funcional Identificar as requisições de entrada e saída

2 Para usuários; Envolvendo outros sistemas existentes. Construir diagramas mostrando as dependências funcionais; Descrever as funções (casos de uso); Identificar as restrições. O diagrama de casos É o principal diagrama para ser usado no diálogo com o usuário na descoberta e validação de requisitos; Os casos de uso constituem elementos que estruturam todas as etapas do processo de software. Ponte entre requisito e análise Aspectos tratados pelos casos de uso Funções Exemplo: Analogia com controle remoto Visão externa do sistema Fornece um conjunto de serviços complexos que são acessados através do controle remoto

3 Exemplo com o sistema de telefonia Tipos de Interação - Comunicação Representa quais atores estão ligados a quais casos de uso Tipos de Interação - Inclusão Um caso inclui (precisa de, é composto de) outro Representada através de um arco pontilhado com o rótulo <<inclui>> ou <<include>> Tipos de Interação - Extensão Um caso de uso pode opcionalmente utilizar um outro

4 Tipos de Interação Generalização/Especialização (sub-tipos de caso de uso) Herança Diagramas de casos de uso x DFD Os Diagramas de Caso de Uso e de Fluxo de Dados possuem similaridades DFD são mais complexos em virtude da maior quantidade de itens Entidades externas Depósitos de dados Fluxo de dados Os Casos de Uso não descrevem fluxo de dados DFD

5 DFD - Substituindo entidades externas DFD - Excluindo depósitos de dados

6 DFD - Substituindo processos DFD - Transformação final Cuidado ao modelar as fronteiras do sistema Um usuário pode desempenhar diferentes papéis

7 Cuidado ao modelar as fronteiras do sistema Quais as fronteiras do sistema? Recomendações Evitar um número muito elevado de casos de uso Fragmentar o sistema em sub-sistemas (ou em sub- pacotes) Usar casos de uso com denominação genéricas como Manter ou Gerenciar para descrever as funções de Cadastro de uma entidade Evitar detalhamento algorítmico Evitar o uso de <<include>> e <<extend>> nas primeiras iterações; Deve-se ter atenção para o fato que o diagrama tem semântica informal, isto é, não é preciso. Para um mesmo problema, múltiplas soluções válidas são admitidas Cenários Mostram como as pessoas interagiriam com o sistema. Adicionam detalhes a uma descrição de requisitos. Descricões de exemplos de sessões de interação. Cada cenário: uma ou mais interações. Diferentes cenários: diferentes tipos de informação sobre o sistema, em diferentes níveis de detalhe. Um cenário deve incluir uma descrição do estado do sistema no início do cenário. o fluxo normal de eventos no cenário. o que pode dar errado e como isso é tratado. outras atividades que podem ocorrer simultaneamente. o estado do sistema no fim do cenário.

8 Especificação de cenários Um caso de uso deve ser descrito textualmente Escrever casos de uso Identificar atores; Identificar objetivos (de alto nível); Objetivos se tornam casos de uso; Escrever cenários Identificar fluxo normal; Identificar fluxos alternativos; Identificar fluxos de erro; Como encontrar atores? Quem usa o sistema??quem instala/mantém o sistema??quem inicia/desliga o sistema??que outros sistemas usam o sistema? Quem recebe informação do sistema? Quem provê informação ao sistema? Como encontrar casos de uso? Atores são fundamentais para a descoberta dos casos de uso? Qual o objetivo de cada ator com o sistema? Pergunte: O sistema armazena informações? Que informações atores irão criar, ler, atualizar ou apagar? O sistema precisa notificar o ator sobre mudanças no seu estado interno? Existe algum evento externo que o sistema precisa saber? Que ator informa o sistema destes eventos? Casos de Uso devem ser Unidades testáveis e auto-contidas! Isso facilita: distribuição de tarefas entre os desenvolvedores; gerenciamento do cronograma; planejamento e realização de testes unitários; integração do sistema. Sem isso, não é viável um desenvolvimento iterativo e incremental!

9 O escopo de um caso de uso deve ser limitado. Fluxo de eventos Especifica o comportamento de um caso de uso É uma sequência de comandos declarativos que descreve as etapas de execução de um Caso de Uso Permanece focado no domínio do problema e não em sua solução Pode conter testes condicionais e iterações Contém informações relativas: Às condições de início e término do caso de uso Quais os atores interessados no sistema Como o caso de uso interage com esses atores Composição dos fluxos de eventos Fluxo básico Fluxo alternativo (um ou mais) Fluxo de exceção (um ou mais)