Casos de uso Objetivo:

Transcrição

1 Casos de uso Objetivo: Auxiliar a comunicação entre os analistas e o cliente. Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.

2 Notação (representação): Atores Um ator é representado por um boneco e um rótulo com o nome do ator. Um ator é um usuário do sistema, que pode ser um usuário humano ou um outro sistema computacional.

3 Caso de uso Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso. Um caso de uso define uma grande função do sistema. A implicação é que uma função pode ser estruturada em outras funções e, portanto, um caso de uso pode ser estruturado.

4 Relacionamento (ajudam a descrever casos de uso). Entre um ator e um caso de uso. Associação Navegabilidade para Uma direção ator Caso de uso Navegabilidade para Ambos os lados Define uma funcionalidade do sistema do ponto de vista do usuário

5 Entre atores. Generalização Ator B - Os casos de uso de B são também casos de uso de A - A tem seus próprios casos de uso Ator A

6 Entre casos de uso. Inclusão <<include>> - instância outros casos de uso para suas condições Extensão <<extend>> - acrescenta outros casos de uso para suas condições Fornecer dados Do cliente <<include>> Incluir produto No pedido <<include>> Definir formas De pagamentos <<include>> Vendedor 1 * Colocar Pedido <<extend>> O vendedor pede o catálogo Consultar catálogos

7 Sistema. Limites do sistema: representado por um retângulo envolvendo os casos de uso que compõem o sistema. Nome do sistema: Localizado dentro do retângulo. Multiplicidade. Indica quantos objetos estão relacionados ao link. Ex. 1...*, 1...1, *...*, etc Ator. Primário e secundário

8 Exemplo

9 Cenários Deve-se especificar o comportamento de um caso de uso descrevendo textualmente um ou mais fluxos de ações, de modo que um usuário não técnico o possa entender sem dificuldade. Tal especificação deve incluir: Como e quando o caso de uso começa e termina; Quando é que o caso de uso interage com os atores; Que objetos são trocados; Cenário principal, e Cenários alternativos (e.g., situações de exceção).

10 Exemplo A operação de um caixa eletrônico tem início a partir de uma sessão em que o cliente seleciona a opção de realizar saque. O cliente então escolhe uma quantia a ser retirada, a partir de um conjunto de opções de quantia disponíveis. O sistema verifica se o caixa eletrônico tem saldo e notas adequadas para compor o valor solicitado (Ex. R$ 50,00 não podem ser fornecidos se só houver três notas de R$ 20,00). Caso tenha notas adequadas, os números da conta e da agência do cliente são enviados ao banco para determinar se existe saldo suficiente na conta do Cliente. Se não houver saldo, uma mensagem adequada é reportada. Havendo saldo, o sistema inicia uma transação com o ator banco e solicita a retirada da quantia desejada e o banco aprova ou desaprova a transação. Se a transação é aprovada, a máquina libera a quantia correspondente e emite um recibo. Se a transação é desaprovada, uma mensagem adequada é reportada. O banco é notificado, independentemente de uma transação aprovada ter sido completada ou não pela máquina. Se a transação é completada, o banco realiza o débito na conta do cliente.

11 Caso de Uso - Realizar Saque Objetivo: Este caso de uso possibilita a um cliente realize um saque de um caixa eletrônico Atores: Cliente, Banco Pré-Condições: Cliente autenticado Condição de Entrada: o ator Cliente seleciona a opção realizar saque Fluxo Principal 1. O sistema pergunta ao Cliente a quantia a ser retirada. 2. O Cliente digita a quantia desejada.[a1] 3. O sistema verifica se a importância requisitada é maior do que a quantia disponível. 4. O saldo é suficiente no caixa [A2] 5. O sistema verifica se a importância desejada pode ser fornecida com as notas existentes no caixa eletrônico.(r$ 50,00 não podem ser fornecidos se só houver três notas de R$ 20,00). 6. Valores disponíveis [A3] 7. O sistema contata o ator banco para determinar se existe saldo suficiente na conta do Cliente. 8. O banco informa que cliente tem saldo[a4] 9. O sistema inicia uma transação com o ator banco e solicita a retirada da quantia desejada. 10. O banco envia aprovação da transação.[a5] 11. O sistema libera a quantia desejada 12. O sistema emite um recibo para o Cliente 13. O sistema fecha a transação com o ator banco. 14. O sistema envia ao banco um log da transação. 15. O caso de uso se encerra.

12 Fluxos Alternativos A1 O cliente não digita a quantia desejada Após 20 seg encerra o caso de uso A2 O caixa automático não tem disponibilidade de dinheiro para atender a solicitação do ator cliente 1. O sistema reporta uma mensagem de falta de recursos no caixa 2. O caso de uso se encerra. A3 O caixa automático não tem disponibilidade notas para compor o valor solicitado pelo ator cliente 1. O sistema reporta uma mensagem de não temos notas de R$X,00 disponíveis para compor esse valor, tente outro valor 2. O caso de uso retorna para o passo 1 do fluxo principal A4. O Cliente não tem saldo suficiente 1. O sistema reporta uma mensagem seu saldo não é suficiente para esse saque 2. O caso de uso se encerra. A5 O banco não aprova a transação devido à violação de alguma regra de negócio (por exemplo: limite diário excedido) 1. O sistema reporta uma mensagem adequada 2. O caso de uso se encerra.

13 Diagrama de Classe Objetivo: Descrever os vários tipos de objetos no sistema e o relacionamento entre eles.

14 Perspectivas Um diagrama de classes pode oferecer três perspectivas, cada uma para um tipo de usuário diferente. São elas: (1) Conceitos ou Entidades Representa os conceitos do domínio em estudo. Perspectiva destinada ao cliente.

15 (2) Classes Tem foco nas principais interfaces da arquitetura, nos principais métodos, e não como eles irão ser implementados. Perspectiva destinada as pessoas que não precisam saber detalhes de desenvolvimento, tais como gerentes de projeto.

16 (3) Classes de Software Aborda vários detalhes de implementação, tais como navegabilidade, tipo dos atributos, etc. Perspectiva destinada ao time de desenvolvimento.

17 Um diagrama de classes contém: Entidades Relacionamentos

18 # Entidades Classe: é representada na forma de um retângulo, contendo duas linhas que separam 3 partes. A primeira contém no nome da classe, a segunda os atributos da classe e a última os métodos da mesma. Interface: Representação Gráfica

19 Perspectivas: Conceitual Apenas classes são utilizadas. Neste tipo de perspectiva, uma classe é interpretada como um conceito. Apenas atributos são utilizados. Especificação Tanto classes como interfaces são utilizados neste tipo de perspectiva. O foco consiste em mostrar as principais interfaces e classes juntamente com seus métodos. Não é necessário mostrar todos os métodos, pois o objetivo deste diagrama nesta perspectiva é prover uma maior entendimento da arquitetura do software a nível de interfaces. Implementação Nesta perspectiva, vários detalhes de implementação podem ser abordados, tais como: visibilidade de atributos e métodos; parâmetros de cada método, inclusive o tipo de cada um; tipos dos atributos e dos valores de retorno de cada método.

20 # Relacionamentos Papel: Descreve o relacionamento. Multiplicidade (utilizado em todas as perspectivas de forma uniforme) Notações possíveis Exemplo:

21 Associação (utilizado em todas as perspectivas) Representação Gráfica Associação Perspectiva: Conceitual Define um relacionamento entre duas entidades conceituais do sistema. Especificação Define responsabilidades entre duas classes. Implica que existem métodos que tratam desta responsabilidade. Implementação Permite saber quem está apontando para quem, através da representação gráfica da navegabilidade. Além disto, é possível compreender melhor de que lado está a responsabilidade.

22 Herança ou Generalização (utilizado em todas as perspectivas) Representação Gráfica Perspectiva: Seja B uma generalização (extensão) de A. Conceitual Considera que B é um subtipo ou um tipo especial de A. O que é válido para A, também é válido para B. Especificação Ocorre uma herança de interface. Implementação Ocorre uma herança de implementação. Exemplo de uma herança de implementação:

23 Navegabilidade (utilizado apenas na perspectiva de implementação) Um relacionamento sem navegabilidade implica que ele pode ser lido de duas formas, isto é, em suas duas direções. Ex.: Uma empresa possui um trabalhador, como também um trabalhador trabalha em uma empresa. Utilizando a propriedade de navegabilidade, podemos restringir a forma de ler um relacionamento. Isto é, em vez de termos duas direções, teremos apenas uma direção (de acordo com a direção da navegação). Ex.: Uma empresa possui um trabalhador.

24 Agregação (utilizado apenas na perspectiva de implementação) Definição Agregação é uma associação em que um objeto é parte de outro, de tal forma que a parte pode existir sem o todo. Em mais baixo nível, uma agregação consiste de um objeto contendo referências para outros objetos, de tal forma que o primeiro seja o todo, e que os objetos referenciados sejam as partes do todo. A diferença entre os relacionamentos de associação e agregação ainda é algo de bastante discussão entre os gurus. De forma geral, utiliza-se agregação para enfatizar detalhes de uma futura implementação (perspectiva de implementação). Representação gráfica Agregação com navegabilidade

25 Composição (utilizado apenas na perspectiva de implementação) Definição Em mais baixo nível, em termos de passagem por parâmetro, seria uma passagem por valor. Enquanto que agregação seria uma passagem por referência. O todo contém as partes (e não referências para as partes). Quando o todo desaparece, todas as partes também desaparecem. Representação Gráfica

26 Implementação (utilizado apenas na perspectiva de implementação) Definição Utilizado para indicar que uma classe implementa uma interface Representação Gráfica Exemplo

27 Exemplos

28 Diagrama de interação: sequência Diagramas de Interação são modelos que descrevem como grupo de objetos colaboram em um determinado comportamento. Um diagrama de interação captura o comportamento entre objetos dentro um único caso de uso.

29 Consiste em um diagrama que tem o objetivo de mostrar como as mensagens entre os objetos são trocadas no decorrer do tempo para a realização de uma operação. Em um diagrama de sequência, os seguintes elementos podem ser encontrados: Linhas verticais representando o tempo de vida de um objeto (lifeline); Estas linhas verticais são preenchidas por barras verticais que indicam exatamente quando um objeto passou a existir. Quando um objeto desaparece, existe um "X" na parte inferior da barra; Linhas horizontais ou diagonais representando mensagens trocadas entre objetos. Estas linhas são acompanhadas de um rótulo que contém o nome da mensagem e, opcionalmente, os parâmetros da mesma. Observe que também podem existir mensagens enviadas para o mesmo objeto, representando uma iteração; Uma condição é representada por uma mensagem cujo rótulo é envolvido por colchetes; Mensagens de retorno são representadas por linhas horizontais tracejadas. Este tipo de mensagem não é frequentemente representada nos diagramas, muitas vezes porque sua utilização leva a um grande número de setas no diagrama, atrapalhando o entendimento do mesmo. Este tipo de mensagem só deve ser mostrada quando for fundamental para a clareza do diagrama.

30 Exemplo: Partindo do diagrama de Casos de Uso

31 Exemplo: Partindo do diagrama de Casos de Uso

32 Exercício Elabore o Diagrama de Casos de Uso para uma biblioteca escolar.

33 Exercício Elabore o Diagrama de Casos de Uso para um sistema de reserva de salas.

34 Exercício Elabore o Diagrama de Casos de Uso para um sistema de entrega de pizzas.

35 Exercício Faça o diagrama de casos de uso para um sistema de Inscrição de um congresso, por exemplo o SICOMP (Simpósio Interinstitucional de Computação).

36 Exercício Construa um modelo de casos de uso para a seguinte situação fictícia: "Estamos criando um serviço de entregas. Nossos clientes podem nos requisitar a entrega de volumes. Alguns volumes são considerados de maior valor por nossos clientes, e, portanto, eles querem ter tais volumes segurados durante o transporte. Contratamos uma companhia de seguro para segurar volumes de valor"