Download
1 / 41
420 likes | 633 Views
Casos de Uso. Maria Augusta Constante Puget (Magu). Origens. A idéia de usar casos de uso para descrever requisitos funcionais foi introduzida em 1986 por Ivar Jacobson , um dos principais contribuintes da UML e do PU.
E N D
Casos de Uso Maria Augusta Constante Puget (Magu)
Origens • A idéia de usar casos de uso para descrever requisitos funcionais foi introduzida em 1986 por Ivar Jacobson, um dos principais contribuintes da UML e do PU. • A idéia de Jacobson foi amplamente aceita, sendo suas virtudes principais: a simplicidade e a utilidade. • Embora muitos tenham feito contribuições para o assunto, possivelmente o passo mais influente na sua definição e sobre como escrevê-los deve-se a Alistair Cockburn, com o seu artigo Writing Effective Use Cases.
Casos de Uso e Requisitos • Casos de uso são requisitos. • Eles são os requisitos funcionais que indicam o que o sistema fará. • Definem uma promessa ou contrato de como o sistema se comportará. • Narrativas de casos de uso são documentos textuais, não diagramas, e a modelagem de casos de uso é basicamente um ato de redigir textos e não desenhar. • Entretanto, a UML define um Diagrama de Caso de Uso para ilustrar os nomes dos casos de uso e atores, assim como seus relacionamentos.
Diagramas de Casos de Uso • Fornecem uma visão de alto nível do sistema: Perspectiva externa e dos atores. • É o mais informal dos diagramas da UML. • Ajuda a capturar os requisitos funcionais do sistema. • É semanticamente limitado: Depende de interpretação. • A sua documentação é essencial. Outros diagramas da UML, como o de atividades e o de seqüência, mais formais e precisos, podem ser usados nessa documentação.
Diagrama de casos de uso: Atores • Representam um conjunto de papeis coerentes que os usuários de casos de uso desempenham quando interagem com ele. • Podem ser: • Humanos. • Dispositivos. • Sistemas. • Residem fora do sistema.
Atores: Representação (1) • Várias pessoas podem ser representadas por um único ator.
Atores: Representação (2) • Uma pessoa pode atuar como mais de um ator.
Atores: Representação (3) • Ator primário: Estimula o sistema a reagir. • Ator secundário: Responde às solicitações do sistema.
Atores: Nomeando (1) • 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. • Use nomes comuns para um sistema existente (do ponto de vista do usuário). Não invente um nome novo.
Relacionamentos de associação (1) • Os relacionamentos de associação entre Atores e classes de Casos de Uso são usados para indicar que o ator participa e se comunica com o sistema conforme descrito no Caso de Uso. • A seta indica quem inicia a comunicação. • Setas não demonstram fluxo.
Relacionamentos de associação (2) • Seta do Ator para o Caso de Uso: • Ator dispara o caso de uso; • Ator estimula o sistema; • Ator principal.
Relacionamentos de associação (3) • Seta do Caso de Uso para o Ator : • Sistema solicita informações; • Sistema espera uma ação do ator; • Ator secundário.
Fatoração de Casos de Uso • Existem 3 tipos de relacionamentos de fatoração: • Inclusão: Include; • Extensão: Extend; • Generalização. • Objetivos: • Reuso de pedaços do Caso de Uso; • Especialização de comportamento; • Descrição de procedimentos opcionais.
Fatoração de Casos de Uso: Inclusão (1) • Utilizado para: • Fatorar o comportamento do Caso de Uso base que não é necessário para o entendimento do propósito principal do Caso de Uso, mas cujo resultado apenas seja importante. • Fatorar um comportamento que seja comum a mais de um Caso de Uso. • Características: • A execução do Caso de Uso incluído é obrigatória; • O Caso de Uso base depende do resultado retornado pelo Caso de Uso incluído; • Nem o Caso de Uso base, nem o incluído, acessam os atributos um do outro; • A inclusão é, na essência, um encapsulamento.
Fatoração de Casos de Uso: Inclusão (3) • No sistema de Caixa Bancário, os casos de uso “Sacar”, “Depositar” e “Transferir” precisam incluir como o cliente será identificado no sistema. • Este comportamento pode ser fatorado em um Caso de Uso “Identificar Cliente” que os 3 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, etc. Só interessa 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.
Inclusão (include) - Descrição • Exemplo do “Sacar Dinheiro” incluindo o “Identificar Cliente”.
Fatoração de Casos de Uso: Extensão (1) • Utilizado para: • Mostrar no modelo que uma parte do Caso de Uso é um comportamento opcional do sistema. • Mostrar que um subfluxo é executado somente sob certas condições. • 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. • Características: • A execução do Caso de Uso de extensão é opcional; • 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 adicional pode acessar e alterar atributos do Caso de Uso base, mas o Caso de Uso base não conhece os atributos do Caso de Uso adicional.
Fatoração de Casos de Uso: Extensão (3) • No sistema Caixa Bancário, quando o cliente for identificado, o sistema precisa saber se ele já adquiriu seguro contra roubo do cartão e, caso negativo, oferecer a aquisição do seguro. • Pode-se evidenciar isso com a criação de um Caso de Uso chamado “Adquirir Seguro” que estende a funcionalidade de “Identificar Cliente”.
Fatoração de Casos de Uso: Generalização (1) • Utilizado para: • Destacar o comportamento comum a mais de um Caso de Uso, mas com algumas particularidades adicionais. • Demonstrar formas mais específicas de comportamento em um Caso de Uso. • Características: • Relacionamento “é-um” entre um caso de uso base (pai) com um ou mais casos de uso filhos. • Semelhante a generalização-herança de classes. • O filho herda toda a estrutura: Comportamento e relacionamentos do pai; • O filho é totalmente dependente da estrutura do pai.
Diagramas bem estruturados - Características • Um diagrama de Caso de Uso bem estruturado: • Tem como foco comunicar um aspecto da visão de Caso de Uso do sistema. • Contém somente os casos de uso e atores essenciais à compreensão desse aspecto. • Fornece detalhes consistentes com seu nível de abstração; deverão ser expostos os adornos essenciais à compreensão. • Não é tão minimalista, que informe mal o leitor sobre a semântica que é importante.
Diagramas bem estruturados - Sugestões • Ao definir um diagrama de caso de uso: • Dê-lhe um nome capaz de comunicar seu propósito. • Distribua os elementos de tal forma a minimizar o cruzamento de linhas. • Organize os elementos espacialmente, de maneira que os comportamentos e papéis semanticamente relacionados apareçam fisicamente próximos. • Use notas e cores como indicações visuais e para chamar atenção para características importantes do diagrama. • Tente não mostrar muitos tipos de relacionamentos. Em geral, se você tiver relacionamentos de inclusão e extensão complicados, coloque esses elementos em outro diagrama.
Casos de Uso: Seções (1) Descrição: Apresenta uma breve descrição do objetivo do caso de uso.
Casos de Uso: Seções (2) Pré-Condição: • É o estado do sistema requerido antes do caso de uso ser iniciado; • Pode ser omitido: Usar apenas quando relevante; • É uma restrição para o início do caso de uso, não o evento que inicia o caso de uso.
Casos de Uso: Seções (3) Pós-Condição: • É o estado no qual o sistema deve estar ao final do caso de uso. • Pode ser omitido: Usar apenas se agregar valor. • Quando usado com extends deve-se ter cuidado para que o caso de uso estendido não introduza um sub-fluxo que viole a pós-condição.
Casos de Uso: Seções (4) Cenário: • É o diálogo ator-sistema detalhando a execução do caso de uso. • Fluxo Básico: • Fluxo onde tudo dá certo: Caminho feliz. • Fluxos alternativos: • Variações na execução do fluxo básico. • Erros (exceções) que podem ocorrer no fluxo básico. Em alguns processos são chamados de fluxos de exceção.
O que os Casos de Uso não contém (1) • O caso de uso descreve a funcionalidade do sistema de uma perspectiva orientada à tarefa (passos). • O caso de uso não contém: • Detalhes da interface com o usuário. • Objetivos de performance. • Detalhes da arquitetura da aplicação. • Requisitos não funcionais.
O que os Casos de Uso não contém (2) • “... O ator clica no botão Ok...” • “... O sistema exibe um DBGrid com os...” • “... A resposta deverá ser retornada em menos de 10 s...” • “... O sistema inicia uma conexão com o servidor de aplicação...” • “... O usuário deverá entrar com os códigos através da caneta ótica...”
Como encontrar Casos de Uso (1) • 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 as funções que o usuário deseja. • Descreva as funções que criam, lêem, atualizam e excluem informações. • Descreva como os atores são notificados sobre alterações de estado do sistema. • Descreva como os atores informam ao sistema sobre eventos ocorridos.
Validação com Casos de Uso (1) • Validação do modelo: • 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?
Nomeando Casos de Uso (1) • Nomeie o caso de uso com uma frase que especifique o objetivo do ator. • Utilize verbos concretos, “fortes”, ao invés de verbos genéricos e fracos. • Seja explícito. Utilize termos específicos. Exemplos: • Termos fracos: Formulário, dado, sistema. • Termos fortes: Propriedade, pagamento, conta.
