Introdu

~ao a Analise Orientada a Objetos

Ce 
lia Mary Fis her Rubira

mrubirai .uni amp.br

http://www.i .uni amp.br/  mrubira

Fernando J. Castor de Lima Filho

fernandoi .uni amp.br

http://www.i .uni amp.br/  fernando

  
 
 










 







 




 






 













Instituto de Computa
~ao

2004
Sumario

Sumario i
Lista de Figuras i
Lista de Tabelas iii
1 Introdu ~ao 3
1.1 Estrutura ~ao de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Manejo da Complexidade do Software . . . . . . . . . . . . . . . . . . 4
1.1.2 Te ni as de Estrutura a~o de Software . . . . . . . . . . . . . . . . . . 4
1.1.3 Crise de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Objetos em Software: Ideias Basi as . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Abstra ~ao de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Classi a ~ao/Instan ia ~ao . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Generaliza ~ao/Espe ializa ~ao . . . . . . . . . . . . . . . . . . . . . . 9
1.2.4 Agrega ~ao/De omposi ~ao . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.5 Hierarquias de Abstra ~ao . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.6 Reusabilidade, Modularidade e Extensibilidade . . . . . . . . . . . . . 12
1.3 Linguagens de Programa ~ao Orientadas a Objetos . . . . . . . . . . . . . . . 13
1.3.1 Evolu ~ao da Abstra ~ao em Linguagens de Programa ~ao . . . . . . . . 14
1.3.2 Programa ~ao Orientada a Objetos . . . . . . . . . . . . . . . . . . . . 17
1.3.3 Linguagens Orientadas a Objetos vs Linguagens Baseadas em Objetos 18
1.4 Analise e Projeto Orientado a Objetos . . . . . . . . . . . . . . . . . . . . . 19
1.4.1 Desenvolvimento de Software Orientado a Objetos . . . . . . . . . . . 20
1.4.2 Metodologias Tradi ionais vs. Orientadas a Objetos . . . . . . . . . . 21
1.4.3 Limita ~oes do Modelo de Objetos . . . . . . . . . . . . . . . . . . . . 23
1.4.4 O Paradigma da Integra ~ao . . . . . . . . . . . . . . . . . . . . . . . 24
1.5 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.6 Exer  ios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Refer^en ias 28

i
ii
Lista de Figuras
1.1 Exemplo de Classi a ~ao/Instan ia a~o . . . . . . . . . . . . . . . . . . . . . 8
1.2 Classes e Objetos em UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Multipli idade de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Exemplo de Generaliza ~ao/Espe ializa a~o, . . . . . . . . . . . . . . . . . . . 9
1.5 Espe ializa a~o Simples em UML . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Espe ializa a~o Multipla em UML . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Exemplo de Agrega ~ao/De omposi ~ao . . . . . . . . . . . . . . . . . . . . . 10
1.8 Agrega ~ao e Composi ~ao em UML . . . . . . . . . . . . . . . . . . . . . . . 11
1.9 Exemplo de Heran a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.10 Passos Intermediarios da Modelagem da Realidade . . . . . . . . . . . . . . . 14
1.11 Classi a a~o de Wegner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.12 Ling. Orientadas a Objetos vs. Ling. Baseadas em Objetos . . . . . . . . . . 20
1.13 Modelo Cas ata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.14 Modelo Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.15 Desenvolvimento de Software orientado a objetos . . . . . . . . . . . . . . . 22
1.16 Compara ~ao entre Metodologias Tradi ionais vs. orientadas a objetos . . . . 23
1.17 Analise e Projeto orientado a objetos dividem-se em duas partes rela ionadas
{ a direita, modelos da estrutura do objeto (dados) e a esquerda, modelos do
seu omportamento (fun ~oes) . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.18 Integra ~ao do Modelo de Objetos om as Demais Te nologias . . . . . . . . . 25

iii
iv
Lista de Tabelas
1.1 Breve Historia de Orienta ~ao a Objetos . . . . . . . . . . . . . . . . . . . . . 17
1.2 Compara ~ao entre o Paradigma Pro edural e o de Objetos . . . . . . . . . . 19

1
2
Captulo 1
Introdu ~ao

Este aptulo dene e dis ute varios on eitos fundamentais de Te nologia de Objetos. A

evoli ~ao da Orienta ~ao a Objetos e tra ada atraves de desenvolvimentos previos em Lin-
guagens de Programa ~ao e Metodologias de Desenvolvimento de Software. Os paradigmas
de programa ~ao pro edural (ou imperativo) e o orientado a objetos s~ao omparados. Os
modelos tradi ionais de desenvolvimento de software s~ao tambem omparados a Orienta ~ao
a Objetos.

1.1 Estrutura
~
ao de Software

Sistemas de software modernos requerem um alto grau de onabilidade, disponibilidade e

seguran a. Alguns exemplo s~ao entrais telef^oni as, ban os de dados e sistemas distribudos,
ontrole de trens e de trafego aereo, et . Entretanto, a onstru a~o de sistemas de software
omplexos e uma tarefa dif il que exige o emprego de te ni as espe ializadas durante todo
o i lo de vida do sistema.
O modelo de objetos apresenta-se omo um modelo promissor para o desenvolvimento de
software onavel e robusto devido a ara tersti as inerentes ao proprio modelo de objetos,
tais omo, abstra ~ao de dados, en apsulamento, heran a e reutiliza a~o de objetos ( om-
ponentes). O uso de te ni as orientadas a objetos fa ilita o ontrole da omplexidade do
sistema porque promove uma melhor estrutura a~o de seus omponentes e tambem permite
que omponentes ja validados sejam reutilizados.

3
4 Cap
tulo 1: Introdu
~ao

1.1.1 Manejo da Complexidade do Software

Sistemas de software s~ao intrinsi amente ompli ados e t^em se tornado mais ompli ados
ainda om os novos requisitos impostos pelas apli a ~oes modernas: alta onabilidade, alto
desempenho, desenvolvimento rapido e barato, tudo isso asso iado a uma omplexidade
res ente. E possvel, e muitas vezes ate desejavel, ignorar a omplexidade dos sistemas de
software, mas isso n~ao faz om que essa omplexidade va embora; ela ertamente apare era
em algum lugar. Apli a ~oes de software que tratam de problemas ompli ados devem lidar
om tal omplexidade em alguma hora. Como seres humanos, nos empregamos varios me a-
nismos para \geren iar" essa omplexidade, tais omo abstra a~o, generaliza a~o e agrega ~ao.
Abstra ~ao e um meio pelo qual evitamos a omplexidade n~ao desejada e e uma das ferra-
mentas mais e ientes para lidarmos om o nosso mundo omplexo.
Cientistas de omputa ~ao ja re onhe eram ha algum tempo que a have para o su esso no
desenvolvimento de software esta no ontrole da sua omplexidade. O on eito de linguagens
de programa ~ao de alto nvel e seus ompiladores foi um grande passo em dire ~ao a este
objetivo pois permitiu que o desenvolvedor de software programasse sem pre isar ser um
espe ialista no fun ionamento do omputador. Depois disso, os pesquisadores e prossionais
ome aram a re onhe er a ne essidade de melhores ferramentas e metodologias para geren iar
a omplexidade; omo onsequ^en ia, surgiram os on eitos de programa a~o estruturada e
bibliote as de programas.
Embora essas ontribui ~oes tenham sido valiosas, elas ainda deixam muito a desejar. Em
outras palavras, existe uma omplexidade ainda maior do que simplesmente tentar minimizar
a omplexidade lo al de ada parte de um programa. Um tipo de omplexidade mais impor-
tante esta rela ionada om a omplexidade estrutural ou global: a ma ro omplexidade da
estrutura de um programa ou sistema (i.e., o grau de asso ia a~o ou interdepend^en ia entre
as prin ipais partes de um programa).
Podemos dizer que a omplexidade de um omponente ou subsistema de software e alguma
medida do esfor o mental requerido para entend^e-lo. De uma forma mais pragmati a, ela e
fun ~ao dos rela ionamentos entre os diversos omponentes do sistema. Complexidade e um
dos prin ipais fatores que ontribui para a produ ~ao de software de baixa qualidade e que
n~ao resolve adequadamente o problema que se prop~oe a resolver.

1.1.2 Te ni as de Estrutura ~ao de Software

Uma diferen a visvel entre uma estrutura de programa boa e ruim esta na omplexidade. Al-
guns on eitos da teoria de sistemas gerais podem ser apli ados para reduzir a omplexidade
em software, a saber[56℄:
Cap
tulo 1: Introdu
~ao 5

(i) parti ionamento do sistemas em partes que sejam muito bem limitadas (modularidade),

(ii) representa ~ao do sistema omo uma hierarquia, e

(iii) maximiza ~ao da independ^en ia entre as partes do sistema (baixo a oplamento e alta
oes~ao).

O parti ionamento de um programa em omponentes individuais pode reduzir a sua

omplexidade ate erto ponto. Embora esse parti ionamento seja util, uma justi ativa mais
plausvel para isso e que ele ria um numero de interfa es bem denidas dentro do programa.
Essas interfa es s~ao muito uteis para o entendimento do programa. Uma interfa e nos mostra
quais elementos s~ao relevantes e quais n~ao s~ao, estreitando o nosso fo o de aten ~ao. Em
outras palavras, a interfa e \es onde" informa a~o \irrelevante" atras dela.
O on eito de hierarquia e de vital import^an ia tanto para o entendimento quanto para
a onstru ~ao de sistemas. Pelo fato da mente humana ter um limite pequeno para o numero
de fatos om os quais pode lidar simultaneamente, nos podemos entender melhor os sistemas
que est~ao denidos de forma hierarqui a[67℄. Hierarquias permitem a estrati a ~ao de um
sistema em varios nveis de detalhes. Cada amada (ou nvel) representa um onjunto de
rela ionamentos agregados das partes dos nveis inferiores. O on eito de amada permite que
uma pessoa entenda o sistema atraves do o ultamento de nveis de detalhes desne essarios.
Embora o parti ionamento e a estrutura hierarqui a sejam on eitos muito importantes
na estrutura ~ao de sistemas, existe um ter eiro on eito rela ionado que e igualmente im-
portante: independ^en ia. Este on eito impli a na maximiza ~ao da independ^en ia de ada
omponente do sistema para que a sua omplexidade seja reduzida. Portanto, o problema
n~ao e meramente parti ionar um programa numa hierarquia, mas determinar omo par-
ti ionar um programa numa estrutura hierarqui a de tal forma que ada subsistema seja
independente dos outros tanto quanto possvel. Portanto, modularidade pode ser denida
omo a propriedade de um sistema que foi de omposto num onjunto de modulos fra amente
a oplados1 e altamente oesos2 .
Outra no ~ao muito importante rela ionada om as anteriores ja dis utidas e aquela de
fazer om que as onex~oes entre omponentes do sistema sejam aparentes tanto quanto
possvel[55℄. Em sistemas grandes e omum en ontramos varios efeitos olaterais que fazem
om que os sistemas sejam dif eis de entender, manter e modi ar.

1 Em Ingl^es low oupling.

2 Em Ingl^es high ohesion.
6 Cap
tulo 1: Introdu
~ao

1.1.3 Crise de Software

O termo \Crise de Software"3 foi unhado na Confer^en ia de Engenharia de Software da
OTAN em 1968, na Europa. Naquela epo a on luiu-se que os metodos de produ ~ao de
software n~ao eram adequados para as ne essidades res entes das industrias de defesa e de
pro essamento de dados. Varios problemas foram identi ados nos sistemas de software
produzidos na epo a, por exemplo, eles eram pou o predizveis, apresentavam uma baixa
qualidade, tinham alto usto de manuten ~ao e havia muita dupli a ~ao de esfor os em sua
onstru ~ao.
As metodologias subsequentes foram tentativas de superar essa rise de software. En-
tretanto, existem varias evid^en ias de que muitos projetos de software ainda s~ao entregues
atrasados, om o or amento estourado e om a espe i a a~o in ompleta, apesar da proli-
fera ~ao das metodologias de analise e de projeto. Nesse ontexto, surge o Paradigma de
Objetos que, embora nos ofere a novas ferramentas e uma abordagem diferente para de-
senvolvimento de software, e mais uma abordagem evolu ionaria do que revolu ionaria. Os
benef ios advindos do emprego do modelo de objetos s~ao varios, por exemplo, abstra ~ao
de dados/en apsulamento, modularidade, reutiliza a~o, maior fa ilidade de extens~ao e manu-
ten ~ao.

1.2 Ob jetos em Software: Id

eias B
asi as

A area de orienta ~ao a objetos e extensa e res ente. O modelo de objetos representa
em software elementos que en ontramos no mundo real. Esses elementos podem ser de
varios tipos, omo entidades fsi as (avi~oes, rob^os, et .) e abstratas (listas, pilhas, las,
et .). A ara tersti a mais importante (e diferente) da abordagem orientada a objetos para
desenvolvimento de software e a uni a ~ao, atraves do on eito de objetos, de dois elementos
que tradi ionalmente t^em sido onsiderados separadamente em paradigmas de programa ~ao
tradi ionais: (i) dados e (ii) fun o~es. Portanto,

Objeto = dados(privados) + fun o~es(publi as)

A uni a ~ao desses dois elementos de programa a~o resulta no que nos hamamos de
en apsulamento { o pro esso de es onder todos os detalhes de um objeto que n~ao ontribuem
para suas ara tersti as essen iais.
3 Em ingl^es: software risis.
Cap
tulo 1: Introdu
~ao 7

1.2.1 Abstra ~ao de Dados

Uma das tarefas mais importantes em desenvolvimento de software e a analise do domnio do
problema e modelagem das entidades e fen^omenos relevantes para a apli a ~ao. A modelagem
on eitual envolve dois aspe tos fundamentais: (i) abstra ~ao, rela ionada om os nossos
pensamentos na observa ~ao do domnio do problema e na deni ~ao dos objetos, propriedades
e a ~oes relevantes para a solu ~ao, e (ii) representa ~ao, que esta rela ionada om a nota ~ao
adotada para expressar o modelo on reto (ou \realidade fsi a"). Portanto, o su esso da
programa ~ao depende da ria ~ao de uma representa ~ao e de um onjunto de opera ~oes que
sejam ambos orretos e efetivos[78℄.
Abstra ~ao e denida omo um me anismo atraves do qual nos observamos o domnio
de um problema e fo amos nos elementos que s~ao relevantes para uma apli a ~ao espe  a,
ignorando todos os pontos que n~ao s~ao relevantes. Ela remove ertas distin ~oes de tal forma
que possamos ver as oisas omuns entre diversas entidades. Em outras palavras, ela des reve
as ara tersti as essen iais de um objeto que o distinguem de todos os outros tipos de
objetos e, portanto, propor iona limites on eituais bem denidos, relativos a perspe tiva
de um observador em parti ular. Isto e, uma abstra ~ao de uma entidade por parte de um
observador pode ser diferente da abstra ~ao de um outro observador observando a mesma
entidade.
Tr^es no ~oes diferentes podem ser abstradas de uma observa ~ao: (i) ategorias, grupos
ou lasses, (ii) a ~oes e (iii) propriedades. Podemos, ent~ao, denir tr^es opera ~oes envol-
vendo abstra ~ao, ada qual om sua opera a~o inversa: lassi a ~ao/instan ia ~ao, genera-
liza ~ao/espe ializa ~ao e agrega ~ao/de omposi a~o.

1.2.2 Classi a ~ao/Instan ia ~ao

A abstra ~ao de lassi a ~ao/instan ia ~ao permite agrupar objetos similares em uma mesma
ategoria. Por exemplo, duas pessoas, Jo~ao e Maria, podem ser lassi ados omo inst^an ias
da ategoria Empregado (Figura 1.1). Classi a ~ao pode ser des rita omo uma asso ia ~ao
e-uma4 , por exemplo, podemos dizer que Jo~ao e-uma pessoa.
Nota ~ao Gra a UML
Ao longo deste livro, diversos diagramas representando aspe tos diferentes de sistemas de
software orientados a objetos s~ao apresentados. Todos estes diagramas seguem uma nota ~ao
hamada UML (Unied Modeling Language). A UML[73℄ e uma linguagem para espe i ar
sistemas orientados a objetos (em ontrapartida om uma linguagem para a implementa a~o
de sistemas orientados a objetos, omo C++ ou Java) que se tornou, nos ultimos anos,
4 Em Ingl^es is a.
8 Cap
tulo 1: Introdu
~ao

Empregado

Clasificação Instanciação
<<instance_of>>
<<instance_of>>

joão:Empregado maria:Empregado

Figura 1.1: Exemplo de Classi a a~o/Instan ia a~o

um padr~ao tanto na industria quanto na a ademia. A UML uni a as nota ~oes propostas
pelas metodologias de Rumbaugh (OMT)[63℄, Boo h[7℄ e Ja obson[35℄ e e independente
da metodologia adotada. Ela foi padronizada por um omit^e interna ional que lida om
te nologias orientadas a objetos hamado Obje t Management Group (OMG)[74℄.
Nota ~ao UML para Classes e Objetos
Uma lasse em UML e representada de a ordo om a Figura 1.2(a) e um objeto e repre-
sentado de forma similar a uma lasse, ex eto que o seu nome e sublinhado om um tra o
(Figura 1.2(b)).

Classe umObjeto

propriedade1 propriedade1
propriedade2 Classe propriedade2 umObjeto

operaçãoA() Versão simplificada operaçãoA() Versão simplificada

operaçãoB() operaçãoB()

Versão Expandida Versão Expandida

(a) (b)

Figura 1.2: Classes e Objetos em UML

O numero de inst^an ias que uma lasse pode ter e hamada de sua multipli idade.
As multipli idades mais utilizada s~ao: (i) zero inst^an ias ( lasse abstrata), (ii) uma uni a
inst^an ia ( lasse singleton), (iii) um numero espe  o de inst^an ias, ou (iv) um numero
qualquer de inst^an ias ( aso default). Em UML, vo ^e pode espe i ar a multipli idade
de uma lasse es revendo uma express~ao no anto superior direito da lasse, onforme a
Figura 1.3.
Cap
tulo 1: Introdu
~ao 9

classe singleton
3
1 ControladorElevador
GerenciadorDeContas

Multiplicidade

Figura 1.3: Multipli idade de Classes

1.2.3 Generaliza ~ao/Espe ializa ~ao

Outra abstra ~ao surge quando observamos, por exemplo, duas ategorias e onseguimos
abstrair uma ter eira ategoria que e mais geral do que as outras duas. A generaliza ~ao
permite que todas as inst^an ias de uma ategoria espe  a sejam tambem onsideradas
inst^an ias de uma ategoria mais abrangente; mas o inverso n~ao e ne essariamente valido. Ela
pode ser des rita omo uma asso ia ~ao e-um-tipo-de5 . Por exemplo, Motorista, Se retario
e Engenheiro podem ser onsiderados ategorias espe iais de Empregados (Figura 1.4). Por
outro lado, Empregado e onsiderado uma generaliza a~o de Motorista, Se retario e Engenheiro.
Podemos ainda dizer que um motorista e-um-tipo-de empregado.

Empregado

Generalização Especialização

Motorista Secretária Engenheiro

Figura 1.4: Exemplo de Generaliza a~o/Espe ializa a~o,

Nota ~ao UML para Generaliza ~ao e Espe ializa ~ao
Em UML, um rela ionamento de generaliza ~ao e representado por uma ou mais linhas que
se ini iam nas lasses mais espe i as e terminam em um tri^angulos bran os que apontam
para a mais abrangente. O rela ionamento de generaliza ~ao e mostrado nas Figuras 1.5 e 1.6.
Na segunda, duas lasses diferentes s~ao espe ializadas por uma mesma lasse.

1.2.4 Agrega ~ao/De omposi ~ao

Agrega ~ao e uma abstra ~ao que permite a identi a ~ao das ategorias onstituintes de ou-
tra(s) ategorias. Ela e um me anismo que forma o todo a partir de partes. Por exemplo,
5 Em Ingl^es is a kind of.
10 Cap
tulo 1: Introdu
~ao

A classe base

classe derivada
classe derivada

B C

Figura 1.5: Espe ializa a~o Simples em UML

A B

Figura 1.6: Espe ializa a~o Multipla em UML

uma L^ampada e onstituda de uma Base, um Bulbo e um Filamento (Figura 1.7). A omple-
xidade de um sistema pode ser reduzida se tratarmos muitos objetos omo se fossem um so.
A agrega ~ao/de omposi ~ao pode ser des rita omo a asso ia a~o e-parte-de6 .
<<instance_of>>
l1 Lâmpada

Agregação Decomposição

Base Bulbo Filamento

<<instance_of>> <<instance_of>> <<instance_of>>

ba1 bu1 f1

Figura 1.7: Exemplo de Agrega ~ao/De omposi a~o

Nota ~ao UML para Agrega ~ao
A nota a~o UML para os rela ionamentos de agrega ~ao e omposi ~ao e mostrada na Fi-
gura 1.8. Em UML, a agrega ~ao e representada por uma linha que se ini ia nas partes e
termina no todo, em um diamante bran o. Existe uma varia ~ao de agrega a~o { a om-
posi ~ao { que adi iona outras sem^anti as importantes a agrega a~o simples. A omposi ~ao
6 Em Ingl^es is part of.
Cap
tulo 1: Introdu
~ao 11

(Figura 1.8(b)) e uma forma de agrega ~ao, om uma posse forte do todo e om tempos de
vida oin identes entre as partes do todo. Uma vez que o agregado foi riado, o todo e as
partes \vivem" e \morrem" juntos. As partes podem ser tambem removidas expli itamente
antes da morte do todo. A omposi ~ao e representada em UML da mesma forma que a
agrega ~ao, om a diferen a de que o todo e indi ado por um diamante negro, e n~ao bran o.

parte A B todo

(a) Agregacão

parte A B todo

(b) Composicão

Figura 1.8: Agrega ~ao e Composi a~o em UML

1.2.5 Hierarquias de Abstra ~ao

Quando um sistema tem muitos detalhes relevantes para serem representados atraves de ape-
nas uma abstra ~ao, essa abstra ~ao pode ser de omposta em hierarquias de abstra ~oes. Uma
hierarquia pode ser vista omo um \ranking" ou uma ordem entre abstra ~oes, permitindo
que detalhes relevantes sejam introduzidos de maneira ontrolada.
Existem dois tipos de hierarquias de abstra ~ao que s~ao de fundamental import^an ia: hie-
rarquias de agrega ~ao e hierarquias de generaliza a~o[5, 60, 59℄. Agrega ~ao dene hierarquias
de parte-todo, sendo que as partes, por sua vez, podem ter seus proprios omponentes e as-
sim re ursivamente. Generaliza ~ao dene hierarquias de ategorias, que formam ategorias
mais generi as.
Generaliza ~ao e um dos mais importantes me anismos que temos para entender o mundo
real. Pesquisas em Ban o de Dados t^em quase que ex lusivamente se preo upado om hierar-
quias de agrega ~ao, enquanto que a area da representa ~ao do onhe imento em Intelig^en ia
Arti ial t^em se preo upado om hierarquias de generaliza ~ao (redes sem^anti as e \frames").
Em linguagens de programa ~ao imperativas, agrega ~ao esta rela ionada om \re ords" e ge-
neraliza ~ao esta rela ionada om \re ords variantes".
Agrega ~ao e generaliza ~ao s~ao no ~oes ompletamente diferentes e omplementares. Elas
s~ao on eitos ortogonais7 e quando empregadas em onjunto formam uma ferramenta efe-
tiva para a modelagem de sistemas. Existe uma diferen a essen ial entre hierarquias de
7 Duas propriedades s~
ao ortogonais quando a retirada, in lus~ao ou modi a ~ao de qualquer uma delas n~ao
afeta a outra.
12 Cap
tulo 1: Introdu
~ao

generaliza a~o e agrega a~o. Nas hierarquias de generaliza ~ao/espe ializa ~ao, a no ~ao de
heran a esta impli itamente representada (Figura 1.9), enquanto que nas hierarquias de
agrega ~ao/de omposi ~ao isso nem sempre e verdade. Por exemplo, na hierarquia da Fi-
gura 1.4, as propriedades gerais de um empregado, tais omo, nome, endere o residen ial
e numero do RG, s~ao impli itamente herdadas por um motorista, uma se retaria ou um
engenheiro. Em ontraste, na hierarquia da Figura 1.7, uma propriedade de l^ampada, omo
por exemplo sua or, n~ao e automati amente herdada por suas partes.

Mamífero

Propiedades:
sangue_quente
vertebrado
vivíparo
Comportamento:
mamar()

Baléia

tempo_medio_vida: 200
habitat: mar

nadar()

Figura 1.9: Exemplo de Heran a

1.2.6 Reusabilidade, Modularidade e Extensibilidade

Uma das raz~oes prin ipais para o problema da baixa produ a~o de software e a di uldade para
reutilizar o odigo gerado pelas metodologias tradi ionais. O modelo de objetos auxilia na
solu ~ao deste problema, ja que promove a modularidade e o en apsulamento; hierarquias de
lasses e objetos s~ao, em geral, omponentes portaveis entre apli a o~es. Se bem projetados,
esses omponentes podem ser reutilizados em varias apli a o~es sem modi a a~o. Alem disso,
podem ser tambem estendidos sem orromper o que ja existe. Portanto, o modelo de objetos
propor iona modularidade, trazendo os seguintes benef ios:

reusabilidade: software pode ser es rito a partir de omponentes ja existentes que podem
ser usados em diversas apli a ~oes ( omo dis utido a ima);
Cap
tulo 1: Introdu
~ao 13

extensibilidade: novos omponentes de software podem ser desenvolvidos a partir de om-

ponentes ja existentes sem afetar os omponentes originais.

Meyer, o riador da linguagem orientada a objetos Eiel[48℄, aponta in o riterios para

a obten ~ao de modularidade. Esses riterios s~ao gerais e podem ser apli ados a qualquer
tipo de modelo, embora seja mais dif il segui-los usando-se modelos tradi ionais:

1. De omposibilidade: parti ionamento de um sistema em unidades manejaveis.

2. Composibilidade: modulos podem ser livremente ombinados em outros sistemas.
3. Entendimento: a ompreens~ao de uma parte ontribui para o entendimento do todo.
4. Continuidade: pequenas mudan as no sistema impli am em pequenas mudan as no
omportamento.
5. Prote ~ao: Condi ~oes ex ep ionais ou err^oneas s~ao onnadas aos subsistemas nas
quais elas o orrem ou afetam apenas as partes diretamente a elas rela ionadas.

Todos esses riterios s~ao mais fa ilmente al an ados por um sistema orientado a objetos
em virtude de objetos serem unidades oesas om interfa es simples, que es ondem suas
implementa ~oes.

1.3 Linguagens de Programa

~ao Orientadas a Ob jetos

As representa ~oes abstratas mais omuns em omputa a~o s~ao as linguagens de programa a~o.
Muitos pesquisadores re onhe em que existe um rela ionamento muito proximo entre os pen-
samentos e a linguagem humana usada para expressa-los. De fato, a natureza da linguagem
modela e da forma aos nossos pensamentos e vi e-versa: linguagem e pensamento modelam
mutuamente um ao outro e n~ao ha uma pre ed^en ia entre eles. A rela a~o entre programas
de software e a linguagem de programa ~ao usada para desenvolv^e-los e semelhante[25℄.
Entretanto, e dif il transformar as abstra ~oes do mundo diretamente nas abstra o~es de
uma linguagem de programa ~ao sem passarmos por passos intermediarios (Figura 1.10).
Neste aso, nota ~oes gra as intermediarias s~ao uteis para ajudar o programador na repre-
senta ~ao das suas abstra ~oes para a linguagem. Podemos, ent~ao, denir desenvolvimento
de software omo um pro esso atraves do qual nos renamos transforma o~es su essivas
de uma representa ~ao de alto nvel para uma representa ~ao de mais baixo nvel exe utavel
num omputador. Consequentemente, o pro esso inteiro e dependente das fa ilidades para a
representa ~ao de abstra ~oes disponveis na linguagem de programa ~ao alvo. Se a linguagem
14 Cap
tulo 1: Introdu
~ao

O modelo deve refletir a realidade

Realidade de uma maneira significativa para
os usuários finais.

Modelo OO
da Realidade O projeto deve ter a mesma
estrutura básica que o modelo.

Projeto O código deve ser gerado

OO tão automaticamente quanto
possível a partir do projeto.

Código

Figura 1.10: Passos Intermediarios da Modelagem da Realidade

de alguma forma restringe o modo omo as abstra ~oes podem ser denidas, ela ertamente
limitara a modelagem das apli a ~oes.
A onstru ~ao top-down e uma te ni a util que requer que uma apli a ~ao seja proje-
tada onsiderando ini ialmente sua ma ro-estrutura omo um todo. Nos passos seguin-
tes do desenvolvimento, esta estrutura e detalhada ate que uma implementa ~ao seja pro-
duzida. Renamento passo-a-passo8 propor iona uma estrategia para a realiza ~ao desse
detalhamento[80℄. De fato, a metodologia de renamento passo-a-passo interage om a abor-
dagem top-down ate que a solu ~ao do problema se torne um programa. Esta metodologia
onsidera ada subproblema omo um problema separado, ria uma des ri ~ao de alto nvel
para ada problema e ent~ao rena-o em termos de outros subproblemas.
A abordagem top-down e uma dis iplina de Engenharia de Software madura na qual
foram baseadas diversas metodologias de projeto estruturadas durante os ultimos 30 anos.
Metodologias de Analise e Projeto Orientado a Objetos apresentam uma alternativa para esta
abordagem onven ional, espe ialmente quando tratamos de sistemas grandes e omplexos.

1.3.1 Evolu ~ao da Abstra ~ao em Linguagens de Programa ~ao

No in io do desenvolvimento de linguagens de programa ~ao, linguagens de montagem permi-
tiam aos projetistas es rever programas baseados em instru o~es de maquina (operadores) que
manipulavam os onteudos das lo a o~es de memoria (operandos). Portanto, as abstra ~oes de
dados e ontrole eram de muito baixo nvel. Um grande passo de evolu ~ao o orreu quando as
8 Em Ingl^es stepwise renement.
Cap
tulo 1: Introdu
~ao 15

primeiras grandes linguagens de programa ~ao imperativas surgiram { Fortran e Cobol. For-
tran foi importante porque introduziu a no a~o de subprogramas { fun ~oes e pro edimentos
{ enquanto Cobol introduziu a no ~ao de des ri a~o de dados.
Subsequentemente, Algol-60 introduziu o on eito de estrutura de blo o, pro edimento,
et . Ela in uen iou fortemente numerosas linguagens de programa ~ao que foram hamadas
linguagens baseadas em Algol. A losoa de Algol-68 onsistia da es olha de um on-
junto adequado de me anismos que deveriam ser ombinados sistemati amente. Apesar da
import^an ia de Algom-60 para a evolu ~ao das linguagens de programa ~ao, foi Pas al que
tornou-se a linguagem de programa a~o mais popular, prin ipalmente por ausa da sua sim-
pli idade, sistemati a e e i^en ia de implementa ~ao. As duas linguagens possuem estruturas
de ontrole ri as e deni ~oes de tipos e tipos de dados, seguindo as ideias da programa ~ao
estruturada riadas por Wirth, Dijkstra and Hoare[16℄.
Desde os anos 70, as linguagens t^em se preo upado em dar mais suporte para programa ~ao
em larga es ala9 . Este tipo de programa a~o ( omplementar a programa ~ao em pequena e
media es ala10 ) preo upa-se om a onstru ~ao de programas grandes a partir de modulos.
Um modulo e uma unidade de programa que pode ser implementado de uma maneira mais
ou menos independente dos outros modulos. Um modulo bem projetado tem um proposito
bem denido e apresenta uma interfa e \estreita" para os outros modulos (veja dis uss~ao
sobre modularidade na Se ~ao 1.1.2). Tal modulo e reutilizavel, i.e. tem grande han e de
ser reutilizado podendo ser in orporado a varios programas, e modi avel, i.e., pode ser
alterado ser ausar grandes mudan as em outros modulos rela ionados. Parnas[61℄, por
volta de 1972, lan ou a dis iplina do o ultamento da informa ~ao (tambem onhe ida
omo en apsulamento). A ideia era en apsular variaveis globais em um modulo juntamente
om o grupo de opera ~oes que tinham a esso direto a elas. Outros modulos podiam a essar
essas variaveis somente indiretamente, atraves das opera o~es ofere idas pelos modulos.
Somente o que o modulo faz e passado para o liente do modulo; o omo e implementado
somente diz respeito ao implementador do modulo. Se um modulo e implementado desta
forma, e dito que esse modulo en apsula seus omponentes. Para a obten ~ao de uma interfa e
\estreita" para outros modulos, um modulo tipi amente faz om que apenas um numero
pequeno de omponentes sejam visveis para os lientes externos. Tais omponentes s~ao
exportados pelo modulo. Muitos outros omponentes permane em \es ondidos" dentro do
modulo. Portanto, en apsulamento sugere que uma estrutura de dados deve residir dentro
de um modulo. Uma interfa e prov^e o a esso ne essario a tais estruturas para modulos
externos. Em resumo, en apsulamento minimiza as inter-depend^en ias entre modulos
es ritos separadamente atraves da deni a~o de interfa es estritas.
Existem pelo menos dois me anismos de linguagens de programa ~ao que d~ao apoio a
essas ideias, a saber:
9 Em Ingl^es programming in the large.
10 Em Ingl^es programming in the small.
16 Cap
tulo 1: Introdu
~ao

(i) modulos, omo implementados em Modula-2 ou omo pa otes11 implementados em

Ada;
(ii) tipo abstrato de dados, tipos denidos indiretamente atraves de suas opera ~oes.

Um modulo onsiste de 2 partes rela ionadas: (1) espe i a ~ao do modulo ( hamada
de spe ) e (2) implementa ~ao do modulo ( hamada de body). A parte spe e um on-
junto de de lara ~oes de estruturas de dados e assinaturas de pro edimentos. A parte body
ontem as implementa ~oes da entidade de laradas na parte spe . Todas as entidades en on-
tradas no body s~ao privadas, i.e., n~ao visveis aos lientes do spe . Cada entidade de larada
no spe deve estar implementada no body. Entretanto, o body pode onter estruturas de
dados e pro edimentos adi ionais usados para implementar as entidades visveis.
A no ~ao de tipos abstratos de dados e muito importante e refere-se ao en apsulamento de
uma estrutura de dados juntamente om as opera o~es que manipulam essas estuturas den-
tro de uma regi~ao protegida. Uma linguagem da apoio a tipos abstratos de dados quando
ela possui me anismos que permitem a sua representa ~ao diretamente. Linguagens de pro-
grama ~ao omo Ada e Modula-2 d~ao apoio a tipos abstratos de dados, mas ainda t^em ertas
limita ~oes:

(i) o sistema de tipos e unidimensional, i. e., um programa e desenvolvido omo um

onjunto de tipos abstratos de dados uja estrutura dos tipos e denida no nvel ho-
rizontal: as hierarquias de generaliza ~ao/espe ializa a~o n~ao podem ser representadas
expli itamente.
(ii) tipos abstratos de dados n~ao s~ao representados expli itamente em tempo de exe u ~ao,
isto e, eles \desapare em" durante tempo de exe u a~o. Embora tipos abstratos de da-
dos sejam uteis durante as fases de analise, projeto e implementa ~ao, eles desapare em
durante tempo de exe u ~ao e o software se torna de novo um monte de linhas de odigo
agrupadas em modulos ompletamente desestruturados.

O proximo passo da evolu ~ao das linguagens de programa ~ao foi introduzido om o on-
eito de objetos, riado por Dahl e Nygaard om a linguagem Simula-67[15℄, e onsolidado
om a linguagem Smalltalk-76. Simula-67 introduziu os on eitos de lasse, objeto e heran a.
O modelo lassi o de objetos emprega lasses para a des ri ~ao de objetos. Classes ontem
a deni ~ao do omportamento dos objetos (i.e. dados e fun ~oes). Classes ja existentes po-
dem ompartilhar seu omportamento om novas lasses. Esta heran a de omportamento
resulta em ompartilhamento de odigo. Essen ialmente, o modelo de objetos trata dados e
fun ~oes omo aspe tos indivisveis no domnio do problema.
11 Do ingl^es: pa kages
Cap
tulo 1: Introdu
~ao 17

1967 Simula-67
1972 Artigo de Dahl sobre o ultamento da informa ~ao
1976 Primeira vers~ao de Smalltalk
1983 Primeira vers~ao de C++
1988 Primeira vers~ao de Eiel
1995 Primeira vers~ao de Java
Tabela 1.1: Breve Historia de Orienta a~o a Objetos

O paradigma de objetos esta fortemente rela ionado om a no ~ao de tipo abstrato de
dados porque objetos podem ser vistos omo inst^an ias de tipos abstrato de dados. Na
verdade, na maioria das linguagens orientadas a objetos, a deni ~ao de uma lasse des reve
um tipo de dados asso iado om as opera ~oes que podem ser exe utadas naquele tipo.
A Tabela 1.1 mostra alguns dos a onte imentos mais mar antes da historia da Orienta ~ao
a Objetos.

1.3.2 Programa ~ao Orientada a Objetos

Programa ~ao orientada a objetos e um modelo de programa a~o baseado em on eitos, tais
omo objetos, lasses, tipos, o ultamento da informa ~ao, heran a, polimorsmo e parame-
triza ~ao. Analise e Projeto Orientados a Objetos (\Obje t-Oriented Analysis and Design")
prov^em uma maneira de usar todos esses on eitos para a estrutura a~o e onstru ~ao de sis-
temas. Esses on eitos s~ao intrinsi amente independentes de linguagens e ada uma tem sua
propria maneira de implementa-los.
A ess^en ia da programa ~ao orientada a objetos e a resolu a~o de problemas baseada na
identi a ~ao de objetos do mundo real perten entes ao domnio da apli a a~o e o pro essa-
mento requerido por esses objetos e na ria ~ao \simula ~oes" deles. Esta ideia de \programas
simulando o mundo real" res eu om Simula-67, que na verdade foi projetada para o desen-
volvimento de apli a o~es de simula ~ao. Devido ao fato do mundo estar povoado de objetos,
uma simula ~ao de tal mundo deveria onter objetos simulados apazes de enviar e re eber
mensagens e reagir a mensagens re ebidas.
Consequentemente, na programa ~ao orientada a objetos, a exe u ~ao de um programa
onsiste de um onjunto de objetos rela ionados que enviam mensagens. Cada objeto tem
um estado interno omposto por atributos que s~ao modi ados mediante a re ep a~o e o
envio de mensagens. Programas s~ao onstrudos atraves da deni a~o de lasses e ria ~ao
de hierarquias nas quais propriedades omuns s~ao transmitidas das super lasses para as
sub lasses atraves do me anismo de heran a. Este estilo de programa a~o tem as seguintes
18 Cap
tulo 1: Introdu
~ao

ara tersti as positivas: modularidade, suporte expl ito para generaliza ~ao/espe ializa ~ao,
uma vis~ao uni ada de dados e pro essos, atividade in remental e evolu ionaria, e reusabi-
lidade.
Muito do interesse no modelo de objetos e devido a res ente per ep ~ao da industria de
que ele e uma maneira melhor de onstruir programas omplexos do que as outras metodo-
logias, pois ele promove reutiliza a~o de software, melhorando a sua qualidade e reduzindo o
seu usto de desenvolvimento.

1.3.3 Linguagens Orientadas a Objetos vs Linguagens Baseadas

em Objetos
Na literatura existe uma distin ~ao lara entre linguagens baseadas em objetos e linguagens
orientadas a objetos. De a ordo om a taxonomia proposta por Wegner[76℄(Figura 1.11),
uma linguagem e baseada em objetos12 quando ela da apoio expl ito somente ao on eito de
objetos. Uma linguagem e baseda em lasses quando ela da apoio para a ria ~ao de objetos
e existe um me anismo de agrupamento de objetos para a ria ~ao de novas lasses, mas n~ao
da suporte para um me anismo de heran a. Uma linguagem e dita orientada a objetos13 se
ela propor iona suporte lingusti o para objetos, requer que esses objetos sejam inst^an ias
de lasses e alem disso, ofere e suporte para um me anismo de heran a. Portanto:

Linguagem Orientada a Objetos = Objetos + Classes + Heran a

Baseado
em
Objetos
+ Classes

Baseado
em
Classes
+ Herança

Orientado
a
Objetos

Figura 1.11: Classi a ~ao de Wegner

12 Em Ingl^es obje t-based language.
13 Em Ingl^es obje t-oriented language.
Cap
tulo 1: Introdu
~ao 19

De a ordo om essa taxonomia, linguagens omo Ada85 e CLU s~ao baseadas em objetos
enquanto C++[70℄, Java[1℄, Modula-3[12℄ e Smalltalk-80[26℄ s~ao orientadas a objetos. Uma
lassi a ~ao mais abrangente e proposta por Blair et al. que tambem in lui as linguagens ba-
seadas em delega ~ao[3℄. Delega ~ao e um me anismo pare ido om o de heran a que promove
o ompartilhamento de omportamento entre objetos, n~ao entre lasses omo o de heran a.
Blair lassi a uma linguagem omo sendo orientada a objetos se ela da apoio a ria ~ao de
objetos e a um me anismo de ompartilhamento de omportamento (heran a ou delega a~o).
Para propositos deste livro, adotaremos a taxonomia proposta por Wegner, ou seja, para nos
uma linguagem orientada a objetos da suporte direto para objetos, lasses e heran a.
O modelo de objetos ompreende um onjunto de prin pios que formam a funda ~ao do
paradigma de objetos. Um ponto muito importante na programa a~o orientada a objetos e
a obten ~ao de omponentes reutilizaveis e exveis atraves de on eitos omo, por exemplo,
de objetos, lasses, tipos, heran a, polimorsmo, e a oplamento din^ami o. Os on eitos de
heran a e a oplamento din^ami o s~ao espe  os da programa ~ao orientada a objetos.
Podemos identi ar similaridades entre a programa ~ao pro edural (ou imperativa) e a
programa ~ao orientada a objetos. A Tabela 1.2 tra a um paralelo entre essas duas aborda-
gens.

Paradigma Pro edural Paradigma de Objetos

tipos de dados lasses/tipos abstratos de dados
variavel objeto/inst^an ia
fun ~ao/pro edimento opera ~ao/servi o
hamada de fun ~ao envio de mensagem
Tabela 1.2: Compara a~o entre o Paradigma Pro edural e o de Objetos

A Figura 1.12 expli ita algumas das diferen as entre uma linguagem orientada a objetos
e uma pro edural.

1.4 An
alise e Pro jeto Orientado a Ob jetos

O paradigma de objetos n~ao e apenas um estilo de programa a~o, mas tambem uma meto-
dologia de projeto para desenvolvimento de software. Analise e projeto orientados a objetos
tipi amente lidam om o problema de desenvolver sistemas de software grandes e omplexos
sujeitos a mudan as. Na onstru ~ao de tais sistemas, a programa ~ao dos omponentes indi-
viduais frequentemente n~ao e o problema mais dif il. O que e realmente mais desaador e a
integra ~ao de tais omponentes e a obten ~ao de um sistema bem estruturado que seja fa il
de manter, estender e entender.
20 Cap
tulo 1: Introdu
~ao

Funções
Objeto Objeto
e Dados
Procedimentos
Objeto
Objeto

Uma Aplicação Estruturada Uma Aplicação Orientada a Objetos

Figura 1.12: Ling. Orientadas a Objetos vs. Ling. Baseadas em Objetos

1.4.1 Desenvolvimento de Software Orientado a Objetos

As etapas do pro esso de desenvolvimento de software, independentemente da metodologia
empregada, s~ao as seguintes:

1. espe i a ~ao do problema,

2. entendimento dos requisitos,

3. planejamento da solu ~ao, e

4. implementa ~ao de um programa numa dada linguagem de programa ~ao.

Uma metodologia de analise e projeto auxilia na onstru ~ao de um modelo do domnio

de um problema e na adi ~ao de detalhes de implementa a~o a esse modelo. A abordagem
orientada a objetos para onstru ~ao de sistemas permite que um mesmo onjunto de on eitos
e uma mesma nota ~ao sejam usados atraves de todo i lo de vida do software: analise,
projeto e implementa ~ao.
Neste estagio, e util denirmos alguns on eitos. No ontexto deste livro, um metodo e
um onjunto de atividades sistemati as para realizar uma tarefa. Uma te ni a e um modo
de exe utar as atividades re omendadas por um metodo e uma metodologia e um onjunto
de metodos e te ni as om os quais um objetivo pode ser realizado. Uma boa metodologia
de analise e projeto deve propor ionar mais do que uma simples nota ~ao: ela deve forne er
orienta ~oes sobre os passos que ser~ao exe utados nos diversos estagios de desenvolvimento e
deve obrir todo i lo de desenvolvimento de software.
Cap
tulo 1: Introdu
~ao 21

1.4.2 Metodologias Tradi ionais vs. Orientadas a Objetos

A ideia prin ipal do paradigma de objetos e o en apsulamento do estado de um programa
na forma de objetos que podem ser a essados somente atraves de opera ~oes denidas na
interfa e publi a dos mesmos. A maioria do software existente hoje foi onstrudo usando
o modelo lassi o as ata (1963) que distingue fases xas, tais omo espe i a ~ao, analise,
projeto, et . (Figura 1.13). A fase de projeto utiliza uma abordagem fun ional top-down.
Ini ialmente, as fun ~oes (pro edimentos) a serem realizadas pelo sistema s~ao identi adas.
Essas fun ~oes s~ao subsequentemente divididas em subtarefas, que s~ao por sua vez renadas.
O resultado e uma des ri ~ao hierarqui a da estrutura do sistema, que sera a base para a fase
de implementa ~ao.

Engenharia
de Sistemas

Análise

Projeto

Codificação

Teste

Manutenção

Figura 1.13: Modelo Cas ata

Uma evolu ~ao do modelo as ata e o modelo espiral (Figura 1.14). O desenvolvimento
de software orientado a objetos pode ser adaptado para o modelo espiral. O pro esso de
desenvolvimento de software orientado a objetos se move sob uma espiral evolu ionaria,
onde as fases de analise, projeto, evolu a~o e modi a a~o s~ao exe utadas de forma iterativa e
in remental (Figura 1.15). Uma vis~ao orientada a objetos para o desenvolvimento de software
demanda uma abordagem evolu ionaria para a engenharia de software. As fases de analise
e projeto n~ao s~ao fases distintas e monolti as; ao ontrario, elas s~ao apenas passos ao longo
do aminho do desenvolvimento in remental e interativo do software. Note que esses passos
podem alimentar-se uns aos outros.
Embora a abordagem estruturada top-down seja melhor do que uma abordagem n~ao-
estruturada bottom-up, ela apresenta alguns serios problemas. Uma das desvantagens prin-
ipais e que geralmente o uso dessa te ni a produz sistemas que s~ao in exveis e n~ao podem
ser alterados fa ilmente para a in orpora ~ao de mudan as. Varios experimentos mostram
que o usto para desenvolver um sistema de software pode ser signi amente menor do que
o usto para mant^e-lo. Portanto, e importante que um software seja apaz de in orporar
22 Cap
tulo 1: Introdu
~ao

Planejamento Análise de Risco

Avaliação do Cliente Engenharia

Figura 1.14: Modelo Espiral

Análise

Projeto

Evolução

Modificação

Figura 1.15: Desenvolvimento de Software orientado a objetos

mudan as de um modo fa il e natural.

Outro problema om o desenvolvimento top-down e que ele n~ao onsidera omponentes de
software ja existentes. Em ontraste, projetistas de hardware freqentemente ome am o seu
projeto onsultando um atalogo de omponentes pre-fabri ados. Os seus projetos s~ao base-
ados em omponentes uteis ja existentes e evitam o desenvolvimento de novos omponentes
o maximo possvel. Em outras palavras, o desenvolvimento top-down de software di ulta
a reutiliza ~ao de software porque e muito raro que um omponente de software ja existente
implemente exatamente o que e requerido pelo novo sistema. Reutiliza ~ao de software esta
geralmente limitada ao uso de rotinas de bibliote as bem do umentadas.
Uma outra limita ~ao da abordagem estruturada e que as fases n~ao se integram de forma
elegante e simples. Diferentes modelos e nota o~es s~ao usados para espe i a ~ao, projeto
Cap
tulo 1: Introdu
~ao 23

e implementa ~ao do sistema, fazendo om que as transi ~oes entre as fases sejam dif eis e
restringindo as possibilidades para a veri a a~o e gera ~ao automati a de programas (Fi-
gura 1.16).
Nas metodologias tradicionais, analistas, projetistas e
programadores têm diferentes modelos conceituais

Análise Projeto Programação

Diagramas de Diagramas de COBOL

Entidade- Fluxo de Dados
Relacionamento

FORTRAN
Decomposição Diagramas de
Funcional Estrutura de
Módulos
C

Diagramas de Diagramas de
Dependência Ação
de Processos PASCAL

A tecnologia de objetos usa um modelo unificado

Análise OO Projeto OO Programação OO

Modelo do Objeto

Figura 1.16: Compara ~ao entre Metodologias Tradi ionais vs. orientadas a objetos

Metodologias de projeto orientadas a objetos promovem uma melhoria substan ial sobre
os modelos tradi ionais. A ideia have da analise e projeto orientados a objetos e o fo o
em objetos (e lasses), ao inves de fun ~oes (ou pro edimentos). O projetista n~ao ome a
pela identi a ~ao das diferentes fun ionalidades do sistemas, mas pela identi a ~ao dos ob-
jetos que modelam o sistema. Uma motiva ~ao para essa abordagem e que mudan as na
espe i a ~ao dos requisitos tendem a afetar menos os objetos do que as fun ~oes. Consequen-
temente, o emprego de objetos produz sistemas que s~ao menos vulneraveis a mudan as em
requisitos. Alem disso, omponentes de um software orientado a objetos t^em uma probabili-
dade maior de serem reutilizados, pois en apsulam representa ~ao de dados e implementa ~ao.
Tambem o modelo de objetos leva a uma melhor integra ~ao das diferentes fases do desenvol-
vimento, ja que todas as fases manipulam objetos (Figura 1.17).

1.4.3 Limita ~oes do Modelo de Objetos

Muitos dos problemas en ontrados em orienta a~o a objetos s~ao devidos ao fato das linguagens
orientadas a objetos e metodologias orientadas a objetos estarem ainda em desenvolvimento,
24 Cap
tulo 1: Introdu
~ao

Análise

Projeto

Construção

Estrutura Comportamento
do Objeto do Objeto

Figura 1.17: Analise e Projeto orientado a objetos dividem-se em duas partes rela ionadas { a
direita, modelos da estrutura do objeto (dados) e a esquerda, modelos do seu omportamento
(fun ~oes)

sem ontar as ferramentas de apoio para analise e projeto que est~ao muito pou o desenvol-
vidas. Existe muito trabalho ainda por ser feito para a provis~ao de suporte para projetos
em larga es ala usando metodologias orientadas a objetos. Desenvolvedores de software pre-
isam de ompiladores, bibliote as, ban o de dados e ferramentas CASE e todas elas est~ao
num estagio ini ial de desenvolvimento.
Outras limita ~oes de orienta a~o a objetos in luem: trabalho em grupo pou o desenvol-
vido; ne essidade de maneiras novas para ger^en ia, teste e qualidade de software; e reu-
tiliza ~ao de software { n~ao e t~ao simples obter omponentes reutilizaveis entre diversas
apli a ~oes, espe ialmente usando-se heran a. Com o uso de heran a, objetos tornam-se
muito dependentes de apli a a~o para serem reutilizados. Existe, portanto, a ne essidade de
te ni as mais efetivas para a obten ~ao de reutiliza ~ao de software.

1.4.4 O Paradigma da Integra ~ao

A analise e projeto orientados a objetos integram diversas te nologias, omo mostra a Fi-
gura 1.18. Essa integra ~ao tem poten ial para ausar uma revolu ~ao na industria de software.
Como dis utido anteriormente (Se ~ao 1.3.3), o paradigma de objetos e ortogonal a outros
paradigmas de programa ~ao, fa ilitando essa integra ~ao. O vasto ampo da te nologia de
objetos pode ser dividido nas seguintes areas prin ipais: analise orientada a objetos, projeto
orientado a objetos, programa ~ao orientada a objetos, ban o de dados orientados a objetos,
interfa es gra as orientadas a objetos, sistemas distribudos orientados a objetos, et .
Cap
tulo 1: Introdu
~ao 25
Repositório Cliente-Servidor
CASE
Reusabilidade
Geradores Maciça
Técnicas
de Código
Estruturadas
Engenharia
de Informação
Máquina de
Inferência Computação
Paralela
Análise e Projeto
Modelos
Baseados Orientados a Objeto
em Regras Bancos de Dados
Orientados a Objeto
LISP
Base de
Conhecimento
Programação SQL
Visual
C++ GUIs
Frameworks Programação OO
JAVA
PROLOG Bibliotecas
de Classes

Figura 1.18: Integra ~ao do Modelo de Objetos om as Demais Te nologias

1.5 Resumo do Cap

tulo

1.6 Exer 
 ios

1. Por que o modelo de objetos se apresenta omo um modelo promissor para o desenvol-
vimento de software onavel e robusto?
2. Quais s~ao os novos requisitos para os sistemas de software impostos pelas apli a ~oes
modernas?
3. Como seres humanos, quais os me anismos que empregamos para lidar om a omple-
xidade?
4. O que vem a ser a omplexidade de um omponente ou subsistema de software e omo
podemos reduzir a omplexidade do software a ser onstrudo?
5. De onde vem o termo \ rise de software" e o que signi a?
6. O que s~ao objetos e quais os benef ios advindos do emprego do modelo de objetos?
7. Qual a ara tersti a mais importante e diferente da abordagem orientada a objetos
para o desenvolvimento de software?
8. Qual e uma das tarefas mais importantes em desenvolvimento de software?
9. Do que depende o su esso da programa a~o?
26 Cap
tulo 1: Introdu
~ao

10. O que vem a ser abstra ~ao?

11. Que no ~oes podem ser abstradas de uma observa ~ao e que opera ~oes podemos denir
envolvendo a abstra a~o? Explique ada uma delas.
12. O que s~ao hierarquias de abstra a~o? Cite os tipos existentes.
13. Quais os benef ios da modularidade presente no modelo de objetos e quais os riterios
para a obten ~ao da mesma?
14. Qual a rela ~ao entre programas de software e a linguagem de programa ~ao usada para
desenvolv^e-los?
15. Como podemos denir \desenvolvimento de software"?
16. Qual e a preo upa ~ao da programa a~o em larga es ala?
17. O que vem a ser en apsulamento?
18. Como e feita a omuni a a~o entre modulos e do que onsiste um modulo?
19. O que vem a ser tipo abstrato de dados e por que o paradigma de objetos esta forte-
mente rela ionado om essa no ~ao?
20. O que vem a ser programa ~ao orientada a objetos? E analise e projeto orientado a
objetos?
21. Como a programa ~ao orientada a objetos e al an ada e que ara tersti as positivas
advem desse tipo de programa a~o?
22. Qual a diferen a entre linguagens orientadas a objetos e linguagens baseadas em obje-
tos?
23. Quais as similaridades entre programa a~o pro edural e programa ~ao orientada a obje-
tos?
24. Analise e projeto orientado a objetos normalmente lidam om que tipo de problema?
Qual desses problemas e realmente desaador?
25. Quais as etapas do pro esso de desenvolvimento de software, independentemente da
metodologia empregada?
26. Dena metodo, te ni a e metodologia no ontexto de desenvolvimento de software.
27. Como e o pro esso de desenvolvimento de software orientado a objetos?
28. Quais os problemas apresentados pela abordagem estruturada top-down?
Cap
tulo 1: Introdu
~ao 27

29. Qual e a ideia- have da analise e projeto orientado a objetos e omo o projetista ome a
seu trabalho?
30. Qual a motiva ~ao para utilizar essa abordagem?
31. Quais as limita ~oes do modelo de objetos?
28
Refer^en ias Bibliogra as
[1℄ K. Arnold and J. Gosling. The Java Programming Language, Sun My rosystems, 1996.
[2℄ T. Bar-David. Obje t-Oriented Design for C++. P T R Prenti e-Hall, 1993.
[3℄ G.S. Blair, J.J. Gallagher & J. Malik. Generi ity vs Inheritan e vs Delegation vs
Conforman e vs ... Journal of Obje t-Oriented Programming, 2(3): 11-17, Septem-
ber/O tober 1989.
[4℄ G.S. Blair. Basi Con epts III (Types, Abstra t Data Types and Polymorphism). In
Obje t-Oriented Languages, Systems and Appli ations, G.S. Blair, J. Gallagher, D.
Hut hison & D. Shepherd (Eds.), Chapter 4, Pitman, 1991.
[5℄ M. Blaha. Aggregation of Parts of Parts of Parts. Journal of Obje t-Oriented Program-
ming, 6(5): 14-20, September 1993.
[6℄ G. Boo h. Obje t-Oriented Design with Appli ations. Benjamin/Cummings Publishing
Company, In ., 1991.
[7℄ G. Boo h J. Rumbaugh & I. Ja obson, The Unied Modeling Language User Guide,
Addison Wesley, 1999.
[8℄ D. Coleman et al. OO Developing: The Fusion Method, Prenti e Hall, 1994.
[9℄ R.H. Campbell & N. Islam. A Te hnique for Do umenting the Framework of an Obje t-
Oriented System. In Pro eedings of the Se ond International Workshop on Obje t Ori-
entation for Operating Systems, September 1992.
[10℄ L. Cardelli. A Semanti s of Multiple Inheritan e. In Pro eedings of the International
Symposium on Semanti s of Data Types, Sophia-Antipolis, Fran e, Le ture Notes in
Computer S ien e, 173: 51-67, G. Kahn, D.B. Ma Queen & G. Plotkin (Eds.), June
1984, Spring-Verlag.
[11℄ L. Cardelli & P. Wegner. On Understanding Types, Data Abstra tion and Poly-
morphism. Computing Surveys, 17(4): 471-522, De ember 1985.
[12℄ L. Cardelli. Modula-3 Report (revised), Systems Resear h Center, Digital, number 52,
November, 1989.

29
30 Refer^
en ias

[13℄ D. de Champeaux & P. Faure. A omparative Study of Obje t-Oriented Analysis

Methods. Journal of Obje t-Oriented Programming, 5(1): 21-33, Mar h/April 1992.
[14℄ J.O. Coplien. Advan ed C++: Programming Styles and Idioms. Addison Wesley, 1992.
[15℄ O.-J. Dahl, B. Myhrhaug & K. Nygaard. Simula 67 Common Base Language. Publi-
ation no. S-22 (revised), Norwegian Computing Center, Oslo, O tober 1970.
[16℄ O.-J. Dahl, E.W. Dijkstra & C.A.R. Hoare. Stru tured Programming. A ademi Press,
1972.
[17℄ S.R. Davis. C++ Obje ts that Change Their Types. Journal of Obje t-Oriented Pro-
gramming, 5(4): 27-32, July/August 1992.
[18℄ D. D'Souza. Navigating Those Learning Curves. Journal of Obje t-Oriented Program-
ming, 5(6): 21-25, O tober 1992.
[19℄ D. D'Souza. From Analysis to Design: Chasm, Gully, or Step?. Journal of Obje t-
Oriented Programming, 5(7): 16-19, November/De ember 1992.
[20℄ M. Eriksson. A Corre t Example of Multiple Inheritan e. ACM SIGPLAN Noti es,
25(7): 7-10, July 1990.

[21℄ D.G. Firesmith. Frameworks: The Golden Path to Obje t Nirvana. Journal of Obje t-
Oriented Programming, 6(6): 6-8, O tober 1993.
[22℄ J. Gallagher. Basi Con epts II (Variations on a Theme). In Obje t-Oriented Languages,
Systems and Appli ations, G.S. Blair, J. Gallagher, D. Hut hison & D. Shepherd (Eds.),
Chapter 3, Pitman, 1991.
[23℄ E. Gamma, R. Helm, R.E. Johnson & J. Vlissides. Design Patterns: Abstra tion and
Reuse of Obje t-Oriented Design. In Pro eedings of the 7th European Conferen e on
Obje t-Oriented Programming, ECOOP'93, Kaiserslautern, Germany, Le ture Notes
in Computer S ien e, 707: 406-431, Os ar M. Nierstrasz (Ed.), July 1993, Springer-
Verlag.
[24℄ E. Gamma, R. Helm, R.E. Johnson & J. Vlissides. Design Patterns: Mi ro-
Ar hite tures for Reusable Obje t-Oriented Software. Addison-Wesley, 1994.
[25℄ C. Ghezzi & M. Jazayeri. Progragramming Language Con epts, Wiley, third edition,
1997.
[26℄ A. Goldberg & D. Robson. Smalltalk-80: The Language and its Implementation.
Addison-Wesley, 1983.
[27℄ Neil Graham, Learning C++, M Graw-Hill, 1991.
[28℄ P. Grogono & A. Bennet. Polymorphism and Type Che king in Obje t-Oriented Lan-
guages. ACM SIGPLAN Noti es, 24(11): 109-115, Month 1990.
Refer^
en ias 31

[29℄ D. Halbert & P. O'Brien. Using Types and Inheritan e in Obje t-Oriented Langua-
ges. In Pro eedings of the 1st European Conferen e on Obje t-Oriented Programming,
ECOOP'87, Paris, Fran e, Le ture Notes in Computer S ien e, J. Bezivin, J.-M. Hul-
lot, P. Cointe & H. Lieberman (Eds.), 276: 20-32, June 1987, Springer-Verlag.
[30℄ D. Harel et al. STATEMATE: A Working Environment for the Development of Com-
plex Rea tive Systems. IEEE Transa tions on Software Engineering, SE-16(4): 403-
414, 1990.
[31℄ W. Haythorn. What is Obje t-Oriented Design?. Journal of Obje t-Oriented Program-
ming, 7(1): 67-78, Mar h/April, 1994.
[32℄ R. Helm, I.M. Holland & D. Gangopadhyay. Contra ts: Spe ifying Behavioral Com-
positions in Obje t-Oriented Systems. In Pro eedings of the 5th Annual Conferen e on
Obje t-Oriented Programming: Systems, Languages and Appli ations and the 4th Eu-
ropean Conferen e on Obje t-Oriented Programming, OOPSLA/ECOOP'90, Ottawa,
Canada, Spe ial Issue of ACM SIGPLAN Noti es, 25(10): 169-180, N. Meyrowitz (Ed.),
O tober 1990.
[33℄ I.M. Holland. Spe ifying Reusable Components Using Contra ts. In Pro eedings of
the 6th European Conferen e on Obje t-Oriented Programming, ECOOP'92, Utre ht,
Netherlands, Le ture Notes in Computer S ien e, 615: 287-308, O. Lehrmann Madsen
(Ed.), June/July 1992, Springer-Verlag.
[34℄ E. Horowitz & J.B. Munson. An Expansive View of Reusable Software. IEEE Tran-
sa tions on Software Engineering, SE-10(5): 477-487, May 1984.
[35℄ I. Ja obson et al. Obje t-Oriented Software Engineering { A Use Case Driven Approa h,
Addisson-Wesley, 1992.
[36℄ I. Ja obson et al. The Unied Software Development Pro ess, Addison Wesley, 1999.
[37℄ R.E. Johnson & B. Foote. Designing Reusable Classes. Journal of Obje t-Oriented
Programming, 1(2): 22-35, June/July 1988.
[38℄ R.E. Johnson & J.M. Zweig. Delegation in C++. Journal of Obje t-Oriented Program-
ming, 4(7): 31-34, November/De ember 1991.
[39℄ R.E. Johnson. Do umenting Frameworks Using Patterns. In Pro eedings of the 7th
Annual Conferen e on Obje t-Oriented Programming: Systems, Languages and Ap-
pli ation, OOPSLA'92, Van ouver, British Columbia, Canada, Spe ial Issue of ACM
SIGPLAN Noti es, 27(10): 63-76, A. Paep ke (Ed.), O tober 1992.
[40℄ S. Khoshaan & R. Abnous. Inheritan e. In Obje t Orientation: Con epts, Languages,
Databases, User Interfa es, Chapter 3, pp. 79-142, Wiley, 1990.
[41℄ G. Ki zales, J. des Rivieris & D.G. Bobrow. The Art of the Metaobje t Proto ol. MIT
Press, 1991.
32 Refer^
en ias

[42℄ D. Lea. Christopher Alexander: an Introdu tion for Obje t-Oriented Designers. ACM
SIGSOFT Software Engineering Notes, 19(1): 39-46, O tober 1993.
[43℄ H. Lieberman. Using Prototypi al Obje ts to implement shared behaviour in OO sys-
tems, OOPSLA'86, pp. 214-223, o t. 1986.
[44℄ B.H. Liskov & A. Snyder. Data Abstra tion and Hierar hy. Addendum to the Pro-
eedings, OOPSLA'87, Spe ial Issue of ACM SIGPLAN Noti es, 23(5):17 -34, May
1988.
[45℄ O. Madsen & B. Magnusson. Strong Typing of Obje t-Oriented Languages Revisited.
ACM SIGPLAN Noti es, 25(10): 140-150, O tober 1990.
[46℄ G. Masini, A. Napoli, D. Colnet, D. Leonard & K. Tombre. Obje t-Oriented Languages.
A ademi Press, 1991.
[47℄ J.D. M Gregor & T. Korso. Supporting Dimensions of Classi ation in Obje t-Oriented
Design. Journal of Obje t-Oriented Programming, 5(9): 25-30, February 1993.
[48℄ B. Meyer. Obje t-Oriented Software Constru tion. Prenti e-Hall, 1988.
[49℄ B. Meyer. Eiel: The Language, Prenti e Hall, 1991.
[50℄ B. Meyer. Design by Contra t. In Advan es in Obje t-Oriented Software Engineering,
D. Mandrioli & B. Meyer (Eds.), Chapter 1, pp. 1-50, Prenti e Hall, 1992.
[51℄ B. Meyer. Applying \Design by Contra t". IEEE Computer, 25(10): 40-51, O tober
1992.
[52℄ J. Mi allef. En apsulation, Reusability and Extensibility in Obje t-Oriented Program-
ming Languages. Journal of Obje t-Oriented Programming, 1(1): 12-35, April/May,
1988.
[53℄ D.E. Monar hi & G.I. Puhr. A Resear h Typology for Obje t-Oriented Analysis and
Design. Communi ations of the ACM, 35(9): 35-47, September 1992.
[54℄ T.J. Mowbray and R.C. Malveau. CORBA Design Patterns. John Wiley & Sons, 1997.
[55℄ G.J. Myers. Software Reliability. John Wiley & Sons, 1976.
[56℄ G.J. Myers. Composite/Stru tured Design. van Nostrand Reinhold Company, 1978.
[57℄ M.L. Nelson. An Obje t-Oriented Tower of Babel. OOPS Messenger, 2(3): 3-11, July
1991.
[58℄ J.J. Odell. Dynami and Multiple Classi ation. Journal of Obje t-Oriented Program-
ming, 4(8): 45-48, January 1992.
[59℄ J.J. Odell. Managing Obje t Complexity, part II: Composition. Journal of Obje t-
Oriented Programming, 4(8): 45-48, January 1992.
Refer^
en ias 33

[60℄ J.J. Odell. Six Dierent Kinds of Composition. Journal of Obje t-Oriented Program-
ming, 6(8): 10-15, January 1994.
[61℄ D.L. Parnas. On the Criteria to Be Used in De omposing Systems into Modules. Com-
muni ations of the ACM, 15: 1053-1058, 1972.
[62℄ H.H. Porter. Separating the Subtype Hierar hy from the Inheritan e of Implementation.
Journal of Obje t-Oriented Programming, 4(9): 20-29, February 1992.
[63℄ J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy & W. Lorensen. Obje t-Oriented
Modeling and Design. Prenti e Hall, 1991.
[64℄ J. Rumbaugh. OMT: The Obje t Model. JOOP, 7(8): 21-27, Jan. 1995.
[65℄ J.H. Saunders. A Survey of Obje t-Oriented Programming Languages. Journal of
Obje t-Oriented Programming, 1(6): 5-11, Mar h/April 1989.
[66℄ S. Shlaer & S.J. Mellor. Obje t Life y les: Modeling the World in States. Yourdon
Press, 1992.
[67℄ H.A. Simon. The Ar hite ture of Complexity. In The S ien es of the Arti ial, Se ond
Edition, MIT Press, 1981.
[68℄ G.B. Singh. Single Versus Multiple Inheritan e in Obje t-Oriented Programming.
OOPS Messenger, 5(1): 34-43, January 1994.
[69℄ A. Snyder. En apsulation and Inheritan e in Obje t-Oriented Programming Lan-
guages. In Pro eedings of the 1st Annual Conferen e on Obje t-Oriented Program-
ming: Systems, Languages and Appli ation, OOPSLA'86, Portland, Oregon, Septem-
ber/O tober, Spe ial Issue of ACM SIGPLAN Noti es, 21(11): 38-45, N. Meyrowitz
(Ed.), November 1986.
[70℄ B. Stroustrup. The C++ Programming Language. Se ond Edition, Addison-Wesley,
1992.
[71℄ W. Tra z. Software Reuse Myths. ACM SIGSOFT Software Engineering Notes,
13(1): 18-22, January 1988.

[72℄ D. Ungar and R. Smith. The Power of Simpli ity. OOPSLA'87, pp. 227-241, o t. 1997.
[73℄ G. Boo h, J. Rumbaugh & I. Ja obson. Unied Modelling Language, vers~ao 1, Rational
Softwre Corporation, jan 1997.
[74℄ The Obje t Management Group. http://www.omg.org
[75℄ I.J. Walker. Requirements of an Obje t-Oriented Design Method. Software Engineering
Journal, 7(2): 102-113, Mar h 1992.
[76℄ P. Wegner. Con epts and Paradigms of Obje t-Oriented Programming. OOPS Mes-
senger, 1(1): 7-87, August 1990.
34 Refer^
en ias

[77℄ N. Wilde & R. Huitt. Maintenan e Support for Obje t-Oriented Programs. IEEE Tran-
sa tions on Software Engineering, 18(12): 1038-1044, De ember 1992.
[78℄ T. Winograd & F. Flores. Understanding Computers and Cognition: A New Foundation
for Design. Addison-Wesley, 1986.
[79℄ N. Wilkinson. Using CRC Cards. Sigs Books, 1995.
[80℄ N. Wirth. Program Development by Stepwise Renement. Communi ations of the
ACM, 14(4): 221-227, April 1971.