41
Análise e Projeto Orientados a Objetos Jhonny Freire Oliveira - 879107 8º Semestre de Sistemas de Informação

Apresentação versão 1.5

Embed Size (px)

Citation preview

Page 1: Apresentação   versão 1.5

Análise e Projeto Orientados a Objetos

Jhonny Freire Oliveira - 8791078º Semestre de Sistemas de

Informação

Page 2: Apresentação   versão 1.5

Sumário• Objetivo• O Paradigma da Orientação a Objetos• UML• Análise Orientada a Objetos• Projeto (Design) Orientado a Objetos

Page 3: Apresentação   versão 1.5

ObjetivoTransmitir uma ideia básica do desenvolvimento orientado a objetos.

Apresentando técnicas adotadas por profissionais experientes na análise e projeto de softwares.

Page 4: Apresentação   versão 1.5

O PARADIGMA DA ORIENTAÇÃO

A OBJETOS

Page 5: Apresentação   versão 1.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.

Page 6: Apresentação   versão 1.5

ClassesNa classe programador define quais são os atributos e os métodos dos objetos criados a partir dela.

Page 7: Apresentação   versão 1.5

A classe é para o objeto o que uma planta é para a construção de uma casa.

Page 8: Apresentação   versão 1.5

Um objeto é como uma casa construída através da especificação de uma planta. Podemos ter vários objetos de uma mesma classe.

Objetos

Page 9: Apresentação   versão 1.5

HerançaPossibilita reaproveitar uma estrutura já existente que nos forneça uma base para o desenvolvimento, provendo recursos básicos e comuns.

Page 10: Apresentação   versão 1.5

Herança

Page 11: Apresentação   versão 1.5

EncapsulamentoPermite ocultar atributos e métodos de um objeto do mundo externo a ele.

Page 12: Apresentação   versão 1.5

EncapsulamentoNão precisamos conhecer o funcionamento interno de um caixa eletrônico para utilizá-lo.

Page 13: Apresentação   versão 1.5

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.

Page 14: Apresentação   versão 1.5

Polimorfismo

Page 15: Apresentação   versão 1.5

Classes AbstratasAlgumas classes podem ter sido criadas tão genericamente para o uso da herança, que não faz sentido instanciá-las diretamente.

Page 16: Apresentação   versão 1.5

Métodos Abstratos

Podemos criar métodos genéricos apenas com a definição do que deve ser feito e não como ser feito.

Page 17: Apresentação   versão 1.5

InterfacesSão como classes abstratas e com apenas métodos abstratos.A responsabilidade de implementar o código fica por conta da classe que implementa a interface.

Page 18: Apresentação   versão 1.5

Agregação

As rodas fazem parte do contexto de carro, mas a existência do carro não depende das rodas, pois podemos trocá-las por outras em qualquer momento.

Page 19: Apresentação   versão 1.5

ComposiçãoO objeto Item do Pedido só tem sentido se fazer parte de um objeto Pedido.

Page 20: Apresentação   versão 1.5

UML

Page 21: Apresentação   versão 1.5

UML(Unified Modeling Language)

Diversos diagramas que facilitam o entendimento entre desenvolvedores e clientes a respeito do sistema a ser desenvolvido.

Page 22: Apresentação   versão 1.5

DIAGRAMAS DE COMPORTAMENTO

• Caso de Uso• Atividades•Máquina de Estado

Page 23: Apresentação   versão 1.5

DIAGRAMAS DE ESTRUTURA

• Classes• Objetos• Componentes• Estrutura de Composição• Pacotes• Implantação

Page 24: Apresentação   versão 1.5

DIAGRAMAS DE INTERAÇÃO

• Sequência• Comunicação• Tempo• Visão geral de Interação

Page 25: Apresentação   versão 1.5

ANÁLISE ORIENTADA A

OBJETOS

Page 26: Apresentação   versão 1.5

Identificação de ClassesExistem várias técnicas para identificar classes, a mais comum é destacar os substantivos do texto que define o problema a ser resolvido pelo sistema.

Page 27: Apresentação   versão 1.5

Identificação de Classes“No cadastro 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...”

Page 28: Apresentação   versão 1.5

Eliminação de Classes

Page 29: Apresentação   versão 1.5

Agregação e Composição

Page 30: Apresentação   versão 1.5

Agregação e ComposiçãoAs associaçõ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.

Page 31: Apresentação   versão 1.5

Utilizando a Herança

Page 32: Apresentação   versão 1.5

Utilizando a Herança

Bottom-Up

Generalizar aspectos comuns das classes em uma superclasse.

Top-Down

Refinar classes existentes em subclasses mais especializadas.

Page 33: Apresentação   versão 1.5

PROJETO (DESIGN)

ORIENTADO A OBJETOS

Page 34: Apresentação   versão 1.5

Acoplamento

Quanto mais dependente de outras classes, mas acoplada a classe está.

Page 35: Apresentação   versão 1.5

AcoplamentoReferenciar outras classes pela superclasse ou pela interface favorece o baixo acoplamento.

Page 36: Apresentação   versão 1.5

CoesãoQuanto menos responsabilidades, mais fácil de entender e manter o código de uma classe.

Page 37: Apresentação   versão 1.5

Coesão

Muitas responsabilidades=

Baixa coesão

Page 38: Apresentação   versão 1.5

Coesão

Poucas responsabilidades

=Alta coesão

Page 39: Apresentação   versão 1.5

Divisão do Sistema (Camadas)

Dividir classes em grupos separados por algum critério facilita o baixo acoplamento e a alta coesão.

Page 40: Apresentação   versão 1.5

Divisão do Sistema (Camadas)

Page 41: Apresentação   versão 1.5

Custo de Processamento

Em tempos de cloud computing, quanto maior o consumo de processamento maior será o custo financeiro para o cliente.