Material das videoaulas do Módulo 3 - Bootcamp Arquiteto de Software

Prévia do material em texto

Design Patterns, Estilos e 
Padrões Arquiteturais
CAPÍTULO 1. INTRODUÇÃO
PROF. GLADSTON JUNIO APARECIDO
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 1.1. INTRODUÇÃO À ARQUITETURA DE SOFTWARE
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceito de Arquitetura de Software.
❑ Importância da Arquitetura de Software.
Arquitetura de Software
• A definição de arquitetura de um software é muitas
vezes subjetiva.
• Metodologias de desenvolvimento em cascata a
definem como:
− Projetos iniciais que devem ser concluídos antes
que qualquer código seja escrito.
Arquitetura de Software
• Como todas as disciplinas da Engenharia de
Software, a arquitetura evolui com o surgimento de:
− Novas metodologias;
− Novas tecnologias.
Arquitetura de Software
• A ISO/IEC/IEEE 42010 define arquitetura como:
“Conceitos e propriedades fundamentais de um sistema
considerando seu ambiente, seus elementos, seus
relacionamentos e seus princípios de projeto e
evolução”.
Arquitetura de Software
• A definição da ISO/IEC/IEEE 42010 tem alguns pontos
importantes e em comum com outras definições:
− A arquitetura é a parte fundamental de software;
− Um software está situado em um ambiente e sua
arquitetura deve considerar as características desse
ambiente;
− A arquitetura deve apresentar documentos que
descrevem como o sistema atenderá aos requisitos
necessários.
− A arquitetura deve apresentar visões distintas,
focadas nos interesses dos diferentes stakeholders.
Arquitetura de Software
• "Arquitetura é sobre as coisas importantes. Seja o
que for.“ [GAMA, Erich, et. al, 1994].
• “A arquitetura de software consiste nas primeiras
decisões que são tomadas para um sistema de
software e uma das mais difíceis de mudar.”
[INGENO, 2018].
Arquitetura de Software
• Em resumo, uma arquitetura de software define as 
estruturas de um sistema, que são compostas por:
− Os elementos que compõem a estrutura;
− Suas propriedades externas;
− O relacionamento entre os elementos.
Arquitetura de Software
FONTE: KEELING, 2017.
Importância da Arquitetura
• A arquitetura é o alicerce do sistema.
• Envolve multas decisões.
− Muitas dessas decisões não são triviais;
− Mudar algumas dessas decisões após o
desenvolvimento do software pode ser
extremamente complexo.
• Permite gerenciar a complexidade do sistema.
− Reduz o gap entre especificação e
implementação.
Importância da Arquitetura
• Arquitetura tem a capacidade de maximizar os
atributos de qualidade de um software:
− Manutenibilidade;
− Interoperabilidade;
− Segurança;
− Performance.
• Impacto direto na qualidade do produto final.
Importância da Arquitetura
Modelo de Qualidade ISO/IEC 25010
Conclusão
✔ Arquitetura consiste de tudo o que é fundamental em um 
software.
✔ Envolve decisões importantes que o software atenda aos 
atributos de qualidade esperados.
✔ Representa decisões para simplificar o desenvolvimento, 
entendimento, manutenção e evolução do software.
02.
01. 03.
Próxima Aula
A importância do Arquiteto de 
Software.
As principais habilidades 
desejáveis para um Arquiteto.
Responsabilidades de um 
Arquiteto de Software.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 1.2. O ARQUITETO DE SOFTWARE 
PROF. GLADSTON JUNIO APARECIDO
Nesta aula
❑ Os papéis de um Arquiteto de Software.
❑ As habilidades necessárias para um Arquiteto.
O Arquiteto de Software
• As responsabilidades de um arquiteto são moldadas
com base no ambiente ao qual está inserido.
− Alguns times possuem um ou mais arquitetos
que exercem esse papel de forma dedicada.
− Outros não possuem o papel fixo de arquiteto.
• Nesse caso, as responsabilidades são
desempenhadas por diferentes membros
equipe.
O Arquiteto de Software
• O arquiteto de software é uma posição única:
− Ele não é o gerente do projeto, mas:
• Decide quando e como o software pode ser
entregue.
• Determina se o software atende aos
requisitos do negócio.
− Ele codifica, mas define projetos mais do que
algoritmos.
− Ele não é administrador da infraestrutura, mas
monitora e garante a operabilidade do sistema.
O Arquiteto de Software
FONTE: KEELING, 2017.
O Arquiteto de Software
• Algumas responsabilidades e características
importantes de um arquiteto são:
− Definir as soluções por uma perspectiva de
engenharia;
− Dividir o sistema e atribuir responsabilidades;
− Gerenciar riscos e débitos técnicos;
− Liderar e contribuir para o crescimento da
equipe;
− Se envolver nas questões políticas da
organização;
− Administrar questões relacionadas à gestão de
configuração e CI/CD;
− Ter uma visão holística.
O Arquiteto de Software
FONTE: KEELING, 2017.
O Arquiteto de Software
• Arquitetura é essencialmente comunicação.
− Um arquiteto deve ser capaz de discutir
inúmeros detalhes técnicos com a equipe e,
posteriormente, apresentá-los para a alta
gerência sem perder a essência da mensagem.
Conclusão
✔ O arquiteto de software tem um papel único no time e no 
ciclo de vida de um software.
✔ Ser arquiteto requer habilidades além da capacidade 
técnica.
✔ Bons arquitetos devem ter uma visão holística de processos 
e da empresa.
01.
Próxima Aula
Terminologia de Arquitetura de 
Software.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 1.3. TERMINOLOGIA DE ARQUITETURA DE SOFTWARE
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Arquitetura de referência.
❑ Arquitetura implementada.
❑ Erosão arquitetural.
❑ Arquitetura de linhas de produtos de software.
Arquitetura de Referência
• Arquitetura conceitual do sistema proposta pelos
arquitetos e representada nas visões arquiteturais e
documentos do projeto.
• Define os tipos de elementos e as interações
permitidas entre eles em um sistema ou em partes
específicas de um sistema.
• Detalha como os requisitos relacionados aos atributos
de qualidade serão respeitados.
Arquitetura Implementada
• Corresponde ao recorte da arquitetura real de um
sistema materializada em seus artefatos (código,
componentes, ambientes, etc.) em um dado
momento.
Erosão Arquitetural
• Fenômeno que ocorre quando a arquitetura
implementada se distancia da arquitetura de
referência na medida em que o software evolui.
Linhas de produtos
• Arquitetura de linhas de produtos (Software Product
Lines):
− Arquitetura aplicada a um conjunto de produtos
(sistemas) dentro de uma organização.
− Esses produtos compartilham elementos em
comum como design e parte da implementação.
− Alguns aspectos desses elementos em comum
podem ser customizados ou estendidos em cada
produto.
Conclusão
✔ A arquitetura de referência é uma representação importante 
para o ciclo de vida de um software.
✔ O arquiteto deve gerenciar os débitos técnicos para evitar a 
erosão arquitetural do sistema.
02.
01. 03.
Próxima Aula
Padrões na Arquitetura de 
Software.
Documentação de Padrões.
Importância dos Padrões.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 1.4. PADRÕES NA ARQUITETURA DE SOFTWARE
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceito de Padrões na Arquitetura de Software.
❑ Importância dos Padrões.
❑ Documentação de Padrões.
Padrões
• “Um padrão é uma entidade que descreve um
problema que ocorre repetidamente em um ambiente
e então descreve a essência da solução para este
problema, de tal forma que você use esta solução
milhões de vezes, sem nunca utilizá-la do mesmo
modo.” Christopher Alexander
• Pontos chaves:
− Soluções reutilizáveis e amplamente testadas;
− Adaptáveis;
− Para problemas específicos e recorrentes.
Padrões
• Não são exclusividade da Engenharia de Software:
− Arquitetura;
− Ciência da computação;
− Economia;
− Telecomunicações.
Padrões
• São utilizados como blueprints para solução de
problemas durante o ciclo de vida de um software.
− Um projeto de software não é materializado do
nada.
− Utiliza-se o conhecimento previamente
adquirido.
Padrões
• Existem padrõespara diversos domínios e contextos
do desenvolvimento de um sistema, como:
− Padrões arquiteturais;
− Padrões de análise de sistemas;
− Padrões de análise e armazenamento de dados;
− Padrões de integração de aplicações.
Importância dos Padrões
• O uso de soluções comprovadas contribuem para a
garantia de qualidade do sistema.
• Trazer um pouco de objetividade na avaliação da
qualidade de uma arquitetura.
• Reduzem os riscos do projeto.
Importância dos Padrões
• Melhoram a comunicação das equipes.
• Independentes de tecnologias ou linguagem de
programação.
Documentação de Padrões
• Existem diferentes propostas de documentação de
padrões.
• Em termos gerais, um padrão deve conter:
− Nome: descreve de forma suscinta o padrão;
− Problema: define quando o padrão deve ser
utilizado.
• Deve descrever o problema e o contexto ao
qual o padrão se aplica.
Documentação de Padrões
− Solução: descreve como o padrão propõe a
resolver o problema de forma genérica.
− A solução descreve:
• Os elementos que constituem a solução;
• Seus relacionamentos;
• Suas responsabilidades e colaborações.
− Não deve estar vinculada a um problema
concreto e sim apresentar uma abstração que
sirva como template para diferentes situações.
Documentação de Padrões
− Resultados e consequências: descrevem os
benefícios da adoção do padrão e suas
consequências.
• Fundamentam as decisões de utilizar ou
não o padrão.
• Podem, por exemplo, descrever impactos
na flexibilidade, extensibilidade,
portabilidade e manutenibilidade.
Documentação de Padrões
Documentação de Padrões
Conclusão
✔ Padrões representam soluções amplamente testadas para 
problemas recorrentes.
✔ Não são exclusivos da Engenharia de Software.
✔ Um padrão deve ser devidamente documentado.
✔ Contribuem para melhoria da qualidade do software e 
comunicação da equipe.
01.
Próxima Aula
Revisão do paradigma da 
Orientação a Objetos.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 1.5. PARADIGMA DE PROGRAMAÇÃO ORIENTADA A OBJETOS
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Introdução à Programação Orientada a Objetos.
❑ Principais conceitos da O.O.
❑ Desafios da Orientação a Objetos.
Orientação a Objetos (O.O.)
• A estrutura de um programa é composta por um
conjunto de classes.
• Cada classe é responsável por um aspecto do
problema a ser resolvido.
• A execução do problema se dá através da interação
entre objetos:
− “Simulação viva do problema”.
Classes
• São templates que definem a representação de um
domínio do problema:
− Determina o estado ou dados (atributos);
− Determina a estrutura das operações ou
responsabilidades (métodos).
Classes
Objetos
• Um objeto representa uma instância de uma classe.
− Todo objeto deve ter uma identidade única no
sistema.
− Chamadas aos métodos de um objeto podem
resultar em mudanças seu estado.
− O consumo de um método de outro objeto é
chamado de mensagem.
Escopo
• Existem basicamente três escopos para
armazenamento de dados na OO:
− Variáveis locais;
− Atributos de instâncias;
− Atributos de classes.
• Atributos e métodos possuem modificadores de
acesso que determinam quem pode acessá-los (ex.:
público, privado e protegido).
Coesão e Acoplamento
• Coesão é sinônimo de responsabilidade única.
− Uma classe deve se preocupar em cumprir sua
responsabilidade de forma satisfatória e não
assumir a responsabilidade de outras classes.
• Acoplamento corresponde a quanto uma classe
depende de outra para funcionar.
− A dependência ocorre quando uma classe
depende de outra para cumprir suas
responsabilidades.
Coesão e Acoplamento
• Quanto maior é a dependência mais fortemente
acoplada as classes estão.
• Um nível de acoplamento elevado faz com que uma
classe tenha que saber muito detalhes de outra
classe para funcionar.
• Devemos sempre buscar reduzir o acoplamento e
aumentar a coesão.
• Também se aplicam aos módulos de um sistema.
Encapsulamento
Encapsulamento é uma técnica que visa separar os
aspectos externos de um objeto de seus detalhes
internos, garantindo a integridade e consistência dos
valores de seus atributos e do resultado da execução de
seus métodos.
Herança
• Permite criar uma hierarquia de classes onde:
− Classes filhas herdam atributos e métodos da
classe pai;
− Somente atributos e métodos públicos e
protegidos são herdados.
• Permite criar generalizações e especializações de um
determinado conceito.
• Também é caracterizado com relacionado “É um”.
Herança
Polimorfismo
• Uma vez criado um objeto nunca muda de forma.
• Apontadores ou referências podem, a cada momento,
representar objetos de diferentes formas.
− Entretanto, esses objetos devem ter
similaridades, ou seja, uma abstração em
comum.
Interfaces
• São utilizadas para representar responsabilidades
comuns de conceitos do sistema.
• Definem um contrato ou representação de um
comportamento de um conceito:
− Estabelece o que as implementações do
conceito têm que fazer;
− Mas não se preocupam em como ele o faz.
Desafios da O.O.
• Decompor um sistema em objetos não é trivial.
− É necessário garantir o reuso, encapsulamento,
flexibilidade, performance, evolução e a
manutenibilidade.
• Muitas vezes as práticas podem gerar conflitos.
Desafios da O.O.
• Representação distinta de outros paradigmas já
conhecidos.
• A modelagem O.O. permite qualquer representação.
− Não existe um agente de categoricamente lhe
afirme que algo é certo ou errado.
Conclusão
✔ Na O.O. a execução do programa ocorre por meio da 
interação entre os objetos.
✔ O.O. possui diferentes mecanismos para promover o reuso 
e a abstração de conceitos do domínio do problema.
✔ Parte dos conceitos não são triviais de serem aplicados.
02.
01. 03.
04.
Próxima Aula
Conceito de Code Smells. Métricas para análise de código.
Análise estática de código.Exemplos de Code Smells.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 1.6. CODE SMELLS E ANALISE ESTÁTICA DE CÓDIGO
PROF. GLADSTON JUNIO APARECIDO
Nesta aula
❑ Conceitos de Code Smells.
❑ Exemplos de Code Smells.
❑ Métricas de análise de código.
❑ Análise estática de código.
Code Smells
• Indicativo de que algo pode, potencialmente, estar
errado com um código.
• Também conhecidos como Bad Smells ou Design
Smells.
• Podem ocorrer por práticas ruins de programação ou
escolhas erradas de projetos.
Code Smells
• Quando ocorrem em nível de código contribuem para:
− Aumento da complexidade do sistema;
− Tornam o código difícil de entender e manter.
• As vezes um code smell pode não representar um
problema real.
− Por isso são denominados como cheiros.
• São uma das principais causas de necessidade de
refatoração de código.
Métricas
• Muitos code smells são baseados em métricas.
• Métricas podem estar relacionados ao tamanho:
− Lines of Code (LOC);
− Number of Attributes (NOA);
− Number of Methods (NOM).
• Métricas podem estar relacionados à complexidade:
− Weighted Method per Class (WMC);
− Lack of Cohesion in Methods (LCOM).
Métricas
• Métricas podem estar relacionados ao projeto:
− Depth of Inheritance Tree (DIT);
− Number of Children (NOC).
• Avaliar a qualidade de um software com base em
métricas pode não ser trivial.
− Qual seria uma métrica aceitável para o
tamanho de um classe?
− Qual a quantidade máxima aceitável para os
níveis de uma hierarquia de classes?
Threshold
• Uma abordagem que pode ser adotada é determinar
um threshold.
• Em uma análise baseada em threshold, o resultado
permite determinar o quanto um atributo está acima
ou abaixo do valor esperado.
• Thresholds devem ser sempre monitorados e
recalibrados.
Threshold
• A definição de um threshold pode ser feita com base
em:
− Referências (normas, padrões, etc.);
− Benchmarks em um conjunto de sistemas;
− Benchmarks de mercado;
− Experiência profissional.
Exemplos de Code Smells
• Inappropriate naming
• Comments
•Dead code
• Duplicate code
• Primitive obsession
• Large class
• God class
• Lazy class
• Middle Ma
• Data clumps
• Data class
• Long method
Exemplos de Code Smells
• Large Class: classes com muitas responsabilidades.
• God Class (object): classes que fazem muito
trabalho, são muito grandes ou muito complexas.
• Duplicated Code: bloco de código existente em mais
de um local.
• Long Method: métodos com código extenso ou
múltiplas responsabilidades.
Exemplos de Code Smells
• Divergent Change: ocorre quando uma classe de
maneiras diferentes e por motivos diferentes.
• Shotgun Surgery: inverso do Divergent Change, se
manifesta quando uma alteração na classe X sempre
resulta em alterações em outras classes.
• Comentários: se manifesta quando o código se torna
incompreensível sem a presença/leitura de
comentários.
Identificação
• Existem diferentes formas de se identificar code
smells.
• A identificação pode ocorrer por:
− Inspeção manual (code review): menos efetiva;
− Análise estática de código;
− Análise dinâmica de código.
Identificação
• A análise estática avalia os artefatos do código fonte
em compile time (sem a execução do sistema).
• Pode ser executada sob demanda ou incorporada em
pipelines de builds de ferramentas de CI/CD.
− Ex.: SonarQube (https://www.sonarqube.org/).
• Referências e comportamentos dinâmicas não são
capturados.
https://www.sonarqube.org/
Conclusão
✔ Code Smells estão diretamente relacionados às más 
práticas de programação.
✔ Não necessariamente representam problemas reais.
✔ Grandes motivadores para refatoração de sistemas.
✔ Definir métricas e thresholds é fundamental para eliminar 
falso positivos.
01.
Próxima Aula
Princípios SOLID.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 1.7. OS PRINCÍPIOS DE PROJETOS SOLID
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Os princípios de projetos SOLID.
SOLID
“Bons sistemas de software começam com código limpo.
Por outro lado, se os blocos não forem bem construídos
a arquitetura da construção pouco importa. Além disso,
você pode fazer uma bagunça substancial com blocos
bem construídos. É aqui que entram os princípios
SOLID.” [ROBERT, 2017].
SOLID
• Na Orientação a Objetos existem diversos conceitos
importantes para a qualidade do código:
− Encapsulamento;
− Herança;
− Interfaces;
− Polimorfismo.
SOLID
• Os conceitos citados da O.O. por si só não garantem
que o código será escrito de forma correta.
• Ex.:
− Uma classe pode ser criada com vários métodos
que não deveriam fazer parte da classe;
− A herança pode ser usada indevidamente
produzindo uma hierarquia de classes
equivocada.
SOLID
• SOLID auxilia na organização de funções e dados em
classes e como interligar essas classes.
− Não se limita apenas ao paradigma orientado a
objetos.
• Acrônimo de:
− S: Single Responsibility Principle
− O: Open/Closed Principle
− L: Liskov Substitution Principle
− I: Interface Segregation Principle
− D: Dependency Inversion Principle
Single Responsibility Principle (SRP)
• O Single Responsibility Principle dita que uma classe
deve ter uma e apenas uma responsabilidade.
• Um dos princípios menos compreendidos do SOLID.
− Uma responsabilidade não quer dizer que uma
classe deve fazer somente uma coisa.
Open/Closed Principle (OCP)
• Uma classe deve ser aberta para extensão, mas
fechada para modificação.
− Em outras palavras, o comportamento de uma
classe deve ser estendido sem que seja
necessário alterá-la.
• Motivo: se a classe for alterada, é bem provável que
as alterações "quebrem" outras partes do sistema
que estavam funcionando.
Liskov Substitution Principle (LSP)
• Coleção de diretrizes para criação de hierarquias de
classes (herança) onde um consumidor pode usar
seguramente qualquer classe ou subclasse sem que
o comportamento esperado seja comprometido.
Liskov Substitution Principle (LSP)
FONTE: ROBERT, 2017.
Interface Segregation Principle (ISP)
• Segundo o ISP, consumidores de uma classes não
devem ser forçados a dependerem de métodos que
eles não usam.
FONTE: ROBERT, 2017.
Interface Segregation Principle (ISP)
FONTE: ROBERT, 2017.
Dependency Inversion Principle (DIP)
• Para garantir a flexibilidade do sistema, as dependências no
código fonte devem apontar apenas para abstrações e não
para tipos concretos.
• Assim como todos os princípios, não se aplica apenas às
classes.
Dependency Inversion Principle (DIP)
• Dada a quase impossibilidade de aplicação do princípio a
todas as dependências, é comum termos como exceções:
− Facilitadores relacionados à sistema operacional;
− Facilitadores relacionados às plataformas e linguagens.
Conclusão
✔ Os princípios SOLID complementam as boas práticas da 
O.O.
✔ Não se aplicam somente às classes, mas também a outros 
artefatos do sistema.
✔ Estão presentes nas recomendas das principais arquiteturas 
de referência.
02.
01.
Próxima Aula
Conceitos do padrão Injeção de 
Dependência.
Demonstração do padrão Injeção 
de Dependência.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 1.8. INJEÇÃO DE DEPENDÊNCIA
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Inversion of Control (IoC).
❑ Injeção de Dependência.
❑ Demonstração.
Inversion of Control (IoC)
• No paradigma de programação procedural, se um
bloco de código A usa um bloco de código B, o bloco
A tem controle sobre o contexto de execução.
• O IoC é princípio de arquitetura que propõe a
inversão desse fluxo de controle.
• Trata-se de um princípio abstrato.
Dependency Injection (DI)
• Uma das principais abordagens para redução de
acoplamento entre componentes de um software.
• De acordo com o DI, as dependências (services) de
um componente devem ser injetadas.
− As dependências deixam de ser especificadas
hard-coded nos construtores ou chamadas dos
componentes.
Dependency Injection (DI)
• A injeção das dependências deve ser realizada
dinamicamente por componentes de terceiros.
• Denominados IoC Containers.
• Exemplos:
− Unity;
− Ninject;
− Castle Windosr;
− Autofac;
− Spring;
− StructureMap.
Dependency Injection (DI)
• DI contribui para:
− O gerenciamento de mudanças futuras;
− Redução da complexidade do código;
− Uso de técnicas de testes unitário de código;
− Criação de linhas de produtos e arquiteturas
dependency free.
Injeção de Dependência
DEMONSTRAÇÃO
Conclusão
✔ Padrão importante para as principais arquiteturas de 
software.
✔ Pode ser implementados em diferentes plataformas.
✔ Contribui para a aplicação efetiva de metodologias como 
TDD.
02.
01.
Próxima Aula
Importância dos Catálogos de 
Padrões.
Principais Catálogos de Padrões.
Design Patterns, Estilos e 
Padrões Arquiteturais
CAPÍTULO 2. CATÁLOGO DE PADRÕES
PROF. GLADSTON JUNIO APARECIDO
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 2.1. OS PRINCIPAIS CATÁLOGOS DE PADRÕES
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Classificações de padrões.
❑ Catálogo de padrões.
Classificação de Padrões
• Ao longo dos anos diversos estudos têm sido
conduzidos com o intuito de identificar padrões.
• Para facilitar o aprendizado e uso dos padrões, foram
definidas algumas classificações, também
denominadas catálogos.
POSA
• Pattern Oriented Software Archicture.
• Catálogo focado em padrões para desenvolvimento
de sistemas de missão-crítica.
• Muito utilizado no desenvolvimento de sistemas
operacionais, servidores web, middlewares, etc.
POSA
• Estruturação:
− Layers
− Pipes & Filters
− BlackBoard.
• Sistemas Distribuídos:
− Broker
− Microkernel
• Sistemas Interativos:
− Model View Controller
− Presentation Abstraction Control
POEAA
• Catálogo proposto por Martin Fowler no livro
Enterprise Application Architecture.
• Foca em padrões para “aplicação corporativas”
usando .Net e Java.
POEAA
• Lógica de domínio:
− Domain model, service layer.
• Fonte de dados:
− Active record, data mapper.
•Comportamento em ORM:
− Unit of Work, lazy load.
• Apresentação Web:
− Model View Controller, page controller, template
view.
Outros Catálogos
• Além das propostas citadas, existem diversos outros
catálogos de padrões úteis para um arquiteto de
software:
− Gang Of Four (GoF)
− Enterprise Integration Patterns (EIP)
− J2EE design patterns
− DDD patterns
− Microservice patterns
Conclusão
✔ Catálogos auxiliam o estudo e aplicações de padrões.
✔ Existem catálogos para padrões de diferentes aplicações.
✔ Arquitetos de software devem conhecer os principais 
catálogos de padrões.
02.
01. 03.
Próxima Aula
Conceitos de AntiPatterns. Importância dos AntiPatterns.
Exemplos de AntiPatterns.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 2.2. ANTIPATTERNS
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos de AntiPatterns.
❑ Exemplos de AntiPatterns.
❑ Importância dos AntiPatterns.
AntiPatterns
• Soluções ruins para problemas recorrentes de
projeto e implementação.
• Seus impactos em um software podem comprometer:
− A compreensão;
− A evolução;
− A manutenção.
AntiPatterns
• Pode acontecer quando um colaborador:
− não conhece uma solução melhor;
− não tem conhecimento ou experiência suficiente
para resolver um determinado tipo de problema;
− aplica um padrão correto, porém, no contexto
errado.
Anti-Patterns
• The Blob
• Continuous Obsolescence
• Lava Flow
• Ambiguous Viewpoint
• Functional Decomposition
• Poltergeists
• Boat Anchor
• Golden Hammer
• Dead End
• Long parameter list
• Spaghetti Code
• Input Kludge
AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis
Anti-Patterns
• Os antipatterns são igualmente importantes
considerando que:
− Permitem mapear com eficiência uma situação
geral para uma classe específica de soluções;
− Fornecem experiência do mundo real no
reconhecimento de problemas recorrentes na
indústria de software;
− Fornecem uma solução detalhada para os
problemas mais comuns;
− Fornecem um vocabulário comum para
identificar problemas e discutir soluções.
Exemplos
• Spaghetti Code
− Se manifesta em;
• Códigos com estruturas fracas;
• Códigos com falta de clareza;
• Códigos comprometidos ao ponto de nem o
desenvolvedor original conseguir entende-
lo;
• Código do violações de diversos outros
antipatterns e code smells.
• Códigos difíceis de manter, sem uso
racional de reuso e sem possibilidades de
extensão.
Exemplos
• RICHARDS, Mark. Microservices antipatterns and
pitfalls. 1. ed. O'Reilly Media, 2016. 66 p.
• KARWIN, Bill. SQL Antipatterns: Avoiding the
Pitfalls of Database Programming. 1. ed. Pragmatic
Bookshelf, 2010. 333 p.
Conclusão
✔ AntiPatterns é um catálogo de padrões.
✔ Foco em soluções ruins, comumente encontrados em 
projetos e implementações de software.
✔ Contribuem para a qualidade do software de forma análoga 
aos padrões de outros catálogos.
02.
01.
Próxima Aula
Conceitos de Design Patterns.
Catálogo de padrões GoF.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 2.3. DESIGN PATTERNS
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitualização.
❑ Design Patterns – Gang of Four.
Design Patterns
• Design Patterns representam soluções para
problemas que ocorrem no projeto (desenho, ou
estruturação) de um software.
• Foco em design time e não em runtime.
• Forte vínculo com o paradigma de programação
orientada a objetos.
Design Patterns – GoF
• No contexto de padrões de projetos (design patterns),
o catálogo mais famoso é conhecido como Gang of
Four (GoF).
− Formalizados em 1994 no livro Design Patterns
Elements of Reusable Object-Oriented
Software (GAMA et al, 1994);
− Propõe 23 padrões divididos em três categorias:
• Creational patterns;
• Structural patterns;
• Behavioral patterns.
Creational Patterns
• Abstraem os processos de criação de instância de
objetos.
− Disponibilizar um objeto “pronto para uso”
envolve mais do que apenas instanciar uma
classe.
• É comum o software evoluir de forma a depender
mais da composição dos objetos do que da hierarquia
de classes.
Creational Patterns
❑ Existem dois pontos centrais nos padrões de criação:
1) determinam quais classes concretas o sistema
utiliza.
2) ocultam como as instâncias são criadas.
❑ O sistema como um todo se baseia em interfaces e
classes abstratas.
❑ Adicionam flexibilidade ao projeto permitindo controlar
o que é criado, quem cria, como é criado e quando
deve ser criado.
Structural Patterns
• Focam em como classes e objetos são composto
com o objetivo de formar estruturas maiores e mais
complexas.
• Provê soluções para, por exemplo, descrever formas
de compor objetos que pode realizar novas
funcionalidades definidas em tempo de execução.
Behavioral Patterns
• Focados em algoritmos e como os objetos atribuem
responsabilidades entre si.
− Ou seja, proveem padrões para problemas
recorrentes na comunicação entre objetos.
• Simplificam o fluxo de execução de algoritmos
complexos difíceis de serem avaliados em runtime.
− Mudam o foco do fluxo de execução para a
interconexão dos objetos.
Design Patterns – GoF
FONTE: GAMA, 1994.
Conclusão
✔ O catálogo de padrões GoF fornece padrões para diferentes 
classes de problemas de um software orientado a objetos.
✔ As soluções propostas abrangem questões relacionadas à 
criação de objetos até o controle do fluxo de execução.
01.
Próxima Aula
Demonstração dos principais 
design patterns de criação.
Design Patterns, Estilos e 
Padrões Arquiteturais
CAPÍTULO 3. DESIGN PATTERNS (GOF) – CREATIONAL PATTERNS
PROF. GLADSTON JUNIO APARECIDO
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 3.1. ABSTRACT FACTORY
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceito do Abstract Factory.
❑ Demonstração.
Abstract Factory
DEMONSTRAÇÃO
Conclusão
✔ Permite projetar classes e objetos que são independentes
de como suas dependências são compostas e criadas.
✔ Simplifica a criação de famílias de produtos de software.
✔ Permite isolar classes concretas.
02.
01.
Próxima Aula
Conceitos do Factory Method.
Demonstração do Factory Method.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 3.2. FACTORY METHOD
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceito do Factory Method.
❑ Demonstração.
Factory Method
DEMONSTRAÇÃO
Conclusão
✔ O Factory Method é um dos padrões mais utilizados do
GoF.
✔ Define uma interface para criação de objetos em uma
hierarquia de classes.
✔ As subclasses são responsáveis por determinar qual classe
concreta será instanciada.
02.
01.
Próxima Aula
Conceito do Singleton.
Demonstração do Singleton.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 3.3. SINGLETON
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos do Singleton.
❑ Demonstração.
Singleton
DEMONSTRAÇÃO
Conclusão
✔ Permite controlar o ciclo de vida de um objeto no sistema de 
forma a se determinar quantas instâncias de uma classe 
devem existir.
✔ Evolução das variáveis globais.
02.
01.
Próxima Aula
Conceito do Adapter.
Demonstração do Adapter.
Design Patterns, Estilos e 
Padrões Arquiteturais
CAPÍTULO 4. DESIGN PATTERNS (GOF) – STRUCTUAL PATTERNS
PROF. GLADSTON JUNIO APARECIDO
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 4.1. ADAPTER
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos do Adapter.
❑ Demonstração.
Adapter
DEMONSTRAÇÃO
Conclusão
✔ Converte a interface de uma classe incompatível para uma
interface reconhecida.
✔ Útil para permitir que objetos de aplicações e bibliotecas
legadas se comuniquem.
02.
01.
Próxima Aula
Conceito do Composite.
Demonstração do Composite.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 4.2. COMPOSITE
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos do Composite.
❑ Demonstração.
Composite
DEMONSTRAÇÃO
Conclusão
✔ Permite representar hierarquias do tipo todo-parte.✔ Tanto a hierarquia (composição) quanto as partes podem
ser manipuladas de forma uniforme.
02.
01.
Próxima Aula
Conceito do Decorator.
Demonstração do Decorator.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 4.3. DECORATOR
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Demonstração do padrão Decorator.
Decorator
DEMONSTRAÇÃO
Conclusão
✔ Permite adicionar novas responsabilidades a um objeto 
dinamicamente.
✔ Provê flexibilidade ao estender as funcionalidades de uma 
hierarquia de classes.
02.
01.
Próxima Aula
Conceito do Facade.
Demonstração do Facade.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 4.4. FACADE
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Demonstração do padrão Facade.
Facade
DEMONSTRAÇÃO
Conclusão
✔ Permite unificar a interface de um conceito no sistema.
✔ Tem por objetivo tornar o sistema mais fácil de ser utilizado.
02.
01.
Próxima Aula
Conceito do Command.
Demonstração do Command.
Design Patterns, Estilos e 
Padrões Arquiteturais
CAPÍTULO 5. DESIGN PATTERNS (GOF) – BEHAVIORAL PATTERNS
PROF. GLADSTON JUNIO APARECIDO
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 5.1. COMMAND
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos do padrão Command.
❑ Demonstração do padrão Command.
Command
DEMONSTRAÇÃO
Conclusão
✔ Encapsula ações em objetos.
✔ Permite ao cliente definir parâmetros para as ações.
02.
01.
Próxima Aula
Conceitos do Iterator.
Demonstração do Iterator.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 5.2. ITERATOR
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos do padrão Iterator.
❑ Demonstração do padrão Iterator.
Iterator
DEMONSTRAÇÃO
Conclusão
✔ Unifica a forma de percorrer uma coleção.
✔ Possui implementações nas principais linguagens de 
programação.
02.
01.
Próxima Aula
Conceitos do Observer.
Demonstração do Observer.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 5.3. OBSERVER
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos do padrão Observer.
❑ Demonstração do padrão Observer.
Observer
DEMONSTRAÇÃO
Conclusão
✔ Permite implementar a primitiva de comunicação Publish 
Subscriber a nível de objetos.
02.
01.
Próxima Aula
Conceitos do Template Method.
Demonstração do Template 
Method.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 5.4. TEMPLATE METHOD
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos do padrão Template Method.
❑ Demonstração do padrão Template Method.
Template Method
DEMONSTRAÇÃO
Conclusão
✔ Permite criar um esqueleto para um algoritmo onde alguns 
passos são definidos pelas classes filhas.
02.
01. 03.
04.
Próxima Aula
Conceitos dos padrões de acesso 
a dados.
Repository.
Unit of Work.Active Record.
Design Patterns, Estilos e 
Padrões Arquiteturais
CAPÍTULO 6. PADRÕES DE ACESSO A DADOS
PROF. GLADSTON JUNIO APARECIDO
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 6.1. INTRODUÇÃO
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Acesso a Dados.
Acesso a Dados
• Na arquitetura de aplicações a camada de acesso a
dados é responsável por se comunicar com diversos
mecanismos de persistência.
• Os mecanismos de persistência podem ser:
− Bancos relacionais;
− NoSql;
− Arquivos;
− Sistemas externos;
− Stream.
Acesso a Dados
• Em aplicações corporativas os bancos de dados
relacionais são os mais utilizados;
• A ampla adoção deles se deu basicamente pela
linguagem SQL e pela robustez das soluções.
• Em aplicações distribuídas e de larga escala outras
alternativas têm sido utilizadas.
Acesso a Dados
• Uma das estratégias de acesso a dados mais
difundidas consiste no acesso de forma ad hoc:
− A gestão do acesso a fonte de dados e a
tradução das operações do sistema para
comandos da fonte de dados é realizada pelo
desenvolvedor da aplicação.
Acesso a Dados
• Nas linguagens O.O., têm disso comum o uso os
mecanismos de Object Relational Mapping (ORM).
• Existem padrões de acesso a dados para ambos os
cenários e alguns podem ser utilizados em ambos os
casos.
Padrões de Acesso a Dados
• É muito importante conhecer e saber aplicar os
padrões de acesso a dados.
• As decisões tomadas no projeto da camada de
acesso a dados têm alto impacto e são difíceis de
serem refatoradas posteriormente.
− Podem impactar não apenas o acesso aos
dados propriamente dito como também como as
classes de domínio são projetadas.
Exemplos de Padrões
• Table Data Gateway
• Row Data Gateway
• Active Record
• Data Mapper
• Unit of Work
• Lazy Load
• Query Object
• Record Set
• Repository
• Identity Map
• Identity Field
Conclusão
✔ Acesso a dados é uma camada muito importante para a 
arquitetura de um software.
✔ Não representa apenas banco de dados relacionais.
✔ Decisões sobre acesso a dados possuem alto impacto.
01.
Próxima Aula
Conceitos de ORM.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 6.2. OBJECT RELATIONAL MAPPING (ORM)
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos de ORM.
Object Relational Mapping (ORM)
• ORM visa abstrair e separar as particularidades das
fontes de persistência das classes e regras do
domínio em O.O.
• A tradução das ações sobre o domínio para
comandos SQL é feita por componentes específicos
para esse fim.
Object Relational Mapping (ORM)
Objetos
Herança
Polimorfismo
Atributos
Interfaces
Tabelas
Colunas
Linhas
Views
Object Relational Mapping (ORM)
• Se usado adequadamente, contribui para:
− Produção de comandos SQL de melhor
qualidade;
− Redução do possível gap técnico em relação à
SQL;
− Uso facilitado de técnicas avançadas de
persistência;
− Facilidade de flexibilização das fontes de dados.
Object Relational Mapping (ORM)
• Existem diferentes abordagens para viabilizar o uso
efetivo da O.O. no universo dos ORM.
• Permitem, por exemplo:
− Trabalhar os herança e interface em classes
mapeadas ao banco de dados.
− Utilizados conceitos como tabelas de
associação.
− Compor objetos com múltiplas tabelas.
Object Relational Mapping (ORM)
• Exemplos:
− Identity Map;
− Foreign Key Mapping;
− Association Table Mapping;
− Dependent Mapping;
− Single Table Inheritance;
− Class Table Inheritance;
− Concrete Table Inheritance.
Object Relational Mapping (ORM)
• Exemplos de bibliotecas:
− Hibernate;
− Nhibernate;
− Dapper;
− Entity Framework.
Conclusão
✔ Embora SQL seja uma linguagem amplamente difundida, 
seus conceitos nem sempre são de conhecimento de todos 
da equipe.
✔ O universo da O.O. possui conceitos distintos do mundo 
relacional, principalmente no que tange ao relacionamento 
entre conceitos.
✔ ORM permitem abstrair a construção dos comandos de 
acesso a dados por meio de mapeamentos.
01.
Próxima Aula
Padrões base.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 6.3. PADRÕES BASE
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Gateway.
❑ Mapper.
❑ Value Obect.
❑ Record Set.
❑ Data Transfer Objects (DTO).
Gateway
• Representam objetos que encapsulam à um sistema
ou recurso externo.
• Contribuem para o isolamento entre softwares.
• Fornecem uma representação O.O. para fontes de
dados baseadas em outros paradigmas.
Gateway
FONTE: FOWLER, 2002.
Mapper
• Objetos responsáveis por viabilizar a comunicação
entre dois objetos independentes.
• Os objetos são interligados de forma que um não tem
conhecimento da existência de outro.
• Base para implementação do padrão Data Mapper.
Mapper
FONTE: FOWLER, 2002.
Value Objet
• Na Orientação a Objetos existem os tipos de dados
que são tratados por referência e outros por valor.
• No caso dos tipos de dados tratados por referência é
comum que as operações de comparação sejam
baseadas em suas “identidades”.
• Value Objects são pequenos objetos cuja
comparação não se dá apenas pelas suas
propriedades chaves.
Record Set
• Representações “as is”, em memória, de umaestrutura de tabelas.
• Disponíveis nas principais linguagens e drivers de
acesso à dados.
• Por serem estruturas desconectadas, é transferir
tabelas como DTO.
• Auxiliam na implementação de manutenção offline de
dados.
Data Transfer Objects
• Objetos responsáveis por transportar dados entre
processos.
• Suas principais funções são:
− Reduzir a quantidade de chamadas de métodos;
− Consolidar diferentes conceitos em um único
objeto.
Data Transfer Objects
FONTE: FOWLER, 2002.
Conclusão
Os padrões bases podem ser utilizados em diversos cenários 
em um software.
São a base para alguns dos principais padrões de acesso à 
dados.
01.
Próxima Aula
Conceitos do padrão Active 
Record.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 6.4. ACTIVE RECORD
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Características do padrão Active Record.
Active Record
• Mantem os dados e comportamentos do domínio
sobre a responsabilidade do mesmo objeto que
realizada as operações de persistência.
FONTE: FOWLER, 2002.
Active Record
• Apresenta uma modelagem bem próxima do banco
de dados:
− Um atributo para cada coluna da tabela.
− Para cada linha da tabela se produz um objeto.
Active Record
• Disponibiliza métodos para operações do tipo:
− Instanciar um objeto ou vários objetos com base
no resultado de uma query;
− Instanciar um objeto para persistência futura;
− Sensibilizar a fonte de persistência;
− Business Logic.
Active Record
• Outros padrões relacionados:
− Identity Field
− Transaction Scripts
− Domain Model
• Quando utilizar:
− Cenários com domínios simples;
− Linguagens ou plataformas com recursos
limitados.
Conclusão
✔ Centraliza no mesmo objeto regras de negócio, dados e 
regras de persistência.
✔ Apresenta uma modelagem bem próxima do banco de 
dados.
01.
Próxima Aula
Conceitos do padrão Data Mapper.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 6.5. DATA MAPPER
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos do padrão Data Mapper.
Data Mapper
• A representação de um domínio por meio da O.O. na
maioria das vezes difere da representação do
domínio na fonte de persistência:
− Herança e algumas coleções por ex. não
existem em bancos relacionais.
• O padrão Data Mapper visa criar uma camada de
tradução (mapeamento) entre os dois mundos.
Data Mapper
FONTE: FOWLER, 2002.
Data Mapper
• Outros padrões relacionados:
− Identity Map
− Unit of Work
− Record Set
− Lazy Load
• Quando utilizar:
− Quando o modelo de objetos e o modelo de
persistência precisam evoluir separadamente.
− Lógicas de persistências mais complexas.
Conclusão
✔ Permite abstrair e simplificar as regras de acesso a dados 
em cenários complexos.
✔ Separa modelo O.O. e modelo relacional.
01.
Próxima Aula
Conceitos do padrão Unif of Work.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 6.6. UNIT OF WORK
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos do padrão Unit of Work.
Unit of Work
• Uma Unit of Work mantém uma coleção de objetos
afetados por uma transação (a nível de negócio) e
coordena a sensibilização das mudanças nesses
objetos para a fonte de persistência.
• É responsável por tratar eventuais problemas de
concorrência.
• Sua implementação depende diretamente da
capacidade de rastrear o que mudou em cada objeto.
Unit of Work
• As regras de negócio comunicam a Unit of Work
sobre as mudanças nos objetos (inclusão, alteração e
remoção).
• Eventualmente, objetos recuperados também podem
ser armazenados na Unit of Work.
• A Unit of Work não permite que os métodos de insert,
update e delete na fonte de persistência sejam
consumidos por objetos externos.
Unit of Work
• A transmissão das mudanças para a fonte de
persistência ocorre por meio do consumo do método
de commit da Unit of Work.
• Durante sua execução são executadas:
− As verificações de concorrência (pessimistics,
optimistics, etc.);
− Tradução das mudanças em comandos para a
fonte de persistência.
Unit of Work
FONTE: FOWLER, 2002.
Unit of Work
• Outros padrões relacionados:
− Domain Model
− Optimistic Offline Lock
− Pessimistic Offline Lock
− Identity Map
− Data Mapper
Unit of Work
• Quando utilizar:
− Cenários onde se faz necessário agrupar e
rastrear mudanças nos objetos antes de enviá-
las para a fonte de dados;
− Quando for necessário reduzir o tempo em que
as conexões com a fonte de dados devem ficar
abertas.
Conclusão
✔ O Unit of Work visa criar, em memória, uma unidade 
transacional.
✔ Rastreia e armazena as mudanças comandadas pela 
execução o sistema e depois as reproduz na fonte de 
persistência.
01.
Próxima Aula
Conceitos do padrão Repository.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 6.7. REPOSITORY
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos do padrão Repository.
Repository
• O padrão Data Mapper provê uma camada que isola
o objetos de domínio do código de acesso a dados.
• Em cenários complexos com múltiplos domínios ou
consultas “pesadas”, uma camada adicional pode ser
útil (repositório).
• O repository funciona como uma coleção de objetos
em memória.
− Uma representação simplificada da fonte de
dados.
Repository
• Nele se concentra a construção das queries.
− Os objetos que desejam acessar a fonte de
dados se comunicam com o repositório;
− Objetos podem ser incluídos e removidos do
repositório;
− O repositório é quem se encarrega de acessar a
fonte de dados.
− Permite o reuso da lógica das queries de um
domínio.
• Ao contrário do Data Mapper, o repositório não expõe
métodos específicos de acesso à fonte de dados.
Repository
FONTE: FOWLER, 2002.
Repository
• Outros padrões relacionados:
− Data Mapper
− Query Object
− Metadata Mapping
Repository
• Quando utilizar:
− Cenários com múltiplos tipos de domínio e
grande variedade de queries;
− Cenários com diferentes fontes de dados;
− Domínios com fontes de persistência diferentes
dos SGBD como XML, SOAP, REST, stream,
etc.
Conclusão
✔ Utilizado para cenários com queries complexas.
✔ Fornece mecanismos para flexibilizar as regras de 
consultas.
✔ Mantem uma coleção de dados em memória.
02.
01.
Próxima Aula
Arquitetura vs Design.
Introdução aos estilos 
arquiteturais.
Design Patterns, Estilos e 
Padrões Arquiteturais
CAPÍTULO 7. ESTILOS E PADRÕES ARQUITETURAIS
PROF. GLADSTON JUNIO APARECIDO
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 7.1. INTRODUÇÃO A ESTILOS E PADRÕES ARQUITETURAIS
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Arquitetura e Design (Projeto).
❑ Estilos e Padrões Arquiteturais.
Arquitetura e Design
• Um arquiteto de software precisa lidar com questões
de projeto (design) e questões arquiteturais.
• Mas qual a diferença entre elas? Elas são iguais?
− Arquitetura tende a lidar com decisões de “alto
nível” (maior impacto).
− Design, em geral, representam estruturas e
decisões de “baixo nível”, mas não menos
importantes.
Arquitetura e Design
• Martin Robert (2017) faz uma comparação em
relação ao planejamento da construção de uma casa.
• O arquiteto toma algumas decisões de alto nível:
− A forma da casa;
− Sua localização no terreno;
− As curvas níveis do terreno e suas elevações;
− Layout e dimensões dos cômodos.
Arquitetura e Design
• Mas também existem outros detalhes de baixo nível:
− Localização das tomadas e lâmpadas;
− Orientação do sol;
− Localização da caixa d'água.
Arquitetura e Design
• Na construção de um software também existem
ambos os tipos de decisões a serem tomadas por um
arquiteto.
• O objetivo principal dessas decisões pode ser
resumido em:
“The goal of software architecture is to minimize the
human resources required to build and maintain the
required system.” (ROBERT, Martin. 2017).
Estilos Arquiteturais
• Diante disso, estilos ou padrões arquiteturais visam:
− Aplicar soluções conhecidas no projeto deum
software;
− O intuito é garantir um ou mais atributos de
qualidade previstos para o software;
− Envolvem design time, runtime e conceitos.
Estilos Arquiteturais
• Exemplos:
− Layer Pattern;
− Ports and Adapters;
− Pipe and Filters;
− Service Oriented Architects;
− Publish Subscribers;
− Multi Tiers.
Conclusão
✔ Estilos arquiteturais representam soluções para questões de 
alto nível do projeto de um software.
✔ Envolvem design time, runtime e conceitos.
02.
01. 03.
Próxima Aula
Conceito de arquitetura 
multicamadas.
Vantagens de um arquitetura 
multicamada.
Características de uma 
arquitetura multicamada.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 7.2. ARQUITETURA MULTICAMADAS
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceito de Arquitetura Multicamadas.
❑ Características e vantagens de uma Arquitetura 
Multicamadas.
Tiers vs Layers
• Tier e layer representam camadas de um sistema.
• Layer representa um agrupamento lógico:
− Está mais ligado ao design time;
− Determina a organização das funcionalidades e
componentes.
• Tier representa um agrupamento físico:
− Está ligado ao runtime;
− Determina a localização da execução dos
componentes.
Arquitetura Multicamadas
• A abordagem mais utilizada durante a distribuição
dos artefatos de um software;
• As camadas são horizontais e formam uma estrutura
hierárquica.
• A interação entre as camadas ocorre de forma top-
down.
Arquitetura Multicamadas
• Um exemplo clássico é a arquitetura de 3-camadas
(apresentação, negócio, acesso a dados).
Fonte: ebrary.net
Arquitetura Multicamadas
• As camadas podem ser abertas ou fechadas:
− Fechadas: uma camada fechada deve
direcionar o fluxo para a primeira camada logo
abaixo.
− Abertas: uma camada aberta pode fazer o by-
pass da camada imediatamente abaixo.
Vantagens
• Facilita a separação de interesses;
• Maior flexibilidade (baixo acoplamento);
• Melhora o entendimento dos artefatos do software;
• Contribui para a construção de software testáveis;
• Contribui para a manutenibilidade e escalabilidade.
Conclusão
✔ Camadas visam agrupar os artefatos de um software por 
responsabilidades.
✔ Podem ser físicas ou lógicas.
02.
01.
Próxima Aula
Arquitetura cliente servidor.
Arquitetura N-Tier.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 7.3. ARQUITETURA CLIENTE SERVIDOR E N-TIER
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Arquitetura Cliente Servidor.
❑ Arquitetura N-Tier.
Arquitetura Cliente Servidor
• Arquitetura mais utilizada e adaptada desde a adoção
das redes de computadores.
• Distribui o runtime do software em duas camadas:
− Cliente.
− Servidor.
Arquitetura Cliente Servidor
ServidorCliente
Arquitetura Cliente Servidor
• Podem existir mais de um cliente o por servidor.
• Clientes podem solicitar dados e algoritmos do
servidor.
• Clientes podem ser classificados como:
− Thin Clients;
− Fat Clients.
Arquitetura Cliente Servidor
• A distribuição física dos componentes do software é
(tiers) fundamental para o seu sucesso.
− Tem impacto direto em atributos de qualidade como
escalabilidade e disponibilidade, fundamentais para
aplicações modernas.
Arquitetura N-Tier
• A arquitetura multicamadas N-Tier ou Multitier
distribui o runtime do software em três ou mais
camadas.
Business TierPresentation Tier Data Tier
Arquitetura N-Tier
• Podem existir quantas camadas forem necessárias.
• A comunicação entre as camadas pode utilizar
protocolos e meios distintos.
Arquitetura N-Tier
FONTE: KEELING, 2017.
Conclusão
✔ O projeto das camadas físicas de um software é tão 
importante quanto as camadas lógicas.
✔ A arquitetura cliente servidor é uma das principais 
arquiteturas para separação de camadas (tiers).
✔ A arquitetura N-Tier distribui o runtime do software em três 
ou mais camadas.
01.
Próxima Aula
Padrão arquitetural Model View 
Controller.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 7.4. MODEL VIEW CONTROLLER (MVC)
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ O padrão Model View Controller.
❑ Vantagens do MVC.
❑ Variações do MVC.
Model View Controller (MVC)
• Um dos padrões arquiteturais mais tradicionais.
• Tem ampla adoção nas bibliotecas Web, mas
também pode ser aplicado em outras plataformas.
• Utilizado amplamente nas camadas de UI.
− Auxilia na separação de interesses da interface.
• Usado em implementações como Spring MVC, Ruby
on Rails, ASP .Net MVC, etc.
Model
• Responsável por gerenciar os dados e o estado da
aplicação.
• Processa os dados de e para as fontes de dados.
• Deve ser independente de controller e view.
• Recebe comandos dos controllers para recuperar
dados ou sensibilizar a fonte de dados.
Model
• Considerando as diferentes variações do MVC o
Model pode ser:
− Ativo: transmite para as views o resultado do
processamento das funcionalidades (mudança
no estado da aplicação);
− Passivo: recebe as demandas e transmite o
resultado do processamento para fora da
aplicação.
View
• Responsável pela apresentação da aplicação.
• Apresenta os dados para o usuário na interface
apropriada;
• Coordena a interação do usuário com a aplicação:
− Coleta dos inputs fornecidos pelo usuário aciona
o controller necessário;
− Apresenta o resultado das ações executadas.
Controller
• Atua como intermediário entre as views e os models.
• Responsável por acionar a view adequada
informando os dados necessários para sua
rendenização.
• Sua implementação depende diretamente da
capacidade de rastrear o que mudou em cada objeto.
Model View Controller (MVC)
1. Sends user actions
ControllerView
Model
3. Selects appropriated view 
Model View Controller (MVC)
1. Sends user actions
ControllerView
Model
3. Selects appropriated view 
4. Sends user actions Mundo 
Externo
Model View Controller (MVC)
1. Sends user actions
ControllerView
Model
3. Selects appropriated view 
View
Controller
Vantagens do MVC
• Dentre as vantagens do padrão MVC se destacam:
− Facilita os testes da aplicação;
− Contribui para que uma alteração em uma
camada não afete as demais;
− Contribui para o reuso dos objetos;
− Auxilia na especialização das atividades de
frontend e backend em aplicações cliente
servidor.
Variações do MVC
• Existem diversas variações do MVC, como:
− Model View Presenter (MVP)
− Model View ViewModel (MVVM)
− Fractal MVC
− Page Controller
− Front Controller
Conclusão
✔ É um dos mais padrões arquiteturais mais conhecidos.
✔ Está presente em diversos frameworks e bibliotecas.
✔ Propõe a distribuição do software em três macro camadas 
(Model, View e Controller).
✔ Tem como vantagem a melhoria do nível de reuso e de 
aptidão para testes.
01.
Próxima Aula
Conceitos do padrão Model View 
Presenter.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 7.5. MODEL VIEW PRESENTER (MVP)
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Os princípios do Model View Presenter (MVP).
❑ Responsabilidades das camadas no MVP.
Model View Presenter (MVP)
• Variação do padrão MVC.
• Propõe a separação entre regras de UI e regras de
negócio.
• Cada interface de usuário possui uma View
correspondente.
Model View Presenter (MVP)
• Os Controllers são substituídos pelos Presenters.
• As Views estão diretamente acopladas ao seu
Presenter.
• As Views não interagem diretamente com o Model.
Model View Presenter (MVP)
FONTE: INGENO, 2018.
Model
• Representa o negócio.
• Encapsula o modelo de negócio e seus dados.
• Interage com a fonte de persistência para recuperar e
armazenar dados.
• Recebe inputs do Presenter e, em seguida, reporta
ao mesmo o resultado da execução.
View
• Responsável por rendenizar as interfaces de usuário.
• Cada interface possui uma View.
• A interação do usuário com a View resulta no envio
de mensagens para o Presenter.
• Possui papel passivo, confiando no Presenter.
Presenter
• Intermediárioentre o Model e a View.
• Responsável por sensibilizar o Model de acordo com
a interação do usuário com a View.
• Formata os dados recebidos do Model de forma
adequada para a View.
Conclusão
✔ Variação do padrão MVC.
✔ Os presenter interagem com o models.
✔ As views possuem relacionamento de 1 para 1 com a 
interface de usuário e têm papel passivo.
01.
Próxima Aula
Conceitos do padrão Model View 
ViewModel.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 7.6. MODEL VIEW VIEWMODEL (MVVM)
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Os princípios do Model View ViewModel (MVVM).
❑ As responsabilidades das camadas no MVVM.
Model View ViewModel (MVVM)
• Padrão arquitetural baseado no MVC.
• Tem como principal diferença a separação da
interface de usuário do restante da aplicação.
• Utiliza o conceito de data binding.
• Pode ser utilizado em aplicações desktop, web e
mobile.
Model
• Tem responsabilidades similares ao Model dos
padrões MVC e MVP.
• Entretanto, podem existir vínculos do tipo data
binding estabelecidos com as propriedades do Model.
− Nesse caso o Model atua de forma ativa.
− Dispara eventos para sinalizar mudanças nas
suas propriedades.
View
• No padrão MVVM as Views possuem as seguintes
características:
− São ativas;
− Não são totalmente manipuladas pelos
Presenters;
− Realizam o tratamento dos seus eventos;
− Têm consciência da existência dos ViewModels
e Models.
− Delegam as ações para o ViewModel por meio
de comandos ou data binding.
ViewModel
• Similares aos Controllers e Presenters do MVC e
MVP.
• Suas principais características e responsabilidades
são:
− Disponibilizar dados para as Views;
− Encapsular as regras de interação entre Views e
Models.
− Concentram as regras de navegação.
• No MVVM as Views tendem a possuir menos código.
Model View ViewModel (MVVM)
FONTE: INGENO, 2018.
Conclusão
✔ Tem como principal diferencial a separação da UI do 
restante da aplicação.
✔ Utiliza conceitos de eventos e data binding para interação 
entre as camadas.
✔ As views possuem o mínimo possível de código.
02.
01. 03.
Próxima Aula
Single Page Applications (SPA). Frameworks SPA.
Padrões arquiteturais nas SPA.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 7.7. SINGLE PAGE APPLICATIONS (SPA)
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Single Page Applications (SPA).
❑ Padrões Arquiteturais nas SPA.
❑ Frameworks SPA.
Single Page Applications (SPA)
Servidor WebCliente
Requisição 1
Requisição 2
Pool
de
Threads
Requisição n
Single Page Applications (SPA)
• Conjunto de princípios e tecnologias onde, uma vez
combinados, permitem:
− Entregar aplicações web modernas;
− Empregar no desenvolvimento de frontends
técnicas até então exclusivas do
desenvolvimento de backend na web.
Single Page Applications (SPA)
HTML5
Javascript e 
Ajax
CSS3
Padrões 
Arquiteturais 
(MVC)
Frameworks
Rotas
Frontend
Inteligente
Página Única
Lightweight 
Backend
Test Driven 
Development
Single Page Applications (SPA)
• O frontend é composto por uma página principal,
denominada shell.
• A shell é responsável por coordenar a navegação do
usuário.
• A interface de usuário é carregada parcialmente
durante a interação do usuário.
Single Page Applications (SPA)
Servidor WebCliente
Requisição 1
Resposta - Shell
Requisição 2...n (AjaxRequest)
Resposta (JSON)
Single Page Applications (SPA)
• Na arquitetura de aplicações SPA é comum o uso de
do padrão Fractal MVC (FMVC).
Single Page Applications (SPA)
• No lado cliente alguns frameworks utilizam o padrão
MVVM.
Frameworks e Bibliotecas
• Angular
• Vue.js
• Backbone.js
• Knockout.js
• React.js
Conclusão
✔ Uma das principais tendências no desenvolvimento de 
aplicações Web.
✔ Utiliza os principais padrões arquiteturais.
✔ Um dos elementos chave é a shell da aplicação.
02.
01.
Próxima Aula
Conceito de Clean Architecture.
Características de uma 
arquitetura Clean Architecture.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 7.8. CLEAN ARCHITECTURE
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceito de Clean Architecture.
❑ Características de uma arquitetura Clean 
Architecture.
Arquiteturas de Software
• Existem diversas propostas para arquiteturas de um
software e a maioria possuem algumas
características em comum:
− Propõem abordagens para separação de
interesses;
− Dividem o software em camadas.
• Exemplos:
− Hexagonal Architecutre;
− Onion Architecture;
− Screaming Architecture.
Arquiteturas de Software
• As arquiteturas em geral visam garantir ao software
características como:
− Independência de framework;
− Testabilidade;
− Independência de interface de usuário;
− Independência de banco de dados;
− Manutenibilidade.
Clean Architecture
• Uma das principais propostas é a Clean Architecture.
• Similar à Onion Architecture.
• O relacionamento entre as camadas do software é
regido por uma diretriz que estabelece :
“As dependências do código-fonte devem apontar
apenas para dentro, em direção a políticas de nível
superior.” (MARTIN, 2017).
Clean Architecture
FONTE: MARTIN, 2017.
Clean Architecture
• As camadas propostas são:
− Entities: concentra as regras de negócio críticas
ou estratégicas para a organização.
− Use Cases: encapsulam as regras de negócio
específicas de um software da organização;
Clean Architecture
• As camadas propostas são:
− Interface Adapters: responsável por adaptar os
dados dos use cases para um formato mais
adequado para os agentes externos (Web,
Mobile, API, etc.);
Clean Architecture
FONTE: MARTIN, 2017.
Clean Architecture
• As camadas propostas são:
− Framework e Drivers: códigos e demais
artefatos específicos de plataformas, acesso a
dados, segurança, etc.
Clean Architecture
FONTE: MARTIN, 2017.
Clean Architecture
• A Clean Architecture é um modelo de referência.
• A interação entre as camadas pode acontecer por
meio de diferentes tecnologias.
• Sua implantação pode ser complexa e onerosa.
Clean Architecture
Conclusão
✔ Importante arquitetura de referência para construção de 
aplicações modernas.
✔ Distribui o software em camadas de forma similar à Onion 
Architecture.
✔ O fluxo de interação entre as camadas deve ser sempre no 
sentido da camada mais interna.
02.
01. 03.
04.
Próxima Aula
Conceito de Sistemas Distribuídos 
(SD).
Principais características de SD.
Desafios do desenvolvimento de 
SD.
Tipos de Sistemas Distribuídos.
Design Patterns, Estilos e 
Padrões Arquiteturais
CAPÍTULO 8. ARQUITETURAS PARA SISTEMAS DISTRIBUÍDOS
PROF. GLADSTON JUNIO APARECIDO
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 8.1. INTRODUÇÃO AOS SISTEMAS DISTRIBUÍDOS
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceito de Sistemas Distribuídos (SD).
❑ Tipos de Sistemas Distribuídos.
❑ Principais características de SD.
❑ Desafios do desenvolvimento de SD.
Sistemas Distribuídos
• Coleção de computadores autônomos, interligados
através de uma rede de computadores e equipados
com software que permite o compartilhamento de
recursos do sistema: hardware, software e dados
[Coulouris].
• Coleção de computadores independentes que se
apresenta ao usuário como um sistema único e
coerente [Tanenbaum].
Recursos
• Termo Abstrato.
• Representa objetos de hardware:
− Discos, impressoras, etc.
• Entidades de software:
− Sistemas, arquivos, banco de dados, etc.
Tipos de Sistemas Distribuídos
• Sistemas de Computação Distribuídos;
• Sistema de Informação Distribuídos;
• Sistemas Distribuídos Pervasivos.
Exemplos
FONTE: Computer.org
Internet
Exemplos
FONTE: Folioweb.org
World Wide Web
Exemplos
FONTE: Citrix
DNS (Domain Name Service)
Exemplos
FONTE: Citrix
Clusters e Grids
Exemplos
• Sistemas de Informação:
− E-commerce;
− Logísticas;
− Banking;
− Reserva de passagens.
• Motivação para o desenvolvimento de tecnologias
paraintegração de aplicações corporativas:
− Service Oriented Architecture (SOA);
− Enterprise Application Integration (EAI);
− Enterprise Service Bus (ESB).
Características
• Execução concorrente dos componentes do sistema.
• Ausência de clock global.
• Independência de falhas.
Desafios
• Heterogeneidade.
• Escalabilidade.
• Segurança.
• Flexibilidade.
• Tratamento de Falhas.
• Concorrência.
• Transparência
Conclusão
✔ SD representam uma coleção de computadores
independentes que se apresenta ao usuário como um
sistema único e coerente.
✔ A presença do meio de comunicação acrescenta grandes 
desafios para o desenvolvimento do sistema.
02.
01.
Próxima Aula
Modelos Arquiteturais em SD.
Middlewares.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 8.2. MODELOS ARQUITETURAIS EM SD
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Modelos Arquiteturais em SD.
❑ Modelo Cliente Servidor.
❑ Modelo Peer to Peer.
Modelos Arquiteturais em SD
• Um modelo arquitetural determina como as partes ou
componentes de um Sistema Distribuído são
estruturadas e dispostas, além de determinar como é
realizado o relacionamento entre elas.
Modelos Arquiteturais em SD
• Um Sistema Distribuído é composto basicamente por
dois tipos de processos:
− Cliente: programa que solicita pedidos a um
processo servidor.
− Servidor: programa que executa operações
solicitadas pelos usuários, enviando o respectivo
resultado.
Modelos Arquiteturais em SD
• O papel de cada processo pode alternar de acordo o
fluxo de informações:
− Um servidor de banco de dados é
frequentemente um cliente de um servidor de
arquivos;
− Um navegador é um cliente dos servidores web;
− Os crawlers dos mecanismos de buscas são
clientes dos servidores web.
Cliente Servidor
• Modelo mais utilizado na prática.
• Simplicidade facilita a implementação.
• Escalabilidade limitada (servidor pode representar um
gargalo).
• Segurança concentrada no servidor e no meio de
comunicação.
Cliente Servidor
• Servidores individuais
Cliente Servidor
• Múltiplos servidores
Cliente Servidor
• Cache / Proxy
Peer to Peer
• Todos os processos podem assumir o papel de
clientes e servidores do mesmo serviço em diferentes
momentos.
• Exemplos:
− Compartilhamento de arquivos;
− Edição colaborativa de documentos.
− Blockchain.
Peer to Peer
• Maior complexidade.
• Não existe ponto único de falha.
• Maior potencial para escalabilidade.
• Heterogeneidade e segurança podem se tornar
pontos críticos.
Peer to Peer
Conclusão
✔ A escolha do modelo arquitetural correto é fator 
determinante para o sucesso de um sistema.
✔ Cliente servidor é o modelo mais utilizado e existem 
diferentes variações.
01.
Próxima Aula
Middlewares.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 8.3. MIDDLEWARES
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Conceitos e características de Middlewares.
Middleware
• Camada de software.
• Provê serviços que permitem:
− Interação entre múltiplos processos em um ou
vários computadores.
• Invocar de métodos remotamente;
• Enviar notificações de eventos;
• Replicação de dados.
Middleware
• Prover um modelo de programação homogêneo,
coeso e conveniente para os desenvolvedores.
• Simplifica e torna mais produtivo o desenvolvimento
de uma aplicação distribuída.
• Amplamente utilizados em:
− Sistemas embarcados e robótica;
− Sistemas de Informação.
− Sistemas multimídia.
Middleware
• Linguagens de programação: abstraem o hardware
(registradores, instruções de máquina, modos de
endereçamento, periféricos, etc.).
• Middleware: abstraem a rede (endereços IP, portas,
sockets, formato de mensagens, conexões, falhas,
etc.).
Middleware
Middleware
Middleware
• Principais tipos de middlewares:
− Middleware procedural / Remote Procedure Call;
− Middleware orientado a transação / transacional;
− Middleware orientado a objetos;
− Middleware orientado a mensagem;
− Middleware baseados em componentes.
Conclusão
✔ Middleware atua acima da plataforma.
✔ Middleware viabiliza e simplifica a comunicação entre os 
computadores do SD.
01.
Próxima Aula
Middlewares Orientados a 
Objetos.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 8.4. MIDDLEWARES ORIENTADOS A OBJETOS
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Middlewares Orientados a Objetos.
Objetos Locais vs Remotos
• Objetos Locais:
− Referência a ponteiros da memória.
− Disponibilizam comportamentos e dados para
outros objetos.
− Implementação independente da interface.
Objetos Locais vs Remotos
• Objetos Distribuídos:
− Referência do objeto aponta para um endereço
de rede.
− Proveem serviços (compartilhamento de
recursos).
− Apenas a interface é visível.
Middleware Orientados a Objetos
• Permite que objetos clientes possam chamar
métodos de objetos remotos com transparência de
acesso.
− Transparência de acesso: uso da mesma
sintaxe de chamadas locais.
Middleware Orientados a Objetos
• Principais Implementações:
− RMI (Remote Method Invocation).
− CORBA.
− Microsoft .Net Remoting.
− DCOM (Distributed COM).
Middleware Orientados a Objetos
• Envolve basicamente três componentes:
− Servidor de Aplicação.
− Servidor de Nomes.
− Cliente.
Servidor de Aplicação
• Cria as instâncias dos objetos remotos.
• Registra os objetos remotos.
− Registrar significa atribuir um nome que permita
o acesso ao objeto pela rede.
Servidor de Nomes
• Provê o serviço de localização de objetos remotos
(diretório).
• Funciona como um catálogo de objetos remotos.
Cliente
• Consulta o servidor de nomes para obter acesso ao
objeto remoto.
− Precisa conhecer o nome do objeto.
• Utiliza a referência de rede do objeto remoto para
realizar as chamadas remotas.
Conclusão
✔ Middlewares Orientados a Objetos permitem acessar 
objetos remotos com transparência de acesso.
✔ São necessário três elementos (servidor de aplicação, 
servidor de nomes, cliente).
01.
Próxima Aula
Demonstração de Middlewares 
Orientados a Objetos.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 8.5. DEMONSTRAÇÃO: MIDDLEWARES A ORIENTADOS OBJETOS
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Demonstração de Middlewares Orientados a Objetos.
DEMONSTRAÇÃO
Conclusão
✔ Java RMI é um dos principais middlewares para 
disponibilização e consumo de objetos remotos.
✔ Middlewares Orientados a Objetos são dependentes de 
plataforma.
✔ Middlewares Orientados a Objetos permitem que dados 
sejam transferidos na rede por valor ou por referência.
01.
Próxima Aula
Middlewares Orientados a 
Mensagens.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 8.6. MIDDLEWARES ORIENTADOS A MENSAGENS
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Middlewares Orientados a Mensagens (MOM).
Contextualização
• Provê suporte para comunicação persistente
assíncrona.
• Oferecem capacidade de armazenamento temporário
para mensagens, não exigindo que o emissor e o
receptor estejam ativos durante a transmissão da
mensagem.
• Suportam trocas de mensagens que podem levar
vários minutos em vez de alguns segundos ou
milissegundos.
Contextualização
• MOM são intermediários na comunicação por
mensagens entre dois processos.
− Não existe comunicação ponto a ponto entre os
processos.
• As principais implementações usam filas de
mensagens:
− O processo emissor insere mensagens na fila;
− O processo receptor lê as mensagens inseridas.
Contextualização
• Diversos processos podem inserir mensagens em
uma fila.
• Filas podem ser exclusivas de uma aplicação ou
compartilhadas.
• Mensagens grandes podem ser fragmentadas e
remontadas pelo sistema de forma transparente para
a aplicação.
Contextualização
• É garantido ao emissor que suas mensagens serão
registradas na fila.
• Entretanto, não há garantias de quando as
mensagens serão lidas e se serão efetivamente lidas.
• Comunicação fracamente acoplada.Contextualização
Quando Utilizar
• Quando for necessário remover a dependência de
conhecimento entre a interface de um componente da
aplicação.
• Quando se deseja executar uma aplicação sem que
todos os componentes estejam executando
simultaneamente.
• Quando o contexto operacional da aplicação
possibilita que um componente envie uma
mensagem a outro e continue funcionando sem
receber uma resposta imediata.
MOM – Arquitetura
MOM – Arquitetura
• Filas são mantidas por componentes denominados
gerentes de filas.
• Filas podem não ter ordem definidas ou seguir regras
como FIFO, LIFO ou prioridade.
MOM – Roteadores
• Componente opcional que permite:
− Encaminhar as mensagens para os gerentes de
filas ou outros roteadores.
− Realizar procedimentos secundários como
segurança e tolerância a falhas.
− Realizar comunicação multicast.
• Assumem a responsabilidade de conhecer a
topologia de rede.
• Melhoram a escalabilidade do sistema.
MOM – Roteadores
MOM – Brokers
• Permite a integração entre aplicações que utilizam
protocolos/formatos distintos.
− Realizam a conversão das mensagens com
base em regras de conversão.
• Auxiliam na integração com aplicações legadas.
MOM – Brokers
MOM – Vantagens
• Paradigma de troca de mensagens é simples, natural
e fácil de entender.
• Emissor e receptor não precisam estar ativos
simultaneamente.
• Componentes podem ser facilmente substituídos.
MOM – Vantagens
• Menor overhead de comunicação.
− Não é necessário manter uma conexão ativa.
• Mensagens podem ser criptografadas impedindo a
violação das mensagens.
MOM – Implementações
• Java Message Service (JMS).
• Advanced Message Queueing Protocol (AMQP).
• IBM WebSphere MQ.
• Apache ActiveMQ.
• Microsoft Message Queue Server (MSQS).
• Oracle Advanced Queueing (AQ).
Conclusão
✔ MOM provê suporte para comunicação persistente
assíncrona.
✔ Permitem que os componentes de software executem suas
funções sem que a outra parte esteja em execução.
✔ Contribuem para a melhoria da escalabilidade do sistema.
02.
01.
Próxima Aula
SOAP.
Web Services.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 8.7. WEB SERVICES
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ SOAP.
❑ Web Services.
❑ WSDL.
❑ UDDI.
SOAP
• Acrônimo de Simple Object Access Protocol.
• Protocolo adotado pelo W3C para troca de
mensagens na Internet.
• Originalmente desenvolvido pela Microsoft, IBM e
Lotus.
• Utiliza XML para formatação de mensagens e HTTP
para transporte de mensagens de um nó a outro.
SOAP
• SOAP especifica como representar, em XML, todas
as informações necessárias para se executar uma
chamada remota.
− Define o formato da mensagem de requisição.
− Define o formato da mensagem de retorno.
• Independente de linguagem de programação.
• As mensagens são representadas por um “envelope”.
SOAP – Envelope
• Código:
• Envelope SOAP:
Web Services
• Middleware para aplicações distribuídas:
− Comunica por meio de mensagens XML;
− Formatadas e encapsuladas de acordo com o
protocolo SOAP;
− Transportadas via HTTP.
− Interface (contrato) é definida em uma
linguagem denominada WSDL (Web Services
Description Language).
− Podem ser registrados em servidores UDDI
(Universal Description, Discovery and
Integration).
Web Services
• Aplicação cliente realiza a chamada.
• Proxy intercepta a chamada e constrói a mensagem XML de requisição.
• Listener SOAP recebe, analisa e valida a mensagem.
• Listener encaminha a requisição para o componente.
• Listener recebe o resultado, constrói e transmite o retorno.
• Proxy recebe e analisa a resposta e encaminhada ao cliente.
• Processo totalmente transparente para o cliente e o componente.
Consumidor Provedor
Aplicação 
Cliente
Proxy
SOAP
XML/HTT
P
Componente
Serviço 
Web
Listener 
SOAP
WSDL
• Linguagem para descrever a localização e a interface
de um Serviço Web:
− Nome e URL do serviço (binding information).
− Assinatura dos métodos disponíveis para
chamada remota (abstract interface).
WSDL
UDDI
• Conjunto de especificações para:
− Registro de um Serviço Web.
− Pesquisa de Serviços Web utilizando uma
interface Web ou SOAP.
• Pesquisas por um serviço podem ser realizadas em:
− Páginas brancas: contém nome e informações
de contato.
− Páginas amarelas: serviços organizados em
“categorias”.
Conclusão
✔ Web Services é um middleware para integração de 
aplicações na Web.
✔ Utiliza SOAP como protocolo de formatação e HTTP como 
protocolo de transporte.
✔ Fornece transparência de acesso.
✔ WSDL é uma linguagem baseada em XML para definição 
de contratos de serviços.
01.
Próxima Aula
Demonstração de Web Services.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 8.8. DEMONSTRAÇÃO: WEB SERVICES
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Demonstração de Web Services.
Web Services
DEMONSTRAÇÃO
Conclusão
✔ Por meio de Web Services é possível ter interoperabilidade 
de plataformas em integrações na Web.
✔ Os contratos dos serviços (WSDL) são gerados 
dinamicamente.
01.
Próxima Aula
Modelo arquitetural REST.
Design Patterns, Estilos e 
Padrões Arquiteturais
AULA 8.9. REST
PROF. GLADSTON JUNIO APARECIDO
Nesta Aula
❑ Definição de REST.
❑ Vantagens do REST.
❑ Diretrizes do REST.
REST
• Representational State Transfer é um estilo
arquitetural para aplicações Web.
− REST não é um protocolo e portanto não é
similar ao SOAP.
− REST não é um middleware e portanto não é
similar aos Web Services.
• Original proposto na tese de doutorado de Roy
Fielding.
− Autor de RFC como RFC2616 HTTP 1.1 e
RFC3986 URI.
REST
• REST propõe uma arquitetura que combina diversos
padrões:
− HTTP
− URL
− XML
− JSON
− MIME types
− Hipermídia
REST
• REST é orientado a recurso:
− Recursos: partes de uma informação;
− Mapeados por uma URI;
− Transferidos de servidor para cliente e vice
versa.
REST
O estado do cliente é alterado com base nas URL
selecionadas.
REST
• O estado da aplicação e seus comportamentos são
abstraído em recursos.
− Os recursos são únicos.
• O acesso aos recursos é padronizada por uma
interface:
− As operações permitidas são definidas pelos
métodos do HTTP (GET, POST, PUT, DELETE).
− O formato do conteúdo é definido pelo content-
type (text/html, application/json, etc.).
Vantagens
• Utiliza conceitos e tecnologias amplamente aceitos.
• Simplicidade.
• Uso da World Wide Web.
Diretrizes
• Uma arquitetura REST é regida por 6 diretrizes:
1) Paradigma Cliente Servidor:
• Cliente recuperar e persiste dados por meio
do servidor.
• Servidor deve interagir com clientes de
qualquer plataforma.
Diretrizes
• Uma arquitetura REST é regida por 6 diretrizes:
2) Stateless
• Cliente deve informar ao servidor tudo que
ele precisa para atender à requisição.
• Servidor não deve armazenar dados de
contexto do uso das requisições.
Diretrizes
• Uma arquitetura REST é regida por 6 diretrizes:
3) Uso de Cache
• Servidor deve rotular as respostas
indicando se elas podem ou não ser
armazenadas em cache.
Diretrizes
• Uma arquitetura REST é regida por 6 diretrizes:
4) Interface Uniforme
• Recursos são identificados e acessos de
forma uniforme (padronizada);
• Hypermedia As The Engine Of Application
State (HATEOAS).
Diretrizes
• Uma arquitetura REST é regida por 6 diretrizes:
5) Distribuição em camadas
• Aplicações compostas por três camadas:
− Cliente;
− Servidor;
− Intermediários.
Diretrizes
• Uma arquitetura REST é regida por 6 diretrizes:
6) Code on demand:
• Diretriz opcional.
• Propõe o download e a execução dinâmica
de código.
• Muito utilizado em SPA por exemplo.
Comunicação
• Em uma aplicação REST-ful o acesso aos recursos
tem as seguintes características:
− Endereço baseado em URI (no caso URL na
Web).
− As operações sobre os recursos (CRUD) são
mapeadas nos métodos do HTTP:
• Create: POST
• Read: GET
• Update: PUT
• Delete: DELETE