Baixar para ler offline
Apresentação versão 1.5
- 1. Análise e Projeto Orientadosa Objetos Jhonny Freire Oliveira - 879107 8º Semestre de Sistemas de Informação
- 2. Sumário • Objetivo • O Paradigma da Orientação a Objetos • UML • Análise Orientada a Objetos • Projeto (Design) Orientado a Objetos
- 3. Objetivo Transmitir uma ideiabásica do desenvolvimento orientado a objetos. Apresentando técnicas adotadas por profissionais experientes na análise e projeto de softwares.
- 4. O PARADIGMA DA ORIENTAÇÃO A OBJETOS
- 5. Orientação a Objetos Émuito mais que apenas uma forma de organizar 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. Classes Na classe programador define quaissão os atributos e os métodos dos objetos criados a partir dela.
- 7. A classe épara o objeto o que uma planta é para a construção de uma casa.
- 8. Objetos Um objeto écomo uma casa construída através da especificação de uma planta. Podemos ter vários objetos de uma mesma classe.
- 9. Herança Possibilita reaproveitar uma estrutura já existenteque nos forneça uma base para o desenvolvimento, provendo recursos básicos e comuns.
- 10.
- 11. Encapsulamento Permite ocultar atributos e métodos de um objeto do mundo externo a ele.
- 12. Encapsulamento Não precisamos conhecer o funcionamento internode um caixa eletrônico para utilizá-lo.
- 13. Polimorfismo (poli = múltiplas , morfo = formas) É o ato de reescrever um método herdado da superclasse ou interface, mas mantendo-se a assinatura do método original.
- 14.
- 15. Classes Abstratas Algumas classespodem ter sido criadas tão genericamente para o uso da herança, que não faz sentido instanciá-las diretamente.
- 16. Métodos Abstratos Podemos criarmétodos genéricos apenas com a definição do que deve ser feito e não como ser feito.
- 17. Interfaces São como classesabstratas e com apenas métodos abstratos. A responsabilidade de implementar o código fica por conta da classe que implementa a interface.
- 18. Agregação As rodas fazemparte do contexto de carro, mas a existência do carro não depende das rodas, pois podemos trocá-las por outras em qualquer momento.
- 19. Composição O objeto Itemdo Pedido só tem sentido se fazer parte de um objeto Pedido.
- 20.
- 21. UML (Unified Modeling Language) Diversos diagramas que facilitam o entendimento entre desenvolvedores e clientes a respeito do sistema a ser desenvolvido.
- 22. DIAGRAMAS DE COMPORTAMENTO •Caso de Uso • Atividades • Máquina de Estado
- 23. DIAGRAMAS DE ESTRUTURA •Classes • Objetos • Componentes • Estrutura de Composição • Pacotes • Implantação
- 24. DIAGRAMAS DE INTERAÇÃO •Sequência • Comunicação • Tempo • Visão geral de Interação
- 25. ANÁLISE ORIENTADA A OBJETOS
- 26. Identificação de Classes Existemvárias técnicas para identificar classes, a mais comum é destacar os substantivos do texto que define o problema a ser resolvido pelo sistema.
- 27. Identificação de Classes “Nocadastro de usuários o administrador deve fornecer o nome completo, CPF, RG, sexo, endereço completo, telefones de contato, senha e email e o nível de usuário, o código de usuário é gerado automaticamente pelo sistema...”
- 28.
- 29.
- 30. Agregação e Composição Asassociações muitas vezes correspondem a verbos estáticos ou a locuções verbais como junto à, parte de, contido em, tem, parte de, trabalha para, casado com.
- 31.
- 32. Utilizando a Herança Top-Down Refinar classes existentes em subclasses mais especializadas. Bottom-Up Generalizar aspectos comuns das classes em uma superclasse.
- 33. PROJETO (DESIGN) ORIENTADOA OBJETOS
- 34. Acoplamento Quanto mais dependente de outras classes, mas acoplada a classe está.
- 35. Acoplamento Referenciar outras classes pela superclasseou pela interface favorece o baixo acoplamento.
- 36. Coesão Quanto menos responsabilidades, mais fácilde entender e manter o código de uma classe.
- 37. Coesão Muitas responsabilidades = Baixa coesão
- 38. Coesão Poucas responsabilidades = Alta coesão
- 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. Divisão do Sistema(Camadas)
- 41. Custo de Processamento Emtempos de cloud computing, quanto maior o consumo de processamento maior será o custo financeiro para o cliente.