Modelagem

Inserir TítulodeAqui
Inserir Título
Sistemas Orientada
Aqui
a Objetos
Conceitos de Orientação a Objetos

Responsável pelo Conteúdo:

Prof. Me. Artur Ubaldo Marques Junior

Revisão Textual:
Prof.ª Me. Luciene Santos
 Conceitos de Orientação a Objetos

Nesta unidade, trabalharemos os seguintes tópicos:

• Contextualização;
• Conceitos de Orientação a Objetos;
• Material Complementar.

Fonte: iStock/Getty Images

Objetivos
• Recapitular os fundamentos gerais de OO, modelagem OO e arquitetura de software.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o
último momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Conceitos de Orientação a Objetos

Contextualização
A modelagem de sistemas orientada a objetos não surgiu por acaso, vários problemas
ocorreram, principalmente na década de 1970 que fizeram com que essa metodologia
começasse aos poucos a ser adotada e ganhasse a dominância para programas
principalmente mobile e web na atualidade.

Para você entender o que ocorreu, leia esse rápido artigo introdutório: https://bit.ly/3BBhPwT

Se você leu esse rápido artigo, deve ter percebido o problema e o desafio consequente
que isso causou.

Para fazer frente a isso, os engenheiros de sistemas e desenvolvedores começaram a

pensar em maneiras de resolver isso. Uma delas foi resgatar e trabalhar em paradigmas
e linguagens já desenvolvidas e postas um pouco de lado devido a processos dominantes
na época como a modelagem tipo Cascata ou Waterfall por exemplo.

É assim que começaremos nossa viagem pela nossa disciplina.

Portanto, você deve estar preparado para essa dinâmica e suas novas regras de jogo
no mercado de desenvolvimento de software, e fazer a diferença conhecendo e sabendo
usar as tecnologias mais adequadas para cada situação de desenvolvimento.

Isso poderá fazer com que você se torne um profissional diferenciado e com maiores
oportunidades.

6
Conceitos de Orientação a Objetos
Uma das primeiras coisas que devemos ter em mente desde o início desta disciplina
é que a Modelagem de Sistemas Orientados a Objetos não é uma panaceia para
qualquer desafio, não se aplica a todos os casos. Por fim, não é melhor e nem pior que
qualquer outra metodologia ou paradigma.

Trata-se apenas de uma abordagem eficaz para o tamanho e a complexidade

de sistemas de informação que vivenciamos atualmente no mundo. Principalmente
quando falamos em mobile e web. Claro, você pode desenvolver sistemas orientados a
outras plataformas tecnológicas, sem problema nenhum, inclusive IoT.

Vamos definir o básico primeiramente:

Metodologia de desenvolvimento de software: é uma estrutura que é usada

para estruturar, planejar e controlar o processo de desenvolvimento de um sistema de
informação. Dessa forma, há diversas metodologias, por exemplo:
• AGILE - Desenvolvimento ágil de software;
• CRYSTAL - Métodos Crystal;
• DSDM - Modelo de Desenvolvimento de Sistemas Dinâmicos;
• XP - Programação Extrema;
• FDD - Desenvolvimento Guiado por Funcionalidade;
• JAD - Desenvolvimento de Aplicações Conjuntas;
• LD - Desenvolvimento Enxuto;
• RAD - Desenvolvimento Rápido de Aplicações;
• RUP - Processo Racional Unificado;
• Scrum;
• Espiral;
• Ciclo de Vida de Desenvolvimento de Sistemas (SDLC);
• Cachoeira ou Waterfall.

Claro, isso inclui MDOO – Metodologia de Desenvolvimento Orientado a Objetos.

Dessa forma, você deve ter percebido que a Metodologia está preocupada com a
forma com que estruturamos pensamentos e as ações derivadas desses pensamentos
explicitamente, ou seja, de maneira a exteriorizar isso. Ela responde a perguntas relativas
a que, como, quando e por que devemos fazer algo.

Paradigma de software: Trata-se de uma palavra grega para “EXEMPLO”. É usada

para se referir a uma categoria de entidades que compartilham uma característica comum.
Em engenharia e desenvolvimento de software, são conhecidos como MODELOS.

7
7
UNIDADE
Conceitos de Orientação a Objetos

Processo: É uma estrutura imposta ao desenvolvimento de um produto de software.

Existem vários modelos para esses processos, cada um descrevendo abordagens para
uma variedade de tarefas ou atividades que ocorrem durante a sua execução. Processos
possuem atividades, por exemplo: (análise de requisitos, especificação, arquitetura de
software, implementação, teste, documentação, treinamento, suporte e manutenção),
entre outros.

Então o que é Metodologia de Desenvolvimento de Sistemas Orientado a Objeto?

(nome grande...)

Vamos lá!

MDSOO ou simplesmente OOM - Object Oriented Methodology, como é conhecida

pelo mundo afora, é uma “nova” abordagem de desenvolvimento de sistemas encorajando
e facilitando a reutilização de componentes de software.

Dessa forma, um sistema pode ser desenvolvido baseado em componentes que

permitam a reutilização efetiva do que já existe e facilitar dessa maneira o compartilhamento
dos componentes por outros sistemas.

A partir do uso dessa abordagem, pode-se conseguir maior produtividade, menor

custo de manutenção e melhor qualidade final do software.

Portanto, trata-se de uma metodologia.

OOM se vale de uma linguagem de modelagem unificada de padrão mundial para

produzir seus artefatos conhecida como UML – Unified Modeling Language criada
pelo OMG – Object Management Group.

UML é um padrão de modelagem para análise e design de OO, que foi amplamente
adotado no setor de TIC – Tecnologia da Informação e Comunicação.

O ciclo de vida, ou processo OOM, se preferir, possui 6 etapas:

• Planejamento comercial;
• Definição de arquitetura de negócios;
• Definição de arquitetura técnica;
• Planejamento de entrega incremental;
• Desenvolvimento incremental;
• Compilação;
• Implantação.

Bom, então você reparou que não é Programação Orientada a Objetos, certo?!

OOP – Oriented Object Programming, em linhas gerais, é um paradigma de

programação baseado no conceito de OBJETOS, que podem conter DADOS, na forma
de ATRIBUTOS, e códigos conhecidos como MÉTODOS.

8
 Calma, para poder usar UML, você precisa entender os conceitos, há uma série de
linguagem de programação híbrida para trabalhar com OOP, por exemplo, suportam
programação orientada a objeto em maior ou menor grau, tipicamente em combinação,
com programação processual, ou estruturada.

Essas linguagens são: JAVA, C++, C#, PYTHON, LISP, PHP, RUBY, SWIFT, PERL,
OBJECT PASCAL, OBJECTIVE C, DART, SCALA, COMMON e SMALL TALK.

Grande parte dessas linguagens utiliza o conceito de CLASSE (coleção de objetos

com características semelhantes que podem ser facilmente identificados e agrupados).
Algumas outras utilizam programação baseada em PROTÓTIPOS, portanto, não utilizam
classes. Entretanto, ambas as técnicas são orientadas a objeto. A mais amplamente
utilizada é a técnica baseada em CLASSES.

Apenas reforçando, estaremos focando em Metodologia Orientada a Objeto.

Vamos conhecer alguns dados históricos:

• Pesquisas sobre OO iniciaram no MIT durante a década de 60 do século XX;
• Alan Kay, trabalhando com a linguagem LISP em 66 usava o conceito de Objeto;
• Ivan Sutherland em também do MIT definiu Objeto e Instância;
• Somente em 1967, o conceito de programação de objetos ganhou corpo por
meio da linguagem SIMULA67, na Noruega, através de Ole-Joahn Dahl e Kristen
Nygaard, que também criaram a noção de classes e instâncias;
• XEROX desenvolve Smaltalk em 70 cunhou definitivamente o termo POO;
• Revista byte publica artigo em 81 divulgando em larga escala a POO;
• Atualmente as linguagens mais usadas para POO são JAVA, C# e VISUAL BASIC;
• PYTHON vem ganhando terreno desde 2010;
• JAVA SCRIPT é uma linguagem de programação baseada em PROTÓTIPO, talvez
uma das poucas em atividade.

Vamos, agora, definir o que é OO – Orientação a Objetos. Mas cuidado, UML não é
uma linguagem orientada a objetos, ela não fornece um método, no sentido de delinear
as etapas que devem ser tomadas no desenvolvimento de um sistema OO. Ela é mais
uma caixa de ferramentas, fornecendo notações e técnicas de modelagem que podem
ser implantadas quando necessário.

Dessa forma, enquanto em métodos estruturados tradicionais temos artefatos como

gráfico de estrutura, especificação do processo, diagramas de fluxo de dados, diagrama
hierárquico, diagramas entidade-relacionamento, dicionário de dados e diagrama de
transição do estado; numa abordagem Orientada a Objetos, temos, por exemplo, temos
diversos diagramas de UML que podem auxiliar, diagramas de classe, objeto, tempo,
estado, módulo, processo...
A orientação a objetos visa descrever um sistema em termos de objetos
(como os principais componentes) e a interação entre eles. Motivado
pelo desejo de chegar a abstrações estáveis, o design orientado a

9
9
UNIDADE
Conceitos de Orientação a Objetos

objetos é muitas vezes caracterizado como a realidade de modelagem,

que é o domínio do aplicativo. No entanto, muitas aplicações exigem,
pelo menos em parte, um sistema orientado para o design, uma
vez que envolvem artefatos do sistema para os quais não existem
correspondências claramente identificáveis no domínio do aplicativo.
Como exemplo, pense em um sistema baseado em “janelas”. Muitos
dos itens introduzidos em tal sistema pertencem a uma realidade
artificial, que na melhor das hipóteses é apenas vagamente análoga à
realidade, como normalmente a entendemos. Independentemente de
o projeto se destinar a um estudo preliminar antes da implementação
ou como uma justificativa “post hoc” do sistema real, a parte mais
importante e difícil do projeto é a identificação de objetos e a
caracterização do seu papel no sistema e a interação com outros
objetos. O design orientado a objetos é melhor visto como orientado
a classe, que é direcionado para a descrição estática de (classes de)
objetos, em vez de uma descrição da interação dinâmica entre objetos
reais.(ELLIENS, 2015)

Ou seja, a CLASSE é o elemento determinante da OO e, identificando objetos,

podemos modelar as CLASSES.

Certo, mas quais os princípios que devemos adotar na modelagem de Sistemas

Orientados a Objetos? Vamos levar em consideração para tanto os princípios da própria
OO, a saber:
• Identidade;
• Abstração;
• Classificação;
• Encapsulamento;
• Herança;
• Polimorfismo;
• Modularidade.

Esses elementos acima são considerados indispensáveis para que estejamos realizando
a Orientada a Objetos. Se qualquer um desse 4 elementos faltarem, deixamos de estar
no mundo OO.

Há também elementos úteis, porém, não fundamentais, e sua presença auxilia, mas
não inviabiliza, a saber:
• Tipificação;
• Concorrência;
• Persistência.

Tipicamente, utilizamos OO porque os sistemas modernos mudam constantemente

seus requisitos, precisam devido a isso serem fáceis de se manter, necessariamente
devem ser robustos, possuem altos níveis de abstração e reusarem seu código.

10
 Baseado no que aprendemos até agora, utilizar a metodologia OO requer uma ordem
disciplinada de eventos no tempo, por exemplo, o desenvolvedor deverá, nesta sequência:
definir os objetos e classes, descrever esses objetos, seus métodos, atributos e de que
forma os objetos responderão às mensagens. Além disso, deve definir o polimorfismo,
a herança, abstração de dados, encapsulamento e protocolo, bem como descrever a
relação entre esses objetos e descrever sua persistência.

Além do mais, absolutamente tudo nesse nosso sistema OO serão objetos.

Fácil?!

Identidade: os dados são organizados em entidades discretas conhecidas como

objetos. Esses objetos possuem comportamento e estado.

Objeto: é um componente autônomo que contém propriedades e métodos necessá-

rios para tornar útil um determinado tipo de dados. As propriedades de um objeto são
o que se conhece e seus métodos é o que ele pode fazer. Os objetos são os blocos de
construção fundamentais das aplicações da OO.

Classificação: os objetos são agrupados por suas afinidades ou características

comuns. Dessa forma, um grupo e objetos formará uma classe.

Classe: é um modelo para construir um tipo específico de objeto. Todo objeto é

construído a partir de uma classe. Cada classe deve ser projetada e programada para
realizar uma e, apenas, uma coisa. As classes podem ter associações.

Tabela 1 – Exemplo de associação e dependência entre classes

Proprietário Automóvel
proprietário
nome
marca
endereço
placa
telefone
possui ano
registrar
consultar
transferir_Proprietário
incluir
mudar_Placa

Instância: é um objeto específico construído a partir de uma classe específica. É

atribuído a uma variável de referência que é usada para acessar todas as propriedades e
métodos da instância.

Abstração: Booch (1994) definiu a abstração da seguinte maneira: “Uma abstração

denota as características essenciais de um objeto que o distingue de todos os outros
tipos de objetos e, portanto, fornece fronteiras conceituais definidas de forma clara, em
relação à perspectiva do visualizador”.

Encapsulamento: processo de unir atributos e métodos juntos dentro de uma classe.

Através do encapsulamento, os detalhes internos de uma classe podem ser escondidos
de fora. Portanto, encapsulamos comportamento e dados, sempre deixando detalhes
que não interessam a determinados processos, ocultos.

11
11
UNIDADE
Conceitos de Orientação a Objetos

Modularidade: processo de decomposição de um problema em partes menores,

melhor gerenciáveis e de menor complexidade. Booch (1994) a definiu como “a
propriedade de um sistema que foi decomposto em um conjunto de módulos coesivos
e ligeiramente acoplados”. Está ligada ao encapsulamento de tal forma a enxergar as
abstrações encapsuladas nos módulos com alta coesão interna.

Herança: diferentes objetos podem ter seus comportamentos semelhantes reusados

através da herança. Segundo Yaiser (2012), “herança permite que novas classes recebam
ou herdam as propriedades e os métodos das classes existentes. Em vez de criar uma
nova classe a partir do zero, faço referência à classe existente e simplesmente indico o
que é diferente”.
» Superclasse: é a classe designada como base da herança.
» Subclasse: herda propriedades da superclasse, mas possui as suas próprias
propriedades adicionadas.

Superclasse ESTUDANTE ESPECIALIZAÇÃO

(Herança)
Subclasse

ESTUDANTE ESTUDANTE
DE GRADUAÇÃO DE PÓS-GRADUAÇÃO
GENERALIZAÇÃO

Figura 1 – Exemplo de herança com uma superclasse e subclasses

Polimorfismo: Yaiser (2012) define como “o conceito de que vários tipos de objetos
são capazes de funcionar em uma determinada situação. Se você escrever uma mensagem
num papel, você poderá usar caneta ou lápis. O que se deve notar é que aquilo que você
usará caiba em sua mão e faça traços quando pressionado contra o papel.”

Persistência: os objetos possuem um tempo de vida, de tal modo que os atributos

deste objeto deverão mudar além de seu tempo de vida. Na programação tradicional,
a vida útil de um objeto é tipicamente o tempo de vida da execução do programa que
o criou. Em arquivos ou bancos de dados, o tempo de vida do objeto é maior que a
duração do processo que cria o objeto. É disso que estamos escrevendo.

Tipificação: trata-se de uma caracterização de um conjunto de elementos. Podem ser

tipificação forte, onde a operação em um objeto é verificada no momento da compilação,
ou tipificação fraca onde a operação é verificada apenas no momento da execução.

Concorrência: objetos inativos e objetos ativos, estes últimos, possuem threads de

controle independentes que podem ser executados simultaneamente com threads de
outros objetos, ou seja, eles se sincronizam.

A partir dessas definições de OO, podemos resumir então que o objetivo da análise
orientada a objetos é desenvolver de maneira precisa, consisa, de excelente entendimento,
com modelos corretos e representativos da situação problema, de tal forma que as
atividaes de modelagem envolverão Objetos, Dinâmica e Funcionalidades.

12
 O que devo fazer em cada uma dessas etapas. É simples, veja um exemplo:

Modelagem de Objetos: leva em consideração a identificação dos objetos, das

classes, as associações entre esses objetos – por exemplo, a relação entre X e Y é
professor → aluno –, os atributos dos objetos e suas associações e tentar simplificar as
classes desses objetos, utilizando o conceito de herança que acabamos de definir. Os
objetos possuem propriedades.

Figura 2 – Propriedades dos objetos

Modelagem da Dinâmica: aqui devemos pensar em criar cenários de sequencia de

interação entre esses objetos, identificar os eventos entre os objetos, ter um diagrama de
estado e casar objetos e eventos para verificar a consistência.

Modelagem Funcional: trata da identificação dos valores para entrada e saída de

processamentos, os cenários dos casos de uso, diagramas de fluxo de dados e suas
dependências funcionais, descrever de forma clara as funções e restrições e, por fim,
especificar os critérios de otimização necessários.

Tendo percorrido esse três grandes pilares, sua modelagem OO está feita.

Cada Modelagem possui seus diagrams da UML correspondentes que abordaremos

durante nossa viagem pelo conhecimento.

Introdução à Modelagem Orientada a Objetos

A abordagem cria a união do desenvolvimento de aplicativos e banco de dados e
o transforma em um modelo de dados unificado em um ambiente de linguagem. A
modelagem orientada a objetos permite a identificação e comunicação de objetos, além
de suportar abstração, herança e encapsulamento de dados. Ao contrário dos modelos
que são orientados para o registro, os valores orientados a objetos são apenas objetos.

Durante a fase de construção ou programação, as técnicas de modelagem são imple-

mentadas usando um idioma que suporte o modelo de programação orientado a objetos.

Portanto, OOM prega desenvolver progressivamente a representação de objetos

através de três fases: análise, design, design de objetos e implementação.

13
13
UNIDADE
Conceitos de Orientação a Objetos

Existe um forte movimento para a adoção de abordagens de engenharia de software

orientadas a objetos, sendo que OOM tem ao menos 3 técnicas diferentes: Rumbaugh,
Booch e Jacobson.

As técnicas de forma geral trabalham com as fases de:

• Análise: construção de modelo pelo analista baseado em situações do mundo real
mostrando as propriedades mais importantes;
• Desenho do Sistema: sistema alvo é organizado em subsistemas baseados na
análise estrutural e arquitetura proposta;
• Desenho de Objetos: o foco aqui é a estrutura de dados e algoritmos necessários
para a implementação das classes;
• Implementação: classes de objetos e relacionamentos desenvolvidos durante a fase
anterior são passados para a codificação e banco de dados.

O modelo de objeto produz o Diagrama de Objetos, que contém: classes, atributos,

operações e herança.

O modelo dinâmico, foca nos aspectos dinâmicos do sistema. Ele verifica as mudanças
que ocorrem nos estados dos diversos objetos a partir de eventos ocorridos. Usamos o
diagrama de estados para descrevê-los. Ele contém: os estados, sub e superestados,
eventos, ações e atividades.

O modelo funcional trabalha basicamente com a transformação do dado durante o

processamento pelo sistema e é normalmente descrito usando o diagrama de fluxo de
dados ou DFD e produz: processos, guarda de dados, fluxo de dados e entidades externas.

Leve em consideração que OOM utiliza engenharia de requisitos como ferramenta de

modelagem. Porém, lembre-se de que estamos modelando objetos de domínio e não o
desenho de um novo systema tradicional.

Para tirar suas dúvidas, quando falamos que em OOM tudo são objetos, vamos dar
alguns exemplos:

Entidades externas – interagem com o sistema que será modelado, podem ser
pessoas, dispositivos e outros programas.

Coisas – que fazem parte do domínio da aplicação na modelagem. Seriam, por

exemplo, sinais, relatórios, telas.

Eventos e ocorrências – que ocorrem no contexto de qualquer sistema, por exemplo,

transferência de recursos, ações de controle.

Papéis – realizados pelas pessoas que interagem com o sistema. Seriam exemplos,
caixas, supervisores, estoquistas etc.

Unidades Organizacionais – apenas as relevantes para a aplicação e, nesse caso,

seriam exemplos, divisões, grupos, equipes, áreas etc.

14
 Locais – que estabeleçam contexto com o problema que está sendo modelado.
Seriam exemplos, o chão da fábrica, doca de um porto, a âncora de um CD.

Estruturas – que definam a classe ou montem um objeto, neste caso, sensores,

veículos, computadores seriam alguns exemplos.

Claro, há coisas que não são considerados objetos em MOO, por exemplo, procedures
(imprimir, inverter...) e atributos como (preto, azul, 100Mb, leve, pesado...)

Como mencionamos anteriormente, engenharia de requisitos é extremamente

importante como ferramenta porque ela se baseia em cenários. As definições de cenários
são revisadas, com suas representações informais e mais formais e papéis no processo
de requisitos. As relações entre cenários, especificações e protótipos são exploradas e
definidas na perspectiva do raciocínio humano sobre os requisitos. Diversos métodos
para elicitação de requisitos existem. Um que se presta muito bem para avaliar riscos de
programação de calendários é o SCRAM.

Em linhas gerais, SCRAM vem de Schedule Compliance Risk Assessment

Methodology, ou em português Metodologia de Avaliação do Risco de Conformidade
do Agendamento ou (Calendário) se preferir.

Segundo WEAVER 2013, trata-se de uma abordagem para identificar riscos para
o cumprimento da programação do programa de desenvolvimento. SCRAM pode
ser utilizado:
• Por organizações para construir um cronograma que maximize a probabilidade de
cumprimento da programação;
• Para garantir que os riscos comuns sejam abordados antes do cronograma ser
resolvido no início de um projeto;
• Para monitorar o status do projeto, realizado ou ad hoc ou para suportar revisões
de marcos apropriadas;
• Para avaliar projetos desafiadores, para avaliar a probabilidade de cumprimento da
programação, a causa raiz do atraso do cronograma e recomendar a remediação
de problemas do projeto.

Introdução ao Design Orientado a Objetos

Os conceitos independentes da tecnologia no modelo de análise são mapeados nas
classes de implementação, as restrições são identificadas e as interfaces são projetadas,
resultando em um modelo para o domínio da solução. O objetivo principal do design OO
é desenvolver a arquitetura estrutural de um sistema. pode ser dividido em duas etapas:
design conceitual e design detalhado.

Design conceitual: todas as classes necessárias são identificadas para a construção

do sistema, responsabilidades específicas são atribuídas a cada classe. O diagrama de
classes é usado para esclarecer as relações entre as classes e o diagrama de interação
é usado para mostrar o fluxo de eventos. Ou seja, trata-se de um design de alto nível.

15
15
UNIDADE
Conceitos de Orientação a Objetos

Design detalhado: atributos e operações são atribuídos a cada classe com base em
seu diagrama de interação. O diagrama de máquina de estado é desenvolvido para des-
crever os detalhes adicionais do projeto. Nesse caso, tratamos do design de baixo nível .

O DOO segue vários principios, por exemplo, dissociação, garantia de coesão e

aberto/fechado.

Design Principles

Decoupling Ensuring Cohesion Open-closed

Figura 3 – Princípios de DOO

Princípio da dissociação: difícil manter um sistema com um conjunto de classes

altamente interdependentes, uma vez que a modificação em uma classe pode resultar em
atualizações em cascata de outras classes.

Garantia de coesão: uma classe coesa executa um conjunto de funções estreitamente

relacionadas. A falta de coesão significa, por outro lado, uma classe desempenhando
funções não relacionadas, embora isso não afete o funcionamento de todo o sistema.

Princípio aberto fechado: conforme esse princípio, um sistema deve poder se

estender para atender aos novos requisitos.

Introdução à Arquitetura Orientada a Objetos

É um paradigma de design baseado na divisão de responsabilidades de uma aplicação
ou sistema em objetos individuais reutilizáveis e autossuficientes. A abordagem popular
do design orientado a objetos é ver um sistema de software como uma coleção de
entidades conhecidas como objetos.

Vantagens:
• Mapeamento da aplicação com objetos do mundo real para maior compreensibilidade;
• Facilitar a manutenção e consequentemente a percepção de qualidade do sistema
se valendo de técnicas de reuso do programa;

16
 • Polimorfismo e abstração são utilizadas garantindo o próprio reuso;
• Características de robustez da aplicação garantem gerenciamento enquanto se roda
a própria aplicação;
• Funcionalidades podem ser melhoradas sem gerar impacto no próprio sistema;
• Isso melhora a resistência ao encapsulamento;
• AOO acelera o desenvolvimento e consequentemente reduzirão o tempo e o custo
para fazer.

Desvantagens:
• AOO – por outro lado, requer muita atenção e conhecimento de negócios para
determinar todas as classes e objetos necessários para um sistema realizar seu
propósito;
• Tempo e orçamento – quando utilizam métodos tradicionais para projetos com
AOO, geram problemas de entrega devido à necessidade principalmente de
entendimento e domínio da técnica e isso pede uma nova forma de gerenciar os
próprios projetos;
• Reuso em larga escala – pedem por codificação de procedimentos bem explícitos.

A arquitetura orientada a objetos vê um sistema como uma série de objetos

cooperantes, em vez de um conjunto de rotinas ou instruções processuais. É uma
metodologia significativa para o desenvolvimento de qualquer software.

Para poder facilitar a vida do analista na descoberta de objetos e classes, normalmente

utilizamos um formulário facilmente encontrado na internet chamado CRC, que nada
mais é do que um cartão índice, que determina as classes e quais as interações referentes.

Esse cartão pode ser desenhado por você mesmo e detém minimamente as se-
guintes colunas:
• O nome da classe;
• Suas classes super e sub;
• As responsabilidades da classe;
• O colaborador, que são nomes de outras classes com as quais a classe irá colaborar
para cumprir suas responsabilidades;
• Autor.

Vejamos a sequência de exemplos para entendermos a real utilidade deste artefato

que ajuda na construção do próprio diagrama de classes UML:

17
17
UNIDADE
Conceitos de Orientação a Objetos

Tabela 2 – Exemplo de template de CRC

Class Name:
Superclasses:
Subclasses:
Responsabilities: Collaborators

Esses cartões são facilmente utilizáveis porque você pode levar para onde quiser. Veja
os exemplos abaixo:

Tabela 3 – CRC demonstrando a classe, suas responsabilidades e que colabora

para sua função. Módulo de leitura de cartão em um ATM (quiosque bancário)
Class CardReader
Responsibilities Collaborators
Tell ATM when card is inserted ATM
Read information from card
Eject card Card
Retain card

Tabela 4 – Classe modelada a partir do entendimento do CRC para o Módulo de

leitura de cartão em um ATM (quiosque bancário) já com os métodos declarados
Class CardReader
- atm: ATM
+ CardReader(atm: ATM)
+ readCard(): Card
+ ejectCard()
+reatinCard()

Dessa forma, por exemplo, o que se espera do método:

• ejectCard(): após o usuário encerrar a operação, ejetar o cartão de dentro do leitor;
• readCard (): ler os dados da tarja magnética ou chip do cartão e validar para garantir
o acesso do cliente;

18
 • retainCard (): reter o cartão para cesta de custódia para alguma ação do banco
avisando o usuário.

Por fim, um outro exemplo muito bom, referente a um exercício com um sistema
de bibliotecas:

Tabela 5 – Exemplo didático do uso de CRC focada na descoberta de objetos,

classes e comportmentos para um sistema didático de bibliotecas
Class: Book Class: Librarian
Responsabilities Collaborators Responsabilities Collaborators
knows whether on loan check in book Book
knows due date check out book Book Borrower
knows its title search for book Book
knows its author(s) knows all books
knows its registration code search for borrower Borrower
knows if late Date knows all borrowers
check out

Class: Borrower Class: Date

Responsabilities Collaborators Responsabilities Collaborators
knows its name knows current date
keeps track borrowed items can compare two dates
keeps track of overdue fines can compute new dates

Funções declaradas:
• Livro: título, autor, código de cadastro;
• Bibliotecário: o ator ou papel que gerencia os livros;
• Mutuário: o ator ou papel de quem tomou os livros, isso inclui o seu contato;
• Data: registra o dia do empréstimo e devolução.

Você pode treinar a confecção de cartões de CRC utilizando este software online:
https://goo.gl/9scNVG

19
19
UNIDADE
Conceitos de Orientação a Objetos

Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Sites
Be Code. O que é Programação Orientada a Objetos e por que você precisa saber?
https://goo.gl/bsnezm
ALVES G. F. de O. Programação Orientada a Objetos: por que aprender isso?
https://goo.gl/bqMZ5R
SCRAM - Schedule Compliance Risk Assessment Methodology
https://goo.gl/NnSDEH

20
Referências
BOOCH, G. Object Oriented Analysis and Design with Applications, 1994, 2.ed.
Pearsons Group, EUA.

ELLIENS, A. Software engineering perspectives, 2015, disponível em < http://www.

cs.vu.nl/~eliens/oop/3.html acessado em 10/03/2018 > acessado em 10/03/2018.

WEAVER P. The Schedule Compliance Risk Assessment Methodology (SCRAM),

2013, disponível em:< https://mosaicprojects.wordpress.com/2013/08/10/the-
schedule-compliance-risk-assessment-methodology-scram/ >acessado em 09/03/2018.

YAISER, M. Object-Oriented Programming Concepts: Inheritance, 2012,

disponível em < https://www.adobe.com/devnet/actionscript/learning/oop-concepts/
inheritance.html > acessado em 08/03/2018.

21
21