2 - Visão Geral do Fluxo de Análise e Projeto

Apresentação em tema: "2 - Visão Geral do Fluxo de Análise e Projeto"— Transcrição da apresentação:

1 2 - Visão Geral do Fluxo de Análise e Projeto

2 Apresentar conceitos utilizados no fluxo de análise e projeto
Objetivos desta parte Apresentar conceitos utilizados no fluxo de análise e projeto Dar uma visão geral das atividades, responsáveis e artefatos deste fluxo Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

3 O Fluxo de Análise e Projeto
Os objetivos do fluxo: Transformar os requisitos em um projeto (inicialmente abstrato) do sistema Desenvolver uma arquitetura robusta Adaptar o projeto levando em consideração os requisitos da futura implementação Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

4 Visão geral dos artefatos
Modelo de análise e projeto Análise e projeto Modelo de caso de uso Documento da arquitetura Mapeamento das classes de análise em elementos de projeto Documento requisitos Glossário Modelo de dados Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

5 Sobre os artefatos A construção do modelo de análise e projeto é o principal objetivo deste fluxo de atividades O modelo de análise e projeto contém as realizações de casos de uso O mapeamento das classes de análise em classes de projeto é um artefato temporário do desenvolvimento O documento da arquitetura é opcional; é usado para descrever em detalhes uma determinada arquitetura A elaboração do modelo de dados está fora do escopo do curso, mas pode conter, por exemplo, o mapeamento do modelo OO para o relacional Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

6 Artefato Realização de caso de uso
Modelo de Casos de uso Modelo de Análise e Projeto Caso de uso Realização do Caso de uso Diagramas de Sequência Caso de uso Diagramas de Classe Diagramas de Colaboração Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

7 Realização de Caso de Uso
Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto Em UML, uma realização de caso de uso pode ser representada através de um conjunto de diagramas: diagrama de classe diagrama de seqüência diagrama de colaboração diagramas de interação Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

8 Artefato Modelo de Análise e Projeto
Diagramas de Sequência Diagramas deColaboração Modelo de análise e projeto Diagramas de Classe Visão de casos de uso + Visão Lógica Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

9 Modelo de Análise e Projeto
Pode ser um só artefato evoluindo de uma visão abstrata (nas atividades de análise), para uma visão detalhada (nas atividades de projeto) Podem ser feitos dois artefatos um modelo de análise um modelo de projeto (inicia igual à última versão do modelo de análise e evolui independentemente) Documentação x esforço e disciplina de manutenção Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

10 Análise X Projeto Análise Projeto Foco no problema
Comportamento (caixa preta, sem detalhes de implementação) Estrutura do sistema Requisitos funcionais Modelo simples Projeto Foco em uma solução Operações e atributos Representação próxima do código Requisitos não funcionais (exemplo: desempenho), além dos funcionais Modelo complexo Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

11 Arquitetura de software O modelo de “4+1 Visões”
Estrutura, componentes Projetista Arquiteto Programadores Estrutura Visão Lógica Visão de Implementação Visão de Casos de Uso Integradores do sistema Arquiteto Integradores do sistema Arquiteto Visão de Processo Visão de Distribuição Topologia, implantação, comunicação Performance, Escalabilidade Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

12 Fluxo de Análise e Projeto do RUP
• • • • • • • Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

13 Fluxo de Análise e Projeto Atividades vistas no curso
Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados • Projetar base de dados Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

14 Responsáveis e Artefatos
Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

15 3 - Atividade Analisar Caso de Uso

16 Projetista de banco de dados
Analisar Caso de Uso Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Revisar projeto Projetista de banco de dados Projetar base de dados Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

17 Objetivos desta atividade
Encontrar classes de análise e distribuir comportamento dos casos de uso entre estas Para cada classe, descrever suas responsabilidades, atributos e associações Unificar classes de análise Esta atividade é realizada para cada caso de uso! Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

18 Visão geral dos artefatos
Glossário Documento da arquitetura Classes de análise Analisar caso de uso Documento de requisitos Realização de caso de uso (desenvolvimento) Modelo de caso de uso Modelo de análise e projeto Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

19 Passos para Analisar Caso de Uso
Para cada caso de uso: 1. Encontrar classes de análise 2. Distribuir comportamento entre as classes Para cada classe: 3. Descrever responsabilidades 4. Descrever atributos e associações 5. Identificar persistência 6. Revisar os Resultados Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

20 Sistema exemplo: Auto Atendimento Descrição do Problema
O auto atendimento é uma característica essencial das agências bancárias atuais. A idéia é que operações simples como saques, depósitos, transferências entre contas e consultas a saldos e extratos sejam realizadas diretamente pelo cliente, sem necessidade da intervenção de funcionários do banco. Esta estratégia de atendimento diminui custos operacionais das agências e agrada ao cliente, que pode efetuar operações corriqueiras mais agilmente. Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

21 Sistema exemplo: Auto Atendimento Descrição do Problema
O sistema em questão deve automatizar essas operações em um caixa automático, que será distribuído em vários locais, permitindo ao cliente realizar transações remotas com o seu banco. O uso do caixa automático deve ser controlado através de cartão magnético e senha, que serão fornecidos a cada cliente pelo banco. O caixa deve ler o cartão para validar o login do cliente e comunicar-se com o sistema central do banco para executar as operações. Toda operação realizada pelo cliente no caixa automático deve ser registra em um log de transações. Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

22 Sistema exemplo: Auto Atendimento Diagrama de casos de uso
Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

23 Passo 1. Encontrar classes de análise
O comportamento do caso de uso é distribuído em classes de análise dos seguintes tipos (estereótipos) fronteira controle entidade Estes estereótipos são uma conveniência de análise que desaparecem no projeto Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

24 Classes de análise: um primeiro passo em direção ao executável
Casos de uso Classes de análise Elementos de projeto Código fonte Executável Use-Case Analysis Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

25 Classes de Fronteira (boundary classes)
Isolam o sistema de mudanças no ambiente externo Atores devem se comunicar apenas com classes de fronteira Exemplos de classes fronteira GUI Interface com outros sistemas Interface com dispositivos <<boundary>> Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

26 O Papel de uma Classe de Fronteira
Modela interação entre o sistema e seu ambiente <<boundary>> <<control>> <<boundary>> Usuário <<boundary>> <<entity>> <<entity>> Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

27 Regra geral para encontrar Classes de Fronteira
Uma classe por cada par ator/caso de uso Exemplo: Caso de uso Sacar Dinheiro Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

28 Descrevendo Classes de Fronteira
GUI Concentre-se nas informações que serão apresentadas, não em um projeto gráfico Interface com outros sistemas ou dispositivos Concentre-se em quais protocolos devem ser definidos, não como serão implementados Concentre-se nas responsabilidades, não nos detalhes! Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

29 Classes de Entidade (entity classes)
Abstrações e conceitos chaves dos casos de uso <<entity>> Glossário <<entity>> <<entity>> Descrição do Caso de uso Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

30 O Papel de uma Classe de Entidade
Armazenam e gerenciam informação no sistema <<boundary>> <<control>> <<boundary>> Customer <<boundary>> <<entity>> <<entity>> Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

31 Orientações para encontrar Classes de Entidade
Usando a descrição do caso de uso, use a abordagem tradicional de filtrar substantivos identifique substantivos no fluxo de eventos remova candidatos redundantes e vagos remova atores que apenas interagem com o sistema mas não fazem parte da modelagem remova atributos (serão usados mais tarde) e operações Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

32 Exemplo: Classes de entidade dos casos de uso Sacar Dinheiro e Registrar Transação
Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

33 Classes de Controle (control classes)
Coordenam o comportamento (lógica de controle) do caso de uso Interface entre fronteira e entidade Dependente do caso de uso, independente do ambiente Permitem separação entre o uso da entidade (específico do sistema) do comportamento inerente à entidade <<control>> Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

34 O Papel de uma Classe de Controle
Coordenam o comportamento do caso de uso Uma classe controle pode ter referência a vários objetos entidade Finalidade semelhante a classes fachada (Arquitetura de Camadas) <<boundary>> <<control>> <<boundary>> Customer <<boundary>> <<entity>> <<entity>> Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

35 Orientações para encontrar Classes de Controle
Usualmente, uma classe de controle por caso de uso Eventualmente mais de uma (comportamento complexo) ou nenhuma (manipulação simples de informações armazenadas) Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

36 Exemplo de Classe de Controle Caso de uso Sacar Dinheiro
Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

37 Exemplo: Classes de Análise resultantes do caso de uso Sacar Dinheiro
<<boundary>> FormularioSaque <<control>> ControladorSaque <<boundary>> SistemaBanco Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

38 Dado: Produzir: Exercício: Projeto
O documento de requisitos, especificamente o fluxo de eventos de um dos principais casos de uso do seu projeto Produzir: Identificação das classes de análise, com seus estereótipos e breve descrição Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

39 Lembrando que estas atividades são realizadas para cada caso de uso
Contexto Encontradas as classes de análise, vamos agora descrever o seu comportamento. Lembrando que estas atividades são realizadas para cada caso de uso Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

40 Passo 2. Distribuir comportamento entre as classes
Para cada fluxo de eventos alocar responsabilidades do caso de uso às classes de análise modelar interações entre as classes através dos diagramas de interação Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

41 Distribuindo comportamento entre as classes
Classes de análise Diagrama de seqüência Diagrama de colaboração Classes de análise com responsabilidades Caso de uso Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

42 Alocando responsabilidades
Use estereótipos de análise como guia Classes de fronteira Comportamento que envolve comunicação com um ator Classes de entidade Comportamento que envolve informação encapsulada na abstração Classes de controle Comportamento específico ao (lógica de controle do) caso de uso Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

43 Alocando responsabilidades
Identificar que classe tem a informação necessária para realizar a responsabilidade isso pode envolver apenas uma classe, pode ser preciso criar nova classe ou relacionamento entre classes Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

44 Modelando interações Diagramas de interação (colaboração e seqüência) modelam interações do sistema com seus atores A interação é iniciada por um ator e envolve instâncias (objetos) das classes Diagramas de interação capturam a semântica do fluxo de eventos do caso de uso Auxiliam a identificar classes, responsabilidades e relacionamentos Mecanismo de validação da arquitetura Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

45 Forma Geral dos Diagramas de Seqüência
Client Object Supplier Object :Client :Supplier Object Lifeline Reflexive Message 1: Perform Responsibility 1.1: Perform Another Responsibility Message Hierarchical Message Numbering Focus of control Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

46 Exemplo de um Diagrama de Seqüência: Caso de uso Registrar Transação

47 Exemplo de um Diagrama de Seqüência: Caso de uso Sacar Dinheiro
Distribuir diagrama para os alunos Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

48 Forma Geral de Diagramas de Colaboração
Client Object Link Supplier Object :Client :Supplier 1: PerformResponsibility Message Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

49 Exemplo de um Diagrama de Colaboração Caso de uso Registrar Transação
Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

50 Vários diagramas podem ser necessários
Pelo menos o fluxo principal deve ser modelado Mas não é necessário modelar todos os fluxos O importante é exemplificar o uso de todas as responsabilidades Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

51 Diagramas de Colaboração e Seqüência
Apresenta relacionamentos além das interações Adequado para visualizar padrões de colaboração Adequado para visualizar efeitos em um dado objeto Útil em sessões de brainstorm Seqüência Apresenta seqüência explícita de mensagens Adequado para visualizar o fluxo completo Adequado para especificações de tempo real e para cenários complexos Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

52 encontramos as classes de análise
Contexto Para cada caso de uso encontramos as classes de análise descrevemos o seu comportamento através de diagramas de interação Agora, para cada classe vamos descrever suas responsabilidades Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

53 Passo 3. Descrever Responsabilidades
Responsabilidades identificadas nos fluxos de eventos são refletidas em diagramas de interação Mensagens nestes diagramas resultam em responsabilidades nas classes receptoras diagrama de interação :Client :Supplier // PerformResponsibility diagrama de classe Supplier // PerformResponsibility Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

54 Exemplo de VOPC (View of Participating Classes) com Responsabilidades: Caso de uso Sacar Dinheiro
LeitoraCartao SistemaBanco ContadoraDinheiro ler cartao() selecionar conta(numero, senha) entregar dinheiro(valor) FormularioSaque ControladorSaque informar senha(senha) iniciar sessao(cartao, senha) informar valor saque(valor) finalizar sessao() iniciar sessao(numero) debitar(identificador conta, valor) Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

55 Poderá resultar em uma alteração dos diagramas de interação
Analisando o Modelo Classes com responsabilidades similares são candidatas a serem combinadas Uma classe com responsabilidades disjuntas é candidata a ser dividida Classes sem (ou com apenas uma responsabilidade) e classes que interagem com muitas classes são candidatas a serem reexaminadas Poderá resultar em uma alteração dos diagramas de interação Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

56 Dado: Produzir: Exercício: Projeto VOPC com responsabilidades
O documento de requisitos, especificamente o fluxo de eventos de um dos principais casos de uso do seu projeto As classes de análise identificadas no exercíco anterior Produzir: Diagrama de interação para o caso de uso VOPC com responsabilidades Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

57 Passo 4. Descrever atributos e associações
Detalhando mais as classes definir atributos estabelecer associações necessárias entre as classes Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

58 Encontrando Atributos
Possíveis fontes: conhecimento do negócio, requisitos, glossário, modelo do negócio, etc. São propriedades/características das classes identificadas informação cujo valor é o aspecto crucial informação de propriedade exclusiva do objeto informação que pode ser lida ou escrita por operações, mas sem outro comportamento a não ser fornecer um valor Se a informação tem comportamento complexo ou é compartilhada, deve gerar uma classe Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

59 Encontrando Relacionamentos
Links entre objetos em diagramas de colaboração indicam a necessidade de relacionamento entre as respectivas classes Links reflexivos só geram relacionamentos reflexivos quando dois objetos da classe precisam se comunicar (mas não quando um objeto envia mensagens para si próprio) A navegabilidade do relacionamento deve estar de acordo com a direção da mensagem Inclua também o papel (role) e a multiplicidade dos relacionamentos Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

60 Encontrando Relacionamentos
1: PerformResponsibility Diagrama de Colaboração :Client :Supplier Link Client Supplier Client Supplier Diagrama de classe 0..* 0..* Prime suppliers PerformResponsibility() Association Um relacionamento para cada link Fonte: Rational Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

61 Exemplo de VOPC com Relacionamentos Caso de uso Registrar Transação
Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

62 Exercício: Projeto Dado: Produzir:
Classes de análise dos casos de uso com estereótipos e responsabilidades Diagramas de colaboração para estes casos de uso VOPCs desenvolvidos no exercício anterior Produzir: VOPCs com relacionamentos e atributos Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

63 Passo 5. Identificar persistência
Identificar quais classes de análise deverão ser persistentes Identificar características de persistência Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

64 Algumas características de persistência
Granularidade Volume: até 200 Freqüência de acesso Leitura Atualização ... Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

65 Exemplo: Classes persistentes Caso de uso Registrar Transação
Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

66 Exercício: Projeto Dado Produzir Artefatos de requisitos
Identificar as classes que deverão ser persistentes Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

67 Passo 6. Revisar Resultados
Verificar se as classes de análise satisfazem os requisitos funcionais Unificar as classes de análise Verificar se todo o modelo está consistente entre si e com os requisitos Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

68 Revisando: Passos realizados nesta atividade
Para cada caso de uso: 1. Encontrar classes de análise 2. Distribuir comportamento entre as classes Para cada classe: 3. Descrever responsabilidades 4. Descrever atributos e associações 5. Identificar persistência 6. Revisar os Resultados Durante a realização dos passos, usa-se bastante a descrição do caso de uso, particularmente de seu fluxo de eventos. Às vezes, a descrição do fluxo é feita em um nível de abstração elevado e, eventualmente, pode ser preciso detalhar mais alguma parte específica do fluxo de eventos. Neste caso, deve-se entrar em contato com o especificador de requisitos e propor a mudança desejada. Maio, 2000Copyright CESAR-Qualiti, Maio Todos os direitos reservados.