Introdução à Arquitetura de Software

Prévia do material em texto

www.labes.ufpa.br
ARQUITETURA DE SOFTWARE
INTRODUÇÃO
PROF. RODRIGO QUITES REIS 
PROF. ADAILTON MAGALHÃES LIMA
labes-ufpa, 2017 1
www.labes.ufpa.br
Agenda
• Unidade 1
– Introdução
– 1 - Arquitetura e Projeto de Software
– 2- Estilos Arquiteturais
2labes-ufpa, 2017
www.labes.ufpa.br
Parte 1
Arquitetura e Projeto de Software
labes-ufpa, 2017 3
www.labes.ufpa.br
Introdução
• Expressões que indicam a adoção de um modelo 
arquitetural
– Sistemas de 3 Camadas...
– Uso do Padrão de Projeto X...
– ...Padrão Fachada...
– Uso da Arquitetura MVC (Modelo-Visão-Controlador)
– ...
4labes-ufpa, 2017
www.labes.ufpa.br
Arquitetura: o que aprender da 
construção civil?
5
Capa de livro
clássico na área
de Arquitetura de
software
labes-ufpa, 2017
www.labes.ufpa.br
Arquitetura: o que aprender da 
construção civil?
6labes-ufpa, 2017
www.labes.ufpa.br
Arquitetura: o que aprender da 
construção civil?
7labes-ufpa, 2017
www.labes.ufpa.br
Arquitetura de Software
Amostra
8
Enactment
GenericDataSource ContractManagement
DiscoverDataLocation SystemInformationManagement
DataChannel MessagesChannel DiscoveryChannel DataExchangeFormat
NotificationInterface
Jxta Channels IMPL (Socket, RMI, WebServices, ....)
ARQUITETURA EM CAMADAS DA EXECUCAO DISTRIBUIDA NO SISTEMA P2Process
O nivel de abstracao cresce de baixo para cima.
No nivel inferior encontram-se os componentes que utilizam diretamente a API JXTA.
No nivel superior esta a interface de execucao de modelos de processos do sistema.
OBS: Dentro de cada pacote há uma descrição breve da funcionalidade de cada camada e componente.
A
B
C
D
E
labes-ufpa, 2017
www.labes.ufpa.br
Arquitetura de Software
Amostra
9labes-ufpa, 2017
www.labes.ufpa.br
Arquitetura de Software
Amostra
10
under 
definition
defined
valid
finished
manager started contract defini...
manager finished contract definition / generate contract validation...
contract defined and isValid()==...
not valid
contract defined and isValid()==f...
supplier defines that all activitities are concl...
isValid()==false, becaus e condition has changed to f...
isValid()==true, because condition has changed to ...
supplier defines that all activitities are concl...labes-ufpa, 2017
www.labes.ufpa.br
O que é Arquitetura de Software?
• A arquitetura de software de um programa ou 
sistema computacional é a estrutura ou estruturas 
do sistema que abrange os componentes de 
software, as propriedades externamente visíveis 
destes componentes e as relações entre eles
11
Bass et al apud Pressman
labes-ufpa, 2017
www.labes.ufpa.br
Por que Arquitetura de Software?
• A arquitetura não é software operacional. Porém, 
permite a um Engenheiro de Software:
– Analisar a adequação de um projeto no atendimento dos 
requisitos estabelecidos
– Considerar alternativas arquiteturais em um estágio em 
que as mudanças do projeto ainda são fáceis e baratas
– Reduzir os riscos associados com a construção de software
12labes-ufpa, 2017
www.labes.ufpa.br
Por que Arquitetura de Software?
• Facilitador da comunicação entre os envolvidos com 
um sistema
• Destaca decisões iniciais de projeto que vão ter um 
impacto profundo em todo o trabalho de se segue
• Modelo relativamente pequeno, intelectualmente 
inteligível de como o sistema é estruturado e como 
seus componentes trabalham em conjunto
13labes-ufpa, 2017
www.labes.ufpa.br
Como começar?
14
A parte de imagem com identificação de relação rId3 não foi encontrada no arquivo.
Spec
A parte de imagem com identificação de 
relação rId3 não foi encontrada no arquivo.
A parte de imagem com identificação de relação rId3 não 
foi encontrada no arquivo.
A parte 
de 
imagem 
com 
identific
ação de 
relação 
rId3 
não foi 
encontr
ada no 
arquivo. Prototype
Design
modeling
labes-ufpa, 2017
www.labes.ufpa.br
Princípios de Projeto (1)
1. O projeto não pode ser “bitolado”
Um bom projetista deve considerar abordagens alternativas, julgando cada uma com base 
nos requisitos do projeto
2. O projeto deve ser relacionável ao modelo de análise
Como um único elemento do projeto pode estar relacionado com vários requisitos, é 
necessários ter recursos para estabelecer como os requisitos são satisfeitos pelo 
projeto
3. O projeto não deve reinventar a roda
Sistemas são construídos usando um conjunto de padrões de projeto, muitos dos quais 
estão descritos amplamente na literatura. Os padrões de componentes COTS devem 
ser escolhidos como alternativa à reinvenção
4. O projeto deve “minimizar a distância intelectual” entre o software e 
o problema, tal como existe no mundo real
O software, sempre que possível, deve imitar a estrutura do domínio do problema
5. O projeto deve exibir uniformidade e integração
Um projeto é uniforme se parece que uma única pessoa desenvolveu a coisa toda. Regras 
de estilo e formato devem ser definidas para uma equipe de projeto antes que o 
trabalho inicie.
Um projeto é integrado se houver cuidado na definição de interfaces entre os seus 
componentes
15labes-ufpa, 2017
www.labes.ufpa.br
Princípios de Projeto (2)
6. O projeto deve ser estruturado para acomodar modificação
7. O projeto deve ser estruturado para degradar suavemente, mesmo 
quando dados, eventos ou condições de operações aberrantes são 
encontradas
8. Projeto não é codificação. Codificação não é projeto
– Mesmo quando os mais detalhados projetos procedimentais são criados 
para os componentes de programa, o nível de abstração de projeto é maior 
que o do código-fonte.
9. O projeto deve ser avaliado quanto à qualidade, à medida que é criado, 
não depois do fato
– Uma variedade de conceitos e medidas de projeto está disponível para 
auxiliar o projetista na avaliação de qualidade.
10. O projeto deve ser revisto para minimizar erros conceituais (semânticos)
– A equipe de projeto deve garantir que os principais elementos conceituais 
(omissões, ambigüidade e inconsistência) tenham sido cuidados antes de se 
preocupar com a sintaxe do modelo
16labes-ufpa, 2017
www.labes.ufpa.br
Princípios de Projeto (3)
• 11. Deve considerar de maneira detalhada o 
atendimento aos requisitos não-funcionais
– Segurança
– Escala
– Tempo de resposta
– Plataforma operacional
– Disponibilidade: 24 x 7
– ...
17labes-ufpa, 2017
www.labes.ufpa.br
Conceitos fundamentais do 
projeto de software
labes-ufpa, 2017 18
www.labes.ufpa.br
Conceitos Fundamentais
• Abstração - dados, procedimento e controle
• Refinamento - elaboração dos detalhes de todas as 
abstrações
• Modularidade - criação de compartimentos para dados e 
funções
• Arquitetura - estrutura completa do software
– Propriedades estruturais
– Propriedades Extra-estruturais
– Estilos e padrões
• Procedimento - os algoritmos que fornecem as funções 
desejadas
• Ocultamento da Informação - interfaces definidas e 
controladas
19labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Abstração
– De dados
20
porta
Definido como uma estrutura de dados
fabricante
modelo
tipo
material
peso
mecanismo de abertura
preço
labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Abstração
– Procedimental
21
abrir
Definido tendo o “conhecimento” do
do objeto que está associado com Abrir
Detalhamento
algorítmico
labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Refinamento
22
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Modularidade
– Facilidade para construir, facilidade para modificar, 
facilidade para conserto, ...
23
A 
par
te 
de 
ima
ge
m 
co
m 
ide
ntif
ica
çã
o 
de 
rel
açã
o 
rId
3 
nã
o 
foi 
en
co
ntr
ad
a 
no 
arq
uiv
o.
A parte de 
imagem com 
identificação de 
relação rId3 não 
foi encontrada no 
arquivo.
A parte de imagem 
com identificação 
de relação rId3não 
foi encontrada no 
arquivo.
A parte de imagem 
com identificação 
de relação rId3 não 
foi encontrada no 
arquivo.
A parte de imagem com identificação de relação rId3 não foi encontrada 
no arquivo.
A parte de imagem com identificação de relação rId3 não foi encontrada no arquivo.
A parte de imagem com identificação de relação rId3 não foi encontrada no arquivo.
A parte de imagem com 
identificação de relação 
rId3 não foi encontrada 
no arquivo.
A parte de imagem com 
identificação de relação 
rId3 não foi encontrada 
no arquivo.
A 
part
e de 
imag
em 
com 
ident
ifica
ção 
de 
relaç
ão 
rId3 
não 
foi 
enco
ntra
da 
no 
arqui
vo.
A 
parte 
de 
imag
em 
com 
identi
ficaçã
o de 
relaç
ão 
rId3 
não 
foi 
enco
ntrad
a no 
arqui
vo.
A parte 
de 
image
m com 
identifi
cação 
de 
relação 
rId3 
não foi 
encont
rada 
no 
arquivo
.
A parte 
de 
image
m com 
identifi
cação 
de 
relação 
rId3 
não foi 
encont
rada no 
arquivo
.
A parte de imagem com 
identificação de relação 
rId3 não foi encontrada 
no arquivo.
A parte de imagem com 
identificação de relação 
rId3 não foi encontrada 
no arquivo.
A parte de imagem com identificação de relação rId3 não foi encontrada 
no arquivo.
A parte de imagem com identificação de relação rId3 não 
foi encontrada no arquivo.
A parte de imagem com identificação de relação rId3 
não foi encontrada no arquivo.
A parte de imagem com identificação de relação 
rId3 não foi encontrada no arquivo.
labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Modularidade
24
Qual o número “correto” de módulos
para um projeto de software específico?
Quantidade “ótima”
de módulos
custo de
software
Quantidade de módulos
module
integration
cost
Custo de desenvolvimento de módulo
labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Modularidade
25
MODULE
What's 
inside??
How big 
is it??
Qual o tamanho “correto” dos módulos?
labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Modularidade à Independência
– Coesão
• Medida da identidade funcional de um módulo
• I.e., módulo realiza uma única função
– Acoplamento
• Grau de dependência entre módulos
– Ideal: coesão alta e acoplamento baixo
– Obs: apesar destas medidas terem surgido para técnicas 
Estruturas, são também aplicáveis em métodos OO
26labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Modularidade: Coesão
– Tipos:
• Funcional (caixa preta, a melhor) – uma e somente uma função 
identificável.
• Seqüencial (várias atividades – que precisam ser - executadas em 
seqüência, e os dados fluem de uma atividade para outra)
• Comunicacional (atividades usam a mesma entrada e a mesma saída)
• Procedural (atividades diferentes, com controle – e não dados -
fluindo de uma para outra)
• Temporal (várias funções executadas no mesmo tempo. Ex: 
inicialização)
• Lógica (várias funções semelhantes porém independentes)
• Coincidental (a pior)
27labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Modularidade: Coesão
– Como conseguir coesão funcional – descrever o módulo 
evitando
• Sentença composta, vírgula, mais de 1 verbo (seqüencial ou 
comunicacional)
• Palavras que se relacionem com o tempo (temporal)
• Predicado da sentença com mais de 1 objeto
28labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Exercício
29labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Modularidade: Acoplamento
– nível de inter-dependência entre os módulos de um programa de 
computador. Quanto maior for o acoplamento menor será o nível 
de coesão. (Wikipedia)
– Tipos
• Acoplamento de dados: troca de parâmetros (o melhor)
• Acoplamento de imagem (estrutura de dados comum utilizada 
parcialmente em vários módulos)
• Acoplamento de controle - exemplo: flags indicando o que um 
módulo deve fazer (intermediário)
• Acoplamento comum (módulos acessam área de dados comum)
• Acoplamento de conteúdo: se um módulo faz referência ao interior 
do outro (o pior)
30labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
31labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Arquitetura
32
“The overall structure of the software and the 
ways in which that structure provides 
conceptual integrity for a system.” [SHA95a]
Propriedades Estruturais. Este aspecto da representação de projeto 
arquitetural define os componentes de um sistema (e.g., módulos, objetos, 
filtros) e a maneira pela qual estes componentes são empacotados e interagem 
entre si.
Propriedades Não-Funcionais. A descrição do projeto arquitetural deve tratar 
como a arquitetura atende os requisitos de performance, capacidade, 
capacidade, segurança, adaptação e outras características do sistema
Famílias de sistemas relacionados. O projeto arquitetural deve ser baseado 
em reutilização e reutilizável
labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Ocultamento da Informação
– Information Hiding, Parnas 1972
33
módulo
interface
controlada
”segredo"
• algoritmo
• estrutura de dados
• detalhe da interface externa
• política de alocação de recurso
clientes
Decisão específica de projeto labes-ufpa, 2017
www.labes.ufpa.br
Conceitos Fundamentais
• Ocultamento da Informação
– Reduz a ocorrência de “efeitos colaterais”
– Limita o impacto global das decisões locais de projeto
– Enfatiza comunicação através de interfaces controladas
– Desencoraja o uso de dados globais
– Leva ao encapsulamento - um atributo de projeto de alta 
qualidade
– Resulta em qualidade de software
34labes-ufpa, 2017
www.labes.ufpa.br
Agenda
• Introdução
• 1 - Arquitetura e Projeto de Software
• 2- Estilos Arquiteturais
• 3 - Padrões de Projeto
• 4 - Estilo em Camadas e MVC – detalhamento
• Exercícios e trabalhos práticos
35labes-ufpa, 2017
www.labes.ufpa.br
Parte 2
Estilos Arquiteturais
nPressman, 2012
nMendes, 2002
nAn Introduction to Implicit Invocation Architectures - Benjamin Edwards (ben@ben-
edwards.com)
nGarlan & Shaw: An Introduction to Software Architecture -
http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf
labes-ufpa, 2017 36
mailto:ben@ben-edwards.com
www.labes.ufpa.br
Referências bibliográficas
37labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
38
Arquitetura = Componentes
+
Conectores
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Arquitetura é composta de:
– Subsistemas ou componentes
• Responsáveis pelo comportamento do sistema
• Exemplos:
– Carrinho de compras, gestor de transações concorrentes, banco de 
dados
– Padrões de Conexão
• Possibilitando vários tipos de interação e compartilhamento de 
informação entre esses componentes
• Exemplos:
– Chamadas de métodos, consultas SQL, requisições HTTP
39labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Cada estilo descreve uma categoria de sistemas que 
engloba:
– Um conjunto de componentes (um banco de dados, 
módulos de interface) que realiza uma função requerida 
pelo sistema
– Um conjunto de conectores que fornecem “comunicação, 
coordenação e cooperação” entre os componentes
– Restrições que definem como os componentes podem ser 
integrados para compor um sistema
– Modelos semânticos que permitem ao projetista entender 
as propriedades gerais do sistema pela análise das 
propriedades conhecidas de suas partes
40labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Pipes & Filters
• Chamada e Retorno
• Orientadas a Objeto
• Camadas
• Centrada em Dados
• Invocação implícita
41labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Centradas em Fluxo de dados ou Pipes and Filters
42
Exemplo: sistemas workflow
Considera uma rede pela qual flui
dados de uma extremidade (origem) à
outra (destino)
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Centradas em Fluxo de dados ou Pipes and Filters: 
Aplicação em compiladores (1)
43
Análise Léxica AnáliseSintática Otimização
Análise
Semântica
Geração de
código
2ª geração) Código intermediário para atender portabilidadeentre plataformas
1ª geração)
Análise Léxica AnáliseSintática
Análise
Semântica Otimização
Geração de
código
Função de análise Função de síntese
Geração de
Código
Intermediário
Análise Léxica AnáliseSintática
Análise
Semântica Otimização
Geração de
código
Função de análise Função de síntese
Geração de
Código
Intermediáriolabes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Pipes and Filters: Compiladores (2)
44
Análise Léxica
Análise
Sintática
Otimização
Análise
Semântica
Geração de
código
Geração de
Código
Intermediário
Tabela de símbolos de
estrutura sintática
editor
Outras
ferramentas
Integração com editores e
outras ferramentas
labes-ufpa, 2017
www.labes.ufpa.br
45
DTE com seqüência de estados
e ações para TCC1 e TCC2.
(CBCC)labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Pipes & Filters
• Chamada e Retorno
• Orientadas a Objeto
• Camadas
• Centrada em Dados
• Invocação implícita
46labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Chamada e Retorno
– Estrutura relativamente fácil de ampliar e mudar
– Subestilos:
• Programa Principal/Subprograma
• Chamada de Procedimentos Remotos (SD)
47
Exemplo: middleware para
programação distribuída
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Chamada e Retorno
– Aplicações:
• Sistemas distribuídos com troca de mensagens
• RMI, CORBA, WebServices, entre outros
48
cliente
Método remoto
execução
 interrom
pida
execução reinicia
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Pipes & Filters
• Chamada e Retorno
• Orientadas a Objeto
• Camadas
• Centrada em Dados
• Invocação implícita
49labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Orientado a Objeto
– Classes encapsulam dados e operações
– Interfaces estabelecem contratos e associação de baixo 
acoplamento
– Comunicação e coordenação entre componentes 
conseguida através de mensagens
50
 : Atendente
comp : 
Computador
 : Loja
Tela Inserção 
Computador
1: inserirComputador(loja)
2: criar(número)
3: comp
4: recuperar(loja)
5: loja
6: inserir(comp)
7: computador inserido
8: computador inserido
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Orientado a Objeto
– Classes e Associações
• Implementação de Tipos Abstratos de Dados (entidades 
independentes)
• Mapeamento com conceitos do domínio do problema
• Troca de mensagens à menor acoplamento que uso de variáveis 
compartilhadas
• Classes podem ser reutilizadas
• Objetos podem ser distribuídos e executar em seqüencialmente 
ou em paralelo 
51labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Orientado a Objetos
– Mensagem
• Comunicação entre obj1 e obj2 (à)
– obj2.msg(); // executada no contexto de obj1
• Destinatário explicitamente declarado (ruim)
52labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
53
 : Usuário : Usuário
Controlador
Relatórios
Controlador
Relatórios
 : 
Equipe
 : 
Equipe
 : Jogo : Jogo : OcorrênciasJogoEquipe : OcorrênciasJogoEquipe
1: obterGolsAno
2: obterEquipes( )
3: equipes
4: equipes
5: obterQuantidadeGols(equipe, ano)
6: obterJogos(Equipe, ano)
7: jogosEquipeAno
8: obterGols(Equipe, Jogo)
9: quantidadeGols
repetir enquanto houver jogosEquipeAno
10: totalGols
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Orientado a Objetos
– Interfaces
• Representam responsabilidades em alto nível de abstração
• Baixo acoplamento baixo: classes não se conhecem
• Facilita a manutenção
54labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Orientado a Objetos
– Interface
55labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Orientado a Objetos
– Frameworks - (wikipedia, pt)
• estrutura de suporte definida em que um outro projecto do 
software pode ser organizado e desenvolvido.
• Pode incluir programas de apoio, bibliotecas de código, linguagens 
de script e outros softwares para ajudar a desenvolver e juntar 
diferentes componentes do seu projecto. 
• Especificamente em OO, framework é um conjunto de classes com 
objetivo de reutilização de um design, provendo um guia para uma 
solução de arquitetura em um domínio específico de software.
• Framework se diferencia de uma simples biblioteca (toolkit), pois 
esta se concentra apenas em oferecer implementação de 
funcionalidades, sem definir a reutilização de uma solução de 
arquitetura (design).
56labes-ufpa, 2017
http://pt.wikipedia.org/wiki/Classe_(programa%C3%A7%C3%A3o)
www.labes.ufpa.br
Estilos Arquiteturais
• Orientado a Objetos
– Possibilita (todos) os estilos arquitetônicos descritos
57labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Pipes & Filters
• Chamada e Retorno
• Orientadas a Objeto
• Camadas
• Centrada em Dados
• Invocação implícita
58labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Camadas
59
¨ Inspirado em 
Sistemas 
Operacionais
¨Utilizado hoje para 
segmentar IU, Lógica 
da aplicação, e BD 
(normalmente)
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Camadas
60
http://www.ime.usp.br/~andrers/aulas/bd2005-1/img/arquitetura_n_camadas.jpg
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
61
http://atlas-connect-forum.web.cern.ch/Atlas-connect-forum/SDP/layers.gif
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Camadas
– Número de camadas depende da funcionalidade a ser oferecida pelo 
sistema
– Definição de critérios de abstração para agrupar subtarefas na 
composição de uma camada
– Critérios: persistência, interação com usuário, distribuição, etc.
– Vantagem: flexibilidade
– Desvantagem: o desempenho fica comprometido face à necessidade 
de um caso de uso passar por várias camadas
– Desafio do projeto em camadas: encontrar equilíbrio entre número de 
camadas x tempo de resposta x outros requisitos não-funcionais
62labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Camadas
– Protocolos de redes de 
computadores
63
física
enlace
rede
transporte
sessão
apresentação
aplicação
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Camadas
– Desenho de aplicação “aberta”
64
física
enlace
rede
transporte
sessão
apresentação
aplicação
física
enlace
rede
transporte
sessão
apresentação
aplicação protocolo da camada 7
protocolo da camada 6
protocolo da camada 5
protocolo da camada 4
protocolo da camada 3
protocolo da camada 2
protocolo da camada 1
Sistema X Sistema Y
física
enlace
rede
transporte
sessão
apresentação
aplicação
física
enlace
rede
transporte
sessão
apresentação
aplicação protocolo da camada 7
protocolo da camada 6
protocolo da camada 5
protocolo da camada 4
protocolo da camada 3
protocolo da camada 2
protocolo da camada 1
Sistema X Sistema Y
Descrição de um protocolo público,
onde cada camada estabelece uma
interface para conversar com
Componentes da camada
correspondente.
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Pipes & Filters
• Chamada e Retorno
• Orientadas a Objeto
• Camadas
• Centrada em Dados
• Invocação implícita
65labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Centradas em Dados
– Repositório (passivo) e Blackboard (ativo)
– Usado quando um sistema é descrito como um armazém 
centralizado de dados que se comunica com um número 
de clientes
– Vantagem: Fácil de administrar
– Desvantagem: Dificuldade em identificar 
erros/dependências
66labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Centradas em Dados - Repositório
– Acesso a um repositório com dados comuns para os clientes
– Componentes-clientes podem ser modificados ou adicionados sem 
preocupação com os outros
67
Repositório
de dados
Software do
cliente
Software do
cliente
Software do
cliente
Software do
cliente
Software do
cliente
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Centradas em Dados
– Baseada em SGBDs “ricos”
• Pode ser visto como um repositório passivo ou blackboard ativo 
– Stored Procedures e triggers podem serusados para notificar clientes
• recursos de programação, ferramentas para geração de telas e 
relatórios, tipos definidos por usuários, ...
• Por exemplo: Oracle, DB2
– Vantagem:
• simplifica o desenvolvimento de ferramentas diversas, 
independentes
– Desvantagem:
• Dependência de um produto/tecnologia/fornecedor.
68labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Pipes & Filters
• Chamada e Retorno
• Orientadas a Objeto
• Camadas
• Centrada em Dados
• Invocação implícita
69labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Invocação Implícita (baseada em eventos)
– Objetivo principal: baixo acoplamento
– Funcionamento:
• Ao invés de invocar um procedimento diretamente, um 
componente pode anunciar um ou mais eventos
• Outros componentes registram o interesse no evento
• Quando um evento é anunciado, o sistema por si só invoca os 
procedimentos registrados pelo evento. 
• Portanto, um evento implicitamente causa a invocação de 
procedimentos em diversos outros módulos
70labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Invocação 
Implícita
71labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Invocação implícita
– Diferença com relação à invocação explícita:
• Os componentes do sistema usam eventos para se comunicar 
entre si.
• Os conectores são ligações fracas entre eventos e métodos dos 
componentes, os quais podem ser (re-)definidos em tempo de 
execução.
72labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Invocação implícita
– Exemplo: framework
• Fluxo de controle determinado pelo framework
• O código do framework invoca o código adicionado
73
Framework
Código do usuário
Fluxo de Controle
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Invocação implícita
– Tipicamente implementado com o padrão Observer
74
http://en.wikipedia.org/wiki/Observer_pattern
labes-ufpa, 2017
www.labes.ufpa.br
Estilos Arquiteturais
• Recado Final
– Leitura adicional é necessária para observar exemplos de 
aplicações
• Garlan e Shaw é uma ótima leitura
– Arquiteturas híbridas
• Invariavelmente um sistema adotada mais de um estilo 
arquitetural simultâneo
75labes-ufpa, 2017