1
Paradigma de Orientação a Objetos
Prof. Dr. Juliano Lopes de OliveiraEstratégia Tecnologia da Informação Ltda
Instituto de Informática - UFG
www.estrategia.eti.br www.inf.ufg.br/~juliano
juliano@ estrategia.eti.br [email protected]
1
Agenda
�Visão geral do paradigma orientado a objetosOrigens e aplicações: Linguagens; BD; IA; ...
�Princípios do paradigmaObjeto; encapsulação; interface; herança; ...
�Representação de conceitos com o paradigmaClassificação; composição; associação; ...
�Mecanismos essenciais do paradigma Herança e PolimorfismoSuporte para persistência, concorrência e distribuição
�Desenvolvimento de software OOCiclo de vida e métodos OO
2
2
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
3
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
4
Origens do Paradigma OO
�Linguagens de Programação e Eng. de SoftwareExemplo 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, ...
5
Origens do Paradigma OO
�Bancos de Dados e Inteligência ArtificialExemplo de Contribuição: Modelos Semânticos
de DadosCapturam 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
4
6
Aplicações de Orientação a Objetos
�Algumas áreas que usam o paradigma OOLinguagens 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
7
Aplicações de Orientação a Objetos
�Linguagens de ProgramaçãoSimula, Smalltalk, Ada, Eiffel, C++, Java
O POO é utilizado como base das principais construções dessas linguagens
�CASE e Ambientes de DesenvolvimentoVisual Basic, Delphi, Rose, Poseidon
Usam o POO como base para modelagem e implementação de software
5
8
Aplicações de Orientação a Objetos
�SGBD OOO2, 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
9
Aplicações de Orientação a Objetos
�Sistemas Operacionais e Interfaces de usuárioWindows, MacOS, Linux
Todos os principais Sistemas operacionais possuem interfaces gráficas baseadas no POOSeleção de objeto e envio de mensagem
Todos os principais IDE (ambientes de desenvolvimento de interface) adotam o POOVisual Basic, Delphi, Jbuilder, NetBeans
6
10
Aplicações de Orientação a Objetos
�Processamento Distribuído Aberto (ODP)Corba, Java RMI, MS.Net
Todos as principais arquiteturas para processamento distribuído estão baseadas no POOTransparência de localização de objeto
Todos os principais protocolos de comunicação adotam algum princípio do POOIP, HTTP, TMN
11
Aplicações de Orientação a Objetos
�Engenharia de SoftwareUML, 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
7
12
Fundamentos do Paradigma OO
�Não existe definição formal e universalExistem, no entanto, conceitos e características que
estão presentes em diversas abordagens OO
�O objeto é o conceito fundamental, incluindoidentidade e propriedades de objeto
encapsulação de estrutura e comportamento
conjunto de abstrações para modelagem
mecanismos de herança e de comunicação
13
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, ...
8
14
�Um objeto possui quatro tipos de propriedadesAtributos 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();
Propriedades de Objeto
15
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
9
16
Estado de Objeto
�O Estado de um objeto é o conjunto de valores de suas propriedadesvalores dos atributos, identidade dos objetos
associados, algoritmos dos métodos, e definição das regrasCertos 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; ...
17
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ávelApós sua criação um OID nunca pode ser modificado
O OID é único em um sistema OOO sistema nunca gera o mesmo OID para dois objetos
10
18
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 objetoTodo objeto está em uma cápsula
• Por isso diz-se que o objeto está encapsulado
Aplicação do princípio de Information HidingQuanto mais isolado o conceito, menor o impacto de
sua mudança no restante do contexto
19
Interface e Implementação de Objeto
�A encapsulação é o principal conceito OO pois “protege” o objeto do restante do sistemaPorém, a cápsula (opaca e indestrutível) impede
que o objeto interaja com o mundo exterior
Solução: dividir o objeto em duas partesInterface: 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
11
20
Interface e Operações de Objeto
�A interface define o comportamento externamente visível através de operaçõesUma 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
21
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çõesA 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
12
22
Implementação de Objeto
�isola e protege a essência do objeto, ou seja, o estado do objetocontém todas as definições do comportamento
corpos de métodos e regras
contém todas as definições da estruturadescrição e valores dos atributos e associações
�provê independência de dados e de funçõesMudanças na implementação de um objeto não são
propagadas para o sistema, se a interface for mantida
23
Método e Operação de Objeto
�ambas as definições estão associadas ao comportamento do objetométodos e regras implementam o comportamento
definido pelas operações da interfacerealizam de fato as atividades definidas nas operações
Há métodos e regras que são internos ao objetorealizam 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
13
24
Níveis de Encapsulação
�Linha de código: nível 0Ausência de encapsulação
�Módulo ou subrotina: nível 1um termo para se referir a um grupo de linhas
�Objeto: nível 2dados e funções agrupados em um único conceito
�Pacote: nível 3grupo de classes de um mesmo nível de abstração
classes não necessariamente interagem
�Componente ou framework: nível 4classes de diversos níveis interagem para compor uma
solução reutilizável para um certo domínio de problema
25
�Objetos se comunicam exclusivamente através de intercâmbio de mensagensA 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
Protocolo de Comunicação OO
14
26
Interface
Implementação
Operação(parâmetros) Interface
Implementação
RespostaClienteServidor
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
27
�Objetos podem ter dois papéisObjetos 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
Iniciativa de Comunicação OO
15
28
�Síncrono: resposta obrigatória (embutida)
�Assíncrono: resposta opcional (via mensagem)
Interface
Implementação
Operação(parâmetros) Interface
ImplementaçãoResposta
Interface
Implementação
Operação(parâmetros) Interface
Implementação
Operação(Resposta)
Mecanismo de Resposta
29
Categorias de Mensagens
�Há três categorias de mensagens OOO mecanismo de tempo-de-execução OO deve
identificar e localizar os destinatáriosponto-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
16
30
Interface
Implementação
Operação(parâmetros)
Objeto 1
Barramento Virtual do Sistema de Execução OO
Objeto 2 Objeto N
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
31
Conceitos Subjacentes à Comunicação OO
�Delegação de funçõesredirecionamento de responsabilidades
�Distribuição de objetostransparê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-realmecanismo de prioridade de mensagens
17
32
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
33
Abstrações do paradigma OO
�As Abstrações OOClassificação
Instanciação
Identificação
Associação
Composição
Agregação
Generalização
Especialização
�Permitemidentificar e compor
objetos complexosConstruir estruturas para
organizar objetosCompartilhar e reutilizar
propriedadesRelacionar e agrupar
conjuntos de entidadesRedefinir, especializar e
generalizar conceitos
18
34
Classificação
�Reúne as propriedades comuns a um conjunto de objetosAbstrai 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
35
Instanciação
�Cria instâncias distintas a partir de uma classeInstâncias são objetos e possuem todas as
propriedades de sua classeEx: 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
19
36
Criação de Instâncias via Classe
O empacotamento de definições em uma Classe permite a sua reutilização via instanciaçãouma instância provê valores para as propriedades
definidas na classe
A criação de instâncias pode serestá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, ...
37
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 objetosEvita 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
20
38
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)
39
Associação
�Estabelece uma correlação entre conceitosEx.: 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 envolvidosEx.: todo objeto da classe Jornal deve estar associado a
um objeto da classe Editora• Diferença entre Ligação e Associação
21
40
Composição
Permite a definição de um conceito complexo a partir da combinação de conceitos mais simplesas 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 recursivaa 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, ...
41
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, bagNão viola a encapsulação dos sub-objetos
Compartilhamento sem redundância via OID
Semântica Parte-Todo, com variaçõescomposiçã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
22
42
Agregação
Estabelece uma relação do tipo Parte-Todo entre conceitosum 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é
43
Especialização
�Permite refinamento de conceitosA especialização de um conceito deve ser
compatível com o conceito original
A aplicação da abstração de Especialização origina uma subclasseA 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.
23
44
Generalização
�Permite abstrair diferenças entre classes de objetosAs 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.
45
Estrutura de um Sistema OO
�A estrutura dos objetos em Sistemas OO busca refletir fielmente a maneira como os conceitos se relacionam na realidade modeladaHierarquia de Generalização/Especialização
Superclasses e Subclasses
Grafo (e não hierarquia) de ComposiçãoObjetos Complexos e Objetos Simples
Associações genéricasRelacionamentos entre Objetos
24
46
Classe de Objetos
Mecanismo para reutilização de implementaçãoas 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 objetosClasses 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
47
Superclasse e Subclasse
�A especialização/generalização origina um relacionamento do tipo É-Um entre classesMecanismo 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
25
48
Herança
�É um mecanismo de reutilizaçãoUm “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çaquanto à 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
49
Herança Total ou Parcial
�Essa taxonomia de herança define a escolha das propriedades que serão herdadas
�Na Herança TotalTodas 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
26
50
Herança Simples ou Múltipla
�Define o número de servidores diretos da herançaNa 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)
51
Herança de Classe ou de Objeto
�Define o tipo de servidor da herança
�Na herança de Classe o servidor é uma classeA implementação mais comum é a baseada em
especialização total de classeOutras 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)
27
52
Herança Estática ou Dinâmica
�Define o tempo em que a herança é resolvidaHeranç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çõesDe parte: herança parcial de métodos transmitidos via mensagem
De escopo: objeto varia seu comportamento de acordo com o contexto
53
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 superclassesEm 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
28
54
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 clientesPode afetar a compatibilidade das substituições, mesmo que o
cliente da herança respeite a encapsulação
55
Mecanismos de reutilização
Classificados quantoao 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çaobjetos 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çãoobjetos 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)
29
56
Polimorfismo
�Um sistema computacional é polimórfico se a mesma função
pode ter implementações distintas
quando aplicada a diferentes tipos de dadosEx.: 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)
57
Polimorfismo em Sistemas OO
�Um sistema OO é polimórfico se a mesma operação pode ter comportamentos distintos
quando aplicada a diferentes objetosEx.: 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 nomesEx: abrir sobre janela e arquivo têm semânticas diferentes
Isto deve ser evitado: pode causar dificuldade de entendimento!
30
58
Polimorfismo Intra Objeto: falso polimorfismo
a mesma operação pode ter comportamentos distintos quando aplicada ao mesmo objetocom diferentes argumentosEx.: 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
59
Polimorfismo e Herança
�Polimorfismo permite redefinição de comportamento herdadoisto 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
31
60
Polimorfismo e Herança de Classe
�É o padrão de facto para reutilização e refinamento de comportamento em Sistemas OOA 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 mensagemEx.: 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
61
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çãoo próprio sistema seleciona o método adequado
Este mecanismo também é conhecido como ligação dinâmica (dynamic binding)
32
62
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âmicasincronizaçã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çãotransparência de localização, controle de versões e
réplicas, evolução de esquema, recuperação de falhas
63
Persistência de Objetos
Objetos transientes morrem com sua aplicação
Objetos persistentes permanecem após a execução do programa que os criouSistemas 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
33
64
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êncianomeaçã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)
65
Ambiente de Desenvolvimento OO
Precisariam oferecer todas as facilidades dos CASE tradicionaisgerência de configuração, referências cruzadas, ...
Precisariam prover suporte para métodos de projeto OO, mas se limitam ao suporte à programação OOo 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
34
66
Teoria e Prática de Desenvolvimento OO
�Ciclos de vida tradicionais adotam uma separação rígida entre etapasNa prática, observa-se que o processo de
desenvolvimento é iterativo e interativo
�Métodos de desenvolvimento tradicionais enfatizam a decomposição funcionalNa prática, comprova-se que a estrutura mais
estável é a dos dados, não a das funções
67
Características dos métodos OO
�Adotam ciclo de vida interativo e iterativosem separação rigorosa entre fases
�Organizam o software em torno de objetosdados 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
35
68
Processo de Desenvolvimento OO
�Um sistema OOnão é um conjunto de funções!
um conjunto de objetos interagindo em uma arquitetura cliente/servidor
�Análise e Projeto de alto nível determinamserviços oferecidos e protocolo de comunicação
�Projeto detalhado incluiespecificação de estruturas e algoritmos
69
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)
36
70
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 estruturaisencapsulação evita “efeito dominó”
Desenvolvimento com Tipos Abstratos (TADs)independência de estruturas e procedimentos
Representação do espaço do problemaausência de mapeamentos entre análise e projeto
rastreabilidade
71
Reutilização em Desenvolvimento OO
�O ciclo de vida OO visa atingir reutilizaçãoA idéia é gastar mais esforço em desenvolvimento
e menos em manutençãobiblioteca 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)
37
72
Fatoração no Desenvolvimento OO
�O projeto tradicional é monolíticoFeito de uma vez, no início do ciclo de vida, com
pouco conhecimento sobre o problema
�O desenvolvimento OO é fatoradoO 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
73
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 esperadosreutilização
manutenibilidade e flexibilidade para adaptação
encapsulação de informação (information hiding)
desenvolvimento iterativo e incremental
uniformidade e representatividade de modelos, ...
38
74
Projeto OO
Enfoque bottom-updetalha as propriedades de cada objeto
Enfoque top-downestrutura: composição, associação e especialização
comunicação: interações em serviços complexos
Fase inicial do projetoidentificar classes que modelam a realidade
distribuir o comportamento entre as classes
determinar colaborações entre componentes
75
Projeto OO
�Refinamentofatorar e estruturar propriedades
hierarquias de herança
determinar protocolos de comunicaçãoconsolidar 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
39
76
Frameworks Orientados a Objetos
�A longo prazo, reuso de projeto é mais importante que reuso de códigoClasses 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çãoClasses do framework são projetadas para serem
refinadas e utilizadas como um grupo
77
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
40
78
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
79
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.
41
80
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.