1. Análise e Projeto
Orientados a 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 ideia bá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 quais sã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á
existente que nos
forneça uma base
para o
desenvolvimento,
provendo recursos
básicos e comuns.

10. Herança

11. Encapsulamento
Permite ocultar
atributos e
métodos de um
objeto do mundo
externo a ele.

12. Encapsulamento
Não precisamos
conhecer o
funcionamento
interno de 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. Polimorfismo

15. Classes Abstratas
Algumas classes podem
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 criar métodos
genéricos apenas com a
definição do que deve
ser feito e não como ser
feito.

17. Interfaces
Sã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.

18. 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.

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

20. UML

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
Existem vá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
“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...”

28. Eliminação de Classes

29. Agregação e Composição

30. Agregação e Composição
As 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.

31. Utilizando a Herança

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)
ORIENTADO A
OBJETOS

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

35. Acoplamento
Referenciar outras
classes pela
superclasse ou pela
interface favorece o
baixo acoplamento.

36. Coesão
Quanto menos
responsabilidades, mais
fácil de 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
Em tempos de cloud
computing, quanto maior o
consumo de processamento
maior será o custo financeiro
para o cliente.