OOPratica

OO na Prática
TODOS OS DIREITOS SÃO RESERVADOS POR INFNET EDUCAÇÃO LTDA.
Orientação a Objetos na
Prática
Fabio Vinicius Binder
fabio.binder@infnet.edu.br
INSTITUTO INFNET - 1
OO na Prática
Orientação a Objetos na Prática

Você aprenderá:
Modelagem de Sistemas
Orientação a Objetos
Diagrama de Classes
Estudo de Caso
OO na Prática
OO na Prática
O que é um Modelo?
Construímos modelos para:

Visualizar o sistema como ele é ou como
desejamos que ele seja;
Dominar a complexidade e entender o
sistema;
Delimitar o escopo de um problema;
Comunicação entre equipe;
Ajudar a planejar as soluções;
Guiar o desenvolvimento do sistema.
“Modelos são construídos para que se possa entender e visualizar um sistema - para
dominar a sua complexidade”
Através dos modelos pode-se delimitar claramente o escopo de um problema e planejar a
solução. O modelo ajuda no entendimento do sistema. Para projetar é preciso conhecer muito
bem o que se pretende com o sistema.
Os modelos servem também para a comunicação. A equipe de desenvolvimento irá se
comunicar através dos modelos.
OO na Prática
Analista de Analista de Arquiteto

Requisitos Sistemas
Reservar Carro
Proposta
Técnica
Estimativa
FPA Modelos Cliente
Retirar Carro
Documento
de Visão
Devolver Carro
Carro
Placa
Modelo Aluguel
Chassi
DataAluguel Fronteira : Carro : Cliente' : Aluguel
Condicao : Cliente
DataEntrega
Estado Sistema de
Agencia Aluguel
Solicitação de Carro
Endereco Reservar() BuscaCarro( ) Tela Manutenção
Telefone AlterarEstado() de Carro
Gerente
Cliente' Tela Cadastro
Empregado Informa Reserva (data,carro)
de Cliente
Nome Nome
Calcula Aluguel( )
Endereco Endereco
Telefone Telefone Tela Controle
DataAdmissao DataNascimento Identificação Pessoal Pagamento
VerificaHistorico( )
DataDemissao NumLicenca VerificaHistorico( )
Tela Cadastro de
Reservar() Reserva
CadastraReserva( ) Tela Devolução
Retirar()
Carro
Pagar()
Vendedor Mecanico
TaxaComissao Qualificacoes
A figura acima mostra os três principais envolvidos no processo de modelagem de sistemas:
analista de requisitos, analista de sistemas e arquiteto de software. Eles geram e utilizam diversos
documentos, modelos e diagramas que servem de base para a construção do sistema.
O analista de requisitos comunica-se com os usuários para descobrir quais são os requisitos
do sistema. Verifica se os requisitos estão completos e bem definidos e resolve os problemas desta
natureza. Documenta os requisitos para que sejam utilizados pelos outros membros da equipe.
O analista de sistemas elabora, a partir dos requisitos funcionais, a solução do sistema,
desenvolvendo os diagramas necessários.
O arquiteto de software trata dos requisitos funcionais e não funcionais, identificando
questões de desempenho, persistência, segurança, confiabilidade, escalabilidade, entre outros.
OO na Prática
Modelagem OO
Foco do desenvolvimento nas entidades que

participam dos processos.
Entidades do mundo real:
Pessoas - Funcionário, Vendedor, Aluno.
Lugares - Sala, Estoque, Estante, Prateleira.
Fatos - Matrícula, Pedido, Apólice de Seguro.
Coisas - Livro, Caminhão, Computador.
A visão tradicional de desenvolvimento de sistemas adota a abordagem por processos:
fluxos de trabalho são o elemento principal deste tipo de modelagem.
A modelagem orientada a objetos se preocupa com a interação das entidades do mundo
real, procura representá-lo como é percebido - pessoas, lugares, fatos e coisas existentes que se
comportam como objetos, possuindo características próprias de apresentação e funcionamento.
Entidades representáveis em um modelo orientado a objetos podem ser pessoas, lugares,
fatos ou coisas. Tudo o que for relevante para o sistema deve ser identificado e modelado.
OO na Prática
Modelagem OO
A figura acima mostra que podemos representar “abstrações” de elementos do mundo real
no ambiente orientado a objetos. Ou seja, são representadas apenas as partes relevantes para o
problema. Essas representações têm relacionamentos entre si, da mesma forma que no mundo
real. O modelo acima identifica apenas nomes e relacionamentos mas não se preocupa com
detalhes como cor, tamanho, tipo.
O foco do estudo e levantamento não é mais o processo, como por exemplo dirigir ou
morar. O cerne do estudo é na entidade que participa do processo, quais as informações
relevantes do Motorista (nome, CPF), do Veículo (placa, cor, marca, ano) e quais as ações
(métodos) que serão executadas (dirigir, morar).
OO na Prática
Modelagem OO
Benefícios Técnicos:
Reusabilidade;
Extensibilidade e manutenção;
Aumento da qualidade;
Benefícios Econômicos:
Apoio ao planejamento;
Reaproveitamento de esforços.
Os benefícios técnicos da modelagem orientada a objetos incluem:
Reusabilidade: A orientação a objetos permite a reutilização de código produzido através
de mecanismos como herança, polimorfismo, encapsulamento, modularização e coesão (esses
termos serão cobertos adiante).
Extensibilidade e Manutenção: As partes do sistema (classes) possuem tanto dados como
funcionalidades. Em um projeto bem desenhado, se for necessário acrescentar novos recursos
ao sistema, basta introduzir as modificações necessárias em partes bem específicas .
Aumento da Qualidade: Sistemas de qualidade são os que foram desenvolvidos no prazo e
no orçamento previstos e que atendem às necessidades dos usuários. A melhoria da qualidade é
possível pela maior participação do usuário na elaboração do sistema.
Além dos benefícios técnicos é possível compreender que existem benefícios econômicos,
principalmente pelo fato de conseguirmos planejar melhor o desenvolvimento e reaproveitar
esforços.
Orientação a Objetos
OO na Prática
OO na Prática
Analogia - Mundo Real
O entendimento de orientação a objetos

é fundamental para o desenvolvimento
de software.
Para iniciar o estudo de OO será usada
uma analogia com o mundo real:
Imagine que você recebeu como herança,
um grande terreno.
Esse terreno é identificado por um número.
A orientação ao objeto visa representar o mundo real no computador. Essa representação é
dependente de conceitos que serão apresentados nessa seção.
Para facilitar o entendimento, vamos partir de uma situação que pode ocorrer com várias
pessoas:
“Imagine que você recebeu como herança, de um parente distante, um grande terreno em
um condomínio fechado. Na frente do terreno passa uma rua e esse terreno é identificado por
um número. Existe alguma casa no terreno? Não, suponha que ele esteja vazio.”
OO na Prática
Você contrata um arquiteto a fim de

projetar uma casa.
O arquiteto faz várias perguntas sobre a
casa, a sua forma, estilo e
funcionalidade.
O arquiteto trabalha algum tempo no
projeto da casa e entrega as plantas
para que você possa construir.
“Após se refazer da surpresa e depois de pensar bastante, você contrata um arquiteto a fim
de projetar uma bela casa, que ocupará o terreno que você ganhou.”
“O arquiteto faz várias perguntas sobre como você deseja a casa, a sua forma, estilo e
funcionalidade.”
“O arquiteto trabalha algum tempo no projeto da casa. Findo esse tempo, ele entrega as
plantas da casa para que você possa construí-la. Existe alguma casa no terreno? Não, ele
continua vazio.”
OO na Prática
Você contrata uma construtora para

erguer a casa.
A construtora leva algum tempo e
termina o serviço.
Existe alguma casa no terreno? Sim, a
casa ocupa espaço no terreno.
“Depois de consultar algumas empresas, você contrata uma construtora para erguer a sua
casa. A construtora leva algum tempo e termina o serviço. Existe alguma casa no terreno? Sim,
a casa ocupa espaço no terreno.”
Essa estória é muito importante. Nela aparecem vários conceitos de orientação a objetos,
conforme veremos a seguir.
OO na Prática
Terreno = Memória
A memória é dividida em partes

referenciadas por endereços.
Existem partes da memória que estão
ocupadas e outras livres.
Dentro de um programa, podemos alocar
espaço na memória e construir objetos.
Esses objetos são acessados através de um
endereço de memória ou de uma referência
ao endereço.
Tudo que precisa ser processado no computador passa primeiro pela
memória.
A memória do computador é como um loteamento, com endereços
preenchidos e “lotes” vazios, esperando para serem preenchidos.
Todas as coisas que ocupam lugar na memória do computador são
referenciadas por endereços.
Objetos são conjuntos de bytes construídos dentro de um programa,
portanto ocupam lugar na memória.
Cada objeto existe em seu próprio espaço de memória e é referenciado
pelo seu endereço.
OO na Prática
Plantas da Casa = Classe
Conceito de Classe:
As plantas da casa representam a classe.
É a definição da forma e funcionalidade.
A partir da classe se constrói um objeto na memória.
Responsabilidade da Classe:
É o que a classe “sabe” e o que ela “faz”.
O que ela “sabe” são as suas propriedades ou atributos.
O que a classe “faz” são os seus métodos ou funções.
O conceito de classe na história é muito claro. As plantas da casa, desenhadas pelo
arquiteto, representam a idéia de classe. É a partir das plantas que se constrói a casa. É a partir
da classe que se constrói um objeto na memória.
A classe é o gabarito, a definição da forma e da funcionalidade. A forma é representada
pelas propriedades e a funcionalidade pelos métodos.
Quando uma classe é modelada, existe a preocupação de documentar as suas
responsabilidades: o que a classe “sabe” (propriedades ou atributos) e o que a classe “faz”
(métodos ou funções).
As casas criadas têm propriedades parecidas (quantidade de cômodos, andares) mas cada
uma tem características próprias, o endereço, por exemplo será diferente para cada uma. A
fachada de uma é azul e outra colocou pastilhas verdes. As características em comum são da
estrutura, fazendo a analogia com sistemas, a classe forma objetos com a mesma estrutura, mas
cada objeto terá valores próprias para suas características.
OO na Prática
Casa = Objeto
Um objeto pode ser alocado na

memória a partir da definição de uma
classe.
Um objeto não interfere em outro, cada
um tem seu próprio espaço.
Instância é sinônimo de objeto.
Instanciar significa criar um objeto a
partir de uma classe.
Uma casa criada a partir das plantas é um objeto, terá endereço, fachada e acabamento
próprios.
Quando um espaço na memória é alocado e o construtor de uma classe é usado, um objeto
é criado. Se existirem dois ou mais objetos criados na memória, eles serão independentes. É
possível alterar as propriedades de um objeto sem interferir nas propriedades do outro.
É possível encontrar textos que utilizam o termo instância como sinônimo de objeto e o
verbo instanciar que significa criar um objeto a partir de uma classe.
OO na Prática
Representação Gráfica
Notação UML
Notação Alternativa: Sacar()
saldo
Funções
Propriedades Depositar()
Notação UML:
A figura da esquerda representa uma classe, enquanto a figura da direita mostra a
representação de um objeto. Note que o objeto traz o nome da classe ao qual ele pertence.
O nome do objeto, como visto no exemplo (conta1: ContaCorrente), segue o padrão -
NomedoObjeto:NomedaClasse, mas poderia aparecer sozinho NomedoObjeto ou apenas
:nomedaClasse - note os dois pontos antes do nome da classe.
Notação Alternativa:
Com esta representação visualizamos bem a proteção que os métodos fazem na classe, a
idéia é que as informações somente sejam acessadas (criados, excluídos, alterados) através dos
métodos da própria classe. Com isso temos dependência do código e sabemos que ao dar
manutenção em algum processo da classe cliente somente iremos alterar os métodos desta
classe, não precisaremos vasculhar o sistema em busca de alterações.
OO na Prática
Propriedades
As propriedades são os dados que

guardam as características e o estado
dos objetos criados a partir da classe.
É o que a classe “sabe”.
Exemplos:
O relógio digital tem as propriedades
“hora” e “minuto”.
Uma agenda tem a propriedade “lista de
contatos”
As propriedades ou atributos são os dados que guardam as características e o estado dos
objetos criados a partir da classe. É o que a classe “sabe”.
A casa da estória, como qualquer outra casa, tem uma aparência externa. A casa pode estar
pintada de azul, amarelo, verde, etc. A classe pode ter uma propriedade que se refere a sua
aparência externa, já que cada objeto tem uma informação diferente.
Um outro exemplo é de um relógio digital. Os circuitos internos do relógio calculam o
tempo ciclicamente e o exibe em um mostrador.
Podemos dizer que o relógio tem as propriedades “hora” e “minuto” atualizadas
ciclicamente.
OO na Prática
Métodos
O termo método representa as

funcionalidades inerentes à classe.
É o que a classe “faz”.
Para alterar o mostrador do relógio
digital não podemos simplesmente
exibir um número qualquer.
Existe um “método” para fazer isso.
O termo método representa as funcionalidades inerentes à classe. Esse termo é usado
porque essas funcionalidades estão, na maioria das vezes, ligadas às propriedades da classe. É o
que a classe “faz”.
No exemplo do relógio, os números do mostrador têm uma lógica. Para alterar o mostrador
não podemos simplesmente exibir um número qualquer. Existe um “método” para fazer isso.
No caso da cor da casa também. Se nós desejamos representar uma alteração na cor da
casa, devemos utilizar um método que “pinte” a casa e altere a sua cor.
OO na Prática
Herança
Relacionamento de generalização e
especialização entre classes.
Permite ao programador criar uma nova
classe “estendendo” uma classe
anterior.
A herança define uma hierarquia onde o
conceito mais genérico fica sobre o
conceito mais específico.
A herança constitui o mecanismo pelo qual se pode compartilhar automaticamente métodos
e dados entre classes diferentes, que tenham um relacionamento de generalização e
especialização.
A herança permite ao programador criar uma nova classe “estendendo” uma classe anterior
e implementando as propriedades e métodos específicas.
Em um banco, por exemplo, podemos ter Conta Especial como uma especialização de
Conta-Corrente. A Conta Especial tem o atributo “limite” que estende o conceito de uma conta
comum.
Um outro exemplo é o Vendedor que estende o conceito de Funcionário. Sabemos que todo
Vendedor é um Funcionário, mas nem todo Funcionário é Vendedor.
A herança define uma hierarquia onde o conceito mais genérico fica sobre o conceito mais
específico e o item mais específica “aproveita” as definições do item mais genérico.
OO na Prática
Exemplo de Herança
+calcularSalario()
A figura mostra uma herança em um sistema de folha de pagamento. Funcionários comuns
tem determinados dados como matrícula, nome, salário base, etc. Possui também métodos para
demissão e cálculo do salário.
Para acrescentar outro tipo de funcionário à empresa basta criar uma subclasse, ou seja fazer
uma classe que herde as características da classe Funcionário e adicione as suas próprias. No caso,
a classe Vendedor foi incluída no diagrama herdando as características de Funcionário e
acrescentando suas próprias: comissão de venda e total de vendas realizadas no mês.
OO na Prática
Encapsulamento
A Classe é um “pacote”, contendo dados

(propriedades) e operações (métodos);
O objeto é referenciado como um módulo único.
public class Data {
...
}
public class UsaData {
public static void main(String [] args) {
Data hoje = new Data();
...
Data ontem = new Data();
...
}
}
O Encapsulamento é um dos recursos mais importantes da Orientação a Objetos. Através
desse conceito concebemos uma Classe como um “pacote” contendo dados e operações em um
único módulo. Sempre que precisamos lidar com um objeto, o referenciamos como um módulo
único.
O Encapsulamento é um conceito que significa “proteger” dados internos da classe,
tornando-os disponíveis apenas através de métodos.
Esse recurso é importante se desejarmos garantir que os dados internos da classe só serão
alterados sob determinadas condições. Uma Conta-Corrente, por exemplo, só deve alterar o seu
saldo dentro de limites pré-estabelecidos pelo banco.
O Ocultamento de dados é implementado através da “Visibilidade” mais restrita -
“protegida” ou “privada”.
OO na Prática
Polimorfismo
Vários comportamentos que uma

mesma operação pode assumir.
Polimorfismo (muitas formas) é a
capacidade de um programa orientado
a objetos distinguir, dentre métodos
homônimos, qual deverá ser executado.
Polimorfismo é a capacidade de um programa orientado a objetos de distinguir, dentre
métodos homônimos, qual deverá ser executado. Isso só é conseguido através da instância da
qual tentamos executar o método.
Existem dois tipos de métodos polimórficos: sobrecarregados e sobrescritos.
OO na Prática
Polimorfismo
CD player
Filmadora Eletrocardiograma
play stop
> ||
pause
MP3 player
Câmera de segurança
Videocassete
É possível identificar com clareza o polimorfismo através de uma analogia com o mundo
real: a operação de gravação: a filmadora, o cd player o eletrocardiograma, a câmera de
segurança, o videocassete e o mp3 player tem o comando gravar. Entretanto, todos sabem que
dependendo do objeto o método de gravação será diferente.
Diagrama de Classes
OO na Prática
OO na Prática
Conceitos
Objetos representam entidades discretas,

que encapsulam estado e comportamento e
são definidos por classes.
O estado é representado pelos atributos do
objeto, o comportamento pelas operações.
Na UML, a classe é representada por um
retângulo dividido em três compartimentos
representando o nome da classe, os atributos
e as operações:
Nas metodologias de modelagem orientadas a objetos, os objetos representam entidades discretas,
com fronteira bem definida e identidade própria, que encapsulam estado e comportamento.
O estado é representado pelos atributos do objeto, e o comportamento pelas respectivas operações.
Os objetos interagem entre si trocando mensagens, que são invocações das operações.
Na UML, a classe é representada por um retângulo dividido em três compartimentos, que contêm
respectivamente: o nome da classe, os atributos e as operações.
Para maior clareza nos diagramas, pode-se suprimir cada um dos compartimentos de atributos e
operações, ou deixar de mostrar determinados atributos ou operações.
São opcionais também: a indicação da visibilidade por caracteres ou ícones; a assinatura (lista de
argumentos e tipo de retorno) das operações; e o tipo e valor padrão dos atributos.
OO na Prática
Exemplos
O exemplo acima mostra três classes do Banco Money: ContaCorrente (Model), TelaMenu (View)
e Principa (Controller). Maiores informações sobre o padrão Model-View-Controller podem ser
encontradas no Apêndice A.
Na fase de análise as classes de negócio são identificadas. Classe de negócio é aquela que trata das
funcionalidades principais do sistema. A classe ContaCorrente é uma classe de negócio pois ela
define os dados e as operações referentes a uma conta corrente.
Em um sistema de agenda eletrônica o objetivo principal é manter os contatos (incluir, buscar,
listar, etc). As classes de negócio identificadas são as seguintes:
OO na Prática
Visibilidade
Os tipos de acesso possíveis aos membros

de uma classe (atributos, métodos) são:
Público (+) : a propriedade ou método da classe
pode ser acessado por todas as demais entidades
do sistema;
Protegido (#) : o acesso aos membros da classe
só é permitido a classes da mesma hierarquia;
Privado (-) : o acesso aos membros da classe só
é permitido aos métodos da própria classe.
Uma classe pode definir o tipo de acesso que seus membros (propriedades e métodos) permitirão
às demais partes do sistema.
Em uma escala progressiva de “privacidade” dos membros, os tipos de acesso possíveis são
público, protegido e privado.
Os tipos de acesso a operações ou atributos de cada classe incluem:
Público:
Qualquer outra classe pode usar;
Símbolo “+”;
Protegido:
Só subclasses dessa classe podem usar;
Símbolo “#”;
Privado:
Nenhuma outra classe pode usar diretamente
Símbolo “-”;
As implementações de visibilidade das linguagens modernas oferecem outros tipos de visibilidade
como pacote (Java) e internal (.NET).
OO na Prática
Visibilidade
Atributos
privativos
Métodos
públicos
A figura mostra a classe ContaCorrente com as suas propriedades e métodos. Do lado esquerdo
destas propriedades e métodos existem os sinais que indicam a visibilidade do elemento.
Todos os atributos estão definidos como private e todos os métodos como públicos. Esta é uma boa
prática pois protege atributos de acessos externos. Entretanto esta regra não é rígida, já que é
bastante comum encontrar métodos privativos (métodos que executam tarefas específicas para a
classe) e atributos constantes públicos (constantes não mudam de valor portanto se forem definidas
como públicas não possuem problemas de alteração fora da classe).
Para alterar atributos privativos são criados métodos “set”. Estes métodos simplesmente atualizam
o atributo com o valor passado como parâmetro. Para recuperar atributos privativos (para serem
mostrados em uma tela por exemplo) são criados métodos “get” que retornam o atributo desejado.
As ferramentas de desenvolvimento normalmente geram estes métodos de maneira automárica.
A grande vantagem desta abordagem é a criação de pontos únicos de acesso aos dados. Qualquer
classe que precise alterar ou recuperar o atributo de outra deve utilizar os métodos. Assim sempre
que for necessária fazer uma alteração no código de alteração ou recuperação, ela será feita em
apenas um local.
OO na Prática
Como Identificar Classes?
As classes de um sistema podem ser

identificadas a partir de um diagrama de casos
de uso e suas descrições.
Liste todas as entidades (tipos complexos)
que forem encontradas nas descrições.
Verifique se entre estas entidades não existe
alguma relação, como por exemplo:
Elas são sinônimos?
Uma contém a outra?
Ambas tem muitos métodos e atributos em
comum?
Uma das maiores dificuldades para quem está começando a trabalhar com orientação a objetos é como identificar as
classes. A experiência ajuda bastanta mas para quem não a tem existem algumas técnicas que ajudam encontrar as
classes de um sistema.
Uma das maneiras mais simples é identificar as entidades ou tipos complexos encontrados nas descrições dos casos de
uso. Em seguida, verifique se cada tipo pode ser uma classe de negócio respondendo a algumas perguntas:
• A entidade tem algum sinônimo ou entidade similar na lista?
• Uma entidade contém outra da lista. Se contém, é necessário deixá-las separadas?
• A entidade contém muitos atributos ou métodos em comum com outra?
• A entidade é realmente complexo e precisa ser tratada de maneira separada?
• A entidade é manipulada pelo sistema?
Como exemplo, considere a descrição do caso de uso “Efetuar Depósito” do capítulo anterior. A lista das entidades
seria:
Pessoa, Depósito, Agência, Conta, Gaveta, Comprovante.
Pessoa não é classe pois o sistema não vai manter informações sobre ela.
Depósito não é classe, é um metodo (depositar) da classe Conta.
Agência não é classe pois não faz parte do escopo do sistema a manipulação de agências separadas.
Gaveta não é classe pois é apenas um dispositivo controlado pelo nosso sistema.
Comprovante pode ser uma classe desde que seja necessário guardar informações sobre cada operação que
aconteceu.
Conclusão: A identificação de classes depende do contexto e dos requisitos funcionais. Além disso, existem várias
soluções possíveis para um mesmo problema.
OO na Prática
Relacionamentos
Os possíveis relacionamentos entre

classes são os seguintes:
Associação
Navegabilidade
Dependência
Agregação
Composição
Generalização
Relacionamentos entre classes indicam de que forma as classes devem ser ligadas para cumprir os
objetivos. Existem relacionamentos que levam em conta apenas a estrutura das classes
(generalização) e outros que são determinados a partir da quantidade de objetos da ligação
(associação, agregação, etc.).
Os tipos de relacionamentos da figura acima tem os seguintes significados:
Associação: indica que duas classes tem um relacionamento forte e duradouro. Normalmente uma
possui um atributo de referência para a outra.
Navegabilidade (Associação Direta): apenas uma das classes “conhece” a outra.
Dependência: a execução de uma das classes depende da existência da outra.
Agregação: uma classe representando um todo contém classes que representam partes.
Composição: idem a anterior mas as partes não existem sem o todo.
Generalização (Herança): uma classe (subclasse) herda atributros e métodos de outra classe
(superclasse).
OO na Prática
Associação
A associação é o relacionamento entre

classes, representada por um traço simples.
As associações podem expressar relações
bidirecionais entre classes.
Faz parte das responsabilidades de um
objeto de uma das classes determinar os
objetos correspondentes da outra classe.
Normalmente uma associação é
implementada com atributos. Assim, se um
pedido está relacionado a um cliente, este
relacionamento pode ser implementado
colocando-se um atributo do tipo cliente
dentro da classe pedido.
As associações indicam a possibilidade de comunicação direta entre os respectivos objetos. Isso
significa que faz parte das responsabilidades de um objeto de uma das classes determinar os
objetos correspondentes da outra classe. É comum existir em cada classe operações para cumprir
essa responsabilidade.
Normalmente uma associação é implementada com atributos. Assim, se um pedido está
relacionado a um cliente, este relacionamento pode ser implementado colocando-se um atributo do
tipo cliente dentro da classe pedido e uma lista de pedidos em cada cliente. Desta forma é possível
identificar pelo pedido qual é o cliente que o efetuou e pelo cliente, quais são os pedidos
realizados.
OO na Prática
Exemplos
Empresa e Produto
possuem atributos para
indicar o relacionamento
Aluno e Curso
também!
A figura mostra que existe algum tipo de colaboração entre a classe Empresa e a classe Produto.
Podemos entender isso quando perguntamos a uma determinada empresa que produtos ela fornece.
Da mesma forma podemos perguntar a um determinado produto que empresas podem fornecê-lo.
Também pode ser visto que existe algum tipo de relacionamento entre aluno e curso: um aluno se
matricula em vários cursos e um curso pode ter vários alunos.
Mesmo sabendo que existem atributos para representar estes relacionamentos, eles não devem ser
escritos nas classes de negócio. O objetivo das classes nesta fase é iniciar a elaboração de uma
solução, portanto o entendimento do relacionamento entre as classes é mais importante do que a
exata maneira como serão implementadas.
Quando for necessário criar classes de projeto estes atributos poderão aparecer para tornar mais
claro qual o nome e tipo do atributo. Por exemplo, um relacionamento de um para muitos pode ser
implementado como um vetor, lista encadeada, tabela hash, etc.
OO na Prática
Multiplicidade e Papéis
A especificação das associações inclui o seu

nome, descrição e possíveis restrições.
Em certos casos, é útil batizar também os
papéis, assim como especificar vários
detalhes destes.
Os nomes das associações devem ser
simples e significativos.
Uma convenção habitual é batizar o
relacionamento de modo que ele seja lido
corretamente de cima para baixo ou da
esquerda para a direita.
A especificação das associações inclui o seu nome, descrição e possíveis restrições.
Em certos casos, é útil batizar também os papéis, assim como especificar vários detalhes destes.
Os nomes das associações devem ser simples e significativos. Recomenda-se usar um substantivo
que descreva bem a semântica do relacionamento. Pode-se também usar um verbo, desde que
esteja claro qual classe é sujeito e qual classe é objeto desse verbo.
Uma convenção habitual é batizar o relacionamento de modo que ele seja lido corretamente de
cima para baixo ou da esquerda para a direita.
De acordo com a UML, um pequeno triângulo pode ser usado para indicar a direção de leitura,
caso necessário.
OO na Prática
Exemplo de Multiplicidade
Essa
Multiplicidade
se refere a
Mercadoria na
associação
com Empresa
No exemplo foi modelado o fato de que uma “Pessoa” poder estar ligada a nenhuma ou uma
“Empresa”, ou seja, podemos cadastrar um desempregado. Enquanto uma “Empresa” poder estar
relacionada com, no mínimo uma instância de “Pessoa”.
Uma “Empresa” pode estar relacionada com zero ou mais instâncias de “Mercadoria” (por
exemplo, fornecer) e uma mercadoria pode ser fornecida por nenhuma (mercadoria obsoleta) ou
muitas empresas.
Um álbum possui de nenhuma a muitas figurinhas:
Durante um campeonato, um time pode possuir muitos jogadores e um jogador pode ser de vários
times (devido a transferências por exemplo):
OO na Prática
Papéis
Os papéis são denominações que exprimem

em que qualidade um objeto de uma das
classes do se relaciona com um objeto da
outra classe.
Os papéis são denominações que exprimem em que qualidade um objeto de uma das classes do
relacionamento se relaciona com um objeto da outra classe.
Os papéis dos participantes devem ser batizados explicitamente quando participarem de um
relacionamento em uma qualidade que não é implícita no respectivo nome da classe.
Cuidado para não poluir o diagrama !
Na figura acima, um objeto da classe "Empresa“ participa no papel de "fornecedor“ do
relacionamento "Fornece", com zero ou mais objetos da classe "Mercadoria", e um objeto dessa
classe se relaciona com zero ou mais objetos da classe "Empresa" na qualidade de "produto".
Uma "Empresa" pode participar de outros relacionamentos em outras qualidades; por exemplo, no
papel de "empregador", em um relacionamento "Emprega" com um objeto da classe "Pessoa".
OO na Prática
Dependência
Relacionamento de dependência é uma

relação fraca, indicando que uma classe usa
outra mas não possui nenhum atributo
permanente dela.
É representada por um traço pontilhado e
direcionado.
Como identificar dependências?
Quando uma classe tem uma operação que usa
uma instância de outra classe como parâmetro;
Uma classe chama uma operação que é de
escopo de outra classe.
Uma operação retorna um objeto de outra classe
A associação vista anteriormente é um relacionamento forte pois implica na existência de um
atributo de ligação entre as classes.
Existem situações nas quais esta ligação é temporária e portanto a associação não é a melhor forma
de explicitar o relacionamento.
Por exemplo, se uma classe apenas chama métodos de outra, recebe um objeto de outra classe
como parâmetro ou se cria objetos de outra dentro de um método (escopo local) então o
relacionamento é uma dependência.
A dependência indica que uma classe depende de outra ou que ela “usa” outra classe. Ou seja, a
existência de uma classe depende da existência da outra.
OO na Prática
Exemplos de Dependência
A classe Círculo possui métodos que usam a

constante PI de Math:
TelaMenu possui o método “executar” que
recebe uma conta como parâmetro:
No primeiro exemplo acima, a classe Círculo possui dois métodos (calcularArea e
calcularPerimetro) que utilizam localmente a classe Math para recuperar o valor da constante PI.
O uso da classe Math é temporário (escopo local), apenas dentro dos referidos métodos, portanto o
relacionamento é de dependência.
No segundo exemplo, a classe TelaMenu deve mostrar o nome do titular em cima do menu.
Portanto, precisa da informação da conta corrente atual. Este objetivo é alcançado passando-se a
conta atual como parâmetro para o método executar, responsável pela exibição do menu. Este
método recupera o nome do titular, exibe-o e retorna. Mais uma vez o relacionamento foi
temporário e deve ser representado como uma dependência.
Abaixo um outro exemplo, no qual uma tela que mostra todas as vendas de um determinado mês
precisa mostrar para cada venda a data que ela foi efetuada. A data deve ser formatada com o
método formatar da classe FormatadorDeData. Este método é chamado dentro do método
exibirVendas, portanto o relacionamento é de dependência.
OO na Prática
Herança
O relacionamento de herança existe

entre classes de natureza mais geral
(chamadas de superclasses ou classes
bases) e suas especializações
(chamadas de subclasses ou classes
derivadas).
As superclasses contêm atributos ou
operações comuns a um grupo de
subclasses.
A herança existe na OO para facilitar a programação e a manutenção dos programas, pois a
codificação dos métodos e definição dos atributos (tipo/tamanho) estará em um único lugar (na
superclasse) e será aproveitado por todas as subclasses.
O relacionamento de herança existe entre classes de natureza mais geral (chamadas de
superclasses, classes base, classes pai) e suas especializações (chamadas de subclasses, classes
derivadas, classes filha). As superclasses contêm atributos ou operações comuns a um grupo de
subclasses.
As subclasses herdam todos os atributos e métodos das superclasses. Este fato facilita o
desenvolvimento de software, principalmente a manutenção e a extensibilidade, pois mudanças são
feitas em locais bem específicos com um mínimo de impacto para o restante do sistema.
OO na Prática
Exemplos de Herança
No primeiro exemplo existem dois tipos de conta corrente: contas comuns e contas especiais. A
única diferença entre elas está no atributo limite, que indica o valor que a conta pode ficar
negativa. Portanto, uma solução bem simples e poderosa é criar a conta especial como subclasse de
conta corrente. Assim, a conta especial herda todos os atributos e métodos de sua superclasse e
especifica os seus próprios. No caso, o método sacar foi reescrito pois a operação de ambas difere
com relação ao limite.
No segundo exemplo, uma escola precisa controlar seus professores e alunos. Estas duas entidades
possuem muitas coisas em comum que são capturadas por uma superclasse denominada Pessoa.
Uma empresa que vende cds e dvds pode modelar seu sistema da forma abaixo, considerando que
cds e dvds possuem atributos em comum (título, preço, estoque, etc):
Estudo de Caso
OO na Prática
OO na Prática
MP3 Organizer
Problema: classificar arquivos MP3 e

permitir várias formas de visualização:
Por Título
Por Artista
Por Álbum
Por Lista Customizada
A herança existe na OO para facilitar a programação e a manutenção dos programas, pois a
codificação dos métodos e definição dos atributos (tipo/tamanho) estará em um único lugar (na
superclasse) e será aproveitado por todas as subclasses.
O relacionamento de herança existe entre classes de natureza mais geral (chamadas de
superclasses, classes base, classes pai) e suas especializações (chamadas de subclasses, classes
derivadas, classes filha). As superclasses contêm atributos ou operações comuns a um grupo de
subclasses.
As subclasses herdam todos os atributos e métodos das superclasses. Este fato facilita o
desenvolvimento de software, principalmente a manutenção e a extensibilidade, pois mudanças são
feitas em locais bem específicos com um mínimo de impacto para o restante do sistema.
OO na Prática
Abordagem
Identificar Classes Básicas (Negócio)

Definir Interface
Identificar Classes de Projeto
Programar
OO na Prática
Classes Básicas
Artista
Álbum
Música
Lista
OO na Prática
Diagrama de Classes Básicas
OO na Prática
Interface
Tela de Visualização:
Lista de todas as músicas com
possibilidade de mudar a classificação
Botão “Sair”
Botão para inserir música
Tela de Inserção
Campos para digitação/alteração dos dados
da música
OO na Prática
Classes de Projeto
Principal: inicia a aplicação, controla a

navegação e os objetos
TelaGeral: tela que exibe as músicas e
demais elementos da interface
TelaMusica: tela para inserção/alteração
de músicas
OO na Prática
Diagrama de Classes de Projeto
Diagrama Geral
OO na Prática

OOPratica

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

OOPratica

Enviado por

Direitos autorais:

Formatos disponíveis

OO na Prática

TODOS OS DIREITOS SÃO RESERVADOS POR INFNET EDUCAÇÃO LTDA.

Orientação a Objetos na Prática

Construímos modelos para:

Analista de Analista de Arquiteto

Foco do desenvolvimento nas entidades que

O entendimento de orientação a objetos

Você contrata um arquiteto a fim de

Você contrata uma construtora para

A memória é dividida em partes

Um objeto pode ser alocado na

As propriedades são os dados que

O termo método representa as

A Classe é um “pacote”, contendo dados

Vários comportamentos que uma

Objetos representam entidades discretas,

Os tipos de acesso possíveis aos membros

As classes de um sistema podem ser

Os possíveis relacionamentos entre

A associação é o relacionamento entre

A especificação das associações inclui o seu

Os papéis são denominações que exprimem

Relacionamento de dependência é uma

A classe Círculo possui métodos que usam a

O relacionamento de herança existe

Problema: classificar arquivos MP3 e

Identificar Classes Básicas (Negócio)

Principal: inicia a aplicação, controla a

Você também pode gostar