Atividade de Análise Fase de Elaboração. Artefatos Casos de Uso –Expansão dos Casos de Uso Definidos na Fase de Concepção: Formulário Específico –Diagramas.

Slides:



Advertisements
Apresentações semelhantes
Modelo de Casos de Uso Diagrama de Casos de Uso
Advertisements

Um pouco mais de cardinalidade e Relacionamentos
Análise e Projeto Orientado a Objetos
Requisitos de Software
Aula 8 Contratos.
UML no CICLO de DESENVOLVIMENTO
APSOO Aula 03.
APSOO Aula 05.
Diagrama de Fluxo de Dados – DFD
Diagrama de fluxo de dados (DFD)
Projeto conceitual Mostra ao cliente exatamente o que o sistema fará
Casos de Uso.
UML Material retirado da apostila do Professor Cesar Augusto Tacla
Lógica de Programação Módulo II
SISTEMA DE INFORMAÇÕES DESENVOLVIMENTO DE SISTEMAS
Análise e Projeto de Sistemas
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
Selma Shin Shimizu Melnikoff 2006
Modelagem para Web Aula de 11/04/2011.
Diagramas de Sequência e Comunicação
Especificação de Requisitos de Software com Casos de Uso
Análise de Sistemas Análise e Projeto Prof. Jeime Nunes Site:
Expansão dos Casos de Uso
Requisitos e Casos de Uso
Análise Estruturada.
Processo Praxis – Fase de Concepção
Expansão dos Casos de Uso
Gestão de Escopo Por Ruan Carlos.
Fase de Elaboração: Fluxo de Análise Análise de Sistemas de Software Prof. Rodrigo Ribeiro.
Caso de Uso - Definição Um caso de uso é uma descrição narrativa de uma seqüência de eventos que ocorre quando um ator (agente externo) usa um sistema.
Silas Juccelino Artulanez.  O que é?  Notação  Estado  Mudança de estado  Condições e ações  Diagramas subdivididos  Passos na construção  Verificação.
Fase de Concepção (Início, Planejamento)
UML - Unified Modeling Language
Casos de Uso.
UML Diagrama de Caso de Uso Profª. Marcelo Siedler
Introdução a Banco de Dados
Laboratório de Programação
RUP - Cap. 3 – Processo Dirigido por Caso de Uso
Desenhando Fluxogramas
Processos do Design 27/09.
Trabalho de Engenharia de Software II
Fase de Concepção Levantamento de Requisitos, Organização de Requisitos, Planejamento dos Ciclos Iterativos.
Conceitos Básicos Introdução.
Técnicas e Projeto de Sistemas
Análise e Projeto de Sistemas
Modelando Sistemas em UML
Fluxos secundários Só devem ser analisados e descritos após a descrição dos fluxos básicos. Fluxos alternativos situações especiais (desconto para um cliente)
Casos de Uso Tarciane Andrade
Abr-17 Analisar Caso de Uso Analisar caso de uso.
Gestão de projetos de Software GTI-16
Modelo de Análise e Projeto
Diagramas de Caso de Uso
Diagramas UML de Seqüência
Fase de Concepção (Início, Planejamento)
Requisitos Não funcionais
Expansão dos Casos de Uso
Contratos Modelagem Funcional.
Fase de Concepção (Início, Planejamento)
Expansão dos Casos de Uso
Modelagem Conceitual Descreve a informação que o sistema vai gerenciar.
Diagrama Casos de Uso.
Análise Estruturada de Sistemas
Aula 02 de Eng. de Requisitos
Engenharia de Software com o RUP - Workflow de Requisitos
Projeto de Sistemas - PRJ Aula 4
Sistema de Gerenciamento de Conferências Tecnológicas Descrição de Casos de Uso e Plano de Projeto Grupo 2 Andre Esteve Henrique Baggio Rafael Cano Victor.
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso.
Como assistir ao Webcast -Clique sobre o tópico do capítulo à esquerda -Leia todos os slides através da navegação automática (recomendado) -Você pode avançar.
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

Atividade de Análise Fase de Elaboração

Artefatos Casos de Uso –Expansão dos Casos de Uso Definidos na Fase de Concepção: Formulário Específico –Diagramas UML Expandidos Decomposição em sub-casos de uso –Relacionamentos include, extend, is_a Modelo Conceitual –Refinamentos sucessivos (cada iteração) do Modelo Preliminar Diagrama de Entidades e Relacionamentos –Agregação/Composição, Hierarquia, Papéis nos relacionamentos

Artefatos (2) Diagrama de Seqüência das Operações de Sistema –Operações que mudam o estado do sistema Contratos das Operações de Sistema Consultas / Relatórios –“Lay-outs”

Artefatos (3) Estudo de Caso –1ª. Iteração: Caso de Uso Emprestar Fitas Expansão do Caso de Uso, incluindo a sua decomposição em sub-casos de uso Diagrama de Seqüência das Operações do Caso de Uso Contratos das Operações do Caso de Uso –2ª. Iteração: Caso de Uso Reservar Fitas –3ª. Iteração: Caso de Uso Devolver Fitas –4ª. Iteração: Consultas / Relatórios

Expansão de Casos de Uso

Casos de Uso no Contexto do UP

Atividades de Expansão Descrever o fluxo principal –Não considera erros ou exceções Descrever fluxos alternativos –Considera erros ou exceções

Níveis de Detalhamento Alto Nível –Fase de Concepção Expandido –Fase de Elaboração

Exemplo de Caso de Uso de Alto Nível

Exemplo de Caso de Uso Expandido

Comentários sobre Textos de Casos de Uso Fluxo Principal –Observe que o estilo em passos permite evitar o uso de expressões se então senão, que são fonte de ambigüidades Pior ainda é o ‘ninho de se´s’: se então senão se... –Sendo mais enfático, o uso de se é proibido no fluxo principal

Comentários sobre Textos... (2) Fluxos Alternativos –O uso de se não é proibido, mas deve ser evitado No exemplo, o passo 4b.3 ainda usa se Nos próximos dois slides, o passo 4b é inteiramente reescrito, e um novo passo 4c é escrito, tudo isso para evitar o uso do se

Comentários sobre Textos... (3) 4b. Uma fita está danificada e existe outra cópia –4b.1 O funcionário informa que a fita está danificada –4b.2 O funcionário registra que a fita está danificada –4b.3 O funcionário substitui a fita –4b.4 Retorna ao passo 4

Comentários sobre Textos... (4) 4c. Uma fita está danificada e não existe outra cópia –4c.1 O funcionário informa que a fita está danificada –4c.2 O funcionário registra que a fita está danificada –4c.3 Retorna ao passo 4

Comentários sobre Textos... (5) Interrupção de Caso de Uso –Tanto em relação ao fluxo principal quanto aos fluxos alternativos, um caso de uso é implicitamente ‘abortado’ se qualquer passo não puder ser integralmente realizado Passo 2: se o cliente não informa seu nome, o caso de uso não pode continuar Passo 3a.2: se o funcionário não cadastra o novo cliente, o caso de uso não pode continuar

Comentários sobre Textos... (6) A solução para o caso de uso Emprestar Fitas admite que o cliente *sempre* leva fitas. Isto não é bem uma realidade. Exercício: Modifique o texto do caso de uso para que um cliente possa sair sem levar fitas.

Comentários sobre Textos... (7) Sossegue! Não vou matá-lo(a) se empregar o se (refiro-me a fluxos alternativos) –Apenas, peço que esgote todas as suas possibilidades de não usar o se

Resumindo …

Tratamento de Exceções em Casos de Uso Depois de descrever o fluxo principal de um caso de uso, deve-se imaginar o que poderia dar errado em cada um dos passos descritos Uma exceção é um evento que se não for devidamente tratado impede o prosseguimento do caso de uso Exceção – se não for tratada -- em um processo não é necessariamente algo que impede que o processo seja iniciado, mas normalmente algo que impede que ele seja concluído

Regras para Tratamento de Exceção Identificador – número da linha no fluxo principal (FP) e código da exceção Descrição da exceção – uma frase Ações corretivas – um fluxo alternativo Finalização – retorno ao FP

Formas de Finalizar um Fluxo Alternativo Voltar ao início do passo do FP que causou a exceção Ir para algum passo posterior do FP Voltar ao início do caso de uso Abortar o caso de uso

Forma a ser evitada no Fluxo Principal Se o cliente possui cadastro então o funcionário registra...

‘Aborto’ de Caso de Uso Um caso de uso é implicitamente ‘abortado’ quando –Não for possível realizar um passo –Não é necessário indicar isso como exceção, pois idealmente pode ocorrer a qualquer momento e em qualquer passo

Repetição de Passos Repetição de um Passo –PassoX* (o ‘*’ indica iteração) Repetição de uma coleção de passos –Repita PassoX – PassoY Enquanto PassoX PassoY

… Fim do Resumo

Como Avaliar a Qualidade do Texto de um Caso de Uso? Resolver o problema do se faz parte da avaliação Classificação dos passos do texto –Obrigatórios –Complementares –Não Recomendáveis

Passos Obrigatórios Descrevem entradas / saídas de informação do sistema necessárias para realizar o caso de uso –Não vale ‘informação’ do tipo “OK” (isso deve ficar implícito) Na falta de um passos obrigatório, o caso de uso deve ficar sem sentido

Exemplo de Caso de Uso em que Falta Informação (Entrada)

Um Diálogo Impossível, Baseado no Caso de Uso do Slide Anterior

Uma Solução Adequada

Tipos de Passos Obrigatórios Eventos de sistema – Entradas (EV), ‘disparadas’ por atores Respostas de sistema – Saídas (RS), ou ações decorrentes de eventos –Obs. Não são respostas de sistema retornos do tipo “OK”. Deve ser enviada ao mundo externo alguma informação armazenada no sistema

Identificação de Passos Obrigatórios em um Caso de Uso

Passos Complementares Não são do tipo EV ou RS, mas ajudam a compreender o contexto Tais passos têm pouca ou nenhuma influência na complexidade do software a ser desenvolvido –Slide anterior: o passo 1 é complementar

Mais Exemplos de Passos Complementares “O cliente chega ao balcão com as fitas que deseja locar” “O cliente vai embora com as fitas” “O funcionário pergunta o nome do cliente”

Passos Não Recomendáveis Passos com –Informação incompleta –‘Informação’ do tipo “OK” Passos que descrevem processos internos ao sistema –O caso de uso só deve descrever a interação entre o sistema e os atores, e não processamento interno Passos do fluxo principal que descrevem exceções –Exceções devem ser tratadas somente em fluxos alternativos Passos não recomendáveis devem ser corrigidos ou para obrigatórios ou para complementares

Exemplos de Passos Não Recomendáveis “O sistema registra o nome do cliente no banco de dados” (processo interno) “O sistema calcula a média das vendas” (processo interno) – Calcular a média é um requisito funcional –Porém, no caso de uso o que deve ser descrito é algo como o sistema mostra a média das vendas (RS)

Um Exemplo de Caso de Uso com Passos Não Recomendáveis

Um Exemplo de Caso de Uso com Passos Não Recomendáveis (2) Os passos não recomendáveis – 4: exceção – 6: processo interno

Técnica de Variante em Casos de Uso Variantes não são exceções, mas cenários distintos dentro de um passo de um caso de uso –Outra forma de evitar o uso do Se –Re-uso

Re-uso de Variantes

Quando Usar Variantes? Quando uma mesma seqüência de passos é repetida em diferentes casos de uso Quando um caso de uso é demasiadamente complexo, e a divisão dele em variantes ajuda na sua compreensão –Diagrama UML de caso de uso: relacionamento is_a

Leituras em Casos de Uso Evite –“O sistema verifica se o usuário está cadastrado” Esta forma não descreve nem entrada e nem saída Prefira –“O funcionário informa a identificação do cliente” Entrada –“O sistema informa os dados do cadastro do cliente” Saída

Leituras em Casos de Uso (2) Note que usamos a palavra Leitura, em vez de Consulta –Consulta é algo bem mais amplo, e deve ser tratada em Consultas / Relatórios (casos de uso especiais)

Outras Seções de um Caso de Uso Expandido Atores Interessados –Atores secundários Pré-condições –Sem elas, o caso de uso intrinsecamente aborta, desde o início Pós-condições –Os efeitos (mudança de estado) no sistema Requisitos Funcionais Correlacionados, ou Referências Cruzadas Variações Tecnológicas Questões em Aberto –Indicam a necessidade de refinar o caso de uso, ao longo das iterações seguintes

Diagramas UML de Caso de Uso Decomposição em Sub-casos de Uso

Construção de Diagramas Variantes –Relacionamentos is_a Fluxos Alternativos –Relacionamentos extend Fluxos Principal e Alternativo –Relacionamentos include, se o fluxo for suficientemente grande

Exercício Desenhe um diagrama UML detalhado, para o caso de uso Emprestar Fitas

Projeto: Parte II Fase Elaboração – Atividade: Análise Detalhada –Versão #2 do Documento, acrescentando à Versão #1, e para cada iteração Casos de Uso Expandidos Diagramas UML Expandidos de Caso de Uso Modelo Conceitual do Sistema (incrementos sucessivos) Diagrama de Seqüência de Operações (DSO), para cada caso de uso Contratos de Operações, para cada DSO –Prazo: 15/08/07