A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Modelos de Casos de Uso. Levantamento de Requisitos Desenvolvedor: O que o Sr. Espera do sistema ? Usuário: Eu tenho uma loja de peças e gostaria que.

Apresentações semelhantes


Apresentação em tema: "Modelos de Casos de Uso. Levantamento de Requisitos Desenvolvedor: O que o Sr. Espera do sistema ? Usuário: Eu tenho uma loja de peças e gostaria que."— Transcrição da apresentação:

1 Modelos de Casos de Uso

2 Levantamento de Requisitos Desenvolvedor: O que o Sr. Espera do sistema ? Usuário: Eu tenho uma loja de peças e gostaria que meu PV fosse interligado ao meu estoque e eu pudesse a qualquer momento alterar valores dos meus produtos. Posso oferecer descontos a alguns tipos de clientes, mas preciso autorizar essa operação.

3 Levantamento de Requisitos Usuário: No fim do mês quero um relatório dos produtos que mais venderam. Preciso também saber a estatística das vendas por forma de pagamento. De tempos em tempos deve aparecer na tela do sistema uma promoção relâmpago que dê brinde ao cliente. Preciso que o sistema controle os pedidos também.

4 Levantamento de Requisitos Perguntas do analista: O que é PV ? Que tipos de clientes podem receber descontos ? Como seria feita autorização de desconto e por quem ? Que quantidade de produtos deve aparecer no relatório dos que mais venderam ? A estatística leva em conta que período ? Quanto tempo significa de tempos em tempos ? Que pedidos precisam ser controlados: os dos clientes ou os feitos aos fornecedores ?

5 Introdução O modelo de casos de uso é uma representação das funcionalidades externamente observáveis do sistema e dos agentes externos ao sistema que interagem com o mesmo. Mostra a interação do SW a ser desenvolvido com seu ambiente O modelo de casos de uso modela os requisitos funcionais do SW.

6 Introdução O diagrama da UML utilizado na modelagem de casos de uso é o diagrama de casos de uso. O diagrama de caso de uso oferece possíveis situações do mundo real para o teste do sistema. Um diagrama de casos de uso mostra as funcionalidades do SW sem se preocupar em expressar: A seqüência das ações, O fluxo de decisões ou As estruturas dos objetos

7 Introdução Um diagrama de casos de uso expressa as interações entre o SW e os agentes externos. Este é normalmente formado por vários casos de uso. Um diagrama de caso de uso representa quem faz o que com o sistema, sem considerar o comportamento interno do mesmo. Se diz para quem e o que implementar e não como

8 Introdução Com um diagrama de caso de uso, o SW é visto como um a caixa-preta sobre as funcionalidades desejáveis do SW. Exemplo: Correto: o sistema registra a venda Incorreto: o sistema grava a venda em um banco de dados (ou mesmo, gera uma instrução INSERT)

9 Introdução Em resumo: o diagrama de casos de uso força o desenvolvedor a moldar o SW de acordo com o usuário e não o contrário Sem casos de uso Com casos de uso

10 Introdução Um pouco de história... Técnica de modelagem idealizada por Jacobson, na década de Posteriormente incorporada ao seu método Objectory. Mais tarde, da união dos 3 amigos, esta foi adicionada à UML. Atualmente, devido sua notação amigável, é muito usada para realizar a documentação dos requisitos funcionais do SW. Facilita a comunicação entre os desenvolvedores e usuários

11 Elementos do Diagrama de Casos de Uso Elementos básicos em um diagrama de caso de uso: Casos de uso Atores Relacionamentos entre os elementos anteriores Sistema

12 Casos de uso – Visão Geral Um caso de uso é a especificação de uma seqüência de interações entre uma parte do SW e os agentes externos Diagramas de interação (seqüência ou colaboração) podem ser usados para especificar como um caso de uso será implementado.

13 Casos de uso – Visão Geral Define-se um caso de uso para cada tarefa/funcionalidade que o SW deve cumprir para os agentes externos, onde: Cada definição destas é feita sem se preocupar em revelar a estrutura e o comportamento internos de cada tarefa/funcionalidade

14 Casos de uso – Visão Geral Os casos de uso compõem uma ferramenta importante de comunicação entre clientes e desenvolvedores Os casos de uso podem também ser usados como base para criar casos de teste

15 Casos de Uso - Formato de Descrição Alguns Formatos de descrição são: Contínua Numerada Particionada

16 Casos de Uso - Formato de Descrição Formato de descrição contínua A narrativa é feita através de um texto livre Este caso de uso inicia quanto o Cliente chega ao caixa eletrônico e insere seu cartão. O Sistema requisita a senha do Cliente. Após o Cliente fornecer sua senha e esta ser validada, o Sistema exibe as opções de operações possíveis. O Cliente opta por realizar um saque. Então o Sistema requisita o total a ser sacado. O Cliente fornece o valor da quantidade que deseja sacar. O Sistema fornece a quantia desejada e imprime o recibo para o Cliente. O Cliente retira a quantia e o recibo, e o caso de uso termina.

17 Casos de Uso - Formato de Descrição Formato de descrição numerada A narrativa é feita através de uma série de passos numerados 1) Cliente insere seu cartão no caixa eletrônico. 2) Sistema apresenta solicitação de senha. 3) Cliente digita senha. 4) Sistema valida a senha e exibe menu de operações disponíveis. 5) Cliente indica que deseja realizar um saque. 6) Sistema requisita o valor da quantia a ser sacada. 7) Cliente fornece o valor da quantia que deseja sacar. 8) Sistema fornece a quantia desejada e imprime o recibo para o Cliente 9) Cliente retira a quantia e o recibo, e o caso de uso termina.

18 Casos de Uso - Formato de Descrição Formato de descrição particionada A narrativa é feita através da divisão da seqüência de interações entre o agente externo e o SW Tem o objetivo de separar as ações dos agentes e as reações do SW Nada impede que se numere as ações e reações

19 Exemplo: Caso de uso realiza saque ClienteSistema Insere seu cartão no caixa eletrônico. Digita senha. Solicita realiza ç ão de saque. Cliente indica o valor da quantia. Retira a quantia e o recibo. Apresenta solicita ç ão de senha. Valida senha e exibe opera ç ões dispon í veis. Requisita quantia a ser sacada. Fornece quantia e recibo.

20 Casos de Uso - Formato de Descrição Exercício: Descreva o caso de uso Realizar Transferência entre contas correntes nos três formatos de descrição

21 Casos de Uso - Formato de Descrição Descrição contínua : Este caso de uso inicia quanto o Cliente chega ao caixa eletrônico e insere seu cartão. O Sistema requisita a senha do Cliente. Após o Cliente fornecer sua senha e esta ser validada, o Sistema exibe as opções de operações possíveis. O Cliente opta por realizar uma transferência. Então o Sistema requisita o tipo de transferência (entre contas correntes ou entre conta corrente e poupança ou entre poupança e conta corrente). O cliente seleciona transferência entre duas contas correntes. O sistema, então, solicita a agência, conta do destino e o valor a ser transferido. O Cliente fornece os dados. O Sistema transfere a quantia desejada para a conta corrente destino e imprime o recibo para o Cliente. O Cliente retira o recibo, e o caso de uso termina.

22 Casos de Uso - Formato de Descrição Descrição Numerada: 1) Cliente insere seu cartão no caixa eletrônico. 2) Sistema apresenta solicitação de senha. 3) Cliente digita senha. 4) Sistema valida a senha e exibe menu de operações disponíveis. 5) Cliente indica que deseja realizar uma transferência. 6) O Sistema requisita o tipo de transferência (entre contas correntes ou entre conta corrente e poupança ou entre poupança e conta corrente). 7) O cliente seleciona transferência entre duas contas correntes. 8) O sistema, então, solicita a agência, conta do destino e o valor a ser transferido. 9) O Cliente fornece a agência, conta do destino e o valor a ser transferido. 10) O Sistema transfere a quantia desejada para a conta corrente destino e imprime o recibo para o Cliente. 11) O Cliente retira o recibo, e o caso de uso termina.

23 Casos de Uso - Formato de Descrição Atenção!! Independente do formato a ser utilizado, a descrição do caso de uso deve ser a mais clara possível! Casos de uso devem ser entendidos e validados pelos usuários!

24 Casos de Uso – Detalhamento da Descrição O nível de detalhamento a ser utilizado na descrição de um caso de uso também pode variar. Os níveis de detalhamentos de um caso de uso podem ser: Sucinto - descreve as interações sem muitos detalhes. Basicamente cita-se apenas os nomes da interações. Expandido - descreve as interações informando, por exemplo, importância, pré-condíções, pós-condições, fluxo principal, fluxo alternativo, fluxo de exceções,...

25 Casos de Uso - Descrevendo Cenários Cenários Geralmente um caso de uso tem diversas maneiras de ser realizado. Um cenário é a descrição de uma das maneiras pelas quais um caso de uso pode ser realizado. Um cenário também é chamado de instância de um caso de uso. Normalmente há diversos cenários para um mesmo um caso de uso.

26 Casos de Uso - Descrevendo Cenários Cenários: Cenário principal: descreve uma seqüência de ações que serão executadas considerando que nada de errado ocorrerá durante a execução da seqüência. Cenário Alternativo: descreve a possibilidade de problemas durante a realização normal de um caso de uso.

27 Casos de Uso - Descrevendo Cenários Abertura de uma conta em um determinado banco Cenário principal: 1) O Cliente solicita a abertura da conta; 2) O Gerente aprova a abertura; 3) O Gerente abre a conta; 4) O Cliente realiza o primeiro depósito; 5) O Cliente ganha o seu cartão magnético.

28 Casos de Uso - Descrevendo Cenários Abertura de uma conta em um determinado banco Cenários alternativos: No passo 2 do Cenário Básico, o Cliente é citado no SPC, inviabilizando a abertura de sua conta; No passo 3 o sistema informatizado do banco apresenta problemas, retardando a abertura da conta do Cliente; No passo 5 o banco está sem mídia do cartão, ou o cartão do Cliente ainda não está pronto, retardando a entrega do mesmo ao Cliente.

29 Casos de Uso - Descrevendo Cenários Exercício: Descreva 3 fluxos alternativos para o caso de uso Realizar Transferência entre contas correntes

30 Casos de Uso - Descrevendo Cenários No passo 1, o cliente verifica que o caixa eletrônico está em manutenção. No passo 1, o sistema indica que a data de validade do cartão expirou. No passo 4, a senha informada pelo cliente é invalida. No passo 9, a agência ou a conta indicada pelo cliente não existe. No passo 10, o sistema indica que o cliente não possui saldo suficiente para a transferência.

31 Casos de Uso – Representação Gráfica Nome do Caso de Uso

32 Atores – Visão Geral Atores são agentes externos que interagem com o sw. Externo - atores não fazem parte do SW. Interage - um ator troca informações com o SW. Em resumo: Os atores não são parte do SW, mas representam qualquer um ou qualquer coisa que interaja com o mesmo. Um parêntese: Casos de uso representam uma seqüência de interações (troca de informações) entre o SW e o ator.

33 Atores – Categorias Categorias de atores: Pessoas - Empregado, Cliente, Gerente, Almoxarife, Vendedor,... Organizações - Empresa Fornecedora, Agência de Impostos, Administradora de Cartões,... Outros Sistemas - Sistema de Cobrança, Sistema de Estoque de Produtos,... Equipamentos - Leitora de Código de Barras, Sensor,...

34 Atores - Papéis Um ator corresponde a um papel que um agente externo pode representar em relação ao sistema. Este não é o agente propriamente dito! O agente propriamente dito pode ser um Cliente que compra mercadorias e também um Vendedor que processa vendas. O nome dado a um ator deve lembrar o seu papel, ao invés de lembrar quem ou o que este representa! ex: João Fernandes versus Estudante

35 Atores - Papéis Tipicamente, os papéis dos atores são encontrados na declaração do problema. Questões que ajudam a identificar os papéis dos atores: Quem está interessado em determinada exigência? Onde, na organização, o sistema é usado? Quem se beneficiará do uso do sistema? Quem fornecerá, ao sistema essas informações?

36 Atores - Papéis Questões que ajudam a identificar os papéis dos atores: Quem suportará e manterá o sistema? O sistema usa um recurso externo? Uma pessoa representa diversos papéis? Várias pessoas representam o mesmo papel? O sistema interage com um sistema legado?

37 Atores - Primários e Secundários Um ator pode participar de muitos casos de uso. Um caso de uso pode envolver vários atores, o que resulta na classificação dos atores em: Primário - inicia uma seqüência de interações de um caso de uso. Secundário - supervisiona,opera,mantém ou auxilia na utilização do SW

38 Atores - Primários e Secundários Os casos de uso devem ser definidos tendo em mente os objetivos dos atores primários! Os atores secundários existem para permitir que os atores primários possam utilizar o SW Exemplo: Para que o Usuário (ator primário) requisite uma página a um Browser (sistema), um outro ator (secundário) está envolvido, o Servidor Web.

39 Atores – Representação Gráfica Nome do Ator > Nome do Ator

40 Relacionamentos – Visão Geral O ator comunica-se com o SW através do envio e recebimento de mensagens Casos de uso e atores não existem isoladamente. Deve haver relacionamentos entre estes, onde: Um ator deve estar associado a um ou mais casos de uso e Um caso de uso pode estar associado a um ou mais atores e/ou a outros casos de uso.

41 Relacionamentos – Visão Geral A UML define diversos de relacionamentos no modelo de casos de uso: Comunicação Inclusão Extensão Generalização

42 Relacionamentos - Comunicação Um ator comunica-se com casos de uso para mostrar cada participação, conectando-se o ator ao caso de uso O relacionamento de comunicação só existe entre atores e casos de uso Expressa quais atores estão associados a que casos de uso. Reflete que um ator interage (troca informações) com o SW O relacionamento de comunicação é o mais utilizado!

43 Comunicação – Representação Gráfica Realizar Saque Cliente

44 Relacionamentos - Inclusão Quando vários casos de uso têm algum comportamento em comum, esse comportamento pode ser descrito em um caso de uso, o qual será usado por outros casos Analogia útil rotina de programação Em uma linguagem de programação, instruções podem ser agrupadas em uma unidade lógica chamada rotina. Sempre que essas instruções devem ser executada, a rotina correspondente é chamada.

45 Relacionamentos - Inclusão Exemplo: Considere um sistema de controle de transações bancárias. Alguns casos de uso deste sistema são Obter Extrato, Realizar Saque e Realizar Transferência Note que todos os casos de uso anteriores, terão que compartilhar um comportamento: Validar o Cliente Então, todos devem incluir o caso de uso Validade Cliente

46 Inclusão – Representação Gráfica Obter Extrato Validar Cliente > Realizar Saque Realizar Transferência > Cliente

47 Relacionamentos - Inclusão Importante: A aplicação do caso de uso comum deverá: Evita a descrição da seqüência de interações mais de uma vez Torna a descrição dos casos de uso mais simples. O relacionamento de Inclusão só existe entre casos de uso.

48 Relacionamentos - Inclusão Em resumo: Relacionamentos de inclusão ocorrem quando há uma parcela de comportamento comum, sugerindo uma reutilização Um relacionamento de inclusão de um caso de uso X para um caso de uso Y expressa que X incluirá o comportamento especificado em Y

49 Relacionamentos - Extensão Utilizado para modelar situações onde diferentes seqüências de interações podem ser inseridas em um caso de uso. Cada uma das diferentes seqüências representa um comportamento opcional, que só ocorre sob certas condições ou cuja realização depende da escolha do ator.

50 Relacionamentos - Extensão Sejam A e B dois casos de uso. Um relacionamento de extensão de B para A indica que um ou mais dos cenários de A podem incluir o comportamento especificado por B. Neste caso, diz-se que B estende A. O caso de uso A é chamado de estendido e o caso de uso B de extensor.

51 Relacionamentos - Extensão Exemplo: Considerar um processador de textos. Considerar que um dos casos de uso deste sistema seja Editar Documento. No cenário típico deste caso de uso, o ator abre o documento, modifica-o, salva as modificações e fecha o documento. Mas, em outro cenário, o ator pode desejar que o sistema faça uma verificação ortográfica no documento. Em outro, o ele pode querer realizar a substituição de um fragmento de texto por outro.

52 Extensão – Representação Gráfica Editar Documento Corrigir Ortografia > Substituir Texto > Escritor

53 Relacionamento - Extensão Interações de Substituir Texto: 1.Em qualquer momento durante Editar Documento, o ator pode optar por substituir um fragmento de texto por outro. 2.O ator fornece o texto a ser substituído e o texto substituto. 3.O ator define os parâmetros de substituição (substituir somente palavras completas ou ocorrências dentro de palavras; substituir no documento todo ou somente na parte selecionada; ignorar ou considerar letras maiúsculas e minúsculas). 4.O sistema substitui todas as ocorrências encontradas no texto.

54 Relacionamentos - Extensão Importante: Um caso de uso estendido é uma descrição completa de uma seqüência de interações (não deve depender do extensor) Uma seqüência de interações definida no extensor só é processada quando o ator opta por executá-la. Ou seja, não necessariamente o comportamento definido pelo caso de uso extensor será realizado

55 Relacionamentos - Extensão Importante: Após a execução do caso de uso extensor, o fluxo de interações volta ao caso de uso estendido, recomeçando logo após o ponto em que o extensor foi inserido. O relacionamento de extensão só existe entre casos de uso.

56 Relacionamentos - Extensão Duas formas para efetuar o ponto de extensão 1) Definir a descrição textual da extensão no extensor Vantagem: o estendido não precisa ser modificado Desvantagem: não é apropriado para descrições numeradas, pois qualquer modificação na numeração do estendido afeta o extensor

57 Relacionamentos - Extensão 2) Definir na descrição textual da extensão do estendido Vantagem: modificações na numeração do estendido não afeta o extensor Desvantagem: a descrição textual do estendido exibe os pontos de extensão, o que diminuir a clareza/entendimento do mesmo A escolha é livre, mas se recomenda utilizar a primeira abordagem. Com a primeira abordagem, evita-se poluir a descrição do estendido com detalhes que, na maioria das vezes, não são necessários

58 Relacionamentos - Extensão Em resumo: Relacionamentos de extensão ocorrem quando há uma parcela de comportamento opcional/excepcional a ser executado Um relacionamento de extensão de um caso de uso X para um caso de uso Y expressa que X possui um comportamento que eventualmente pode ser requisitado por Y

59 Relacionamentos - Generalização Relacionamento no qual o reuso é mais evidente. Este relacionamento permite que um caso de uso (ou um ator) herde características de um caso de uso/ator mais genérico. O caso de uso/ator herdeiro pode especializar o comportamento do caso de uso/ator base. Pode existir entre dois casos de uso ou entre dois atores.

60 Relacionamento - Generalização Na generalização entre casos de uso, sejam X e Y dois casos de uso. Quando Y herda de X, as seqüências de comportamento de X valem também para Y. Quando for necessário, Y pode redefinir as seqüências de comportamento de X. Além disso, Y participa em qualquer relacionamento no qual X participa. Vantagem: comportamento do caso de uso original é reutilizado pelos casos de uso herdeiros.

61 Relacionamento - Generalização A generalização entre atores significa que o herdeiro possui o mesmo comportamento que o ator do qual ele herda. Além disso, o ator herdeiro pode participar em casos de uso em que o ator do qual ele herda não participa.

62 Relacionamento - Generalização Um exemplo: considere uma loja na qual existem clientes e clientes especiais. Ambos podem realizar compras de qualquer produto Entretanto, só os clientes especiais podem fazer pagamento a prazo.

63 Generalização – Representação Gráfica Pagamento a prazo Realizar Pagamento Cliente Cliente Especial Pagamento a vista

64 Generalização – Representação Gráfica

65 Lembre-se: No início do desenvolvimento, não pensem na implementação. Concentrem-se apenas nos desejos dos usuários! Sempre registrem as razões de todas as decisões, para reutilizá-las, quando necessário!

66 Sistema Pode-se também representar a fronteira do sistema em um diagrama de casos de uso. Usa-se esta divisão quando se deseja enfatizar o interior e o exterior do sistema Nesta divisão: Os atores ficam do lado de fora da fronteira e Os casos de uso ficam dentro da fronteira

67 Sistema – Representação Gráfica Sistema de Vendas XPTO Cliente Vendedor Empresa Transportadora Realizar Pedido

68 Identificação dos elementos – Visão Geral Os atores e os casos de uso são identificados a partir de informações coletadas na fase de levantamento de requisitos do sistema. Durante esta fase, os analistas devem identificar as atividades do negócio relevantes ao sistema a ser construído.

69 Identificação dos elementos – Visão Geral Não há uma regra geral que indique quantos casos de uso ou atores são necessários para descrever completamente um SW. A quantidade de casos de uso ou de atores a ser utilizada depende completamente da complexidade do sistema. A partir de agora, serão apresentadas algumas dicas sobre como identificar atores e casos de usos

70 Identificação de atores Para começar a construção do SW deve-se identificar seus atores. Para isso deve-se identificar as fontes e os destinos das informações a serem processadas. Uma vez que um ator é todo elemento externo que interage com o sistema.

71 Identificação de atores Tipos perguntas úteis para identificação de atores: Que órgãos, empresas ou pessoas irão utilizar o sistema? Que outros sistemas irão-se comunicar com o sistema a ser construído? Alguém deve ser informado de alguma ocorrência no sistema? Quem está interessado em um certo requisito funcional do sistema?

72 Identificação de atores Além desta identificação inicial, deve-se continuar a pensar sobre atores, quando passar para a identificação dos casos de uso. Novos atores podem aparecer na identificação dos casos de uso!

73 Identificação de casos de uso A partir da lista inicial de atores, deve-se passar à identificação dos casos de uso. Nessa identificação, pode-se distinguir entre dois tipos de casos de uso Primários: Representam os objetivos dos atores. Secundários: Não trazem benefício direto para os atores, mas são necessários para que sistema funcione adequadamente.

74 Casos de uso primários Representam os principais processos do negócio a serem automatizados Tipos de perguntas úteis para identificação de casos de uso primários: Quais são as necessidades e objetivos de cada ator em relação ao sistema? Que informações o sistema deve produzir? O SW deve realizar alguma ação que ocorre regularmente no tempo? Para cada requisito funcional, existe um (ou mais) caso(s) de uso para atendê-lo?

75 Casos de uso primários Outras técnicas de identificação: Caso de uso oposto Baseia-se em desfazer a realização de um outro caso de uso Pergunta-se: Como a realização do caso de uso X pode ser desfeita? Ex: Registrar Pedido Cancelar pedido

76 Casos de uso primários Caso de uso que precede a outro caso de uso Baseia-se em casos de usos que são antecedentes as outros Pergunta-se: O que pode ocorrer antes da realização do caso de uso X? Ex:Registrar Pedido Cadastrar Cliente Caso de uso que sucede a outro caso de uso. Baseia-se em casos de usos que são subsequentes as outros Pergunta-se: O que pode ocorrer após a realização do caso de uso X? Ex:Registrar Pedido Finalizar Venda

77 Casos de uso primários Outras técnicas de identificação (Cont): Caso de uso temporal Baseia-se em casos de usos que são realizados de tempos em tempos Pergunta-se: Há alguma tarefa que o SW deve realizar periodicamente? Ex: Gerar comissão vendedores (todos os sábados as 12:00) Obs: nestes casos, os atores podem ser os agentes que recebem os resultados ou um agente chamado tempo

78 Casos de uso primários Caso de uso relacionado a uma condição interna Baseia-se em casos de usos que são realizados por eventos internos Pergunta-se: Há alguma tarefa que o SW deve realizar automaticamente? Ex:Informar produtos que atingiram o estoque mínimo Obs: nestes casos, os atores também podem ser os agentes que recebem os resultados ou um agente chamado evento interno

79 Casos de uso secundários Estes se encaixam nas seguintes categorias: Manutenção de cadastros Realizam operações como: inclusão, exclusão, alteração ou consulta Atenção: Só um ator defini-se um único caso de uso para estas operações Mais de um ator casos de usos separados por operações/atores

80 Casos de uso secundários Manutenção de usuários. Realizam operações como: adição, permissão e perfis de usuários Manutenção de informações provenientes de outros sistemas. Realizam operações como sincronização de informações entre SW EX: SW de Venda X SW de Estoque Validar estoque

81 Importante: Priorizem a identificação dos casos de uso primários! Iniciar a especificação com casos de uso secundários é uma indicação de como o SW deve ser construído!

82 Construção do diagrama de casos de uso Notas gerais: Os diagramas de casos de usos objetivam facilitar a comunicação (discussão das funcionalidades) entre usuários e desenvolvedores Os diagramas de casos de uso devem servir para dar suporte à parte escrita do modelo, fornecendo uma visão de alto nível. Evite diagramas poluídos. Quanto mais fácil for a leitura do diagrama de casos de uso, melhor.

83 Construção do diagrama de casos de uso Notas gerais: Se o SW sendo modelado não for tão complexo, pode ser criado um único diagrama de casos de uso. Para SW complexos a abordagem anterior cria diagramas ilegíveis: Solução Criar diagramas segundo uma das seguintes abordagens: 1) Um caso de uso e seus relacionamentos; 2) Todos os casos de uso para um ator; 3) Todos os casos de uso a serem implementados em um ciclo de desenvolvimento.

84

85 Construção do diagrama de casos de uso Documentação dos atores Uma breve descrição para cada ator deve ser adicionada ao diagrama de casos de uso. O nome de um ator deve lembrar o papel desempenhado pelo mesmo no sistema.

86 Construção do diagrama de casos de uso Documentação dos casos de uso UML não define uma estruturação específica a ser utilizada na descrição do formato expandido de um caso de uso. A seguir, é apresentada uma sugestão de descrição.

87 Documentação dos casos de uso (possíveis itens) Construção do diagrama de casos de uso Nome Descrição Identificador Importância Ator Primário Atores Secundários Pré-condições Fluxo Principal Fluxos Alternativos Fluxos de Exceção Pós-condições Regras do Negócio Histórico Notas de Implementação

88 Atenção: A equipe de desenvolvimento deve utilizar o formato de descrição que lhe for realmente útil. A descrição do diagrama deve ser mantida no nível mais simples possível. Construção do diagrama de casos de uso

89 Documentação dos Casos de Uso Nome O mesmo que aparece no diagrama de casos de uso Deve ser único Identificador Um código que possibilita referência cruzada entre diversos documentos do modelo de casos de uso Exemplo: CSU01, CSU02,...

90 Documentação dos Casos de Uso Importância Casos de uso identificados para um sistema em função de: risco de desenvolvimento e prioridades estabelecidas pelos usuários Categorias identificadas: Risco Alto e Prioridade Alta; Risco Alto e Prioridade Baixa;Risco Baixo e Prioridade Alta; Risco Baixo e Prioridade Baixa.

91 Documentação dos Casos de Uso Sumário ou Descrição Uma breve descrição do caso de uso (duas ou três linhas) Atores Quem interage com o caso de uso Podem ser divididos entre primários e secundários Pré-condições Situações ou eventos que devam ter ocorrido no sistema antes do início do caso de uso em questão Exemplo: antes de Realizar Pedido, o cliente precisa estar cadastrado

92 Documentação dos Casos de Uso Fluxo Principal ou Cenário Principal Corresponde à seqüência de passos do fluxo principal que descreve o que normalmente acontece quando o caso de uso é realizado Deve ser escrito em linguagem clara e concisa, focado no domínio do problema e não na solução deste

93 Documentação dos Casos de Uso Fluxos Alternativos Descreve o que acontece quando o ator faz uma escolha alternativa, diferente da descrita no fluxo principal São utilizados também para descrever situações de escolhas exclusivas entre si (há diversas situações e apenas uma deve ser realizada) Diferença entre fluxo alternativo e caso de uso de extensão: o fluxo alternativo descreve o comportamento alternativo para execução do fluxo principal. Uma extensão descreve um comportamento que funciona como uma interrupção em relação ao caso de uso principal.

94 Documentação dos Casos de Uso Fluxos de Exceção Correspondem às situações de exceção que descrevem o que acontece quando algo inesperado ocorre na interação entre ator e caso de uso Exemplo: Caso de uso Realizar Pedido Situações: cartão de crédito com limite excedido;loja sem quantidade do produto solicitada; cliente com débito anterior na loja.

95 Documentação dos Casos de Uso Pós-condições Descreve o estado que o sistema alcança após a realização do caso de uso Regras de Negócio Pode fazer referência às políticas, condições ou restrições que devem ser consideradas na execução dos processos da organização

96 Documentação dos Casos de Uso Histórico Contém informações como nome do autor do caso de uso, a data em que foi criado, versão, última alteração, entre outras. Notas de Implementação Descreve as idéias o autor quanto à implementação do caso de uso, caso surjam durante a elaboração do caso de uso.

97 Documentação Associada O modelo de casos de uso resgata os requisitos funcionais do sistema Existem outros tipos de requisitos (desempenho, interface, segurança, regras do negócio, etc.) que também fazem parte do documento de requisitos, mas que não são considerados no modelo de casos de uso.

98 Regras do negócio São políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização. Descrevem a maneira pela qual a organização funciona. Estas regras são identificadas e documentadas no chamado modelo de regras do negócio. A partir da identificação pode-se referenciá-la em outros artefatos A descrição do modelo de regras do negócio pode ser feita utilizando-se texto informal, ou alguma forma de estruturação.

99 Regras do negócio Alguns exemplos de regras do negócio: O valor total de um pedido é igual à soma dos totais dos itens do pedido acrescido de 10% de taxa de entrega. Um professor só leciona disciplinas para as quais esteja habilitado. Um aluno não pode cursar mais do que 6 disciplinas por semestre.

100 Regras do negócio Alguns exemplos de regras do negócio: Um cliente do banco não pode retirar mais de $ 1000 por dia da conta. Os pedidos para um cliente comum devem ser pagos a vista. As Senhas devem ter, no mínimo 6 caracteres

101 Regras do negócio Regras do negócio normalmente têm influência sobre um ou mais casos de uso. Os identificadores das regras do negócio devem ser adicionados à descrição do caso de uso. Utilizando a seção regras do negócio da descrição do caso de uso. Possível formato para documentação de uma regra de negócio.

102 Regras do negócio NomeQuantidade de inscrições possíveis (RN01) DescriçãoUm aluno não pode ser inscrever em mais de seis disciplinas por semestre letivo. FonteCoordenador da escola de informática HistóricoData de identificação: 12/07/2002

103 Requisitos de Desempenho Define características relacionadas à operação do sistema Exemplos: Número de transações por unidade de tempo Tempo máximo esperado para uma determinada operação Volume de dados Utiliza-se uma tabela para conectar casos de uso a requisitos de desempenho

104 Requisitos de Desempenho Ident. Caso de UsoFreq. UtilizaçãoTempo Máximo CSU01 5/mês 15/dia 60/dia 180/dia Interativo 1 segundo Interativo 10 segundos

105 Casos de uso – Iterativo e Incremental A identificação da maioria dos atores e casos de uso é feita na fase de concepção. A descrição dos casos de uso considerados mais críticos começa já nesta fase, que termina com ~10% a 20% do modelo de casos de uso completo.

106 Casos de uso – Iterativo e Incremental Ao final da fase de elaboração ~80% do modelo de casos de uso estará construído. A descrição dos casos de uso feita até este momento tem em um nível de abstração essencial.

107 Casos de uso – Iterativo e Incremental Na fase de construção, casos de uso formam uma base natural através da qual podem-se realizar as iterações do desenvolvimento. Um grupo de casos é alocado a cada iteração. Em cada iteração, o grupo de casos de uso é detalhado e desenvolvido.

108 Casos de uso – Iterativo e Incremental O processo continua até que todos os casos de uso tenham sido desenvolvidos e o sistema esteja completamente construído. Este tipo de desenvolvimento é chamado de desenvolvimento dirigido a casos de uso.

109 Casos de uso – Iterativo e Incremental Deve-se considerar os casos de uso mais importantes primeiramente. Pode-se classificar os casos de uso em função do risco de desenvolvimento e das prioridades estabelecidas pelo usuário.

110 Casos de uso – Iterativo e Incremental 1) Risco alto e prioridade alta - São os mais críticos e devem ser considerados o quanto antes 2) Risco alto e prioridade baixa - Verificar com o usuário a verdadeira necessidade do caso de uso 3) Risco baixo e prioridade alta - Sempre priorize os casos de uso com Risco Alto, depois os demais. 4) Risco baixo e prioridade baixa - Em situações de atraso, estes são os primeiros a serem cortados

111 Casos de uso – Iterativo e Incremental Considerando-se a categorização anterior, um caso de uso não tão importante não será contemplado nas iterações iniciais. Atacar o risco maior mais cedo...

112 Casos de uso – Iterativo e Incremental A descrição expandida de um caso de uso pode ser deixada para a iteração na qual este deve ser implementado. Isso evita perder de tempo no início com o detalhamento e Constitui uma estratégia mais adaptável aos requisitos voláteis.

113 Exercício Defina o que significa um ator. Defina o que significa um caso de uso. Qual o objetivo dos diagramas de casos de uso? Que tipos de relacionamentos podem existir entre casos de uso? Exemplifique e explique a semântica dos mesmos.

114 Estudo de Caso Aplicação: Faculdade necessita de um sistema para controlar seus processos acadêmicos. Lista de Requisitos Funcionais: R1: O sistema deve permitir que os alunos visualizem as notas obtidas durante o semestre R2: O sistema deve permitir o lançamento das notas das disciplinas, controlando prazos R3: O sistema deve manter informações cadastrais sobre disciplinas e currículos escolares R4: O sistema deve permitir a abertura de turmas para uma disciplina, assim como a definição de salas e laboratórios a serem utilizadas e dos horários e dias da semana em que haverá aula das turmas

115 Estudo de Caso Lista de Requisitos Funcionais: R5: O sistema deve permitir que os alunos realizem a inscrição e disciplinas R6: O sistema deve permitir o controle do andamento das inscrições em disciplinas feitas por alunos R7: O sistema deve se comunicar com o sistema de recursos humanos para obter dados cadastrais do professores R8: O sistema deve e comunicar com o sistema financeiro para informar as inscrições feitas pelos alunos R9: O sistema deve manter informações cadastrais dos alunos e seus respectivos históricos escolares.

116 Regras de Negócio Quantidade máxima de inscrições por semestre letivo (RN01) Descrição Em um semestre, um aluno não pode se inscrever em uma quantidade de disciplinas cuja soma de créditos ultrapasse 20 Pré-requisitos para uma disciplina (RN02) Descrição Um aluno não pode se inscrever em uma disciplina para a qual não possua os pré-requisitos necessários Cancelamento de matrícula Descrição Um aluno deve ter a matrícula cancelada se for reprovado mais de duas vezes na mesma disciplina

117 Atores Aluno: indivíduo que está matriculado na faculdade e que tem interesse em se inscrever em disciplinas do curso Professor: Indivíduo que leciona disciplinas na faculdade Coordenador: pessoa interessada em agendar as alocações de turmas e professores e visualizar o andamento de inscrições dos alunos

118 Atores Departamento de Registro Escolar: Departamento da faculdade interessado em manter informações sobre os alunos matriculados e sobre seu histórico escolar Sistema de Recursos Humanos: Este sistema legado é responsável por fornecer informações cadastrais sobre os professores Sistema Financeiro: Este sistema legado tem interesse em obter informações sobre inscrições dos alunos para realizar o controle de pagamento de mensalidades.

119 Sistema de Controle Acadêmico Atender Listas de Espera Manter Disciplinas Manter Cadastro Alunos Realizar Inscrição Cancelar Inscrição Visualizar Inscrições Visualizar Avaliações Abrir Turmas Fornecer Disponibilidade Lançar Notas Atualizar Cadastro Professor Lançar Faltas Aluno Coordenador DRE Professor SRH SF Visualizar Grade Curricular

120 CSU01 – Realizar Inscrição Sumário: Aluno usa o sistema para realizar inscrições em disciplinas Ator primário: Aluno Ator Secundário: Sistema Financeiro Pré-condições: O aluno está identificado pelo sistema

121 CSU01 – Realizar Inscrição Fluxo principal: 1. O aluno solicita a realização de inscrição 2. O sistema apresenta as disciplinas disponíveis para o semestre corrente e para as quais o alunos tem pré-requisitos (RN02) 3. O aluno seleciona as disciplinas desejadas e as submete para inscrição 4. Para cada disciplina selecionada, o sistema aloca o aluno em uma turma que apresente uma oferta para tal disciplina

122 CSU01 – Realizar Inscrição 5. O sistema informa as turmas nas quais o aluno foi alocado. Para cada alocação, o sistema informa o professor, os horários e os respectivos locais das aulas de cada disciplina 6. O alunos confere as informações fornecidas 7. O sistema envia os dados sobre a inscrição do aluno para o Sistema Financeiro, e o caso de uso termina.

123 CSU01 – Realizar Inscrição Fluxo Alternativo(4): Inclusão em lista de espera a. Se não há oferta disponível para alguma disciplina selecionada pelo aluno, o sistema reporta o fato e fornece a possibilidade de inserir o aluno em uma lista de espera b. Se o aluno aceitar, o sistema o insere na lista de espera e apresenta a posição na qual o aluno foi inserido na lista. O caso de uso retorna ao passo 4 c. Se o aluno não aceitar, o caso de uso prossegue a partir do passo 4

124 CSU01 – Realizar Inscrição Fluxo de Exceção (4): Violação da RN01 a. Se o aluno atingiu a quantidade máxima de inscrições (RN01), o sistema informa ao aluno a quantidade de disciplinas que ele pode selecionar, e o caso de uso retorna ao passo 2 Pós-condições: O aluno foi inscrito em uma das turmas de cada uma das disciplinas desejadas ou foi adicionado a uma ou mais listas de espera. Regras de Negócio: RN01 e RN02

125 Exercício: Construir documentação dos seguintes casos de uso: 1. Visualizar Avaliações 2. Atualizar cadastro de Professor 3. Visualizar Inscrições


Carregar ppt "Modelos de Casos de Uso. Levantamento de Requisitos Desenvolvedor: O que o Sr. Espera do sistema ? Usuário: Eu tenho uma loja de peças e gostaria que."

Apresentações semelhantes


Anúncios Google