PROJETO ORIENTADO A OBJETOS UTILIZANDO UML

Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2 
 
 
SUMÁRIO 
1 INTRODUÇÃO ..................................................................................... 3 
2 MODELO DE ANÁLISE DE SOFTWARE (ORIENTADA A 
OBJETOS)..... ......................................................................................................... 4 
3 ENGENHARIA DE SOFTWARE APLICADA À ANÁLISE DE 
SOFTWARE ORIENTADA A OBJETOS ................................................................. 5 
4 ELEMENTOS DA MODELAGEM ORIENTADA A OBJETOS.............. 6 
4.1 Linguagem de modelagem unificada (UML).................................. 7 
4.2 Diagrama de classe ...................................................................... 9 
4.3 Casos de uso .............................................................................. 11 
5 VANTAGENS E DESVANTAGENS DA ANÁLISE ORIENTADA A 
OBJETOS.... .......................................................................................................... 14 
6 PADRÕES DE PROJETOS ............................................................... 16 
6.1 O que é um padrão de projeto? .................................................. 18 
7 PROGRAMAÇÃO ORIENTADA A OBJETOS ................................... 21 
7.1 Linguagens orientadas a objetos ................................................ 23 
8 DESENVOLVENDO COM PROGRAMAÇÃO ORIENTADA A 
OBJETOS... ........................................................................................................... 28 
9 REFERÊNCIAS ................................................................................. 31 
 
 
 
 
 
 
 
3 
 
1 INTRODUÇÃO 
Prezado aluno! 
O Grupo Educacional FAVENI, esclarece que o material virtual é 
semelhante ao da sala de aula presencial. Em uma sala de aula, é raro – quase 
improvável - um aluno se levantar, interromper a exposição, dirigir-se ao professor 
e fazer uma pergunta, para que seja esclarecida uma dúvida sobre o tema tratado. 
O comum é que esse aluno faça a pergunta em voz alta para todos ouvirem e todos 
ouvirão a resposta. No espaço virtual, é a mesma coisa. Não hesite em perguntar, 
as perguntas poderão ser direcionadas ao protocolo de atendimento que serão 
respondidas em tempo hábil. 
Os cursos à distância exigem do aluno tempo e organização. No caso da 
nossa disciplina é preciso ter um horário destinado à leitura do texto base e à 
execução das avaliações propostas. A vantagem é que poderá reservar o dia da 
semana e a hora que lhe convier para isso. 
A organização é o quesito indispensável, porque há uma sequência a ser 
seguida e prazos definidos para as atividades. 
Bons estudos! 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4 
 
2 MODELO DE ANÁLISE DE SOFTWARE (ORIENTADA A OBJETOS) 
 
Fonte: google.com.br 
A análise orientada a objetos, diferentemente do enfoque tradicional, sugere 
que um sistema é uma coletânea de objetos que interagem entre si, com 
características próprias, representadas por atributos e operações. Neste tipo de 
análise, os atributos representam os dados de um objeto e servem para expressar 
características e informações. Já as operações são as ações que podem ser 
realizadas pelo objeto. O mais interessante é a possibilidade de modelar o sistema 
usando objetos que representam elementos do mundo real. Isso permite que 
sistemas complexos sejam facilmente modelados e implementados, além de facilitar 
o seu crescimento e a manutenção. (Morais, 2018). 
Neste capítulo, você vai adquirir conhecimentos fundamentais para avançar 
no aprendizado sobre análise orientada a objetos. Explore conceitos básicos sobre 
o modelo, suas ferramentas, vantagens e desvantagens. (Morais, 2018). 
 
 
 
 
5 
 
3 ENGENHARIA DE SOFTWARE APLICADA À ANÁLISE DE SOFTWARE 
ORIENTADA A OBJETOS 
A era tecnológica almeja por softwares cada vez mais complexos. Essa 
complexidade está ligada diretamente à grande quantidade de informações que 
devem ser processadas simultaneamente. Com o tempo, os recursos tecnológicos 
passaram por diversas mudanças, tanto em seus dispositivos físicos quanto lógicos. 
A Engenharia de Software surgiu devido à necessidade de haver técnicas que 
norteassem o processo de desenvolvimento do software (Morais, 2018). 
Diante dos diversos conceitos, métricas e ferramentas que regem a 
Engenharia de Software, foram desenvolvidas maneiras de realizar a análise de 
software. Primeiramente, o modelo mais utilizado foi o modelo de análise 
estruturada, que ficou conhecido também como um modelo clássico. Por ser 
clássico, ele traz conceitos de base para se realizar a análise de um software. 
Porém, como citado anteriormente, vivemos em uma era em que os artefatos 
tecnológicos devem ser cada vez mais robustos e compatíveis às novas 
tecnologias. (Morais, 2018). 
A OOA (análise orientada a objetos, em inglês object-oriented analysis,) é 
uma técnica de análise semiformal para o paradigma de orientação a objetos. A 
análise orientada a objetos é um componente-chave do paradigma de orientação a 
objetos. Quando esse fluxo de trabalho é realizado, as classes são extraídas. Os 
casos de uso e as classes são a base de um produto de software orientado a objetos 
a ser desenvolvido (SCHACH, 2010, p.395). Dessa forma, “concentra-se na 
definição de classes e na maneira como colaboram entre si para atender aos 
requisitos dos clientes” (PRESSMAN; MAXIM, 2016, p. 172). Uma classe traz um 
conceito do mundo real, representa algum conceito, um objeto, que tem 
comportamento e características e que executa ações. 
Assim como as diversas vertentes da Engenharia de Software, a 
metodologia de análise de software também requer técnicas específicas para que 
todos os detalhes observados sejam documentados, seja por meio da escrita de 
 
6 
 
uma documentação específica, seja pelo uso de recursos gráficos. Veremos quais 
elementos são utilizados pela análise orientada a objetos no próximo tópico. 
Uma das metodologias existentes na Engenharia de Software é a 
metodologia ágil e que pode ser aplicada na análise de software. No The Official 
Agile Modeling Site, Scott Ambler (apud PRESSMAN; MAXIM, 2016, p. 81), 
descreve modelagem ágil (AM) da seguinte maneira: 
Modelagem ágil (AM) consiste em uma metodologia prática, 
voltada para a modelagem e documentação de sistemas baseados em 
software. Simplificando, modelagem ágil consiste em um conjunto de 
valores, princípios e práticas voltados para a modelagem do software que 
podem ser aplicados a um projeto de desenvolvimento de software de 
forma leve e eficiente. Os modelos ágeis são mais eficientes do que os 
tradicionais pelo fato de serem simplesmente bons, pois não têm a 
obrigação de ser perfeitos. 
4 ELEMENTOS DA MODELAGEM ORIENTADA A OBJETOS 
 
Fonte:google.com.br 
O modelo de análise de software estruturado faz uso do diagrama de fluxo 
de dados e do dicionário de dados, não se limitando a nenhum desses elementos, 
 
7 
 
até mesmo porque o uso de uma metodologia ou ferramenta irá depender do 
contexto ao qual ela será inserida. Dessa forma, para a realização da análise de 
software orientado a objetos, se faz comum o uso da linguagem de modelagem 
unificada (do inglês UML – unified modeling language) como elemento de 
representação gráfica e informacional de dados e informações de um software. 
(Morais, 2018). 
4.1 Linguagem de modelagem unificada (UML) 
A UML nos permite visualizar e especificar detalhes de um software em 
desenvolvimento por meio de uma linguagem específica. Ela permite que 
elementos, relacionamentos e diagramas sejam modelados. Esses elementos 
podem ser estruturais, comportamentais e, até simples anotações sobre os artefatos 
do software, que são compostos por classes, componente, interações, pacotes, 
dentre outros. Os relacionamentos entre as classes, ou seja, entre os objetos dentro 
de um contexto de orientação a objetos,ocorrem por meio de dependências, 
associações, implementações e até generalizações. Cada relacionamento é 
estabelecido conforme o problema a ser solucionado. (Morais, 2018). 
Para Larman (2007, p. 39), a palavra visual na definição é um ponto-chave. 
A UML é a notação diagramática padrão, de fato, para desenhar ou apresentar 
figuras (com algum texto) relacionadas a software – principalmente software 
orientado a objetos (OO). Em Fowler (2003 apud Larman, 2007), três modos pelos 
quais as pessoas aplicam UML são apresentados: 
 
• UML como rascunho: diagramas incompletos e informais 
(frequentemente rascunhados à mão em quadros brancos) criados 
para explorar partes difíceis do problema ou espaço de soluções, 
explorando o poder das linguagens visuais. 
 
• UML como planta de software: diagramas de projeto relativamente 
detalhados, usados seja em Engenharia reversa, para visualizar e 
 
8 
 
melhor entender o código existente em diagramas UML; ou geração 
de código (Engenharia avante). 
 
• Em Engenharia reversa: uma ferramenta UML lê o código fonte ou o 
código binário e gera (tipicamente) diagramas UML de pacotes, de 
classes e de sequência. Essas “plantas de software” podem ajudar o 
leitor a entender os elementos, a estrutura e as colaborações globais. 
 
• Antes da programação, alguns diagramas detalhados podem 
fornecer diretrizes para a geração de código (por exemplo, em Java), 
quer manualmente, quer automaticamente, com uma ferramenta. É 
comum que os diagramas sejam usados para uma parte do código e 
outra parte seja preenchida por um desenvolvedor que esteja 
codificando (talvez também aplicando rascunhos UML). 
 
• UML como linguagem de programação: especificação executável 
completa de um sistema de software em UML. Código executável 
será automaticamente gerado, mas não é normalmente visto ou 
modificado por desenvolvedores; trabalha-se apenas na “linguagem 
de programação” UML. Esse uso da UML requer um modo prático de 
diagramar todo o comportamento ou a lógica (provavelmente usando 
diagramas de interação ou estado) e está ainda em desenvolvimento 
em termos de teoria, ferramentas robustas e usabilidade. 
 
Ainda sob o ponto de vista do autor, “a UML descreve tipos de esboço de 
diagramas, tais como diagramas de classe e diagramas de sequência. Ela não 
superpõe a eles uma perspectiva de modelagem. Por exemplo, a mesma notação 
UML de diagrama de classes pode ser usada para desenhar imagens de conceitos 
do mundo real ou de classes de software em Java” (LARMAN, 2007, p. 40). 
 
 
 
9 
 
4.2 Diagrama de classe 
O diagrama de classe 
“fornece um conjunto inicial de elementos de notação que todos 
os outros diagramas de estrutura usam. A representação UML de uma 
classe é um retângulo contendo três compartimentos empilhados 
verticalmente [...]. O compartimento superior mostra o nome da classe. O 
compartimento do meio lista os atributos da classe. O compartimento 
inferior lista as operações da classe. Ao projetar um elemento de classes 
em um diagrama de classes, deve-se usar o compartimento superior, e os 
dois compartimentos inferiores são opcionais (os dois inferiores seriam 
desnecessários em um diagrama que ilustrasse um nível mais alto de 
detalhes, no qual o propósito fosse mostrar somente o relacionamento 
entre os classificadores (BELL, 2016, p. 3). 
A Figura 1 a seguir traz um exemplo da notação gráfica do diagrama de 
classes. 
 
 
 
O contexto que envolve a manipulação de objetos traz também a questão 
da herança, a qual permite que uma classe herde outras funcionalidades e até 
outros atributos. A representação gráfica desse conceito é realizada pela ligação 
entre as classes por meio de uma ponta de seta, já que o “traço” representa apenas 
uma associação. Neste caso, essa ponta de seta não deve ser preenchida e deve 
 
10 
 
apontar, da classe que está disponibilizando, seus atributos e operações. 
Chamamos essa classe de superclasse (Figura 2). 
 
 
 
De acordo com Pressman e Maxim (2016, p. 895), 
qualquer alteração nos atributos ou nas operações contidas 
dentro de uma superclasse é imediatamente herdada por todas as 
subclasses. Portanto, a hierarquia de classes torna-se um mecanismo pelo 
qual alterações (em altos níveis) podem ser imediatamente propagadas 
em um sistema. É importante notar que, em cada nível de hierarquia de 
classe, novos atributos e operações podem ser acrescentados àqueles que 
foram herdados de níveis mais altos na hierarquia. 
 
 
11 
 
 
 
4.3 Casos de uso 
O caso de uso é outro diagrama da UML, e Alistair Cockburn (2001, apud 
PRESSMAN; MAXIM, 2016, p. 149) observa que “um caso de uso captura um 
contrato [...] [que] descreve o comportamento do sistema sob várias condições, à 
medida que o sistema responde a uma solicitação de um de seus envolvidos”. Para 
Pressman e Maxim (2016, p. 149), basicamente, um caso de uso conta uma jornada 
estilizada sobre como um usuário (desempenhando um de uma série de papéis 
possíveis) interage com o sistema sob um conjunto de circunstâncias específicas. 
De acordo com Schach (2010, p. 290), outra forma de interpretar um caso 
de uso é que ele mostra a interação entre o produto de software e o ambiente no 
qual ele opera, isto é, o ator é o membro do mundo externo ao produto de software, 
ao passo que o retângulo no caso de uso representa o produto de software. 
Normalmente, é mais fácil identificar um ator. 
 
• Frequentemente, ator é um usuário de produto de software. No caso 
de um produto de software para a área bancária, os usuários desse 
 
12 
 
produto de software são os clientes e os funcionários do banco, como 
caixas e gerentes. 
 
• Em geral, o ator desempenha um papel em relação ao produto de 
software, que poderia ser como usuário deste. Entretanto, o iniciador 
de um caso de uso, ou alguém que desempenhe um papel crítico em 
um caso de uso, também desempenha um papel, portanto, é 
considerado um ator, independentemente de essa pessoa também 
ser um usuário do produto de software (Figura 3). 
 
 
 
Assim como no diagrama de classe, o caso de uso também traz 
associações, que relacionam os autores, os casos de uso, e até outros autores que 
podem estar envolvidos no mesmo contexto. Para Jacobson (1992 apud 
PRESSMAN; MAXIM, 2016, p. 150), algumas perguntas que devem ser 
respondidas por um caso de uso: 
 
• Quais são as metas do ator? 
• Que precondições devem existir antes de uma jornada começar? 
• Que tarefas ou funções principais são realizadas pelo ator? 
 
13 
 
• Que exceções poderiam ser consideradas à medida que uma 
jornada é descrita? 
• Quais são as variações possíveis na interação do ator? 
• Que informações de sistema o ator adquire, produz ou modifica? 
• O ator terá de informar o sistema sobre mudanças no ambiente 
externo? 
• Que informações o ator deseja do sistema? 
• O ator gostaria de ser informado sobre mudanças inesperadas? 
 
Diversos mecanismos podem ser utilizados na concepção de um caso de 
uso. Geralmente, as informações contidas nesse tipo de diagrama são oriundas de 
uma completa documentação de requisitos, os quais devem trazer os requisitos 
funcionais do sistema. Dessa forma, todos devem trazer mais clareza e consistência 
ao sistema, pois demonstram visualmente alguns de seus mais importantes 
aspectos, que são suas funcionalidades. (Morais, 2018). 
 
 
 
 
14 
 
5 VANTAGENS E DESVANTAGENS DA ANÁLISE ORIENTADA A OBJETOS 
A demanda social trouxe diversas versões da UML. Dessa forma, suas 
conotações buscaram sempre acompanhar a necessidade dos desenvolvedores de 
software. Com isso, uma das vantagens em utilizar a UML na análise de software 
orientada a objetos é que sempre há alguma atualização nova, para que sua 
usabilidade não fique obsoleta. Ela também traz facilidades que visam à melhor 
compreensão das funcionalidades de um sistema, deixando todos os detalhes mais 
claros,não só para os desenvolvedores, mas também para os clientes, que na 
maioria das vezes são leigos no assunto. (Morais, 2018). 
A desvantagem se encontra no tempo, o qual deve ser dedicado ao 
desenvolvimento dos diagramas e, consequentemente, de uma vasta 
documentação. Dessa forma, só é indicado dar início ao processo de 
implementação após todo o sistema ter sido especificado nos diagramas. Outro fator 
atrelado à desvantagem do uso da UML na análise de software orientado a objetos 
é a familiaridade da equipe desenvolvedora com as notações dos diagramas e com 
as ferramentas utilizadas para desenvolvê-los, um fato que acaba atrelado ao tempo 
– e sabemos que para obter lucro no desenvolvimento de um software o custo-
benefício deve estar ligado diretamente ao investimento de tempo, ferramentas e 
uma equipe especializada. (Morais, 2018). 
De qualquer forma, a Engenharia de Software traz métodos que podem ser 
adaptáveis a qualquer projeto. O importante é sabermos que temos diversas 
opções. Porém, para realizarmos a melhor escolha, devemos conhecer todas as 
técnicas disponíveis e sabermos como elas operam em um ciclo de 
desenvolvimento de software. (Morais, 2018). 
 
 
15 
 
 
 
 
 
16 
 
6 PADRÕES DE PROJETOS 
Projetar software orientado a objetos é difícil, mas projetar software 
reutilizável orientado a objetos é ainda mais complicado. Você deve identificar 
objetos pertinentes, fatorá-los em classes no nível correto de granularidade, definir 
as interfaces das classes, as hierarquias de herança e estabelecer as relações-
chave entre eles. O seu projeto deve ser específico para o problema a resolver, mas 
também genérico o suficiente para atender problemas e requisitos futuros. Também 
deseja evitar o reprojeto, ou pelo menos minimizá-lo. Os mais experientes 
projetistas de software orientado a objetos lhe dirão que um projeto reutilizável e 
flexível é difícil, senão impossível, de obter corretamente da primeira vez. Antes que 
um projeto esteja terminado, eles normalmente tentam reutilizá-lo várias vezes, 
modificando-o a cada vez. (SAGAH, 2018) 
Projetistas experientes realizam bons projetos, ao passo que novos 
projetistas são sobrecarregados pelas opções disponíveis, tendendo a recair em 
técnicas não orientadas a objetos que já usavam antes. Leva um longo tempo para 
os novatos aprenderem o que é realmente um bom projeto orientado a objetos. Os 
projetistas experientes evidentemente sabem algo que os inexperientes não sabem. 
O que é? (SAGAH, 2018) 
Uma coisa que os melhores projetistas sabem que não devem fazer é 
resolver cada problema a partir de princípios elementares ou do zero. Em vez disso, 
eles reutilizam soluções que funcionaram no passado. Quando encontram uma boa 
solução, eles a utilizam repetidamente. Consequentemente, você encontrará 
padrões, de classes e de comunicação entre objetos, que reaparecem 
frequentemente em muitos sistemas orientados a objetos. Esses padrões resolvem 
problemas específicos de projetos e tornam os projetos orientados a objetos mais 
flexíveis e, em última instância, reutilizáveis. Eles ajudam os projetistas a reutilizar 
projetos bem-sucedidos ao basear os novos projetos na experiência anterior. Um 
projetista que está familiarizado com tais padrões pode aplicá-los imediatamente a 
diferentes problemas de projeto, sem necessidade de redescobri-los. (SAGAH, 
2018) 
 
17 
 
Uma analogia nos ajudará a ilustrar este ponto. Os novelistas ou autores de 
roteiros (cinema, teatro, televisão) raramente projetam suas tramas do zero. Em vez 
disso, eles seguem padrões como “O herói tragicamente problemático” (Macbeth, 
Hamlet, etc.) ou “A Novela Romântica” (um sem-número de novelas de romances). 
Do mesmo modo, projetistas de software orientado a objetos seguem padrões como 
“represente estados como objetos” e “adorne objetos de maneira que possa 
facilmente acrescentar/remover características”. Uma vez que você conhece o 
padrão, uma grande quantidade de decisões de projeto decorre automaticamente. 
(SAGAH, 2018) 
Todos sabemos o valor da experiência de projeto. Quantas vezes você já 
não passou pela experiência do déja vu durante um projeto – aquele sentimento de 
que já resolveu um problema parecido antes, embora não sabendo exatamente 
onde e como? Se pudesse lembrar os detalhes do problema anterior e de que forma 
o resolveu, então poderia reutilizar a experiência em lugar de redescobri-la. 
Contudo, nós não fazemos um bom trabalho ao registrar experiência em projeto de 
software para uso de outros. (SAGAH, 2018) 
Os padrões de projeto tornam mais fácil reutilizar projetos e arquiteturas 
bem-sucedidas. Expressar técnicas testadas e aprovadas as torna mais acessíveis 
para os desenvolvedores de novos sistemas. Os padrões de projeto ajudam a 
escolher alternativas de projeto que tornam um sistema reutilizável e a evitar 
alternativas que comprometam a reutilização. Os padrões de projeto podem 
melhorar a documentação e a manutenção de sistemas ao fornecer uma 
especificação explícita de interações de classes e objetos e o seu objetivo 
subjacente. Em suma, ajudam um projetista a obter mais rapidamente um projeto 
adequado. (SAGAH, 2018) 
Nenhum dos padrões de projeto descreve projetos novos ou não-testados. 
Incluímos somente projetos que foram aplicados mais de uma vez em diferentes 
sistemas. Muitos deles nunca foram documentados antes. São parte do folclore da 
comunidade de desempenho de software orientado a objetos ou elementos de 
sistemas orientados a objetos bem-sucedidos — em nenhum dos casos é fácil para 
projetistas novatos aprender as lições. Assim, embora esses projetos não sejam 
 
18 
 
novos, nós os capturamos numa forma nova e acessível: como um catálogo de 
padrões, que tem um formato consistente. (SAGAH, 2018) 
6.1 O que é um padrão de projeto? 
Christopher Alexander afirma: “cada padrão descreve um problema no 
nosso ambiente e o cerne da sua solução, de tal forma que você possa usar essa 
solução mais de um milhão de vezes, sem nunca o fazer da mesma maneira” 
[AIS+77, pág. x]. Muito embora Alexander estivesse falando acerca de padrões em 
construções e cidades, o que ele diz é verdadeiro em relação aos padrões de projeto 
orientados a objeto. Nossas soluções são expressas em termos de objetos e 
interfaces em vez de paredes e portas, mas no cerne de ambos os tipos de padrões 
está a solução para um problema num determinado contexto. (SAGAH, 2018) 
Em geral, um padrão tem quatro elementos essenciais: 
 
1. O nome do padrão é uma referência que podemos usar para 
descrever um problema de projeto, suas soluções e consequências 
em uma ou duas palavras. Dar nome a um padrão aumenta 
imediatamente o nosso vocabulário de projeto. Isso nos permite 
projetar em um nível mais alto de abstração. Ter um vocabulário para 
padrões permite-nos conversar sobre eles com nossos colegas, em 
nossa documentação e até com nós mesmos. O nome torna mais 
fácil pensar sobre projetos e a comunicá-los, bem como os custos e 
benefícios envolvidos, a outras pessoas. Encontrar bons nomes foi 
uma das partes mais difíceis do desenvolvimento do nosso catálogo. 
 
 
2. O problema descreve em que situação aplicar o padrão. Ele explica 
o problema e seu contexto. Pode descrever problemas de projeto 
específicos, tais como representar algoritmos como objetos. Pode 
descrever estruturas de classe ou objeto sintomáticas de um projeto 
 
19 
 
inflexível. Algumas vezes, o problema incluirá uma lista de condições 
que devem ser satisfeitas para que faça sentido aplicar o padrão. 
 
3. A solução descreve os elementos que compõem o padrão de 
projeto, seus relacionamentos, suas responsabilidades e 
colaborações. A solução não descreve um projeto concreto ou uma 
implementação em particular porque um padrão é como um gabarito 
que pode ser aplicado em muitas situações diferentes. Em vez disso, 
o padrão fornece uma descrição abstratade um problema de projeto 
e de como um arranjo geral de elementos (classes e objetos, no 
nosso caso) o resolve. 
 
4. As consequências são os resultados e análises das vantagens e 
desvantagens (trade-offs) da aplicação do padrão. Embora as 
consequências sejam raramente mencionadas quando descrevemos 
decisões de projeto, elas são críticas para a avaliação de alternativas 
de projetos e para a compreensão dos custos e benefícios da 
aplicação do padrão. As consequências para o software 
frequentemente envolvem balanceamento entre espaço e tempo. 
Elas também podem abordar aspectos sobre linguagens e 
implementação. Uma vez que a reutilização é frequentemente um 
fator no projeto orientado a objetos, as consequências de um padrão 
incluem o seu impacto sobre a flexibilidade, a extensibilidade ou a 
portabilidade de um sistema. Relacionar essas consequências 
explicitamente ajuda a compreendê-las e avaliá-las. 
 
O ponto de vista afeta a interpretação de alguém sobre o que é, ou não, um 
padrão. O padrão de uma pessoa pode ser um bloco de construção primário para 
outra. Padrões de projeto não são projetos, como listas encadeadas e tabelas de 
acesso aleatório, que podem ser codificadas em classes e ser reutilizadas tais como 
estão. Tampouco são projetos complexos, de domínio específico, para uma 
 
20 
 
aplicação inteira ou subsistema. Padrões de projeto, neste livro, são descrições de 
objetos e classes comunicantes que precisam ser personalizadas para resolver um 
problema geral de projeto num contexto particular. (SAGAH, 2018) 
Um padrão de projeto nomeia, abstrai e identifica os aspectos-chave de 
uma estrutura de projeto comum para torná-la útil para a criação de um projeto 
orientado a objetos reutilizável. O padrão de projeto identifica as classes e 
instâncias participantes, seus papéis, colaborações e a distribuição de 
responsabilidades. Cada padrão de projeto focaliza um problema ou tópico 
particular de projeto orientado a objetos. Ele descreve em que situação pode ser 
aplicado, se ele pode ser aplicado em função de outras restrições de projeto e as 
consequências, custos e benefícios de sua utilização. Uma vez que em algum 
momento devemos implementar nossos projetos, um padrão de projeto também 
fornece exemplos em código – nesse caso, C++ e, algumas vezes, Smalltalk – para 
ilustrar uma implementação. (SAGAH, 2018) 
Embora padrões de projeto descrevam projetos orientados a objeto, 
baseiam-se em soluções reais que foram implementadas nas principais linguagens 
de programação orientadas a objeto, como Smalltalk e C++, em vez de 
implementações em linguagens procedurais (Pascal, C, Ada) ou linguagens 
orientadas a objetos mais dinâmicas (CLOS, Dylan, Self). Nós escolhemos Smalltalk 
e C++ por razões práticas: a nossa experiência do dia a dia foi com estas linguagens 
e elas estão se tornando cada vez mais populares. (SAGAH, 2018) 
A escolha da linguagem de programação é importante porque influencia o 
ponto de vista do projetista (usuário do pradrão): nossos padrões assumem 
recursos de linguagem do nível do Smalltalk/C++, e essa escolha determina o que 
pode, ou não, ser implementado facilmente. Se tivéssemos assumido o uso de 
linguagens procedurais, deveríamos ter incluído padrões de projetos como 
“Herança”, “Encapsulamento” e “Polimorfismo”. De maneira semelhante, alguns dos 
nossos padrões são suportados diretamente por linguagens orientadas a objetos 
menos comuns. Por exemplo, CLOS tem multi- métodos que diminuem a 
necessidade de um padrão como Visitor (pág. 305). De fato, há bastante diferenças 
 
21 
 
entre Smalltalk e C++, o que significa que alguns padrões podem ser expressos 
mais facilmente em uma linguagem que em outra. (SAGAH, 2018) 
 
7 PROGRAMAÇÃO ORIENTADA A OBJETOS 
O conceito de POO tem suas raízes na linguagem de programação simula 
67, criada por Alan Kay, o precursor dos conceitos desse paradigma de 
programação. Contudo, sua grande evolução foi totalmente alcançada com a 
chegada da linguagem de programação Smalltalk 80: 
De fato, algumas pessoas consideram Smalltalk a modelo base 
para uma linguagem de programação puramente orientada a objetos. Uma 
linguagem orientada a objetos deve fornecer suporte para três recursos 
chave de linguagem: tipos de dados abstratos, herança e vinculação 
dinâmica de chamadas a métodos (SEBESTA, 2018, p. 547). 
Linguagens que suportam a POO são, atualmente, muito usadas. Algumas 
das linguagens de programação mais novas, projetadas para a POO, não 
implementam mais conceitos de linguagens procedurais como as primeiras 
implementavam. Porém, ainda assim, empregam estruturas básicas da 
programação estruturada e são imperativas, como as linguagens Java e C#, 
atualmente muito utilizadas e consideradas exemplos de sucesso de POO. 
(SAGAH, 2018) 
Smalltalk 80 foi primeira linguagem a implementar completamente os 
conceitos da POO, pois, em 1980, mesmo com a evolução dos módulos e pacotes 
pelas linguagens de programação da época, os problemas ainda persistiam. Um 
dos maiores problemas com os recursos atuais era que não existia mecanismo para 
inicialização e finalização automática do tipo fornecido. (SAGAH, 2018) 
Segundo Tucker e Noonan (2009, p. 307) “As inicializações normalmente 
necessárias incluem abertura de um arquivo, alocação de memória e inicialização 
de variáveis locais ao módulo”. Já quanto às finalizações, incluem o fechamento de 
arquivos e a liberação de memória. 
 
22 
 
Além disso, alguns programadores e projetistas começaram a perceber que 
algumas necessidades não eram atendidas com as atuais linguagens de 
programação imperativa de decomposição funcional e abstração de dados, como 
os padrões de graphical user interfaces (GUI), que poderiam ser melhor 
implementadas com o conceito de objetos que pudessem trocar mensagens uns 
com os outros. Uma GUI poderia ser mais facilmente implementada se 
considerarmos, por exemplo, que seus componentes (botões, áreas de texto, 
imagens etc.) são tratados como objetos que podem interagir entre si e com o 
usuário do sistema. (SAGAH, 2018) 
Assim, a POO surge como um paradigma centrado no desenvolvimento de 
objetos, no lugar da atual decomposição funcional e abstração de dados. Na Figura, 
você pode perceber um pouco dessa diferença entre a atual programação 
estruturada e o conceito de objetos. (SAGAH, 2018) 
 
 
Em uma linguagem de POO, o encapsulamento dos tipos de dados e suas 
funções é alcançado por meio da implementação das classes. Uma classe é uma 
declaração de um tipo de objeto que encapsula os seus tipos de dados pelos seus 
atributos e funções por meio de seus métodos. É comum ouvir falar que uma classe 
serve como uma matriz de objetos, pois, ao determinar os seus atributos e métodos, 
 
23 
 
serve como um modelo para que diversas instâncias de um objeto sejam criadas a 
partir de sua estrutura. (SAGAH, 2018) 
Ao analisar a Figura, você pode perceber que um programa em 
programação estrutural possui um desempenho melhor que um mesmo programa 
em POO, e isso ocorre pelo fato de, na programação estruturada, um código ser 
executado após o outro sequencialmente, ao passo que na POO são necessários 
alguns desvios. Entretanto, a POO traz outros pontos que acabam sendo mais 
interessantes no contexto de aplicações modernas. Como, na maioria das 
aplicações, o desempenho das aplicações não é uma das grandes preocupações 
(devido ao poder de processamento dos computadores atuais), a POO se tornou 
muito difundida. (SAGAH, 2018) 
Na próxima seção, vamos abordar como as linguagens Java, C# e Python 
implementam os conceitos da POO. Essas linguagens serão exemplos por serem 
muito utilizadas atualmente no contexto de desenvolvimento de software. 
7.1 Linguagens orientadas a objetos 
Agora, você entenderá um pouco sobre as linguagens Java, C# e Python, 
atualmente muito utilizadas e que implementam os conceitos da POO. (SAGAH, 
2018)Java é uma linguagem de programação que foi desenvolvida pela Sun 
Microsystems no início da década de 1990. Ela se tornou um símbolo da POO, 
inclusive causando certa confusão, por julgarem que a POO era um paradigma de 
Java e não ao contrário (MACHADO; FRANCO; BERTAGNOLLI, 2016, p. 54). 
De fato, a característica mais marcante da linguagem de programação Java 
está relacionada a sua portabilidade, pois os sistemas construídos não são 
compilados em código nativo da plataforma. Programas em Java são compilados 
para um bytecode, que é executado por uma máquina virtual, a Java virtual 
machine, que permite que os programas escritos em Java possam ser rodados em 
qualquer plataforma compatível com a sua máquina virtual. (SAGAH, 2018) 
 
24 
 
Em Java, todo o programa usa classes e objetos, e é fundamental que o 
programador compreenda esses conceitos da POO para conseguir programar em 
Java. Os programas são escritos em pequenos pedaços separados, chamados de 
objetos. Segundo Machado, Franco e Bertagnolli (2016, p. 78), “Objetos são 
pequenos programas que guardam dentro de si os dados — em suma, as variáveis 
— que precisam para executar suas tarefas”. Os objetos também trazem em si, 
como sub-rotinas, as instruções para processar esses dados. As variáveis que um 
objeto guarda são chamadas de atributos, e as suas sub- -rotinas são chamadas de 
métodos. (SAGAH, 2018) 
Veja o exemplo de uma classe Cachorro em Java com os atributos nome, 
peso, altura e cor e o método pular (). 
 
 
 
Como você pode observar, a programação em Java é praticamente regrada 
pelos conceitos de POO, e as classes são a base de qualquer código Java. 
Qualquer análise para um novo programa em Java deve partir do entendimento do 
seu contexto e projeção das classes. (SAGAH, 2018) 
 
25 
 
Agora, vamos analisar a linguagem C#. A linguagem C# (lê-se C Sharp) é 
definida pela Microsoft, que a desenvolve como uma linguagem de POO que faz 
parte de sua plataforma de desenvolvimento .NET. Embora a linguagem C# tenha 
sido criada totalmente do zero pela Microsoft, foi baseada na linguagem C++, e 
possui muitos elementos das linguagens Java e Pascal. (SAGAH, 2018) 
A plataforma .NET na qual teve seu desenvolvimento inicial, apresentou 
algumas limitações que motivaram que, em 1999, fosse montada uma força tarefa 
para o desenvolvimento de uma nova linguagem para essa plataforma. 
Segundo Ledur (2018, p. 108): 
A criação da linguagem C# ajudou muito no desenvolvimento do 
.NET, pois a plataforma não precisou se adequar a nenhum código de 
alguma linguagem já existente. O C# foi criado especificamente para .NET, 
sendo que muitas outras linguagens têm suporte à C#. 
Os principais objetivos do projeto da linguagem C# são: 
• Ser simples moderna e de propósito geral OO. 
• Ter uma linguagem e suas implementações que forneçam suporte 
para princípios de engenharia de software. 
• Ser destinada à utilização no desenvolvimento de componentes de 
software. 
• Possibilitar a portabilidade dos programas escritos em C#, assim 
como é possível na linguagem Java. 
• Fornece suporte para a escrita de programa, tanto hospedados 
localmente como incorporados. 
 
A Figura a seguir mostra um exemplo da estrutura de uma classe em C#. 
 
 
 
 
 
 
 
26 
 
 
 
 
Você pode perceber que, assim como em Java, C# possui uma estrutura 
semelhante com a declaração dos atributos da classe logo no início e depois em 
seus métodos, além de uma semelhança na sintaxe entre as duas linguagens, o 
que é explicado devido ao embasamento do C# na linguagem Java. (SAGAH, 2018) 
Para finalizar esta seção, vamos abordar a POO na linguagem de 
programação Python, que é uma linguagem de programação bastante utilizada por 
sua facilidade de aprendizado, aliada as suas características de programação de 
alto nível, de script, imperativa, OO e interpretada. (SAGAH, 2018) 
Python é uma linguagem que permite o desenvolvimento tanto no conceito 
de programação estruturada como a POO. Possui suporte a tipificação dinâmica, 
recursos de gerenciamento de uso de memória, além de oferecer uma abrangente 
biblioteca padrão. Os interpretadores Python possuem suporte para diversos 
sistemas operacionais, possibilitando a adaptação dos sistemas construídos. 
(SAGAH, 2018) 
 
27 
 
A origem do nome Python, apesar de confundido com o animal cobra, na 
realidade é oriunda do grupo de comédia britânico que era assistido pelo criador da 
linguagem, chamado Monty Python, formado por Graham Chapman, John Cleese, 
Eric Idle, Michael Palin, Terry Jones e Terry Gilliam. (SAGAH, 2018) 
Carinhosamente, são chamados de Pythonistas os programadores Python, 
e as referências aos trabalhos do grupo de comédia estão espalhadas pelos tutoriais 
e sua documentação (LUTZ; ASCHER, 2007). 
Python é uma linguagem muito simples, fácil de usar e aprender, apesar 
disso, também é uma linguagem extremamente robusta e utilizada nas mais 
diversas soluções: 
• back-end de sistemas Web, customer relationship management 
(CRM), ou gerenciamento de relacionamento com o cliente; 
• pesadas simulações de engenharia; 
• processamento pesado de efeitos especiais de filmes; 
• soluções de análise de dados (data analytics); 
• aprendizado de máquina, do inglês machine learning (ML). 
 
Veja o exemplo de uma classe Pessoa em Python 
 
 
 
 
 
 
 
28 
 
 
 
Apesar da sintaxe do Python ser um pouco diferente da sintaxe de Java e 
C#, é possível verificar a estrutura da classe com a definição de atributos e métodos 
e que Python é outro exemplar de linguagem OO. Na próxima seção, você verá 
alguns exemplos da aplicação da programação OO em classes de exemplos, para 
fixar o entendimento. (SAGAH, 2018) 
8 DESENVOLVENDO COM PROGRAMAÇÃO ORIENTADA A OBJETOS 
Para ajudar a elucidar o conceito de POO, vamos começar analisando a 
seguinte situação: um exemplo em Java que demonstra a criação da classe Pessoa 
com os atributos nome, dataNascimento e CPF; e o método tirarCopias, que calcula 
o custo da geração de cópias em um sistema de gestão de impressões de uma 
escola. (SAGAH, 2018) Esse sistema deve calcular o valor da cópia embasado na 
seguinte regra: 
 
• para alunos da escola, o valor unitário da cópia será de R$ 0,07; 
• para os demais usuários, o valor unitário será de R$ 0,10. 
 
A diferença é que este requisito será implementado com os seguintes 
conceitos da POO: 
 
29 
 
• classes; 
• heranças. 
Observe na Figura, onde consta a classe Pessoa. 
 
 
Na classe Pessoa podemos observar os seguintes atributos: 
• nome; 
• cpf; 
• data nascimento. 
 
Observamos, também, que essa classe possui o método tirarCopias, que 
faz o cálculo do valor da cópia para pessoas em geral, ou seja, pessoas que não 
são alunos. Porém, você pode estar se perguntando, onde estão os dados do aluno 
e o método que faz o cálculo do valor da cópia quando se trata de um aluno? 
(SAGAH, 2018) 
Esses dados estão na classe Aluno, mas, como o Aluno também é uma 
pessoa e tem alguns atributos que são comuns as demais pessoas, não vamos 
repetir na classe Aluno. A Figura mostra como ficaria a classe Alunos em Java. 
 
30 
 
 
 
 
 
É possível, portanto, observar que no início da classe Aluno existe a 
declaração extends. Essa declaração significa que a classe Aluno está dizendo que 
herda a classe Pessoa, dessa forma, os atributos que são comuns à classe Pessoa 
não necessitam ser repetidos. Além disso, percebe-se que a classe Aluno possui o 
atributo matrícula, que é específico do Aluno. (SAGAH, 2018) 
Por fim, veja que, na classe Aluno, o método tirarCopias é alterado de 
acordo com o valor específico para os Alunos, o que é possível em razão de um 
outro recurso de POO: o polimorfismo. Polimorfismo é um recurso que permite ao 
objeto ter um comportamento diferente, dependendo da situação. Nesse caso, o 
cálculo do valor da cópia se altera por conta da situação de desconto de aluno.Pelos exemplos apresentados, percebe-se na prática alguns recursos e 
usos da programação OO e seus benefícios para a programação, possibilitando, 
principalmente, a reutilização do código. (SAGAH, 2018) 
Conceitos como os observados nos exemplos das Figuras 3 e 4 são casos 
comuns em POO, por isso é importante todo programador conseguir abstrair 
classes com seus atributos e métodos separados e, quando utilizar conceitos bases 
da POO, como herança de classes, evitar reutilização de código. (SAGAH, 2018) 
 
 
31 
 
9 REFERÊNCIAS 
BELL, D. Fundamentos básicos de UML: o diagrama de classes. Uma 
introdução aos diagramas de estrutura em UML 2. IBM developerWorks, 
Nova York, 2016. Disponível em: Accesso em: 22/07/2020. 
 
COCKBURN, A. Writing Effective Use-Cases. Reading: Addison-Wesley, 
2001. 
 
GAMMA, E. et al. PADRÕES DE PROJETOS: Soluções reutilizáveis de 
software orientado an objeto. 1. Ed. Porto Alegre: Bookman, 2007. P. 17-
20. 
 
GASPAROTTO, H. M. Os 4 pilares da Programação Orientada a Objetos. 
DevMedia, Rio de Janeiro, 2014. Disponível em: 
https://www.devmedia.com.br/os-4-pilares-da- -programacao-orientada-a-
objetos/9264. Acesso em: 15 set. 2019. 
 
GEOVANE, H. Entendendo e Aplicando Herança em Java. DevMedia, Rio 
de Janeiro, 2012. Disponível em: 
https://www.devmedia.com.br/entendendo-e-aplicando-heranca-em- -
java/24544. Acesso em: 15 set. 2019. 
 
FOWLER, M. UML Distilled. 3. ed. Reading: Addison-Wesley.2003. 
 
JACOBSON, I. Object-Oriented Software Engineering. Reading: Addison-
Wesley, 1992. 
 
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao 
projeto orientados a objetos e ao desenvolvimento iterativo.3. ed. Porto 
Alegre: Bookman, 2007. 
 
32 
 
 
LEDUR, C. L. Desenvolvimento de sistemas com C#. Porto Alegre: SAGAH, 
2018. 268 p. 
 
LUTZ, M.; ASCHER, D. Aprendendo Python. 2. ed. Porto Alegre: Bookman; 
O’Reilly, 2007. 566 p. 
 
MACHADO, R. P.; FRANCO, M. H. I.; BERTAGNOLLI, S. C. 
Desenvolvimento de software III: programação de sistemas web orientada 
a objetos em Java. Porto Alegre: Bookman, 2016. 220 p. (Série Tekne; Eixo 
Informação e Comunicação). 
 
RODRIGUES, J. Como criar minha primeira classe em C#. DevMedia, Rio 
de Janeiro, 2017. Disponível em: https://www.devmedia.com.br/como-criar-
minha-primeira-classe-em- -csharp/38785. Acesso em: 22/07/2020. 
 
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem 
profissional. 8. ed. Porto Alegre: AMGH, 2016. 
 
SCHACH, S.R. Engenharia de software: os paradigmas clássicos e 
orientado a objetos. 7. ed. Porto Alegre: AMGH, 2010. 
 
SEBESTA, R. W. Conceitos de linguagem de programação. 11. ed. Porto 
Alegre: Bookman, 2018. 758 p. 
 
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 
2011. 
 
TUCKER, A. B.; NOONAN, R. E. Linguagens de programação: princípios e 
paradigmas. 2. ed. Porto Alegre: AMGH, 2009. 630 p.