520 likes | 612 Views
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
E N D
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
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
Comentários sobre Textos de Casos de Uso • Fluxo Principal • Observe que o estilo em passos permite evitar o uso de expressões se <condição> então <ação-1> senão <ação-2>, que são fonte de ambigüidades • Pior ainda é o ‘ninho de se´s’: se <condição1> então <ação-1> senão se <condição2> ... • 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
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 <condição> PassoX ... ... PassoY
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
Um Diálogo Impossível, Baseado no Caso de Uso do Slide Anterior
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
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 registrao nome do cliente no banco de dados” (processo interno) • “O sistema calculaa 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 (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
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