Академический Документы
Профессиональный Документы
Культура Документы
Ce
lia Mary Fis
her Rubira
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
1.1 Estrutura
~
ao de Software
3
4 Cap
tulo 1: Introdu
~ao
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
onabilidade, 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 prossionais
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.
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),
(iii) maximiza
~ao da independ^en
ia entre as partes do sistema (baixo a
oplamento e alta
oes~ao).
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,
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
Empregado
Clasificação Instanciação
<<instance_of>>
<<instance_of>>
joão:Empregado maria:Empregado
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
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
Empregado
Generalização Especialização
A classe base
classe derivada
classe derivada
B C
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
ba1 bu1 f1
(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
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()
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
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.
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, denir desenvolvimento
de software
omo um pro
esso atraves do qual nos renamos 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
Modelo OO
da Realidade O projeto deve ter a mesma
estrutura básica que o modelo.
Código
de alguma forma restringe o modo
omo as abstra
~oes podem ser denidas, 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. Renamento passo-a-passo8 propor
iona uma estrategia para a realiza
~ao desse
detalhamento[80℄. De fato, a metodologia de renamento 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 rena-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.
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 losoa 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 deni
~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 denido 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 deni
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
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:
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 deni
~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 deni
~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.
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.
Baseado
em
Objetos
+ Classes
Baseado
em
Classes
+ Herança
Orientado
a
Objetos
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, polimorsmo, 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.
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 desaador 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
Engenharia
de Sistemas
Análise
Projeto
Codificação
Teste
Manutenção
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
Análise
Projeto
Evolução
Modificação
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
FORTRAN
Decomposição Diagramas de
Funcional Estrutura de
Módulos
C
Diagramas de Diagramas de
Dependência Ação
de Processos PASCAL
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).
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.6 Exer
ios
1. Por que o modelo de objetos se apresenta
omo um modelo promissor para o desenvol-
vimento de software
onavel 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
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 Unied 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
[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 Unied 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. Khoshaan & 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. Unied 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 Renement. Communi
ations of the
ACM, 14(4): 221-227, April 1971.