ARQUITETURAS E PADRÕES DE SOFTWARE IV

Prévia do material em texto

Arquiteturas e 
Padrões de Software
Responsável pelo Conteúdo:
Prof. Me. Wilson Vendramel
Revisão Textual:
Prof.ª M.ª Sandra Regina Fonseca Moreira
Padrões Arquiteturais
Padrões Arquiteturais
 
 
• Entender a aplicação de padrões arquiteturais no desenvolvimento de sistemas de software.
OBJETIVO DE APRENDIZADO 
• Estilos Arquiteturais;
• Padrões Arquiteturais;
• Padrão Arquitetural MVC;
• Arquitetura em Camadas;
• Arquitetura Cliente-Servidor;
• Arquitetura de Sistemas de Informação.
UNIDADE Padrões Arquiteturais
Estilos Arquiteturais
A Unidade anterior descreveu os padrões de software como uma prática comum e 
adequada que busca o reuso e a construção de sistemas de software de qualidade, lem-
brando que esses padrões são aplicáveis no decorrer do processo de desenvolvimento de 
software como padrões de projeto e padrões de arquitetura e ainda enfatizou o entendi-
mento da aplicação de padrões de projeto. Já o foco desta unidade é o entendimento dos 
padrões arquiteturais. Vale recordar que esses padrões são técnicas que apoiam o reuso 
de software no nível de abstração, no qual o software não é reutilizado diretamente, em 
vez disso, o conhecimento das abstrações de sucesso é aplicado no projeto de software 
em questão.
Por que a aplicação de padrões é tão importante no projeto (design) de software e, conse-
quentemente, na construção do sistema?
Antes de mais nada, é importante relembrar que o projeto orientado a objetos é 
constituído por duas atividades principais: o projeto de arquitetura e o projeto detalhado. 
Além disso, a aplicação de padrões é uma das atividades primordiais do projeto orien-
tado a objetos.
Um dos objetivos do projeto (design) de software é obter um quadro arquitetural de 
um sistema de software para representar a organização a partir da qual atividades mais 
detalhadas de projeto são direcionadas, incluindo um conjunto de padrões arquiteturais 
que possibilite ao engenheiro de software reusar conceitos em nível de projeto. Além 
disso, as vantagens da construção de produtos de software com base em padrões como 
técnica para o desenvolvimento de software já são comprovadas pela comunidade de 
engenharia de software (PRESSMAN; MAXIM, 2016). O projeto baseado em padrões define 
uma “nova maneira de pensar” (SHAW, 2005 apud PRESSMAN; MAXIM, 2016, p. 354).
Importante!
Segundo Christopher Alexander, “Cada padrão descreve um problema que ocorre repeti-
damente em nosso ambiente e, então, descreve o núcleo da solução para esse problema 
de forma que podemos usar a solução milhões de vezes sem jamais fazê-lo da mesma 
forma.” (PRESSMAN; MAXIM, 2016, p. 233).
É importante salientar que os padrões de software não são elementos independentes. 
Os padrões de projeto, por exemplo, encontram-se em um nível de abstração elevado, 
mas influenciam a maneira pela qual outros padrões serão aplicados em níveis de abs-
tração mais baixos. Além disso, os padrões em geral colaboram uns com os outros. 
Ao selecionar um padrão de arquitetura, ele pode influenciar os padrões de projeto esco-
lhidos no nível de componentes. Da mesma forma, ao selecionar um projeto específico 
para interfaces, muitas vezes será obrigatório utilizar outros padrões que cooperam com 
o referido projeto (PRESSMAN; MAXIM, 2016).
8
9
 Os melhores projetistas de qualquer área têm uma capacidade extra-
ordinária de vislumbrar padrões que caracterizam um problema e pa-
drões correspondentes que podem ser combinados para criar a solução. 
(PRESSMAN; MAXIM, 2016, p. 354)
Uma vez estando ciente da importância da aplicação de padrões durante o projeto de 
software, surge a pergunta: por que adotar estilos arquiteturais?
De forma sintetizada, um estilo de arquitetura propicia a organização geral dos compo-
nentes de um sistema, simplificando assim o projeto arquitetural de software. Não menos 
importante, também define regras e restrições sobre o uso combinado desses componentes.
Segundo Sommerville (2019), a intenção de um estilo ou padrão arquitetural é con-
templar questões relacionadas às decisões de projeto de arquitetura (vide Figura 3 da 
unidade “Contexto e Visões de Arquitetura”). Cabe aqui relembrar três dessas questões 
e trazer respostas para elas:
• Qual será a abordagem fundamental utilizada para estruturar o sistema? É impor-
tante escolher a estrutura mais adequada, como cliente-servidor ou em camadas, 
que vai permitir o cumprimento dos requisitos do sistema de software;
• Qual estratégia será utilizada para controlar a operação dos componentes do siste-
ma? Durante o processo de modelagem de controle, é necessário tomar decisões 
sobre como a execução de componentes deve ser controlada, desenvolvendo um 
modelo geral dos relacionamentos de controle entre as diversas partes do sistema;
• Como os componentes estruturais no sistema serão decompostos em subcomponen-
tes? Para decompor unidades estruturais do software, é preciso decidir sobre a 
estratégia para a decomposição de componentes em subcomponentes.
 Por conta da estreita relação entre os requisitos não funcionais e a arquitetura do software, 
o estilo e a estrutura da arquitetura particular a ser escolhida para um software devem depen-
der dos requisitos não funcionais do sistema de software (SOMMERVILLE, 2019).
Percebe-se que os termos estilo e padrão são abordados de forma similar dentro do 
contexto de projeto de software. Diante disso, eis aqui uma indagação: há diferença en-
tre adotar um estilo ou um padrão para uma arquitetura de software?
Esse tema é bastante discutível, não havendo uma exatidão na resposta para essa 
pergunta. Alguns autores tratam os conceitos de forma semelhante, outros já entendem 
que há diferença, mesmo que sutil, entre estilos e padrões de arquitetura.
 A arquitetura um sistema de software pode se basear em um determinado 
padrão ou estilo de arquitetura (esses termos acabaram ganhando o mes-
mo significado). (SOMMERVILLE, 2019, p. 151)
No âmbito da arquitetura de software, é possível entender de forma branda que o 
conceito de estilo tem um sentido mais amplo, visando a organização global de um sis-
tema de software, e que o conceito de padrão é mais específico, cujo propósito é definir 
uma granularidade na solução em termos de componentes (módulos ou subsistemas) e 
seus relacionamentos. Vale ressaltar que o entendimento apresentado aqui não buscar 
9
UNIDADE Padrões Arquiteturais
trazer uma verdade absoluta sobre a questão levantada, apenas uma possibilidade de 
diferenciação entre estilo e padrão.
Uma diferença entre estilos e padrões pode ser observada no artigo “Uma olhada rápida 
nos estilos e padrões arquiteturais”, disponível em: https://bit.ly/2MBgz7X
Quando estudamos estilos arquiteturais, é muito difícil não elencar a importante publi-
cação “An Introduction to Software Architecture”, de David Garlan e Mary Shaw, dispo-
nível em: https://bit.ly/36VZBYC
Alguns estilos arquiteturais serão apresentados a partir da próxima seção desta uni-
dade. Cabe realçar que esta unidade trata os conceitos de estilo e padrão de forma aná-
loga, ou seja, com o mesmo significado no contexto da arquitetura de software.
Padrões Arquiteturais
A arquitetura de um software pode se basear em um determinado padrão ou estilo de 
arquitetura. “Um padrão de arquitetura é uma descrição de uma organização de sistema” 
(GARLAN; SHAW, 1993, apud SOMMERVILLE, 2019, p. 151) como, por exemplo, 
uma organização cliente-servidor, ou uma arquitetura em camadas. Os padrões arquite-
turais capturam a essência de uma arquitetura comumente usada no desenvolvimento de 
diferentes sistemas de software. Ao tomar decisões sobre a arquitetura de um software, 
é significativo conhecer determinados padrões, bem como saber onde eles podem ser 
adotados e quais são suas vantagens e desvantagens (SOMMERVILLE, 2019).
Os padrões de arquitetura foram propostos nos anos 1990 com o nome 
‘estilos de arquitetura’ (SHAW; GARLAN, 1996). Uma série bem detalha-
da de manuais, em cinco volumes, sobrearquitetura de software orientada 
a objetos, foi publicada entre 1996 e 2007 (BUSCHMANN et al., 1996; 
SCHMIDT et al., 2000; BUSCHMANN; HENNEY; SCHMIDT, 2007a, 
2007b; KIRCHER; JAIN, 2004). (SOMMERVILLE, 2019, p. 155)
Um padrão arquitetural pode ser pensado como uma descrição abstrata, estilizada, 
de boas práticas experimentadas e testadas em diferentes sistemas e ambientes, por-
tanto, um padrão de arquitetura deve descrever uma organização sistêmica bem-suce-
dida com base em experiências obtidas do histórico de desenvolvimento de produtos 
de software (SOMMERVILLE, 2019). 
10
11
Importante!
“Padrões e Linguagens de Padrões são maneiras de descrever as melhores práticas, os 
bons projetos e capturar a experiência de uma maneira que viabilize a reutilização des-
sas experiências por outras pessoas” (SOMMERVILLE, 2019, p. 187).
Resumindo, a aplicação de um padrão arquitetural facilita o reuso de soluções arqui-
teturais de sucesso e ajuda na decomposição do sistema de software em partes menores, 
especificamente componentes (módulos ou subsistemas) de modo organizado.
De ntre os diversos padrões arquiteturais adotados no desenvolvimento de software, 
alguns são frequentemente usados na construção de diferentes tipos de sistema de 
software e capturam os bons princípios de projeto de arquitetura, podendo citar aqui 
os seguintes padrões: arquitetura MVC, arquitetura em camadas, arquitetura de repo-
sitório, arquitetura cliente-servidor e arquitetura de dutos e filtros (pipes and filters) 
(SOMMERVILLE, 2019).
Dentre os padrões mencionados, quais padrões foram elencados nesta unidade?
As próximas seções apresentam o padrão arquitetural MVC, o padrão de arquitetura 
em camadas e o padrão de arquitetura cliente-servidor com uma extensão para a arqui-
tetura orientada a serviços. 
Vale mencionar que diferentes estilos arquiteturais podem ser integrados no projeto 
arquitetural de um produto de software. A maioria dos sistemas de software de grande 
porte não segue apenas um padrão de arquitetura, desse modo, dois ou mais estilos ar-
quiteturais são adotados de forma conjunta, onde cada componente da arquitetura pode 
seguir um determinado padrão. A combinação de diversos estilos arquiteturais resulta 
nas chamadas Arquiteturas Heterogêneas.
Uma fonte de informações sobre os padrões e linguagens de padrões . 
Disponível em: https://bit.ly/3q5gkAo
Padrão Arquitetural MVC
O padrão Modelo-Visão-Controlador, do inglês Model-View-Controller (MVC) é um 
padrão de arquitetura de software que especifica a interação entre objetos de interface 
com o usuário e os demais objetos de uma aplicação. Esse padrão arquitetural é comu-
mente utilizado para separar as responsabilidades entre a lógica da apresentação e a 
lógica da aplicação (BEZERRA, 2015). 
11
UNIDADE Padrões Arquiteturais
O Quadro 1 descreve o padrão MVC aplicado como base no gerenciamento de inte-
ração em sistemas de software baseados em Web.
Quadro 1 – O padrão MVC (Modelo-Visão-Controlador)
Descrição
Separa a apresentação e a interação dos dados do sistema. O sis-
tema é estruturado em três componentes lógicos que interagem 
entre si. O componente Modelo gerencia os dados do sistema e as 
operações a ele associadas. O componente Visão define e gerencia 
como os dados são apresentados ao usuário. O componente Con-
trolador gerencia a interação do usuário (por exemplo, pressiona-
mento de teclas, cliques de mouse etc.) e passa essas interações 
para Visão e Modelo.
Quando é usado
É utilizado quando há várias maneiras de visualizar e interagir 
com os dados. Também é utilizado quando os requisitos futuros 
para interação e apresentação dos dados são desconhecidos.
Vantagens
Permite que os dados sejam alterados independentemente de sua 
representação e vice-versa. Apoia a apresentação dos mesmos da-
dos de maneiras diferentes, exibindo as alterações feitas em uma 
representação em todas as demais.
Desvantagens Pode envolver mais código e aumentar sua complexidade quando o modelo de dados e as interações forem simples.
Fonte: Adaptado de SOMMERVILLE, 2019, p. 155
Visando apresentar a organização dos três elementos que compõem o padrão MVC e 
suas devidas interações, a Figura 1 exibe uma visão conceitual desse padrão arquitetural.
Mudança
de estado
Controlador
• Mapeia as ações do usuário 
com atualizações do modelo;
• Seleciona visão.
• Encapsula o estado da aplicação;
• Noti�ca a visão das mudanças
de estado.
• Renderiza o modelo;
• Requisita atualizações do modelo;
• Envia eventos do usuário para o controlador.
Visão
Modelo
Seleção 
de visão
Eventos 
do usuário
Noti�cação
de mudança Consulta de estado
Figura 1 – A organização do MVC (Modelo-Visão-Controlador)
Fonte: Adaptada de SOMMERVILLE, 2019, p.156
O padrão MVC permite a separação da interface de usuário da funcionalidade e do 
conteúdo informacional de uma aplicação Web (PRESSMAN; MAXIM, 2016). A Figura 2 
12
13
mostra uma possível arquitetura em tempo de execução (runtime) quando o referido padrão 
é usado para o gerenciamento de interações em um sistema de software baseado em Web.
Controlador
• Processamento da requisição
HTTP;
• Lógica especí�ca de aplicação;
• Validação de dados.
• Lógica de negócio;
• Banco de dados.
• Geração dinâmica de página;
• Gerenciamento de formulário.
Visão
Modelo
Formulário
para exibir
Eventos 
do usuário
Noti�cação
de mudança Requisição
de atualização
Requisição
de atualização
Navegador
Figura 2 – Arquitetura de aplicação Web usando o padrão MVC
Fonte: Adaptada de SOMMERVILLE, 2019, p. 156
É importante salientar que o padrão MVC é um padrão arquitetural apresentado ini-
cialmente na linguagem de programação Smalltalk-80, sendo que no decorrer do tem-
po, surgiram variações dessa proposta original. Muitos frameworks adotaram esse pa-
drão arquitetural, principalmente os de desenvolvimento de aplicações Web. No âmbito 
da linguagem Java, as tecnologias JavaServer Pages (JSP) e Servlets são adotadas para 
implementar o MVC para Web. Existem também frameworks MVC que dão suporte à 
organização da aplicação de acordo com o referido padrão. Um exemplo de framework 
MVC para a plataforma Java é o Spring MVC (BEZERRA, 2015).
Para maiores detalhes sobre o framework Spring Web MVC, disponível em: https://bit.ly/3jtaTc1
Arquitetura em Camadas
A separação e independência são aspectos essenciais para o projeto de arquitetu-
ra porque permitem que modificações sejam localizadas. Como visto, o padrão MVC 
separa os elementos de um sistema, permitindo modificá-los de forma independente. 
O padrão de arquitetura em camadas é outra alternativa para obter a separação e inde-
pendência dos elementos do software (SOMMERVILLE, 2019).
13
UNIDADE Padrões Arquiteturais
O Quadro 2 descreve o padrão de arquitetura em camadas, em que a funcionalidade 
do software é organizada em camadas separadas, e cada camada depende dos recursos 
e serviços oferecidos pela camada imediatamente inferior a ela.
Quadro 2 – O padrão de arquitetura em camadas
Descrição
Organiza o sistema em camadas, com funcionalidade associada 
a cada uma. Uma camada fornece serviços para a camada acima 
dela; então as camadas nos níveis mais inferiores representam os 
serviços essenciais que tendem a ser utilizados em todo o sistema.
Quando é usado
Utilizado quando se cria novos recursos em cima de sistemas exis-
tentes; quando o desenvolvimento é distribuído por vários times, 
cada um deles responsável por uma camada de funcionalidade; 
quando há necessidade de segurança da informação (security) em 
múltiplos níveis.
Vantagens
Permite a substituição de camadas inteiras, contanto que a inter-
face seja mantida. Recursos redundantes, como a autenticação, 
podem ser fornecidos em cada camada para aumentar a depen-
dabilidade (dependability) do sistema.
Desvantagens
Na prática, muitas vezes é difícil proporcionar uma separação cla-
ra entre as camadas, de modo que camadas dos níveis mais altos 
podem ter de interagir diretamente com as dos níveismais baixos, 
em vez das imediatamente inferiores a elas. O desempenho pode 
ser um problema por causa dos múltiplos níveis de interpretação 
de uma requisição de serviço, à medida que essa requisição é pro-
cessada em cada camada.
Fonte: Adaptado de SOMMERVILLE, 2019, p. 157
O padrão em camadas apoia o desenvolvimento incremental de software. Quando 
uma camada é desenvolvida, alguns dos serviços prestados por ela podem ser dispo-
nibilizados para os usuários. Essa arquitetura também é mutável e portável. Enquanto 
sua interface for inalterada, uma camada pode ser substituída por outra equivalente. 
Além disso, quando a camada de interfaces muda ou tem novos recursos adiciona-
dos, somente a camada adjacente é afetada. Como sistemas em camadas localizam 
dependências das máquinas em camadas internas, isso facilita o fornecimento de im-
plementações de multiplataformas de uma aplicação. Apenas as camadas internas 
dependentes da máquina são implementadas novamente para poder levar em con-
sideração os recursos de um sistema operacional ou de um banco de dados distinto 
(SOMMERVILLE, 2019).
A Figura 3 mostra uma arquitetura genérica em camadas, nesse caso, com quatro 
camadas. A camada mais baixa inclui software de apoio ao sistema. A próxima camada é 
a camada de aplicação, que engloba os componentes relacionados com a funcionalidade 
da aplicação e os componentes utilitários que são usados por outros componentes da 
aplicação. A terceira camada lida com gerenciamento de interface de usuário e fornecimento 
de autenticação e autorização de usuário, com a camada superior provendo recursos de 
interface de usuário.
14
15
Interface com o usuário
Gerenciamento de interface com o usuário
Autenticação e autorização
Lógica principal do negócio/funcionalidade da aplicação
Componentes utilitários para o sistema
Apoio ao sistema (sistema operacional, banco de dados etc.)
Figura 3 – Uma arquitetura genérica em camadas
Fonte: Adaptada de SOMMERVILLE, 2019, p. 157
Naturalmente, o número de camadas da Figura 3 é arbitrário. Qualquer camada ilustra-
da nessa figura pode ser particionada em duas ou mais camadas (SOMMERVILLE, 2019).
Arquitetura Cliente-Servidor
Uma organização bastante usada para sistemas distribuídos em tempo de execução 
é o padrão arquitetural cliente-servidor, sendo que um sistema de software que segue 
esse padrão é organizado como um conjunto de serviços e servidores vinculados e clien-
tes que acessam e usam esses serviços. As arquiteturas cliente-servidor costumam ser 
vistas como arquiteturas de sistemas distribuídos, porém, o modelo lógico de serviços 
independentes sendo executados em servidores separados pode ser implementado em 
uma única máquina. Novamente, um aspecto a ser destacado aqui é a separação e a in-
dependência, já que serviços e servidores podem ser alterados sem comprometer outras 
partes do sistema (SOMMERVILLE, 2019). O Quadro 3 descreve o padrão arquitetural 
cliente-servidor em tempo de execução usada normalmente em sistemas distribuídos.
Quadro 3 – O padrão cliente-servidor
Descrição
Em uma arquitetura cliente-servidor, o sistema é apresentado 
como um conjunto de serviços, e cada serviço é fornecido por um 
servidor separado. Os clientes são usuários desses serviços e aces-
sam os servidores para usá-los.
Quando é usado
Utilizado quando os dados em um banco de dados compartilhado 
têm de ser acessados a partir de diversos locais. Como os servi-
dores podem ser replicados, eles também podem ser utilizados 
quando a carga em um sistema for variável.
15
UNIDADE Padrões Arquiteturais
Vantagens
A principal vantagem desse modelo é que os servidores podem 
ser distribuídos em rede. A funcionalidade geral (por exemplo, um 
serviço de impressão) pode estar disponível para todos os clientes 
e não precisa ser implementada por todos os serviços.
Desvantagens
Cada serviço é um único ponto de falha, e, portanto, é suscetível a 
ataques de negação de serviço ou a falhas no servidor. O desem-
penho pode ser imprevisível porque depende da rede e também 
do sistema. Podem surgir problemas de gerenciamento se os ser-
vidores forem de propriedade de organizações diferentes.
Fonte: Adaptado de SOMMERVILLE, 2019, p. 160
A Figura 4 mostra um exemplo de sistema de software baseado no padrão cliente-
-servidor. Trata-se de um sistema de aplicação Web para fornecimento de uma biblioteca 
de filmes e fotos, havendo vários servidores gerenciando e apresentando os diferentes 
tipos de mídia.
Cliente 1
Servidor 
de catálogo
Catálogo
da biblioteca
Cliente 2 Cliente 3
Internet
Cliente 4
Servidor 
de vídeo
Repositório 
de �lmes
Servidor 
de Imagens
Repositório 
de fotos
Servidor web
Informações de
�lmes e fotos
Figura 4 – Arquitetura ciente-servidor de uma biblioteca de filmes
Fonte: Adaptada de SOMMERVILLE, 2019, p.161
A principal vantagem do padrão de arquitetura cliente-servidor é que se trata de uma 
arquitetura distribuída, permitindo assim o uso efetivo por sistemas em rede com muitos 
processadores distribuídos, facilitando a inclusão de um novo servidor e a integração 
deste último com o restante do sistema e a atualização dos servidores de forma transpa-
rente, sem afetar as outras partes do software (SOMMERVILLE, 2019).
Dentro do contexto de arquiteturas distribuídas, cabe mencionar aqui a arquitetura 
orientada a serviços, do inglês Service-Oriented Architecture (SOA). A arquitetura 
orientada a serviços é um padrão de arquitetura para o desenvolvimento de sistemas 
distribuídos onde os componentes do sistema de software são serviços autônomos 
executados em computadores distribuídos. Os protocolos são baseados em XML, SOAP 
e WSDL e foram projetados para oferecer suporte à comunicação de serviço e à troca 
de informações, desse modo, os serviços são implementados de forma independente de 
linguagens de programação. Os sistemas de software podem ser construídos mediante 
a composição de serviços locais e serviços externos de provedores distintos, havendo 
interação entre os serviços no sistema. Os protocolos de web services abrangem todos 
os aspectos da arquitetura orientada a serviços, desde os mecanismos básicos para troca 
de informações de serviço até os padrões de programação. Os padrões de web services 
para SOA foram desenvolvidos para serem padrões abertos, porém, há uma resistência 
16
17
significativa a eles por conta de sua ineficiência. Há desenvolvedores de sistemas de 
software baseados em serviços que preferem adotar protocolos RESTful porque têm 
uma sobrecarga (overhead) intrinsicamente mais baixa do que os protocolos de web 
services (SOMMERVILLE, 2019).
Um documento sobre arquitetura de Web Services que identifica os componentes funcionais 
e define seus relacionamentos para efetivar as propriedades desejadas para uma arquitetura, 
disponível em: https://bit.ly/2YYxWSt
Um estilo de arquitetura para sistemas distribuídos é o Representational State Transfer (REST). 
Maiores informações sobre esse estilo, disponível em: https://bit.ly/3oUPf1q
Arquitetura de Sistemas de Informação
Os sistemas que envolvem a interação com bancos de dados compartilhados podem ser 
vistos como sistemas de informação baseados em transações. Um sistema de informação 
permite acesso controlado a uma grande base de informações, como um catálogo de 
biblioteca, um horário de voo ou os registros de pacientes em um hospital. Cada vez mais, 
sistemas de informação são sistemas baseados na Web, nesse caso, acessados via browser. 
A Figura 5 mostra um modelo geral de sistema de informação. Nesse caso, foi adotado 
o padrão de arquitetura em camadas, em que a camada superior lida com a interface do 
usuário, e a inferior é o banco de dados do sistema. A camada de comunicação de usuário 
é responsável pelas entradas e saídas da interface de usuário e a camada de recuperação 
de informação possui uma lógica específica de aplicação para acessar e atualizar o banco 
de dados. Nesse modelo genérico, as camadas podem ser mapeadas diretamente aos 
servidores,em uma aplicação Web distribuída (SOMMERVILLE, 2019).
Interface com o usuário
Comunicação 
com o usuário
Autenticação
e autorização
Recuperação e modi�cação da informação
Gerenciamento de transação
Banco de dados
Figura 5 – Arquitetura de sistema de informação em camadas
Fonte: Adaptada de SOMERVILLE, 2019, p. 166
17
UNIDADE Padrões Arquiteturais
Uma arquitetura de software recomendada para aplicações Web é a arquitetura em 
três camadas porque separa a interface da navegação e o comportamento da aplicação. 
Essa separação simplifica a implementação e aumenta a reutilização (PRESSMAN; 
MAXIM, 2016). A Figura 6 ilustra uma arquitetura cliente-servidor multicamadas para 
um sistema de internet banking em que existem três camadas no sistema. Nesse caso, 
o uso da arquitetura de três camadas permite a troca de informações entre o servidor 
Web e o servidor de banco de dados para ser otimizado. As comunicações entre esses 
sistemas podem usar protocolos de troca de dados rápidos e de baixo nível. Vale salientar 
que o padrão de arquitetura cliente-servidor de três camadas pode ser estendido para 
uma variante em multicamadas, na qual novos servidores passam a ser adicionados ao 
sistema (SOMMERVILLE, 2019).
Cliente
Cliente
Cliente
Cliente
Camada 1. Apresentação
Interação via HTTPS
Consulta SQL
Servidor web Servidor de banco de dados
Camada 2. Processamento
da aplicação e manipulação
de dados
Prestação de
serviço de conta
Banco de dados 
de contas de cliente
SQL
Camada 3. Processamento
de banco de dados
Figura 6 – Arquitetura de três camadas para um sistema de internet banking
Fonte: Adaptada de SOMERVILLE, 2019, p. 476
Diante do contexto de sistemas de informação, quais as camadas comumente identi-
ficadas para o projeto de arquitetura de um sistema de informação?
A nomenclatura adotada para as camadas típicas de um sistema de informação está 
distante de uma padronização. Contudo, uma divisão frequentemente encontrada para 
as camadas lógicas de um sistema de software orientado a objetos é a que separa o sis-
tema nas seguintes camadas: apresentação, aplicação, domínio e infraestrutura. No caso 
dessa lista de nomes, da esquerda para a direita, têm-se camadas cada vez mais genéri-
cas. Também da esquerda para a direita, há a ordem de dependência entre as camadas, 
por exemplo, a camada da apresentação depende da camada de aplicação, mas não 
o contrário (BEZERRA, 2015). A Figura 7 representa as camadas lógicas comumente 
encontradas em um sistema de informação. Vale salientar que embora a notação visual 
UML adotada para representar os conceitos de pacote e camada lógica seja a mesma, 
os significados desses conceitos são distintos.
18
19
Apresentação
Aplicação
Domínio
Serviços Técnicos
Figura 7 – Camadas lógicas típicas de um sistema de informação
Fonte: Adaptada de BEZERRA, 2015, p. 344
De forma resumida, são descritas aqui cada uma das camadas lógicas tipicamente 
encontradas em um sistema de informação:
• Apresentação: essa camada também é chamada de interface de usuário, sendo 
composta de classes que constituem a funcionalidade para visualização dos dados 
pelos usuários e interface com outros sistemas. As classes de fronteira se encon-
tram nessa camada. São exemplos de camadas de apresentação: um sistema de 
menus baseados em texto; uma interface gráfica construída em algum ambiente 
de programação. Os objetos de fronteira que interagem com usuários são alocados 
nessa camada;
• Aplicação: essa camada também é chamada de camada de serviço. Trata-se de 
uma camada intermediária entre os vários componentes da camada de apresenta-
ção (telas da interface gráfica e interfaces de voz, interfaces por linha de comando 
etc.) e a lógica contida nos objetos do negócio. Essa camada transforma as men-
sagens que recebe da camada da aplicação em mensagens compreendidas pelos 
objetos do domínio. É também responsabilidade dessa camada o controle da nave-
gação do usuário de uma janela a outra, quando a interação ocorrer por meio de 
uma interface gráfica;
• Domínio: essa camada também é conhecida como camada de negócio. A cama-
da do domínio é aquela onde se encontram a maioria dos objetos identificados 
durante a atividade de análise. Essa camada recebe requisições provenientes da 
camada da aplicação. Os objetos nessa camada normalmente são independen-
tes da aplicação, significando que podem ser reusados em diferentes aplicações 
dentro de uma organização. Essa camada é responsável por validações das re-
gras de negócio, assim como de dados provenientes da camada de apresentação, 
intermediadas pela camada de aplicação. As classes da camada do domínio são 
19
UNIDADE Padrões Arquiteturais
aquelas que representam os conceitos do domínio da aplicação que o sistema 
deve processar. Essas classes representam as informações produzidas durante a 
realização dos processos do negócio, assim como as regras de negócio que dire-
cionam a manipulação dessas informações;
• Infraestrutura: essa camada também é chamada de camada de serviços técnicos. 
A camada de infraestrutura é o local onde são encontrados serviços genéricos e 
úteis para uma gama vasta de aplicações. Como o próprio nome diz, essa camada 
fornece serviços referentes às tecnologias usadas na implementação da aplicação. 
Exemplos de serviços fornecidos por esta camada são autenticação e autorização, 
controle de transações, registro de operações do sistema (logging), manipulação de 
arquivos, estruturas de dados, classes utilitárias, entre outros. Além dos serviços 
listados, a camada de infraestrutura também deve conter classes que permitam 
que o sistema se comunique com outros sistemas para realizar tarefas ou adquirir 
informações (acesso a um banco de dados ou a web services). Particularmente, 
a camada de persistência é um serviço (subcamada) da camada de infraestrutura 
(BEZERRA, 2015).
Como uma arquitetura de software para um sistema de informação pode ser estabelecida?
A arquitetura de um sistema de informação pode ser definida em dois níveis arqui-
teturais: arquitetura lógica e arquitetura física. A arquitetura lógica determina como um 
software é decomposto em diversos subsistemas e como suas classes são distribuídas 
nos diversos subsistemas identificados. A arquitetura lógica se refere à organização das 
classes de um sistema em subsistemas, representando assim um coletivo de classes. 
Um sistema de software pode ser dividido em diversos subsistemas, sendo que a comu-
nicação entre eles é realizada por meio de suas interfaces. A arquitetura física, também 
conhecida como arquitetura de implantação, representa a distribuição física do software 
pelo hardware disponível. Essa arquitetura se refere à disposição dos subsistemas pelas 
máquinas disponíveis. Para sistemas simples, a arquitetura de implantação não tem mui-
ta relevância, mas na modelagem de sistemas complexos, inclusive sistemas distribuídos 
baseados na Web, é essencial conhecer quais são os componentes físicos do sistema, 
quais são as interdependências entre eles e de que forma as camadas lógicas do sistema 
de software estão organizadas por esses componentes (BEZERRA, 2015).
Para um sistema de informação desenvolvido de acordo com o padrão de arquitetura 
cliente-servidor, é muito comum utilizar as definições das camadas lógicas como um guia 
para a alocação física dos subsistemas. Dessa forma, para cada camada física, como um 
servidor, são alocadas uma ou mais camadas lógicas. É importante tomar cuidado ao uti-
lizar o conceito de camada, pois frequentemente esse termo é adotado com dois sentidos 
diferentes. Quando nos referimos à camada lógica, o termo layer é mais apropriado; já 
quando nos referimos à camada física, o termo tier é mais adequado (BEZERRA, 2015).
Há relação do padrão de arquitetura MVC com o projeto arquitetural de um sistema 
de informação?
O padrão arquitetural MVC tem relação com a arquitetura lógica do software. Apesar 
dos componentes do MVC não serem camadas, é possível fazer uma correspondênciaentre seus componentes e as camadas lógicas da arquitetura de um sistema de informa-
ção, principalmente para aplicações Web. Os componentes View (Visão) e Controller 
20
21
(Controlador), em relação às requisições HTTP, representariam a camada de Apresenta-
ção. O componente Controller (Controlador), no que se refere ao controle de um caso 
de uso, representaria a camada de Aplicação, já que gerencia a resposta esperada ao se 
comunicar com a camada de Domínio. Por fim, o componente Model (Modelo) repre-
sentaria a camada de Domínio. (BEZERRA, 2015). 
O padrão arquitetural MVC foi adotado pela comunidade de desenvolvimento de 
software também para o nível arquitetural de larga escala. Nesse caso, o modelo 
se refere à camada de domínio, a visão se refere à camada de interface de usuário 
(apresentação) e os controladores são os objetos de fluxo de trabalho da camada de 
aplicação (LARMAN, 2007). 
Vale destacar que o projeto (design) da camada de domínio é também conhecido 
como design lógico, já que a camada de domínio corresponde ao conjunto de classes 
que realizam toda a transformação de dados e consultas. As demais camadas imple-
mentam aspectos tecnológicos do software como persistência, interface, comunicação, 
segurança etc., sendo comumente derivadas e dependentes da camada de domínio cuja 
função é conectar a lógica do domínio com os aspectos físicos computacionais como re-
des de comunicação, interfaces de usuário, dispositivos de armazenamento entre outros 
(WAZLAWICK, 2015).
Para maiores detalhes sobre as camadas típicas de um sistema de informação descritas nes-
ta unidade e a relação do padrão MVC com a arquitetura lógica, você pode explorar o capítu-
lo 12 do livro “Princípios de análise e projeto de sistemas com UML”, de Eduardo Bezerra, 
disponível na Biblioteca Virtual da Universidade, disponível em: https://bit.ly/3tE708K
Para maiores detalhes sobre o Projeto (Design) da Camada de Domínio, você pode explorar o 
capítulo 9 do livro “Análise e design orientados a objetos para sistemas de informação: 
modelagem com UML, OCL e IFML”, de Raul Sidnei Wazlawick, disponível na Biblioteca 
Virtual da Universidade, a partir do link disponível em: https://bit.ly/2OrPQLx
21
UNIDADE Padrões Arquiteturais
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Biblioteca Virtual Cruzeiro do Sul
https://bit.ly/3p6UpHP
 Leitura
An Introduction to Software Architecture
https://bit.ly/2Z3zfzD
Representational State Transfer (REST)
https://bit.ly/3jDeWmb
Uma Olhada Rápida nos estilos e padrões arquiteturais
https://bit.ly/3rGysAZ
The Hill Site Group
https://bit.ly/3p6SzGV
Web Services Architecture
https://bit.ly/2LBCAmo
Web on Servlet Stack
https://bit.ly/3p8CYXo
22
23
Referências
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3.ed. São 
Paulo: Elsevier, 2015.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orien-
tados a objetos e ao desenvolvimento iterativo. 3.ed. Porto Alegre: Bookman, 2007.
PRESSMAN, R. S.; MAXIM. B. R. Engenharia de software. 8.ed. Porto Alegre: 
AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 10.ed. São Paulo: Pearson, 2019.
WAZLAWICK, R. S. Análise e design orientados a objetos para sistemas de informa-
ção: modelagem com UML, OCL e IFML. 3.ed. Rio de Janeiro: Campus Elsevier, 2015.
23