Orientação a Objetos: Conceitos e Benefícios

Prévia do material em texto

1ºAula
Orientação a objetos
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
• conhecer os conceitos de Orientação a Objetos;
• compreender as dificuldades de se observar um problema e transformar em uma solução;
• entender os benefícios da orientação a objetos.
Prezados(as) alunos(as),
Em nossa primeira aula, vamos estudar os conceitos 
importantes sobre orientação a objetos.
Se ao final desta aula tiverem dúvidas, vocês poderão saná-
las através das ferramentas da plataforma de ensino.
Conto com a sua participação, aproveite para ler e refletir 
os objetivos de aprendizagem, afinal da sua participação 
dependerá seu aprendizado.
Bom Trabalho!
Bons estudos!
141
Análise de Sistemas II 6
Seções de estudo
1 – Conceitos da orientação a objetos
2 – A complexidade do domínio do problema
3 – Benefícios da orientação a objetos
1 - Conceitos da orientação a objetos
CONCEITO
CURIOSIDADE
“Uma abordagem orientada a objetos para o desenvolvimento de 
software 
O conceito de orientação a objetos já vem sendo 
discutido há algum tempo. Por volta de 1970, surgiram 
as primeiras publicações, mas a sua maior disseminação 
ocorreu nos anos 90, quando se tornou uma das principais 
metodologias de desenvolvimento de software. Desde o 
lançamento da primeira linguagem orientada a objetos, a 
SIMULA, várias referências da engenharia de software mundial 
como: Peter Coad, Edward Yourdon e Roger Pressman 
abordaram extensamente a análise orientada a objetos como 
um grande avanço no desenvolvimento de sistemas.
No início dos anos 80, surgiu a análise essencial para 
sistemas em tempo real, que ajudaram a análise estruturada 
por eventos, delimitando a área de atuação do sistema, através 
da utilização da lista de eventos, o conceito de “tecnologia 
introduzindo o modelo Entidade Relacionamento (DER). 
As suas principais vantagens residem em oferecer critérios 
objetivos para o particionamento do sistema, observando 
suas características, facilita a obtenção da solução, através dos 
eventos, isola os requisitos de restrições de implementação, 
de análise e sincroniza a modelagem de dados com a de 
processos.
Entretanto, os sistemas desenvolvidos baseados nas 
técnicas estruturadas ainda apresentam algumas limitações, 
principalmente quando da inclusão de novas funções ou 
alterações em funções já existentes, que na maior parte das 
vezes, provocam problemas em outras partes do software.
A grande esperança que levou aos estudos da orientação 
a objetos com mais intensidade foi a de suprir algumas 
das principais preocupações das empresas de software: a 
necessidade cada vez mais crescente de se construir softwares 
corporativos de forma muito mais rápida, com baixo custo, 
em desenvolvimento de software, de Orientação a Objetos. 
apresenta a sua visão do que entende por essa abordagem. 
Alguns dos conceitos encontrados são:
• a orientação a objetos pode ser vista como a 
abordagem de modelagem e desenvolvimento 
de sistemas que facilita a construção de sistemas 
complexos a partir de componentes individuais;
• o desenvolvimento orientado a objetos é a técnica 
de construção de software na forma de uma coleção 
estruturada de implementações de tipos abstratos 
de dados;
• desenvolvimento de sistemas orientado a objetos é 
um estilo de desenvolvimento de aplicações onde 
o encapsulamento potencial e real de processos 
e dados é reconhecido num estágio inicial de 
desenvolvimento e num alto nível de abstração, 
com vistas a construir de forma econômica o que 
• a orientação a objetos é uma forma de organizar o 
software como uma coleção de objetos discretos que 
incorporam estrutura de dados e comportamento;
• quando construídos corretamente, sistemas 
possuem estruturas bem conhecidas e provêm a 
oportunidade de criar e implementar componentes 
totalmente reutilizáveis;
• modelos orientados a objetos são implementados 
convenientemente, utilizando uma linguagem de 
programação orientada a objetos. A engenharia de 
software orientada a objetos é muito mais que utilizar 
mecanismos de sua linguagem de programação, é 
saber utilizar, da melhor forma possível, todas as 
técnicas da modelagem orientada a objetos;
• a orientação a objetos não é só teoria, mas uma 
usadas em inúmeros projetos e para construção de 
diferentes tipos de sistemas;
• a orientação a objetos requer um método que integre 
o processo de desenvolvimento e a linguagem 
de modelagem com a construção de técnicas e 
ferramentas adequadas.
A Orientação a Objetos é um dos maiores, e talvez o 
maior avanço em software destes últimos anos. Ela nos oferece 
uma forma mais natural de se analisar o mundo e transformar 
as necessidades em programas que irão resolver nossos 
problemas. Ela nos permite construir sistemas melhores e 
mais fáceis de dar manutenção.
As técnicas de análise estruturadas ainda hoje são as mais 
sempre tiveram grande aceitação desde que foram lançadas 
sendo utilizadas, a decomposição das funções (chamada 
mostrou-se inadequada em situações de sistemas complexos 
aperfeiçoamentos foram introduzidos desde então, e ajudaram 
existe uma probabilidade maior de que os sistemas criados 
142
7
com as técnicas estruturadas sejam mais difíceis de serem 
incrementados com novas funções e as alterações em funções 
já existentes, muitas vezes, provocam sérios problemas em 
outras partes do software.
A orientação a objetos permite modelar de forma mais 
natural o mundo real, pois as estruturas de dados são vistas 
como objetos, ou seja, têm características e funções. Seu maior 
objetivo é aumentar a produtividade do desenvolvimento de 
software através de uma maior expansibilidade e reutilização 
de código, além de controlar a complexidade e o custo de 
manutenção.
1.1
Por muitos anos, o termo “orientado a objetos” (OO) 
foi usado para denotar uma abordagem de desenvolvimento 
de software que usava uma das linguagens de programação 
orientadas a objeto (ex. Ada 95, C++ , Eiffel, Smalltalk). Hoje, 
o paradigma abrange uma visão completa da Engenharia de 
Software. Edward Berard, citado por Pressman (2006, p.552) 
Os benefícios da tecnologia orientada 
a objetos são incrementados se ele for 
endereçado cedo - através do processo de 
engenharia de software, considerando que a 
tecnologia OO deve avaliar seu impacto em 
todo este processo. Simplesmente empregar 
a programação OO (OOP) não irá produzir 
os melhores resultados. Os engenheiros de 
software e seus gerentes devem considerar 
também itens como Análise de Requisitos 
OO (OORA), projeto OO (OOD), análise 
de domínio OO (OODA), sistemas de banco 
de dados OO (OODBMS) e engenharia de 
software auxiliada por computador orientada a 
objetos (OOCASE). (PRESSMAN, 2006, s/p)
A orientação ao objeto se dedica a desenvolver um 
modelo orientado a objetos do domínio da aplicação. Os 
estão associadas com o problema a ser resolvido.
O enfoque da orientação a objetos é uma visão sobre um 
mundo como uma coletânea de objetos que interagem entre 
si, apresentando características próprias que são representadas 
pelos seus atributos e operações.
No paradigma orientado a objetos, os dados e as funções 
são vistos de forma agregada, não ocorrendo uma modelagem 
separada para cada um desses componentes; portanto, sob 
esse ponto de vista, a orientação a objetos favorece uma 
modelagem mais natural, que melhor retrata a realidade, 
pois processos e dados estão coligados, não se encontram 
dissociados em nenhuma atividade real.
software
2
problema
A tarefa da equipe de desenvolvimento de software é 
construir a ilusão da simplicidade (Booch, 2005), como mostra 
software 
o usuário.
Para o usuário, não importa o quão complexa é a estrutura interna 
do software, para ele o que importa é se o software resolve suas 
necessidades de forma fácil, rápida e segura. Para o usuário, o 
sistema deve ser simples.
A complexidade de um software é uma propriedade 
essencial e não acidental. Observa-se que a herança da 
complexidade deriva de quatro elementos:• A complexidade do domínio do problema – o 
domínio do problema que estamos citando aqui não 
está relacionado com “dominar o problema”, mas 
sim a abrangência, o escopo do problema, este escopo 
envolve os dados, informações, procedimentos, 
o problema. Geralmente a pessoa que desenvolve 
não é quem conhece o domínio do problema que 
está sendo analisado. É preciso destacar também 
que a tarefa de levantamento das necessidades do 
sistema é complicada e demorada, além disso, estas 
necessidades podem mudar ao longo do trabalho, 
ou seja, são instáveis. Devemos pensar também que 
o sistema precisará evoluir para continuar sendo útil 
para a empresa, portanto o domínio do problema 
não está apenas nos requisitos atuais levantados, 
mas também nas possibilidades de necessidades 
futuras que devem ser percebidas pela equipe de 
análise.
• 
– os desenvolvedores devem 
criar a ilusão da simplicidade, ou seja, por mais 
complexo que o software possa ser na sua arquitetura 
interna e nos seus procedimentos, para o usuário 
deve parecer sempre uma coisa simples e de 
fácil utilização. Outro ponto importante é que 
o tamanho do software não está ligado á sua 
qualidade, programas grandes demais não são 
ou mais complexos que outros menores, nem 
mesmo podemos dizer que programas menores 
são melhores porque foram melhor estruturados, 
tudo vai depender de como o software é construído 
e com que desenvoltura ele resolve os problemas 
do usuário. Outro problema importante que precisa 
ser gerenciado é a comunicação entre os integrantes 
da equipe de desenvolvimento, para evitar 
• 
– Um 
mesmo problema pode ser resolvido de várias 
de interesses entre integrantes da equipe de 
desenvolvimento, que podem querer, cada um dos 
integrantes, defender sua alternativa de solução 
como sendo a melhor entre todas as outras. 
Algumas vezes o desenvolvedor pode acabar 
143
Análise de Sistemas II 8
perdendo tempo tentando “reinventar a roda”, ou 
seja, criar coisas que já existem, ou ainda não querer 
aproveitar recursos já disponíveis, seria como se um 
construtor quisesse fabricar os tijolos que irá usar 
na sua obra, ou plantar as árvores para ter a madeira 
que precisará durante a construção. A falta de 
padronização dos procedimentos é outro problema 
que é comum na indústria de software
muito o trabalho em equipe.
• 
um sistema deverá se comportar em determinadas 
situações é uma tarefa que exige um grande esforço 
de equipe e uma grande percepção das necessidades 
e limitações do usuário.
software
Podemos dizer que sistemas complexos são aqueles que 
possuem algumas das características fundamentais, como:
• possuem um longo ciclo de vida;
• 
todos os detalhes do projeto;
• a complexidade pode ultrapassar a capacidade da 
percepção humana, o que vai exigir um esforço em 
conjunto para resolver determinados problemas;
• em alguns sistemas, a complexidade estará sempre 
presente e pode apenas ser gerenciada e não 
superada, mesmo que este gerenciamento deva ser 
Serão descritos a seguir alguns princípios para administrar 
a complexidade, ou seja, levar ordem ao caos.
Figura 1.1. A complexidade do software
Fonte: Booch (2005)
2.1
trazendo ordem ao caos
Administrar a complexidade dos sistemas é tarefa 
essencial, pois sem ela os sistemas acabam por não atender 
todas as necessidades dos usuários, ou podem atender de 
forma errada, além disso, os prazos não serão cumpridos e o 
de construção do sistema.
2.1.1
Dividir um problema maior em partes menores é 
importante para facilitar o entendimento das necessidades, 
pois é muito mais tranquilo administrar problemas menores 
um sistema de software complexo está sendo projetado é 
essencial decompô-lo em partes cada vez menores, cada 
Dessa forma, é possível satisfazer a uma restrição real que 
existe sobre a capacidade de cognição humana: para entender 
qualquer nível de um sistema, é necessário compreender 
somente um pequeno número de partes de uma vez (ao invés 
inteligente endereça diretamente a complexidade inerente do 
software através de uma divisão forçada do espaço do estado 
do sistema” (BOOCH, 2005, s/p).
Para entender melhor o problema como um todo, é 
preciso que se tenha inicialmente uma visão geral sobre 
ele, sem se preocupar inicialmente com os detalhes 
procedimentais que possam aparecer no decorrer do processo 
de desenvolvimento. A partir daí, esse problema “grande” 
deverá ser subdividido em problemas menores e, aí sim, a cada 
subdivisão, os detalhes irão aparecer naturalmente, mas aí já 
será mais fácil administrar a complexidade desses problemas, 
uma vez que eles irão aparecer em porções menores.
A complexidade é organizada como uma hierarquia, 
um sistema complexo é composto por subsistemas inter-
relacionados que, por sua vez, têm seus próprios subsistemas 
e assim por diante, até que se chegue a componentes 
quais serão os componentes mais elementares de um sistema 
e quais são os mais primitivos será uma decisão arbitrária 
da equipe de análise e depende basicamente da visão que o 
observador do sistema terá.
pois descobrir as abstrações e mecanismos comuns num sistema 
Um dos maiores problemas para os desenvolvedores 
de software é conseguir transformar necessidades de 
gerenciamento de informação em soluções de software. Os 
experimentos de Miller, citados por Booch (2005) relatam que 
ele concluiu que “um indivíduo pode compreender somente 
sete (mais ou menos duas) partes de informação ao mesmo 
tempo. Este número aparece como sendo independente do 
conteúdo da informação”. Miller observou que “o espaço do 
julgamento absoluto e o espaço de memória imediata impõem 
várias limitações na quantidade de informação que as pessoas 
estão aptas a receber, processar e relembrar.
Através da organização dos estímulos de entrada 
simultaneamente em várias direções e sucessivamente 
144
9
dentro de uma sequência de partes, o ser humano é capaz de 
interromper esse engarrafamento (entrave) de informação.” 
perceber até sete níveis de informação sem se perder, com 
uma variação de mais ou menos duas. A partir deste número 
da informação. Em termos contemporâneos, este processo é 
chamado .
Uma forma de facilitar o entendimento de sistemas 
complexos é descobrir abstrações, mecanismos comuns e 
elementos já conhecidos em outras situações.
CURIOSIDADE
Um motorista consegue dirigir um novo modelo de carro 
Wulf, citado por Booch, (2005) descreve que:
os humanos desenvolveram uma técnica 
poderosa e excepcional para lidar com a 
complexidade. Eles a abstraem. Uma vez 
que o ser humano é inábil para dominar um 
objeto complexo por total, ele escolhe ignorar 
os detalhes não essenciais, lidando, no lugar, 
com um modelo de objetos idealizado e 
generalizado” (BOOCH, 2005, s/p).
Em cada nível de abstração, os elementos cooperam 
entre si para desempenharem suas funcionalidades por meio 
de uma interface e oferecem serviços para os níveis mais altos.
3
O benefício principal do desenvolvimento Orientado a 
Objetos não é reduzir o tempo de desenvolvimento. Ele pode 
levar mais tempo que o desenvolvimento convencional 
porque na Orientação a Objetos se pretende que haja a 
promoção da reutilização futura e a redução dos erros 
posteriores e futuras manutenções. O tempo transcorrido até 
que o código esteja completo pela primeira vez é possivelmente 
ou em alguns casos ligeiramente maior.
O benefício da Orientação a Objetos consiste em que as 
interações subsequentes são mais rápidas e mais fáceis do que 
empregando um método convencional, porque as revisões estão 
mais localizadas. A prática mostra que é necessário um menor 
número de interações porque um maior número de problemas 
são descobertos e corrigidos durante o desenvolvimento.
As técnicas de Orientação a Objeto pressupõem que 
se possam criar sistemas compondo-se objetos previamente 
criados e, consequentemente, reduzindo-se o tempo 
produtividade e qualidade.
Durante as seções anteriores comentamos sobre algumas 
das vantagens do uso da tecnologiade orientação a objetos 
para desenvolvimento de sistemas, vamos agora destacar 
detalhes de alguns dos principais benefícios:
• 
desenvolvimento estruturado, em que se elabora um 
projeto e depois se faz os programas, podemos ter 
seus objetivos depois de implementado. No 
desenvolvimento OOP (Object Oriented Project, ou 
Projeto Orientado a Objetos), devido ao fato deste 
ser feito de maneira quase que interativa com o 
A pouca quantidade de código programável 
projeto.
• 
reage aos erros imprevistos como: uma falha na 
impressora, ou um disco cheio. Tanto maior for a 
potencialidade, maior a capacidade do programa 
em causar o menor “estrago” possível aos dados e 
evitar uma saída drástica do sistema.
• - Dizemos que quanto maior for a 
extensibilidade do software, maior será sua capacidade 
analistas.
• - A capacidade de se otimizar a 
produtividade do programador depende diretamente 
da maneira como o software disponibiliza a 
reutilização do código (programa fonte) gerado. 
já reutiliza código anteriormente gerado, porém a 
perfeita reutilização consiste na utilização completa 
de um código gerado para algum sistema sem 
qualquer outra adaptação prévia.
• - A aplicação dos 
conceitos da orientação a objetos na análise de 
sistemas permitirá modelar a empresa ou as áreas 
da aplicação de uma forma mais natural, visto que 
os recursos a serem aplicados retratam com mais 
facilidade o mundo real. A capacidade de retratar 
o universo pesquisado é moldado em diagramas 
mundo real. A própria transição entre etapas na 
construção do software, aplicando- se o paradigma 
os mesmos conceitos e linguagem.
• 
de métodos reduz a complexidade na construção 
do código dos programas. Isso traz simplicidade 
software.
Devemos lembrar que os benefícios da orientação a 
objetos serão maiores e mais evidentes se ela for adotada do 
software.
Na prática, podemos dizer que a maior vantagem 
da orientação a objetos é a facilidade de manutenção do 
sistema (quando OO é aplicado corretamente). Mas, tem 
como desvantagem um maior tempo para desenvolvimento. 
Levantar um sistema orientado a objetos dá um pouco mais de 
145
Análise de Sistemas II 10
trabalho que um sistema procedural, pois temos que planejar 
o sistema pensando nos objetos e suas funções e não apenas 
nas funções que o sistema irá executar.
A orientação a objetos também possui algumas desvantagens 
• maior tempo necessário para o desenvolvimento do 
projeto do sistema;
• complexidade no aprendizado para 
desenvolvedores de linguagens estruturadas – 
com o desenvolvimento estruturado sentem maior 
orientação a objetos;
• maior uso de memória, por exemplo para aplicações 
móveis em algumas linguagens como o JavaME;
• maior esforço na modelagem de um sistema OO do 
que um sistema estruturado, porém oferece menor 
• dependência de funcionalidades já implementadas 
em superclasses no caso da herança, implementações 
espalhadas em classes diferentes (veremos o 
CURIOSIDADE
Retomando a aula
A orientação a objetos surgiu com o intuito de tornar 
possível criar sistemas mais complexos de forma mais rápida 
e que pudessem receber manutenção de forma que não fosse 
necessário fazer muitas mudanças na estrutura do projeto do 
sistema.
Apesar da maior complexidade nos trabalhos iniciais, a 
orientação a objetos permite que sistemas mais complexos 
possam ser desenvolvidos mais rapidamente.
2 – A complexidade do domínio do problema
A complexidade dos sistemas precisa ser administrada, 
mas isto não é uma tarefa simples, pois envolve uma série 
de problemas relacionados a: complexidade do domínio do 
caracterização do comportamento de sistemas.
Uma das formas de gerenciar a complexidade é a 
decomposição, que permite dividir problemas grandes em 
partes menores, tornando-os problemas menores e mais 
facilmente gerenciáveis.
Os principais benefícios da orientação a objetos são: 
exatidão, potencialidade, extensibilidade, reutilização, 
mais simples.
No entanto, vamos observar que foram citadas várias 
outras vantagens, entre elas, a maior facilidade quando se 
software.
Podemos apontar outros benefícios importantes como 
o ciclo de vida mais longo para os sistemas, desenvolvimento 
mais acelerado sem que isto implique em perda da qualidade, 
possibilidade de se construir sistema muito mais complexos 
pela incorporação de funções prontas (reutilização), menor 
custo para desenvolvimento e manutenção de sistemas.
Vale a pena
PRESSMAN, Roger. Engenharia de Software. São Paulo-
SP: Makron Books, 2006. SOMMERVILLE, I. Engenharia 
de Software. 8ª Edição. Addison Wesley, 2007. BOOCH, 
Grady, JACOBSON, Ivar; RUMBAUGH, James. UML – 
guia do usuário. Elsevier, Rio de Janeiro. 2005.
pena ler
• YOUTUBE. Conceitos básicos de orientação a 
objetos. Disponível em: