aula02

Prévia do material em texto

Met. para de Desenvolvimento de Software
2º Aula
Metodologia orientada a objetos
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
Olá, pessoal, tudo bem? 
Chegamos à segunda aula da nossa matéria. Vamos ver 
aqui como funciona a Análise Orientada a Objetos, uma das 
metodologias mais atuais do ramo. Além disso, veremos uma 
introdução da Orientação a Objetos, um dos paradigmas mais 
utilizados atualmente pelos programadores.
A sua participação é muito importante para nós.
Bons estudos!
154
11
Seções de estudo
1 - Introdução à Orientação a Objetos
1 – Introdução à Orientação a Objetos
2 – Análise Orientada a Objetos
3 – Projeto Orientado a Objetos
Apesar de ser um tópico que se popularizou nas últimas 
décadas, a orientação a objetos (também chamada de OO) já 
era discutida desde a década de 1960 e 1970, com as linguagens 
SmallTalk e SIMULA, consideradas pioneiras nesse paradigma. 
Apesar disso, demorou certo tempo para que o paradigma 
orientado a objetos fosse popularizado.
Como vimos, a análise estruturada dominou a década 
de 1980, junto com as linguagens que adotavam o paradigma 
procedimental. Esse paradigma se baseia nos comandos 
e atualização de variáveis e cada programa escrito nesse 
paradigma é visto como um conjunto de funções que 
manipulam dados. Assim, tanto a análise estruturada quanto 
o paradigma procedimental viam dados e comportamentos 
como coisas separadas.
Existem vários nomes para o paradigma procedimental, 
dependendo do autor. Ele pode ser chamado de paradigma 
imperativo, paradigma modular ou paradigma estrutural.
Segundo Lee e Tepfenhart (2002), a programação 
procedimental eliminou o código spaghetti (nomeada em 
alusão ao excesso de instruções GOTO, que dificultavam o 
entendimento e a manutenção do programa), possibilitando 
um melhor modo para construir software. Apesar de a 
programação procedimental ajudar na administração de 
funções, ela pouco ajudava na administração de dados.
Lee e Tepfenhart ainda relatam que com a ascensão da 
modelagem de banco de dados na década de 1980, através 
de autores como Peter Chen e Edgard Codd, os projetistas 
passaram a ter mais ferramentas de modelagem de dados, mas 
passou a constatar que o paradigma procedural pouco ajudava, 
pois, como ressaltado, o paradigma procedural colocava pouca 
organização sobre os dados, ou seja, geria os dados de forma 
débil. Além disso, nenhuma das duas modelagens permitia 
capturar satisfatoriamente o comportamento dinâmico das 
entidades de um programa.
Assim, o paradigma orientado a objetos foi visto como 
o paradigma que satisfazia essas necessidades. Como veremos 
mais tarde, o paradigma orientado a objetos não vê um 
programa como um conjunto de funções que compõem, 
e sim um conjunto de objetos, onde cada objeto contém os 
dados que o identificam e os seus métodos, que representam 
seu comportamento perante o programa. Como os dados e 
funções ficam juntos, o programador pode estabelecer regras 
sobre o acesso aos dados. Graças a essa possibilidade, várias 
novas possibilidades surgiram na informática.
Na programação orientada a objeto, a aplicação (sistema) 
é uma rede dinâmica de objetos colaboradores. (LEE, 
Vamos ver agora os benefícios de usar a orientação a 
objetos.
1.1 - Benefícios da orientação a 
objetos
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 ocorra 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 o mesmo que o 
transcorrido em uma codificação convencional, 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, pois as revisões estão 
mais localizadas. A prática mostra que é necessário um menor 
número de interações porque um número maior de problemas 
é descoberto e corrigido durante o desenvolvimento.
As técnicas de orientação a objetos pressupõem que se 
possam criar sistemas compondo-se objetos previamente 
criados e, reduzindo-se o tempo de desenvolvimento, 
com um significativo ganho de produtividade e qualidade, 
consequentemente.
 A seguir, vamos destacar alguns benefícios do uso da 
orientação a objetos:
Exatidão: Devido à característica do desenvolvimento 
estruturado, em que se elabora um projeto e depois se faz os 
programas, podemos ter no final um sistema que não atenda 
perfeitamente 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 usuário, esse risco é 
significativamente diminuído. A pouca quantidade de código 
programável também reduz os problemas inerentes às 
mudanças das especificações durante o desenvolvimento do 
projeto.
Potencialidade: Define-se como o programa 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. 
Extensibilidade: Dizemos que quanto maior for a 
extensibilidade do software, maior será sua capacidade em 
adequar-se às especificações definidas pelos analistas.
Reutilização: 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. De fato, a maioria dos 
programadores profissionais 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.
Modelagem mais natural: 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 é moldada em diagramas que refletem 
exatamente o arranjo dos objetos no mundo real. A própria 
155
12Met. para de Desenvolvimento de Software
transição entre etapas na construção do software, aplicando-
se o paradigma orientado a objetos, são refinações sucessivas 
com os mesmos conceitos e linguagem.
Codificação dos programas de forma mais simples: 
Devido à estrutura de como se apresenta o paradigma da 
orientação a objetos, a codificação de métodos reduz a 
complexidade na construção do código dos programas. Isso 
traz simplicidade no momento de codificar, testar e manter o 
software.
Devemos lembrar que os benefícios da orientação a 
objetos serão maiores e mais evidentes se ela for adotada do 
início ao fim do processo de construção de 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 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.
No entanto, a orientação a objetos também possui 
algumas desvantagens com relação à análise estruturada, entre 
elas estão:
de linguagens estruturadas – Profissionais de desenvolvimento 
acostumados com o desenvolvimento estruturado sentem 
maior dificuldade em se adaptar aos novos conceitos da 
que um sistema estruturado, porém oferece menor esforço na 
em superclasses no caso da herança, implementações 
espalhadas em classes diferentes (veremos o conceito de 
herança e polimorfismo mais adiante).
A seguir, veremos as definições de Classes e Objetos, 
que sãoa base para o paradigma orientado a objetos.
1.2 - Objeto
Em relação ao objeto, Booch (2005) define: “Um objeto 
comportamento de objetos similares são definidos em suas 
(similares)”. 
Podemos definir um objeto como uma entidade do 
mundo real, podendo ser um carro, uma geladeira, uma 
televisão, um relatório, este parágrafo desta aula, etc. Pode 
representar algo concreto (como os exemplos acima) ou uma 
entidade conceitual (uma regra de um jogo, por exemplo).
Como vimos anteriormente, cada objeto possui 
seus dados e suas funções. Na verdade, os dados que são 
armazenados em um objeto são chamados de atributos, 
sendo que os conjuntos desses atributos formam o estado 
do objeto.
Por sua vez, as funções que ficam em um objeto, ou seja, 
o que um objeto pode fazer, são denominadas de métodos, 
que formam o comportamento do objeto. Os métodos são 
importantes, pois permitem que um objeto possa se comunicar 
com outro, por meio da troca de mensagens, chamando os 
métodos da outra classe. Além disso, cada objeto recebe uma 
identidade única, fazendo que seja distinguível de outros 
objetos que tenham valores dos seus atributos iguais.
Tomemos, por exemplo, um objeto que representa um 
carro (por exemplo, um Gol). Esse carro, por exemplo, tem 
velocidade, nível do combustível, potência, modelo e cor. 
Podemos chamar esses elementos de atributos desse objeto. 
Um carro pode acelerar e frear, caracterizando o que esse 
objeto pode fazer. Assim, podemos chamar essas duas ações 
de métodos desse objeto.
A seguir, veremos a definição de classe.
1.3 - Classe
Podemos chamar de classe o agrupamento de objetos 
que possuem características idênticas, ou seja, com a mesma 
estrutura de dados (definida pelos atributos ou propriedades) e 
comportamento (operações ou métodos).
Voltemos ao exemplo do Gol que mostramos 
anteriormente. Você concorda que outros modelos de outras 
marcas de carro, como Corsa, Uno, HB20, Fiesta (entre outros) 
possuem as mesmas características, ou seja, possuem os 
mesmos atributos (velocidade, nível do combustível, potência, 
modelo e cor) e fazem as mesmas ações (acelerar e frear)? Se 
você concorda, podemos agrupar esses objetos em uma classe 
denominada Carro.
156
13
Na realidade, quando implementamos um programa 
orientado a objetos, definimos as classes desse programa (ex. 
Carro, Moto, Relatório, Boletim etc), e ao mesmo momento, 
seus atributos e métodos. Após isso, para usar as classes, 
criamos um objeto, por meio de uma instanciação, onde 
atribuímos uma variável a um objeto no programa. Apesar 
desse nome, em muitas linguagens isso é bastante simples, 
sendo semelhante a uma inicialização de uma variável. Só que 
ao invés de atribuir um tipo predefinido a uma variável, você 
atribui um tipo que você mesmo criou a essa variável.
Agora que você já sabe o que são classes e objetos, vamos 
ver outras características da programação orientada a objetos 
que você deve saber antes de estudarmos a análise orientada 
a objetos.
1.4 - Outras características da 
orientação a objetos
Agora, vamos ver outras características que tornam a 
orientação a objetos uma tecnologia poderosa na construção 
de sistemas.
Abstração: A abstração consiste em enfocar os 
que é e o que ele faz), ignorando suas características internas 
formas fundamentais do ser humano lidar com complexidade. 
Assim, podemos usar uma parte das características e ações 
de um determinado objeto para modelar em um sistema 
computacional.
Hierarquia: A Hierarquia é um enfileiramento ou 
ordenação das abstrações. A estrutura do objeto é importante, 
uma vez que ilustra como diferentes objetos colaboram uns 
com os outros através de padrões de interação, chamados 
mecanismos. A estrutura de classes é igualmente importante, 
uma vez que destaca a estrutura comum e comportamento 
dentro de um sistema. A identificação de hierarquias entre 
classes e objetos dentro de um sistema de software complexo 
não é uma tarefa fácil, uma vez que requer a descoberta de 
padrões entre vários objetos.
No entanto, a partir do momento em que essas estruturas 
estiverem mapeadas, a estrutura do sistema e seu entendimento 
se tornam simplificados. 
Encapsulamento: O encapsulamento consiste em 
ocultar ao usuário o funcionamento interno de uma classe. 
A principal vantagem do encapsulamento é permitir que os 
programadores mudem a implementação de uma classe sem 
que precisem alterar algum código gerado. O encapsulamento 
é o empacotamento de dados (atributos) e de operações sobre 
esses (métodos), também conhecido como a capacidade 
de “esconder informação” de detalhes de implementação 
(abstração). No caso da orientação a objetos, os dados não 
podem ser acessados diretamente, mas através de mensagens 
enviadas para as operações. O uso de encapsulamento permite 
que a implementação de um objeto possa ser modificada 
sem afetar as aplicações que usam esse objeto ou a forma de 
acessá-lo.
Herança: A Herança é uma das principais 
características da orientação a objetos, pois permite o 
reaproveitamento de métodos e atributos, diminuindo o 
tempo de desenvolvimento do sistema e facilitando as futuras 
manutenções. 
Ela consiste no compartilhamento de atributos e 
operações entre as classes baseado num relacionamento de 
hierarquia. Permite que uma nova classe seja descrita a partir 
de outra classe já existente (reutilização). A subclasse herda 
as características e o comportamento da superclasse, além de 
poder adicionar novas características e comportamentos aos 
veículo algumas propriedades e operações, pois a classe 
automóvel pertence à classe veículo. Da mesma forma que 
um gerente herda as características de um funcionário, mas 
tem suas características próprias.
´
157
14Met. para de Desenvolvimento de Software
Polimorfismo: Consiste em um método de possuir 
várias implementações dentro de um mesmo programa, daí 
o nome polimorfismo. Por exemplo, a operação calcular o 
perímetro que é diferente para as instâncias de classe círculo 
e polígono ou a operação mover diferente para a janela de 
computador e para uma peça de um jogo de xadrez. 
O usuário não precisa saber quantas implementações 
existem para uma operação, ou explicitar qual método deve 
ser utilizado: a linguagem de programação deve ser capaz de 
selecionar o método correto a partir do nome da operação, 
classe do objeto e argumentos (parâmetros) para a operação. 
Assim, novas classes podem ser adicionadas sem a necessidade 
de modificação de código já existente, pois cada classe apenas 
define os seus métodos e atributos.
Agora que você já sabe como funciona o paradigma 
orientada a objetos, veremos como funciona a Análise 
Orientada a Objetos.
2 - Análise Orientada a Objetos
Segundo Engholm Jr. (2010), a etapa de análise serve 
para entender o problema a partir da perspectiva do cliente, 
sem preocupações relacionadas à tecnologia onde o sistema 
será implementado.
Assim, Engholm Jr. ressalta alguns objetivos que devem 
ser cumpridos nesta etapa:
A Análise Orientada a Objetos tem como objetivo, 
modelar quais serão as classes e os objetos que estarão no 
sistema, definindo seus papéis e o seu ciclo de vida. A base 
dessa análise são os Casos de Uso, vindos da descoberta dos 
requisitos. Por isso, ela também é chamada de Análise Baseada 
em Casos de Uso.
dele e descrevem a funcionalidade do sistema desempenhada pelos 
atores. Você pode imaginar um caso de uso como um conjunto 
de cenários, onde cada cenário é uma sequência de passos a qual 
descreve uma interação entre um usuário e o sistema. 
Imasters, 2006. 
A partir dos Casos de Uso, a análise OO detecta:
 Engholm Jr. ressalta que a análise OO gera como 
saídas:
Nesta aula, você aprenderá as etapas da Análise Orientada a Objetos. 
Nas próximas aulas, você aprenderá o que são os diagramas que 
citamos acima.
Agora, você vai saber das etapas que correspondem à 
Análise Orientada a Objetos.
2.1 - Etapas da Análise OO
Como você viu, para que possamos descobrir os 
componentes do nossosistema, precisamos saber quais serão 
os casos de uso do sistema. Mas, para sabermos quais casos 
de uso o sistema deverá ter, precisamos saber o que o cliente 
deseja. Assim, precisamos saber antes os requisitos do sistema.
Portanto, a primeira etapa da Análise Orientada a Objetos 
é a Elicitação de Requisitos, que é o processo de descoberta 
e entendimento do domínio do problema a ser atendido pelo 
sistema a ser construído, além das necessidades de negócio que 
devem ser contempladas por esse sistema.
Nesse processo participam os stakeholders, as pessoas que 
têm interesse no sistema a ser construído. Em um sistema 
comercial, podemos encaixar os diretores, funcionários, e 
proprietários da empresa nesse conceito.
Várias técnicas são aplicadas para extrair esses requisitos, 
tais como:
workshops, ou a técnica 
Delphi.
Além disso, os requisitos podem se dividir em:
Requisitos funcionais: São aqueles que definem 
funcionalidades ou ações que o sistema deve fornecer. Esses 
requisitos lidam com o que o sistema deve funcionar. Assim, 
os requisitos funcionais são, na maioria das vezes, convertidos 
para Casos de Uso.
Requisitos não funcionais: Descrevem atributos 
do sistema ou do ambiente do sistema, como extensibilidade, 
usabilidade, confiabilidade, desempenho, escalabilidade, 
performance etc.
Usamos, como exemplo, um projeto de software para 
um saque, informando sua conta, sua senha e o valor 
pretendido” é alguma ação que o sistema deve fazer, logo, é 
um requisito funcional. Já o requisito “O processo de saque 
deve ser completado em no máximo 30 segundos”. Fala de 
158
15
algum atributo que o sistema deve ter. Logo, é um requisito 
não funcional.
Com os requisitos levantados, podemos saber quais serão 
os casos de uso do sistema, que servirão de base para a nossa 
segunda etapa, que é a identificação dos componentes do 
sistema. Essa etapa compreende as seguintes tarefas:
entre os objetos.
Para isso, são usadas várias técnicas para mapear essas 
situações. Uma das formas mais usuais é a interpretação dos 
casos de uso, através da leitura dos casos e selecionando as 
seguintes situações:
Nomes, pronomes e frases substantivadas 
são grandes candidatas a serem classes e objetos. Nomes 
no singular (João, ele, ela, estação de trabalho) e nomes de 
referência direta (o sexto jogador, a transação) podem ser 
objetos. Já nomes no plural (pessoas, alunos, professores) são 
nomes podem representar 
propriedades (atributos) de um objeto, além de adjetivos e 
frases possesivas. Por exemplo, a idade da criança, o nível do 
Verbos, como pagar, solicitar, emitir, por exemplo, são 
candidatas a serem serviços, ou seja, métodos dessas classes.
Depois de selecionarmos essas situações, devemos 
eliminar alguns objetos essenciais “falsos”, através de um teste. 
Para cada objeto detectado, verifique se encaixa nas seguintes 
definições:
já selecionei antes?
pode ser definido totalmente?
Depois de refinarmos a lista, podemos verificar se há 
uma relação de generalização/especialização entre um ou 
mais objetos detectados. Uma abordagem para detectar isso é 
explicada por Lee e Tepfenhart:
Recomendamos a utilização da lista original de 
objetos potenciais, sem os objetos externos à 
aplicação, como a nossa lista de objetos que 
podem ser potencialmente utilizados em um 
relacionamento é um. Com essa lista, aplicamos 
os seguintes testes para cada par possível de 
objetos. Perguntamos: “O objeto A é um 
objeto B?” e “O objeto B é um objeto A?”. As 
respostas admissíveis são sempre, às vezes e nunca. 
Se a resposta para ambas às questões for nunca, 
os dois objetos não terão um relacionamento é 
um entre si. Se ambas as respostas forem sempre, 
(Eles ou são instâncias da mesma classe ou 
diferentes nomes para a mesma classe). Se a 
resposta para “O objeto A é um objeto B?” 
for sempre e a resposta para “O objeto B é um 
objeto A?” for às vezes [e vice-versa], então o 
objeto A terá um relacionamento é_um com 
p. 149 - Adaptado)
outro objeto, temos dois candidatos à herança. Por exemplo, 
se dissermos que um cliente é uma pessoa, e uma pessoa 
às vezes pode ser um cliente, então, dizemos que há um 
relacionamento entre eles. E em um programa, uma classe 
Cliente pode herdar atributos e comportamentos de Pessoa.
Por fim, devemos atentar a situações de composição 
(por exemplo: “Uma caixa tem 20 unidades de um produto”, 
“Um hotel possui quartos”, “Um boletim possui notas”), 
onde detectamos quando um objeto é composto por outros 
objetos. E também por situações de relacionamento, quando 
um objeto precisa saber sobre o estado de outro objeto para 
requerer os serviços deste. 
Agora que você já sabe das etapas e das técnicas da 
Análise Orientada a Objetos, veremos a etapa seguinte, que é 
o Projeto Orientado a Objetos.
3 - Projeto Orientado a Objetos
O Projeto Orientado a Objetos se dedica a desenvolver 
um modelo orientado a objetos de um sistema de software 
para implementar os requisitos. Os objetivos em um projeto 
OO estão relacionados à solução do problema que está sendo 
resolvido.
Embora a tecnologia orientada a objetos não seja 
nova, o Projeto Orientado a Objetos é uma abordagem 
inovadora para o desenvolvimento do software que, se bem 
implementada, trará benefícios substanciais para o aumento 
da produtividade com qualidade. É necessário, no entanto, 
que se consiga transpor as razões habituais de resistência para 
adoção de novas tecnologias.
Algumas das vantagens do Projeto OO são:
entre as entidades do mundo real para objetos do sistema.
adotaram ainda o projeto orientado a objetos? Alguns dos 
motivos apontados são:
know-how
não orientadas a objetos.
Além dos benefícios citados anteriormente, outros 
fatores ligados à produtividade também são esperados. Deve 
haver uma maior reutilização do software, acarretando ganhos 
159
16Met. para de Desenvolvimento de Software
de performance na construção de novos sistemas.
A partir da década de 90, as aplicações se tornaram mais 
complexas, demorando mais tempo para serem executadas e 
apresentando um índice proporcionalmente maior de falhas.
O tempo e o dinheiro necessários para a manutenção 
dessas aplicações também aumentaram substancialmente.
A fase de projeto é responsável por incorporar requisitos 
tecnológicos aos requisitos essenciais. Assim, o projetista 
deverá estar atento aos critérios de qualidade que o sistema 
terá que atender.
O projeto OO modela a solução e consiste das atividades 
de criação (como pode ser feito), enquanto que a análise 
modela o problema e consiste das atividades necessárias para 
entender o domínio do problema (o que deve ser feito).
A qualidade do projeto pode ser medida conforme os 
requisitos citados a seguir:
Funcionalidade: refere-se à existência de um conjunto 
de funções que satisfaz às necessidades explícitas e implícitas 
e suas propriedades específicas. Tem como subcaracterísticas: 
adequação, acurácia, interoperabilidade, segurança de acesso e 
conformidade.
Confiabilidade: diz respeito à capacidade do 
software de manter seu nível de desempenho, sob 
condições estabelecidas, por um período de tempo. Tem 
como subcaracterísticas: maturidade, tolerância a falhas, 
recuperabilidade e conformidade.
Usabilidade: refere-se ao esforço necessário para se 
utilizar um produto de software, bem como o julgamento 
individual de tal uso por um conjunto de usuários. Tem 
como subcaracterísticas: inteligibilidade, apreensibilidade, 
operacionalidade, atratividade e conformidade.
Eficiência: diz respeito ao relacionamento entre 
o nível de desempenho do software e a quantidade de 
recursos utilizados sob condições estabelecidas. Tem como 
subcaracterísticas: comportamento em relação ao tempo, 
comportamento em relação aos recursos e conformidade.
anutenibilidade: concerne ao esforço necessário 
para se fazer modificações no software. Tem como 
subcaracterísticas: analisabilidade, modificabilidade, 
estabilidade, testabilidade e conformidade.
Portabilidade: refere-se à capacidadedo software 
ser transferido de um ambiente para outro. Tem como 
subcaracterísticas: adaptabilidade, capacidade para ser 
instalado, coexistência, capacidade para substituir e 
conformidade.
Para auxiliar na análise e no projeto orientados a objetos, 
existem os diagramas da notação UML. Veremos esses 
diagramas a partir da próxima aula.
Retomando a aula
Parece que estamos indo bem. Então, para encerrar 
1 – Introdução a Orientação a Objetos
Vimos que a Orientação a Objetos é uma nova forma 
de enxergar elementos em um programa de computador. Ao 
invés de termos funções e dados separados, as classes definem 
tipos compostos por atributos e funções, proporcionando 
o encapsulamento dos dados. A orientação a objetos ainda 
facilita a portabilidade e a reusabilidade de código.
2 – Análise Orientada a Objetos
Vimos que a Análise Orientada a Objetos compreende a 
extração das classes, objetos, além de seus atributos e métodos 
relacionados e da extração de relacionamentos entre as classes. 
Para isso, são empregados os casos de uso extraídos através 
dos requisitos elicitados pelos stakeholders.
3 – Projeto Orientado a Objetos
Você percebeu que o Projeto Orientado a Objetos se 
dedica a desenvolver um modelo orientado a objetos de um 
sistema de software para implementar os requisitos. É uma 
abordagem nova, que propicia vários benefícios ao software.
PRESSMAN, Roger. Engenharia de Software. São Paulo-
SP: Makron Books, 2006.
SOMMERVILLE, I. Engenharia de Software. 8ª Edição. 
Addison Wesley, 2007.
James. UML – guia do usuário. Elsevier, Rio de Janeiro. 2005.
UML e 
C++-Guia prático de desenvolvimento orientado a objeto. São Paulo: 
Makron, 2002.
ENGHOLM JR, Hélio. Engenharia de Software na prática. 
São Paulo: Novatec Editora, 2010.
SEBESTA, Robert W. Conceitos de linguagens de programação. 
Porto Alegre: Bookman Editora, 2009.
Vale a pena
Vale a pena ler
Vale a pena acessar
DEVMEDIA. Análise e projeto orientado a objetos. 
Disponível em <http://www.devmedia.com.br/curso/
analise-e-projeto-orientado-a-objetos/336>. Acesso em: 24 
set. 2017.
UNESP. Projeto orientado a objetos. Disponível em <http://
www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/2006/
aula11_ProjetoOrientadoObjeto.pdf>. Acesso em: 24 set. 
2017.
CAELUM. Herança, reescrita e polimorfismo. [S.l.:] 
Caelum, [s.d.]. Disponível em: <https://www.caelum.com.
br/apostila-java-orientacao-objetos/heranca-reescrita-e-
polimorfismo/>. Acesso em: 24 set. 2017.
160