Modelos de Casos de Uso.

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 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.

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.

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 ?

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.

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

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”

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)

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 Com casos de uso Sem casos de uso

Introdução Um pouco de história...
Técnica de modelagem idealizada por Jacobson, na década de 1970. 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

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

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.

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

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

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

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.

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.

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

Cliente Sistema Exemplo: Caso de uso “realiza saque”
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.

Exercício: Descreva o caso de uso Realizar Transferência entre contas correntes nos três formatos 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.

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.

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!

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,...

Casos de Uso - Descrevendo 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.

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.

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.

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.

Exercício: Descreva 3 fluxos alternativos para o caso de uso Realizar Transferência entre contas correntes

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.

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

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.

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, ...

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

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?

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?

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

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.

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

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.

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

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!

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

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.

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

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

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.

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

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.

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.

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.

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

Relacionamento - Extensão
Interações de Substituir Texto: Em qualquer momento durante Editar Documento, o ator pode optar por substituir um fragmento de texto por outro. O ator fornece o texto a ser substituído e o texto substituto. 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). O sistema substitui todas as ocorrências encontradas no texto.

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

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.

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

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

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

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.

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.

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.

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.

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

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

Sempre registrem as razões de todas as decisões, para reutilizá-las,
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!

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

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

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.

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

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.

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?

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!

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.

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?

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

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

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

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

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

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

Priorizem a identificação dos casos de uso primários!
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!

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.

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.

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.

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.

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

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.

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, ...

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.

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

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

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.

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.

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

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.

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.

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.

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.

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

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.

Regras do negócio Nome Quantidade de inscrições possíveis (RN01)
Descrição Um aluno não pode ser inscrever em mais de seis disciplinas por semestre letivo. Fonte Coordenador da escola de informática Histórico Data de identificação: 12/07/2002

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

Requisitos de Desempenho
Ident. Caso de Uso Freq. Utilização Tempo Máximo CSU01 5/mês 15/dia 60/dia 180/dia Interativo 1 segundo 10 segundos

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.

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.

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.

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.

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.

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

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...

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.

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.

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

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.

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

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

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.

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

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

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

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.

Fluxo Alternativo(4): Inclusão em lista de espera 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 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 Se o aluno não aceitar, o caso de uso prossegue a partir do passo 4

Fluxo de Exceção (4): Violação da RN01 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

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

Modelos de Casos de Uso.

Apresentações semelhantes

Apresentação em tema: "Modelos de Casos de Uso."— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Modelos de Casos de Uso.

Apresentações semelhantes

Apresentação em tema: "Modelos de Casos de Uso."— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback