1

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

2
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!

3
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).

4
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

5
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,

6
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

7
 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).

8
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

9
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.

10
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

11
 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?

12
 • 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).

13
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).

14
15
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)

16
 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

17
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

18
 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 abstrata de 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

19
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

20
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.

21
 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,

22
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)

23
 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)

24
 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#.

25
 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)

26
 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

27
 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:

28
 • 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.

29
 É 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)

30
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.

31
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.

32