Paradigma de Orientação a Objetos

Prof. Dr. Juliano Lopes de Oliveira

Estratégia Tecnologia da Informação Ltda
Instituto de Informática - UFG

[Link] [Link]/~juliano

juliano@ [Link] juliano@[Link]

Agenda

Visão geral do paradigma orientado a objetos
ִOrigens e aplicações: Linguagens; BD; IA; ...

Princípios do paradigma
ִObjeto; encapsulação; interface; herança; ...

Representação de conceitos com o paradigma
ִClassificação; composição; associação; ...

Mecanismos essenciais do paradigma
ִHerança e Polimorfismo
ִSuporte para persistência, concorrência e distribuição

Desenvolvimento de software OO
ִCiclo de vida e métodos OO

1
O Paradigma de Orientação a Objetos

Paradigma: [Aurélio, 1998]

[Do gr. parádeigma, pelo lat. paradigma]. S. m.
1. Modelo, padrão; 2. Aquilo que serve de exemplo ou
norma; 3. Aquilo que serve de base para a avaliação de
qualidade ou quantidade

Paradigma OO:
conjunto de princípios computacionais (conceitos,
técnicas, métodos, ...) que definem a base comum e o
conjunto de características essenciais da abordagem e
dos sistemas Orientados a Objetos
2

Origens do Paradigma OO

Não há uma única origem ou um único autor

O paradigma é formado por idéias surgidas em
diferentes tempos e em diversas áreas de
conhecimento
ִLinguagens de Programação
ִEngenharia de Software
ִInteligência Artificial
ִBancos de Dados
3

2
Origens do Paradigma OO

Linguagens de Programação e Eng. de Software

ִExemplo de Contribuição: Tipo Abstrato de Dados
Encapsula estrutura de dados e comportamento,
separando especificação de implementação
Permite reutilizar a especificação sem conhecer a
implementação
Exemplo: TAD Pilha Lógica
• Especifica operações: create, pop, push, ...
• Implementação é “visível” apenas para o projetista do TAD: usa
lista simples, lista dupla, vetor, ...

Origens do Paradigma OO

Bancos de Dados e Inteligência Artificial

ִExemplo de Contribuição: Modelos Semânticos
de Dados
Capturam e representam um domínio de aplicação (e
não simplesmente sua solução computacional)
Provêem abstrações apropriadas
• classificação; generalização; especialização; composição; ...
Exemplo: Modelo de Dados ER estendido
• Permite modelagem estrutural de conhecimento

3
Aplicações de Orientação a Objetos

Algumas áreas que usam o paradigma OO

ִLinguagens de programação
ִModelagem de dados e SGBD
ִInterfaces de usuário e Sistemas Operacionais
ִProcessamento Distribuído Aberto (ODP)
ִGerência de Redes (TMN) e Protocolos de
Comunicação
ִEngenharia de Software

Aplicações de Orientação a Objetos

Linguagens de Programação
ִSimula, Smalltalk, Ada, Eiffel, C++, Java
O POO é utilizado como base das principais
construções dessas linguagens

CASE e Ambientes de Desenvolvimento
ִVisual Basic, Delphi, Rose, Poseidon
Usam o POO como base para modelagem e
implementação de software

4
Aplicações de Orientação a Objetos

SGBD OO
ִO2, GemStone, Versant, ObjectStore, Ontos,
Itasca, Matisse, Objectivity, Poet, Caché

SGBD Objeto-Relacional
ִPostgreSQL, Oracle (>v8), Illustra
Em breve todos os grandes SGBD relacionais se
tornarão objeto-relacionais

O modelo de dados OO é a base desses SGBD

Aplicações de Orientação a Objetos

Sistemas Operacionais e Interfaces de usuário

ִWindows, MacOS, Linux
ִTodos os principais Sistemas operacionais
possuem interfaces gráficas baseadas no POO
Seleção de objeto e envio de mensagem
ִTodos os principais IDE (ambientes de
desenvolvimento de interface) adotam o POO
Visual Basic, Delphi, Jbuilder, NetBeans

5
Aplicações de Orientação a Objetos

Processamento Distribuído Aberto (ODP)

ִCorba, Java RMI, [Link]
ִTodos as principais arquiteturas para
processamento distribuído estão baseadas no POO
Transparência de localização de objeto
ִTodos os principais protocolos de comunicação
adotam algum princípio do POO
IP, HTTP, TMN

10

Aplicações de Orientação a Objetos

Engenharia de Software
ִUML, RUP, Java, Use Cases, Component Based
Design, Agentes Inteligentes, Business Modeling,
Design Patterns, Frameworks, ...
ִTodos os principais processos, métodos, técnicas
e ferramentas que têm sido propostos e adotados
na Engenharia de Software seguem o POO

11

6
Fundamentos do Paradigma OO

Não existe definição formal e universal

Existem, no entanto, conceitos e características que
estão presentes em diversas abordagens OO

O objeto é o conceito fundamental, incluindo
identidade e propriedades de objeto
encapsulação de estrutura e comportamento
conjunto de abstrações para modelagem
mecanismos de herança e de comunicação

12

Definição de Objeto

É uma representação de um conceito existente
em um determinado Contexto de Modelagem
ִUm objeto pode representar um conceito
Concreto:
• um carro é uma entidade que tem cor, ano, marca, modelo,
proprietário, ...
Abstrato:
• um projeto é uma entidade que envolve cronograma, equipe,
líder, objetivos, orçamento, ...

13

7
Propriedades de Objeto

Um objeto possui quatro tipos de propriedades

ִAtributos que o caracterizam
• cor, ano, marca, modelo, ...
ִAssociações que o relacionam com outros objetos
• proprietário (associação com um objeto Pessoa), ...
ִComportamentos que ele pode realizar
• manter(velocidade); ir_para_frente(marcha); marcha_ré();
virar(direção, ângulo); travar_portas(); parar(); ...
ִRegras que ele deve obedecer
• se em_movimento então travar_portas();
14

Características de Objeto

As propriedades podem ser separadas em

ִEstrutura do Objeto: atributos e associações
ִComportamento do Objeto: operações e regras
ִEstas propriedades estabelecem características
que o objeto é capaz de
lembrar: atributos
conhecer: associações
realizar: operações
manter: regras
15

8
Estado de Objeto

O Estado de um objeto é o conjunto de valores

de suas propriedades
ִvalores dos atributos, identidade dos objetos
associados, algoritmos dos métodos, e definição
das regras
Certos autores consideram que o Estado do Objeto se
limita apenas ao conjunto de valores para sua estrutura
(atributos e associações)
• cor: vermelho; ano:1999; marca: Ferrari; modelo: F-44;
proprietário: Sr. Rico; ...

16

Identidade de Objeto

Todo objeto possui um Identificador (OID)

ִO OID é um atributo implícito de todo objeto
É gerado pelo sistema na criação do objeto
• O projetista não tem acesso à definição do OID do objeto
• É diferente do conceito de chave: mudar nome, sexo ou CPF
não muda a pessoa
ִO OID é imutável
Após sua criação um OID nunca pode ser modificado
ִO OID é único em um sistema OO
O sistema nunca gera o mesmo OID para dois objetos
17

9
Encapsulação de Objeto

Cápsula: [Aurélio, 1998]

[Do lat. capsula]. S. f.
membrana que reveste uma substância
ִNo paradigma OO é uma membrana opaca e
indestrutível que isola e protege o objeto
Todo objeto está em uma cápsula
• Por isso diz-se que o objeto está encapsulado
ִAplicação do princípio de Information Hiding
Quanto mais isolado o conceito, menor o impacto de
sua mudança no restante do contexto
18

Interface e Implementação de Objeto

A encapsulação é o principal conceito OO

pois “protege” o objeto do restante do sistema
ִPorém, a cápsula (opaca e indestrutível) impede
que o objeto interaja com o mundo exterior
ִSolução: dividir o objeto em duas partes
Interface: não encapsulada
• Permite a interação do objeto com o sistema
Implementação: encapsulada
• Isola a essência do objeto do restante do sistema

19

10
Interface e Operações de Objeto

A interface define o comportamento

externamente visível através de operações
ִUma operação é definida por uma assinatura
Nome da operação + Tipos dos parâmetros de entrada
+ Tipos dos parâmetros de saída
• Por exemplo, a assinatura: ir_em_frente (IN marcha int, OUT
marcha_atual int) define uma operação do objeto Carro que
solicita que ele se desloque para frente
• A operação tem como parâmetro de entrada a marcha a ser
empregada no deslocamento, e retorna a marcha em uso no
momento da solicitação da operação
20

Interface e Responsabilidades de Objeto

A interface permite interação disciplinada e

controlada, descrevendo o comportamento
externamente visível do objeto
ִCertos autores admitem que a interface também
contenha regras, atributos e associações
A interface estabelece as responsabilidades do objeto
• Responsabilidade de lembrar: atributos
• Responsabilidade de conhecer: associações
• Responsabilidade de realizar: operações
• Responsabilidade de ser coerente: regras
21

11
Implementação de Objeto

isola e protege a essência do objeto, ou seja, o

estado do objeto
ִcontém todas as definições do comportamento
corpos de métodos e regras
ִcontém todas as definições da estrutura
descrição e valores dos atributos e associações

provê independência de dados e de funções
Mudanças na implementação de um objeto não são
propagadas para o sistema, se a interface for mantida
22

Método e Operação de Objeto

ambas as definições estão associadas ao

comportamento do objeto
ִmétodos e regras implementam o comportamento
definido pelas operações da interface
realizam de fato as atividades definidas nas operações
ִHá métodos e regras que são internos ao objeto
realizam funções de manutenção interna do objeto que
não são externamente visíveis
• Toda operação tem método, mas não vice-versa

23

12
Níveis de Encapsulação

Linha de código: nível 0
ִAusência de encapsulação

Módulo ou subrotina: nível 1
ִum termo para se referir a um grupo de linhas

Objeto: nível 2
ִdados e funções agrupados em um único conceito

Pacote: nível 3
ִgrupo de classes de um mesmo nível de abstração
classes não necessariamente interagem

Componente ou framework: nível 4
ִclasses de diversos níveis interagem para compor uma
solução reutilizável para um certo domínio de problema 24

Protocolo de Comunicação OO

Objetos se comunicam exclusivamente através

de intercâmbio de mensagens
ִA mensagem contém uma assinatura de operação
é uma solicitação de um objeto (cliente) para execução
de uma operação da interface de um objeto (servidor)
• métodos são encapsulados, logo não podem ser invocados
O servidor recebe a mensagem e tenta casar a
assinatura da mensagem com a de uma de suas
operações
• Se isto for possível ele escolhe o método a executar, portanto o
cliente não controla que método é executado
25

13
Execução da Comunicação entre Objetos

Uma mensagem é enviada por um método do objeto

cliente e transportada pelo sistema OO até a interface
do objeto servidor
• O protocolo de comunicação OO exige mecanismos de tempo-
de-execução para identificação e localização do servidor

Interface
Operação(parâmetros) Interface
Implementação Implementação

Cliente Resposta
Servidor

26

Iniciativa de Comunicação OO

Objetos podem ter dois papéis

Objetos ativos tomam a iniciativa da comunicação
Objetos passivos somente respondem
• Em sistemas de objetos homogêneos, qualquer objeto pode ser
ativo (cliente) ou passivo (servidor) em diferentes interações

A única maneira de ativar um método é

enviando uma mensagem para um objeto
há um problema: como começar a comunicação?
– Em geral isto é feito via estímulo externo ou via um
objeto “principal” definido pelo sistema

27

14
Mecanismo de Resposta

Síncrono: resposta obrigatória (embutida)

Interface
Operação(parâmetros) Interface
Implementação Resposta Implementação

Assíncrono: resposta opcional (via mensagem)

Interface
Operação(parâmetros) Interface
Implementação Implementação
Operação(Resposta)

28

Categorias de Mensagens

Há três categorias de mensagens OO

ִO mecanismo de tempo-de-execução OO deve
identificar e localizar os destinatários
ponto-a-ponto: há um único destinatário, identificado
pelo seu OID
broadcast: a mensagem vai para todos os objetos do
sistema, sem que o emissor os identifique
multicast: há um grupo de destinatários, identificados
pelos seus OIDs
ִExiste sempre um único emissor da mensagem
29

15
Comunicações Complexas

ִCom os tipos básicos é possível construir sistemas

de comunicação complexos
Ex.: broadcast síncrono com resposta ponto-a-ponto

Interface Operação(parâmetros)

Implementação Barramento Virtual

do Sistema de
Execução OO

Objeto 1 Objeto 2 Objeto N

30

Conceitos Subjacentes à Comunicação OO

Delegação de funções
ִredirecionamento de responsabilidades

Distribuição de objetos
ִtransparência de localização = ODP

Concorrência inter e intra objetos
ִobjetos e sistemas de objetos multi-thread
sincronismo embutido no intercâmbio de mensagens

Suporte a tempo-real
ִmecanismo de prioridade de mensagens 31

16
O Conceito de Abstração

Abstração: [Aurélio, 1998] S. f.
Ato de separar um ou mais elementos de uma
totalidade complexa (coisa, representação, fato), os
quais só mentalmente podem subsistir fora dessa
totalidade
Uma abstração permite capturar um determinado
aspecto existente em uma realidade, eliminando
detalhes irrelevantes
Cada tipo de abstração representa fielmente o seu
aspecto alvo, de acordo com um significado predefinido
• Exemplo: a taxonomia é uma abstração que permite identificar
propriedades que caracterizam um certo conjunto de conceitos
32

Abstrações do paradigma OO

As Abstrações OO
Permitem

ִidentificar e compor
ִClassificação objetos complexos
ִInstanciação ִConstruir estruturas para
ִIdentificação organizar objetos
ִCompartilhar e reutilizar
ִAssociação propriedades
ִComposição ִRelacionar e agrupar
conjuntos de entidades
ִAgregação
ִRedefinir, especializar e
ִGeneralização generalizar conceitos
ִEspecialização 33

17
Classificação

Reúne as propriedades comuns a um conjunto

de objetos
ִAbstrai todas as características que não são
compartilhadas por todos os objetos considerados
ִExemplo: a classe jornal define propriedades
comuns aos objetos “O Popular”, “Diário da
Manhã”, ...

O resultado da aplicação da abstração de
Classificação sobre um conjunto de objetos é uma
Classe de Objetos 34

Instanciação

Cria instâncias distintas a partir de uma classe
ִInstâncias são objetos e possuem todas as
propriedades de sua classe
Ex: Folha de São Paulo é uma instância da classe
Jornal
• compartilha todas as propriedades da classe Jornal com os
demais objetos desta classe
• define um estado particular (valores) para essas propriedades
ִUma instância é o resultado da aplicação da
abstração de instanciação sobre uma Classe de
Objetos
é uma maneira de criar objetos, mas não a única
maneira 35

18
Criação de Instâncias via Classe

ִO empacotamento de definições em uma Classe

permite a sua reutilização via instanciação
uma instância provê valores para as propriedades
definidas na classe
ִA criação de instâncias pode ser
estática: todos os objetos são definidos em tempo de
compilação
dinâmica: os objetos podem ser criados em tempo de
execução
• requer suporte: alocação/desalocação, garbage collection, ...

36

Criação de Instâncias via Objeto

ִA instanciação de Classe não é a única maneira de se

criar objetos
ִUm Objeto Prototípico (ou simplesmente Protótipo)
é um modelo para criar outros objetos
Evita a proliferação de classes em sistemas em que
• objetos evoluem rápida e continuamente
• instâncias possuem mais diferenças que semelhanças
Um objeto é criado e reutiliza as definições de um ou mais
objetos prototípicos

37

19
Identificação

Permite distinguir as instâncias de uma classe

Pode ser feita com base no estado do objeto
Ex: a instância da classe Jornal cujo valor para o
atributo nome é “Folha de São Paulo”

Porém, o paradigma OO não exige que o
estado de um objeto seja único em sua classe!
Pode haver duas instâncias da classe Jornal cujo valor
do atributo nome é Folha de São Paulo
ִDuas instâncias podem ser idênticas (mesmo
OID) ou iguais (mesmo estado)
38

Associação

Estabelece uma correlação entre conceitos
ִEx.: o objeto OPopular, da classe Jornal, está
associado ao objeto Gráfica J.Câmara, da classe
Editora
ִObjetos específicos são abstraídos, permanecendo
a associação entre as Classes de Objetos
envolvidos
Ex.: todo objeto da classe Jornal deve estar associado a
um objeto da classe Editora
• Diferença entre Ligação e Associação

39

20
Composição

ִPermite a definição de um conceito complexo a

partir da combinação de conceitos mais simples
as propriedades de um objeto resultam da aplicação da
abstração de composição sobre um conjunto de
atributos, associações e comportamentos
ִComposição pode ser recursiva
a estrutura de um objeto pode ser definida em termos
de estruturas de objetos mais simples
• A estrutura da classe Jornal é uma composição das
propriedades: nome, tiragem, data de fundação, editora, ...

40

Objetos Complexos

Um objeto pode ser composto por outros objetos,

usando uma combinação arbitrária e recursiva de
construtores de tipo: tupla, lista, conjunto, bag
ִNão viola a encapsulação dos sub-objetos
ִCompartilhamento sem redundância via OID
ִSemântica Parte-Todo, com variações
composição simples (sub-objetos independentes) ou agregação
(sub-objetos não existem fora da composição)
componentes com um (composição física) ou vários (composição
de cátalogo) compositores

41

21
Agregação

ִEstabelece uma relação do tipo Parte-Todo entre

conceitos
um conceito representa o Todo, definindo uma
agregação de elementos
os demais conceitos representam as Partes, ou seja, os
componentes da agregação
ִa união dos componentes (partes) constitui o
conceito definido na agregação (todo)
• A página de um jornal é uma agregação de cabeçalho, corpo e
rodapé

42

Especialização

Permite refinamento de conceitos

ִA especialização de um conceito deve ser
compatível com o conceito original
ִA aplicação da abstração de Especialização
origina uma subclasse
A subclasse pode tornar mais específica cada definição
feita na classe original
• A Edição de Domingo é uma especialização da Edição Padrão
de um jornal.

43

22
Generalização

Permite abstrair diferenças entre classes de

objetos
ִAs propriedades comuns são sintetizadas em uma
única superclasse
ִO significado da abstração de generalização é
exatamente o oposto da abstração de
especialização
• A superclasse Edição representa o conceito genérico,
eliminando particularidades das edições de Domingo.

44

Estrutura de um Sistema OO

A estrutura dos objetos em Sistemas OO busca

refletir fielmente a maneira como os conceitos
se relacionam na realidade modelada
ִHierarquia de Generalização/Especialização
Superclasses e Subclasses
ִGrafo (e não hierarquia) de Composição
Objetos Complexos e Objetos Simples
ִAssociações genéricas
Relacionamentos entre Objetos
45

23
Classe de Objetos
ִMecanismo para reutilização de
implementação
as propriedades (estrutura e comportamento)
de objetos de uma classe são definidas uma
única vez, na classe, e não para cada objeto
ִClasse é fábrica e armazém de objetos
Classes podem ser consideradas meta-objetos
• Atributos de classe: quantidade de instâncias, ...
• Métodos de classe: criação de instância, ...
• Em sistemas OO “puros”, a classe é um objeto
46

Superclasse e Subclasse

A especialização/generalização origina um
relacionamento do tipo É-Um entre classes
ִMecanismo para reutilização de projeto
a subclasse reutiliza as soluções da superclasse
ִMecanismo para estruturação do sistema
Hierarquia de especialização
• a especialização não pode ser recursiva
• Super e Subclasse não são definições absolutas, mas papéis de
uma classe numa especialização
• Um objeto é instância de sua classe e membro de todas as suas
superclasses
47

24
Herança

É um mecanismo de reutilização
ִUm “cliente de herança” reutiliza (herda)
definições de um “servidor de herança”
Não deve ser confundida com Especialização!
ִHá várias taxonomias de herança
quanto à escolha das propriedades a reutilizar
quanto ao número de servidores
quanto ao tipo de servidor
quanto ao momento em que a reutilização pode ocorrer
48

Herança Total ou Parcial

Essa taxonomia de herança define a escolha

das propriedades que serão herdadas

Na Herança Total
ִTodas as propriedades do servidor são reutilizadas
pelo cliente da herança, de modo obrigatório

Na Herança Parcial
ִÉ permitido ao cliente escolher as propriedades
que deseja reutilizar
ִPode dificultar o entendimento do sistema
49

25
Herança Simples ou Múltipla

Define o número de servidores diretos da herança
ִNa Herança Simples um único servidor é a fonte direta das
propriedades a serem reutilizadas
pode haver servidores indiretos na hierarquia de
generalização
ִNa Herança Múltipla muitos servidores contribuem com
propriedades que o cliente reutiliza
Pode gerar conflito de nomes
• resolução pelo sistema (regra default)
• resolução pelo projetista (escolha explícita)

50

Herança de Classe ou de Objeto

Define o tipo de servidor da herança

Na herança de Classe o servidor é uma classe
ִA implementação mais comum é a baseada em
especialização total de classe
Outras abordagens são possíveis. Ex: C++ permite
herança parcial, sem criar subclasse

Na herança de Objeto o servidor é um objeto
ִÉ o caso de objeto prototípico
Permite herdar propriedades e estado (valores)
51

26
Herança Estática ou Dinâmica

Define o tempo em que a herança é resolvida

ִHerança Estática: todos os aspectos de reutilização são
conhecidos em tempo de compilação
ִHerança Dinâmica: a interação entre objetos leva a
mudanças de propriedades em tempo de execução
ִVariações
De parte: herança parcial de métodos transmitidos via mensagem
De escopo: objeto varia seu comportamento de acordo com o
contexto

52

Herança de Classe por Especialização

É o padrão de facto para uso de herança

A subclasse reutiliza todas as propriedades de
todas as suas superclasses
ִEm geral, Simples: evita conflitos de nomes
ִSempre Total (proíbe supressão de propriedades)
ִcom Substituição (permite substituir propriedades,
mantendo a compatibilidade com a superclasse)
ִcom Inclusão: permite incluir novas propriedades
na subclasse
53

27
Questões sobre Herança

Herança viola encapsulação!
ִCliente não deve usar o conhecimento herdado
ִAcesso via interface do servidor da herança

Evolução de Esquema é potencialmente perigosa!
ִEsta evolução não é herança dinâmica (a mudança de
comportamento não decorre da interação entre objetos)
ִMudança em servidor de herança é propagada para todos
os clientes
Pode afetar a compatibilidade das substituições, mesmo que o
cliente da herança respeite a encapsulação

54

Mecanismos de reutilização
ִClassificados quanto
ao momento de definição: estático ou dinâmico
ao tipo de declaração: implícito ou explícito
ao cliente do mecanismo: objeto ou grupo de objetos
ִAbordagem Template: Classe e Herança
objetos são criados pela fôrma da classe da qual reutilizam
(estaticamente) as definições de propriedades, as quais podem ser
redefinidas (implicitamente) via subclasse (cliente da reutilização é
o grupo de objetos)
ִAbordagem Empatia: Protótipo e Delegação
objetos são criados à imagem de um objeto protótipo. e reutilizam
(dinamicamente) propriedades pela delegação (explícita) de tarefas
(cliente da reutilização é cada objeto)
55

28
Polimorfismo

Um sistema computacional é polimórfico se

ִa mesma função
ִpode ter implementações distintas
ִquando aplicada a diferentes tipos de dados
Ex.: a função +
• aplicada a dois números produz a soma
• aplicada a dois strings produz a concatenação
Em Linguagens de Programação o polimorfismo é
também chamado de operation overloading
(sobreposição de operações)
56

Polimorfismo em Sistemas OO

Um sistema OO é polimórfico se

ִa mesma operação pode ter comportamentos distintos
quando aplicada a diferentes objetos
Ex.: a operação display aplicada a um objeto texto produz a
apresentação de um texto e aplicada sobre um objeto gráfico
produz uma saída gráfica
ִO polimorfismo verdadeiro mantém a semântica da
operação; o polimorfismo ad hoc é uma mera coincidência
de nomes
Ex: abrir sobre janela e arquivo têm semânticas diferentes
Isto deve ser evitado: pode causar dificuldade de entendimento!

57

29
Polimorfismo Intra Objeto: falso polimorfismo

ִa mesma operação pode ter comportamentos distintos

quando aplicada ao mesmo objeto com diferentes
argumentos
Ex.: a operação display de um objeto pode ter como argumento o
dispositivo de apresentação
a apresentação gerada será diferente para dispositivos de tipos
diferentes (tela e impressora, por exemplo)
ִo polimorfismo só ocorre se a assinatura for idêntica
nome da operação; tipos dos argumentos; e tipo de retorno (este
último é desconsiderado pelo mecanismo de polimorfismo)
o método deve ativar o comportamento polimórfico de acordo com
os valores dos argumentos

58

Polimorfismo e Herança

Polimorfismo permite redefinição de
comportamento herdado
ִisto contribui para a flexibilidade e adaptabilidade
um novo objeto pode ser introduzido para realizar todo
o comportamento do objeto existente (por herança),
adaptando partes desse comportamento a uma nova
realidade (por polimorfismo)
ִtanto o comportamento antigo quanto o novo
podem conviver simultaneamente no Sistema OO

59

30
Polimorfismo e Herança de Classe

É o padrão de facto para reutilização e refinamento de

comportamento em Sistemas OO
ִA Superclasse define o comportamento genérico
Cada subclasse herda esse comportamento e pode implementar seus
próprios métodos, redefinindo o comportamento herdado
ִO sistema deve selecionar o método a ser executado de acordo
com a classe do objeto que recebeu a mensagem
Ex.: a mensagem Desenha( ) pode ser enviada para objetos da
superclasse Figura ou para objetos das subclasses Polígono e Círculo
Um membro (instância de uma subclasse) sempre pode ser usado no
lugar de uma instância

60

Polimorfismo e Ligação Adiada

Para oferecer polimorfismo, em geral, é

preciso prover ligação adiada (late binding)
Ex.: ao invocar a operação Desenha() sobre uma
variável, só em tempo de execução pode-se saber se ela
contém uma instância ou um membro de Figura
ִo método a ser executado só é definido em tempo
de execução
o próprio sistema seleciona o método adequado
Este mecanismo também é conhecido como ligação
dinâmica (dynamic binding)
61

31
Suporte de Tempo de Execução OO

Nomeação e persistência de objetos
ִOID, indexação, estruturas de armazenamento, cluster de
objeto, acesso ao “dicionário de objetos”

Concorrência e criação dinâmica
ִsincronização de comunicações, coleta de lixo, mensagens
prioritárias (tempo real), polimorfismo (ligação dinâmica),
transações, tratamento de exceções

Distribuição e replicação
ִtransparência de localização, controle de versões e
réplicas, evolução de esquema, recuperação de falhas

62

Persistência de Objetos

ִObjetos transientes morrem com sua aplicação

ִObjetos persistentes permanecem após a
execução do programa que os criou
Sistemas convencionais oferecem persistência de
dados usando sistemas de BD ou arquivos
Em Sistemas OO esta solução envolve a Linearização
de objetos
• É um processo potencialmente caro
• SGBDs OO oferecem soluções eficientes
• uma classe pode conter objetos persistentes e transientes

63

32
SGBD OO
ִPrecisam oferecer todos os serviços de SGBD
tradicionais
transações, persistência, distribuição, recuperação de falhas, ...
ִPrecisariam prover todos os mecanismos de tempo de
execução OO, mas ainda não o fazem com eficiência
nomeação de objetos distribuída, evolução de esquema, ...
ִDificuldades adicionais
ausência de modelo de dados e linguagem padronizadas
(ODMG/OQL é uma proposta)
ausência de diretivas de projeto (“normalização” OO)
64

Ambiente de Desenvolvimento OO
ִPrecisariam oferecer todas as facilidades dos CASE
tradicionais
gerência de configuração, referências cruzadas, ...
ִPrecisariam prover suporte para métodos de projeto OO,
mas se limitam ao suporte à programação OO
o ambiente deveria guiar o desenvolvedor no processo de
estruturação do software OO: escolha de objetos, interfaces, ...
ִDificuldades adicionais
selecionar elementos para reutilização em bases de objetos que
evoluem constantemente
propagação de atualizações nas bases de reutilização

65

33
Teoria e Prática de Desenvolvimento OO

Ciclos de vida tradicionais adotam uma

separação rígida entre etapas
ִNa prática, observa-se que o processo de
desenvolvimento é iterativo e interativo

Métodos de desenvolvimento tradicionais
enfatizam a decomposição funcional
ִNa prática, comprova-se que a estrutura mais
estável é a dos dados, não a das funções

66

Características dos métodos OO

Adotam ciclo de vida interativo e iterativo

ִsem separação rigorosa entre fases

Organizam o software em torno de objetos
ִdados e funções são integrados
ִO sistema é um conjunto de objetos interagindo

Enfatizam a encapsulação
ִdados e comportamento são ocultos no objeto
ִInterfaces bem definidas entre objetos
67

34
Processo de Desenvolvimento OO

Um sistema OO
ִnão é um conjunto de funções!
ִum conjunto de objetos interagindo em uma
arquitetura cliente/servidor

Análise e Projeto de alto nível determinam
ִserviços oferecidos e protocolo de comunicação

Projeto detalhado inclui
ִespecificação de estruturas e algoritmos
68

Processo de Desenvolvimento OO

Análise e Projeto de alto nível (top-down)

ִrealizados de forma concorrente e iterativa
baseados em um conjunto uniforme de modelos

Projeto detalhado (bottom-up)
ִpostergado para o final do ciclo de vida
Não é o final do processo (ciclo de vida iterativo)
ִfeito para cada objeto (information hiding)
implementação segue diretamente (middle-out)

69

35
Conseqüências da Abordagem OO

ִProcessos e estruturas não são “congelados”

flexibilidade e capacidade de adaptação
ִModificações não geram mudanças estruturais
encapsulação evita “efeito dominó”
ִDesenvolvimento com Tipos Abstratos (TADs)
independência de estruturas e procedimentos
ִRepresentação do espaço do problema
ausência de mapeamentos entre análise e projeto
rastreabilidade
70

Reutilização em Desenvolvimento OO

O ciclo de vida OO visa atingir reutilização

ִA idéia é gastar mais esforço em desenvolvimento
e menos em manutenção
biblioteca de classes e padrões de projeto representam
esforço adicional de desenvolvimento
ִO ganho em reuso e manutenibilidade é
compensador!
Soluções são reaproveitadas (biblioteca e padrões)
Efeitos colaterais são controlados (encapsulação)

71

36
Fatoração no Desenvolvimento OO

O projeto tradicional é monolítico

ִFeito de uma vez, no início do ciclo de vida, com
pouco conhecimento sobre o problema

O desenvolvimento OO é fatorado
ִO sistema final é sintetizado a partir de
componentes desenvolvidos isoladamente
Partes do sistema podem estar prontas (biblioteca),
outras partes em projeto e outras em implementação

72

Desenvolvimento OO é a Solução?

O paradigma OO tem potencial, mas não é

uma panacéia!
ִDeve ser usado de maneira metódica para
alcançar os objetivos esperados
reutilização
manutenibilidade e flexibilidade para adaptação
encapsulação de informação (information hiding)
desenvolvimento iterativo e incremental
uniformidade e representatividade de modelos, ...

73

37
Projeto OO

ִEnfoque bottom-up
detalha as propriedades de cada objeto
ִEnfoque top-down
estrutura: composição, associação e especialização
comunicação: interações em serviços complexos
ִFase inicial do projeto
identificar classes que modelam a realidade
distribuir o comportamento entre as classes
determinar colaborações entre componentes

74

Projeto OO

Refinamento
ִfatorar e estruturar propriedades
hierarquias de herança
ִdeterminar protocolos de comunicação
consolidar interfaces de classes e componentes
ִidentificar classes Concretas e Abstratas
• Classe abstrata não é instanciada, mas especializada
– define atributos e métodos básicos (herança)
– mecanismo de especificação de outras classes
• Classe concreta é instanciada em objetos
– reutilização por instanciação, não por herança 75

38
Frameworks Orientados a Objetos

A longo prazo, reuso de projeto é mais

importante que reuso de código
ִClasses permitem reuso de projeto, mas em uma
granularidade muito fina
ִUm Framework é um conjunto de classes que
formam a arquitetura típica de um certo tipo de
aplicação
Classes do framework são projetadas para serem
refinadas e utilizadas como um grupo

76

Frameworks Orientados a Objetos

Frameworks oferecem mecanismos e regras

ִpara reuso de código (instanciação de classes)
ִpara reuso de projeto (propriedades e
comportamentos de objetos em uma aplicação)

Um framework define um projeto genérico de
um subsistema (padrão de projeto)
pode ser refinado (via especialização) e configurado
(via parâmetros) para compor um dado subsistema
• Exemplo: Frameworks para construção de interfaces

77

39
Conclusões

Origens e aplicações do POO

Princípios fundamentais do POO

Representação de conceitos com o POO

Mecanismos essenciais do POO

Desenvolvimento de software com o POO

Mudanças culturais para POO

78

Bibliografia

Object-Oriented Concepts, Databases, and Applications.
Editado por Won Kim e Frederick Lochovsky. Addison-
Wesley, 1989.

Communications of the ACM - Special issue on Object-
Oriented Paradigm. Vol.33, num.9, set/90.

Engenharia de Software. Roger S. Pressman. Ed. McGraw-
Hill, terceira edição, 1995.

Análise Baseada em Objetos. Peter Coad e Edward Yourdon.
Ed. Campus, segunda edição, 1991.

Design Patterns for Object-Oriented Software Development.
Wolfgang Pree. Addison-Wesley, 1994.

Object-Oriented Database Systems – Concepts and
Architectures. Elisa Bertino e Lorenzo Martino. Addison-
Wesley, 1993.
79

40
Bibliografia

Object-Oriented Software Construction. Bertrand Meyer.
Prentice-Hall, 1997, segunda edição.

Object-Oriented Modeling and Design for Database
Applications. Michael Blaha e William Premerlani. Prentice-
Hall, 1998.

Análise e Projeto Orientados a Objetos – Estudos de Caso.
Edward Yourdon e Carl Argila. Makron Books, 1999.

UML Destilled – Applying the Standard Object Modeling
Language. Martin Fowler e Kendall Scott. Addison-Wesley,
1997.

The Unified Modeling Language User Guide. Grady Booch,
James Rumbaugh e Ivar Jacobson. Addison-Wesley, 1999.

Design Patterns – Elements of Reusable Object-Oriented
Software. Erich Gamma et al. Addison-Wesley, 1995.
80

41