1

ESCOLA SUPERIOR ABERTA DO BRASIL ESAB

ANLISE ORIENTADA A OBJETOS E O SEU IMPACTO NO DESENVOLVIMENTO DE

SOFTWARES

Nestor Flaviano Madureira Barbosa1

Fbio Luiz Bigati2

Resumo

Este trabalho trata-se do estudo para elucidar os principais conceitos, ferramentas e

tecnologias usadas no desenvolvimento e no apoio a confeco de sistemas de software
orientado a objetos. Conceitos estes, que por sua vez, so empregados desde a concepo do
sistema, at a sua implantao no ambiente operacional onde ele ter de operar. Este estudo
aborda os principais conceitos da Analise Orientada a Objetos (AOO), analisa processos de
software orientados a objetos, algumas tcnicas de desenvolvimento e as boas prticas de
desenvolvimento usadas atualmente e empregadas no mercado de trabalho pelas diversas
empresas de desenvolvimento de softwares existentes no mercado, conhecer um pouco sobre
as principais linguagens de programao que do suporte a abordagem de desenvolvimento de
software orientado a objetos mais usadas atualmente.

Palavras chave: Anlise Orientada a Objetos. Desenvolvimento de Software. Processos de

Software.

1. Introduo

Com o constante avano e uso da tecnologia em todos os ramos da cincia, diverso,

entretenimento, no mundo dos negcios e diversos outros ramos, os softwares tambm
tiveram que acompanhar esse crescimento. Foram se desenvolvendo novas ferramentas e
formulando novos mtodos de apoio ao desenvolvimento de sistemas para tais tecnologias e
equipamentos. Desde os anos 60, onde os desenvolvedores empregavam ainda conceitos da
anlise estruturada no desenvolvimento de softwares, viu-se a necessidade do uso de uma

1 Ps Graduando em Engenharia de Sistemas na Escola Superior Aberta do Brasil ESAB.

nestorflaviano@gmail.com.

2 Mestrando em Educao
 2

metodologia que os ajudassem a construir sistemas maiores, robustos e ainda mais confiveis,
de maneira que o suporte e manuteno desses sistemas fossem dados de maneira fcil, gil e
com um menor custo para as companhias.

Desde ento mtodos, ferramentas, equipamentos e outros meios que apiam o

desenvolvimento de sistemas do seu nascimento, passando pela implementao e testes, na
implementao no ambiente de trabalho, at sua evoluo, foram sendo criados, aperfeioados
e adequados de acordo com a necessidade e com as tendncias da poca em que eram criados.

Ainda hoje a busca para entender e trabalhar com essas metodologias muito grande,
existem diversas ferramentas de apoio ao desenvolvimento de sistemas orientado a objetos
disponveis atualmente para serem usadas, ferramentas essas sendo tanto de carter livre,
quanto proprietrio. Da vem dvida de que os conceitos mais bsicos da orientao a
objetos e das metodologias que empregam esse conceito esto sendo bem compreendidas
pelos usurios menos experientes.

Este artigo tem como principal objetivo conhecer e entender os principais conceitos
usados no desenvolvimento de um sistema de software orientado a objetos e tambm o
impacto resultante no emprego do uso dessa metodologia. Impacto esse que podemos
enxergar de diversas formas, como na reutilizao de cdigo fonte, modularizao do sistema,
em uma maior facilidade de manuteno, simplesmente pelo falto do cdigo fonte ficar mais
legvel e esbelto e altamente robusto, aumentando a clareza e entendimento das linhas de
cdigo.
 3

2. Conceitos de Orientao a Objetos

Tendo seu surgimento em meados dos anos 60 na Noruega, onde Kristen Nygaard e
Ole-Johan Dahl j utilizavam os conceitos de classes e herana usando a linguagem Simula
67, mais tarde refinada por Alan Kay, um dos precursores do paradigma da orientao a
objetos e o refinamento da linguagem smalltalk nos faz pensar em uma nova forma de
encarar o desenvolvimento de software. Alan kay ento formulou a teoria da Analogia
biolgica, onde um software se comporta como o corpo humano, onde cada rgo
funcionasse de forma independente e em harmonia com os outros rgos do corpo e que
tambm cada rgo interagiria com os demais, a fim de se tornar um nico sistema, o ser
humano.

A orientao a objetos nos mostra um mundo onde todo ele povoado por objetos, que
possuem uma estrutura e comportamento prprios e que comunicam entre si atravs de troca
de mensagens. Um sistema feito com o paradigma da orientao a objetos procura se basear
de forma nica e exclusiva a regra de negcios e no domnio do negcio onde o mesmo ser
implantado. A orientao a objetos fundamenta-se em uma srie de conceitos, entre eles:
Abstrao, Encapsulamento, Hierarquia, modularizao e etc. Veremos agora os principais
conceitos dessa que a abordagem de desenvolvimento de sistemas mais usada atualmente.

2.1 Objetos

Objetos podem ser entendidos como uma entidade que povoa o mundo real que por
sua vez possui caractersticas comuns a outros e se comunicam entre si. Os objetos possuem
estado, comportamento e identidade prpria.

Estado o que diz respeito a seus atributos e valores associados a eles, ou seja,
aquilo que o objeto sabe sobre si mesmo;
Comportamento Est ligado diretamente ao que o objeto faz. So as operaes que o
objeto dever executar;
Identidade Atravs de uma classe pode ser criada diversos objetos, sendo eles iguais,
porem o conceito de identidade faz com que os objetos sejam nicos, mesmo sendo do
mesmo tipo.

2.2 Classes
 4

As classes podem ser vistas como um modelo, ou seja, uma especificao dos
atributos e mtodos que dever conter os objetos do mesmo tipo. Um objeto em si, a
instancia de uma determinada classe, ele criado de acordo com o que est descrito na sua
classe. As classes podem ser de dois tipos:

2.2.1 Classes Concretas

So descries dos futuros objetos, onde futuramente durante a execuo do sistema, podero
ter objetos instanciados a partir dela.

2.2.2 Classes Abstratas

So classes que a partir delas, no podero ter objetos instanciados a partir dela,
servido apenas para agrupar/organizar atributos, operaes comuns.

Classe abstrata so projetadas com o intuito de conter implementaes completas,

prontas para prover operaes, onde outras classe podero herdar, e assim instanciar objetos
para fazer uso de tais funcionalidades, ou tambm de apenas uma definio de como sero
implementadas as operaes, deixando toda a implementao a cargo da classe herdeira onde
as operaes verdadeiramente sero escritas.

2.3 Mensagens

Para garantir a estabilidade do sistema, uma vez que os atributos de um objeto so

protegidos (encapsulados), no podero ser acessados diretamente. Os objetos comunicam-se
com outros objetos atravs da troca de mensagens, pois basta conhecer os servios que aquele
objeto oferece, no sendo necessrio saber como o mtodo implementado para poder fazer
uso de suas funcionalidades.

2.4 Associaes

Associaes em orientao a objetos, assim como nos modelos relacional e entidade

relacionamento de um banco de dados, so meios para se representar relacionamentos entre
classes (associao) e objetos (ligao), sendo que representa um conjunto de ligaes e
semntica comuns.
 5

2.5 Hierarquia

uma forma de organizar as entidades identificadas em uma anlise elicitao de

requisitos para a construo de uma estrutura organizada e fcil de gerir. Para organizar essas
classes usamos os conceitos de generalizao e especializao, que no final podemos notar
outro conceito bastante conhecido e uma das maiores vantagens da anlise e projeto orientado
a objetos, a herana. A figura 1, nos d uma idia de como representado uma estrutura
hierrquica.

Figura 1: Representao da estrutura Generalizao/Especializao

Fonte: Elaborao Prpria (2015)
Nota: Criado com Packet Tracer 5.0 e editado com Paint.

Generalizao uma estrutura hierrquica onde uma classe, nesse caso a classe
me/superclasse est localizada acima de outras classes (subclasses), sendo essa uma classe
mais genrica e as outras classes mais abaixo da sua estrutura hierrquica mais especializada.
Especializao o contrrio da generalizao, tendo em vista, que o refinamento feito nas
subclasses, tornando assim as classes acima mais genricas.

2.5.1 Herana
2.5.2
um conceito e tambm um mecanismo da orientao a objetos que permite que
subclasses implementem operaes e herde o mesmo comportamentos de classes situadas
imediatamente acima delas (superclasses). Temos dois tipos de herana:
Herana Simples Diz que uma subclasse, poder herdar atributos e operaes
apenas de uma superclasse.
Herana Mltipla Diz que uma subclasse, poder herdar atributos e operaes de
vrias outras classes, podendo existir dois problemas:
 6

o Coliso de Nomes Mtodos herdados de diferentes classes, e que venham a

ter o mesmo nome, ficaria difcil saber qual implementar.
o Herana repetida podendo herdar as mesmas caractersticas de vrias
superclasses, a mesma implementao contida em uma pode estar contida em
outra, gerando uma duplicidade na herana.

2.5.3 Agregao

Agregao um mecanismo de estruturao de classes do tipo: faz parte de um ou

est contido em, onde um objeto agregado composto por diversos objetos componentes.
Um exemplo no mundo real no qual podemos nos basear para entender tal conceito o de um
computador, onde formado por diferentes componentes como: monitor, discos rgidos, placa
me, processador e memria.

2.5.4 Composio

Podemos enxergar o conceito de composio, como um meio de juntar diversos

objetos simples, com a finalidade de criar um nico objeto mais complexo. Porm possui uma
diferena com a agregao, que na existncia dos objetos depois da destruio do objeto
composto. A destruio da classe agregadas, implica tambm na destruio das classes
componentes, uma vez que a relao de dependncia foi criada de um para o outro. E outra
diferena sua representao, como veremos nas figuras abaixo:

Figura 2: Agregao
Fonte: Elaborao Prpria (2015)
Nota: Criado e editado com Paint.
 7

Figura 3: Composio
Fonte: Elaborao Prpria (2015)
Nota: Criado e editado com Paint.

2.6 Encapsulamento

Consiste em esconder os detalhes internos da sua implementao, estado e do seu

comportamento, tendo como principal finalidade garantir a estabilidade e reuso do sistema. O
encapsulamento e a abstrao so conceitos complementares, isso quer dizer que atravs da
abstrao o encapsulamento provm que apenas as informaes mais relevantes sobre as
classes so reveladas.

2.7 Polimorfismo

O polimorfismo indica a capacidade de abstrair vrias implementaes diferentes em

uma nica interface (BEZERRA, 2006). O termo polimorfismo vem do grego e quer dizer
vrias formas, podendo assim o objeto se comportar de forma diferente a cada mensagem
que receber.

Por exemplo, em uma operao mover que implementada em uma superclasse, cada
mtodo que a implementar abaixo dela, responder de uma forma distinta. Um controle
remoto universal tambm contem diversas implementaes, podendo assim ser usado em
diversos aparelhos de TV, bastando assim ser configurado.

2.8 Reutilizao de Cdigo

Com a evoluo dos mtodos de engenharia de software, desenvolvimento e criao

de novas tcnicas e ferramentas e com uma maior maturidade dos processos que possibilitam
a criao de um software com maior confiabilidade, que por sua vez atendem com completeza
e consistncia as necessidades dos seus usurios, sistemas mais antigos foram dando lugar a
 8

sistemas mais novos e mais robustos. Sendo assim nos ltimos 20 anos houve uma
preocupao em maximizar o uso de sistemas pr-existentes, da nasceu necessidade de
criao de ferramentas que apiam o reuso de parte do cdigo ou do programa eu sua quase
totalidade.
Podemos enxergar a reusabilidade como forma de agilizar o desenvolvimento,
diminuir custo de produo e manuteno, uma vez que uma parte do sistema possivelmente
foi usado em ambiente de operao por diversas vezes, aumentando ainda mais a sua
confiabilidade .

Dentre diversos tipos de reuso, podemos destacar as seguintes:

Reuso de objetos e funes uma das principais vantagens no desenvolvimento

de um software orientado a objetos e tambm a forma de reuso mais utilizada, pois
funes e objetos de outros projetos podem ser aproveitados, alterando pouca coisa
ou as vezes nada do que j foi feito;
Reuso de componentes Este tipo de reuso j visa o uso total de um componente
do sistema, podendo ser um mdulo financeiro, de gerencia de usurios, de
compras entre outros, ou seja, pode ser um componente estrutural ou um
subsistema;
Reuso de Sistemas Nessa modalidade um sistema pode ser usado em sua
totalidade ou ser incorporado a outros sistemas, sendo necessrio adequao e
customizao, um bom exemplo de como podemos usar esse tipo de reuso com
os web services, que um meio usado para integras sistemas escritos em
plataformas diferentes e na comunicao dessas aplicaes.

3. Mtodos de Desenvolvimento Orientado a Objetos

Para que um software seja desenvolvido de forma consistente, preciso aliar boas
prticas da engenharia de software3 com um robusto e eficiente processo de desenvolvimento.
Diferentes tipos de sistemas necessitam de diferentes processos de desenvolvimento. Por
exemplo, um software de tempo real de uma aeronave deve ser completamente especificado
antes do inicio do desenvolvimento, enquanto que um sistema de comrcio eletrnico a

3 Engenharia de Software uma disciplina da engenharia relacionada com todos os aspectos da

produo de software, desde os estgios iniciais de especificao do sistema at sua manuteno,
depois que este entrar em produo (SOMMERVILLE, 2007).
 9

especificao e o desenvolvimento do software podem ser conduzidos paralelamente. O uso

de um processo de software inadequado pode reduzir a qualidade ou a utilidade do produto de
software a ser desenvolvido e/ou aumentar os custos de desenvolvimento. Este fato leva as
organizaes que produzem software a usar processos de desenvolvimento que sejam
eficientes e que atendam plenamente suas necessidades (SOMMERVILE, 2007).
Ian Sommerville diz um processo de software como um conjunto de atividades que
leva produo de um produto de software (SOMMERVILLE, 2007). Um sistema de
software durante todo seu processo de desenvolvimento, deve ser estudado e planejado desde
a sua concepo at a implantao/evoluo. Durante muito tempo, diversos mtodos e
tcnicas de foram desenvolvidos e propostos por diversos engenheiros de softwares e
pesquisadores no s da rea de softwares, mas tambm de processos de outras reas que
tambm so benficos e ajudam bastante e tem uma boa aplicabilidade na engenharia de
software.
Mtodos de desenvolvimento de software orientado a objetos, assim como outros
processos e ferramentas que auxiliam na elaborao dos artefatos, na modelagem e nas
diversas atividades do seu desenvolvimento so usadas com a finalidade de refinar e dar uma
maior qualidade aos produtos de softwares desenvolvidos. Sero mostradas agora, algumas
das metodologias mais usadas no desenvolvimento de software orientado a objetos.
RUP Essas siglas significam Rational Unified Process4. um processo de
engenharia de software criado pela Rational Software Corporation criado para apoiar o
desenvolvimento de sistemas orientado a objetos. Tendo como objetivo e principal
desafio a entrega de um software de qualidade dentro dos prazos estipulados em seus
cronogramas e dentro da margem de custos previstos. Pode-se dizer que o RUP um
refinamento do PU (processo unificado), pois conta com vrias semelhanas como as
mesmas fases, mesma filosofia de desenvolvimento, porm o RUP conta com mais
ferramentas de apoio e tambm um pouco mais usada e difundida.

As fazes do RUP so:

o Concepo a fase inicial do desenvolvimento, onde o escopo, as

estimativas iniciais do projeto, os casos de uso mais importantes do negocio
so identificados, e tambm um esboo da arquitetura do sistema feito;

4 Processo de Engenharia de software proprietrio criado pela Rational Software Corporation, adquirida
pela IBM, ganhando um novo nome IRUP que agora uma abreviao de IBM Rational Unified Process.
 10

o Elaborao - Nesta fase feito um refinamento dos requisitos colhidos na fase

de concepo e os demais requisitos remanescentes, permitindo uma melhor
mensurao do tamanho real que o sistema ir alcanar. Sua arquitetura se
tornar mais estvel, pois os requisitos centrais do sistema estaro mais bem
compreendidos, riscos j sero bem mais fceis de prever e serem eliminados
do projeto;
o Construo Esta fase onde acontecem iteraes intensas, pois o sistema
est sendo fisicamente construdo. Os fluxos de Anlise, projeto,
implementao e testes so feitos de tempos em tempos em intervalos que
chamamos de iterao. E a cada iterao um artefato ou um mdulo do sistema
estar pronto para ser testado e integrado a arquitetura principal do software;
o Transio A fase de transio a fase que o sistema sai do ambiente de
desenvolvimento e vai para o ambiente de execuo, onde sero feitos os
demais testes e tambm onde ser usado pelos usurios finais. Nessa fase
tambm ser confeccionado o manual do usurio, com os procedimentos de
instalao e uso das ferramentas que o sistema dispe.
Algumas caractersticas do RUP so:
o Iterativo e Incremental Visa a construo dos sistemas com uma arquitetura
estvel atravs de uma srie de incrementos, que por sua vez desenvolvido
primeiro os requisitos principais de sua arquitetura e os com maior prioridade
do ponto de vista do negcio, sendo que cada uma dessas iteraes composta
pelas atividades de anlise de requisitos, projeto, implementao e testes.
o Guiado por Casos de Uso Os casos de uso da UML no so utilizados
somente para a elicitao dos requisitos, mas tambm nas definies dos casos
de teste, onde os requisitos so avaliados para saber se so estveis ou mal
compreendidos, no planejamento da integrao do sistema e tambm na
criao e validao dos modelos de projeto.
o Centrado na Arquitetura O software segundo essa metodologia disposto
em mdulos coesos, tendo uma arquitetura estvel e de fcil manuteno, j
que logo nas fases iniciais j feito um esboo da arquitetura, sendo cada vez
mais aperfeioada nas fases seguintes.

Extreme Programming uma metodologia gil de desenvolvimento de softwares

no s orientado a objetos para pequenas e mdias equipes e ser usado para o
desenvolvimento de softwares com requisitos no to bem compreendidos e de
constantes mudanas nas suas especificaes. No muito aconselhada no
 11

desenvolvimento de grandes aplicaes, pois aplicaes de grande porte necessitam de

uma quantidade maior de artefatos, para que os engenheiros de softwares possam ter
uma idia do andamento e do progresso do projeto.
A XP5 enfatiza a produo de software de alta qualidade e que seja desenvolvido de
forma rpida, para que assim haja o cumprimento dos prazos de entrega estipulados no
projeto, fique dentro dos custos previstos no oramento e atenda as necessidades dos
usurios. A Extreme Programming conta com 4 (quatro) valores descritos abaixo:

o Comunicao fundamental para o sucesso, pois visa manter um

canal direto de comunicao entre desenvolvedores e clientes, dando
preferncia a conversas pessoais e mais amigveis do que entrevistas
formais, tendo como principal objetivo, criar um ambiente de harmonia
para que assim entender melhor os requisitos e agregar valores
positivos ao projeto;
o Simplicidade Manter todo o projeto da forma mais simples possvel,
melhorando e aperfeioando a cada iterao. Procurando implementar
somente os requisitos essenciais do sistema, para que assim o projeto
no sofra com atrasos. As implementaes simples evitam que a
arquitetura do software fique carregada de funcionalidades que podero
no sero usadas, podendo at dificultar o crescimento do sistema e
prejudicar na sua estabilidade;
o Feedback o resultado positivo da comunicao entre a equipe de
desenvolvimento e o cliente, uma vez que o cliente acaba se tornando
um membro da equipe, e ajuda no desenvolvimento do projeto do inicio
at a entrega do produto final. Sua participao responsvel pelo
esclarecimento dos requisitos menos compreendidos, definem a
prioridade de quais sero implementados e valida o sistema, tendo
assim mais chances de sucesso devido essa troca de informaes.

o Coragem preciso ter coragem para implementar as regras, coragem

na comunicao com os usurios, rompendo a barreira da falta de
comunicao para entender os requisitos e manter a simplicidade no
desenvolvimento do projeto.
5 Abreviao comumente usada para Extreme Programming
 12

Em XP os requisitos dos usurios so mostrados em cenrios que so conhecidos

como Estrias do Usurio, onde o requisito impresso em um carto e descrito nele
um conjunto de atividades a seguir na iterao, a fim de alcanar o resultado
necessrio, ou seja, a total satisfao do requisito pelo sistema de software.
A XP tambm incorpora em si todas as caractersticas fundamentais dos mtodos geis
de desenvolvimento de software e algumas mais, so elas:

o Planejamento Tem por objetivo a elaborao dos cenrios (estrias do

usurio), descrio das atividades, definio dos custos, estimativas de prazos e
cronograma detalhado, alm de definir as prioridades dos requisitos;
o Entregas frequentes A entrega rpida dos incrementos propiciam a equipe
um feedback rpido do software, sendo que atravs disso podem conhecer mais
afundo os requisitos dos clientes, podendo at apontar erros omissos e sugerir
mudanas para as prximas verses;
o Projeto simples Desenvolvimento de forma simples, focando somente na
resoluo de um requisito por vez, sem se preocupar com possveis
atualizaes futuras;
o Desenvolvimento Test-First Os desenvolvedores elaboram casos de testes
antes da implementao do cdigo, para testar a consistncia dos requisitos;
o Refactoring Sempre que possvel, o cdigo do projeto refinado, isso o
deixa mais simples e fcil de entender, facilitando as futuras alteraes e a
adio de novas funcionalidades;
o Programao em pares A equipe geralmente dividida em duplas e usam o
mesmo terminal, onde enquanto um codifica, o outro verifica os possveis erros
sintticos e semnticos, diminuindo assim os erros;
o Propriedade Coletiva O cdigo de responsabilidade de todos da equipe.
Qualquer membro da equipe pode propor ou realizar melhorias no sistema,
desde que saiba o que est fazendo. Sendo isso uma grande vantagem, pois
acaba com aquela dependncia de um membro da equipe que fica encarregado
de uma determinada funo no projeto;
o Integrao continua Logo que um incremento feito, ele integrado, e a
cada integrao so realizados novos testes;
o Ritmo Sustentvel Uma equipe XP, no deve fazer uma quantidade grande
de horas extras por duas semanas seguidas, a no ser que haja uma necessidade
 13

extrema, podendo assim sobrecarregar a equipe e gerando uma queda do

desempenho;
o Cliente Presente A presena do cliente se faz necessria no ambiente de
desenvolvimento, pois ele faz parte da equipe evitando assim suposies de
membros que no conhecem o domnio da aplicao e esclarecendo as dvidas
sobre os requisitos tratados no momento;
o Metfora Uma descrio do sistema criada sem a utilizao de termos
tcnicos, para guiar o desenvolvimento;
o Padronizao de Cdigo Todo o cdigo do sistema dever seguir padres
pr-estabelecidos, para que a equipe toda equipe o compartilhe;
o Reunies em p So realizadas reunies rpidas geralmente em p, para
discutir o que foi realizado e o que ainda falta para se realizar no projeto, assim
a equipe no perdem o foco do trabalho.

A XP exige uma abordagem extrema no sentido de desenvolvimento iterativo do

software, no engajamento de sua equipe em se relacionar com os clientes e tambm nos testes
das funcionalidades. Descarta o principio da mudana, uma vez que muito difcil prever
possveis mudanas nos requisitos do sistema em longo prazo.

4. Ferramentas de apoio

Atualmente existem diversos tipos de ferramentas que apiam o desenvolvimento de

software desde a fase de requisitos at o controle de verses. Toda ferramenta ou recurso
utilizado em quaisquer das fases da engenharia de software conhecida como ferramenta
CASE6. Sendo que o seu uso trs muitos benefcios como:

Aumento da produtividade - uma vez que diversos processos podem ser agilizados
pelo fato da ferramenta fazer grande parte do trabalho que um gerente de projetos ou
programador iria fazer;
Reduo de custos Com o aumento da produtividade pelo uso da ferramenta os
custos tendem a ficar menores, ainda mais pelo fato de existir diversas ferramentas
CASE livres;

6 Do ingls Computer-Aided Software Engineering que traduzindo Engenharia de Software Auxiliada

por Computador
 14

Tempo de desenvolvimento O tempo de desenvolvimento tambm tende a ser

menor pelo fato da ferramenta agilizar muito dos trabalhos que seriam feitos por uma
equipe;

Ferramentas CASE tambm podem ter alguns empecilhos em seu uso, por exemplo:
uma empresa que deseja fazer uso de alguma ferramenta CASE para automatizar seus
processos, deve primeiro fazer um estudo para ver se aquele tipo de ferramenta que esto
querendo usar realmente ir atend-los, depois disso vem o esforo para o treinamento da
equipe pois ir ter um gasto com a capacitao das pessoas que iro trabalhar com tais
ferramentas. Algumas ferramentas CASE so:

JUnit uma ferramenta open-source usada para fazer testes de unidade;

CVS, Subversion, GIT Ferramentas usadas para controle de verses;
Transformica, Unitech CodeFSW, JEE Spider Ferramentas usadas para a gerao
automtica de cdigo fonte.

5. Linguagens Orientadas a Objetos

Linguagens de programao orientadas a objetos so usadas na codificao de um

software orientado a objetos, pois elas implementam conceitos chave da orientao a objetos
dando suporte a conceitos como: herana, polimorfismo, classes, objetos, encapsulamento
entre outros conceitos vistos neste artigo. Existe uma grande quantidade de linguagens de
programao orientada a objetos.
 15

6. Referencias

BEZERRA, E. Princpios de Anlise e Projeto de Sistemas com UML. 2. Ed. Rio de Janeiro:
Campus, 2006.

BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML Guia do Usurio. 2. Ed. Rio de Janeiro:
Campus, 2006.

C.M.F.Rubira & P.H.S.Brito, Introduo Programao Orientada a Objetos usando Java,

apostila, IC-Unicamp, 2007.

GILLEANES T.A.Guedes. UML 2 uma abordagem prtica. Novatec. 2008.

LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto

orientados a objetos e ao desenvolvimento interativo. 3. ed. Porto Alegre: Bookman, 2007.

MCLAUGHLIN, B.; POLLICE, G.; WEST, D. Use a Cabea! Anlise e Projeto Orientado ao
Objeto. 1. Ed. Rio de Janeiro: Alta Books, 2007.

PILONE, D.; MILES, R., Use a Cabea! Desenvolvimento de Software, Rio de Janeiro,
AltaBooks, 2008.

PRESSMAN, Roger S. Engenharia de software. 6 ed. Porto Alegre: Bookman, 2006.

SOMMERVILLE, Ian. Engenharia de software. 8 ed. So Paulo: Pearson Addison-Wesley,

2007.