Casos de Uso

Casos de Uso – O que é Descrições narrativas de processos do domínio da aplicação Documentam a seqüência de eventos de um ator (um agente externo) usando o sistema para completar, do início ao fim, um determinado processo Representação em UML:

Objetivos de um Caso de Uso Ser compreensível para os usários leigos em informática Auxiliar a tarefa de análise, especificando funcionalidades e comportamento do sistema Delimitar o sistema Servir de base para derivar casos de teste

Atores Entidades externas ao sistema que de algum modo participam da estória do caso de uso Estimulam o sistema com eventos de entrada, ou recebem alguma coisa dele Designados pelo papel que exercem no caso de uso Ex.: Cliente, Operador, etc. Representação em UML:

Atores e Casos de Uso Um caso de uso possui um ator que o inicia, que gera o estímulo inicial, e possivelmente vários atores participantes O ator iniciador deve ser indicado explicitamente na descrição do caso de uso Algumas categorias típicas de atores incluem: papeis exercidos por pessoas sistemas de computação, outros softwares dispositivos elétricos e mecânicos hardware

Diagramas de Caso de Uso Ilustram um conjunto de casos de uso e atores para um sistema e os relacionamentos entre eles POST Buy Items Cashier Customer Log In Refund Purchased items

Relacionamentos no Diagrama de Casos de Uso Relacionamento entre atores Relacionamento entre atores e casos de uso Relacionamento entre casos de uso

Relacionamento entre atores Relacionamento de Associação Relacionamento de Generalização _________ Cliente Caixa Como os atores são entidades externas, os relacionamentos entre eles serão relações externas ao sistema. Embora estas relações possam ser desprezadas, pois não fazem parte do sistema e nem são de conhecimento do sistema, é possível incluí-las no modelo de casos de uso. De certa forma, estas relações descrevem parte do modelo de negócios da empresa. As duas relações mais comuns entre atores são a comunicação (ou associação) e a especialização (ou generalização). Um relacionamento de comunicação indica que os dois atores, de forma uni ou bidirecional, realizam uma comunicação (troca de informação ou de mensagem) que possui um significado formal para o sistema modelado. Trata-se de uma comunicacão explícita cuja ocorre ncia deve ter alguma repercussão ou significado para o sistema. Um relacionamento de generalização, por outro lado, representa uma relação conceitual entre atores indicando que um ator é um caso especial de outro ator mais gené rico. Esta relação indica que o ator especializado inclui todos os atributos do ator genérico e inclui ainda atributos adicionais. De certa forma, o ator especializado estende o ator genérico. _________ Funcionario Cliente

Herança entre atores Gerente Gerente de Compras Gerente de Vendas O Gerente de compras e gerente de vendas podem ser utilizados no lugar de gerente porque herdam as suas funções. Gerente de Compras Gerente de Vendas

Relacionamento entre atores e casos de uso _________ Cliente O Relacionento representa uma comunicação entre casos de uso e atores. Um caso de uso pode estar relacionado a mais de um ator caso a participação de diversos atores sejam necessárias Geralmente utilizam-se traços sem direção para representar a comunicação. Mas também costuma-se utilizar setas direcionadas. Do ator para o caso de uso, mostrando que o ator é quem inicia aquele caso de uso. ou 2) mostrando o sentido da comunicacao, nesse caso todas as retas teriam traços em uma ou ambas extremidades É importante escolher uma notacao e ser coerente com ela. _________ A seta pode indicar duas alternativas a escolher: ator que inicia o caso de uso ou simplesmente a direção dos dados

Relacionamento entre Casos de Uso <<uses>> ou << include>> <<extends>> ______ ________ RealizarPedido RealizarPedido Cliente Cliente <<extends>> <<uses>> Em alguns casos complexos, podemos utilizar casos de uso secundarios que simplificam o comportamento de casos de usos complexos, através dos relacionamentos de extensão e de inclusão (ou use). O caso de uso realizar pedido é estendio (ou seja é o caso básico). Se cliente não cadastrado Entao extends cadastrar cliente. O cadastrar cliente estende Realizar pedido. É o caso de uso extensão que não sabe da existência do caso de uso base. ValidarCliente CadastrarCliente

Relacionamento de Uso ou Include Utilizar quando se tem um bloco de comportamento que é o mesmo para vários casos de uso. Representar o fluxo comum como um outro caso de uso B a ser chamado pelo caso de uso A complexo: A <<uses>>B Validar Cliente pode ser um caso de uso utilizado por outro caso tal como Abrir Conta além de Realizar Pedido Não faz parte da UML chamar casos de uso como primários ou secundários... O relacionamento de include permite decompor um caso de uso complexo em sub-partes. O caso complexo inclui a parte. Na maioria das vezes, o caso de uso incluido não faz sentido sem o caso de uso complexo.

Relacionamento de Extensão Utilizar quando se tem dois casos de usos que fazem algo parecido, só que o caso de uso B faz alguma coisa a mais que A. B estende A B representa alguma situação não muito comum que ocorre em A mediante a satisfação de uma pré-condição Indica uma extensão possível de um caso de uso básico. No caso de uso básico, tem-se um ponto de extensão onde se usa o caso de uso de extensão. Em casos normais apenas o caso de uso básico será executado e em algumas vezes ele será estendido. Ao contrário da inclusão o caso de uso extensão não sabe da existência do caso de uso base. UMLJava.ps

Relacionamento de Generalização relação estrutural entre um caso de uso mais geral e um caso de uso mais específico. o caso de uso mais geral é uma generalização (abstração) do ou dos casos de uso mais específicos. O caso de uso geral, representa as partes comuns de casos de uso especializados. _______ Identificar Usuário A notação UML para a generalização envolve a ligação dos dois casos de uso através de um segmento de reta e a colocacão de um triângulo na extremidade do caso de uso mais geral. O Livro Applying Use cases diz que existe generalização somente entre atores. O UML User Guide diz que existe generalização entre casos de uso. O caso de uso mais específico pode ser usado ao invés do geral. Verificar Senha

Fluxo de Eventos, Cenários Um caso de uso descreve um fluxo de eventos para realizar uma operação Cenário: é uma das formas possíveis de se realizar um caso de uso Tipos de fluxos: Típicos: Principal ou Básico Atípicos: Alternativos, casos de erro, cancelamento, etc. Cada fluxo quando executado corresponderá a um cenário no caso de uso. Ou seja o cenário é uma instância de um caso de uso, podem ser primários ou principais ou secundários. Auxiliam a geração de dados de teste.

Pré e Pós Condições Condições que devem ser verdadeiras antes de o caso de uso ser executado, ou após a sua execução. Ex: retirar dinheiro em um caixa Pré-condição: cliente precisa ter conta no banco Pós-condição: o terminal fica pronto para outro cliente. Representa o estado do sistema antes e depois da execução e devem ser verdadeiras independentemente do cenário (fluxo) executado.

Interfaces entre Atores e Casos de Uso Identificam quais operações o ator (ou o caso de uso) realizam Auxiliam a especificar as interações e a reutilizar casos de uso A linha simples indica quem realiza a interface, no caso o ator E a linha tracejada quem usa a interface o caso de uso realizar pedido. ________ -------------- Cliente Interface Cliente Realizar Pedido

Tipos de Caso de Uso Com Respeito à Importância Primário Representam os processos principais ou mais comuns (ex.: Comprar Itens) Secundário Representam processos menos importantes ou mais raros (ex.: Cadastrar Operadores) Opcional Representam processos que podem ser ignorados ou incluídos em futuras versões do sistema (ex.: Solicitar Estoque para um Novo Produto) Essa classificação está no livro do Larman e não na UML

Tipos de Casos de Uso com Respeito à Descrição Textual Alto-nível Breve descrição de um processo, normalmente em duas ou três frases, e deliberadamente vago em decisões de projeto Criados na fase inicial de requisitos Expandido Descrição passo a passo dos fluxos de eventos de um processo Durante a fase de requisitos, apenas os casos de uso mais importantes são geralmente escritos nesse formato

Casos de Uso Alto Nível Exemplo de um caso de uso de alto-nível: A UML não especifica um formato rígido para os cabeçalhos e a estrutura de um caso de uso Podem ser alterados de acordo com as necessidades de documentação Caso de uso: Atores: Tipo: Descrição: Comprar Itens (Buy Items) Cliente (Customer), Operador (Cashier ) primário Um Cliente chega no caixa com itens para comprar. O Operador registra os itens e coleta o pagamento. Ao final, o Cliente sai com os itens. O nome do caso de uso pode ser qq sentença, mas recomenda-se que seu nome seja um verbo+substantido, exemplo comprar itens.

Típica Seqüência de Eventos Caso de Uso Expandido Exemplo de um caso de uso expandido: Caso de uso: Atores: Propósito: Descrição: Comprar Itens com Dinheiro (Buy Items with Cash) Cliente (Iniciador), Operador Capturar uma venda e seu pagamento em dinheiro. Um Cliente chega no caixa com itens para comprar. O Operador registra os itens e coleta um pagamento com dinheiro. Ao final, o Cliente sai com os itens. Tipo: Referencia: primário e essencial Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1 Típica Seqüência de Eventos Ação do Ator Resposta do Sistema 1. Este caso de uso começa quando um Cliente chega no caixa com itens para comprar.

Típica Seqüência de Eventos Caso de Uso Expandido Exemplo de um caso de uso expandido (cont.): Típica Seqüência de Eventos Ação do Ator Resposta do Sistema 2. O Operador registra o identi-ficador de cada item. Se há mais de um do mesmo item, o Operador também pode infor-mar a quantidade. 3. Determina o preço do item e adiciona informação sobre o item à transação de venda em anda-mento. Mostra a descrição e o preço do item corrente. 4. Após processar o último item, o Operador indica ao POST que a entrada de itens terminou. 5. Calcula e mostra o valor total da venda. Note que o caso de uso não descreve como as funcionalidades vao ser implementadas 6. O Operador informa o total ao Cliente. .

Típica Seqüência de Eventos Caso de Uso Expandido Exemplo de um caso de uso expandido (cont.): Típica Seqüência de Eventos Ação do Ator Resposta do Sistema 7. O Cliente entrega um paga-mento em dinheiro, possivelmente maior do que o valor total. 8. O Operador registra o valor recebido em dinheiro. 9. Mostra o troco devido. Emite um recibo. 10. O Operador deposita o dinheiro e retira o troco devido. O Operador entrega o troco e o recibo ao Cliente. 11. Registra a venda no log de vendas completadas. 12. O Cliente sai com os itens comprados. .

Tipos de Casos de Uso com Respeito à Implementação Essencial Descrição de um processo em termos de sua motivação e atividades essenciais Expressos relativamente livres de detalhes de implementação, decisões de projeto, e uso de tecnologias Real Descrição de um processo em termos de seu projeto real, comprometido com tecnologias de desenvolvimento, interfaces de entrada e saída, etc.

Caso de Uso Essencial Trecho do caso de uso Comprar Itens essencial Ação do Ator Resposta do Sistema 2. O Operador registra o identi-ficador de cada item. Se há mais de um do mesmo item, o Operador também pode infor-mar a quantidade. 3. Determina o preço do item e adiciona informação sobre o item à transação de venda em anda-mento. Mostra a descrição e o preço do item corrente. 4. ... 5. ...

Caso de Uso Real Trecho do caso de uso Comprar Itens real Ação do Ator Resposta do Sistema 2. Para cada item, o Operador digita o código universal de pro-duto (UPC) no campo de entrada UPC da Janela 1. Ele então pres-siona o botão “Entra Item” com o mouse ou pressiona a tecla <Enter>. 3. Determina o preço do item e adiciona informação sobre o item à transação de venda em anda-mento. Mostra a descrição e o preço do item corrente na Caixa de Texto 2 da Janela 1. 4. ... 5. ...

Casos de Uso com Fluxos Alternativos Caso de uso Comprar Itens Expandido Seção: Principal Ação do Ator Resposta do Sistema 1. ... 2. O Cliente escolhe o tipo de pagamento: a) Se pagamento com dinheiro, veja seção Pagamento com Dinheiro. b) ... Ação do Ator Seção: Pagamento com Dinheiro Resposta do Sistema 1. O Cliente entrega um paga-mento em dinheiro ...

Formato para um Caso de Uso Nome do caso de uso Descrição Atores Tipo Referências Pré-condições Fluxo de eventos Fluxo principal (típico) Fluxos alternativos Fluxos não típicos (erros, cancelamentos, etc) Pós-condições Pontos de extensão Casos de uso incluídos Outros requisitos (Interfaces)

Decomposição de Diagramas de Casos de Uso Pode-se dividir sistemas complexos em sub-sistemas e para cada um deles um diagrama de Casos de Uso Para mostrar o relacionamento entre esses sub-sistemas, os Casos de Uso são agrupados em Pacotes. Geralmente tem-se um diagrama de caso de uso único por sistema Um caso de uso ou ator em um sub-sistema ou pacote podem ter relacionamentos com elementos de outros pacotes, isso é demostrado por uma seta tracejada, mostrando dependências. Também podem ser definidas interfaces. Quando um caso de uso ou ator tiver que aparacer em mais de um pacote, eles devem ser copiados, indicando-se nos demais pacotes qual o pacote de origem daquele ator ou caso de uso.

Decomposição de Diagramas de Casos de Uso Adminitrativos Mercadológicos Geralmente tem-se um diagrama de caso de uso único por sistema Um caso de uso ou ator em um sub-sistema ou pacote podem ter relacionamentos com elementos de outros pacotes, isso é demostrado por uma seta tracejada, mostrando dependências. Também podem ser definidas interfaces. Quando um caso de uso ou ator tiver que aparacer em mais de um pacote, eles devem ser copiados, indicando-se nos demais pacotes qual o pacote de origem daquele ator ou caso de uso. Casos de uso Gerais

Identificando Casos de Uso Normalmente não são eventos ou passos individuais, mas um processo completo Erro mais comum! Método baseado em atores 1. Identificar os atores relacionados com o sistema ou organização 2. Para cada ator, identificar os processo que eles iniciam ou participam

Identificando Casos de Uso Método baseado em eventos 1. Identificar os eventos externos aos quais o sistema deve responder 2. Relacionar os eventos a atores e casos de uso Exemplos do sistema Posto Comercial Operador: Login, Retirar Dinheiro Cliente: Comprar Itens, Devolver Itens Digitar Senha? Imprimir Recibo?

Casos de Uso e Funções Todas as funções do sistema identificadas na especificação dos requisitos devem ser alocadas a casos de usos Alocação documentada através da seção Referencia

Casos de Uso e o Limite do Sistema Identificar os atores e casos de uso de um sistema requer a definição de seu limite de atuação Alguns limites típicos incluem: o software/hardware de um dispositivo ou sistema de computação um departamento de uma organização uma organização inteira Limites diferentes podem resultar em diferentes conjuntos de atores e casos de uso

Casos de Uso e o Limite do Sistema Exemplo de um diagrama de caso de uso para o sistema Posto Comercial, quando o limite de atuação é a loja inteira Store Buy Items Customer Refund Purchased items

Recomendações Crie nomes sempre começando com um verbo Identifique primeiro os fluxos principais, iniciando com: Este caso de uso começa quando <Ator> <inicia evento> Use a seção Seqüências não Típicas para representar desvios para seqüências de eventos incomuns ou excepcionais. Use subseções para representar desvios para seqüências alternativas com igual importância ou probabilidade de ocorrência

Recomendações Procure estimar a dimensão (granularidade) do caso de uso. Se ele estiver muito extenso procure identificar sub-casos Procure identificar partes comuns nos seus casos de uso, e usar <<include>>. Identifique serviços comuns aos casos de uso e crie casos de uso genéricos. A medida que se definem os casos de uso um refinamento no diagrama é possível

Referências Boock, G. and Rumbaugh, J. The Unified Modeling Language User Guide . Addison-Wesley, 1999 Arlow, J. and Neustadt, I. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design, 2nd Edition, The Addison-Wesley Object Technology Series, 2005. Rumbaugh, J.; Jacobson, I. and Booch , G. The Unified Modeling Language Reference Manual, 2nd Edition, The Addison-Wesley Object Technology Series, 2004. Boock, G.; Rumbaugh, J. and Jacobson, I; Unified Modeling Language User Guide, 2nd Edition, The Addison-Wesley Object Technology Series, 2005. Jacobson, I; Boock, G. and Rumbaugh, J., Unified Software Development Process, Addison-Wesley, Janeiro 1999. Larman, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design Prentice-Hall, New Jersey - USA, 1997 Bezerra, E. Princípios de Análise e Projeto com a UML, ed. Campus-Elsevier. 2003.