Your SlideShare is downloading. ×
0
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Aula4 TEES UFS: Orientação a Objetos

1,716

Published on

Aula4 TEES UFS: Orientação a Objetos

Aula4 TEES UFS: Orientação a Objetos

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,716
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
85
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Transcript

    • 1. Orientação por Objectos > Modelo de Processo OO > Identificação de Classe e Objectos Aula 4
    • 2. Sumário
      • Actividades Básicas Independentes do Modelo
      • Conceitos e Princípios OO
        • relevantes para o processo de desenvolvimento de SW
      • Modelo de Processo OO
        • Exemplo de Processos dentro de uma Empresa
        • Modelo Recursivo / Paralelo
      • Identificação de Classes e Objectos
        • Análise Sintáctica Gramatical
        • Formas de Manifestação
        • Considerações que um Analista deve ter em mente
      • Boas Práticas para o desenvolvimento de SW OO
    • 3. Actividades Básicas Independentes do Modelo de Processos
      • adaptáveis a qualquer modelo de processo
      • Exemplo que veremos na aula prática..
        • actividades do Modelo Espiral
          • Comunicação com o cliente
          • Planeamento
          • Análise do risco
          • Actividades de Engenharia
          • Construção e Entrega
          • Avaliação do Cliente
      Convém estabelecer um conjunto de actividades básicas para desenvolverem durante toda a semana Nas aulas práticas, faremos o ponto da situação.
    • 4. Espiral de Boehm Comunicação com o cliente Planeamento Engenharia Análise de riscos Construção e adaptação Avaliação do cliente
    • 5. Exemplo: Comunicação com o Cliente
      • Projecto pequeno
        • Desenvolver lista de aspectos a esclarecer
        • Reunião com o cliente
        • Determinar conjuntamente âmbito do projecto
        • Revisão do âmbito com todos os envolvidos
        • Modificar o âmbito quando requerido
      • Projecto complexo
        • Revisar pedido do cliente
        • Planear e programar reunião formal
        • Definir soluções propostas e enfoques existentes
        • Preparar documentos de trabalho e agenda reunião
        • Realizar reunião
        • Desenvolver conjuntamente mini-especificações que reflectem as características do software
        • Revisar mini-especificações
        • Integrar mini-especificações num documento de alcance do projecto
        • Revisar o documento de alcance
        • Modificar o documento de alcance quando requerido
    • 6. Selecção do modelo
      • Deve haver flexibilidade na escolha
      • Projectos pequenos: ciclo clássico
      • Limites severos de tempo: DRA
      • Data entrega muito próxima: modelo incremental
      Os modelos vistos até agora não são, por si só, suficientes para o sucesso de projectos baseados no Paradigma Orientado a Objectos
    • 7. Conceitos e Princípios OO
      • Quem define os objectos?
        • o Engenheiro de Software
      • O que implica a definição de objectos?
        • a descrição de:
          • Propriedades (atributos)
          • Comportamentos (Operações, Serviços ou Métodos)
          • Mensagens
      • Por que é importante?
        • porque os componentes de SW derivados do paradigma OO mostram características associadas com SW de alta qualidade
      • Independência Funcional, Ocultação de Informação, etc.
    • 8. Conceitos e Princípios OO
      • Quais são os passos?
        • AOO, DOO, Implementação e Testes
      • Qual é o produto obtido?
        • produz-se um conjunto de Modelos Orientados por Objectos
          • ou Diagramas, ou bonecos ;)
      • Estes diagramas descrevem o(s):
        • Requisitos (Documento de Especificação)
        • Desenho
        • Código
        • Processos de Testes
      … para o desenvolvimento de um Sistema ou Produto OO
    • 9. Conceitos e Princípios OO
      • Análise Orientada por Objectos
        • Especificação, Casos de Utilização, Diagrama de Classes e de Objectos
          • Identificam-se as Classes e Objectos relevantes no Domínio do Problema
      • Desenho OO
        • Diagramas de Interacção, de Actividades e de Estados
          • aqui descrevem-se detalhes sobre a arquitectura , as interfaces e os componentes
        • a implementação “transforma” o Desenho em Código
      • Testes OO
        • os testes corroboram a arquitectura, as interfaces e os componentes
      O software OO é mais fácil de manter porque sua estrutura é pouco acoplada – o que implica menos efeitos colaterais quando se fazem mudanças
    • 10. Casos de Desenvolvimento de SW
    • 11. Modelo de Processo OO (ou Modelo Recursivo-Paralelo)
      • O melhor paradigma deve ser um modelo evolutivo de processo acoplado com um enfoque que fomenta a reutilização
      • Nenhum dos outros modelos vistos pôde ser utilizado isoladamente com sucesso para a OO
      Identificar classes candidatas recursivo (modelo evolutivo) paralelo (reutilização de componentes) buscar classes na biblioteca extrair classes, se existem desenvolver novas classes, se não existem adicionar novas classes à biblioteca construir n-ésima iteração do sistema Análise de Riscos Engenharia e Construção
    • 12. Modelo Recursivo-Paralelo
      • Realizar a análise suficiente para isolar as classes do problema e as conexões mais importantes
      • Realizar um pequeno desenho para determinar se as classes e as conexões podem ser implementadas de maneira prática
      • Extrair objectos reutilizáveis de uma biblioteca para construir um protótipo prévio
      • Conduzir alguns testes para descobrir erros no protótipo
      • Obter retro-alimentação do cliente sobre o protótipo
      • Modificar o modelo de análise baseando-se na Análise , no Desenho e no Cliente
    • 13. Modelo Recursivo-Paralelo
      • Refinar o Desenho para acomodar as mudanças
      • Construir objectos especiais (não disponíveis na biblioteca)
      • Montar um novo protótipo usando
        • Objectos da biblioteca
        • Novos objectos
      • Realizar provas para descobrir erros
      • Obter retro-alimentação do cliente sobre o protótipo
      - Este enfoque continua até o protótipo evoluir para uma aplicação em produção!
    • 14. Sequencia típica de um Processo OO em termos de actividades para o Plano de Projecto OO planificação testes extrair classes reutilizáveis análise desenho protótipo análise desenho planificação análise desenho análises do cliente (…) testes classes reutilizáveis protótipo planificação análise desenho entrega ao cliente Revisão e Refinamento: revisões, avaliações do cliente e testes a cada incremento (…)
    • 15. Identificação de Classes e Objectos
      • Análise Sintáctica Gramática
        • Sublinhar os substantivos do texto
          • da narrativa do processo
          • ou da Descrição do Âmbito do Sistema
        • Descartar os sinónimos
      Um objecto nunca deve ser uma forma verbal!
    • 16. Identificação: Formas de Manifestação
      • Entidades externas (outros sistemas, pessoas)
        • que produzem ou consomem informação a ser usada pelo sistema
      • Coisas (cartas, apresentações, etc.)
        • que são parte do domínio de informação do problema
      • Ocorrências (acções que se repetem – ex. instalação)
        • que ocorrem dentro do contexto de uma operação do sistema
      • Papéis (director, engenheiro, vendedor, etc.)
        • desempenhados por pessoas que interagem com o sistema
    • 17. Identificação: Formas de Manifestação
      • Unidades Organizacionais (divisão, grupo, equipa)
        • Relevantes numa organização
      • Estruturas (sensores, veículos de 4 rodas, etc.)
        • que definem uma classe de objectos
          • ou classes relacionadas de objectos
      • Lugares (planta de produção, armazém de carga, etc.)
        • que estabelecem o contexto do problema e a função geral do sistema
    • 18. Identificação: Considerações para os Analistas
      • Como saber se um objecto deve ser incluído (ou não) no Modelo de Análise OO? – Perguntem-se:
        • A informação acerca dele deve ser lembra?
          • ou seja, é um objecto persistente ?
        • Possui operações identificáveis que podem mudar o valor dos seus atributos?
        • Possui atributos múltiplos?
          • ou somente um atributo?
        • Possui atributos comuns?
          • que são aplicáveis a todas as ocorrências do objecto
        • Possui operações comuns?
          • que são aplicáveis a todas as ocorrências do objecto
        • São entidades externas ?
          • que produzem ou consomem informação do sistema?
      Se qualquer uma das respostas for SIM, o objecto deve ser incluído no modelo
    • 19. Finalizando a identificação
      • Alguns objectos descartados serão atributos dos objectos seleccionados
      • Durante as iterações do Modelo de Processo OO (Modelo Recursivo-Paralelo) podem ser adicionados outros novos objectos
    • 20. Boas Práticas de Desenvolvimento OO
      • Alta Coesão
        • Os métodos tendem a manipular um número limitado de atributos
      • Baixo Acoplamento
        • A classe tem pouca comunicação com outros elementos do sistema porque a comunicação ocorre (internamente) somente através de métodos declarados
      • Polimorfismo
        • Permite que operações diferentes tenham o mesmo nome
          • Por exemplo: o método desenhar() para classes gráficas..
        • Reduz o acoplamento entre objectos tornando-os mais independentes
      • evitar Herança Múltipla
        • Pode dificultar a manutenção!
          • Em geral, complica a hierarquia da classe e cria problemas potenciais no controle da Configuração (veremos no projecto)
        • É mais coerente especializar (gerar) uma nova classe “filha”

    ×