Apresentação versão 1.5

340 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
340
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Apresentação versão 1.5

  1. 1. Análise e ProjetoOrientados a Objetos Jhonny Freire Oliveira - 879107 8º Semestre de Sistemas de Informação
  2. 2. Sumário• Objetivo• O Paradigma da Orientação a Objetos• UML• Análise Orientada a Objetos• Projeto (Design) Orientado a Objetos
  3. 3. ObjetivoTransmitir uma ideia básica dodesenvolvimento orientado a objetos. Apresentando técnicas adotadas por profissionais experientes na análise e projeto de softwares.
  4. 4. O PARADIGMADA ORIENTAÇÃO A OBJETOS
  5. 5. Orientação a ObjetosÉ muito mais que apenas uma forma deorganizar o código-fonte de um software. Trata-se de uma forma de abstrair o domínio e capturar sua estrutura em um modelo conceitual.
  6. 6. ClassesNa classeprogramadordefine quais sãoos atributos e osmétodos dosobjetos criados apartir dela.
  7. 7. A classe é para oobjeto o que umaplanta é para aconstrução deuma casa.
  8. 8. ObjetosUm objeto é como umacasa construída atravésda especificação de umaplanta. Podemos tervários objetos de umamesma classe.
  9. 9. HerançaPossibilitareaproveitar umaestrutura jáexistente que nosforneça uma basepara odesenvolvimento,provendo recursosbásicos e comuns.
  10. 10. Herança
  11. 11. Encapsulamento Permite ocultar atributos e métodos de um objeto do mundo externo a ele.
  12. 12. EncapsulamentoNão precisamosconhecer ofuncionamentointerno de um caixaeletrônico parautilizá-lo.
  13. 13. Polimorfismo (poli = múltiplas , morfo = formas)É o ato de reescrever um métodoherdado da superclasse ouinterface, mas mantendo-se aassinatura do método original.
  14. 14. Polimorfismo
  15. 15. Classes AbstratasAlgumas classes podemter sido criadas tãogenericamente para o usoda herança, que não fazsentido instanciá-lasdiretamente.
  16. 16. Métodos AbstratosPodemos criar métodosgenéricos apenas com adefinição do que deveser feito e não como serfeito.
  17. 17. InterfacesSão como classes abstratas ecom apenas métodos abstratos.A responsabilidade deimplementar o código fica porconta da classe que implementaa interface.
  18. 18. AgregaçãoAs rodas fazem parte do contexto de carro,mas a existência do carro não depende dasrodas, pois podemos trocá-las por outras emqualquer momento.
  19. 19. ComposiçãoO objeto Item do Pedido só temsentido se fazer parte de um objetoPedido.
  20. 20. UML
  21. 21. UML (Unified Modeling Language)Diversos diagramas que facilitamo entendimento entredesenvolvedores e clientes arespeito do sistema a serdesenvolvido.
  22. 22. DIAGRAMAS DE COMPORTAMENTO• Caso de Uso• Atividades• Máquina de Estado
  23. 23. DIAGRAMAS DE ESTRUTURA• Classes• Objetos• Componentes• Estrutura de Composição• Pacotes• Implantação
  24. 24. DIAGRAMAS DE INTERAÇÃO• Sequência• Comunicação• Tempo• Visão geral de Interação
  25. 25. ANÁLISEORIENTADA A OBJETOS
  26. 26. Identificação de ClassesExistem várias técnicas paraidentificar classes, a maiscomum é destacar ossubstantivos do texto quedefine o problema a serresolvido pelo sistema.
  27. 27. Identificação de Classes“No cadastro de usuários oadministrador deve fornecer onome completo, CPF, RG, sexo,endereço completo,telefones de contato, senha e email eo nível de usuário, o código deusuário é gerado automaticamentepelo sistema...”
  28. 28. Eliminação de Classes
  29. 29. Agregação e Composição
  30. 30. Agregação e ComposiçãoAs associações muitas vezescorrespondem a verbos estáticosou a locuções verbais como juntoà, parte de, contido em, tem,parte de, trabalha para, casadocom.
  31. 31. Utilizando a Herança
  32. 32. Utilizando a Herança Top-Down Refinar classes existentes em subclasses mais especializadas. Bottom-UpGeneralizar aspectoscomuns das classesem uma superclasse.
  33. 33. PROJETO (DESIGN)ORIENTADO A OBJETOS
  34. 34. Acoplamento Quanto mais dependente de outras classes, mas acoplada a classe está.
  35. 35. AcoplamentoReferenciar outrasclasses pelasuperclasse ou pelainterface favorece obaixo acoplamento.
  36. 36. CoesãoQuanto menosresponsabilidades, maisfácil de entender emanter o código deuma classe.
  37. 37. CoesãoMuitas responsabilidades = Baixa coesão
  38. 38. Coesão Poucas responsabilidades = Alta coesão
  39. 39. Divisão do Sistema (Camadas) Dividir classes em grupos separados por algum critério facilita o baixo acoplamento e a alta coesão.
  40. 40. Divisão do Sistema (Camadas)
  41. 41. Custo de ProcessamentoEm tempos de cloudcomputing, quanto maior oconsumo de processamentomaior será o custo financeiropara o cliente.

×