Apostila Poo

CENTRO FEDERAL DE EDUCAO TECNOLGICA DA PARABA
DIRETORIA DE ENSINO COORDENAO DE INFORMTICA
INTRODUO AO
PARADIGMA DE
ORIENTAO A OBJETOS
MENSAGEM
OBJETO B
OBJETO A
AUTOR: PROF. CARLOS ALBERTO KAMIENSKI
JOO PESSOA, JULHO DE 1996
Introduo ao Paradigma de Orientao a Objetos
NDICE
1. Introduo
1.1. Por que estudar o paradigma de orientao a objetos ? ..........................
1.2. A natureza das novas aplicaes .............................................................
1.3. O desafio das novas tecnologias .............................................................
1.4. Os ambientes de programao modernos ................................................
1.5. Programao Orientada a Objetos...........................................................
2. Conceitos bsicos e terminologia
2.1. Abstrao de dados .................................................................................
2.2. Objetos ....................................................................................................
2.3. Mensagens ...............................................................................................
2.4. Mtodos ...................................................................................................
2.5. Classes .....................................................................................................
2.6. Herana ...................................................................................................
2.6. Polimorfismo ...........................................................................................
2.7. Relaes entre Objeto, Classe e Herana ................................................
2.7.1. Classificao/Instanciao .......................................................
2.7.2. Generalizao/Especializao ..................................................
2.7.3. Composio/Decomposio .....................................................
3. Avaliao da POO
3.1. Vantagens da POO ..................................................................................
3.2. Desvantagens da POO .............................................................................
3.3. O estilo de programao com POO.........................................................
3.4. Programao Dirigida por Eventos .........................................................
4. Linguagens Tpicas
4.1. A linguagem de programao SmallTalk ................................................
4.2. A linguagem de programao C++ .........................................................
4.3. A linguagem de programao Object Pascal ..........................................
5. O paradigma de orientao a objetos
5.1. Desenvolvimento Orientado a Objetos ...................................................
5.2. Anlise Orientada a Objetos ...................................................................
5.3. Projeto Orientado a Objetos ....................................................................
5.4. Tcnica de Modelagem de Objetos .........................................................
5.4.1. Anlise ......................................................................................
5.4.2. Projeto do sistema ....................................................................
5.4.3. Projeto dos Objetos ..................................................................
5.5. Bancos de Dados Orientados a Objetos ..................................................
5.6. Outras utilizaes da Orientao a Objetos ............................................
5.6.1. Reengenharia de Processos Orientada a Objetos .....................
5.6.2 Ambientes de Desenvolvimento de Software Orientados a
Objetos ......................................................................................
5.6.3 Interfaces Grficas de Usurio Orientadas a Objetos ...............
5.6.4 Sistemas Operacionais Orientados a Objetos ............................
6. Bibliografia
1
1
1
2
2
3
5
5
6
8
9
9
11
13
15
15
15
16
16
17
18
19
20
21
22
25
27
31
31
33
33
34
35
36
36
37
38
38
38
39
39
39
Copyright 1996 - Carlos Alberto Kamienski CEFET-PB - verso preliminar
1. Introduo
O paradigma de Orientao a Objetos (OO) no apenas um nome pomposo,
uma nova terminologia ou modismo sem efeito prtico. Possui o objetivo, e consegue
obt-lo em conjunto com outras tecnologias, de atenuar o que se convencionou
chamar de crise do software. No incio do era dos computadores o hardware era to
caro que o custo do software era muitas vezes desprezado nas organizaes. As
aplicaes eram tambm, se comparadas com a atualidade, representativamente mais
simples. Com o passar do tempo observou-se que os custos associados ao hardware
diminuram gradativamente, enquanto que os custos do software aumentaram
assustadoramente. Hoje, em uma instalao os custos associados com o software
superam em vrias vezes cos custos de hardware, e a tendncia que isto aumente
cada vez mais.
1.1. Por que estudar o paradigma de orientao a objetos ?

Existem qualidades que atualmente todas as empresas querem atribuir a seus
produtos, que nem implementam corretamente. Trs qualidades mais notrias so:
1. Sistema aberto: tudo atualmente aberto, mesmo que no siga padres
(que define os sistemas abertos) de mercado ou de direito.
1. Arquitetura cliente/servidor: tudo atualmente cliente/servidor, mesmo
que no possibilite a diviso do software entre clientes e servidores.
1. Orientao a objetos: tudo atualmente orientado a objetos, mesmo que
no implemente objetos, classes e herana.
O primeiro bom motivo para estudar o paradigma de orientao a objetos
distinguir quais produtos so orientados a objetos e quais no so. O segundo que a
orientao a objetos no s moda, est-se utilizando e vai se utilizar cada vez mais
desde Reengenharia de Processos Orientada a Objetos at Bancos de Dados
Orientados a Objetos, passando pela anlise, projeto e programao.
1.2. A natureza das novas aplicaes

A natureza das novas aplicaes de computadores tem evoludo mais
rapidamente que a capacidade de concretiz-las. Algumas caractersticas crticas de
novas aplicaes e necessidades emergentes incluem:
Tamanho e complexidade: Software de uso geral tem dezenas de Mbytes de
cdigo-fonte. Mesmo pacotes utilitrios cuja arquitetura interna passa em
larga medida despercebida pelo usurio comum chegam facilmente a essa
faixa. Por outro lado, a prpria arquitetura interna das aplicaes
altamente complexa, incluindo paralelismo, transaes mltiplas, forte
interao grfica, etc.
Alta confiabilidade: Na medida em que sistemas automatizados vo sendo
introduzidos para assistir usurios comuns no especializados em tarefas
Copyright 1996 - Carlos Alberto Kamienski - CEFET-PB - verso preliminar
complexas, a margem de erro aceitvel se torna cada vez menor, uma vez
que, a rigor, o prprio operador de um sistema est a reboque do sistema e
no o contrrio.
Alto desempenho: Novas aplicaes demandam alto desempenho em
clculos (ex.: rastreamento por satlites, previso do tempo, sistemas de
informaes geogrficas, CAD, etc.) e/ou em coordenao e comunicao
entre as partes (usando redes de computadores, por exemplo).
1.3. O desafio das novas tecnologias

O software sempre muito caro, os prazos no so cumpridos e a manuteno
problemtica. O problema bsico a ser enfrentado em desenvolvimento de software
, em poucas palavras:
CONSTRUIR SOFTWARE RPIDO, BARATO E FLEXVEL
Construir Rpido: Na medida em que os requisitos e plataformas so
fludos e evolutivos, despender tempo excessivo terrvel. Por outro lado,
com o backlog de aplicaes a desenvolver cada vez maior, a construo
de software mais rpido uma necessidades na prtica.
Construir Barato: O custo de desenvolvimento relativamente alto,
devido estruturao da tarefa nos moldes atuais em linhas de montagem
hiper-dimensionadas, e devido baixa produtividade. necessrio um
aumento drstico na quantidade e qualidade de software produzido por
indivduos, passando pela reutilizao de software j desenvolvido.
Construir Flexvel: Sistemas devem ser arquitetados de tal forma que sua
alterao para qualquer fim (modificao ou extenso para atender a novos
requisitos, reutilizao em outros projetos, etc.) seja fcil.
Linhas de ao para atacar esses problemas tm includo:
investigao de novas tcnicas e seu suporte adequado em ambientes
integrados para desenvolvimento de software;
reviso do modelo clssico de ciclo de vida de sistemas e de mtodos de
desenvolvimento de software;
melhor compreenso de aspectos fundamentais envolvidos no processo de
software.
Tais linhas de ao tm em geral seguido caminhos isolados, quando no
conflitantes. H, contudo, uma nfase crescente em idias convergindo para o
chamado paradigma de orientao a objetos, como uma possvel foco integrador
dessas linhas.
1.4. Os ambientes de programao modernos
Os ambientes de Desenvolvimento de Software tm evoludo muito nos

ltimos anos para incorporar vrias tecnologias num movimento sinrgico em direo
obter melhores condies do desenvolvimento de sistemas. Com relao s
ferramentas especficas para a programao, atualmente vrias caractersticas tm se
firmado em termos de mercado:
Programao visual: programao visual se refere utilizao de interfaces
grficas interativas para o desenvolvimento de programas. Dessa forma, o
programador no desempenho da sua tarefa, obtm os mesmos benefcios
das GUI (Grafical User Interface - interface grfica de usurio) que ele
projeta.
Programao dirigida por eventos. Nos ambientes grficos o
processamento perde o carter puramente seqencial que se est
acostumado para ser dirigido pelos eventos gerados pelo usurio (seo
3.4).
Programao para Windows: existem vrios ambiente que utilizam
programao visual e processamento dirigido por eventos, mas o Windows
tornou-se o padro em termos de ambiente desktop. A programao para
Windows tm certas caractersticas especficas, como o tratamento de
mensagens e recursos, que no entanto, somente so de interesse de
programadores de sistemas bsicos em linguagens como C.
Programao orientada a objetos: o assunto desse trabalho
RAD (Rapid Application Development): significa desenvolvimento rpido
de aplicaes; ambientes que implementam RAD permitem o
desenvolvimento de programas de entrada e sada de dados utilizando
pouco ou nenhum cdigo (o cdigo gerado automaticamente). Utiliza a
programao visual.
Prototipagem: um prottipo uma aplicao que ainda no tem toda a
funcionalidade final. Seu objetivo maior o dilogo com o usurio e os
refinamentos sucessivos. Tipicamente, sistemas so construdos
desenhando suas telas e relatrios facilmente, com RAD, e vai evoluindo
gradativamente medida que seu desenvolvimento prossegue, at adquirir
toda a funcionalidade desejada.
Arquitetura Cliente/Servidor: os ambientes modernos permitem a diviso
do programa entre cdigo cliente e servidor, que pode ser executado em
mquinas distintas em um ambiente distribudo. Os ambientes possuem
drivers para acessar SQL de vrios bancos de dados e conexo ODBC.
Sistemas abertos: em geral o objetivo de aderir a padres alcanado
nesses ambientes
Gerenciamento de equipes de desenvolvedores: equipes de desenvolvedores
trabalhando em um sistema complexo precisam de uma organizao nvel
de programas. Os ambientes modernos proporcionam facilidades de checkin/check-out (bloqueio para leitura e escrita de componentes do sistema),
controle de verses e at o armazenamento dos sistemas integralmente em
bancos de dados.
1.5. Programao Orientada a Objetos

Programao orientada a objetos (POO) uma metodologia de programao
adequada ao desenvolvimento de sistemas de grande porte, provendo modularidade e
reusabilidade. A POO introduz uma abordagem na qual o programador visualiza seu
programa em execuo como uma coleo de objetos cooperantes que se comunicam
atravs de mensagens. Cada um dos objetos instncia de uma classe e todas as
classes formam uma hierarquia de classes unidas via relacionamento de herana.
Existem alguns aspectos importantes na definio de POO:
Usa objetos, e no funes ou procedimentos como seu bloco lgico
fundamental de construo de programas
Objetos comunicam-se atravs de mensagens
Cada objeto instncia de uma classe
Classes esto relacionadas com as outras via mecanismos de herana
POO uma maneira de programar que difere substancialmente da
programao tradicional, como em COBOL, Pascal, FORTRAN, C e outras
linguagens. O que torna a POO diferente que em vez de iniciar um programa
escrevendo um lao principal e ento todas as subrotinas que constituem a aplicao,
inicia-se decidindo quais objetos a aplicao requer e ento os objetos so
caracterizados com propriedades e comportamento. Objetos so agrupados em uma
hierarquia de classes, como a hierarquia existente no reino animal.
A expresso programao orientada a objetos derivada do conceito de objeto
utilizado na linguagem Simula 67. Nesta linguagem, a execuo de um programa
realizada de maneira cooperativa, mas no paralela, seguindo uma organizao em
corrotinas, de uma coleo de objetos. Os objetos compartilhando uma estrutura
comum so ditos instncias de uma mesma classe.
Embora outras linguagens de programao tenham mostrado algumas
tendncias orientao a objetos, Smalltalk ainda a linguagem mais representativa
do paradigma de objetos. Mais do que uma linguagem de programao, Smalltalk
um completo ambiente de programao refletindo a filosofia de orientao a objetos.
Programao orientada a objetos d nfase estrutura de dados, adicionando
funcionalidade ou capacidade de processamento a estas estruturas. Em linguagens
tradicionais, a importncia maior atribuda a processos, e sua implementao em
subprogramas. Em uma linguagem como Pascal, procedimentos ativos agem sobre
dados passivos que foram passados a eles. Em linguagens orientadas a objetos, ao
invs de passar dados a procedimentos, requisita-se que objetos realizem operaes
neles prprios.
Alguns aspectos so fundamentais na definio de programao orientada a
objetos, que sero devidamente investigados neste trabalho:
Abstrao de dados
Objetos
Mensagens
Classes
Herana
Polimorfismo
2. Conceitos bsicos e terminologia

Para que se possa utilizar uma linguagem de programao orientada a objetos
necessrio primeiramente conhecer os conceitos e a terminologia utilizada por este
paradigma.
2.1. Abstrao de dados

Um conceito que teve muita influncia na POO chama-se programao com
tipos abstratos de dados. Tipos abstratos de dados possuem caractersticas como
encapsulamento e modularidade.
A noo de tipos de dados ocorre na maioria das linguagens de programao
tradicionais. Na declarao do tipo de uma varivel, delimita-se o conjunto de valores
que ela pode assumir e as operaes que ela pode sofrer. A especificao de um tipo
de dados deve definir os objetos constituintes do tipo e as operaes aplicveis a estes
objetos. Alm disso, possvel estabelecer uma maneira de representao para os
objetos.
Geralmente, uma linguagem de programao prov alguns tipos bsicos prdefinidos (tipos primitivos) e ainda oferece mecanismos para definio de novos tipos
de dados renomeando tipos existentes ou agregando alguns tipos primitivos e/ou
definidos pelo usurio (em Pascal, por exemplo, utiliza-se o comando type para criar
novos tipos de dados). Existem linguagens que alm de proporcionarem tipos de
dados primitivos e tipos de dados definidos pelo usurio, incorporam o conceito de
tipos abstratos de dados. Tipos abstratos de dados envolvem a disponibilidade de
dados e operaes (comportamento) sobre estes dados em uma nica unidade.
A abstrao de dados utilizada para introduzir um novo tipo de objeto, que
considerado til no domnio do problema a ser resolvido. Os usurios do tipo abstrato
de dados preocupam-se apenas com o comportamento dos objetos do tipo,
demonstrado em termos de operaes significativas para tais objetos, no
necessitando conhecer como estes objetos esto representados ou como as operaes
so realizadas neles (ocultamento de informao). Portanto, uma abstrao de dados
consiste de um conjunto de valores e de operaes que completamente caracterizam o
comportamento dos objetos. Esta propriedade garantida fazendo-se com que as
operaes sejam a nica maneira de criar e manipular os objetos. Como conseqncia,
necessrio incluir operaes suficientes para proporcionar todas as possveis aes
que os objetos possam sofrer.
Mais precisamente, um tipo abstrato de dados pode ser definido como um tipo
de dados que satisfaz as seguintes condies:
A representao e definio do tipo e as operaes nos objetos do tipo so

descritos em uma nica unidade sinttica (como em uma Unit, em Turbo
Pascal)
A representao (implementao) dos objetos do tipo escondida das
unidades de programa que utilizam o tipo; portanto, as nicas operaes
possveis em tais objetos so aquelas que fazem parte da definio
(interface) do tipo.
O estilo de programao com tipos abstratos de dados inclui o princpio de
encapsulamento, que proporciona ocultamento e proteo de informao,
viabilizando a manuteno e facilitando a evoluo de sistemas. Com o
encapsulamento da estrutura de dados que representa os objetos e dos procedimentos
que representam as possveis operaes sobre os objetos, tem-se que uma alterao na
estrutura de dados provavelmente exigir modificaes nos procedimentos, porm o
efeito dessas modificaes fica restrito s fronteiras da unidade sinttica que descreve
o tipo (a Unit, no caso). Se a interface permanecer a mesma, as unidades de programa
que utilizam o tipo no necessitam sofrer alteraes.
Uma outra vantagem que pode ser citada o considervel aumento de
confiabilidade obtido atravs do princpio da proteo. Unidades de programa que
utilizam um tipo no esto aptas a fazer modificaes diretamente. Elas somente
podem chamar as operaes que esto disponveis na interface, aumentando a
integridade dos objetos.
2.2. Objetos
Na viso de uma linguagem imperativa tradicional (Pascal, C, COBOL, etc.),
os objetos aparecem como uma nica entidade autnoma que combina a
representao da informao (estruturas de dados) e sua manipulao
(procedimentos), uma vez que possuem capacidade de processamento e armazenam
um estado local. Pode-se dizer que um objeto composto de (Figura 2.1):
Propriedades: so as informaes, estruturas de dados que representam o
estado interno do objeto. Em geral, no so acessveis aos demais objetos.
Comportamento: conjunto de operaes, chamados de mtodos, que agem
sobre as propriedades. Os mtodos so ativados (disparados) quando o
objeto recebe uma mensagem solicitando sua execuo. Embora no seja
obrigatrio, em geral uma mensagem recebe o mesmo nome do mtodo que
ela dispara. O conjunto de mensagens que um objeto est apto a receber
est definido na sua interface.
Identidade: uma propriedade que diferencia um objeto de outro; ou seja,
seu nome.
INTERFACE
OPERAO 1
ESTADO
INTERNO
OPERAO 2
IMPLEMENTAES DAS
OPERAES 1, 2 E 3
OPERAO 3
Figura 2.1. Estrutura de um objeto

Enquanto que os conceitos de dados e procedimentos so freqentemente
tratados separadamente nas linguagens de programao tradicionais, em POO eles so
reunidos em uma nica entidade: o objeto. A figura 2.2 apresenta outra visualizao
para um objeto.
ATRIBUTOS
MTODOS
Figura 2.2. Outra representao para um objeto

No mundo real no difcil a identificao de objetos (em termos de sistemas,
objetos so todas as entidades que podem ser modeladas, no apenas os nossos
conhecidos objetos inanimados). Como exemplo, em uma empresa pode-se identificar
claramente objetos da classe (seo 2.4) empregado.
Um empregado possui uma identidade prpria, seu nome: Jos da Silva.
Possui tambm propriedades como: endereo, idade, dependentes, salrio, cargo,
entre outras. O comportamento pode ser determinado por operaes como: aumentar
salrio, listar dependentes e alterar cargo. As propriedades somente podem ser
manipuladas atravs das operaes definidas na interface do objeto, de modo que a
forma de armazenamento das propriedades e a implementao das operaes so
desconhecidas pelas outras entidades externas (encapsulamento de informaes).
NOME
AUMENTAR
SALRIO
CARGO
...
...
SALRIO
LISTAR
DEPENDENTES
Figura 2.3. O objeto Empregado

Benefcios proporcionados pelos objetos:

Uma vez que objetos utilizam o princpio da abstrao de dados (seo 2.1), o
encapsulamento de informao proporciona dois benefcios principais para o
desenvolvimento de sistemas:
Modularidade: o cdigo fonte para um objeto pode ser escrito e mantido
independentemente da cdigo fonte de outros objetos. Alm disso, um
objeto pode ser facilmente migrado para outros sistemas.
Ocultamento de informao: um objeto tem uma interface pblica que os
outros objetos podem utilizar para estabelecer comunicao com ele. Mas,
o objeto mantm informaes e mtodos privados que podem ser alterados
a qualquer hora sem afetar os outros objetos que dependem dele. Ou seja,
no necessrio saber como o objeto implementado para poder utiliz-lo.
2.3. Mensagens
Um objeto sozinho no muito til e geralmente ele aparece como um
componente de um grande programa que contem muitos outros objetos. Atravs da
interao destes objetos pode-se obter uma grande funcionalidade e comportamentos
mais complexos.
Objetos de software interagem e comunicam-se com os outros atravs de
mensagens. Quando o objeto A deseja que o objeto B execute um de seus mtodos, o
objeto A envia uma mensagem ao objeto B (Figura 2.4). Algumas vezes o objeto
receptor precisa de mais informao para que ele saiba exatamente o que deve fazer;
esta informao transmitida juntamente com a mensagem atravs de parmetros.
MENSAGEM
OBJETO B
OBJETO A
Figura 2.4. O envio de mensagens entre objetos

Uma mensagem formada por trs componentes bsicos:
o objeto a quem a mensagem endereada (receptor)
o nome do mtodo que se deseja executar
os parmetros (se existirem) necessrios ao mtodo
Estes trs componentes so informao suficiente para o objeto receptor
executar a mtodo desejado. Nada mais necessrio. Ento, objetos em processos
distintos ou ainda em mquinas distintas podem comunicar-se atravs do uso de

mensagens.
Como exemplo, pode-se imaginar a realizao de uma operao aritmtica
utilizando-se objetos, mtodos e mensagens. Uma adio realizada enviando-se uma
mensagem a um objeto representando o nmero. A mensagem especifica que a
operao desejada a adio e tambm o nmero que deve ser somado ao objeto
receptor. Ento, a operao x+ y interpretada como a mensagem + sendo
enviada ao objeto x com o parmetro y. Pode parecer estranho primeira vista,
mas em SmallTalk operaes aritmticas so realmente tratadas dessa forma.
A ttulo de comparao com as linguagens convencionais, uma mensagem se
comporta como uma chamada de subrotina (procedimento ou funo). A sintaxe em
geral tambm muito parecida.
Benefcios proporcionados pelas mensagens:
Desde que tudo que um objeto pode fazer expressado pelos seus mtodos,
a troca de mensagens suporta todos os tipos possveis de interao entre
objetos
Para enviar e receber mensagens, objetos no precisam estar no mesmo
processo ou mquina (ex: CORBA)
2.4. Mtodos
Um mtodo implementa algum aspecto do comportamento do objeto.
Comportamento a forma como um objeto age e reage, em termos das suas trocas de
estado e troca de mensagens.
Um mtodo uma funo ou procedimento que definido na classe e
tipicamente pode acessar o estado interno de um objeto da classe para realizar alguma
operao. Pode ser pensado como sendo um procedimento cujo primeiro parmetro
o objeto no qual deve trabalhar. Este objeto chamado receptor (seo 2.3). Abaixo
apresentada uma notao possvel para o envio de uma mensagem (invocao do
mtodo)
receptor.nome_da_mensagem(par1, par2, par3)
Muitas vezes quando se trabalha com objetos deseja-se realizar certas
operaes no momento da criao e destruio de um objeto. Em algumas linguagens
dado um tratamento de modo a ficar transparente ao programador a sua
implementao. Em outras, necessrio utilizar mtodos especiais para este fim,
chamados de construtores e destrutores.
Construtores so usados para criar e inicializar objetos novos. Tipicamente, a
inicializao baseada em valores passados como parmetros para o construtor.
Destrutores so usados para destruir objetos. Quando um destrutor invocado, as
aes definidas pelo usurio so executadas, e ento a rea de memria alocada para o
objeto liberada. Em algumas linguagens, como C++, o construtor chamado
automaticamente quando um objeto declarado. Em outras, como Object Pascal,
necessrio chamar explicitamente o construtor antes de poder utiliz-lo.
Um exemplo de utilizao de construtores e destrutores seria gerenciar a

quantidade de objetos de uma determinada classe que j foram criados at o momento.
No construtor pode-se colocar cdigo para incrementar uma varivel e no destrutor o
cdigo para decrement-la. Na seo 4 so apresentados exemplos da utilizao de
construtores e destrutores.
2.5. Classes
Objetos de estrutura e comportamento idnticos so descritos como
pertencendo a uma classe, de tal forma que a descrio de suas propriedades pode ser
feita de uma s vez, de forma concisa, independente do nmero de objetos idnticos
em termos de estrutura e comportamento que possam existir em uma aplicao. A
noo de um objeto equivalente ao conceito de uma varivel em programao
convencional, pois especifica uma rea de armazenamento, enquanto que a classe
vista como um tipo abstrato de dados, uma vez que representa a definio de um tipo.
Cada objeto criado a partir de uma classe denominado de instncia dessa
classe. Uma classe prov toda a informao necessria para construir e utilizar objetos
de um tipo particular, ou seja, descreve a forma da memria privada e como se
realizam as operaes das suas instncias. Os mtodos residem nas classes, uma vez
que todas as instncias de uma classe possuem o mesmo conjunto de mtodos, ou
seja, a mesma interface.
Cada instncia pertence a uma classe e uma classe pode possuir mltiplas
instncias. Devido ao fato de todas as instncias de uma classe compartilharem as
mesmas operaes, qualquer diferena de respostas a mensagens aceitas por elas,
determinada pelos valores das variveis de instncia.
Em algumas linguagens, aparece tambm a definio de variveis de classe.
Variveis de classe surgem quando se tem a viso de classes sendo manipuladas como
objetos. Esta abordagem se torna til ao se tentar manter classes contendo
informao. Como exemplo, uma classe poderia armazenar o nmero de objetos que
tenham sido instanciados da classe at um certo momento. Cita-se, ainda, a
importncia de se ter classes como objetos para modelar a entidade que recebe uma
mensagem requisitando a criao de um novo objeto (como em Object Pascal).
A Figura 2.5 ilustra o relacionamento entre classes e objetos. Cada objeto
instanciado a partir de uma classe possui as propriedades e comportamento definidos
na classe, da mesma maneira que uma varivel incorpora as caractersticas do seu
tipo. A existncia de classes proporciona um ganho em reusabilidade. pois o cdigo
das operaes e a especificao da estrutura de um nmero potencialmente infinito de
objetos esto definidos em um nico local, a classe. Cada vez que um novo objeto
instanciado ou que uma mensagem enviada, a definio da classe reutilizada. Caso
no existissem classes, para cada novo objeto criado, seria preciso uma definio
completa do objeto.
10
CLASSE 1
OBJETOS DA
CLASSE 1
CLASSE 2
OBJETOS DA
CLASSE 2
CLASSE 3
OBJETOS DA
CLASSE 3
Figura 2.5. Relacionamento entre classes e objetos

No exemplo de uma empresa seria possvel criar classes para vrias entidades
a ser modeladas, como: empregados, departamentos, filiais, produtos, documentos
fiscais, etc. Na definio da classe empregado, so especificados as suas propriedades
e comportamento e escrito o cdigo fonte da sua implementao. Quando um novo
empregado admitido na empresa, ele criado como uma instncia da classe
empregado, e automaticamente possui todas as caractersticas da classe.
Metaclasses
Uma metaclasse uma classe de classes. Pode-se julgar conveniente que, em
uma linguagem ou ambiente, classes tambm possam ser manipuladas como objetos.
Por exemplo, uma classe pode conter variveis contendo informaes teis, como:
o nmero de objetos que tenham sido instanciados da classe at certo
instante;
um valor mdio de determinada propriedade, calculado sobre os valores
especficos desta propriedade nas instncias (por exemplo, mdia de idade
de empregados).
Essas variveis no devem ser criadas para cada objeto (instncia), mas para
cada classe deve existir apenas uma cpia de cada. Para implementar isto
conveniente considerar uma classe como sendo tambm um objeto. Neste caso, a
classe precisar ser instncia de outra classe. Esta classe de classes chama de
metaclasse.
Benefcios proporcionados pelas classes:
O maior benefcio proporcionado pela utilizao das classes a reusabilidade
de cdigo, uma vez que todos os objetos instanciados a partir dela incorporam as suas
propriedades e seu comportamento.
2.6. Herana
O mecanismo de herana permite a reutilizao das propriedades de uma
classe na definio de outra. A classe mais generalizada chamada superclasse e a
11
mais especializada, subclasse. No desenvolvimento de software, herana surge como

a maneira para garantir que caixas pretas construdas no se tornem caixas isoladas.
Atravs da herana, novas caixas pretas so obtidas aproveitando-se operaes j
implementadas, proporcionando a reusabilidade de cdigo existente. Assim como no
mundo dos seres humanos, o objeto descendente no tem nenhum trabalho para
receber a herana. Ele a recebe simplesmente porque um objeto descendente.
Herana a contribuio original do paradigma de objetos, que o diferencia da
programao com tipos abstratos de dados. Ela viabiliza a construo de sistemas a
partir de componentes reusveis. A herana no s suporta a reutilizao entre
sistemas, mas facilita diretamente a extensabilidade em um mesmo sistema. Diminui a
quantidade de cdigo para adicionar caractersticas a sistemas j existentes e tambm
facilita a manuteno de sistemas, tanto provendo maior legibilidade do cdigo
existente, quanto diminuindo a quantidade de cdigo a ser acrescentada.
A herana no limitada a apenas um nvel; a rvore de herana, ou
hierarquia de classes pode ser to profunda quanto for necessrio. Mtodos e
variveis internas so herdados por todos os objetos dos nveis para baixo. Quanto
mais para baixo na hierarquia uma classe estiver, mais especializado o seu
comportamento. Vrias subclasses descendentes podem herdar as caractersticas de
uma superclasse ancestral, assim como vrios seres humanos herdam as
caractersticas genticas de um antepassado.
EMPREGADO
EXECUTIVO
PRESIDENTE
GERENTE
DIRETOR
GERENTE
DEPARTAMENTO
COLABORADOR
GERENTE
DIVISO
Figura 2.6. Herana na classe Empregado

Na figura 2.6 pode-se ver a hierarquia de classes para a classe Empregado.
As classes Executivo, Gerente e Colaborador herdam todos os mtodos e variveis da
classe Empregado; alm disso, podem redefini-los e criar novas caractersticas. A
classe Presidente, tambm herda todas as caractersticas da classe Executivo, que por
sua vez j herdou da classe Empregado.
A herana interpretada da seguinte maneira: se B subclasse de A
(conseqentemente, A superclasse de B), ento:
os objetos da classe B suportam todas as operaes suportadas pelos
objetos da classe A, exceto aquelas redefinidas
as variveis de instncia de B incluem todas as variveis de instncia de A.
Analisando os itens acima, tem-se que uma subclasse compartilha o
comportamento e o estado de sua superclasse, podendo redefini-lo para seu prprio
12
uso. Alm disso, possvel acrescentar novas caractersticas que identificam um

comportamento prprio. A maior parte das linguagens orientadas a objetos utiliza
herana como uma tcnica para prover suporte especializao, e no permitem que
uma classe exclua uma operao herdada.
A utilizao de herana em linguagens orientadas a objetos pode afetar o
encapsulamento de informao. Alm dos clientes da classe que simplesmente
requisitam operaes sobre instncias da classe, surge uma nova categoria de clientes
que so as classes definidas atravs da herana, ou seja, as subclasses. Geralmente, s
subclasses permitido o total acesso representao das variveis de instncias
definidas na sua superclasse. Desta forma, compromete-se o princpio de
encapsulamento, uma vez que as variveis de instncia de uma classe sero parte
implcita da interface que ela proporciona para as suas possveis subclasses.
Mudanas na implementao de uma classe, como por exemplo a remoo de uma
varivel de instncia, poder comprometer a implementao de suas subclasses.
Assim, no existe mais a liberdade para modificar a representao de uma classe em
provocar efeitos nos seus clientes.
Herana no necessariamente est limitada a uma nica superclasse. Uma
subclasse pode herdar caractersticas de diversas superclasses, introduzindo o
conceito de herana mltipla. Indiscutivelmente, obtido um maior potencial para o
compartilhamento de cdigo, porm a possibilidade de conflitos, como o confronto de
nomes entre as operaes herdadas, entre mltiplas superclasses aumenta a
complexidade dos sistemas.
Benefcios proporcionados pela herana:
Subclasses provem comportamentos especializados tomando-se como base
os elementos comuns definidos pela superclasse. Atravs do uso da
herana, pode-se reutilizar o cdigo da superclasse vrias vezes.
Pode-se implementar classes que definem comportamentos genricos
(chamadas de classes abstratas). A essncia da superclasse definida e
pode ser parcialmente implementada, mas a maior parte da classe deixada
indefinida e no implementada. Os detalhes so definidos em subclasses
especializadas, que podem ser implementadas inclusive por outros
programadores de acordo com sua necessidade.
2.6. Polimorfismo
Polimorfismo refere-se capacidade de dois ou mais objetos responderem
mesma mensagem, cada um a seu prprio modo. A utilizao da herana torna-se
fcil com o polimorfismo. Desde que no necessrio escrever um mtodo com nome
diferente para responder a cada mensagem, o cdigo mais fcil de entender. Por
exemplo, sem polimorfismo, para inserir um novo empregado, seria necessrio o
seguinte cdigo:
Colaborador1.InsereColaborador
Gerente1.InsereGerente
Presidente1.InserePresidente
13
Neste caso, Colaborador1, Gerente1 e Presidente1 so objetos das

respectivamente das classes Colaborador, Gerente e Presidente. Com o polimorfismo,
no necessrio ter um mtodo diferente para cada tipo de objeto. Pode-se
simplesmente escrever o seguinte:
Colaborador.Insere
Gerente.Insere
Presidente.Insere
Neste exemplo, os trs diferente empregados tm trs diferentes mtodos para
ser inseridos, embora o tenha sido utilizado o mtodo com o mesmo nome. No cdigo
para esses empregados, seria necessrio escrever trs mtodos diferentes: um para
cada tipo de empregado. O mais importante a ser observado que as trs rotinas
compartilham o mesmo nome.
O polimorfismo obviamente no nos auxilia a reutilizar o cdigo. Em vez
disso, ele til na compreenso de programas. Desde que uma grande quantidade de
objetos compartilham o mesmo comportamento com implementaes ligeiramente
diferentes, encontrar uma maneira de diminuir o nmero de linhas de cdigo para
invocar estes comportamentos auxilia imensamente. Os programadores que so
usurios da classe Empregado no precisam saber que a maneira de inserir um
empregado diferente; quando eles querem inserir, somente utilizam o mtodo
Insere.
Se considerarmos que o mtodo Insere est sendo utilizado dentro de uma
estrutura de repetio, fica bastante aparente o ganho obtido em legibilidade e
tamanho do cdigo. Sem a utilizao de polimorfismo esta estrutura seria:
Para todos os Empregados Faa
Se Empregado Presidente Ento
Empregado[i].InserePresidente
Se Empregado Gerente Ento
Empregado[i].InsereGerente
Se Empregado Colaborador Ento
Empregado[i].InsereColaborador
Fim Se
Fim Para
Com a utilizao do polimorfismo seria possvel utilizar o seguinte cdigo:
Para todos os Empregados Faa
Empregado[i].Insere
Fim Para
O polimorfismo visto nos exemplos acima implica na existncia de mtodos
com implementao diferente com o mesmo nome em classes distintas. Outra forma
simples de polimorfismo permite a existncia de vrios mtodos com o mesmo nome,
definidos na mesma classe, que se diferenciam pelo tipo ou nmero de parmetros
suportados. Isto conhecido como polimorfismo paramtrico, ou sobrecarga de
operadores (overloading). Neste caso, uma mensagem poderia ser enviada a um
objeto com parmetros de tipos diferentes (uma vez inteiro, outra real, por exemplo),
ou com nmero varivel de parmetros. O nome da mensagem seria o mesmo, porm
o mtodo invocado seria escolhido de acordo com os parmetros enviados.
14
Dependendo das caractersticas da linguagem e do tipo de polimorfismo

suportado por ela, a implementao do polimorfismo pode exigir facilidades
proporcionadas pela ligao dinmica. De um modo geral, uma ligao (binding)
uma associao, possivelmente entre um atributo e uma entidade ou entre uma
operao e um smbolo. Uma ligao dita esttica se ocorre em tempo de
compilao ou de interligao (linking) e no mais modificada durante toda a
execuo do programa. A ligao dinmica feita em tempo de execuo ou pode ser
alterada no decorrer da execuo do programa.
Com a ligao dinmica, a ligao do operador a uma particular operao pode
ser feita em tempo de execuo, isto , o cdigo compilado para um tipo abstrato de
dados pode ser usado para diferentes tipos de dados, aumentando consideravelmente
sua reusabilidade. Entretanto, o uso de ligao dinmica compromete a eficincia de
implementao.
Benefcios proporcionados pelo polimorfismo
Legibilidade do cdigo: a utilizao do mesmo nome de mtodo para vrios
objetos torna o cdigo de mais fcil leitura e assimilao, facilitando muito
a expanso e manuteno dos sistemas.
Cdigo de menor tamanho: o cdigo mais claro torna-se tambm mais
enxuto e elegante. Pode-se resolver os mesmos problemas da programao
convencional com um cdigo de tamanho reduzido.
2.7. Relaes entre Objeto, Classe e Herana

Objetos, classes e o mecanismo de herana permitem a definio de
hierarquias de abstraes, que facilitam o entendimento e o gerenciamento da
complexidade dos sistemas estudados. Isto porque classes agrupam objetos com
caractersticas iguais, enquanto herana estrutura classes semelhantes.
A capacidade em classificar objetos e classes concede grande poder de
modelagem conceitual e classificao, podendo expressar relaes entre
comportamentos, tais como classificao/instanciao, generalizao/especializao e
agregao/composio. Facilita a compreenso humana do domnio estudado e
tambm o desenvolvimento de programas que o satisfaa. Pode-se dizer que a grande
vantagem do paradigma de objetos a possibilidade de expressar diretamente este
poder de modelagem conceitual numa linguagem de programao orientada a objetos.
Assim, o modelo conceitual proposto durante a etapa de anlise no se perde nas
etapas de projeto e implementao. O que em geral ocorre a sua extenso.
2.7.1. Classificao/Instanciao
A capacidade de classificar objetos (em classes) permite expressar relaes do
tipo classificao/instanciao. O relacionamento feito a partir da observao de
diversos fenmenos para categorizao dos mesmos em grupos (classes), com base no
conjunto de propriedades comuns a todos. Por exemplo, dois computadores, IBM PC
e Machintosh, podem ser classificados como instncias (objetos, modelos, ou
espcimes) da classe (categoria) Microcomputador (Figura 2.7). A relao inversa
15
a de instanciao de uma publicao (IBM PC, por exemplo) a partir da classe

Microcomputador.
INSTANCIAO
MICROCOMPUTADOR
MACHINTOSH
IBM PC
CLASSIFICAO
Figura 2.7. Relao de classificao/instanciao
2.7.2. Generalizao/Especializao
Este tipo de relao ocorre quando, a partir a observao de duas classes,
abstramos delas uma classe mais genrica. Por exemplo, as classes
Microcomputador e Mainframe podem ser considerados casos especiais da classe
Computador. Esta classe considerada uma generalizao das duas primeiras, que
so chamadas de especializaes da classe Computador (Figura 2.8). A idia da
generalizao/especializao a base para a classificao das espcies nas cincias
naturais. Do ponto de vista de propriedades, o pressuposto que as subclasses tenham
todas as propriedades das classes de quem elas so especializaes. Deve haver pelo
menos uma propriedade que diferencie duas classes especializadas (subclasses) a
partir da mesma classe genrica (superclasse). Este o tipo de relao utilizado com o
mecanismo de herana.
ESPECIALIZAO
COMPUTADOR
MICROCOMPUTADOR
MAINFRAME
GENERALIZAO
Figura 2.8. Relao de generalizao/especializao
2.7.3. Composio/Decomposio
A relao de composio (ou agregao)/decomposio permite que objetos
sejam compostos pela agregao de outros objetos ou componentes. Neste
relacionamento, so determinados que instncias (objetos) de uma classe so
compostas por instncias de outras classes. Essa operao denominada
decomposio e a relao inversa, a formao de uma nova classe como um agregado
de classes preexistentes, denominada composio. Por exemplo, instncias da
16
classe Microcomputador so compostas por, entre outras, instncias das classes

Teclado e Vdeo (Figura 2.9).
DECOMPOSIO
MICROCOMPUTADOR
TECLADO
VDEO
COMPOSIO
Figura 2.9. Relao de composio/decomposio
3. Avaliao da POO
O paradigma de objetos no apenas um nome pomposo. Seu objetivo claro
melhorar a produtividade dos programadores no desenvolvimento a sistemas. A POO
realmente torna mais rpidas as atividades de programao e manuteno de sistemas
de informao. Assim como a programao estrutura melhorou a qualidade dos
sistemas em relao aos mtodos praticados anteriormente (programas estilo
spagueti recheados de comandos goto), a POO surge como um modelo promissor
para solucionar as necessidades crescentes da nossa sociedade por sistemas
informatizados.
A grande vantagem do paradigma de objetos o seu carter unificador: trata
todas as etapas do desenvolvimento de sistemas e ambientes sob uma nica
abordagem. Nesse sentido, podemos ter anlise, projeto, programao, banco de
dados e ambientes orientados a objetos, eliminando as diferenas de impedncia
entre eles.
3.1. Vantagens da POO

A POO tem alcanado tanta popularidade devido s vantagens que ela traz.
Entre elas podemos citar:
Reusabilidade de cdigo
Escalabilidade de aplicaes
Mantenabilidade
Apropriao
A reusabilidade de cdigo , sem dvida, reconhecida como a maior vantagem

da utilizao de POO, pois permite que programas sejam escritos mais rapidamente.
Todas as empresas sofrem de deficincia em seus sistemas informatizados para obter
maior agilidade e prestar melhores servios a seus clientes. Um levantamento feito na
AT&T, a gigante das telecomunicaes nos EUA, identificou uma deficincia da
ordem de bilhes de linhas de cdigo. Uma vez que a demanda est sempre
17
aumentando, procura-se maneiras de desenvolver sistemas mais rapidamente, o que

est gerando uma srie de novas metodologias e tcnicas de construo de sistemas
(por exemplo, ferramentas CASE). A POO, atravs da reusabilidade de cdigo, traz
uma contribuio imensa nesta rea, possibilitando o desenvolvimento de novos
sistemas utilizando-se muito cdigo j existente. A maior contribuio para
reusabilidade de cdigo apresentada pela herana.
Escalabilidade pode ser vista como a capacidade de uma aplicao crescer
facilmente sem aumentar demasiadamente a sua complexidade ou comprometer o seu
desempenho. A POO adequada ao desenvolvimento de grandes sistemas uma vez
que pode-se construir e ampliar um sistema agrupando objetos e fazendo-os trocar
mensagens entre si. Esta viso de sistema uniforme, seja para pequenos ou grandes
sistemas (logicamente, deve-se guardar as devidas propores).
O encapsulamento proporciona ocultamento e proteo da informao.
Acessos a objetos somente podem ser realizados atravs das mensagens que ele est
habilitado a receber. Nenhum objeto pode manipular diretamente o estado interno de
outro objeto. De modo que, se houver necessidade de alterar as propriedades de um
objeto ou a implementao de algum mtodo, os outros objetos no sofrero nenhum
impacto, desde que a interface permanea idntica. Isto diminui em grande parte os
esforos despendidos em manuteno. Alm disso, para utilizar um objeto, o
programador no necessita conhecer a fundo a sua implementao.
O polimorfismo torna o programa mais enxuto, claro e fcil de compreender.
Sem polimorfismo, seriam necessrias listas enormes de mtodos com nomes
diferentes mas comportamento similar. Na programao, a escolha de um entre os
vrios mtodos seria realizada por estruturas de mltipla escolha (case) muito
grandes. Em termos de manuteno, isto significa que o programa ser mais
facilmente entendido e alterado.
A herana tambm torna a manuteno mais fcil. Se uma aplicao precisa de
alguma funcionalidade adicional, no necessrio alterar o cdigo atual.
Simplesmente cria-se uma nova gerao de uma classe, herdando o comportamento
antigo e adiciona-se novo comportamento ou redefine-se o comportamento antigo.
Outra vantagem da POO tambm uma desvantagem: apropriao. Problemas
do mundo real so freqentemente solucionados facilmente utilizando as tcnicas de
orientao a objetos. As nossas mentes so classificadores naturais de coisas.
Tipicamente ns classificamos coisas em hierarquias de classes. A POO leva
vantagem desse fato e nos fornece uma estrutura que funciona como a nossa mente.
Apropriao significa agrupar os objetos de comportamento similar em classes e essas
classes em hierarquias de herana.
3.2. Desvantagens da POO

Apesar de das inmeras vantagens, a POO tem tambm algumas desvantagens,
que incluem:
Apropriao
Fragilidade
Linearidade de desenvolvimento
18
A apropriao apresentada tanto como uma vantagem como uma

desvantagem, porque a POO nem sempre soluciona os problemas elegantemente.
Enquanto que a mente humana parece classificar objetos em categorias (classes) e
agrupar essas classes em relacionamentos de herana, o que ela realmente faz no
to simples. Em vez disso, objetos com caractersticas mais ou menos similares, e no
precisamente definidas, so reunidos em uma classificao. A POO requer definies
precisas de classes; definies flexveis e imprecisas no so suportadas. Na mente
humana, essas classificaes podem mudar com o tempo. Os critrios para classificar
objetos podem mudar significativamente. A apropriao utilizada na POO torna-a
muito rgida para trabalhar com situaes dinmicas e imprecisas.
Alm disso, algumas vezes no possvel decompor problemas do mundo real
em uma hierarquia de classes. Negcios e pessoas tm freqentemente regras de
operaes sobre objetos que desafiam uma hierarquia limpa e uma decomposio
orientada a objetos. O paradigma de objetos no trata bem de problemas que
requerem limites nebulosos e regras dinmicas para a classificao de objetos.
Isto leva ao prximo problema com POO: fragilidade. Desde que uma
hierarquia orientada a objetos requer definies precisas, se os relacionamentos
fundamentais entre as classes chave mudam, o projeto original orientada a objetos
perdido. Torna-se necessrio reanalisar os relacionamentos entre os objetos principais
e reprojetar uma nove hierarquia de classes. Se existir uma falha fundamental na
hierarquia de classes, o problema no facilmente consertado. A mente humana
adapta-se continuamente, e geralmente adequadamente, a situaes novas. Ela
encontra maneiras de classificar objetos no ambiente automaticamente. Enquanto a
nossa mente tem essa capacidade, os ambientes POO no so to bem equipados.
Em virtude dessa fragilidade, a POO requer anlise e projeto frontal para
assegurar que a soluo adequada. Com isto existe uma tendncia em criar uma
abordagem linear de desenvolvimento, em vez de cclica. Infelizmente, alguns
problemas so perversos, o que significa que no se sabe como resolver um
problema at efetivamente resolv-lo. Tais problemas desafiam at mesmo os
melhores projetistas e analistas de sistemas. Utilizar a abordagem de
Desenvolvimento Rpido de Aplicaes (RAD - Rapid Application Development,
utilizada pelo Delphi, SQL-Windows e outros ambientes de desenvolvimento para
Windows adequados prototipagem) com ciclos entre o projeto do prottipo,
construo e realimentao do usurio algumas vezes uma boa maneira de resolver
problemas perversos. Entretanto, a POO necessita de um projeto cuidadoso da
hierarquia de classes, o que pode elevar os custos da sua utilizao em um ambiente
RAD.
3.3. O estilo de programao com POO

O estilo de programao induzido pelo paradigma de objetos tem
caractersticas muito precisas:
Modularidade: o estilo impe alta modularidade na tarefa de projeto e
programao. O conceito de objetos e sua descrio em classes
incorporando dados e operaes constituem um critrio de modularizao
altamente efetivo e propiciam uma boa traduo prtica de encapsulamento
de informaes.
19
Suporte a generalizao/especializao: o estilo suporta diretamente a

estruturao de conceitos em hierarquias de generalizao/especializao
que representa a deficincia fundamental de abordagens de programao
limitadas a tipos abstratos de dados (TADs).
Viso balanceada entre dados e processos: o estilo tenta induzir, ao
contrrio de outros mtodos, uma viso integrada de dados e processos na
modelagem conceitual de aplicaes.
Composio botton-up de aplicao: o estilo privilegia a composio de
uma nova aplicao a partir de composio de classes de aplicaes
preexistentes. Nesse sentido, a composio da aplicao bottom-up (de
baixo para cima, ao contrrio de top-down).
A atividade incremental e evolutiva: o estilo favorece uma abordagem
incremental de programao, onde pequenas modificaes podem ser
rapidamente efetuadas e testadas, quer a partir da criao de novas classes,
quer a partir da rpida especializao de um classe preexistente.
Reusabilidade de cdigo: o estilo favorece a reutilizao de cdigo j
existente, na forma de bibliotecas de classes que sero diretamente
instanciadas ou modificadas pelo usurio.
Robustez: o estilo favorece a criao de aplicaes robustas, ou seja, muito
estveis em situaes sujeitas a falhas. A maioria das linguagens orientadas
a objetos possui mecanismos de tratar adequadamente erros vindos do
usurio e tambm excees do sistema.
Programao em grande escala: o estilo adequado ao desenvolvimento
de sistemas grandes e complexos com equipes formadas por vrios
programadores. Algumas caractersticas apresentadas acima contribuem
substancialmente para este item, como a modularidade e a reusabilidade.
3.4. Programao Dirigida por Eventos

Existe uma confuso muito comum atualmente com relao POO e
Programao Dirigida por Eventos (PDE). Os dois conceitos costumam ser usados
indisciplinadamente e tambm misturados. Um erro comum pensar que todas as
linguagem de programao para Windows (que implementa a PDE) so tambm
orientadas a objetos.
A linguagem SmallTalk, que a linguagem orientada a objetos mais pura
nasceu em conjunto com um ambiente grfico de desenvolvimento. A seguir alguns
sistemas copiaram a idia das interfaces grficas de usurio(GUI), alguns
implementando POO, outros no. Na realidade as tcnicas de orientao a objetos
trazem muitos benefcios s interfaces de usurio, como ser visto na seo 5.
Os conceitos de POO foram apresentados nas sees 2 e 3 e dizem respeito
objetos, classes, herana, polimorfismo, etc. A PDE diz respeito maneira como a
execuo dos programas tratada nos ambientes de desenvolvimento e contrasta
diretamente com a programao seqencial. POO e PDE representam aspectos
20
distintos porm complementares, que utilizados em conjunto obtm alto grau de

sinergia nos resultados apresentados.
Um determinado ambiente de desenvolvimento, como pode ser visto na Tabela
3.1, pode ter caractersticas de POO e PDE, de apenas uma delas, ou de nenhuma.
Ambiente
POO
PDE
COBOL tradicional
Visual Basic
Turbo C++
Delphi
NO
NO
SIM
SIM
NO
SIM
NO
SIM
Tabela 3.1. Ambientes POO e PDE

A seguir ser dada uma pequena viso comparativa entre programao
seqencial e programao dirigida por eventos.
Programao Seqencial
Programao Seqencial o que se imagina quando se pensa em programao.
o modelo bsico para os programadores desde que a programao comeou, e
fcil de conceituar. Em programao seqencial, h um incio, meio e fim. Ela
unidirecional. Tipicamente um programa seqencial possui os seguintes passos:
1.
2.
3.
4.
Inicializar todas as variveis

Ler os dados
Aplicar um algoritmo sobre os dados
Escrever os resultados
Onde o algoritmo poderia ser qualquer coisa, desde ordenar dados

alfabeticamente at calcular horscopo.
Em um nvel fundamental, exatamente isso o que ocorre dentro do
computador. Pode-se ver um computador realizando muitas atividades ao mesmo
tempo, mas uma CPU pode somente realizar efetivamente uma por vez. Parece que
elas so executadas ao mesmo tempo porque o computador (o sistema operacional, na
realidade) troca rapidamente de uma tarefa para outra
O modelo Seqencial continua ainda sendo verdadeiro, mas algumas vezes
til olhar de um ponto de vista diferente, ou de um nvel de abstrao diferente.
Programao Dirigida por Eventos

Programao Dirigida por Eventos o modelo que tipicamente utilizado
pelos sistemas operacionais e programas aplicativos atuais. Na Programa Dirigida por
Eventos, no existe um foco de processamento linear que o programa segue. Um
programa configurado como uma coleo de tratadores (handlers) que so utilizados
quando os vrios eventos ocorrem. Um tratador de eventos constitui-se basicamente
em subrotina em um programa (um procedimento ou uma funo). Um programa
dirigido por eventos pode ser imaginado como tendo os seguintes passos:
1. Inicializar
2. Configurar a interface
21
3. Esperar por um evento

4. Quando um evento ocorrer, deve-se trat-lo
5. Ir para o passo 3 (o estado de espera)
Por exemplo, um evento pode ser: o usurio clica em um cone, o usurio
escolhe Novo em um menu, ou o usurio pressiona a tecla c.
A principal diferena entre esses dois paradigmas que em Programao
Dirigida por Eventos, qualquer coisa pode acontecer. Um usurio (ou um programa,
ou um computador atravs de um rede, etc.) pode causar um determinado evento
dentre um vasto repertrio de possibilidades. Os eventos disponveis (que so
tratados) so aqueles geralmente que o programador achar necessrios.
Pode-se notar que a Programao Dirigida por Eventos constitui-se apenas em
uma camada no topo da Programao Seqencial. Um programa constitudo de
muitos tratadores de eventos, que so programas seqenciais, em vez de um nico
grande programa seqencial. A Programao Dirigida por Eventos ento justamente
um nvel de abstrao em cima do nosso modelo seqencial bsico, que torna mais
fcil a tarefa de projetar e escrever programas. A linguagem de programao utilizada
para implementar os tratadores de eventos pode seguir o paradigma procedimental
tradicional (linguagens como Pascal, C, Cobol, Fortran, etc.), orientado a objetos
alm de outros possveis.
4. Linguagens Tpicas
Com relao ao suporte a objetos, pode-se classificar as linguagens de
programao em: no baseadas em objetos, baseadas em objetos, baseadas em
classes e orientadas a objetos.
Uma linguagem que no suporte objetos como uma construo primitiva ,
obviamente, no baseada em objetos. Exemplos de linguagens no baseadas em
objetos so Pascal, C, FORTRAN e COBOL.
Caso uma linguagem suporte objetos, ento ela denominada como sendo
baseada em objetos. As linguagens baseadas em objetos incluem Modula-2, ADA,
CLU, Simula, SmallTalk, C++ e Object Pascal.
Para ser considerada uma linguagem baseada em classes necessrio que todo
objeto pertena a alguma classe. CLU, Simula, SmallTalk, C++ e Object Pascal so
tambm linguagens baseadas em classes, mas no o so o ADA e Modula-2. Uma
linguagem orientada a objetos baseada em classes dispostas em hierarquias.
SmallTalk, C++ e Object Pascal so orientadas a objetos, uma vez que suas classes
suportam o mecanismo de herana. CLU baseada em classes, mas no orientada a
objetos, uma vez que suas classes no suportam herana.
Linguagens baseadas em classes so um subconjunto prprio das linguagens
baseadas em objetos, enquanto linguagens orientadas a objetos so um subconjunto
prprio das linguagens baseadas em classes. A Figura 4.1 mostra o relacionamento
entre as classes de linguagens de programao baseadas a objetos.
22
BASEADAS EM
OBJETOS
+ CLASSES
BASEADAS EM
CLASSES
+ HERANA
ADA
ORIENTADAS A
OBJETOS
CLU
SMALLTALK
C++
Figura 4.1. Relacionamento entre classes de linguagens baseadas em objetos

Estas classes de linguagens so teis para distinguir as diferentes linguagens
baseadas em objetos existentes, como base em suas caractersticas, relacionamento
estas distines com a capacidade da linguagem em suportar determinada
metodologia. Por isso, deve-se considerar o efeito de objetos, classes e herana na
metodologia de programao.
4.1. A linguagem de programao SmallTalk

A linguagem de programao Smalltalk inteiramente implementada com
base no modelo de objetos comunicando-se seqencialmente atravs de mensagens. A
idia fundamental caracterizando a linguagem a uniformidade. Um objeto representa
um componente do sistema, isto , representa nmeros, filas, diretrios de discos,
compiladores, etc.
Em SmallTalk o paradigma de objetos levado s ltimas conseqncias.
Todas as entidades manipuladas por um programa so objetos ou referncias a
objetos. A construo 5 + 2, por exemplo, que em outras linguagens geralmente
considerada uma expresso aritmtica, interpretada em SmallTalk como um objeto
representando o inteiro 5 ao qual enviada a mensagem + cujo argumento outro
objeto representando o valor inteiro 2. Nesse caso, o objeto que representa o valor 5
efetua a operao de soma e retorna como resposta um objeto representando o valor
inteiro 7.
As entidades bsicas manipuladas em Smalltalk refletem os conceitos j
apresentados. Um objeto consiste de uma rea de memria (variveis de instncia) e
de operaes (mtodos). Uma mensagem vista como uma requisio para um objeto
realizar uma de suas operaes. A definio da interface de um objeto feita atravs
das mensagens que o objeto pode responder. Esta interface restringe a manipulao da
rea privada de um objeto s operaes associadas s mensagens. O envio de uma
mensagem a um objeto acarreta a procura de um mtodo cujo seletor seja adequado
mensagem. Se o mtodo no for encontrado na interface da classe deste objeto a
procura passa a ser feita na interface da sua superclasse, e assim sucessivamente.
23
Desta forma, a ligao (binding) da mensagem com um mtodo a ser executado

feita em tempo de execuo. Outra caracterstica da linguagem que no se trabalha
com a verificao de tipos, j que no existe a associao de uma varivel a um
tipo.
As classes descrevem a implementao de objetos que representam
componentes do sistema possuindo comportamentos idnticos. Como todas as
entidades do sistema Smalltalk so vistas como objetos e todos os objetos so
instncias de uma classe, as prprias classes devem ser representadas por instncias
de uma classe, surgindo o conceito de metaclasses. Em verses preliminares da
linguagem existia apenas uma nica metaclasse, chamada Class. Com esta
abordagem, o protocolo de todas as classes estava limitado a ser o mesmo. Assim,
mltiplas metaclasses so necessrias porque mensagens para iniciao de novas
instncias so diferentes para diversas classes. Portanto, uma classe uma instncia
nica de uma metaclasse, que possui o objetivo de definir o protocolo de utilizao da
classe.
Todas as metaclasses so instncias de uma classe chamada Metaclass e
possuem uma superclasse abstrata (Class) que descreve a natureza geral das
metaclasses. Cada metaclasse pode adicionar novas mensagens de criao de
instncias ou redefinir as mensagens fundamentais, isto , cada metaclasse adiciona o
comportamento especfico sua nica instncia atravs dos mtodos da classe
apresentados como parte da descrio da classe. O uso de mensagens de classe
tambm importante para a iniciao de variveis de classe.
Um objeto alocado explicitamente por intermdio da mensagem new. No
entanto, no existem mecanismos para especificao de destruio de um objeto. Fazse a utilizao de uma tcnica de recuperao automtica de memria garbage
collection, tornando o processo de destruio de objetos transparente ao usurio.
O mecanismo de herana simples, uma vez que uma subclasse derivada de
apenas uma superclasse direta e muitas classes podem compartilhar a mesma
superclasse, resultando em uma hierarquia em forma de rvore. O ambiente Smalltalk
possui uma biblioteca de classes contendo uma hierarquia concebida na definio do
sistema. A esta biblioteca novas classes podem ser adicionadas pelos usurios. Desta
maneira, o programador Smalltalk sempre cria uma nova classe como sendo uma
subclasse de uma classe j existente. Uma classe do sistema, chamada Object e que
a nica no sistema a no possuir superclasse, descreve as similaridades de todos os
objetos do sistema. Portanto, toda classe dever pelo menos ser subclasse de Object.
Um programa em SmallTalk uma expresso ou uma seqncia de expresses
separadas pelo smbolo . (ponto). Expresses podem ser:
1. um literal (objeto constante como nmeros, caracteres, cadeias e vetores
compostos por literais);
2. uma varivel (referncia a um objeto);
3. um envio de mensagem;
4. um bloco (uma seqncia, delimitada por colchetes, de expresses
separadas por ., cuja ao postergada).
24
Na Figura 4.2. pode-se ver um trecho de programa em SmallTalk onde so

definidas as classes Empregado e Gerente.
class name
Empregado
superclass
Object
Instance variable names
nome
salario
class variable names
NumeroDeEmpregados
class methods
initialize
NumeroDeEmpregados := 0
new
| newEmp |
newEmp := super new.
NumeroDeEmpregados := NumeroDeEmpregados + 1.
^newEmp
instance methods
atualizaNome: umNome
nome := umNome
nome
^nome
atualizaSalario: umSalario
salario := umSalario
salario
^salario
class name
Gerente
superclass
Empregado
Instance variable names
comissao
25
instance methods
atualizaComissao: umaComissao
comissao := umaComissao
salario
^(salario + comissao)
Figura 4.2. Definio de classes em SmallTalk

Na Figura 4.3 est listado um trecho de programa que retorna a quantidade de
nmeros mpar em um vetor.
| v nOdd |
v := #(1 5 2 3 6).
nOdd := 0.
v do: [:elem | elem odd ifTrue: [nOdd := nOdd + 1 ]].
v at: 1 put: nOdd.
^nOdd
Figura 4.3. Programa exemplo em SmallTalk
4.2. A linguagem de programao C++

A linguagem de programao C++ foi desenvolvida a partir da linguagem
procedimental C, acrescentando a idia de tipos abstratos de dados e fornecendo o
mecanismo de herana para proporcionar o suporte programao orientada a
objetos. As preocupaes da linguagem C com as questes de eficincia do cdigo
gerado, flexibilidade e portabilidade permaneceram presentes em C++. Existe tambm
o compromisso de compatibilidade com a linguagem C. Portanto, as construes
usuais em C devero ser tratadas pelo compilador C++.
O conceito de tipos abstratos de dados implementado atravs da construo
de classes. As classes especificam um conjunto de objetos (instncias da classe) que
possuem caractersticas comuns (variveis de instncia e operaes). Em C++ a
declarao de uma classe pode ser dividida em trs sees com o objetivo de controlar
a visibilidade dos elementos da classe:
Privada (private), que limita a manipulao das variveis de instncia e
operaes apenas s rotinas da prpria classe, ou seja, aquelas rotinas
definidas na declarao da classe, exceto o caso das funes amigas,
descrito mais adiante;
Protegida (protected), que estende o acesso aos elementos da classe a
todas as suas subclasses;
Pblica (public), que define a interface das instncias da classe. Todos os
elementos declarados nesta seo esto disponveis aos clientes da classe.
26
Vale salientar que, se variveis de instncia so declaradas como pblicas,

torna-se possvel trat-las diretamente, ou seja, no necessria a
invocao de operaes para fazer acessos. Desta forma, uma varivel de
instncia pode ser vista como uma componente de uma estrutura (struct) em
C.
As variveis de instncia declaradas em uma classe possuem um tipo
associado, uma vez que a declarao feita da mesma forma como em C. O conceito
de varivel de classe existente na linguagem Smalltalk implementado atravs da
clusula static, isto , uma varivel declarada como static torna-se disponvel a todas
as instncias de uma classe, havendo um compartilhamento do mesmo dado. As
operaes, mtodos do Smalltalk, so implementadas como funes em C, sendo
permitida a sobrecarga de identificadores, isto , pode existir a definio de duas ou
mais funes com o mesmo nome, sendo a distino feita atravs do tipo e/ou do
nmero de argumentos. O acesso a objetos de uma classe pode ser restrito s funes
que so declaradas como parte da classe do objeto. Tais funes so chamadas de
funes membros. Alm de funes membros, funes declaradas como amigas da
classe esto autorizadas a manipular elementos privados e protegidos da classe sem
pertencer ao escopo desta classe. Tambm existe a possibilidade de fazer com que
todas as funes de uma classe sejam amigas de outra classe, resultando em uma
relao de amizade entre classes. Com este conceito de amizade, C++ compromete a
filosofia de tipos abstratos de dados, violando o encapsulamento de informao.
A criao e iniciao de objetos so feitas por intermdio de funes membros
especialmente declaradas com este objetivo, denominadas construtores. Um objeto
pode ser criado como:
Automtico: criado toda vez que sua declarao encontrada na execuo
do programa e destrudo quando o bloco em que ele ocorre deixado;
Esttico: criado no incio da execuo do programa e somente destrudo
quando o programa terminado;
Dinmico: Criado utilizando-se o operador new e destrudo atravs do
operador delete;
Membro: criado como membro de outra classe ou como elemento de um
vetor ou estrutura.
Funes membros existentes para a destruio de objetos so chamadas de
destruidores. Portanto, C++ no prov nenhum mecanismo para realizar a
recuperao automtica de memria garbage collection. O acesso a um membro de
uma classe feito de forma semelhante ao acesso de elementos de uma estrutura em
C. Ao contrrio de Smalltalk, a ligao de uma mensagem a um mtodo feita em
tempo de compilao, a menos que seja solicitada a ligao dinmica, no caso do
mtodo ser declarado como virtual. Uma funo membro declarada com virtual
especifica que poder existir uma redefinio em quaisquer das possveis subclasses.
A linguagem C++ suporta o conceito de herana mltipla. Assim, mais de
uma classe pode contribuir para a formao da estrutura e do comportamento das
instncias de uma classe. O programador pode definir classes que no so
especializaes de nenhuma outra. Classes deste tipo so chamadas bsicas. Para uma
classe que possui duas ou mais superclasses diretas a especificidade destas
27
superclasses na sua definio determinada atravs da ordem na qual as superclasses

esto relacionadas. A primeira delas a mais especfica. A questo de conflitos de
nomes foi resolvida atravs do operador de escopo (::).
Como os tipos existentes na linguagem C foram mantidos em C++, no tornase restrita a estruturao de dados apenas atravs de classes e a linguagem pode ser
utilizada sem estar associada programao orientada a objetos.
Na Figura 4.4. pode-se ver um trecho de programa em C++ onde so definidas
as mesmas classes Empregado e Gerente do exemplo em SmallTalk;
class empregado {
string* nome;
float salario;
static int numeroDeEmpregados;
public:
empregado();
~empregado() { numeroDeEmpregados--; }
void atualizaNome(string* umNome) { nome = umNome; }
string* obtemNome() { return nome }
void atualizaSalario(float umSalario) { salario = umSalario; }
float obtemSalario() { return salario }
};
int empregado::numeroDeEmpregados = 0;
empregado::empregado() {
nome = NULL;
salario = 0.0;
numeroDeEmpregados++;
}
class gerente : public empregado {

float comissao;
public:
gerente() { comissao = 0.0; }
void atualizaComissao(float umaComissao) { comissao = umaComissao; }
float obtemSalario();
}
float gerente::obtemSalario();
return (document::obtemSalario() + comissao);
}
Figura 4.4. Definio de classes em C++
4.3. A linguagem de programao Object Pascal

A linguagem Object Pascal uma extenso linguagem procedimental Pascal,
suportando os conceitos do paradigma de orientao a objetos. Object Pascal foi
28
criada por desenvolvedores da Apple Computer e em 1986 tornou-se pblica como a

linguagem a ser suportada pelo ambiente de desenvolvimento da famlia de
computadores Macintosh, da Apple. Teve um grande impulso em 1995, quando a
Borland lanou o Delphi, um ambiente para programao para Windows que a utiliza
como linguagem de programao para o desenvolvimento de aplicaes.
Object Pascal suporta completamente os conceitos de POO. Permite a
definio de objetos, o gerenciamento de objetos por classes e o relacionamento de
classes atravs do mecanismo de herana. Suporta tambm a definio de mtodos
polimrficos, mas no permite a herana mltipla (como em SmallTalk e ao contrrio
de C++). Alm disso, no permitido polimorfismo paramtrico (o mesmo nome do
mtodo, diferenciado apenas pelo tipo ou quantidade de parmetros passados na
mensagem).
Alm do mecanismo bsico de encapsulamento obtido atravs dos objetos,
Object Pascal suporta o encapsulamento em outro nvel, atravs de units. Units so
mdulos dentre dos quais pode-se definir quaisquer elementos de Object Pascal, como
variveis, objetos, procedimentos, exceto outra unit. Uma unit implementa o
ocultamento de informao em dois nveis de visibilidade: interface e implementao
(implementation). Na interface so declarados os dados, procedimentos e funes
visveis fora da unit. Na implementao so declaradas as caractersticas visveis
somente no interior da unit.
importante frisar que Object Pascal uma linguagem de propsito geral,
podendo ser empregada para desenvolver os mais variados tipos de aplicaes, desde
sistemas em tempo real que controlam uma indstria, at um sistema de informaes
de uma loja de departamentos. O que faz a diferena so as bibliotecas de classes
disponveis para um certo domnio de aplicao. No ambiente Delphi, as bibliotecas
de classes para Object Pascal esto direcionadas para o desenvolvimento de sistemas
de informao em arquiteturas cliente/servidor.
Em Object Pascal todos as classes so descendentes da classe TObject, de
modo que as funes bsicas de manipulao de objetos so tratadas nessa classe
genrica (como o construtor e destrutor das instncias). Se em uma declarao de
classe for omitida a superclasse, automaticamente ela ser subclasse de TObject.
Os componentes de uma classe so:
Campos: definem os itens de dados que existem em cada instncia da
classe. Isto similar a um campo de um registro (estrutura composta).
Mtodos: um procedimento ou funo que efetua alguma operao em um
objeto. Existem mtodos especiais que so o construtor e o destrutor. O
construtor define as aes associadas com a criao de um objeto
(inicializaes, alocao de memria, etc.). O destrutor descreve as aes a
serem tomadas quando o objeto destrudo, com a liberao de memria.
Propriedades: so atributos para os quais so definidas aes para a sua
leitura e escrita.
O ocultamento de informao nas classes de Object Pascal implementado em
cinco nveis, utilizando os seguintes atributos de visibilidade:
29
Public: os componentes declarados na seo public de uma classe no tm

nenhuma restrio quanto sua visibilidade
Published: as regras de visibilidade so idnticas s de public. A diferena
est no fato de que gerado informao de tipagem em tempo de execuo
para campos e propriedades da seo published.
Automated: as regras de visibilidade so idnticas s de public. A diferena
est no fato de que gerado informao de tipagem para automao para
mtodos e propriedades da seo automated. Esta informao torna
possvel a criao de servidor OLE (Object Linking and Embedding).
Protected: os componentes declarados na seo protected de uma classe
somente podem ser vistos dentro da prpria classe e suas descendentes.
Private: a visibilidade dos componentes declarados na seo private de uma
classe restrita ao mdulo (unit) que contem a declarao da classe. Ou
seja, em todo o escopo da unit, pode-se acessar os componentes declarados
na seo private.
Programas escritos em Object Pascal podem seguir a sintaxe e semntica
tradicional da programao procedimental em Pascal, ou seja, o seu compilador,
compila programas que no utilizem as tcnicas de POO. A grande vantagem dos
ambientes que fornecem bibliotecas de classes pr-definidas est no fato de que se
obtm os benefcios da POO sem utiliz-la conscientemente. O ambiente
customizado e a programao auxiliada pelas tcnicas de POO embora o
programador no se d conta disso. O Delphi utiliza este conceito.
unit Empregado;
interface
type
TEmpregado = class
protected
Nome: string[30];
Salario: real;
public
constructor Create;
destructor Destroy;
procedure AtualizaNome (umNome: string);
function ObtemNome: string;
procedure AtualizaSalario (umSalario: real);
function ObtemSalario: real;
class procedure Inicializa;
end;
TGerente = class (TEmpregado)
private
Comissao: real;
public
constructor Create;
procedure AtualizaComissao (umaComissao: real);
function ObtemSalario: real;
30
end;
implementation
var
NumeroDeEmpregados: integer;
class procedure TEmpregado.Inicializa;
begin
NumeroDeEmpregados := 0;
end;
constructor TEmpregado.Create;
begin
inherited Create;
Nome := '';
Salario := 0.0;
NumeroDeEmpregados := NumeroDeEmpregados + 1;
end;
destructor TEmpregado.Destroy;
begin
inherited Destroy;
NumeroDeEmpregados := NumeroDeEmpregados - 1;
end;
procedure TEmpregado.AtualizaNome (umNome: string);
begin
Nome := umNome;
end;
function TEmpregado.ObtemNome: string;
begin
ObtemNome := Nome;
end;
procedure TEmpregado.AtualizaSalario (umSalario: real);
begin
Salario := umSalario;
end;
function TEmpregado.ObtemSalario: real;
begin
ObtemSalario := Salario;
end;
constructor TGerente.Create;
begin
inherited Create;
Comissao := 0.0;
end;
procedure TGerente.AtualizaComissao (umaComissao: real);
begin
31
Comissao := umaComissao;
end;
function TGerente.ObtemSalario: real;
begin
ObtemSalario := Salario + Comissao;
end;
end.
Figura 4.5. Definio de classes em Object Pascal
5. O paradigma de orientao a objetos

O paradigma de orientao a objetos apresenta a caracterstica fundamental de
unificar os esforos no desenvolvimento de sistemas. Nas sees acima foram
abordados os aspectos tericos da orientao a objetos, com nfase na programao.
Aqui ser abordado o assunto de maneira mais ampla, apresentando como os vrios
nveis de tcnicas, modelos e ambientes esto evoluindo em torno da orientao a
objetos.
5.1. Desenvolvimento Orientado a Objetos

O desenvolvimento de sistemas orientado a objetos envolve a utilizao de
metodologias bem definidas e sedimentadas. A metodologia consiste na construo de
um modelo de um domnio de aplicao e na posterior adio a este dos detalhes de
implementao durante o projeto de um sistema.
Uma Metodologia Orientada a Objeto (MOO) para desenvolvimento de
sistemas, consiste basicamente de: notaes grficas, processos e ferramentas.
Alm disso uma boa metodologia deveria prover (nem todas abordam os aspectos
abaixo):
Orientao para estimativa de custos;

Aspectos de gerenciamento de projetos;
Medidas para controle correticidade
Procedimentos e polticas para garantia de qualidade de software
Descries de papis (funes desempenhadas por pessoas) e programas de
treinamento detalhados
Exemplos completos (trabalhados no mundo real)
Exerccios de treinamento;
Tcnicas bem definidas para utilizao do mtodo
Existem atualmente algumas Metodologias Orientadas a Objetos que podem

ser consultadas em livros ou publicaes especializadas, entre as quais pode-se citar:
Metodologia de Berard, consistindo de:
32
Berard, E. V., Essays on Object-Oriented Software Engineering, v. 1,

Prentice Hall, 1993.
Berard, E. V., A Project Management Handbook for Object-Oriented
Software Development, Berard Software Engineering, Inc., 1992.
Metodologia de Booch, consistindo de:
Booch,
G.,
Object-Oriented
Benjamin/Cummings, 1991.
Design
With
Applications,
Metodologia de Colbert, consistindo de:

Colbert, E., "The Object-Oriented Software Development Method: A Practical
Approach to Object-Oriented Development," Anais de TRI-Ada '89, ACM,
out. 1989.
Metodologia de Coad e Yourdon, consistindo de:
Coad, P. & Yourdon, E, Object-Oriented Analysis, Prentice Hall, 1990.
Coad, P. & Yourdon, E, Object-Oriented Design, Prentice Hall, 1990.
Metodologia de Embley e Kurtz, consistindo de:
Embley, D.W. et al., Object-Oriented Systems Analysis, A Model-Driven
Approach, Yourdon Press/Prentice Hall, 1992.
Metodologia da IBM, consistindo de:
IBM, Object-Oriented Design: A Preliminary Approach - Documento
GG24-3647-00, IBM International Technical Support Center, 1990.
IBM, Object-Oriented Analysis of the ITSO Common Scenario Documento GG24-3566-00. IBM International Technical Support Center,
1990
Metodologia de Martin e Odell, consistindo de:
Martin, J., & Odell, J.J., Object-Oriented Analysis and Design, Prentice
Hall, 1992.
Metodologia de Rumbaugh, consistindo de:
Rumbaugh, M. et al, Object-Oriented Modeling and Design, Prentice Hall,
1991.
Metodologia de Shlaer e Mellor, consistindo de:
Shlaer, S. & Mellor, S.J., Object-Oriented Systems Analysis: Modeling the
World In Data, Yourdon Press/Prentice Hall, 1988.
Shlaer, S. & Mellor, S.J., Object-Oriented Systems Analysis: Modeling the
World In States, Yourdon Press/Prentice Hall, 1992.
33
Metodologia de Wirfs-Brock, consistindo de:

Wirfs-Brock, R. et al, Designing Object-Oriented Software, Prentice Hall,
1990.
Na seo 5.4 ser apresentada resumidamente a metodologia de Rumbaugh,
conhecida como Tcnica de Modelagem de Objetos (TMO).
5.2. Anlise Orientada a Objetos

A anlise responsvel pelo desenvolvimento de uma representao, a mais
completa, concisa, correta e legvel possvel do domnio do problema. O analista parte
do enunciado do problema, e constri um modelo da situao do mundo real,
mostrando suas propriedades relevantes. O analista deve trabalhar em conjunto com o
usurio para entender o problema uma vez que as definies dos problemas raramente
so completas ou corretas.
O modelo de anlise uma abstrao concisa e precisa do que o sistema
desejado dever fazer, no como o sistema dever faz-lo. Os objetos do modelo
devem ser conceitos do domnio da aplicao e no conceitos de implementao
computacional, como, por exemplo, estruturas de dados. Um bom modelo pode ser
compreendido e criticado por peritos em aplicaes que no sejam programadores. O
modelo de anlise no deve conter quaisquer decises de implementao.
A Anlise Orientada a Objetos (AOO) empenha-se em entender e modelar, em
termos de conceitos de orientao a objetos (objetos, classes, herana) um
determinado problema dentro de um domnio de problema. Isto dentro de uma
perspectiva do usurio ou de um especialista sobre o domnio em questo e com
nfase em modelar o mundo real. O produto, ou modelo resultante, da AOO
especifica um sistema completo e um conjunto integral de requisitos (especificaes)
e a interface externa do sistema a ser construdo.
Mtodos convencionais de anlise de sistemas (DeMarco, Yourdon, Gane &
Sarson, Shlaer & Mellor) distanciam-se da forma de pensar das pessoas. J os
orientados a objetos facilitam a interao analista/usurio, pois modelam o mundo
identificando classes e objetos que formam o vocabulrio do domnio do problema.
Como resultado, possvel a modelagem de domnios de problemas mais desafiadores
com resultados de anlise mais consistentes.
A anlise orientada a objetos facilita a representao explcita dos pontos
comuns do domnio da aplicao, atravs do uso de mecanismos de estruturao
(herana, composio, classificao). So elaboradas especificaes que facilitam as
alteraes que se fazem constantemente necessrias devido a mudanas de requisitos.
Existe tambm o potencial para reutilizao de resultados obtidos em anlises
anteriores, principalmente num mesmo domnio de aplicao. Isto leva a uma melhor
qualidade dos sistemas desenvolvidos. O resultado de um processo de AOO facilita o
entendimento do sistema para a etapa de projeto.
5.3. Projeto Orientado a Objetos

34
A etapa de projeto o processo de mapear os requisitos de sistema definidos

durante a etapa de anlise para uma representao abstrata de uma implementao
especfica do sistema, dentro de restries de custo e desempenho. O projetista de
sistemas toma decises de alto nvel relativamente arquitetura geral. Durante o
andamento do projeto, o sistema alvo organizado em subsistemas baseados tanto na
estrutura da anlise quanto na arquitetura proposta. O projetista de sistemas deve
decidir quais caractersticas de desempenho devem ser otimizadas, escolher a
estratgia de ataque ao problema e realizar alocaes experimentais de recursos.
Projeto Orientado a Objetos (PrOO) um mtodo de projeto que incorpora um
processo de decomposio orientado a objetos e uma notao para descrever um
modelo lgico e fsico, bem como esttico e dinmico do sistema projetado. Existem
duas partes importantes nesta definio:
O PrOO leva a uma decomposio orientada a objetos do sistema
Utiliza uma notao para expressar os diferentes modelos dos projeto
lgico e fsico do sistema
o suporte para decomposio orientada a objetos que torna o projeto
orientado a objetos bastante diferente do projeto estruturado. Aquele usa classes e
objetos como abstraes para estruturar logicamente os sistemas, enquanto este usa
abstraes de funes para estruturao.
As metodologias orientadas a objetos utilizam uma progresso de AOO para
PrOO para POO. Um domnio de problema tem muitas possveis realizaes, ou
diferentes AOOs (depende de quem realiza a anlise). Uma AOO tem muitas
possveis realizaes, ou diferentes PrOOs, mas uma notao similar utilizada
para anlise e projeto. Um PrOO tem tambm muitas realizaes, ou diferentes POOs,
mas permite que haja uma seleo de ma linguagem especfica entre vrias (ou seja,
escolher a melhor linguagem para implementar o projeto). A maneira como a
progresso encaminhada e como so escolhidas as realizaes depende da
metodologia utilizada e do contexto com o qual a equipe de desenvolvimento tem que
trabalhar.
A diferena entre anlise e projeto pode, s vezes, parecer arbitrria e confusa.
Mas, existem algumas regras simples que podem auxiliar a nas decises com relao
ao escopo correto da anlise e do projeto.
O modelo da anlise deve incluir informaes significativas sob a perspectiva
do mundo real e apresentar a viso externa do sistema. O modelo da anlise deve ser
compreensvel para o cliente do sistema, devendo fornecer uma base til para
evidenciar os verdadeiros requisitos de um sistema. Os requisitos verdadeiros so
aqueles realmente necessrios, internamente consistentes e possveis de serem
atingidos.
Em contraste, o modelo do projeto depende da relevncia para implementao
em computador. Assim, ele deve ser razoavelmente eficiente e de codificao prtica.
Na prtica, muitas partes do modelo da anlise podem, freqentemente, ser
implementados prontamente, sem necessidade de modificaes; desse modo pode
haver uma considervel sobreposio dos modelos de anlise e de projeto. O modelo
de projeto deve mencionar detalhes de nveis inferiores que so omitidos no modelo
35
de anlise. Os dois modelos combinam-se para fornecer uma valiosa documentao de

um sistema, sob duas perspectivas diferentes, porm complementares.
5.4. Tcnica de Modelagem de Objetos

A Tcnica de Modelagem de Objetos (TMO) uma metodologia proposta por
Rumbaugh onde o processo de desenvolvimento se baseia na construo de trs
modelos (Modelo de Objetos, Modelo Dinmico e Modelo Funcional), que descrevem
o sistema em estudo, oferecendo trs vises diferentes e complementares do mesmo.
Est baseada na modelagem de objetos do mundo real e independente da linguagem
de programao utilizada na implementao. A metodologia tem as seguintes etapas:
anlise, projeto do sistema, projeto dos objetos e implementao.
5.4.1. Anlise
O objetivo da anlise desenvolver um modelo do que o sistema ir fazer.
Este modelo expresso em termos de objetos e relacionamentos, fluxo de controle
dinmico e transformaes funcionais. O processo de obteno dos requisitos e de
discusses com o usurio solicitante deve manter-se durante toda a anlise.
Neste fase, a entrada a prpria descrio do problema e a sada um modelo
formal do mesmo. Os passos para realizar a anlise so os seguintes:
Escrever ou obter uma descrio inicial do problema

Construir um Modelo de Objetos
Desenvolver um Modelo Dinmico
Construir um Modelo Funcional
Verificar, repetir e refinar os trs modelos
O Modelo de Objetos
O modelo de objetos descreve a estrutura de objetos de um sistema - sua
identidade, seus relacionamentos com outros objetos, seus atributos e suas operaes.
o mais importante dos trs modelos, pois enfatiza a construo da arquitetura lgica
do sistema, tendo como base os objetos e seus relacionamentos, que em geral so as
partes mais estveis de um sistema. O modelo de objetos proporciona a estrutura
necessria sobre a qual podem ser colocados os modelos dinmico e funcional.
A notao utilizada para descrio deste modelo , na verdade, uma extenso
da notao empregada no Modelo Entidade-Relacionamento (MER), pois combina os
conceitos de orientao a objetos (classes e herana) e da modelagem da informao
(entidades e associaes). Possui as seguintes caractersticas:
Utiliza grafos cujos ns representam classes de objetos e os arcos
representam relacionamentos.
As classes so organizadas em hierarquias. Elas definem os valores dos
atributos carregados por cada objeto e definem as operaes que cada
objeto faz ou recebe.
36
Proporciona uma estrutura de dados, onde o modelo funcional e dinmico

podem ser alocados
Possui uma estrutura esttica
O Modelo de Dinmico
Descreve os aspectos temporais e comportamentais do sistema, capturando o
controle e o seqenciamento de operaes. Deve definir quais so os estmulos
enviados aos objetos e quais as suas respostas. Suas caractersticas so as seguintes:
Utiliza diagramas de transio de estados (DTE). Estes diagramas so
grafos, onde os ns so estados e os arcos dirigidos representam transies
entre estados, sendo causados por eventos.
formado por uma coleo de DTEs que interagem uns com os outros.
A representao grfica mostra o estado e a seqncia de transies de
estados vlidas no sistema para uma classe de objetos.
Possui uma estrutura de controle.
O Modelo Funcional
Descreve os aspectos de transformao dos dados dentro do sistema. Deve
determinar quais so as computaes que cada objeto executa atravs de suas
operaes. Seu objetivo e caractersticas so o seguinte:
Identificar os valores de entrada e sada da declarao do problema e
mostrar as dependncias entre os valores de entrada e a computao
necessria para gerar a sada desejada.
Utiliza diagramas de fluxo de dados (DFD).
Preocupa-se com o que o sistema faz, sem se preocupar como ou quando
faz.
Possui um estrutura computacional.
Fornece uma descrio de cada funo.
Identifica restries entre objetos e especifica critrios de otimizao.
5.4.2. Projeto do sistema

Durante o projeto do sistema determinada a estrutura de alto nvel do
sistema. Vrias arquiteturas cannicas podem ser utilizadas como ponto de partida. O
paradigma de orientao a objetos no apresenta novidades especiais em termos de
projeto de sistemas. Algumas caractersticas so:
Organizar o sistema em subsistemas

Identificar concorrncias inerentes ao problema
Alocar subsistemas a processadores e tarefas
Escolher a estratgia bsica para implementao dos depsitos de dados em
termos de estruturas de dados, arquivos e bancos de dados.
Identificar os recursos globais e determinar mecanismos para controlar o
acesso a eles.
Considerar condies externas e estabelecer prioridades
37
5.4.3. Projeto dos Objetos

O projeto de objetos um modelo baseado no modelo da anlise, mas
contendo detalhes de implementao. O projetista acrescenta detalhes ao modelo do
projeto de acordo com a estratgia estabelecida durante o projeto do sistema. O
enfoque do projeto de objetos so as estruturas de dados e os algoritmos necessrios
implementao de cada classe.
As classes de objetos provenientes da anlise ainda so significativas, mas so
acrescidas das estruturas de dados do domnio do computador e algoritmos escolhidos
para otimizar medidas importantes de desempenho. No projeto de objetos ainda
ajustada a estrutura de classes para aperfeioar a herana; concretizado o projeto e
implementao das associaes; determinada a representao exata dos atributos dos
objetos e arrumadas as classes e associaes em mdulos.
5.5. Bancos de Dados Orientados a Objetos

Bancos de Dados Orientados a objetos (BDOO) so bancos de dados que
suportam objetos e classes. Eles so diferentes dos bancos de dados relacionais mais
tradicionais porque permitem uma estruturao com sub-objetos, cada objeto tendo a
sua prpria identidade, ou identificador de objeto (ao contrrio do modelo relacional,
onde a abordagem orientado a valores). possvel tambm proporcionar operaes
relacionais em um BDOO. BDOOs permitem todos os benefcios da orientao a
objetos, assim como tm uma forte equivalncia com os programas orientados a
objetos. Esta equivalncia perdida se outra alternativa for escolhido, como um
banco de dados puramente relacional.
Um BDOO deve satisfazer, no mnimo, aos seguintes requisitos:
Deve prover funcionalidade de banco de dados. Como tal, podem ser
apresentadas: modelo e linguagem no-trivias, ou seja deve entender
alguma estrutura nos dados e prover uma linguagem para manipular esses
dados; relacionamentos entre os objetos; persistncia, ou seja os dados
devem poder ser acessados aps o trmino do processo que os criou;
compartilhamento; tamanho arbitrrio; entre outras
Deve suportar identidade de objetos, atravs do identificador de objetos,
que utilizado para localizar com preciso um objeto a ser recuperado.
Deve prover encapsulamento, que a base sobre a qual objetos abstratos
so definidos.
Deve suportar objetos com um estado complexo. O estado de um objeto
pode se referir a outros objetos, que por sua vez podem ter referncias a
outros objetos, e assim por diante.
Deve suportar transaes longas, que podem durar horas ou dias,
envolvendo um ou mais usurios (por exemplo, a edio de trechos de
programa em um ambiente multiusurio).
Com relao incluso da herana os conceitos de BDOO, existem muitas
divergncias, pois sua implementao apresenta alguns problemas no triviais.
38
Embora a herana seja considerada a contribuio original do paradigma de

orientao a objetos, algumas linhas de pensamento preferem retir-la dos BDOOs.
BDOOs devem ser utilizados como repositrio final de dados em uma
metodologia de desenvolvimento que utiliza a AOO, o PrOO e a POO. Embora j
existam BDOOs comercialmente disponveis, as opes so poucas e a tecnologia no
est ainda sedimentada. Por este motivo, no so utilizados em grande escala,
reduzindo-se a universidades e ambientes de pesquisa. Este fato traz problemas
utilizao de uma metodologia totalmente orientada a objetos, pois no momento do
armazenamento dos dados necessria uma converso (para o modelo relacional, por
exemplo), onde perdida grande parte dos benefcios do paradigma.
Existem algumas aplicaes, no entanto, que se beneficiam sobremaneira da
utilizao de BDOO, principalmente aquelas cujos dados no so facilmente
estruturados em tabelas, como aplicaes CAD (Computer-Aided Design - Projeto
Auxiliado por Computador), CASE (Computer-Aided Software Enginering) e
tambm os Sistemas de Automaco de Escritrios, entre outras. Essas aplicaes de
projeto impem uma demanda muita alta nas tecnologias convencionais de bancos de
dados., incluindo a capacidade de modelar dados muito complexos e a capacidade de
evoluo da base de aplicao sem efeitos negativos. Essa demanda por sua vez
impem requisitos no sistema de prover um nvel apropriado de escalabilidade das
aplicaes (ver vantagens da orientao a objetos, seo 3.1) para capturar facilmente
semnticas de dados especficas e mecanismos para o desenvolvimento incremental
de estruturas de bancos de dados.
5.6. Outras utilizaes da Orientao a Objetos

Como um paradigma unificador, vrias vertentes de computao esto
convergindo para a orientao a objetos, em busca dos benefcios j citados.
5.6.1. Reengenharia de Processos Orientada a Objetos

A Reengenharia de Processos Orientada a Objetos (RPOO) procura redesenhar
os processos bsicos da empresa com nfase em objetos, identificando os domnios de
aplicao e as principais classes de objetos e seus relacionamentos. Uma vez que a
empresa como um todo est modelada de acordo com o paradigma de orientao a
objetos, o desenvolvimento de sistemas torna-se uma continuao de um processo
muito mais amplo, que se iniciou na prpria concepo da empresa. A grande
vantagem a viso da empresa inteira como objetos que se comunicam atravs de
mensagens.
Nestes casos, o processo de identificao dos objetos bsicos de um sistema
executada na fase de AOO torna-se mais rpido, conciso e confivel. A RPOO pose
ser vista como uma etapa inicial na progresso determinada pela metodologia
orientada a objetos, antecedendo a AOO.
Uma das experincias mais interessantes da utilizao da RPOO no Brasil a
vivida pelo Banco Bamerindus, que investiu uma grande quantidade de tempo e
dinheiro envolvendo pessoal extremamente qualificado do pas e do exterior para
reprojetar completamente as suas atividades. A partir a modelagem obtida na RPOO
39
foi empregada uma metodologia de desenvolvimento orientada a objetos, em conjunto

com todas as tecnologias disponveis atualmente para este tipo de aplicao.
5.6.2 Ambientes de Desenvolvimento de Software Orientados a

Objetos
A definio de um Ambiente de Desenvolvimento de Software (ADS) pode
ser utilizada para representar vrias ferramentas de apoio ao desenvolvimento de
sistemas, desde ferramentas bsicas de programao at sistemas CASE integrados.
Em geral, um ADS pode ser definido como uma coleo de ferramentas integradas
segundo um esquema extensvel, destinadas a suportar tarefas tcnicas e
administrativas de desenvolvimento de software em larga escala, envolvendo a
interao de pessoas e grupos no necessariamente prximos, segundo um mtodo de
desenvolvimento de software que componha um ciclo qualquer completo, desde a
definio de requisitos at a manuteno.
Em geral, difcil encontrar ambientes completos que atendam aos requisitos
da definio apresentada. Existem alguns esforos em reas dispersas, como o caso
dos ambientes de programao orientados a objetos. O Delphi implementa tal
ambiente, que utiliza a linguagem Object Pascal para dar suporte a um ambiente
facilmente amigvel e extensvel devido a orientao a objetos. O Delphi implementa
uma biblioteca de classes para o Object Pascal para as tarefas de programao visual
em Windows, permitindo que o ambiente seja customizado dentro dele mesmo, com
os seus prprios recursos (leia-se herana).
5.6.3 Interfaces Grficas de Usurio Orientadas a Objetos

As interfaces de usurio muito se beneficiaram da orientao a objetos. Muitos
sistemas de informao (aplicativos) e at sistemas operacionais oferecem atualmente
interfaces que aos olhos do usurio so orientadas a objetos, que obviamente so
grficas, formando ento uma GUI (Graphical User Interface). O usurio seleciona
um objeto (uma janela, um cone, etc.) e ento dispe de vrias operaes que o
objeto suporta. A orientao a objetos est presente tambm (e talvez de forma mais
importante) na implementao da interface contribuindo de maneira significativa para
a reduo dos problemas devidos a construo de GUIs.
5.6.4 Sistemas Operacionais Orientados a Objetos

Os Sistemas Operacionais Orientados a Objetos provm recursos bsicos
atravs de objetos. Algumas vezes chegando at a gerenciar a mquina em si sob este
paradigma, no caso de arquiteturas orientadas a objetos (como a projeto SOAR SmallTalk On a Risc). Eles so quase sempre sistemas distribudos, permitindo que
objetos viajem livremente entre as mquinas. Tais sistemas so tipicamente baseados
em permisses (capabilities) desde que os objetos, e dessa forma os recursos do
sistema, somente podem ser acessados se os programas possuem as devidas
permisses. Existem atualmente vrios sistemas operacionais orientados a objetos,
como Chorus, Choises, GEOS, Mach, SOS e Spring (Sun).
40
6. Bibliografia
Coad, P. & Yourdon, E., Object-Oriented Analysis, Prentice Hall, 1990.
Hathaway, B., Object-Orientation FAQ (Frequently-Asked Question), World-Wide
Web: (http://iamwww.unibe.ch), 1996.
Kamienski, F. V., Programao Orientada a Objetos, Relatrio Tcnico, IMECCUnicamp, fev. 1992.
Korson, T. & McGregor, J. D., Understanding Object-Oriented: A Unifying
Paradigm, Communications of the ACM, v. 33, n. 9, set. 1990.
Martin, J. Princpios de Anlise e Projeto Baseados em Objetos, Editora Campus,
1994.
Motta, G. H. M. B., Introduo Orientao a Objetos: Programao, Projeto,
Anlise e Bancos de Dados, material particular, 1995.
Motta, G. H. M. B., Programao Orientada a Objetos com Delphi, material
particular, 1995.
Rumbaugh, J. et al, Modelagem e Projetos Baseados a Objetos, Editora Campus,
1994.
Sebesta, R. W., Concepts of Programming Languages, Benjamin/Cummings, 1989.
Stroustrup, B., The C++ Programming Language, Addison-Wesley, 1986.
Takahashi, T., Liesenberg, H. K. E. & Xavier, D. T., Programao Orientada a
Objetos, VII Escola de Computao, So Paulo, 1990.
The Object Agency, Inc., A Comparison of Object-Oriented Development
Methodologies, World-Wide Web: (http://www.toa.com), 1995.
Todd, B. & Kellen, V., Delphi: A Developers Guide, M&T Books, 1995.
Wegner, P., Concepts and Paradigms of Object Oriented Programming, ACM
Object-Oriented Messenger, v. 1, n. 1, 1990.
Zdonik, S. B. & Maier, D., Readings in Object-Oriented Database Systems, Morgan
Kaufmann, 1990.
41

Apostila Poo

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Apostila Poo

Diunggah oleh

Hak Cipta:

Format Tersedia

CENTRO FEDERAL DE EDUCAO TECNOLGICA DA PARABA

DIRETORIA DE ENSINO COORDENAO DE INFORMTICA

AUTOR: PROF. CARLOS ALBERTO KAMIENSKI

JOO PESSOA, JULHO DE 1996

Introduo ao Paradigma de Orientao a Objetos

Copyright 1996 - Carlos Alberto Kamienski CEFET-PB - verso preliminar

Introduo ao Paradigma de Orientao a Objetos

1.1. Por que estudar o paradigma de orientao a objetos ?

1.2. A natureza das novas aplicaes

Introduo ao Paradigma de Orientao a Objetos

1.3. O desafio das novas tecnologias

1.4. Os ambientes de programao modernos

Copyright 1996 - Carlos Alberto Kamienski - CEFET-PB - verso preliminar

Introduo ao Paradigma de Orientao a Objetos

Os ambientes de Desenvolvimento de Software tm evoludo muito nos

Introduo ao Paradigma de Orientao a Objetos

1.5. Programao Orientada a Objetos

Introduo ao Paradigma de Orientao a Objetos

2. Conceitos bsicos e terminologia

2.1. Abstrao de dados

Copyright 1996 - Carlos Alberto Kamienski - CEFET-PB - verso preliminar

Introduo ao Paradigma de Orientao a Objetos

A representao e definio do tipo e as operaes nos objetos do tipo so

Copyright 1996 - Carlos Alberto Kamienski - CEFET-PB - verso preliminar

Introduo ao Paradigma de Orientao a Objetos

Figura 2.1. Estrutura de um objeto

Figura 2.2. Outra representao para um objeto

Figura 2.3. O objeto Empregado

Introduo ao Paradigma de Orientao a Objetos

Benefcios proporcionados pelos objetos:

Figura 2.4. O envio de mensagens entre objetos

Copyright 1996 - Carlos Alberto Kamienski - CEFET-PB - verso preliminar

Introduo ao Paradigma de Orientao a Objetos

distintos ou ainda em mquinas distintas podem comunicar-se atravs do uso de

Introduo ao Paradigma de Orientao a Objetos

Um exemplo de utilizao de construtores e destrutores seria gerenciar a

Copyright 1996 - Carlos Alberto Kamienski - CEFET-PB - verso preliminar

Introduo ao Paradigma de Orientao a Objetos

Figura 2.5. Relacionamento entre classes e objetos

Introduo ao Paradigma de Orientao a Objetos

mais especializada, subclasse. No desenvolvimento de software, herana surge como

Figura 2.6. Herana na classe Empregado

Introduo ao Paradigma de Orientao a Objetos

uso. Alm disso, possvel acrescentar novas caractersticas que identificam um

Copyright 1996 - Carlos Alberto Kamienski - CEFET-PB - verso preliminar

Introduo ao Paradigma de Orientao a Objetos

Neste caso, Colaborador1, Gerente1 e Presidente1 so objetos das

Introduo ao Paradigma de Orientao a Objetos

Dependendo das caractersticas da linguagem e do tipo de polimorfismo

2.7. Relaes entre Objeto, Classe e Herana

Copyright 1996 - Carlos Alberto Kamienski - CEFET-PB - verso preliminar

Introduo ao Paradigma de Orientao a Objetos

a de instanciao de uma publicao (IBM PC, por exemplo) a partir da classe

Figura 2.7. Relao de classificao/instanciao

Figura 2.8. Relao de generalizao/especializao

Copyright 1996 - Carlos Alberto Kamienski - CEFET-PB - verso preliminar

Introduo ao Paradigma de Orientao a Objetos

classe Microcomputador so compostas por, entre outras, instncias das classes

Figura 2.9. Relao de composio/decomposio

3.1. Vantagens da POO

A reusabilidade de cdigo , sem dvida, reconhecida como a maior vantagem

Introduo ao Paradigma de Orientao a Objetos

aumentando, procura-se maneiras de desenvolver sistemas mais rapidamente, o que

3.2. Desvantagens da POO