Você está na página 1de 160

Arquitetura de software

Geórgia Maria Ferro Benetti


Jeanfrank Teodoro Dantas Sartori
Sidartha Azevedo Lobo de Carvalho
Presidente da Divisão de Ensino Prof. Paulo Arns da Cunha
Reitor Prof. José Pio Martins
Pró-Reitor de Graduação Prof. Carlos Longo
Pró-Reitor de Pós-Graduação e Pesquisa Prof. Ronaldo Vinicius Casagrande
Coordenação Geral de EAD Prof. Everton Renaud
Coordenação de Metodologia e Tecnologia Profa. Roberta Galon Silva
Autoria Profa. Geórgia Maria Ferro Benetti
Prof. Jeanfrank Teodoro Dantas Sartori
Prof. Sidartha Azevedo Lobo de Carvalho
Parecer Técnico Prof. Cleverson Avelino Ferreira
Supervisão Editorial Aline Scaliante Coelho Baggetti
Projeto Gráfico e Capa Regiane Rosa

DTCOM – DIRECT TO COMPANY S/A


Análise de Qualidade, Edição de Texto, Design Instrucional,
Edição de Arte, Diagramação, Design Gráfico e Revisão.

Dados Internacionais de Catalogação na Publicação (CIP)


Biblioteca da Universidade Positivo – Curitiba – PR

© Universidade Positivo 2018


Rua Prof. Pedro Viriato Parigot de Souza, 5300 – Campo Comprido
Curitiba-PR – CEP 81280-330
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos.
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização.
A violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
Imagens de ícones/capa: © Thinkstock / © Anatomy Insider / Shutterstock.com
COMPREENDA SEU LIVRO
Metodologia

Caro aluno,
A metodologia da Universidade Positivo apresenta materiais e tecnologias apropriadas
que permitem o desenvolvimento e a interação entre alunos, docentes e recursos didáticos e
tem por objetivo a comunização bidirecional entre os atores educacionais.
O seu livro, que faz parte dessa metodologia, está inserido em um percurso de aprendi-
zagem que busca direcionar a construção de seu conhecimento por meio da leitura, da con-
textualização teórica-prática e das atividades individuais e colaborativas; e fundamentado
nos seguintes propósitos:

valorizar suas incentivar a estimular a oportunizar a reflexão


experiências; construção e a pesquisa; teórica e aplicação
reconstrução do consciente dos temas
conhecimento; abordados.

Arquitetura de software 3
COMPREENDA SEU LIVRO
Percurso

Com base nessa metodologia, o livro apresenta a seguinte estrutura:

Objetivos do capítulo
Indicam o que se espera que você
aprenda ao final do estudo do Tópicos que serão estudados

capítulo, baseados nas necessida- Descrição dos conteúdos que serão

des de aprendizagem do seu curso. estudados no capítulo.

Contextualizando o cenário
Contextualização do tema que será Pergunta norteadora

estudado no capítulo, como um Ao final do Contextualizando o cenário,

cenário que o oriente a respeito do consta uma pergunta que estimulará sua

assunto, relacionando teoria e prática. reflexão sobre o cenário apresentado,


com foco no desenvolvimento da sua
Pausa para refletir capacidade de análise crítica.
São perguntas que o instigam a
refletir sobre algum ponto Boxes

estudado no capítulo. São caixas em destaque que podem


apresentar uma citação, indicações de
leitura, de filme, apresentação de um
Proposta de atividade contexto, dicas, curiosidades etc.
Sugestão de atividade para que você
desenvolva sua autonomia e siste­
matize o que aprendeu no capítulo. Recapitulando
É o fechamento do capítulo. Visa sinte-
tizar o que foi abordado, reto­mando os
Referências bibliográficas
objetivos do capítulo, a pergunta nortea-
São todas as fontes utilizadas no
dora e fornecendo um direcionamento
capítulo, incluindo as fontes mencio­
sobre os questionamentos feitos no
nadas nos boxes, adequadas
decorrer do conteúdo.
ao Projeto Pedagógico do curso.

4 Arquitetura de software
BOXES

Afirmação
Citações e afirmativas pronunciadas por teóricos de relevância
na área de estudo.

Assista
Indicação de filmes, vídeos ou similares que trazem informações
complementares ou aprofundadas sobre o conteúdo estudado.

Biografia
Dados essenciais e pertinentes sobre a vida de uma determinada
pessoa relevante para o estudo do conteúdo abordado.

Contexto
Dados que retratam onde e quando aconteceu determinado fato;
demonstram a situação histórica, social e cultural do assunto.

Curiosidade
Informação que revela algo desconhecido e interessante sobre
o assunto tratado.

Dica
Um detalhe específico da informação, um breve conselho, um alerta,
uma informação privilegiada sobre o conteúdo trabalhado.

Esclarecimento
Explicação, elucidação sobre uma palavra ou expressão específica
da área de conhecimento trabalhada.

Exemplo
Informação que retrata de forma obje­tiva determinado assunto
abordando a relação teoria-prática.

Arquitetura de software 5
SUMÁRIO

Apresentação 13
A Autoria 14

CAPÍTULO 1
A Arquitetura de Software no processo de desenvolvimento de
sistemas 17
Contextualizando o cenário 18
1.1. Visão Geral 19
1.1.1. Arquitetura do sistema 19
1.1.2. Motivação para desenvolver uma Arquitetura de Software 21
1.1.3. Erros comuns 22

1.2. Conceitos e processos de software 23


1.2.1. Definição de Arquitetura de Software 23
1.2.2. Modelo de análise e projeto 24
1.2.3. Coesão e acoplamento 25
1.2.4. Níveis de abstração 25

1.3. Arquiteto de Software 27


1.3.1. Papel do arquiteto de software 27
1.3.2. Contexto de atuação 28

1.4. Casos de Uso 29


1.4.1. Exemplo de aplicação 29
1.4.2. Custo e benefícios 30
1.4.3. Modelo Visual do Sistema (MVS) 31

Proposta de Atividade 33
Recapitulando 33
Referências 34

Arquitetura de software 7
CAPÍTULO 2
O modelo 4 + 1 35
Contextualizando o cenário 36
2.1. Diferentes conceitos 37
2.1.1. Modelo de referência 37
2.1.2. Framework 39
2.1.3. Estilos 40
2.1.4. Padrões 43

2.2. 4+1 e a visão de cenários de uso 44


2.2.1. Visão lógica 45
2.2.2. Visão de processo 46
2.2.3. Visão física 47
2.2.4. Visão de desenvolvimento 48

2.3. Documento de Arquitetura de Sistema (DAS) 49


2.3.1. Visão geral 49
2.3.2. Como utilizar 50

Proposta de Atividade 51
Recapitulando 51
Referências 53

CAPÍTULO 3
Padrões de Projeto 55
Contextualizando o cenário 56
3.1. Padrões do Gang of Four (GOF) e suas categorias 57
3.1.1. Componentes dos padrões GOF 57
3.1.2. Padrões Criacionais 60
3.1.3. Padrões Estruturais 61
3.1.4. Padrões Comportamentais 62

3.2. Implementação dos padrões 64


Proposta de Atividade 70
Recapitulando 70
Referências 71
CAPÍTULO 4
Arquitetura Orientada a Serviços (SOA) 73
Contextualizando o cenário 74
4.1. Introdução 75
4.1.1. Requisitos 77
4.1.2. Acoplamento 78
4.1.3. Desenho 79

4.2. Serviço 80
4.2.1. Visão geral 82
4.2.2. Granularidade 84

4.3. Aplicação 86
4.3.1. Exemplo de aplicação 86
4.3.2. Vantagens e desvantagens da arquitetura SOA 87

Proposta de Atividade 88
Recapitulando 88
Referências 90

CAPÍTULO 5
Arquitetura n-tier 91
Contextualizando o cenário 92
5.1. Camadas 93
5.1.1. Camada cliente 95
5.1.2. Camada aplicação 97
5.1.3. Camada banco de dados 100

5.2. Aplicação 101


5.2.1. Exemplo de aplicação 101
5.2.2. Vantagens e desvantagens da arquitetura n-tier. 103

Proposta de Atividade 105


Recapitulando 105
Referências 107

Arquitetura de software 9
CAPÍTULO 6
Arquitetura móvel 109
Contextualizando o cenário 110
6.1. Modelo de arquitetura 111
6.1.1. Visão geral 113
6.1.2. Estilo Representational State Transfer (REST) 116

6.2. Aplicação 119


6.2.1. Exemplo de aplicação 120
6.2.2. Premissas e restrições de uma arquitetura móvel 122

Proposta de Atividade 123


Recapitulando 123
Referências 124

CAPÍTULO 7
Arquitetura de aplicações ricas (RIA) 125
Contextualizando o cenário 126
7.1. Visão geral 127
7.1.1. Benefícios 127
7.1.2. Deficiências e restrições 129
7.1.3. Dificuldades de gerenciamento 131

7.2. Tecnologia 132


7.2.1. Chamada assíncrona 132
7.2.2. Tecnologias de apresentação 134
7.2.3. Interfaces Web Mobile responsivas 135

7.3. Aplicação 136


7.3.1. Utilização de Java Script 137
7.3.2. Utilização de Angular JS 138

Proposta de Atividade 139


Recapitulando 140
Referências 141

10 Arquitetura de software
CAPÍTULO 8
Computação em nuvem e softwares adaptativos 143
Contextualizando o cenário 144
8.1. Introdução à computação em nuvem 145
8.1.1. Tipologia da computação em nuvem 146
8.1.2. Desenho da arquitetura 148
8.1.3. Modelo de implantação 149

8.2. Arquitetura reativa 151


8.2.1. Manifesto reativo 152
8.2.2. Decisões arquiteturais 153

8.3. Arquitetura adaptativa 154


8.3.1. Habilidade de mudança 155
8.3.2. Exemplo de aplicação 155

Proposta de Atividade 157


Recapitulando 157
Referências 158

Arquitetura de software 11
APRESENTAÇÃO

Planejamento prévio é uma recomendação válida e pertinente para todo projeto. Afi-
nal, muitos erros decorrem diretamente do fato de essa etapa ter sido negligenciada ou
feita inadequadamente. Ela busca garantir, em linhas gerais, que se saiba claramente onde
se quer chegar e o que precisará ser executado para esse fim.
No desenvolvimento de softwares, não é diferente. Antes de iniciar-se o processo de
codificação, é recomendada a seguinte prática: a criação de um modelo geral que descreva
como esse sistema será distribuído em componentes (ou módulos) e suas conexões e rela-
ções. Mas essa responsabilidade compete a qual profissional? E ele fará uso de qual prin-
cipal instrumento de planejamento? Quais são as metodologias mais comuns adotadas?
Esses e outras perguntas serão respondidas ao longo nesta disciplina, que também ensi-
nará de que forma é possível executar, com propriedade, esse importante papel em proje-
tos de desenvolvimento de software. Bons estudos!

Arquitetura de software 13
A AUTORIA

A Professora Georgia Maria Ferro Benetti Ribeiro é Doutora em Ciências Humanas, com
formação em Análise de Sistemas. Tem vários anos de experiência como docente no ensino
superior em cursos de graduação e pós-graduação. Embaixadora e mentora no desafio Tech-
novation Challenge Brasil. Integrante do PyLadies Florianópolis. Sócia Fundadora da ONG
Inspiring Girls no Brasil.

Currículo Lattes:
<lattes.cnpq.br/2605217800781166>

Dedico esse material a todos e todas


que tenham como propósito trabalhar
a tecnologia como um recurso que está
a serviço do humano em nós e da vida
humana como parte integrante da
natureza.

14 Arquitetura de software
A AUTORIA

O Professor Jeanfrank Teodoro Dantas Sartori é graduado em Administração pela


Universidade Federal do Paraná. Possui mais de 15 anos de experiência na área de Tecnologia
da Informação e Análise de Dados, tendo atuado no setor educacional, gráfico e bancário.

Currículo Lattes:
<lattes.cnpq.br/2047592684381858>

A Deus, a quem tudo pertence. Aos


meus pais, que me deram amor
e me prepararam para a vida.
Aos meus professores, que me
ensinaram o caminho acadêmico.
Aos verdadeiros amigos e a todos
vão além do seu dever.

Arquitetura de software 15
A AUTORIA

O Professor Sidartha Azevedo Lobo de Carvalho é mestre em Ciência da Computa-


ção pela Universidade Federal de Pernambuco com ênfase em Sistemas Embarcados (2015).
Bacharel em Sistemas da Informação pela Universidade Federal do Ceará (2012). Atuou como
pesquisador no Projeto Samsung e Motorola pelo Projeto CIN/UFPE. Trabalha principal-
mente com ferramentas e técnicas inteligentes para eficiência energética em smatphones.

Currículo Lattes:
<lattes.cnpq.br/9163574470590664>

Agradeço toda a equipe que contribuiu


para a concretização desse deste
trabalho.

16 Arquitetura de software
CAPÍTULO 1

A Arquitetura de Software no processo de


desenvolvimento de sistemas
Jeanfrank Teodoro Dantas Sartori

OBJETIVOS DO CAPÍTULO
• Entender como a Arquitetura de Software está inserida no processo de desenvol-
vimento e o papel do arquiteto de software nesse processo, definindo os conceitos
básicos e suas aplicações.

TÓPICOS DE ESTUDO

1 Visão Geral 3 Arquiteto de Software

• Arquitetura de Software. • Papel do arquiteto de software.


• Motivação para desenvolver uma • Contexto de atuação.
arquitetura de software.
• Erros comuns.

2 Conceitos e Processo de Software 4 Casos de Uso

• Definição de Arquitetura de • Exemplo de aplicação.


Software. • Custo e benefícios.
• Modelo de análise e projeto. • Modelo Visual do Sistema (MVS).
• Coesão e acoplamento.
• Níveis de abstração.

Arquitetura de software 17
Contextualizando o cenário

A primeira etapa de aprendizado desta disciplina trará uma visão geral da Arquitetura de
Software ou de Sistemas. Os estudos também contemplarão sua definição, seus benefícios
e custos, além de uma visão geral do papel do profissional responsável por sua criação – o
Arquiteto de Software –, quais suas atribuições, desafios e contribuições para o processo de
desenvolvimento como um todo.

Diante desse cenário, fica a questão: é possível imaginar qual é papel da Arquitetura de
Software e do profissional responsável por ela? E como isso se encaixa no fluxo de cria-
ção de um software?

18 Arquitetura de software
1.1. Visão Geral

A maioria dos profissionais de arquite-


tura conhece o papel do arquiteto em uma
construção ou ponto urbanístico, suas rela-

© Dragon Images / / Shutterstock.


ções com o trabalho do engenheiro civil e
suas responsabilidades quanto ao resultado
geral de um projeto.
Nesse sentido, o uso do termo arqui-
tetura para a área de Tecnologia da Infor-
mação não é coincidência ou uma aleatoriedade. Ao contrário: a analogia é bastante
pertinente e ajuda a compreender o papel e a função da arquitetura no processo de desen-
volvimento de um software.

1.1.1. Arquitetura do sistema

A palavra arquitetura representa, entre outros significados, segundo o dicionário


Michaelis, a “Arte e ciência de projetar e supervisionar a construção de edifícios ou outras
estruturas (...)” ou o “modo como se dispõem as partes ou os elementos de um edifício ou
de um espaço urbano”. Já a expressão engenharia significa, na construção civil, segundo
esse mesmo dicionário, a “Arte de aplicar os conhecimentos científicos à invenção, aperfei-
çoamento ou utilização da técnica industrial” (Weiszflog, 2004).
Nesse contexto, em linhas gerais, cabe à arquitetura a concepção geral de uma edifi-
cação, definição de suas partes, sua integração, seus aspectos técnicos e funcionais. Além
disso, a arquitetura planeja o aspecto visual desse edifício (por exemplo, a fachada de um
prédio, suas cores, revestimento, etc.). Ademais, apesar de ter conhecimentos gerais sobre
as questões estruturais e operacionais, ela se ocupa prevalentemente dos aspectos mais
panorâmicos do planejamento de uma dada construção.
Ao engenheiro civil, por sua vez, compete transformar o projeto arquitetônico em
uma construção efetiva, competindo a ele os cálculos estruturais, orçamento e otimização
dos materiais a serem empregados, planejamento e coordenação da operação de constru-
ção e vistoria do resultado final, entre outras muitas atribuições.
Como exemplo disso, podemos pensar na construção de um museu. Para projetar
esse museu, um arquiteto desenha, primeiramente, um croqui (esboço). O resultado real (o
museu pronto para visitação), produzido por meio do trabalho dos engenheiros que atua-
ram em seu planejamento e construção, foi baseado em um desenho. A figura a seguir
demonstra o Museu Oscar Niemeyer já pronto para visitação.

Arquitetura de software 19
Museu Oscar Niemeyer

© Gregorio Koji / / Shutterstock.


E é justamente a partir de uma analogia desses termos oriundos da área da constru-
ção que surgem as expressões equivalentes na área de sistemas, conforme apresentado no
quadro a seguir.

Paralelos entre as atividades da Construção Civil e da Análise de Sistema

Construção Civil Análise de Sistemas

Arquiteto Arquiteto de oftware

Engenheiro Civil Engenheiro de Software

Assim, a Arquitetura de Software corresponde, em linhas gerais, ao planejamento


ou à definição dos componentes de um sistema, suas principais propriedades e suas inter-
-relações. Por componentes podemos compreender os elementos fundamentais, como um
servidor, um banco de dados e até mesmo os usuários.
A engenharia de software, por sua vez, resumidamente é a área encarregada de
gerenciar e executar efetivamente a programação de um sistema, a partir do escopo defi-
nido inicialmente, até o seu resultado final. Zela, também, pela manutenção e atualização.

20 Arquitetura de software
No cotidiano e na própria academia, todavia, a fronteira entre a arquitetura e a enge-
nharia de software nem sempre é tão clara, e sobreposições acabam acontecendo, assim
como na construção civil. Há diferentes visões em relações a aspectos mais específicos, e,
por essa razão, deve prevalecer sempre o bom senso e o trabalho em equipe, visando ao
resultado final, e não ao destaque pessoal.

1.1.2. Motivação para desenvolver uma Arquitetura de Software

Entre as razões e vantagens da criação de uma Arquitetura de Software, pode-se des-


tacar o fato de ela constituir um meio de comunicação entre os stakeholders de um projeto,
proporcionar o estabelecimento das decisões fundamentais de sistema e a reusabilidade da
abstração em outros sistemas (BASS; CLEMENTES; KAZMAN, 2003).
Primeiramente, o desenvolvimento de sistemas envolve um conjunto de diversos
interesses, por vezes conflitantes, dos stakeholders.

Esclarecimento
Stakeholders são as partes interessadas ou afetadas pelo software, como o
cliente, os engenheiros de software, os programadores etc.

Nesse sentido, a Arquitetura de Software oferece uma linguagem e uma base comum
para que essas questões sejam discutidas e sanadas antes que as primeiras linhas de código
tenham sido construídas.
Por sua vez, as decisões fundamentais tomadas no escopo da Arquitetura de Software
definem, entre outros fatores, os componentes gerais de um software, o que permite um
melhor planejamento da alocação de recursos financeiros e humanos no efetivo desenvolvi-
mento. Tem-se, assim, a possibilidade de se otimizar todo o ciclo produtivo a partir de uma
visão mais clara de seus elementos fundamentais.
Além disso, por constituir uma abstração do sistema, a Arquitetura de Software pode
vir a ser reutilizada, ainda que parcialmente, em outros projetos análogos ou similares, per-
mitindo uma grande economia de recursos, do mesmo modo que sempre se busca, quando
possível, a reutilização de códigos de programação.
Mas, apesar de apresentar diversas vantagens, a Arquitetura de Software também
oferece algumas armadilhas, por vezes recorrentes, as quais chamamos de erros.

Arquitetura de software 21
1.1.3. Erros comuns

Um dos erros mais comuns e fonte de diversos problemas é a criação de um distancia-


mento entre arquitetos de software e engenheiros de software e programadores, assim
como ocorre, muitas vezes, na construção civil. Esse fator pode ter origem na coordenação
geral de uma empresa ou projeto, mas também pode ter suas raízes nos próprios arquite-
tos e engenheiros.
Ser responsável pelas definições gerais
de um software não significa ser dono da
razão nem possuir qualquer outro poder
© Graphic farm / / Shutterstock

sobrenatural. Ao contrário: exige grande res-


ponsabilidade, além de capacidade de ouvir
e avaliar diferentes pontos de vista, incluindo
o cliente e os engenheiros de software. Com
estes últimos, deve-se formar uma perspec-
tiva de equipe que compartilha um objetivo comum. Por essa razão, as preocupações e ques-
tionamentos dos stakeholders envolvidos devem ser sempre consideradas e avaliadas.
Outro erro frequente diz respeito à criação de elefantes brancos, uma metáfora que
se refere à idealização de uma arquitetura desproporcionalmente grande e complexa em
relação às reais necessidades do projeto. O resultado certamente será um grande desper-
dício de recursos, uma vez que seu desenvolvimento terá dificuldades desnecessárias e não
agregarão benefícios reais ao cliente. Ademais, há risco de, eventualmente, ser necessário
um retorno à fase de concepção, para correções, ou mesmo de haver dificuldades posterio-
res de manutenção e atualização.

Contexto
Erros de modelagem de software podem custar caro. Em 1996, o então novo
foguete de carga Ariane 5 explodiu 40 segundos após o lançamento, por um erro de especi-
ficação e de design do sistema de navegação. Foram pelos ares 8,5 bilhões de dólares desen-
volvimento e da carga abordo. (LIONS, 1996).

Por fim, outro erro bastante comum acontece quando há um distanciamento dos
aspectos técnicos do posterior desenvolvimento. Em outras palavras, esse problema ocorre
quando a arquitetura tem sua abstração do sistema demasiadamente desconectado da rea-
lidade de desenvolvimento e das questões a ele relacionados, o que pode gerar um con-
ceito de sistema difícil de ser concretizado. Esse erro pode ter origem no distanciamento
com a equipe de engenharia e programação.

22 Arquitetura de software
Pausa para refletir

Colocar em prática a arquitetura de software não é tão simples como possa parecer. Você
consegue imaginar como esse processo é desenvolvido? E como será que essa arquitetura
costuma ser representada?

1.2. Conceitos e processos de software

A Arquitetura de Software é um
modelo geral que explica como o sistema
irá funcionar e suas principais funcionalida-
des. Assim, precisa representar quais módu-

© Iconic Bestiary / / Shutterstock.


los ou componentes farão quais papéis e
como se conectam. A definição adequada
dessas questões tornará mais fluidas e efi-
cientes as fases posteriores de desenvolvi-
mento e codificação.
Além dessas questões, a seguir serão estudadas as características que devem estar
presentes no processo de desenvolvimento e fatores gerais que devem ser considerados na
Arquitetura de Software. Esse estudo é importante porque, embora o ato de esboçar uma
Arquitetura de Software possa parecer, inicialmente, uma tarefa até simples, a realidade
dos projetos costuma ser bastante desafiadora.

1.2.1. Definição de Arquitetura de Software

A Arquitetura de Software é composta por um conjunto de componentes e conexões


entre eles. Todavia, ela possui uma significativa subjetividade, fazendo uso de elementos
gráficos, uma compreensão compartilhada do futuro sistema e um conjunto de decisões
estabelecidas desde o início do projeto (FOWLER, 2006). Isso não é atingido pela mera
representação gráfica.
Primeiramente, não basta simplesmente elencar os componentes, pois eles pre-
cisam estar devidamente especificados quanto a sua natureza, além de saber se são pro-
cessos, programas ou ambos. A separação entre componentes deve ter uma justificativa
apresentada, bem como a descrição de como suas respectivas funções serão executadas
em termos de tempo e processamento. Além disso, cada componente deve ter sua respon-
sabilidade definida, ou seja, é necessário saber qual papel deve exercer dentro do sistema
como um TODO (BASS; CLEMENTES; KAZMAN, 2003).

Arquitetura de software 23
Com relação às conexões, não basta uma simples interligação gráfica. É necessário espe-
cificar o que elas significam e de que tipo são. Podem ser, por exemplo, uma relação de mera
comunicação, controle, evocação, sincronização etc. (BASS; CLEMENTES; KAZMAN, 2003).
Assim, a arquitetura define os componentes ou elementos de um sistema, subsidiando
a própria divisão do desenvolvimento, uma vez que cada equipe sabe exatamente o que a sua
parte deve fazer em relação ao todo. Desse modo, todo sistema tem uma arquitetura, ainda
que, em alguns casos não ideais, ela não tenha sido concebida de modo prévio e deliberado.

1.2.2. Modelo de análise e projeto

Construir uma Arquitetura de Software requer, essencialmente, um modelo geral


e panorâmico de seu funcionamento, que servirá como uma espécie de mapa e de norte
para o desenvolvimento do sistema, guiando a atuação de engenheiros e programadores.
Isso ocorre porque o desenvolvimento de um software é algo complexo, e sua com-
preensão fica facilitada quando o problema é decomposto em partes menores que, em
conjunto, formarão a Arquitetura de
Software (LARMAN, 2007).
Para a construção desse modelo,
é bastante recomendada a utilização
© MicroOne / / Shutterstock

da Linguagem de Modelagem Unifi-


cada (UML, na sigla em inglês), própria
para esse tipo de descrição de sistemas
(LARMAN, 2007).

Contexto
O uso de modelos é tão importante no processo de desenvolvimento de soft-
ware que cada vez tem ganho maior centralidade e preponderância. Tem-se, por exemplo, a
arquitetura dirigida por modelo e também uma metodologia de testes nela baseada. (UZUN;
TEKINERDOGAN, 2018).

Construir um modelo adequado e útil, que não crie dificuldades ou problemas para as
etapas seguintes, requer algumas características e propriedades balizem o seu desenvolvi-
mento. Isso inclui coesão e acoplamento.

24 Arquitetura de software
1.2.3. Coesão e acoplamento

Ao modelar e fazer a definição das funções de cada um dos componentes da Arqui-


tetura de Software, é importante buscar atender às principais características de coesão e
acoplamento, uma vez que, dessa observância, tende a emergir um projeto robusto e que
não gerará dificuldades e conflitos na fase de desenvolvimento e codificação.
O primeiro conceito, de coesão, guarda
sentido, primeiramente, com as funções atri-
buídas a um dado componente. A ideia por
ela expressa é de que essas funções devem
ser coesas e relacionadas. É de se imaginar

© tasani bin abdul hamid / / Shutterstock.


que um módulo de gestão de folha de paga-
mentos também cuide, eventualmente, dos
controles de apontamentos e bancos de
horas. Porém seria pouco razoável incluir no
mesmo componente o processamento de
balanço contábil ou controle de caixa.
Em termos de acoplamento, tem-se a ideia de um encaixe adequado entre os múlti-
plos componentes, ou seja, eles se completam e possuem uma boa interdependência. Em
outras palavras, não extrapolam suas funções nem se sobrepõem uns aos outros.
Somando ambos conceitos, podemos fazer uma analogia com um quebra-cabe-
ças: cada peça tem a forma exata do local onde deve ser encaixada, não sendo maior
nem menor, sem sobreposições, ou seja, é o acoplamento perfeito. A imagem de sua face
envolve somente elementos daquela parte da imagem total, pixel a pixel, próximos e corre-
lacionados: é a coesão.
Mas não só destes atributos se faz uma boa Arquitetura de Software. É preciso, ainda,
adequar o nível de abstração às necessidades do projeto.

1.2.4. Níveis de abstração

Abstração é a capacidade, única de nossa espécie, de, a partir de vários elementos


dispersos, construir uma correlação superior que não está, ao menos em seu todo, explí-
cita. É encontrar significado em partes sem uma lógica previamente conhecida, podendo
dar-se por analogia, inferência e outros métodos.

Arquitetura de software 25
© Kirasolly / / Shutterstock.
Porém, é fácil perceber que uma abstração pode ser feita em diversos níveis, depen-
dendo do foco e da necessidade. Quanto mais alta a abstração, menor o nível de detalha-
mento, porém mais amplo o alcance do modelo. Isso é especialmente útil quando há um
grande número de funções distintas, uma vez que a visão mais panorâmica facilitará a
construção do modelo e o posterior desenvolvimento.
Quanto mais baixa, mais detalhada – e maior a especificidade abrangida. Torna-se
pertinente quando temos um número menor de funções, porém com complexidade e parti-
cularidades maiores. Contudo, não há regras: caberá ao profissional compreender qual é a
abstração mais adequada a cada projeto.

Pausa para refletir

Por trás desta etapa importante do desenvolvimento de software certamente estará ao


menos um profissional. Quais os desafios que ele irá enfrentar? Como ele deve conduzir a
construção da Arquitetura de Software em um dado projeto?

Podemos resumir os últimos três tópicos no quadro a seguir.

Síntese das características ideais da Arquitetura de Software e suas propriedades

Característica Propriedade

Coesão Funções relacionadas dentro de cada componente.

Acoplamento Complementariedade e interdependência dos componentes.

Abstração Nível de simplificação do modelo geral.

26 Arquitetura de software
Desse modo, podemos perceber o quanto a coesão, o acoplamento e a abstração
são aspectos importantes a serem considerados pelo arquiteto de software em sua atua-
ção profissional. A seguir, começaremos a explorar um pouco mais sobre sua atuação e seu
papel em um projeto de desenvolvimento de software.

1.3. Arquiteto de Software

Por traz de uma Arquitetura de Software


bem construída e que, efetivamente, sustente um

© Monkey Business Images / / Shutterstock.


eficiente e fluido desenvolvimento, está a figura
de um profissional de suma importância, em espe-
cial em projetos de grande complexidade.
Essa construção da Arquitetura de Software
fica a cargo do Arquiteto de Software, que é o pro-
fissional especializado na implementação dessa
importante etapa inicial dos projetos de desenvolvimento de sistemas. Para isso, ele preci-
sará compreender bem o seu papel e como deverá exercê-lo para atingir seus objetivos.

1.3.1. Papel do arquiteto de software

A atividade do arquiteto de software está


presente em todo e qualquer projeto de desen-
volvimento de sistemas, independentemente
© Syda Productions / / Shutterstock

de o cargo específico existir formalmente ou


não. Afinal, elaborar o design geral é uma ati-
vidade que precisará, de algum modo, ser
feita, explícita ou implicitamente, planejada ou
resultante, detalhada ou simplificada.
Todavia, em cenários mais complexos ou com um volume grande de projetos con-
comitantes, a tendência é que se adote a contratação de um profissional especializado, o
Arquiteto de Software.
Nesse contexto, esse profissional – usualmente o único (ou um dos poucos) que exer-
cem essa função numa organização – ficará responsável exclusivamente pelo desenvolvi-
mento das arquiteturas de software dos projetos. Em outras palavras, todos os sistemas
passarão primeiro por suas mãos, cabendo a esse profissional a responsabilidade de desen-
volver modelos adequados e que permitam que a continuidade do desenvolvimento e codi-
ficação se deem de modo fluido e eficiente.

Arquitetura de software 27
Em seu papel, o arquiteto precisa lidar
com diversos fatores humanos e sociais den-
tro das organizações. Primeiramente, há a
relação com engenheiros de software, que
pode ser delicada em virtude de haver algu-
mas áreas de penumbra, ou seja, de sobrepo-
© Fotos593 / / Shutterstock

sição entre as funções. Se isso não for bem


administrado e amenizado por meio de um
bom relacionamento, pode tornar-se uma
grande e persistente fonte de conflitos.
Não menos importantes são as etapas seguintes de engenharia e programação, que
não podem receber um grande elefante branco, que seria de difícil desenvolvimento, inte-
gração, manutenção e atualização. Entregar a essa equipe um design mal elaborado será
fonte de conflitos, atrasos e desperdício de recursos.
Além disso, o desenvolvimento da Arquitetura de Software requer do profissional
mais do que simplesmente conhecimento técnico e experiência. É preciso que haja uma boa
comunicação e capacidade de abstração, uma vez que o bom desempenho de seu traba-
lho dependerá da adequada captação das necessidades e desejos dos diversos stakeholders
envolvidos no projeto, além da habilidade de negociar expectativas por vezes conflitantes.
Assim, é essencial que o arquiteto de software conheça seu contexto de atuação.

1.3.2. Contexto de atuação

O cargo de arquiteto de software é mais frequente em empresas de grande porte,


com muitos projetos simultâneos e/ou poucos projetos, porém de alta complexidade. E há
uma razão para isso.
Primeiramente, é preciso levar em conta que sua atuação é concentrada nos estágios
iniciais de um software, com pouca participação – apesar de existente – no restante do pro-
cesso de desenvolvimento. Afinal, se esse profissional se envolver permanentemente nas eta-
pas seguintes, talvez acabe fazendo mais sentido seu cargo ser de engenheiro de software.
Assim, se não houver uma demanda significativa, em quantidade ou complexidade, é
difícil justificar a presença de um colaborador exclusivo para a função de arquiteto de soft-
ware. O quadro a seguir apresenta, didaticamente, a probabilidade de atuação de um pro-
fissional dedicado exclusivamente à função de arquiteto de software em uma empresa,
com base na complexidade e quantidade de projetos.

28 Arquitetura de software
Probabilidade de atuação de um Arquiteto de Software segundo a quantidade de pro-
jetos e respectiva complexidade

Complexidade do(s) Projeto(s)

Quantidade de Projetos Baixa Alta

Poucos Improvável Provável

Muitos Possível Indispensável

Além disso, são profissionais que costumam atuar sozinhos ou, no máximo, em uma
pequeníssima equipe. Por serem raros aqueles com experiência e domínio da área, acabam
sendo bem remunerados – uma restrição para pequenas organizações.

1.4. Casos de Uso

Quanto mais complexo for o contexto de desenvolvimento de software, mais impor-


tante é o papel do arquiteto de software. Isso será ilustrado em um exemplo bastante inco-
mum, visando contemplar melhor a aplicação dos conceitos estudados.
Àqueles profissionais que desejam desenvolver essa função, é necessário não se
assustar diante de áreas complexas e desconhecidas como a que ilustraremos a seguir. Ao
contrário: essa situação deve ser familiar no sentido de que será o arquiteto de software
que irá traduzi-la num modelo bem construído, robusto e compreensível para todos os
envolvidos no projeto.

1.4.1. Exemplo de aplicação

Para compreender, de um modo prático e


aplicado, a Arquitetura de Software e o traba-
lho do profissional que o desenvolve, podemos
pensar em um novo projeto fictício de sistema:
© dominika zarzycka / / Shutterstock.

a criação de um software de gestão do primeiro


laboratório de aceleração de partículas do Brasil.
Não é necessário entender da avançada
Física envolvida neste empreendimento – ace-
lerar partículas subatômicas e colidi-las para

Arquitetura de software 29
estudar elementos que as compõem – para compreender que se trata de um projeto de
software totalmente novo. Para esse projeto, não temos uma arquitetura de referência no
Brasil – é o primeiro laboratório nacional do tipo – nem no exterior, uma vez que, pelo fato
de o projeto ser altamente estratégico e uma área de ponta na ciência, essas questões são
tratadas como segredo absoluto, por vezes por políticas do próprio país.
Num cenário como esse, o papel do arquiteto de software tem grande relevância,
pois não é razoável que se parta diretamente para etapas de desenvolvimento, monta-
gem de equipe, distribuição de tarefas etc. Antes disso, é fundamental que seja concebido
um design geral do que será necessário, quais são os componentes de software que serão
necessários, as devidas conexões, as necessidades dos stakeholders etc.
O profissional dessa área irá se deparar com diversos desafios, uma vez que, prova-
velmente, não haverá familiaridade nenhuma dele com a área específica e pouco material
de referência. Por isso, as reuniões, discussões e negociações com os stakeholders serão
fundamentais para o sucesso dessa etapa de planejamento, bem como das fases posterio-
res do desenvolvimento.

1.4.2. Custo e benefícios

Obviamente, esse projeto terá custos. Primeiramente, a própria necessidade de con-


tratação do arquiteto de software (se esse profissional não fizer parte da equipe) será um
necessário dispêndio, porém não o único. Certamente, dada a complexidade do projeto e
da atividade, não será algo a ser resolvido em questão de poucos dias ou semanas.
Neste exemplo, não seria nenhuma surpresa se o adequado desenvolvimento da
arquitetura deste software levasse alguns meses para ser concluído. Obviamente, o tempo
é um recurso importante e custoso, que seria dispensado nessa etapa. Além disso, é pre-
ciso considerar que o restante da equipe pouco poderá fazer enquanto essa fase não esti-
ver concluída, podendo incidir em custos adicionais se essa equipe não estiver alocada em
outro projeto nesse período.
Mas, apesar de tudo, os benefícios justificam esse custo. Num projeto de grande
complexidade, como é o caso deste exemplo, são muito grandes as chances de insucesso
se esta etapa for pulada. Pode-se imaginar que o sistema, se for desenvolvido de forma
inadequada, não atenderá a algumas funções, fazendo com que alguma atribuição opere
de maneira imprópria ou com que tamanha falha de integração torne necessário voltar
às fases iniciais de concepção. Obviamente isso representaria um custo e um risco muito
maior, que não merecem ser incorridos.

30 Arquitetura de software
© LeoWolfert / / Shutterstock.
Ao desenvolver sua missão, o arquiteto de software pode tomar o teorema ou prin-
cípio de Pareto, que, muito resumidamente, estabelece uma relação 20/80 entre causa e
efeito. Nesse contexto, podemos imaginar que 20% dos componentes responderão por
80% das funções do sistema em nosso exemplo. Assim, é razoável inferir que o profissional
deve estar focado em identificar esses elementos-chave e em uma especificação mais cui-
dadosa desses elementos, deixando os demais num plano um pouco menos relevante.

Contexto
O teorema ou princípio de Pareto possui diversas aplicações em várias áreas, e sua
justificativa é bem mais ampla do que esta aqui apresentada. Você pode conhecer mais esse
teorema na obra O Princípio 80/20 - Os Segredos Para Conseguir Mais Com Menos Nos Negó-
cios e na Vida (KOCH, 2015).

A principal forma de apresentar uma arquitetura de software se dá por meio de um


modelo visual, tendo em vista o quanto ele facilita a compreensão e a transmissão das
informações gerais de um dado projeto de desenvolvimento de software.

1.4.3. Modelo Visual do Sistema (MVS)

Para executar adequadamente um projeto, a utilização de uma modelagem visual


é um recurso extremamente útil, pois facilita a abstração e reflexão, bem como funciona
como uma boa base para as discussões com os diversos stakeholders envolvidos (cientistas,
professores, fontes financiadoras, ministério da ciência e tecnologia, universidades etc.).

Arquitetura de software 31
Essa Modelagem Visual do Sistema (MVS) possui diversas abordagens, sendo que
cada uma pode ser mais adequada a determinados contextos. Porém, nesta disciplina,
basta entender o conceito geral, de uma representação que abranja os principais elemen-
tos que precisarão ser atendidos pelo sistema. Essa modelagem pode ter um foco maior
nos processos ou nos módulos/unidades, ser mais detalhado ou resumido, panorâmico ou
analítico. Cada necessidade irá moldar o modelo visual que o representa.
Todavia, em todos os casos, deve-se levar em consideração que a modelagem de um
sistema precisa ser suficientemente resumida para ser útil. Como exemplo, pode-se pen-
sar em uma maquete em escala natural (ou seja, em tamanho real): exceto em casos bem
específicos, isso seria inútil, pois se perderia justamente a maior utilidade da maquete, que
é uma visão geral e panorâmica de um dado local ou construção, em um tamanho redu-
zido. Por analogia, assim deve ser uma visão geral de um modelo visual do software.
O exemplo da criação de um software de gestão do primeiro laboratório de acelera-
ção de partículas do Brasil, por ser complexo, não permite que, no escopo deste capítulo,
construamos um MVS realista, pois precisaríamos, antes, explorar as diversas particulari-
dades da área, do projeto do laboratório, necessidades dos stakeholders etc. Entretanto, é
possível ilustrá-lo no esquema a seguir.

Representação de um possível MVS para o caso de uso em análise

Equipamentos Registro de
Equipamentos
de controle de ponto e gestão
científicos
acesso físico de folha

Controle
Sistemas Cadastro e
Coleta e análise autenticação
nativos dos gerenciamento
de dados e acesso aos
equipamentos de acesso
sistemas

Gestão Controle e
financeira, Gestão de Módulo de
monitoramento
de compras e documentos manutenção
das instalações
despesas

Gestão
financeira, Administração
de compras e geral
© DTCOM

despesas

32 Arquitetura de software
Obviamente, dada a complexidade, o modelo visual anterior não passa de um
modesto rascunho. Todavia, poderia constituir-se como uma base inicial para o desenvolvi-
mento real, a partir da interação com os stakeholders envolvidos e uma maior compreensão
dos desafios propostos.

Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa,
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.

Agora é a hora de recapitular tudo o que você aprendeu neste capítulo! Elabore, em MVS
(Modelo Visual de Sistema), um esboço de uma Arquitetura de Software para um sistema
de bibliotecas em uma universidade, procurando destacar as principais ideias abordadas ao
longo do capítulo, relacionando-as com essa elaboração. Ao produzir sua proposta de arqui-
tetura, considere as leituras básicas e complementares realizadas.

Recapitulando

Ao longo do capítulo, estudamos que a Arquitetura de Software é um elemento de


suma importância em qualquer projeto de desenvolvimento de software, pois se trata, em
linhas gerais, de uma abstração geral do sistema que será desenvolvido, definindo compo-
nentes e conexões que o formarão.
Além disso, seu desenvolvimento e a dedicação de uma ou mais pessoas para essa ati-
vidade pode ensejar custos, justificados pelos benefícios que o seguem, em especial o fato de
permitir um fluxo mais ordenado e assertivo para as etapas de programação que o seguirão.
Também estudamos que o arquiteto de software é o profissional responsável por essa
etapa do processo, cabendo a ele a habilidade de abstrair as necessidades dos diversos
stakeholders. Isso tudo, somado aos seus conhecimentos técnicos e requisitos do projeto,
construirá o modelo que guiará as fases subsequentes.
Por fim, vimos que a presença desse profissional costuma estar associado à projetos
de maior complexidade ou empresas com grande volume de projetos simultâneos.

Arquitetura de software 33
Referências

ARQUITETURA. In: WEISZFLOG, W. Michaelis Moderno Dicionário da Língua Portu-


guesa. 2004. São Paulo: Moderna. Disponível em: <michaelis.uol.com.br>. Acesso em:
09/11/2018.
BASS, L.; CLEMENTES, P.; KAZMAN, R. Software Architecture in Practice. 2. ed. Boston:
Addison-Wesley Professional, 2003.
FOWLER, M. Padrões de Arquitetura de Aplicações Corporativas. 1. ed. Porto Alegre:
Bookman, 2006.
FUNDAÇÃO Oscar Niemeyer. Museu Oscar Niemeyer. Disponível em: <www.niemeyer.
org.br/obra/pro513>. Acesso em: 13/11/2018.
KOCH, R. O Princípio 80/20 - Os Segredos Para Conseguir Mais Com Menos Nos Negócios
e na Vida. 1. ed. Belo Horizonte: Gutenberg, 2015.
LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e ao projeto orientado
a objetos. 3. ed. Porto Alegre: Bookman, 2007.
LIONS, J.-L. ARIANE 5: Flight 501 Failure. 1996. Disponível em: <www.sunnyday.mit.edu/
nasa-class/Ariane5-report.html>. Acesso em: 31/10/2018,
UZUN, B.; TEKINERDOGAN, B. Model-driven architecture based testing: A systematic
literature review. 2018. Information and Software Technology, 30-48. Disponível em: <doi.
org/10.1016/j.infsof.2018.05.004>. Acesso em: 12/11/2018.

34 Arquitetura de software
CAPÍTULO 2

O modelo 4 + 1
Sidartha Azevedo Lobo de Carvalho

OBJETIVOS DO CAPÍTULO
• Documentar uma arquitetura e diferenciar modelo, framework, estilos e padrões
utilizando as visões arquiteturais do modelo 4+1.

TÓPICOS DE ESTUDO

Documento de Arquitetura de
1 Diferentes conceitos 3
Sistema (DAS)

• Modelo de referência. • Visão geral.


• Framework. • Como utilizar.
• Estilos.
• Padrões.

2 4+1 e a visão de cenários de uso

• Visão lógica.
• Visão de processo.
• Visão física.
• Visão de desenvolvimento.

Arquitetura de software 35
Contextualizando o cenário

A arquitetura de software é utilizada para definir a organização dos elementos de um sis-


tema e suas propriedades. Normalmente, ela define a disposição dos requisitos não funcio-
nais da aplicação e também a disposição dos relacionamentos entre seus elementos.

Como às vezes os requisitos são conflitantes, a arquitetura de software visa balanceá-los da


melhor maneira para que o sistema seja implementado da forma correta. Nesse sentido, as
diferentes visões fornecem formas de organizar os elementos do sistema.

Para balancear os requisitos, em 1995, Krushten desenvolveu um modelo de visão arquitetu-


ral denominado 4+1. Esse modelo tem como objetivo principal fornecer visões em diferentes
perspectivas do software, permitindo que cada visão foque em um determinado conjunto de
características.

Dito isso, surge a questão: Como funcionam as visões de Krushten? E como elas auxiliam
a arquitetura de software?

36 Arquitetura de software
2.1. Diferentes conceitos

A arquitetura de um software consiste no mapeamento dos requisitos para que


se cumpra o objetivo do sistema em questão. Essa arquitetura deve contemplar tanto os
requisitos funcionais como os não funcionais.
Para se chegar a arquitetura de software de um sistema, podemos partir de uma
arquitetura de referência para o domínio específico da aplicação, ou seja, podemos usar
uma arquitetura já pronta que contém os principais conceitos necessários para a constru-
ção do sistema em questão. A figura a seguir ilustra a relação entre os conceitos que ire-
mos abordar nessa seção:

Modelo de
referência
Arquitetura de Arquitetura de
referência software
Estilos de
arquitetura

Padrões

© DTCOM
Os estilos de arquitetura são compostos principalmente por padrões de software.
Esses estilos, juntamente com o modelo de referência, resultam na arquitetura de refe-
rência, que, por sua vez, serve de base para a construção da arquitetura de software.
Para que esses conceitos fiquem claro, nos próximos tópicos iremos detalhar os mode-
los de referência de uma arquitetura, a utilidade e o uso dos frameworks, além dos estilos e
padrões empregados nas fases de arquitetura durante a construção de um software.

2.1.1. Modelo de referência

O modelo de referência é formado pela decomposição padronizada do problema (con-


ceitos/funcionalidades do sistema/arquitetura formados a partir do modelo), abordado em
partes menores para formar a solução. Esses problemas são definidos a partir da colaboração
de diversos especialistas que percebem que ele é recorrente no domínio. Após esse processo
de amadurecimento da solução, temos o modelo de referência (KRUCHTEN, 1995).

Arquitetura de software 37
Ainda segundo Kruchten (1995), a arquitetura de referência é um tipo especial de
arquitetura de software. Essa última, como é mais genérica e definida em um alto nível de
abstração, permite incluir as regras de negócio, os estilos e os padrões arquiteturais.
A arquitetura de referência, portanto, se difere da arquitetura de software por não
possuir um grupo bem definido das partes interessadas. Ou seja, nesse tipo de arquitetura,
o sistema encontra-se em uma fase inicial, sendo algumas entidades e relacionamentos
ainda desconhecidos.
Pode-se dizer que a arquitetura de referência objetiva garantir mais atributos de
qualidade arquitetural e, além disso, permite que os requisitos não funcionais sejam res-
peitados. Assim, elas são projetadas para serem aplicadas a um domínio particular, sendo
construídas a partir de um estudo do domínio ao invés de um sistema já existente.

© Kit8.net // Shutterstock

Os frameworks, por sua vez, são instrumentos utilizados para prover o reuso de
código/funcionalidades para o desenvolvimento de aplicações mais específicas. Assim, um
framework é a implementação das arquiteturas de referência para a resolução de proble-
mas específicos.
No próximo tópico iremos detalhar melhor os frameworks no contexto da arquitetura
de software.

38 Arquitetura de software
2.1.2. Framework

Um framework de arquitetura repre-


senta um conjunto de componentes que
são utilizados para criar uma determinada

© Sinart Creative // Shutterstock


arquitetura. O uso desses frameworks é pri-
mordial para acelerar o desenvolvimento de
sistemas, uma vez que eles auxiliam na abs-
tração de complexidades quanto à infraes-
trutura e outras características complexas.
Segundo Pressman (2011, p. 40):

Uma metodologia (framework) de processo estabelece o alicerce para um processo de


engenharia de software completo, por meio da identificação de um pequeno número
de atividades estruturais aplicáveis a todos os projetos de software, independente-
mente de tamanho ou complexidade. Além disso, a metodologia de processo engloba
um conjunto de atividades de apoio (umbrella activities — abertas) aplicáveis em todo
o processo de software.

Pode-se dizer, portanto, que a utilização de frameworks auxilia na composição de


novas arquiteturas, uma vez que eles apresentam uma estrutura preestabelecida e tornam
a arquitetura mais padronizada.
Uma categoria bastante utilizada são os frameworks para desenvolvimento web e
mobile. Veja alguns exemplos:
• ASP.NET: ASP.NET Dynamic Data, ASP.NET MVC, ASP.NET Web Forms, BFC,
DotNetNuke, MonoRail, OpenRasta e Umbraco.
• JAVA: AppFuse, Flexive, Grails, GWT, ICEfaces, ItsNat, JavaServer Faces, Jspx,
Juzu, dentre outros.
• JavaScript: Ample SDK, AngularJS, Backbone.js, Chaplin.js, jQuery, Wakanda,
dentre diversos outros.
Os frameworks mais utilizados pela indústria de software, por outro lado, são o
TOGAF e o ZACHMAN, sendo específicos para a construção de arquiteturas em diferentes
níveis de abstração.
Esse é um pequeno exemplo da quantidade de frameworks disponíveis para as dife-
rentes linguagens. Cada um tem suas especificidades e são melhor aproveitados depen-
dendo do contexto e do domínio da aplicação. No próximo tópico iremos detalhar melhor
os estilos arquiteturais.

Arquitetura de software 39
2.1.3. Estilos

O estilo de arquitetura é um atributo das arquiteturas de software. Esse atributo


impõe algumas regras que devem ser seguidas para garantir a uniformidade na arquitetura.
Segundo Kruchten (1995), um estilo arquitetural pode ser representado como a
agregação de um conjunto de características que são repetidas em diversos sistemas, ou
seja, um conjunto de escolhas já feitas que serão aplicadas na construção de novas arquite-
turas. Um sistema que adere a um determinado estilo, nesse sentido, herda as característi-
cas do estilo escolhido, sendo utilizados para descrever aquela arquitetura.

Esclarecimento
Uma determinada arquitetura pode aderir a mais de um estilo arquitetural, con-
tendo características de diferentes estilos.

O estilo é definido como um conjunto de padrões, componentes ou conectores que


funcionarão como a base de uma arquitetura. Os estilos são utilizados para expressar
esquemas da organização estrutural dos sistemas, fornecendo um mapeamento dos com-
ponentes do sistema, além de suas responsabilidades e interações (KRUCHTEN, 1995).
Cada estilo arquitetural trabalha com diferentes tipos de atributos de qualidade e,
para saber se o estilo é adequado à construção de uma determinada arquitetura, deve-se
confrontar os atributos mais relevantes da solução com os atributos do estilo.

Pausa para refletir

Como o estilo arquitetural está relacionado ao processo de construção da arquitetura de


software?

Como exemplo de estilo, podemos citar o modelo Cliente-Servidor. Nesse caso, a


palavra modelo e estilo são usadas como sinônimos.
O Cliente tem como atribuição principal fazer pedidos ao servidor e esperar as res-
postas desses pedidos. Um pedido é uma requisição de um cliente (usuário, outro sis-
tema, dentre outros) para um servidor de dados ou aplicações requisitando algum dado.
Após receber as respostas, o cliente pode realizar o processamento desejado com os dados

40 Arquitetura de software
recebidos. Ele geralmente se conecta a um número pequeno de servidores simultanea-
mente e faz uso de recursos de rede. Quando não definido previamente, é comum que essa
interação entre cliente e servidor utilize um protocolo sem muita padronização estabele-
cida pelo desenvolvedor.
Por outro lado, cabe ao Servidor esperar um pedido de requisição por parte do
cliente. Assim, ele deve estar sempre preparado para receber solicitações. Geralmente é
criada uma classe principal, que fica executando dentro de um laço infinito, só para receber
as requisições. Ao receber uma solicitação, o servidor abre uma thread de execução com a
requisição e volta a esperar novas requisições.

Esclarecimento
Uma thread de execução é uma linha de execução distinta da execução atual do
programa, ou seja, que executa em paralelo.

O servidor pode se conectar a outros servidores ou a diversos bancos de dados para


responder a requisição do cliente. Além disso, ele deve contar com uma boa infraestrutura
de hardware, mensurada de acordo com a previsão de requisições que irá atender.
A figura a seguir ilustra esse estilo arquitetura:

Modelo Cliente Servidor

Clientes
© VasutinSergey // Shutterstock

Servidor

A seguir, observe a série de vantagens que o estilo de arquitetura Cliente-Servidor


apresenta:

Arquitetura de software 41
• Apresenta uma divisão clara de papéis e responsabilidades, o que facilita a
manutenção;
• Possibilita a conexão com vários servidores em rede, aumentando a escalabilidade
do sistema;
• Investe mais em segurança, uma vez que apresenta uma estrutura centralizada.
Isso permite que os canais de entrada e saída de dados sejam visualizados de
forma clara, bem como o gerenciamento de acessos.
• Facilita a atualização de dados. Isto porque, como a maioria do processamento é
feita pelo servidor, não há necessidade de clientes com alto poder de processa-
mento ou armazenamento.
A arquitetura Cliente-Servidor também possui algumas desvantagens. Pode haver
sobrecarga no servidor em determinadas situações em que o fluxo de requisições é maior
que o normal, por exemplo. Portanto, é importante estimar de forma correta o fluxo de
dados para que essa sobrecarga não aconteça. Outro problema recorrente nesse tipo de
arquitetura é o ponto de falha centralizado. Se o servidor principal fica indisponível, por
exemplo, todos os clientes ficam sem poder acessar o serviço se não houver servidores
adicionais.
Outro exemplo de estilo arquitetural é o modelo Peer to Peer, “concorrente” direto
do estilo arquitetural Cliente-Servidor. Nesse modelo, a conexão entre os elementos é reali-
zada de forma não centralizada, sendo cada nó da rede independente para emitir, rotear e
receber dados.
Quando comparado ao estilo Cliente-Servidor, o Peer to Peer possui uma distribuição
horizontal, enquanto o Cliente-Servidor conta com uma distribuição vertical. Por um lado,
um sistema de distribuição vertical facilita o gerenciamento, uma vez que divide as respon-
sabilidades de processamento entre várias máquinas. Em contrapartida, uma distribuição
horizontal, como a utilizada na abordagem Peer to Peer, divide o processamento entre os
clientes e servidores.
Assim, podemos dizer que na distribuição horizontal, todas as funções necessárias
para o processamento e roteamento de dados devem estar presentes em todos os clientes
e em todos os servidores. Ou seja, todo cliente e todo servidor pode atuar como cliente ou
como servidor dependendo do processamento a ser realizado.
Os sistemas Peer to Peer não dependem da existência de alguma entidade centrali-
zada, seja para processamento ou para administração. Nesse sentido, nos sistemas decen-
tralizados desse estilo arquitetural, todos os nós são iguais, não havendo nenhum especial
para administração ou descoberta de serviços. No entanto, há alguns nós especiais para

42 Arquitetura de software
gerenciamento dos demais nós, não sendo totalmente descentralizados, por exemplo, o
aplicativo BitTorrent que faz uso do protocolo Torrent.
No próximo tópico iremos discorrer sobre os padrões de software. Como os padrões
podem ser de projeto, de arquitetura, entre outros, iremos aborda-los de forma genérica
para depois focar em um nicho específico.

2.1.4. Padrões

Os padrões da engenharia de software permitem que os desenvolvedores façam uso


de soluções já existentes para problemas recorrentes no desenvolvimento de uma aplicação.
Nesse sentido, podemos ter padrões de arquitetura de software, padrões de análise, padrões
de projeto, padrões de teste, padrões de implementação, dentre outros. (GAMMA, 2000).
Assim, os padrões de projeto dispõem de um
esquema para melhoramento de componentes ou sub-
sistemas de um sistema (GAMMA et al., 2000). Já os
padrões arquiteturais expressam a organização funda-
mental para uma estrutura.

© Macrovector // Shutterstock
Um padrão deve conter as seguintes informa-
ções: nome do padrão, contexto, problemática e solu-
ção. A seguir, temos um exemplo de um padrão,
chamado de Broker (KRUCHTEN, 1995).
Nome: Broker
Contexto: Ambiente distribuído
Problemática: Auxilia na definição dos meios de comunicação entre os componentes
de um sistema.
Solução: É necessário criar um intermediário entre o cliente e o servidor. O cliente
envia uma mensagem para o intermediário (Broker) contendo todas as informações
para que a comunicação seja efetuada.
Para a definição dos padrões de arquitetura, Pressman (2011) sugere que o docu-
mento deve conter as seguintes informações:
• Problema de Projeto: apresenta os problemas que a arquitetura está tentando
resolver, definidos de forma clara e não ambígua.
• Resolução: apresenta a abordagem escolhida como a melhor para resolver o
problema.

Arquitetura de software 43
• Categoria: descreve o projeto de dados, a estrutura de conteúdo, a comunicação,
além da integração e da apresentação dos componentes.
• Hipóteses: apresenta as propostas que podem ajudar na resolução do problema.
• Alternativas: apresenta alternativas de projeto da arquitetura e o motivo da rejei-
ção dessas alternativas.
• Argumento: descreve as justificativas de escolha da arquitetura.
• Implicações: descreve as consequências de uso da arquitetura no projeto, devendo
responder como tal escolha pode afetar outras partes do projeto.
• Decisões relacionadas: descreve quais outras decisões foram tomadas ou cogitadas.
• Necessidades relacionadas: descreve outras necessidades relacionadas à arquite-
tura proposta.
• Artefatos: descreve os artefatos que sofrerão mudanças em decorrência das deci-
sões tomadas.
• Notas: apresenta, de forma geral, as anotações da equipe que não foram contem-
pladas nos tópicos anteriores, mas que podem ser acrescentadas.
No próximo tópico iremos detalhar o modelo proposto por Kruchten, o modelo 4+1.

2.2. 4+1 e a visão de cenários de uso

Nos tópicos anteriores, vimos os conceitos relacionados as arquiteturas de forma


geral, sem utilizar um modelo específico para representar essa arquitetura. Agora iremos
aprofundar nosso conhecimento utilizando um modelo bastante difundido, chamado 4+1,
desenvolvido por Philippe Kruchten em 1995. Nesse modelo, é descrito diferentes visões
de uma mesma arquitetura para melhor compreender suas características.

Biografia
Philippe Kruchten, nascido em 1952, é um engenheiro de software canadense. Ele
também é professor na universidade British Columbia em Vancouver, Canadá. Em 1995, Philippe
desenvolveu o modelo de visão arquitetural 4+1 (UNIVERSITY OF BRITISH COLUMBIA, 2018).

44 Arquitetura de software
O modelo 4+1 fornece diferentes perspectivas de visualização da arquitetura. Assim,
ele é composto por cinco visões distintas, sendo elas: a visão lógica, a visão de processo,
a visão física, a visão de desenvolvimento e a visão utilizando cenários, como ilustra o
esquema a seguir:

Visão de
Visão lógica desenvolvimento

Cenários

Visão de
Visão física
processo

© DTCOM
Fonte: Adaptado de Kruchten,1995, p. 2

As quatro visões ilustradas dentro do retângulo devem trabalhar de forma conjunta e


ser descritas pelos casos de uso mais gerais (cenários). Os cenários, por sua vez, são abstra-
ções dos requisitos mais importantes da arquitetura e são expressos utilizando objetos que
compõem o sistema que está sendo modelado.
O termo “4+1” se dá pelo fato desse modelo contar com quatro visões distintas e, ao
final, utilizar os casos de uso (+1) para ilustrar as demais visões. Esses cenários de caso de
uso, nesse sentido, exploram os elementos de arquitetura durante sua construção e servem
de instrumento de validação e ilustração após a finalização da construção da arquitetura.
Nos próximos tópicos iremos descrever em detalhe cada visão desse modelo.

2.2.1. Visão lógica

A visão lógica é o design do modelo de objetos para sistemas orientados a objetos.


Nela, o sistema é composto por um conjunto de abstrações retiradas principalmente do
domínio do problema, fornecendo suporte às funcionalidades que os usuários necessitam
(KRUCHTEN, 1995).
Ainda segundo Kruchten (1995), essa etapa de modelagem da visão lógica serve para
identificar os possíveis elementos que podem ser reutilizados dentro de todo o sistema.
Um método que verifica a autenticidade de um usuário, por exemplo, pode ser repetido em
diversas páginas web.

Arquitetura de software 45
A visão lógica utiliza diagramas de classe, mostrando um conjunto de classes e suas
relações. A partir desse conjunto, pode ser definido um template de classe, utilizado para
definir operações principais e identificar os objetos chave (KRUCHTEN, 1995). Além disso,
temos o diagrama do estado de transição, utilizado para representar o comportamento
interno de um objeto.
A seguir, a figura ilustra a representação dos componentes do modelo da visão lógica:

Componentes Conectores
Associação
Classe
Agregação
Classe de Uso
utilidade
Herança
Classe Instanciação
parametrizada

Categoria
de classe

© DTCOM
Fonte: adaptado de Kruchten, 1995, p. 3.

Dando continuidade ao modelo 4+1, no próximo tópico iremos descrever a visão de


processo deste modelo.

2.2.2. Visão de processo

A visão de processo visa encaixar as principais abstrações da visão lógica no processo


arquitetural, endereçando preocupações diferentes. Ou seja, nessa visão é a feita a decom-
posição do sistema através do mapeamento das classes e dos subsistemas. Nessa visão,
também são levados em consideração alguns requisitos não funcionais, como desempenho
e disponibilidade.
O processo é o agrupamento de tarefas que forma uma unidade executável. Assim,
os processos representam o nível de abstração do processamento computacional que
pode ser controlado, sendo iniciado, recuperado, reconfigurado ou desligado, por exemplo
(KRUCHTEN, 1995).
Uma tarefa é uma thread de execução separada que pode ser escalonada individual-
mente (TANENBAUM, 2003). Essas tarefas podem ser diferenciadas pelo tamanho da
tarefa. Enquanto as tarefas maiores podem ser elementos arquiteturais e identificadas de
forma única, as tarefas menores sempre são implementações locais.

46 Arquitetura de software
A figura abaixo identifica os elementos utilizados na criação da arquitetura na visão
de processo.

Componentes Conectores

Sem especificação

Processo Mensagem
Chamada de procedimento remoto
Mensagem bidirecional
Processo
simplificado Evento de broadcast

Processo

© DTCOM
periódico

Fonte: Adaptado de Kruchten,1995, p. 5.

Dando continuidade ao estudo do modelo 4+1, iremos estudar a visão física na pró-
xima seção.

2.2.3. Visão física

A visão física permite o mapeamento do software para o hardware. Ela foca princi-
palmente nos requisitos não funcionais do sistema, como disponibilidade, tolerância a
falhas, desempenho e escalabilidade. Quando o software executa em uma rede de compu-
tadores, por exemplo, os vários elementos identificados podem ser: redes, processos, tare-
fas e objetos. Esses elementos identificados são mensurados para garantir os requisitos
não funcionais. (KRUCHTEN, 1995).
Além disso, nessa visão, espera-se que diferentes configurações físicas sejam utiliza-
das, como configurações de desenvolvimento e testes e de depuração do sistema.

Pausa para refletir

Como a visão física se relaciona com as demais visões do modelo 4+1?

O mapeamento do software para os nós tem que ser feito de forma altamente flexí-
vel e gerar impacto mínimo no código fonte. O diagrama UML que representa a visão física
é o diagrama de implementação (deployment diagram). A figura a seguir ilustra os elemen-
tos da visão física:

Arquitetura de software 47
Componentes Conectores

Comunicação
Comunicação não
permanente
Comunicação direcional
Alta banda de utilização de
comunicação
Processador

Outros dispositivos

© DTCOM
Fonte: adaptado de Kruchten, 1995, p. 5.

Até o momento já vimos três das visões do modelo 4+1. Agora, dando continuidade,
iremos estudar, no próximo tópico, a visão de desenvolvimento.

2.2.4. Visão de desenvolvimento

A visão de desenvolvimento foca nos módulos do software voltados para a orga-


nização. O software é particionado em pequenos módulos que podem ser bibliotecas ou
subsistemas. Cada módulo pode ser desenvolvido por um ou mais desenvolvedores. Os
subsistemas, por sua vez, são organizados de forma hierarquia, e cada nível da hierarquia
provê uma interface bem definida para os níveis próximos (KRUCHTEN, 1995).
Ainda segundo Kruchten (1995), a arquitetura de desenvolvimento somente pode ser
descrita em sua completude quando todos os elementos de software são identificados.
Essa visão serve como uma base para: alocação de requisitos, alocação e organização
de trabalho de equipes, avaliação e planejamento de custos, monitoramento do progresso
do projeto, reutilização de software, portabilidade e segurança. Ou seja, ela é a base para o
estabelecimento de uma linha de produto.
A figura a seguir ilustra os componentes dessa visão:

48 Arquitetura de software
Componentes Conectores

Módulo Dependência

Subsistema

Camada

© DTCOM
Fonte: adaptado de Kruchten, 1995, p. 7.

Agora que finalizamos o estudo quanto às visões do modelo 4+1, vamos exemplificar
como documentar essas visões em um documento de arquiteturas.

2.3. Documento de Arquitetura de Sistema (DAS)

O Documento de Arquitetura de Siste-


mas (DAS) é o documento utilizado para o armaze-
namento das arquiteturas criadas para o sistema
projetado. Assim, todas as visões são agrupadas,
simplificando o acesso à todas as arquiteturas.
Desse modo, o DAS apresenta uma perspec-

© vladwel // Shutterstock.
tiva geral das visões e utiliza arquiteturas específicas
para ilustrar os diversos aspectos do sistema. Com
isso, objetiva-se disponibilizar as decisões que foram
tomadas durante o projeto de arquitetura do sistema.
No próximo tópico, iremos descrever em linhas gerais o que esse documento deve
conter.

2.3.1. Visão geral

Segundo o RUP for Value Creation ([s.d]), o DAS deve seguir uma certa padronização,
sendo necessário conter os seguintes tópicos:

Arquitetura de software 49
• Introdução: Deve conter os objetivos, o escopo, as definições necessárias, os acrô-
nimos, as abreviações, as referências e a visão geraldo documento.
• Representação Arquitetural: descreve, em linhas gerais, a arquitetura de soft-
ware do sistema e como ela está sendo representada. Deve conter os casos de uso,
a implementação, o processo, a lógica e as visualizações de implementação.
• Restrições e Metas arquiteturais: Deve conter os requisitos e os objetivos do soft-
ware que possam gerar impacto sobre a arquitetura. Por exemplo: segurança, dis-
ponibilidade, privacidade, reuso de software e portabilidade.
• Visão de Casos de Uso: Deve conter os casos de uso ou cenários e a representação
das funcionalidades gerais do sistema.
• Visão Lógica: Deve conter uma visão geral, como os pacotes de design significati-
vos do ponto de vista arquitetural e os casos de uso relevantes para a visão lógica.
• Visão de Processos: deve descrever a decomposição do sistema em processos,
organizados em grupos. Os grupos devem ser formados levando em consideração
a interação entre os processos, mantendo os mais comunicantes próximos uns aos
outros.
• Visão da Implementação: deve conter a estrutura geral do modelo de implemen-
tação, bem como a divisão do software em camadas e subsistemas.
• Tamanho e Desempenho: deve conter uma descrição das principais características
do sistema, focando em seu tamanho e nas restrições de desempenho.
• Qualidade: deve apresentar uma descrição de como a arquitetura do software
contribui para todos os recursos (exceto para a funcionalidade) do sistema.
Agora que já vimos como o DAS é estruturado, no próximo tópico iremos finalizar
este capítulo descrevendo como utilizar o DAS em um projeto de software.

2.3.2. Como utilizar

Como estudado, a arquitetura de um software é um artefato essencial para a produ-


ção de um bom sistema. Agora, para organizar essas arquiteturas em um único documento
e prover acesso centralizado a todos os interessados no negócio, utiliza-se o DAS – descrito
no tópico anterior. A seguir, portanto, iremos descrever como e quando utilizar esse inte-
ressante artefato de software.

50 Arquitetura de software
O DAS deve ser preenchido com os artefatos gerados no momento de modelagem
do sistema em produção, como nas diferentes arquiteturas geradas usando as visões do
modelo 4+1. Cada tópico que compõe a estrutura do DAS deve ser escrito com as caracte-
rísticas específicas do software em construção.
Após colocar cada arquitetura em seu tópico específico e preencher as demais carac-
terísticas do software, é preciso sintetizar essas visões arquiteturas utilizando os casos de
uso específicos.
Na sequência, após o preenchimento do DAS, é necessário disponibilizá-lo para todos
os envolvidos na produção do software. Para tanto, podemos disponibilizar o DAS em
uma pasta compartilhada com toda a equipe do projeto. Esse compartilhamento facilita a
comunicação e melhora o entendimento do software que está sendo produzido.

Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa,
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.

Agora é a hora de recapitular tudo o que você aprendeu nesse capítulo! Elabore um DAS uti-
lizando o modelo 4+1. Para tanto, crie diferentes visões para um sistema fictício. Ao produzir
o DAS, aplique todo o conhecimento adquirido nos capítulos da disciplina. Considere as lei-
turas básicas e complementares realizadas para ampliar seu conhecimento.

Recapitulando

Nesse capítulo estudamos alguns conceitos importantes para a construção de arqui-


teturas de software. Dentre eles, resumimos a importância do modelo de arquitetura como
uma forma de reutilizar uma arquitetura já pronta. Porém, como o modelo é genérico, res-
saltamos que é necessário adaptá-lo ao sistema que está sendo desenvolvido.
Estudamos também o estilo de arquitetura, que define características próprias que
devem ser seguidas para padronizar a arquitetura. Cada estilo possui características e atri-
butos que devem ser adequados ao problema a ser resolvido.
Além disso, também discorremos sobre os frameworks, que são implementações de
componentes arquiteturais genéricos. Eles servem para auxiliar no processo de definição
de novas arquiteturas, uma vez que possuem uma notação bem definida, permitindo a reu-
tilização de componentes. Ademais, os frameworks podem fazer uso de padrões e soluções
já conhecidas para problemas recorrentes.

Arquitetura de software 51
Também vimos a importância do modelo 4+1 e detalhamos cada uma de suas visões.
Após esse detalhamento, pudemos observar que as visões desse modelo servem para criar
abstrações da arquitetura do sistema, permitindo a visualização de informações únicas em
cada arquitetura construída.
Por fim, estudamos o DAS, artefato de software que serve para documentar a arqui-
tetura criada de forma clara. Esse documento visa ser disseminado para que toda a equipe
possa visualiza-lo facilmente.

52 Arquitetura de software
Referências

GAMMA, E. et al. Padrões de projeto: soluções reutilizáveis de software orientado a


objetos. Porto Alegre: Bookman, 2000.
KRUCHTEN, Philippe. The “4+1” View Model of Software Architecture. IEEE Software.
v. 12, n. 6, p. 42-50, nov. 1995.
RUP FOR VALUE CREATION. Artefato: Documento de Arquitetura de Software. Cen-
tro de Informática - UFPE. Disponível em: <www.cin.ufpe.br/~gta/rup-vc/extend.for-
mal_resources/guidances/templates/software_architecture_document_CE85F5AC.html>.
Acesso em 20 de outubro de 2018.
PRESSMAN, S. R. Engenharia de Software: Uma Abordagem Profissional. 7 ed. Rio de
Janeiro–RJ: McGraw-Hill, 2011.
TANENBAUM, A. S. Sistemas Operacionais Modernos. ed. 2. Pearson Prentice Hall. 2003.
UNIVERSITY OF BRITISH COLUMBIA. Electrical and Computer Engeneering. Disponível
em: <www.ece.ubc.ca/faculty/philippe-kruchten>. Acesso em 23 de outubro de 2018.

Arquitetura de software 53
CAPÍTULO 3

Padrões de Projeto
Geórgia Maria Ferro Benetti

OBJETIVOS DO CAPÍTULO
• Aplicar os padrões de projeto na arquitetura de software, resolvendo problemas
recorrentes e conhecidos.

TÓPICOS DE ESTUDO

Padrões do Gang of Four (GOF) e


1 2 Implementação dos padrões
suas categorias

• Componentes dos padrões GOF. • Factory method.


• Padrões Criacionais. • Facade.
• Padrões Estruturais. • Template method.
• Padrões Comportamentais. • Singleton.

Arquitetura de software 55
Contextualizando o cenário

Desenvolver sistemas consistentes orientados a objetos é uma tarefa desafiadora, uma vez
que esse trabalho requer soluções adequadas para possíveis problemas de software.

Os padrões de projetos, nesse sentido, representam o registro dessas boas soluções para o
desenvolvimento de sistemas. Essas soluções, que foram sendo descobertas somente com a
prática do desenvolvimento de software, começaram a ser documentadas e implementadas
em linguagens orientadas a objeto.

Podemos afirmar, então, que os padrões de projeto auxiliam na resolução de problemas recor-
rentes do desenvolvimento de software através da documentação de soluções já testadas.

Nesse sentido, um dos padrões de projeto mais utilizados para o desenvolvimento de soft-
ware são os Padrões GOF (Gang of Four). Por intermédio da reutilização de soluções já tes-
tadas, esses padrões favorecem a elaboração de um código robusto e “sustentável”.

Dito isso, como podemos utilizar padrões de projeto para construir sistemas eficien-
tes, flexíveis para aceitar constantes mudanças e, ao mesmo tempo, que sejam de fácil
manutenção?

56 Arquitetura de software
3.1. Padrões do Gang of Four (GOF) e suas categorias

O estabelecimento de padrões de projetos começou na área de construção civil com


o trabalho do arquiteto Christopher Alexander (Alexander, 1977), que tinha como objetivo
aprimorar projetos de edifícios e de áreas urbanas.
Utilizando esse trabalho como inspiração, um grupo de quatro desenvolvedores, que
ficaram conhecidos como Gang of Four (GOF), criaram padrões específicos para o desen-
volvimento de sistemas. Os 23 padrões que eles elaboraram em 1994, ganharam reconheci-
mento e se transformaram no Catálogo de Padrões GOF.
Esse catálogo, então, deu origem
à primeira edição do livro de Gamma et
al. (1995), denominado Design Patterns:

© Photobank gallery // Shutterstock


Elements of Reusable Object-Oriented
Software e traduzido como Padrões de
Projetos: Padrões de projeto: soluções
reutilizáveis de software orientado a obje-
tos, no português.
Para Gamma et al. (2007, p. 20), padrões de projeto são:

[...] descrições de objetos e classes comunicantes que precisam ser personalizadas para
resolver um problema geral de projeto num contexto particular. Um padrão de projeto
nomeia, abstrai e identifica os aspectos-chave de uma estrutura de projeto comum
para torná-la útil para a criação de um projeto orientado a objetos reutilizável.

Ao longo desse capítulo, portanto, estudaremos cada um desses padrões, dividindo-


-os nas categorias comportamental, estrutural e criacional e apresentando suas caracte-
rísticas, classificações, aplicações e implementações. Acompanhe!

3.1.1. Componentes dos padrões GOF

Os padrões GOF apresentam componentes bem particulares quando comparados à


cultura vigente na área de desenvolvimento de software, que, normalmente, utiliza lingua-
gem gráfica para documentar projetos. Esse tipo de linguagem, apesar de muito utilizado,
costuma representar um estado consolidado do processo - como se fosse uma fotografia -
dando uma conotação fixa à documentação. Os padrões de projeto, por sua vez, são mais
abrangentes e vão além dos estados estáticos.

Arquitetura de software 57
Segundo Gamma et al. (2007), cada um dos 23 padrões contém: alternativas para o
desenvolvimento de sistemas, que englobam perspectivas analíticas e indicativos de reuti-
lização de soluções, sempre relacionados ao custo-benefício de sua adoção. Observando as
alternativas disponíveis, os desenvolvedores contam com diferentes opções para construir
sistemas de acordo com o contexto de cada situação.
Para comportar todas essas informações, os padrões GOF foram elaborados de modo
descritivo e estão compostos por, pelo menos, quatro elementos básicos (GAMMA et al.,
2007):
• Nome do padrão;
• Problema a ser resolvido;
• Solução dada pelo padrão;
• Consequências.
O nome é o elemento que identifica o padrão, facilitando o processo comunicativo
entre as pessoas que o utilizam como recurso. Esse nome também reflete na elaboração
dos códigos, tornando-os mais compreensíveis e menos complexos de depurar. Um
exemplo é o padrão prototype que fornece um protótipo para criação de novos objetos.

Afirmação
“Encontrar bons nomes foi uma das partes mais difíceis do desenvolvimento do
nosso catálogo. ” (GAMMA et al., 2007, p. 19).

Conforme Matos e Barbosa (2016, p. 42):

O uso dos padrões de projeto como referência (nome do padrão) para soluções de pro-
blemas identifica o seu comportamento e propósito permitindo o seu entendimento
no processo de desenvolvimento de sistemas. Utilizar o nome do padrão facilita no
entendimento de sua funcionalidade do que detalhar como uma implementação deve-
ria trabalhar.

A nomeação de padrões, portanto, deve comunicar a síntese do problema que ele


resolve, as soluções propostas para esse problema, assim como as possíveis consequências
dessas soluções. Sua função de síntese está em expressar, em poucos termos, uma solução
complexa e abrangente.

58 Arquitetura de software
Como exemplo, temos o padrão Observer que “define uma dependência um-para-
-muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus
dependentes são automaticamente notificados e atualizados” (GAMMA et al, 2007 p. 25).
Esse padrão, portanto, pode ser empregado em um objeto que está sujeito a mudan-
ças, como a carga horária de um curso. Se o sistema acadêmico que você utiliza seguir esse
padrão, por exemplo, a medida que você avança no curso, a carga horária cursada vai sendo
atualizada em diferentes modos de visualização (gráficos, relatórios, entre outros recursos).
O problema, por sua vez, contém indicativos das situações e contextos em que o
padrão pode ser adotado. Como os contextos são situacionais, um padrão pode trazer lis-
tadas as condições em que a aplicação do padrão pode ser uma opção viável.
Como exemplo de padrão para a resolução de um problema a ser resolvido, podemos
citar o Composite, que estrutura objetos em uma árvore hierárquica do tipo partes-todo.
Assim, para resolver um problema de visão composta de objetos, por exemplo, podemos
utilizar esse padrão para que os clientes tratem de maneira sempre uniforme os objetos
individuais e as composições de objetos. Isso é possível porque o Composite hierarquiza
as classes, diferenciando as que tratam de objetos primários das subclasses que tratam de
objetos compostos (GAMMA et al., 2007).
A solução é uma descrição hipotética da saída do problema através de um exemplo
de aplicação do padrão. Essa solução contém informações sobre os relacionamentos e res-
ponsabilidades e também sobre as colaborações entre os elementos do sistema. No
entanto, é importante colocar que essa solução é apenas uma abstração, não apresen-
tando, portanto, informações específicas sobre implementação.
As consequências, por fim, apresentam as vantagens e desvantagens da aplicação de
um padrão. Elas incluem a análise de diferentes alternativas de padrões que podem ser ado-
tados e consideram os benefícios a serem obtidos com a adoção da solução. Para tanto, leva-
-se em conta os custos, os desafios e os impactos
envolvidos. Além disso, as consequências estão for-
temente relacionadas a critérios de flexibilidade,
extensibilidade e portabilidade, uma vez que a reu-
tilização de soluções é um dos principais objetivos
do uso de padrões.
© Marina Sun // Shutterstock

Ao falar de consequências, é preciso mencio-


nar uma prática denominada anti-pattern. Essa
prática se refere à utilização de recorrentes solu-
ções de código que não seguem os padrões de

Arquitetura de software 59
projetos, embora possam ser semelhantes a eles. Essas soluções parecem ser adequadas
quando implementadas, porém, com o tempo, podem resultar em um código sujo e trun-
cado, desfavorecendo a evolução e a manutenção da aplicação.

Pausa para Refletir

Todo padrão de projeto possui quatro elementos básicos – nome, problema, solução e con-
sequência. Mas, dentre esses quatro, três são fundamentais. Quais são eles?

Agora que já adquirimos noções gerais do que são padrões de projetos, vamos estu-
dar cada uma das categorias de padrões elaboradas pela Gang of Four. Essas categorias se
baseiam nas variações de granularidade e no nível de abstração de cada padrão, conside-
rando sua finalidade – criação, estrutura ou comportamento. Acompanhe!

3.1.2. Padrões Criacionais

Os Padrões Criacionais partem da instanciação de classes para abstrair a criação


de objetos. Conforme Matos e Barbosa (2016), a consequência da utilização desse tipo de
padrão é que os sistemas se tornam independentes do comportamento dos objetos cria-
dos, compostos ou representados. Isto porque se uma classe criada por meio de herança
varia de instância, a criação dos objetos transfere a instância para outro objeto.
São Padrões Criacionais definidos por Gamma et al. (2007):
• Singleton: garante que uma classe tenha instância única e dispõe de um ponto glo-
bal que dá acesso para essa classe.
• Abstract Factory: Proporciona uma interface para criar famílias de objetos relacio-
nados ou dependentes sem especificar suas classes concretas.
• Builder: decompõem um objeto complexo em partes, separando-o da sua repre-
sentação e tornando possível que esse objeto origine representações variadas.
• Factory Method: disponibiliza uma interface que permite a constituição de obje-
tos, de modo que as classes descendentes decidam qual objeto instanciar.
• Prototype: elabora um protótipo que particulariza tipos de objetos que podem ser
criados. Os objetos novos podem ser derivados desse protótipo (por clonagem),
sem que o sistema saiba qual classe específica está sendo instanciada.
Agora que aprendemos sobre os padrões que permitem ações de criação, a seguir
estudaremos os padrões que atuam nas estruturas e interfaces.

60 Arquitetura de software
3.1.3. Padrões Estruturais

Os Padrões Estruturais referem-se à organização, elaboração e associação de clas-


ses, objetos e interfaces em estruturas mais abrangentes ou complexas. Além disso, eles
definem como uma classe é herdada de outra.
São padrões estruturais descritos por Gamma et al. (2007):
• Adapter: promove compatibilidade
entre interfaces que são, aparente-
mente, incompatíveis, pois transforma

© Preechar Bowonkitwanchai // Shutterstock


a interface de uma classe em outra.
• Bridge: desacopla uma interface e
outras abstrações (como as ações de
uma classe) de sua implementação,
de maneira que elas possam variar
independentemente.
• Composite: compõe objetos semelhantes que podem variar de nenhum até n obje-
tos, dispondo-os em hierarquia de árvore (todo-parte). Isso possibilita trata-los
como um objeto único.
• Decorator: por meio de um processo dinâmico, aporta responsabilidades suple-
mentares para determinado objeto, acrescentando funcionalidades a ele ao invés
de acrescentá-las às classes. Esse padrão possibilita a extensão de funcionalidades
por meio de herança.

Curiosidade
O Decorator atua de maneira contrária ao mecanismo de extensão de objetos
dinâmicos que é feito, tradicionalmente, por herança, e atua acrescentando funcionalidades
em tempo de compilação.

• Facade: disponibiliza uma interface que unifica as várias interfaces de um mesmo


subsistema. Ele estabelece uma interface de nível mais alto, facilitando, assim, a
operação do subsistema.
• Flyweight: Permite suportar uma quantidade elevada de objetos (de fina granulari-
dade), mas mantendo a eficiência com baixo consumo de memória.

Arquitetura de software 61
• Proxy: Disponibiliza uma alternativa, chamada proxy, por meio da qual um deter-
minado objeto comanda o acesso a outros.
Após estudarmos os padrões relacionados às estruturas das aplicações, vamos, a
seguir, discorrer sobre o último grupo de padrões que compõem o catálogo GOF: os que se
referem ao comportamento. Acompanhe!

3.1.4. Padrões Comportamentais

Os Padrões Comportamentais se preocupam com os algoritmos, com as responsabi-


lidades dos objetos e com a comunicação entre objetos e classes.
São Padrões Comportamentais desenvolvidos por Gamma et al. (2007):
• Chain of Responsability: previne que ocorra acoplamento entre o emitente de uma
solicitação e o receptor. Concatena os receptores, transmitindo uma determinada
solicitação pela extensão da cadeia até que ela chegue ao objeto que pode trata-la.
• Interator: fornece uma interface que promove acesso sequencial para com-
ponentes de determinado objeto agregado sem mostrar o modo como ele é
representado.
• Template Method: determina o esquema do algoritmo envolvido na operação, de
modo que certas etapas do processo são delegados para as subclasses. Assim, as
subclasses têm autonomia para reconfigurarem passos determinados pelo algo-
ritmo sem alterar o modo como ele está estruturado.
• Visitor: corresponde a certas operações que podem ser efetuadas em cima dos
elementos que estruturam os objetos. Isso torna possível a definição de outras
operações sem que seja necessário alterar as classes de cada componente.
• State: permite que um objeto altere
o modo de se comportar em função
das alterações de seu estado interno.
© Vector Tradition // Shutterstock. (Adaptado).

• Memento: apreende e exterioriza o


estado de um objeto, permitindo que
seja possível voltar a esse estado.
• Mediator: estabelece objetos que
encapsulam o modo pelo qual obje-
tos atuam em conjunto, fornecendo
uma interface. Assim, os objetos não se referem diretamente uns aos outros, o que
resulta um fraco acoplamento entre eles.

62 Arquitetura de software
• Command: opera encapsulando as requisições sob forma de objeto. Isso permite
que se trabalhe com clientes de requisições distintas, mesmo desconhecendo o
modo de execução da operação e o destinatário.
• Observer: Estabelece dependência do tipo de um-para-muitos, permitindo que
quando um objeto altere seu estado, todos os objetos dependentes sejam comu-
nicados e também atualizados de modo automático. Nesse padrão os objetos são
observadores (observers) ou ouvintes (listeners) e observam um evento.
• Strategy: estabelece um conjunto de algoritmos, executa o encapsulamento indi-
vidual de cada componente do conjunto e os torna intercambiáveis, permitindo
que as variações do algoritmo não dependam do cliente que irá utilizá-lo.
• Interpreter: estabelecida a linguagem, fixa a representação para sua gramática
atuando em conjunto com o interpretador das expressões relacionadas a ela.

Pausa para Refletir

Depois de conhecer todos os padrões, você acredita que eles são mais frequentemente apli-
cados individualmente ou combinados durante o desenvolvimento de sistemas?

Agora que já estudamos as três categorias de padrão GOF, veja o quadro a seguir que
ilustra cada padrão de acordo com sua devida categoria:

Catálogo GOF

Padrões Criacionais Padrões Estruturais Padrões Comportamentais

Singleton Adapter Chain of Responsability

Abstract Factory Bridge Command

Builder Composite Interpreter

Factory Method Decorator Interactor

Prototype Facade Mediator

FlyWeight Memento

Proxy Observer

Strategy

State

Arquitetura de software 63
Catálogo GOF

Padrões Criacionais Padrões Estruturais Padrões Comportamentais

Tempalte Method

Visitor

Conhecidos os padrões GOF na totalidade de suas três categorias. Agora estudare-


mos como eles podem ser implementados.

3.2. Implementação dos padrões

Para serem implementados, os padrões devem ser considerados conforme o escopo


em questão. Portanto, eles são agrupados conforme a classe ou objeto que se relaciona
com a tipologia criacional, estrutural ou comportamental, como ilustra a tabela a seguir:

Propósito

Criação Estrutural Comportamental

Interpreter
Classe Factory Method Adapter (classe)
Tempante Method

Chain of
Responsibility
Adapter (objeto)
Command
Bridge
Escopo Abstract Factory Iterator
Composite
Builder Mediator
Objeto Decorator
Prototype Memento
Façade
Singleton Observer
Flyweight
State
Proxy
Strategy
Visitor

Fonte: GAMMA et al., 2007, p. 26. (Adaptado).

Os Padrões de Classes tratam de relacionamentos entre classes e subclasses defini-


dos por hereditariedade. Eles são estáticos e ficam estabelecidos quando ocorre a compila-
ção. São padrões de classe: Factory Method, Adapter, Template Method, Interpreter.

64 Arquitetura de software
Já os Padrões de Objetos referem-se às relações entre objetos e são dinâmicos por-
que podem se modificar quando estão em execução. São padrões de objetos: Template
Method. Mediator, Iterator, Visitor, Memento, Interpreter, Strategy,tão Command, Chair of
Responsability, Observer, State.
Para compreender melhor a utilização dos padrões de projeto na prática, vamos conhe-
cer quatro possibilidades de implementação que envolvem alguns dos padrões estudados.
• Factory Method:
O padrão Factory Method estabelece
uma interface comum de criação de objetos,
porém delega para as subclasses a decisão de
que classe instanciar. Ou seja, nesse padrão a

© Wright Studio // Shutterstock


instanciação é postergada para as subclasses.
O Factory Method é muito aplicado em
frameworks que, por sua vez, precisam ser fle-
xíveis. Para tanto, esses frameworks contam
com classes abstratas que determinam e sustentam relacionamentos entre objetos, possi-
bilitando que eles, por sua vez, sejam criados pelo próprio framework.

Esclarecimento
Um Framework é estrutura básica e genérica que contém classes, objetos e relacio-
namentos já projetados para construir determinadas aplicações específicas (MALDONADO,
2002).

Observe, agora, um exemplo retirado de DE Albuquerque et al (2010), em que há a


aplicação do Factory Method no desenvolvimento de um framework. Esse framework visa
criar um padrão para que bancos de dados relacionais sejam utilizados por aplicações Java.
No projeto que desenvolveram, os autores utilizaram o Factory Method para a criação
de objetos SQLDescriptor, que são descritores dos XML do SQL, conforme a estrutura de
classes a seguir:

Arquitetura de software 65
class sqlDescriptor

<<interface>>
Descriptor DescriptorFactory

SQLDescriptorFactory
SQLDescriptor creates
createDescriptor() : Descriptor
getDescriptor() : Descriptor

© DTCOM
Fonte: ALBUQUERQUE et al, 2010, p. 15. (Adaptado).

Conforme ilustra a figura anterior, quando o cliente faz a solicitação para que um novo
objeto seja criado, ele precisa informar só o nome do descritor XML, sem necessidade de
especificar a classe. Fica delegado para a classe SQLDescriptorFactory, então, a implemen-
tação do método getDescriptor() que irá instanciar um descritor XML específico. Dessa
maneira, o cliente pode usar o objeto criado mesmo sem conhecer sua classe específica.
• Facade:
O padrão de projetos Facade promove
uma interface que permite acessar diversos
subsistemas. O exemplo que estudaremos,

© JNT Visual // Shutterstock


retirado de Mourato et al (2009), ilustra um
sistema de avaliação de conteúdos que per-
mite aos alunos avaliar os conteúdos das
aulas que cursaram.
O sistema foi planejado em uma arquitetura de três camadas, na qual o Facade pro-
move a comunicação intermediária entre o View e o Controller, desacoplando esses dois
módulos, como ilustra a figura a seguir:

View

Facade
© DTCOM

Controller

66 Arquitetura de software
Com essa organização, a interface provida pelo View renderiza as informações impu-
tadas por quem utiliza o sistema, enquanto o Controller faz a validação para que esses
dados sejam inseridos na base de maneira consistente.
Além disso, o Facade permite que todas as funcionalidade e informações sejam aces-
sadas igualmente tanto em modo web quanto desktop.
• Template Method:
O padrão Template Method é um padrão comportamental aplicado a classes. Ele per-
mite definir a estrutura de um determinado algoritmo, estabelecendo certos passos a
serem executados pelas subclasses quando forem implementadas.
Para ilustrar a implementação desse padrão, utilizaremos um módulo para o cálculo
do tributo ICMS que visa prevenir falhas humanas. Esse exemplo de módulo, retirado de
Aquino e De Souza (2008), dispensa que a pessoa que digita os dados da nota fiscal esco-
lha o cálculo que será aplicado ao produto.
Vale ressaltar que desenvolver um sistema que calcula esse tipo de tributo é um desa-
fio para os desenvolvedores, uma vez que o cálculo não é único e está sujeito a regras
específicas para diferentes atividades econômicas. Por isso, o algoritmo envolve códigos
complexos e extensos, cuja manutenção é trabalhosa e sujeita a erros.
Além disso é uma aplicação que exige bastante manutenção porque é regida por
regras dinâmicas que se modificam a luz da legislação e de outros fatores, como convênios
e políticas de isenção.
Observe, a seguir, o diagrama que ilustra a implementação desse padrão:

SortAlgorithm
Client processArray();
+sort()
compare()
+#compare()
returnArray();
+returnArray()
+processArray()

SortAscending SortDescending

+#compare() +#compare()
© DTCOM

Fonte: AQUINO; DE SOUZ A, 2008 p. 142. (Adaptado).

Como ilustrado, a classe SortAlgoritm é abstrata e contém o método sort(), que uti-
liza, além de outros métodos concretos, o compare(), que é abstrato. Dessa maneira, o
compare() é implementado dependendo da subclasse de SortAlgorithm que for instanciada.

Arquitetura de software 67
Nessa arquitetura, as regras de cálculo específicas são subclasses. Assim, o Template
Method parte de uma única regra padrão de cálculo que se comunica com as específicas de
modo independente.
Esse padrão permite checar cada uma das regras, verificando de forma automática
quais podem ser utilizadas para um determinado cálculo. Se o imposto irá ser cobrado de
uma atividade econômica A, por exemplo, as regras para as outras atividades econômicas
são automaticamente descartadas dessa operação. Veja o diagrama que segue:

RegraB
RegraA
ICMS +isRegraUtilizavel() : boolean
+isRegraUtilizavel(); boolean +ajustarValores() : void
+calcularlcmsItem() : IcmsDTO
+ajustarValores(): void +getTipoRegra() : Integer
+getTipoRegra(): integer

return hasDestinatarioCNAEFarmacia(); icmsDestacado = 0;


icmsFrete = 0;
RegrasICMS
+isRegraUtilizavel(): boolean
+ajustarValores(): void
+getTipoRegra() : Integer
+calcularlcmsRegra():IcmsDTO
RegraPadrao +calcularExpressaoGenerica() : double RegraC
+isRegraUtilizavel() : boolean +isRegraUtilizavel() ; boolean
+ajustarValores() : void Atualmente existem +ajustarValores() : void
+getTipoRegra() : Integer 17 regras, ou seja, +getTipoRegra() : Integer
17 Sub-Classes.
agregacaoBaseCalculo = getAgregacaoBCIndustria();

© DTCOM
return true;

Fonte: AQUINO; DE SOUZA, p. 147. (Adaptado).

Se a regra de cálculo do imposto se modificar apenas para o setor industrial, por


exemplo, é possível ajustar somente essa subclasse sem alterar todos os outros componen-
tes de cálculo padrão.
• Singleton:
O Padrão Singleton é adotado para assegurar que a classe terá uma única instância
e também para estabelecer um ponto global para acessá-la (Gamma et al., 2007). Assim,
nesse padrão, uma instância única da classe determina o construtor da classe Singleton
“como privado (private) e o método que retornará a instância dessa classe como estático
(static) ” (MATOS; BARBOSA, 2016 p. 44).
Observe a solução elaborada por Matos e Barbosa (2016) para mapear o conjunto
de usuários online conectados a uma determinada aplicação. Essa aplicação parte de uma
modelagem em diagrama de classes e é implementada em linguagem JAVA:

68 Arquitetura de software
UsuariosOnlineSingleton

– static instancia: UsuariosOnlineSingleton


– numero_usuarios_online: int

+ static getInstancia (): UsuariosOnlineSingleton


+ conectar ()
+ desconectar ()
+ getNumeroUsuariosOnline ()

Fonte: MATOS; BARBOSA, 2016, p. 45. (Adaptado).

Ao final da execução do código temos como resultado:

Usuário 01 conectado...
Número de usuários online: 1

Usuário 02 conectado...
Número de usuários online: 2

Usuário 01 desconectado...
Número de usuários online: 1

Fonte: MATOS; BARBOSA, 2016, p. 46. (Adaptado).

No resultado, observa-se que os diferentes objetos  usuario01, usuario02 e usua-


rios_online – compartilham a mesma instância da classe UsuáriosOnlineSingleton. Dessa
maneira, é possível ter o número de usuários online em tempo real com base no status indi-
vidual de cada usuário.
Encerramos nossos estudos com alguns exemplos de implementação de padrões de
projetos em diferentes contextos de desenvolvimento de software. Com esse aprendizado,
acredito que você está pronto para colocar em prática todo o conhecimento adquirido rea-
lizando a atividade a seguir.

Arquitetura de software 69
Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa,
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.

Agora é a hora de recapitular tudo o que você aprendeu nesse capítulo! Tomando por
base as informações sobre implementação de padrões contidas no livro texto, elabore um
exemplo semelhante utilizando um padrão diferente dos que constam no material. Ao pro-
duzir seu exemplo, considere as leituras básicas e complementares realizadas.

Recapitulando

Os padrões de projetos apresentam respostas para desafios que se repetem perio-


dicamente e que já foram aplicadas com êxito em situações anteriores. Desse modo, eles
conferem mais agilidade no desenvolvimento de software.
Existem padrões para desenvolver projetos em diferentes áreas, mas, na área de
software, uma referência amplamente reconhecida é o trabalho de quatro autores – ape-
lidados de Gang of Four (GOF) – que somaram esforços para sintetizar um catálogo de 23
padrões. Esses padrões são divididos em três macro categorias: criacionais, estruturais e
comportamentais.
Os padrões GOF podem apresentar diversos elementos detalhados em sua descrição,
mas todos os padrões se estabelecem com base em três elementos fundamentais – pro-
blema, solução e consequência. O quarto elemento básico consiste na definição de um
nome que comunique o conjunto da situação reunida pelos outros três aspectos.
No desenvolvimento de sistemas, a aplicação desses padrões acontece de modo com-
binado, uma vez que a complexidade da arquitetura de um sistema costuma apresentar
diferentes desafios a serem solucionados.
Pode-se dizer, por fim, que cada padrão auxilia na resolução de um problema especí-
fico através de soluções já testadas. Isso garante que as constantes atualizações e manu-
tenções das aplicações aconteçam de maneira mais ágil.

70 Arquitetura de software
Referências

AQUINO, F. W. C; DE SOUZA, J. T. Experiência de Aplicação de Padrões de Software


para o Cálculo de ICMS. SugarLoaf PloP – 7th Latin American Conference on Pattern
Languages of Programming Fortaleza, Brazil, 2008, p. 138. Disponível em: <www.
academia.edu/2086838/Linguagem_de_Padr%C3%B5es_para_Avalia%C3%A7%C3%A3o_
de_Conhecimento_em_Objetos_de_Aprendizagem_Parte_II?auto=download>. Acesso em:
20 de outubro de 2018.
ALEXANDER, C. A pattern language: towns, buildings, construction. Oxford: University
Press, 1977.
DE ALBUQUERQUE, M. T.; ROJAS, A.; RIBEIRO, P. C. M. Utilizando Design Patterns GoF
no apoio ao desenvolvimento de um Framework Java. Cadernos do IME-Série Informá-
tica, v. 30, p. 13-27, 2010. Disponível em: <www.e-publicacoes.uerj.br/index.php/cadinf/
article/view/6590/4695>. Acesso em 20 de outubro de 2018
GAMMA, E. et al. Design patterns: elements of reusable object-oriented software.
Pearson Education India, 1995.
GAMMA, E. et al. Padrões de Projetos [recurso eletrônico]: Soluções Reutilizáveis de
Software Orientado a objetos. Porto Alegre: Bookman, 2007. Disponível em: <www.
academia.edu/9146719/Padroes_de_Projetos_-_Solucoes_Reutilizaveis_-_Gamma_Erich>.
Acesso em 20 de novembro de 2018.
MALDONADO, J. C. et al. Padrões e Frameworks de software. Notas Didáticas. Instituto
de Ciências Matemáticas e de Computação da Universidade de São Paulo, ICMC/USP, São
Paulo/SP, Brasil, 2002.
MATOS, C. C.; BARBOSA, F. K. O uso dos padrões de projeto GoF na análise e desenvolvi-
mento de sistemas. UNILUS Ensino e Pesquisa, v. 13, n. 30, p. 41-53, 2016. Disponível em:
<revista.unilus.edu.br/index.php/ruep/article/view/715/u2016v13n30e715>. Acesso em 09
de novembro de 2018.
MOURATO, L. P.; PIRES, G. M; D’EMERY, R. A. Model View Controller e Facade: um
estudo de caso. IX Jornada de Ensino Pesquisa e Extensão, 19 a 23 de outubro de
2009, Universidade Federal Rural de Pernambuco, Recife, 2009. Disponível em <www.
eventosufrpe.com.br/jepeX2009/cd/resumos/R1091-1.pdf>. Acesso em 20 de out de 2018.

Arquitetura de software 71
CAPÍTULO 4

Arquitetura Orientada a Serviços (SOA)


Sidartha Azevedo Lobo de Carvalho

OBJETIVOS DO CAPÍTULO
• Empregar uma arquitetura SOA, identificando as restrições e benefícios através de
modelos e exemplos de aplicação.

TÓPICOS DE ESTUDO

1 Introdução 3 Aplicação

• Requisitos. • Exemplo de aplicação.


• Acoplamento. • Vantagens e desvantagens da
• Desenho. arquitetura SOA.

2 Serviço

• Visão geral.
• Granularidade.

Arquitetura de software 73
Contextualizando o cenário

Dada a grande expansão e popularização da tecnologia e dos meios de acessa-la, a maioria


das aplicações são desenvolvidas para serem usadas em ambientes distribuídos, como inter-
net e intranets.

Essas aplicações, por sua vez, tendem a oferecer todas as funcionalidades de software como
serviços, visando facilitar a manutenção e o uso por outras aplicações. Para tanto, cada vez
mais, as aplicações vêm sendo “quebradas” em pequenos serviços bem definidos para dimi-
nuir a complexidade e o acoplamento.

Um dos principais objetivos da Arquitetura Orientada a Serviços (SOA), portanto, é alcan-


çar um baixo acoplamento entre os módulos do sistema, reduzindo, assim, os custos de
manutenção e permitindo que os serviços sejam reutilizados.

Dito isso: O que representa um sistema de software possuir um baixo acoplamento? E


como isso impacta na arquitetura do software?

74 Arquitetura de software
4.1. Introdução

A orientação a objetos surgiu como uma forma de melhorar o design de sistemas


que, até então, era feito através de uma arquitetura distribuída convencional. Para tanto, a
orientação a objetos agregou o conhecimento das abordagens tradicionais e fez melhorias
para resolver problemas recorrentes encontrados nas aplicações.
Assim, esse estilo arquitetural, originalmente denominado Service-Oriented Architecture
(SOA) – Arquitetura Orientada a Serviços, em português -, objetiva que funcionalidades
sejam fornecidas em forma de serviços com o intuito de aprimorar as aplicações (ERL, 2009).

Curiosidade
As publicações de Thomas Erl são formalmente endossadas por importantes
organizações de software. Além disso, Erl é fundador de uma empresa especializada em ser-
viços de consultoria e treinamento SOA (ERL, 2009).

Esses serviços oferecidos, que devem ser disponibilizados por uma API (Application
Program Interface – Interface de Programação de Aplicações, em português) bem definida,
são chamados de web service. Para ilustrar esses serviços, imagine que você está proje-
tando um sistema para uma loja virtual. Essa loja deve possuir as funcionalidades de cadas-
trar produtos, consultar os produtos disponíveis, consultar estoque, dentre outras.
Ao utilizar uma abordagem baseada em serviços, cada funcionalidade deve ser
implementada como um serviço. Ou seja, devemos ter uma URL para listar os produtos
(http://localhost:80/sistema/listarprodutos), outra para remover um produto passando seu
identificador como um parâmetro pela URL, e assim por diante.
Assim, o serviço pode ser definido como uma representação lógica de um processo
repetível que tem uma saída definida. Por exemplo: consultar o crédito de um cliente, pro-
ver informações de tempo, consolidar relatórios, dentre outros.
É importante ressaltar que um serviço pode ser composto por diferentes serviços, ou
seja, ele pode reutilizar e integrar serviços já existentes para formar um novo. Além disso,
ele deve ser autocontido, o que significa não fazer uso de módulos que não estão presentes
na sua implementação.
Dito isso, a arquitetura voltada para serviço (SOA), possui as seguintes características
(THE OPEN BOOK, 2009):

Arquitetura de software 75
• Baseia-se na modelagem de serviços que, por sua vez, refletem as atividades reais
do negócio.
• Utiliza descrições do negócio para prover o contexto do serviço.
• Insere requisitos únicos na infraestrutura. Recomenda-se que as implementações
usem padrões abertos, possibilitando, assim, interoperabilidade e transparência
nos procedimentos.
• Utiliza implementações dependentes do ambiente. Ou seja, elas são ativadas pelo
contexto e, portanto, devem ser descritas dentro dele.
A SOA também faz uso dos conceitos da computação distribuída, utilizando o método
de requisição e resposta para permitir a comunicação entre os sistemas comunicantes.
Essa troca de informação entre os ser-
viços é feita utilizando um protocolo que des-
creve como enviar e como receber os dados.
© Bakhtiar Zein / / Shutterstock. (Adaptado).

Para tanto, utiliza-se descrições de metada-


dos, como o JSON (JavaScript Object Nota-
tion) - uma notação padronizada para transferir
dados entre serviços.

ARQUITETURA ORIENTADA A SERVIÇOS A utilização dessa padronização auxilia a


troca de mensagens entre diferentes dispositi-
vos. Desse modo, novos projetos (e também adaptações de projetos antigos) devem levar
em conta essa padronização para ser competitivo na internet.
O grande objetivo da SOA é que cada serviço implemente uma ação, como visuali-
zar um formulário ou realizar login. Esses serviços, por sua vez, fazem uso de métodos que
visam não acessar diretamente o código fonte da aplicação servidora.
Pode-se dizer que a implementação de sistemas baseados em serviços pode gerar um
trabalho inicial maior, mas os benefícios são comprovados: reduz a complexidade, diminui
o acoplamento entre os métodos, proporciona melhor divisão de tarefas e garante mais
segurança.

Pausa para refletir

Você consegue imaginar um exemplo de uma arquitetura ou de aplicação em que uma classe
é dependente de outra (alto acoplamento)?

76 Arquitetura de software
Por fim, vejamos os oito princípios básicos da orientação a serviços (ERL, 2009):
• Maior consistência na representação da funcionalidade dos dados;
• Menor dependência entre unidades logicas;
• Menor necessidade de preocupação com o design da lógica subjacente e com os
detalhes de implementação;
• Mais oportunidades para a utilização de uma parte da lógica para diversas finalidades;
• Mais oportunidades para a combinação de unidades da lógica em diferentes
configurações;
• Maior capacidade de previsão comportamental;
• Maior disponibilidade e capacidade de escala;
• Maior consciência da lógica disponível.
Conhecidos os conceitos gerais da SOA e também seus princípios básicos, a seguir ire-
mos descrever os requisitos necessários para incorporar os sistemas nesse estilo arquitetural.

4.1.1. Requisitos

Para implementar a arquitetura SOA, é necessário seguir alguns requisitos básicos.


Um desses requisitos refere-se à interoperabilidade entre os diversos sistemas que podem
fazer uso do serviço e também entre as diversas linguagens que podem ser utilizadas para
consumir esse serviço. Esse requisito pode ser cumprido com o uso de um protocolo bem
definido de troca de mensagens e de uma interface padronizada para a disponibilização
dos serviços.
Ao contar com interfaces de troca de mensagens bem definidas, diminui-se a comple-
xidade da aplicação, o que possibilita a separação de responsabilidades, permitindo que o
desenvolvedor foque seus esforços no desenvolvimento do sistema.
Outro requisito importante é fazer uso de implementações de padrões de código
aberto durante a implementação da arquitetura SOA. Isso garante que as demais pessoas
ou serviços consigam acessar os serviços de forma fácil, permitindo alcançar a escalabili-
dade da aplicação.
Além disso, é possível fazer uso de padrões de projeto para implementar o sistema,
garantindo, assim, mais confiabilidade à codificação do software (GAMMA, 2000). Os
padrões de projeto são ferramentas essenciais na produção de um software de qualidade.
Isto porque eles auxiliam na resolução de problemas comuns na produção dos sistemas de
software, fornecendo soluções otimizadas.

Arquitetura de software 77
Curiosidade
Os padrões de projeto propostos pela Gang of Four – GoF (grupo de 4 pessoas
responsáveis por escrever os padrões de projeto) são um dos mais conhecidos e utilizados
mundialmente. Eles são empregados como referência na construção de software de qualidade.

Agora que vimos como os requisitos se relacionam com a arquitetura e com a imple-
mentação de um sistema, no próximo tópico vamos discutir em detalhe o acoplamento dos
componentes.

4.1.2. Acoplamento

Erl (2009, p. 111) afirma que “A maneira mais comum de explicar o acoplamento é
compará-lo a dependência. Uma medida de acoplamento entre dois elementos é equiva-
lente ao nível de dependência que existe entre eles. ”
O acoplamento, portanto, corresponde ao grau de dependência de um módulo do
sistema quando comparado a outro módulo. Uma característica importante de um bom
software é o baixo acoplamento entre seus componentes, ou seja, um baixo nível de
dependência entre os componentes. Essa característica é aplicada nas arquiteturas que
fazem uso do SOA.
Se um determinado módulo do sistema possui responsabilidades e atividades bem
definidas e um baixo acoplamento com os demais módulos, por exemplo, ele é considerado
coeso. Para que fique mais claro o que é realmente o acoplamento, imagine o seguinte
cenário no desenvolvimento de software orientado a classes: temos a classe X que possui
os métodos somar() e dividir() e a classe Y que possui o método calcularMedia().
O método calcularMedia() faz uso do método somar() e do método dividir(), logo, esse
método possui uma grande dependência (alto acoplamento) da classe X. Assim, se alterar-
mos a classe X, essa ação irá impactar diretamente a classe Y, pois Y é dependente de X. Esse
nível de dependência gera problemas de manutenção e aumenta a complexidade do código.
Por outro lado, podemos assumir que a classe X possui um baixo acoplamento, pois
não utiliza componentes de software de outras classes, ou seja, tudo que ela precisa está
contido em sua própria implementação.
Depois de entender como funciona o acoplamento, no próximo tópico iremos estudar
o desenho de uma arquitetura. Acompanhe!

78 Arquitetura de software
4.1.3. Desenho

O desenho de uma arquitetura é representado por um diagrama que descreve os seus


componentes e os seus relacionamentos.
A figura a seguir ilustra a visão geral do desenho de uma arquitetura SOA:

Serviço

Componentes

Infraestrutura

© DTCOM
Em sua base está a camada chamada de infraestrutura. Nela estão contidos os ele-
mentos de hardware - servidores de dados e de páginas web, conexões físicas de comuni-
cação, entre outros elementos - que dão suporte as demais camadas.
Na camada que comunica diretamente com a infraestrutura, temos os componentes.
Essa camada é responsável por fornecer o serviço para a aplicação acima e por implemen-
tar os artefatos mais comuns ao sistema.
Já na camada superior, temos os serviços. Nela, as ações do sistema ou as funcionali-
dades são implementadas utilizando as duas camadas abaixo.
Agora, veja, na imagem a seguir, alguns exemplos de componentes e serviços ofereci-
dos pela nossa arquitetura fictícia:

Serviço Enviar mensagens Efetuar login Salvar cadastro

Troca de
Componentes Segurança
mensagens

Persistência
Infraestrutura Login
© DTCOM

de dados

Arquitetura de software 79
Ao observar a imagem, podemos notar os seguintes exemplos de serviços oferecidos
utilizando a abordagem SOA: Enviar mensagens, Efetuar login e Salvar cadastro. Esses ser-
viços foram reduzidos para simplicidade didática, mas em um sistema comercial, por exem-
plo, temos diversos deles, provavelmente centenas.
Cada serviço oferecido fornece uma API de comunicação bem definida e segue um
padrão de nomenclatura que facilita a comunicação por outros sistemas. Além disso, cada
serviço apresentado faz uso de alguns componentes específicos oferecidos pelo sistema.
O serviço enviar mensagens, por exemplo, faz uso de um protocolo de comunicação para a
troca de mensagens e de um algoritmo de criptografia de dados para garantir a segurança.
No próximo tópico iremos descrever o principal componente de um sistema orien-
tado a serviços, o próprio serviço.

4.2. Serviço

Um serviço web é uma coleção de protocolos


e padrões públicos que são utilizados para troca de
informações entre aplicações e sistemas. As aplica-

WEB
© toozdesign / / Shutterstock.(Adaptado).

ções de software são diversificadas, utilizam diversas


linguagens de programação e executam em diferen-
SERVICES tes plataformas. Para que o serviço seja acessível por
uma quantidade maior de aplicações e sistemas, usa-se
padrões e APIs bem definidas.
Erl (2009, p. 45) afirma que:

[...] um serviço pode atuar essencialmente como um contêiner de capacidades rela-


cionadas. Ele é composto por um corpo de lógica projetada para executar essas capa-
cidades por um contrato de serviços que expressa quais de suas capacidades são
disponibilizadas para uso.

Para cumprir esse papel de container de capacidades relacionadas, os serviços devem:


• Ser disponíveis pela internet ou intranet;
• Fazer uso de padrões de troca de mensagens bem definidos;
• Não ser dependente de qualquer sistema operacional ou linguagem de programação;
• Se auto descrever utilizando um protocolo público e permitir a descoberta desse
serviço utilizando uma simples e bem definida interface.

80 Arquitetura de software
A figura a seguir ilustra a arquitetura de um web service com quatro serviços distin-
tos que são implementados dentro do servidor. Os web services são requisitados pelo
usuário/cliente e o servidor responde a esse pedido utilizando os serviços implementados
de acordo com a requisição. Após consultar o web service específico, o servidor devolve a
resposta ao cliente. Observe:

insereUsuario apagarUsuario

Requisição
Cliente COMPUTADOR
Resposta

buscalDUsuario excluirUsuario

© DTCOM
Servidor

A tabela a seguir lista os serviços que o sistema oferece com os parâmetros de


entrada e saída (retorno do serviço):

Serviço Parâmetros de entrada Retorno do serviço

Nome: String
Login: String
insereUsuario ID: inteiro
Senha: String
Email: String

buscaIDUsuario Login: String ID : inteiro

excluirUsuario ID: inteiro Resposta : Boolean

apagarUsuario ID: inteiro Resposta : Boolean

Na primeira coluna da tabela temos o nome dos serviços. Esse nome é o que acessa-
remos através da URL, por exemplo: http://localhost:8080/sistemas/insereUsuario.
Os parâmetros de entrada, por sua vez, podem ser passados utilizando o método GET
ou POST do HTTP. Se for utilizado o método GET, os parâmetros apareceram na URL, por
exemplo: http://localhost:8080/sistemas/insereUsuario?Nome=Jose. Por outro lado, se for
utilizado o método POST, os métodos são passados no corpo da mensagem, não sendo
possível visualizar na URL, o que é mais seguro e prático.

Arquitetura de software 81
O método GET possui restrição de tamanho, ou seja, só podemos passar uma certa
quantidade de parâmetros que não exceda o tamanho definido pela URL. No método
POST, além da segurança, não temos essa restrição, tornando a comunicação mais limpa
sem muitos parâmetros na URL.
Ainda nessa segunda coluna, podemos perceber que temos os atributos e seu tipo
correspondente. Por exemplo, o e-mail será um tipo string, enquanto o ID (identificador
único) será um tipo inteiro.
Na terceira coluna temos os atributos de resposta do web service. Após a requisição a
um web service e do processamento dessa requisição, temos a resposta, ou seja, o atributo
que será devolvido ao usuário para finalizar o processo de comunicação.
Essa definição clara dos serviços e seus parâmetros é essencial para construir uma
boa arquitetura.
Na próxima seção iremos descrever, de forma geral, a arquitetura orientada a servi-
ços, chamada de SOA.

4.2.1. Visão geral

O grande objetivo da SOA é a criação de aplicações de forma fácil. Isto é possível


porque todas as funcionalidades dessas novas aplicações já estão implementadas, sendo
responsabilidade da SOA apenas fazer o agrupamento delas (ou implementar o mínimo
possível) para formar um novo sistema.
Dessa forma, as SOAs devem permitir que os usuários agrupem as funcionalidades
para obter novas, seguindo a ideia de software modular e de reuso. Quanto maior for o
agrupamento, menor será a quantidade de interfaces necessárias para implementar um
determinado conjunto de funcionalidades. Se você possui um agrupamento ou modulo
muito grande, por exemplo, provavelmente será mais difícil achar utilidade para ele. A
ideia, então, é criar módulos pequenos e com finalidade bem definida.
Agora para documentar os serviços implementados pela arquitetura SOA, é
disponibilizada uma tabela resumo com todos os serviços e componentes implementados.
Juntamente com essa tabela, tem-se também uma descrição das funcionalidades, da API
de comunicação e dos tipos de dados utilizados na abordagem.
Já para permitir a comunicação entre os serviços descritos utilizando SOA, podemos
utilizar o Simple Object Access Protocol (SOAP) – Protocolo Simples de Acesso a objetos,
em português.

82 Arquitetura de software
A descrição dos metadados, por sua vez, deve acontecer de modo que seja possível a
descoberta e a configuração dinâmica dos serviços para a utilização por outros sistemas.
Para tanto, essa descrição deve manter a coerência e a integridade dos dados.

© Artram / / Shuterstock.
Como opção ao uso da SOA, temos uma abordagem mais atual, o Representational
State Transfer (REST) - Transferência de Estado Representacional, em português. Essa é
uma abordagem que visa apresentar uma API fácil de ser identificada, permitindo que os
serviços oferecidos sejam descobertos de forma automática.
No entanto, o REST é uma abordagem sem estado (stateless), ou seja, os serviços ofere-
cidos não retêm dados da sessão de comunicação e, portanto, cada requisição é individual, não
dependendo das anteriores. Em contrapartida, a SOA possui estados e é utilizada em aplica-
ções que necessitam desse recurso, embora isso seja mais custoso computacionalmente.
Além de tudo que já foi exposto, os serviços também podem ser utilizados para for-
necer uma nova interface de comunicação com sistemas legados, ou seja, com sistemas
que já não fazem uso da tecnologia corrente. Dessa forma, é possível fazer uso dos serviços
para fornecer uma nova forma de se comunicar com esses sistemas.

Pausa para refletir

Você consegue listar alguns tipos de sistemas em que é mais adequado o uso de SOA e
outros em que é mais adequado o uso de REST?

Pode-se dizer, por fim, que os serviços a partir da perspectiva SOA são constituídos
de outros serviços. Isso facilita a construção do sistema e reduz os custos, além de promo-
ver uma padronização na indústria do software. Em contrapartida, o REST provê uma abor-
dagem mais leve, fazendo uso de menos verbos HTTP.
No próximo tópico iremos descrever a granularidade que os serviços podem possuir
de acordo com sua finalidade e implementação.

Arquitetura de software 83
4.2.2. Granularidade

Ao aplicar os conceitos da SOA, a granularidade de um serviço é um ponto chave na


etapa de modelagem. Segundo Erl, 2009 (p. 81):

“O termo ‘granularidade’ é o mais comumente usado para comunicar o nível (ou ausên-
cia de) de detalhes associado a algum aspecto do design de programa de software. No
contexto do design de serviços, nossa principal preocupação é a granularidade do con-
trato de serviços e o que ela representa. Em um serviço, há diferentes formas de gra-
nularidade e todas podem ser influenciadas pela maneira como os princípios de design
da orientação a serviços são aplicados.”

A granularidade de um serviço, portanto, define


© OpturaDesign // Shutterstock. (Adaptado).

o escopo que esse serviço vai abranger. Ela pode


estar presente tanto na lógica do negócio quanto no
design da interface.
A granularidade pode ser grossa ou fina depen-
dendo do tamanho de abrangência para o serviço.
Além disso, Erl (2009) assume que a granularidade
pode se expressar em diversas formas, sendo elas: granularidade do serviço, da capacidade,
dos dados e da restrição.
A granularidade do serviço não reflete a quantidade de lógica que está inserida
nesse serviço, mas a quantidade potencial que esse serviço pode agregar. Um serviço de
granularidade grossa, por exemplo, tem um amplo contexto funcional, mesmo que tenha
uma ou dez capacidades expressadas.
Nesse sentido, uma granularidade grossa possui um escopo maior de abrangência
para o serviço. Imagine que temos um serviço para pesquisar um CPF em todas as bases
de dados do Brasil e outro serviço para busca-lo em uma única base de dados. O primeiro é
um serviço mais amplo, pois exige o uso de diversos outros serviços (granularidade grossa),
enquanto que o segundo é um serviço mais simples, ou seja, de granularidade fina. Um ser-
viço de granularidade grossa geralmente exige um número maior de chamadas a métodos
ou outros serviços para oferecer o serviço disponibilizado.
Já a granularidade da capacidade expressa a quantidade de trabalho computacional que
deve ser realizado em um determinado momento. De forma geral, uma capacidade de granu-
lação fina terá menos trabalho a ser realizado quando comparada a uma de granulação grossa.

84 Arquitetura de software
Na granularidade dos dados, por sua vez, se temos uma grande troca de dados,
podemos dizer que temos uma granularidade grossa. Se temos pouca troca de dados, por
outro lado, como no estilo de comunicação Remote Procedure Call (RPC) – Chamada de Pro-
cedimento Remoto, em português -, temos uma granularidade fina.
Por fim, a granularidade da restrição expressa a quantidade de detalhes de uma
determinada entidade. Pode-se exigir, por exemplo, que se siga restrições de tamanho, de
tipo e formato de dados, entre outras.
Encontrar uma granularidade ideal é uma tarefa bem complexa e, muitas vezes, sub-
jetiva. Não há uma resposta definitiva, mas podemos seguir os parâmetros citados ante-
riormente para encontrar uma solução boa.
Muitos fatores podem influenciar a granularidade de um serviço. A seguir será listado
quatro fatores principais que devem ser considerados no momento da modelagem do ser-
viço, sendo eles: função do negócio, desempenho, tamanho da mensagem e qualidade do
serviço (Quality-of-service - QoS).

Dica
Há diversas métricas que podem ser utilizadas para avaliar o QoS de um serviço.
Podemos utilizar, por exemplo, a quantidade de frames executados em um vídeo ou a taxa
de download de um arquivo. Quanto maiores essas quantidade e taxas, melhores os serviços.

No critério função do negócio cada serviço deve objetivar somente uma única função
no domínio do negócio. Isso deixa a implementação do serviço mais simples e consequen-
temente, promove um baixo acoplamento.
No quesito desempenho, por sua vez, devemos garantir que os serviços web sejam
acessados de forma remota por chamadas na rede. Isso aumenta a quantidade de tráfego
na rede e, consequentemente, o tempo de resposta. O objetivo dessa prática é criar servi-
ços que façam o mínimo de chamadas possíveis.
Quanto ao tamanho da mensagem, é preciso que a ela seja pequena pois, quanto menor
ela for, mais compacto será o serviço e, consequentemente, menor será o uso de recursos.
Geralmente serviços de granularidade grossa necessitam passar mais dados (maior
tamanho de mensagem) do que um serviço de granularidade fina. Esse processamento com-
putacional intenso pode levar a perda de desempenho no sistema que faz uso do serviço ou
no que o hospeda. No entanto, é possível reduzir a complexidade de um serviço de granulari-
dade grossa implementando vários outros serviços menores de granularidade fina.

Arquitetura de software 85
No último critério temos a qualidade do serviço, que se refere a integridade dos
dados. Os serviços devem operar em uma única transação, ou seja, eles devem executar
tudo que foi planejado ou não executar nada. Isso garante integridade nos dados e con-
fiança no fornecimento do serviço. Além disso, esse processo melhora o processo de recu-
peração após um erro, facilitando a modelagem do serviço.
Conhecidos os conceitos relacionados aos serviços, no próximo tópico iremos descre-
ver exemplos de aplicação que envolvem a SOA.

4.3. Aplicação

Até o momento, vimos a teoria que contempla as SOAs e também alguns exemplos
de como aplicar seus conceitos na construção de sistemas web. Nesta seção, por sua vez,
iremos focar na descrição de um exemplo prático do design de um sistema utilizando os
conceitos SOA e comentar as vantagens e desvantagens de seu uso. Acompanhe!

4.3.1. Exemplo de aplicação

Como exemplo, iremos modelar um sistema simplificado de uma universidade. A figura


a seguir ilustra a arquitetura da nossa aplicação que é composta por quatro sistemas distin-
tos: sistema de RH, sistema de marketing, sistema acadêmico e sistema de pagamento.

Sistema de RH Sistema de marketing

BD REDE BD

Sistema acadêmico Sistema de pagamento


© DTCOM

BD BD

O sistema de RH contempla a administração dos colaboradores da empresa, con-


tendo suas informações pessoais, contratos, dentre outras informações relacionadas aos
colaboradores da universidade. O sistema de marketing, por sua vez, contém as ativida-
des relacionadas a divulgação da universidade junto à comunidade. Já o sistema acadêmico

86 Arquitetura de software
concentra informações relacionadas às aulas, às avaliações, à alocação da estrutura física,
dentre outras atribuições. Por fim, o sistema de pagamento remete ao gerenciamento dos
pagamentos dos alunos e funcionários.
Diante da figura, podemos perceber que cada sistema possui um banco de dados pró-
prio e que a integração desses sistemas é feita somente pela rede de dados, sendo neces-
sário, portanto, definir um protocolo de comunicação para esses sistemas.
Para tanto, cada sistema deve descrever uma API para comunicação com os demais
sistemas, fornecendo somente as informações necessárias. Isso garante uma certa segu-
rança, pois somente é exposto o que se deseja expor, sem que os demais sistemas acessem
diretamente o código fonte ou os métodos da aplicação.
No próximo tópico iremos destacar alguns vantagens e desvantagens da arquitetura
SOA.

4.3.2. Vantagens e desvantagens da arquitetura SOA

Como vimos anteriormente, o uso de arquiteturas orientadas a serviço possui algu-


mas vantagens como:
• Redução da complexidade através do menor acoplamento entre os componentes;
• Melhor divisão de tarefas entre os módulos;
• Padronização da comunicação e oferta de serviços de forma dinâmica e automatizada;
• Fornecimento de serviços de granularidade fina para as camadas superiores.
Além disso, a arquitetura SOA é essencial para o aprimoramento dos sistemas dispo-
níveis no cenário mundial. Isto porque ela permite agilidade, reuso de software, facilidade
na manutenção, além de flexibilidade e rapidez nas adaptações dos serviços que precisam
ser modificados para acompanhar a constante evolução do mercado.
Porém, todo tipo de desenvolvimento de
software oferece desvantagens. No caso da
SOA, como ela depende fortemente de normas
e padrões de codificação, a sua implementação
pode ser mais difícil de ser realizada. Além disso,
© Eviart / / Shutterstock.

esse tipo de arquitetura não é recomendável para


aplicações que precisem transferir grandes quan-
tidades de dados ou que demandem um alto aco-
plamento entre seus componentes.

Arquitetura de software 87
Outra desvantagem se apresenta devido à quantidade de serviços que são implemen-
tados na arquitetura SOA. Desse modo, podemos ter problemas em gerenciar essa grande
quantidade. Adicionalmente, se temos muitos serviços, iremos ter muitos acessos a esses
serviços, o que pode levar a problemas de infraestrutura que implicam em altos custos de
manutenção para manter o desempenho desejado do sistema.
Por fim, é muito complexo testar e depurar serviços já em execução na arquitetura
SOA. Isto porque, devido ao uso de internet ou intranet, há um tráfego de dados por meios
não seguros, o que pode levar os dados a serem interceptados, alterados ou lidos por pes-
soas não autorizadas.
Embora a SOA possua algumas desvantagens, uma abordagem tradicional de desen-
volvimento de software não é mais suficiente para suprir as necessidades das organi-
zações, sendo o uso da arquitetura orientada a serviços, portanto, uma resposta às
dificuldades enfrentadas no desenvolvimento de software.

Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa,
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.

Agora é a hora de recapitular tudo o que você aprendeu nesse capítulo! Elabore uma arquite-
tura, utilizando uma notação de sua escolha, para representar um sistema fictício. Ao produ-
zir a arquitetura, siga todos os princípios SOA que vimos neste capítulo. Para tanto, aplique
todo o conhecimento adquirido nos capítulos da disciplina e considere as leituras básicas e
complementares realizadas para ampliar seu conhecimento.

Recapitulando

No decorrer desse capítulo aprendemos que o acoplamento corresponde ao nível de


dependência que um módulo do sistema apresenta em relação a outros módulos. Nesse
sentido, quando um software apresenta um alto acoplamento, tem-se um aumento na
complexidade da implementação e uma maior dificuldade na correção de erros.
A principal vantagem de uma abordagem SOA, nesse sentido, é o baixo acoplamento,
o que impacta diretamente no sistema desenvolvido. Esse baixo acoplamento torna a
arquitetura mais simples, facilitando, por exemplo, a inserção de funcionalidades e a manu-
tenção do sistema, além de permitir uma maior segurança na troca de informações.

88 Arquitetura de software
Além disso, pudemos perceber que alguns tipos de sistemas são mais indicados para
aplicarem os conceitos SOA do que outros. Sistemas que exigem uma maior segurança no
envio e recebimento de mensagens, por exemplo, devem aplicar os conceitos SOA, mesmo
que isso represente um atraso na comunicação. Isso é justificado pela segurança reforçada
que a arquitetura SOA oferece. Por outro lado, aplicações que exigem menos tráfego de
dados, e que não precisam guardar os estados das sessões anteriores, podem utilizar REST,
tornando as aplicações menos complexas.

Arquitetura de software 89
Referências

GAMMA, E. et al. Padrões de projeto: soluções reutilizáveis de software orientado a obje-


tos. Porto Alegre: Bookman, 2000.
ERL, T. SOA design patterns. Boston, Prentice Hall, 2009
THE OPEN BOOK. SOA Source Book. Van Haren Publishing, 2009. Disponível em: <www.
opengroup.org/soa/source-book/soa/p1.htm#soa_definition/>. Acesso em 17 de outubro
de 2018.

90 Arquitetura de software
CAPÍTULO 5

Arquitetura n-tier
Georgia Maria Ferro Benetti

OBJETIVOS DO CAPÍTULO
• Empregar uma arquitetura n-tier, analisando as restrições e benefícios através de
modelos e exemplos de aplicação.

TÓPICOS DE ESTUDO

1 Camadas 2 Aplicação

• Camada cliente. • Exemplo de aplicação.


• Camada aplicação. • Vantagens e desvantagens da
• Camada banco de dados. arquitetura n-tier.

Arquitetura de software 91
Contextualizando o cenário

Nos anos 80 predominava-se a arquitetura centralizada, em que computadores do tipo main-


frame reuniam interface e processamento em um único componente físico.

Mas, devido à evolução da tecnologia da informação e ao desenvolvimento e expansão das


redes de computadores, os sistemas se tornaram cada vez mais complexos e passaram a
pedir mais escalabilidade.

Dessa forma, como alternativa à arquitetura centralizada, surgiram os sistemas distribuídos,


planejados com arquitetura em camadas.

A arquitetura em camadas permitiu vários avanços para os sistemas de informação. Entre


eles, podemos citar o desenvolvimento de interfaces gráficas mais intuitivas e amigá-
veis, além da utilização de desktops que permitem o acesso de dados localizados em outra
máquina ou em outro local de rede.

Dito isso, cabe a pergunta: qual o tipo de arquitetura é mais indicado para os sistemas,
considerando que temos aplicações complexas e multiplataforma que podem ser acessa-
das por terminais desktop, web e mobile?

92 Arquitetura de software
5.1. Camadas

A arquitetura em camadas é uma maneira de organizar os componentes de um sis-


tema em uma estrutura hierárquica, atribuindo a cada um deles responsabilidades específi-
cas e bem definidas.
Esse tipo de arquitetura promove uma separação lógica entre as partes do sistema
e é interligado por uma hierarquia do tipo cliente-servidor. Assim, uma camada superior é
cliente da inferior, que, por sua vez, é responsável por promover serviços a ela. Como uma
camada só pode fazer solicitações as que estão abaixo dela, também podemos considerar
esse tipo de arquitetura como um recurso para gerenciar dependências.
Para exemplificar essa arquitetura, imagine que um sistema seja projetado com uma
camada de apresentação, uma de regras de negócio e outra de banco de dados. Cada uma
dessas camadas, então, além de apresentar componentes, funcionalidades e códigos pró-
prios, se comunica uma com a outra, via interface, com o mínimo de acoplamento possível.
(SILVEIRA et al., 2011).
Esse tipo de organização permite a atualização de apenas uma das camadas, possibili-
tando manutenções e atualizações focadas sem impactar negativamente todo o sistema em
caso de erro. Veja na imagem a seguir a representação de uma arquitetura multicamadas que
pode ser acessada por vários clientes diferentes mantendo uma única camada de apresentação.

Serviço de Suporte

Cliente 1
Proteção de dados © VasutinSergey / / Shutterstock (Adaptado).

Enviar

Cliente 2

Enviar

Cliente 3 Backups Servidor

Arquitetura de software 93
Já a arquitetura n-tier se baseia no conceito de camadas, promovendo não apenas
a separação lógica, mas também a separação física entre as diferentes camadas. Assim,
tem-se uma arquitetura do tipo cliente-servidor que concentra a função de processamento
na camada do servidor.

Afirmação
Com a virtualização das máquinas e com a computação em nuvem, os limites
físicos ficaram mais difíceis de estabelecer. É possível pensar em tiers, portanto, como com-
ponentes que têm comunicação remota por meio de rede, estando eles em espaços físicos
diferentes ou não (Silveira et al., 2011).

O termo tier (inglês) significa “camada” e, conforme Fowler (2009), é preciso tomar
cuidado para não confundi-lo com o termo layer (inglês), que também significa “camada”.
Embora os dois tenham a mesma conotação, quando empregados como termos técnicos,
representam coisas diferentes.
Layer refere-se ao conceito de arquitetura em camadas, que pode variar conforme
sejam empregados diferentes tipos de organização e aplicação. Já tier é um tipo específico
de layer, configurando uma arquitetura organizada com camadas baseadas em responsabi-
lidades (EELES, 2002).
Cada camada lógica (layer) está localizada em uma diferente camada física (tier) para
melhorar a escalabilidade e a resiliência do sistema, mas esse efeito vantajoso pode acarre-
tar em um indesejável aumento da latência da comunicação de rede adicional.
Na arquitetura n-tier, o número de camadas pode variar n vezes conforme os requisi-
tos de complexidade e abstração do sistema (Chartier, 2002). Contudo, em uma aplicação
clássica, que é o formato a ser estudado nesse capítulo, teremos três camadas (3-tiers):
• Camada de apresentação (cliente);
• Camada intermediária (aplicação);
• Camada de banco de dados.

Esclarecimento
O n significa o número de camadas.

A seguir, estudaremos cada uma dessas camadas detalhadamente. Acompanhe!

94 Arquitetura de software
5.1.1. Camada cliente

As camadas do tipo cliente, também chamadas de camadas de apresentação, “for-


necem funcionalidades destinadas à comunidade de usuários” (Sommerville, 2011 p. 678).
O conceito de comunidade de usuários deve considerar não apenas os seres humanos, mas
toda fonte externa de usuários que possam proporcionar entradas aos sistemas, ou seja,
inclui também outras aplicações e dispositivos.
Exemplos dessas fontes externas de usuários são os robôs spiders e crawlers, que per-
correm as redes e executam funções diversas em sites, como recolher dados para big data,
adicionar seguidores em redes sociais e executar outras funções em aplicações web.

Pausa para refletir

Algumas interfaces dos sites costumam solicitar para você assinalar um check box atestando
que não é um robô ou solucionar um desafio cognitivo CAPTCHA. Você conhece as razões e
consequências da adoção desses recursos?

Podemos dizer que a camada de apresentação con-


centra as informações que serão visualizadas e utiliza-

© LuckyDesigner / / Shutterstock. (Adaptado).


das pelos usuários. Assim, ela atua como uma via de mão
dupla, disponibilizando informações para usuários e, ao
mesmo tempo, obtendo informações deles.
Esse tipo de camada baseia-se nos pedidos que envia
a seus servidores para realizar as entradas e as saídas do
sistema. Logo, essa camada é responsável por captar as
informações e ações que vêm do usuário; transforma-las em requisições para as camadas
inferiores que irão processá-las; e devolver o resultado desse processamento com informa-
ções que possam ser compreendidas e utilizadas pelo requisitante.
Em uma arquitetura multicamadas, a camada cliente oferece suporte a múltiplos
clientes, podendo ser acessada em desktop - web ou mobile - pendrives e smartcards. Para
tanto, ela pode estar alocada nas estações cliente, como em programas instalados em
computadores, ou rodar em servidores.
A figura a seguir ilustra o relacionamento das camadas inferiores com as interfaces
múltiplas de uma camada de clientes. Por meio dessas muitas possibilidades, a interação
com o sistema adquire flexibilidade e os usuários podem, por exemplo, realizar uma opera-
ção de entrada por meio de um desktop e acessar a saída dessa operação por um disposi-
tivo móvel, ou vice-versa.

Arquitetura de software 95
Camada Cliente Camada Intermediária Camada de Dados

© TechnoVectors / / Shutterstock (Adaptado).


Como a camada cliente está no topo da hierarquia do sistema, ela depende de
outra(s) camada(s) para que as ações sejam executadas. Ela pode chamar essas outras
camadas de aplicação, mas nunca pode atuar como servidor.
É importante ressaltar que uma aplicação pode conter mais de uma camada de
apresentação. Dessa maneira, uma loja virtual que dispõe de um browser web com uma
vitrine de produtos e um formulário de cadastramento de clientes, por exemplo, pode
atualizar sua vitrine sem que os formulários de cadastro sejam atualizados.

Esclarecimento
A expansão das redes computadores torna vantajoso dividir a camada de apresenta-
ção da web. Dessa maneira há economia de recursos, uma vez que não é preciso instalar a aplica-
ção em cada computador que vai acessá-la. Esse raciocínio também é valido para intranets.

Já a representação visual e funcional da camada de apresentação pode ser bem sim-


ples e conter apenas uma linha de comando, mas é mais comum trabalhar com interfaces
gráficas complexas em clientes ricos (quando todas as funções específicas da aplicação são
implementadas nas camadas cliente) e em interfaces baseadas em HTML (Fowler, 2009).
As interfaces baseadas em HTML têm como característica ser do tipo front end, ou
seja, contém códigos desenvolvidos em HTML, CSS e JavaScript, ou equivalentes, referen-
tes à apresentação gráfica e aos campos de formulário. Um exemplo de camada de apre-
sentação baseado em HTML, válido para aplicações web, são os diferentes navegadores
que nos dão acesso às informações disponíveis na internet.

96 Arquitetura de software
Em tempos de computação em nuvem e de internet das coisas (IOT), devemos pen-
sar na camada de apresentação como o resultado de saída do sistema que fica acessível
por meio de vários clientes. Esses clientes podem estar associados a computação ou não,
podendo ser monitores, televisões, displays diversos, leitores de códigos de barras, pulseira
e relógios do tipo smart, impressoras, dispositivos de GPS, dispositivos médicos, automó-
veis e, até mesmo, aspiradores de pó.

Esclarecimento
é a interação inteligente dos objetos entre si e em rede de forma a tornar as
ações do cotidiano mais eficientes (DE MENEZES et. al, 2017).

Agora que já compreendemos o que é a camada de apresentação, vamos conhecer a


camada de aplicação.

5.1.2. Camada aplicação

A camada de aplicação, também conhecida como camada de lógica de negócios,


contém as regras de negócio, os requisitos e as funcionalidades do sistema, sendo respon-
sável por intermediar o acesso da camada cliente ao banco de dados (MARTINS, 2006).
Logo, ela é uma camada intermediaria que coordena todo o trânsito de informações, sendo
a única que tem acesso direto ao banco de dados.
Essa camada é a que efetivamente faz o trabalho previsto no domínio de negócio da
aplicação. Ela, portanto, é responsável pela configuração de parâmetros, pelos cálculos
que utilizam dados de entrada e dados do banco, pela validação de dados, pela compreen-
são dos dados a serem executados a partir de comandos realizados na interface, pelos cli-
ques com mouse, pela digitação em teclado, entre outras funções (FOWLER, 2009).
A camada de aplicação, é um desenvolvimento do tipo back end (utiliza uma lingua-
gem que é entendida somente pelo servidor), na qual o usuário não tem acesso direto. Para
tanto, essa camada pode empregar diferentes linguagens, como JSP, Java Servlets, Ruby,
PHP, Python ou equivalentes, podando rodar tanto em uma máquina local quanto em uma
estrutura em nuvem.
Por ser back end e estar subjacente e subordinada à camada de apresentação, a
camada de aplicação se comunica com as adjacentes por meio de interfaces abstratas.
Essas interfaces mapeiam as operações, definindo as entradas e saídas necessárias para

Arquitetura de software 97
que elas sejam realizadas. Esse funcionamento oculta os detalhes dos componentes e das
funções desempenhadas por eles, o que pode ser considerado um incremento de segu-
rança adicionado pela arquitetura de três camadas.

Pausa para refletir

A comunicação entre as camadas pode se dar com mais ou com menos conhecimento do
conteúdo das camadas adjacentes. A camada de banco de dados, por exemplo, só pode ser
acessada via camada de aplicação Dito isso, o quanto cada uma das camadas “conhece” e
depende do trabalho feito por outra?

Apesar do modelo clássico da arquitetura n-tiers ser bem comum e suficiente para
aportar a maioria dos sistemas, em alguns casos pode ser interessante projetar mais cama-
das através da divisão da camada de lógica de negócios.
Essa divisão pode prover escalabilidade e prevenir o congestionamento dos servido-
res, uma vez que possibilita distribuir as requisições por funcionalidade (compra, venda,
trocas, entre outras). A imagem abaixo representa essa divisão através de uma arquitetura
5-tiers:

© TechnoVectors / / Shutterstock.

98 Arquitetura de software
Uma divisão comum da camada de aplicação acontece na separação das regras de
negócio das regras de acesso ao banco de dados, como ilustra o diagrama a seguir:

Camada de Apresentação

WEB SERVICES

Camada de Aplicação Camada de Aplicação


Regras de Negócio Regras de Acesso ao Banco de Dados

Camada de

© DTCOM
Banco de Dados

A disposição das regras de negócio em uma camada única confere flexibilidade ao


software, permitindo que novos requisitos sejam implementados rapidamente.
Uma prática interessante utilizada na camada de aplicação é o uso de APIs (Applica-
tion Programming Interface - Interface de Programação de Aplicativos, em português), que
possibilitam utilizar as funcionalidades de um aplicativo mesmo desconhecendo detalhes
da sua implementação. Esse recurso permite que uma camada encapsule certas funcionali-
dades de camadas inferiores.
Mas, conforme Fowler (2009), é preciso estar atento à essa prática, uma vez que as
camadas não são eficientes em encapsular todas as funcionalidades. Em caso de modifi-
cações que se refletem em todo o sistema, por exemplo, pode-se esbarrar no limite lógico
entre as camadas.
Por fim, podemos dizer que a organização possibilitada pela arquitetura em cama-
das, quando bem elaborada, é uma alternativa interessante para promover o devido grau
de acoplamento abstrato entre classes (alcançado por meio de interfaces da camada de
aplicação), sem pôr em risco a flexibilidade e portabilidade do sistema. Conforme Gamma
(2000) quando as classes de um código são muito acopladas seu reuso se torna difícil e o
sistema adquire a característica de ser monolítico, ou seja, de difícil atualização e manu-
tenção. Quando o acoplamento é fraco, por outro lado, a possibilidade de portabilidade e
ajuste é bem mais ampla.

Arquitetura de software 99
A partir do que foi estudado até agora, percebe-se que a camada de aplicação pode ser
considerada o cérebro ou o coração das aplicações, já que ela contém as regras de negócio
dos sistemas. Dito isso, vamos então estudar a camada subsequente, a de banco de dados.

5.1.3. Camada banco de dados

A camada de banco de dados é uma camada do tipo servidor que atende as camadas
de aplicação. Portanto, ela sempre roda em servidores, exceto quando se tem um cliente
muito potente capaz de sincronizar todo o banco com o servidor e que deseje operar nele
desconectado do servidor. (Fowler, 2009)
Segundo Sommerville, 2011 (p. 678):

A base de dados estabelece a fundação de uma arquitetura cliente-servidor e gerencia


transações e consultas dos aplicativos do servidor. No entanto, essas transações e con-
sultas devem ser controladas com base em um conjunto de regras de negócio (defini-
das por um processo de negócio existente ou que passou por uma reengenharia).

A camada de banco de dados é a mais inferior da aplicação, contendo as estruturas e


tecnologias de gestão e armazenamento de informação. Nessa camada há uma restrição
que determina que os dados só podem ser lidos pela camada de aplicação, garantindo
maior segurança aos dados armazenados.
Para essa camada ser projetada, ela precisa envolver alguma tecnologia de banco de
dados, como PostgreSQL database, MySQL, NoSQL ou equivalentes. A interface da camada
de aplicação, por sua vez, deve ser compatível com a tecnologia escolhida e conter méto-
dos que invoquem a camada de dados.
Essa relação da camada de aplicação
com o banco de dados confere maior liber-
dade e flexibilidade ao sistema, tornando pos-
sível a troca de tecnologia e de fornecedor de
© everything possible / / Shutterstock

banco de dados sem impactar outras cama-


das do sistema. Isso também permite que a
aplicação varie e incorpore diferentes configu-
rações de bancos de dados - relacionais, não
relacionais, legados e assim por diante.
Essa flexibilidade também é uma solução para a persistência de dados. Como
as organizações trabalham com dados que precisam ser guardados por longos perío-
dos de tempo, a disponibilidade desses dados não pode estar sujeita a durabilidade das

100 Arquitetura de software


tecnologias e aplicações. Desse modo, uma camada de dados desacoplada do restante do
sistema permite a migração dos dados e lhes confere uma vida mais longa.
Agora que completamos nossos estudos acerca da estrutura básica que compõem
uma arquitetura n-tier, a seguir iremos exemplificar esse conteúdo através de uma aplica-
ção que utiliza esse tipo de arquitetura. Acompanhe!

5.2. Aplicação

Uma aplicação que apresenta uma arquitetura do tipo n-tier é construída em um


número n de camadas lógicas que estão fisicamente separadas. Esse modo de projetar sis-
temas amplia as possibilidades de operação, permitindo o acesso de múltiplos clientes,
uma característica cada vez mais desejável às aplicações disponíveis no mercado.
Essa separação física das camadas, de modo que cada uma seja autocontida e isolada
das outras, também permite que a aplicação rode distribuída em locais de rede diferentes,
podendo esses locais serem físicos ou situados na nuvem de computadores.
No exemplo que veremos a seguir, compreenderemos como esses conceitos aconte-
cem na prática. Acompanhe!

5.2.1. Exemplo de aplicação

Para que você possa visualizar uma aplica-


ção planejada com a arquitetura 3-tier, escolhemos
o case de um projeto GIS (Geography Informa-
tion System – Sistema de informação Geográfica,
em português), desenvolvido por Miranda et al.
© Naschy / / Shutterstock.

(2002). Essa aplicação é um tipo de GIS que gera


mapas e roda em ambiente web.
A camada de apresentação desse frame-
work contém páginas JSP geradoras de HTML
e SVG para apresentar imagens e mapas. A camada de aplicação, por sua vez, é desen-
volvida em Java para acessar dados geográficos e não geográficos. Já a camada de dados
contém um banco de dados relacional.
A aplicação gera um mapa com o qual o usuário pode interagir. Para obter o mapa,
o usuário faz a requisição por meio da interface e informa alguns aspectos sobre os dados
geográficos. Essa requisição desencadeia o seguinte fluxo:

Arquitetura de software 101


camada de aplicação converte para
OPENGIS, formata em um tipo de
camada
saída específico requisitado pelo
usuário instancia camada de apli- de dados
usuário (existem várias saídas para
objetoIGISrequest cação requisita a disponibiliza
o mesmo dado) e disponibiliza para
---→ de dados ----→ os dados
a camada de apresentação cujo
---→
acesso pode ser feito a partir de
múltiplos dispositivos e interfaces.

Fonte: Adaptado de Miranda et al., 2002, p. 157

A camada de aplicação, por sua vez, contém quatro módulos, conforme ilustra o dia-
grama a seguir:

1 Controle Define a sequência das ações das camadas.

Carregador Obtém dados espaciais e transforma o sistema independente da tecno-


2
de Dados logia de banco de dados utilizada.

Modelo de
3 Permite manipular os dados de forma independente do banco de dados.
Dados

Inclui um formatador próprio do objeto de modelo de dados que permite


Formatador
4 alterar o formato de saída sem qualquer alteração no modelo. Nesse
de Saída
caso, a alteração é feita no formatador.

Fonte: Adaptado de Miranda et al. 2002, p. 158

Esse GIS se propõe a ser diferente dos outros GISs disponíveis no mercado. Entre
outras características técnicas, sua arquitetura em n-camadas foi escolhida para proporcio-
nar escalabilidade e equilibrar o balanceamento de carga.
Para tanto, sua camada de apresentação, além de ser uma interface funcional, tam-
bém desenha os mapas. Assim, a responsabilidade pela formatação dos dados é transfe-
rida, em grande parte, para essa camada. Com isso, é possível alterar os formatos de saída
sem a necessidade de alterar o modelo de dados.
Essa organização permite exportar os mapas gerados em formato de imagem varia-
dos, como PNG, GIF, JPEG, e até mesmo em formatos proprietários, ArcInfo e MapView. Essa
camada também tem funcionalidades relacionadas à visualização dos mapas, como zoom e
exibição de coordenadas geográficas ao posicionar o mouse sobre um ponto do mapa.
A camada de aplicação, por sua vez, consegue trabalhar com os dados de maneira
independente do banco de dados e inclui a classe AbstracFormatable que contém atributos
e métodos que são comuns a todos os objetos formatable. Com isso, é possível dispensar a
implementação de métodos da interface formatable.

102 Arquitetura de software


Por fim, a camada de dados possui recursos tecnológicos que possibilitam armaze-
nar, recuperar e alterar dados espaciais.
Pode-se perceber, portanto, que a arquitetura n-tiers pode apresentar soluções inte-
ressantes para problemas reais que abrangem uma grande comunidade. A aplicação que
acabamos de estudar, por exemplo, promove um avanço nos sistemas SIGs já existentes,
uma vez que expande as aplicações web.
Mas a arquitetura n-tiers não é solução para todo e qualquer problema, por isso
vamos refletir sobre algumas vantagens e desvantagens desse tipo de arquitetura com o
objetivo de avaliar corretamente os casos em ela deve ser adotada.

5.2.2. Vantagens e desvantagens da arquitetura n-tier.

Quando pensamos em arquitetura em camadas, o ideal é modelar o mínimo de cama-


das possível. Para alguns sistemas, por exemplo, uma única camada já é suficiente.

Pausa para refletir

Uma aplicação n-tiers padrão possui três camadas. Qual é o anti padrão (anti-pattern) desse
modelo? Em que casos pode ser útil aplicá-lo?

Nesse sentido, um dos desafios da arquitetura em camadas é definir bem o número


de camadas. Assim, é preciso estar atento à essa decisão, pois ela envolve custo-benefício.
Poucas camadas com tamanho muito grande, por exemplo, podem ter baixo índice
de reuso. Mas, por outro lado, a fragmentação em muitas camadas está associada a baixo
desempenho dos sistemas.
Vamos, então, refletir sobre as vantagens e desvantagens desse tipo de arquitetura,
começando pelos pontos positivos:
• Modularização do software: a divisão de responsabilidades facilita o geren-
ciamento e permite que o software seja atualizado e mantido com maior flexi-
bilidade. Como as aplicações mudam e evoluem rapidamente, uma arquitetura
multicamadas permite modificar apenas a tecnologia utilizada em uma das cama-
das, sem ter que atualizar a aplicação inteira. Se temos uma camada de banco de
dados independente, por exemplo, é possível atualizá-la sem ter que trabalhar no
restante da aplicação, o que não é possível em uma arquitetura de camada única.

Arquitetura de software 103


• Especialização da equipe de desenvolvimento: como cada camada tem funciona-
lidades e responsabilidades específicas, times diferentes podem trabalhar em cada
uma delas focando em um tipo específico de desenvolvimento ( front end, back end
ou DBA – Desenvolvimento de Banco de Dados, por exemplo). Isso permite que os
profissionais aprendam e adquiram experiência mais rapidamente, além de propi-
ciar uma equipe com profissionais especializados no trabalho que desenvolvem.
• Segurança: cada camada pode ter seu próprio tratamento de segurança, e isso
pode ser feito através da utilização de diferentes métodos. Além disso, o fato de
os dados estarem armazenados longe da camada de apresentação impossibilita o
acesso direto dos clientes aos dados, garantindo maior segurança.
• Flexibilidade: como as camadas são independentes, cada uma delas pode ser
ampliada isoladamente, conforme seja necessário. Isso facilita a adição de
recursos.
• Escalabilidade: a divisão em camadas permite aumentar a capacidade de operar ser-
viços de modo progressivo. Para tanto, ela possibilita a identificação dos componen-
tes que são mais ativos e requisitados, além de orientar e permitir sua duplicação caso
haja necessidade de melhorar o desempenho do sistema. Também é possível modular
a capacidade dos servidores à demanda de usuários de maneira proporcional.
• Facilidade de reuso: por conter n camadas isoladas, é possível que uma camada
seja reutilizada integralmente em outro sistema.
• Balanceamento de carga: como as responsabilidades são divididas entre as cama-
das, se a aplicação é bem planejada, os recursos das camadas mais profundas
podem ser economizados e postos em ação apenas quando necessário.

Mesmo tendo todos esses pontos positivos, a arquitetura n-tier também apresenta
algumas desvantagens a serem consideradas:
• Não é aplicável a todos os sistemas: embora seja bem popular, não faz sentido
adotar esse tipo de arquitetura em sistemas que só precisam resgatar informações
no banco de dados no formato de output que o banco fornece, por exemplo. Se a
camada intermediária não tem função definida e não modifica os dados, ela só vai
tornar o sistema mais lento.
• Tráfego da informação: como as camadas só se comunicam com as adjacentes,
a informação precisa passar em vários níveis de sistema mediante operações que
implementam sucessivos calls.

104 Arquitetura de software


• Segurança: aparentemente, esse tipo de arquitetura tem mais recursos de segu-
rança, porém, como envolve diversos servidores conectados em rede, requer aten-
ção. Quanto maior for o sistema, mais difícil se torna a gestão de segurança.
• Desempenho: esse tipo de arquitetura requer recursos de hardware e de rede que
sejam rápidos ao rodar as múltiplas requisições para que o desempenho do sistema
não fique comprometido. Essa estrutura pode acarretar em custos elevados.
Conhecidas as vantagens e desvantagens das arquiteturas multicamadas, vamos, a
seguir, aprimorar o conteúdo estudado realizando a atividade proposta.

Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa,
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.

Agora é a hora de recapitular tudo o que você aprendeu nesse capítulo! Elabore um diagrama
que represente uma loja virtual, cuja aplicação tenha sido desenvolvida com uma arquite-
tura n-tier. Justifique sua proposta de arquitetura detalhando cada camada e enumerando as
vantagens e desvantagens esperada para a implementação da aplicação. Aqui é interessante
definir aspectos como volume de tráfego no site, operações mais acessadas e volume de
requisições. Ao produzir seu case, considere as leituras básicas e complementares realizadas.

Recapitulando

A arquitetura em camadas é um formato reconhecidamente eficiente em dividir um


sistema, podendo ser adotado pela maioria das aplicações atuais.
Quando a separação dos componentes de um sistema define camadas lógicas, mas
também desencadeia uma separação física, o termo “camada” assume uma nomenclatura
específica e técnica em inglês denominada tiers. Nesse caso específico, em que ocorre sepa-
ração física das camadas, a arquitetura multicamadas é chamada de arquitetura n-tiers.
Em seu formato mais popular, essa arquitetura se organiza em três camadas: de apre-
sentação ou cliente, de aplicação ou domínio e de banco de dados. Cada uma dessas
camadas tem uma posição fixa na organização hierárquica, além de funções e responsabili-
dades próprias.
Na arquitetura n-tiers, as camadas são independentes umas das outras e se comu-
nicam por interfaces, o que possibilita a adoção de novas tecnologias que possam surgir
depois do sistema desenvolvido. Portanto, é possível a adição de novos componentes sem

Arquitetura de software 105


que toda a aplicação precise ser modelada ou reescrita. Além disso, esse tipo de arquite-
tura permite o acesso de múltiplos clientes.
Embora apresente algumas desvantagens para as quais devemos estar atentos, essa
organização em n-camadas costuma ser considerada vantajosa pelos estudiosos da área.
Isto porque ela confere maior potencial de reuso e escalabilidade, além de facilitar a atuali-
zação e a manutenção das aplicações.
Por fim, como grande vantagem, esse tipo de arquitetura tem sua camada de apre-
sentação independente das demais. Isso possibilita o fácil ajuste dos requisitos de aplica-
ções multiplataforma, que são cada vez mais comuns, uma vez que se aplicam em sistemas
desktop, web e mobile.

106 Arquitetura de software


Referências

DE MENEZES, M. et al. A prática da teoria–vivenciando a Internet das Coisas na mobi-


lidade urbana. SIGraDi 2017 - XXI Congresso da Sociedade Ibero-Americana de Gráficos
Digitais. Concepción, Chile, 22 a 24 de novembro de 2017. Disponível em: <papers.cumin-
cad.org/data/works/att/sigradi2017_030.pdf>. Acesso em 28 de novembro de 2018.
CHARTIER, R. Application Architecture: An N-Tier Approach. INT Media Group, 2002.
ENGHOLM JR, Hélio. Engenharia de Software na prática. Novatec Editora, 2010.
EELES, P. Layering strategies. Rational Software White Paper, TP, v. 199, n. 08, p. 01,
2002.
FOWLER, M. Padrões de arquitetura de aplicações corporativas. Bookman, 2009.
GAMMA, E. et al. Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a
Objetos. Porto Alegre: Bookman, 2000.
MARTINS, V. M. M. Integração de Sistemas de Informação: Perspectivas, normas e aborda-
gens. Universidade do Minho Guimarães. Dissertação de Mestrado, 218p. 2006. Disponível
em: <repositorium.sdum.uminho.pt/handle/1822/5657>. Acesso em 29 de outubro de 2018.
MIRANDA, R. A. V. et al. IGIS: Um framework para Sistemas de Informações Geográfi-
cas em N-Camadas usando um SGBD objeto-relacional. IV Simpósio Brasileiro de GeoIn-
formática-Caxambú, MG, Brasil, 2002. Disponível em: <www.geoinfo.info/portuguese/
geoinfo2002/papers/Miranda.pdf>. Acesso em: 29 de novembro de 2018.
SILVEIRA, P. et al. Introdução à Arquitetura de Design de Software: Uma Introdução à
Plataforma Java. Elsevier Brasil, 2011.
SOMMERVILLE, I. Arquitetura orientada a serviços. 9 ed. [S.l]: Pearson, 2011.

Arquitetura de software 107


CAPÍTULO 6

Arquitetura móvel
Sidartha Azevedo Lobo de Carvalho

OBJETIVOS DO CAPÍTULO
• Aplicar uma arquitetura móvel, por meio de modelos e exemplos de aplicação para
compreensão das restrições e benefícios.

TÓPICOS DE ESTUDO

1 Modelo de arquitetura 2 Aplicação

• Visão geral. • Exemplo de aplicação.


• Estilo Representational State • Premissas e restrições de uma
Transfer (REST). arquitetura móvel.

Arquitetura de software 109


Contextualizando o cenário

Como o desenvolvimento de software é um ramo da Tecnologia da Informação que vem cres-


cendo continuamente, possuir métodos que aumentem a produtividade e que garantam qua-
lidade é de extrema importância. Um desses métodos é a construção de uma Arquitetura de
Software.

A arquitetura de um software é uma característica importante no momento de modelagem


do sistema. Utilizando a arquitetura, o sistema é definido em termos de elementos e relacio-
namentos entre os elementos, integrando-os para formar o sistema.

Além disso, os dispositivos móveis têm ganhando bastante destaque nos últimos anos, tanto
por conta de sua popularização quanto pelo incremento de funcionalidades e pela inserção
de novas formas de pensar nesses dispositivos, como é o caso da internet das coisas.

Juntando esses conceitos (a Arquitetura de Software e os dispositivos móveis), temos dois


conceitos em destaque atualmente. A partir dos conceitos aprendidos nesse capítulo,
o aluno será capaz de responder à seguinte pergunta norteadora: qual é a importância e
como definir uma arquitetura para um sistema móvel?

110 Arquitetura de software


6.1. Modelo de arquitetura

Um modelo de arquitetura serve para guiar o processo de definição da arquitetura


de um software a partir de algumas premissas, de acordo com o domínio escolhido. Além
disso, o modelo de arquitetura serve para padronizar a estrutura de comunicação entre os
elementos de software.
Fowler (2006) define que a arquitetura de um sistema deve ser guiada por dois objeti-
vos principais: servir de instrumento para a decomposição do sistema, de forma a melhorar
sua representação; e ter uma representação estável, ou seja, a arquitetura deve ser definida
de uma forma que as mudanças sejam mínimas até a finalização da construção do sistema.
Para cada domínio, podemos ter uma ou várias arquiteturas-modelo, cada uma
podendo focar em diferentes aspectos do domínio. Por exemplo, podemos ter um modelo
de arquitetura para manusear redes de internet das coisas (Internet of Things – IoT) e um
outro modelo para redes de sensores sem fio, pois são domínios diferentes.

© KenoKickit / / Shutterstock.

O modelo de arquitetura é definido como um desenho abstrato que relaciona conhe-


cimento e experiências da melhor forma para projetar as entidades (sistemas de software,
aplicativos diversos, dispositivos IoT, dentre outros) em um domínio específico.
Outro conceito, bastante confundido com o modelo de arquitetura, é a arquitetura
de referência. Esse tipo de arquitetura auxilia na interoperabilidade entre diferentes tec-
nologias que utilizam a mesma arquitetura de referência, ou seja, é utilizada como uma
forma de padronização (NAKAGAWA; OQUENDO; MALDONADO, 2014).

Arquitetura de software 111


Podemos diferenciar o modelo de referência da
arquitetura de referência da seguinte forma:
• Modelo de referência: segundo Nakagawa,
Oquendo e Maldonado (2014), é um conceito mais
abstrato, representando um conjunto de entida-
des e relacionamentos dentro de um domínio de
negócio específico. O modelo de referência não

© TechnoVectors / / Shutterstock
apresenta padrões tecnológicos, não é depen-
dente de implementações ou de qualquer detalhe
técnico. Geralmente esses modelos são represen-
tados por desenhos, podendo ser modelos concei-
tuais, ontologias ou taxonomias.
• Arquitetura de referência: de acordo com Nakagawa, Oquendo e Maldonado
(2014), a arquitetura de referência é construída a partir de um ou vários modelos
de referência, unificando as regras, padrões arquiteturais, estilos, boas práticas
de desenvolvimento e definições diversas. Também pode haver uma unificação do
hardware, tornando os seus componentes padronizados para a arquitetura.
Em resumo, podemos concluir que o modelo de referência geralmente é utilizado
para construir uma arquitetura de referência, e uma arquitetura de referência fornece a
estrutura e os elementos a serem utilizados na construção da arquitetura de um sistema
real. A figura a seguir ilustra esses conceitos.
Relacionamentos entre modelos de referência, arquiteturas de referência e arquitetu-
ras concretas

- conceitos
- relacionamentos
- modelo estruturado
(modelo conceitual,
taxonomia, ontologia)
Modelo de
referência é especializada
compôe Arquitetura em Arquitetura
Sistema
de referência concreta
Outros
elementos
é instância de
- regras de negócio
- estilos/padrões
arquiteturais
- decisões arquiteturais
- boas práticas de
desenvolvimento
© DTCOM

- blocos de construção
(hardware/software)

Fonte: PIRES et al., 2015, p. 7.

112 Arquitetura de software


Podemos ver, na figura, que o modelo de referência representa os conceitos e rela-
cionamentos que compõem o modelo. Esse modelo é representado, geralmente, por um
modelo conceitual, taxonomia ou ontologia. A arquitetura de referência utiliza o modelo de
referência como base para a sua construção e também para os demais elementos, que são:
regras de negócio, estilos e padrões arquiteturais, boas práticas de programação e infraes-
trutura de hardware/software.
A arquitetura concreta é a arquitetura real de um sistema, sendo construída a partir
da arquitetura de referência no domínio, ou seja, é a concretização de uma arquitetura de
referência em um domínio específico.
Já o sistema é a entidade de mais baixo nível na nossa representação, sendo que o
seu modelo de referência é o mais abstrato (alto nível). Para construir uma arquitetura de
referência, deve haver um refinamento no modelo de referência para as especificidades do
domínio do negócio.

6.1.1. Visão geral

As arquiteturas móveis devem respeitar diversas restrições que são impostas pelas
entidades que integram a arquitetura móvel. Como exemplo, podemos citar os dispositivos
móveis, que possuem restrições energéticas por dependerem de bateria, e também os ser-
vidores, que devem fornecer uma vazão de rede para atender a todas as requisições.
Para melhor compreender essa questão, é possível considerar a seguinte situação:
para uma determinada demanda, temos os mesmos requisitos técnicos para a formulação
de um sistema, porém, foram produzidas duas arquiteturas distintas. Nesse contexto, é
preciso tentar determinar se uma é melhor que outra. Mas nem sempre isso é possível.
Infelizmente, não há métodos para definir, de forma clara, se uma arquitetura é
melhor que outra. Porém, é possível que determinada arquitetura se encaixe melhor em
um determinado contexto que outra. Um exemplo disso é a arquitetura Cliente-Servidor:
ela pode ser perfeitamente utilizada em um sistema financeiro de uma grande empresa,
porém, não é recomendada para uma aplicação espacial (BASS et al., 2013). A arquitetura
Cliente-Servidor é formada por, pelo menos, um cliente e um servidor, que se comunicam
de forma centralizada, ou seja, o cliente requisita ao servidor algum dado e este responde
seguindo o protocolo definido.
Há algumas sugestões que devem ser seguidas no processo de definição da arquite-
tura. BASS et al. (2013) sugerem algumas regras no momento de construção da arquitetura
de software. No momento de definição da arquitetura, é recomendado que ela seja cons-
truída por um arquiteto ou por um pequeno grupo de arquitetos, que deverá contar com
um líder identificado, o qual responderá pelas decisões da arquitetura.

Arquitetura de software 113


O arquiteto ou a equipe deve ter todos os requisitos funcionais do sistema, além de
uma lista de outros atributos complementares, a qual deve ser obedecida de forma anteci-
pada. Como exemplo disso, podemos citar um sistema que está sendo moldado e que deve
ser seguro e fácil de modificar.
Além disso, a arquitetura deve ser bem
documentada e possuir pelo menos uma visão
estática e uma visão dinâmica, utilizando uma
notação conhecida por todos os envolvidos. A
visão estática representa os cenários que são fixos
a uma determinada arquitetura: por exemplo,
os protocolos de rede a serem utilizados, diagra-
© Jacky Co / / Shutterstock.

mas de casos de uso etc. (se há um ou mais servi-


dores). Por outro lado, a visão dinâmica pode ser
representada pela interação entre as classes de
um sistema orientado a objetos (diagrama UML
de sequência e comunicação). Esses envolvidos devem participar, de forma ativa, da concep-
ção da arquitetura, mas somente o arquiteto ou a equipe de arquitetos pode realizar as modi-
ficações na arquitetura.
Ademais, a arquitetura deve ser avaliada nos requisitos estipulados, aplicando-se
medições quantitativas (por exemplo, vazão de dados), e formalmente avaliada pelos atri-
butos de qualidade. Quanto antes forem identificadas as falhas, menos custoso será para
realizar as correções.
Além disso, a arquitetura desenvolvida deve permitir um melhoramento incremen-
tal pelo uso de um esqueleto da arquitetura, no qual as funcionalidades mais simples são
implementadas. Esse esqueleto da arquitetura pode levar o sistema a crescer de forma
segura, expandindo funcionalidades e melhorando as já desenvolvidas.

Esclarecimento
O esqueleto de uma arquitetura contém os principais componentes, ou seja,
componentes que são comuns à grande maioria das arquiteturas. Esses componentes serão
utilizados para montar a arquitetura final.

Para finalizar as recomendações voltadas ao processo de construção da arquitetura,


é aconselhável que a arquitetura resulte em um conjunto pequeno de recursos e que eles
sejam bem definidos, sendo disseminados, de forma clara, junto à equipe. Por exemplo,

114 Arquitetura de software


se o sistema deve ter uma restrição de tempo, isso deve ser detalhado na arquitetura. Por
outro lado, se a restrição se refere à quantidade de tráfego de dados, isso também deve ser
descrito de forma clara.
Ainda é necessário seguir algumas recomendações em relação à estrutura da arqui-
tetura. A arquitetura deve apresentar módulos bem definidos, sendo que, na criação das
responsabilidades do módulo, deve-se utilizar as boas práticas de separação de responsa-
bilidades entre os módulos. Todo módulo que fizer uso de métodos que estejam encapsula-
dos deve conter as implementações desses métodos utilizados, para evitar dependência de
outras classes ou permitir que o módulo seja inutilizado por possíveis mudanças que alte-
rem os módulos dependentes.

Pausa para Refletir

Como deve ser feita a divisão de responsabilidades para criar os módulos do sistema?

Cada módulo deve conter uma interface bem definida que encapsula ou esconde os
aspectos que podem mudar no módulo. Um exemplo disso são as estratégias de imple-
mentação e estruturas de dados que possam vir a ser utilizadas por outros módulos, cau-
sando dependência.
Por outro lado, a arquitetura deve ser independente de uma versão específica de um
produto comercial ou ferramenta utilizada. Em outras palavras, deve ser genérica e inde-
pendente. Se for inevitável construí-la na dependência de algum produto ou ferramenta,
isso deve ser feito de uma forma que a migração para uma nova versão seja fácil, sem cau-
sar grandes impactos ou custos excessivos.
Ademais, os módulos que consomem dados devem ser separados dos módulos que
geram dados. Essa recomendação é importante porque é comum haver mudanças nos
módulos de geração ou consumo de dados, sendo mais complexo se esses módulos estive-
rem juntos.
Visando à aceleração do processamento para sistemas de processamento paralelo,
é necessário modelar a arquitetura de forma que os módulos não façam uso da estrutura
já conhecida, pois isso permite que eles possam ser “quebrados” posteriormente para
aumentar o processamento. Além disso, essa construção deve ser feita de modo que seja
fácil a migração dessa execução de um processador para outro.
Por fim, a arquitetura deve possuir um número pequeno de simples interações, ou
seja, deve fazer as mesmas rotinas em todos os módulos. Essa prática ajuda a diminuir a
complexidade do sistema, reduzir o tempo de desenvolvimento (reuso de código), aumen-
tar a confiabilidade e reduzir o tempo para realizar mudanças no software.

Arquitetura de software 115


A seguir, falaremos do paradigma Representational State Transfer (REST), usado
amplamente em sistemas baseados na web atualmente. O REST é utilizado principalmente
para fornecer flexibilidade, padronizando os serviços web e recomendando uso de nomen-
clatura e forma estrutural comum. Essa padronização é útil para que novos serviços/usuá-
rios possam utilizar os serviços que implementam o REST de forma facilitada.

6.1.2. Estilo Representational State Transfer (REST)

Para entender o conceito de Representational State Transfer (REST), é preciso conhe-


cer, primeiro, o Simple Object Access Protocol (SOAP). O SOAP é um protocolo mais antigo
que a abordagem REST, sendo proposto pela Microsoft. O SOAP também é um protocolo
mais rígido que o REST, impondo regras na troca de mensagens.
Porém, também há pontos em comum entre eles: tanto SOAP quanto o REST utili-
zam o protocolo HTTP na camada mais baixa. Além disso, ambos são abordagens que defi-
nem como se deve acessar serviços na web, estabelecendo regras de nomenclatura para
acessar e fornecer serviços.

Dica
Cuidado para não confundir SOAP com Arquitetura Orientada a Serviços (SOA)
(ERL, 2009), pois são conceitos distintos. SOA é um paradigma, e SOAP é um protocolo.

Continuando as comparações entre SOAP e REST, como o SOAP não define lingua-
gem, restrições ao uso podem ocorrer em decorrência da linguagem utilizada. Uma das
características mais importantes do SOAP é uma abordagem para o tratamento de erros.
Se houver um problema com a requisição, a resposta contém informações do erro ocorrido
que podem ajudar a consertar o problema.
Além disso, no SOAP há uma padronização de códigos de erros por meio da qual é
possível automatizar o tratamento dos erros no código. Outra característica importante
é que SOAP não é obrigada a usar HTTP, também podendo ser expandida para utilização
sobre o SMTP. Ainda é possível utilizar outras linguagens, como Python e PHP.
Em contrapartida, REST provê uma alternativa leve: em vez de usar um arquivo XML
para fazer uma requisição (como acontece no SOAP), é utilizada somente uma URL em
muitos casos. É importante saber, também, que o REST pode usar verbos HTTP 1.1 (GET,
POST, PUT e DELETE) para executar tarefas.

116 Arquitetura de software


Ademais, desde que o REST use o padrão HTTP, é mais simples que quase todas as
abordagens.

Curiosidade
O termo REST foi proposto por Roy Fielding no ano 2000, em sua tese de dou-
torado, com o título Architectural Styles and the Design of Network-based Software Archi-
tectures, apresentada na universidade da Califórnia, Irvine, USA (FIELDING, 2000).

O REST permite o suporte a vários formatos de dados, enquanto o SOAP suporta ape-
nas o XML. Essa abrangência do REST pode incorporar mais complexidade, mas quase não é
perceptível o esforço para implementar outros formatos de dados. Além disso, o formato de
dados JavaScript Object Notation (JSON) geralmente é uma escolha inteligente para enviar
dados, dando vantagem ao REST por possuir, de forma facilitada, suporte ao JSON.

Pausa para Refletir

Em qual momento da definição da arquitetura devemos decidir se vamos construir um ser-


viço RESTful?

Em resumo, a abordagem SOAP é útil e importante para determinado cenários.


Porém, há cenários (mais comuns ao desenvolvedor padrão) nos quais o REST é mais indi-
cado. O protocolo SOAP é mais indicado quando se necessita, por exemplo, de uma segu-
rança a mais na comunicação (desenvolvimento de um aplicativo para acessar o banco de
forma on-line). Se, ao acessar o aplicativo do banco, não houver segurança nessa comuni-
cação, poderá haver um problema gigantesco para o cliente e para o banco.
Mas também há vantagens. Uma das grandes vantagens das arquiteturas móveis
é permitir a troca de informações de forma facilitada, tanto entre os dispositivos móveis
quanto entre os dispositivos móveis e os servidores de dados. Um exemplo disso é o apli-
cativo de troca de mensagens Whatsapp. É provável que ele utilize a abordagem REST,
pois é possível enviar uma mensagem somente utilizando uma URL (exemplo: < api.what-
sapp.com/send?phone=5581911112222>. Nessa URL, os números após o atributo phone
representam o número de telefone que irá receber a mensagem: primeiramente, o código
do país (55 - Brasil); depois, o código de área (81 - Recife); e, por fim, o número do tele-
fone). Essa URL pode ser acessada tanto de um dispositivo móvel quanto de um computa-
dor desktop ou de qualquer outro dispositivo que implemente o protocolo HTTP. Esse uso,
comum a diversos dispositivos, permite uma grande interoperabilidade entre os dispositi-
vos conectados na rede, permitindo uma comunicação rica.

Arquitetura de software 117


O serviço que implementa o REST deve apresentar uma API cujos serviços sejam
facilmente identificados, para os serviços serem descobertos de forma automática ou faci-
litada. Além disso, como não temos estados na comunicação, é possível aumentar o sis-
tema replicando repositórios.
Por exemplo, um serviço que não possui estado não retém dados da sessão de comu-
nicação, ou seja, cada requisição é individual, tendo como vantagem não depender das
requisições anteriores. Porém, uma das desvantagens do REST é ter que utilizar requisi-
ções GET ou POST (do HTTP), o que pode levar a um trabalho maior na implementação.
A internet é um dos meios mais importantes que fazem uso do protocolo HTTP,
sendo também a arquitetura Cliente-Servidor uma das mais utilizadas pelas mais diver-
sas aplicações. Diante disso, a seguir, temos um sistema que faz uso do paradigma REST,
JSON, HTTP e da arquitetura Cliente-Servidor.

[{”cidade”:”Recife”,”unidade”:”Celsius”}]
Sistema Requisita ao Cliente

/servidor/tempo Responde ao HTTP POST

© DTCOM
[{”cidade”:”Recife”,”unidade”:”Celsius”}]

Podemos ver, nessa figura, que há dois blocos distintos: o cliente e o servidor, que
retratam o uso da arquitetura Cliente-Servidor. O método utilizado para enviar e receber as
requisições é o HTTP, protocolo de mais baixo nível. As mensagens de dados são enviadas
por meio do JSON, em que temos primeiro o atributo (cidade ou unidade), e, depois dos
dois-pontos, o valor desse atributo: Recife e Celsius.

Dica
O método HTTP possui mais métodos do que os abordados aqui. porém, os que
foram abordados são os mais importantes e utilizados. Os métodos que compõem o HTTP
são: GET, POST, PUT, DELETE, TRACE, OPTIONS, PATCH, CONNECT e HEAD.

Todo esse conjunto caracteriza o paradigma REST, no qual temos: operações bem
definidas (métodos GET, POST e PUT do HTTP); sintaxe única para representar atributos
e valores (URL); a transferência de dados feita de forma padronizada e de domínio público
(XML, HTML, JSON etc.).

118 Arquitetura de software


Quanto ao protocolo usado para a padronização da comunicação, o REST, é comum
ouvir falar em RESTful. De forma simplificada, o REST é um paradigma arquitetural, enquanto
o RESTful é uma característica de um serviço que implementa as recomendações REST.
O quadro a seguir representa uma descrição dos serviços oferecidos por nosso sistema.

Serviço RESTful

Método URL Descrição do serviço

Listagem de todas as cidades que pos-


GET <localhost:80/servidor/tempo> suem a previsão do tempo disponíveis no
servidor.

Leitura dos atributos de temperatura


GET <localhost:80/servidor/tempo/recife> mínima e máxima para a cidade infor-
mada após o /tempo/.

Inserção de um novo atributo para a


POST <localhost:80/servidor/tempo/recife>
cidade informada após o /tempo/.

Atualização dos valores dos atributos


PUT <localhost:80/servidor/tempo/recife>
para a cidade informada após o /tempo/.

Remove a cidade cadastrada e todos os


<localhost:80/servidor/tempo/
DELETE seus atributos para a cidade informada
fortaleza>
após o /tempo/.

Com base nesse quadro, podemos dizer que o REST é muito importante. Além disso,
uma descrição bem detalhada e uma API fácil de ser utilizada são essenciais para a produção
de um software de qualidade, com baixo custo de manutenção e grande poder de expansão.

6.2. Aplicação

Agora descreveremos, de forma simplificada, a modela-


gem de um sistema baseado na web que utiliza a arquitetura
Cliente-Servidor n-tier (n-camadas) para modelar o servidor.
Além disso, iremos descrever os tipos de clientes que podem
ser implementados para funcionar com essa arquitetura.
© Jacky Co / / Shutterstock.

Primeiramente, iremos descrever um exemplo de apli-


cação com foco em sistemas móveis e, depois, vamos falar
das premissas e restrições de uma arquitetura móvel no con-
texto atual.

Arquitetura de software 119


6.2.1. Exemplo de aplicação

Uma arquitetura n-tier é representada pela divisão de n camadas para conter a imple-
mentação do sistema. Se tivermos uma arquitetura 1-tier, temos uma única camada, que
irá conter as três principais vertentes de uma aplicação: software do servidor, regras de
negócio e banco de dados (FOWLER, 2006). A arquitetura n-tier é ilustrada a seguir.

Arquitetura n-tier

Camada 1

Camada 2

© DTCOM
Camada n

Em uma abordagem 2-tier, temos o banco de dados hospedado em outro servidor


(independentemente do que armazena a aplicação), juntamente com as regras de negócio.
Se a abordagem for 3-tier, cada vertente deverá ficar em um servidor distinto. Esses con-
ceitos são representados na figura a seguir.

Implementação da arquitetura 3-tier

Servidor do
BD aplicativo

Servidor das regras


do negócio

Servidor de dados

BD BD BD
© DTCOM

120 Arquitetura de software


Na última figura, podemos ver um exemplo da representação de uma arquitetura
baseada em Cliente-Servidor 3-tier. Temos o dispositivo móvel, ilustrado por um smart-
phone que possui um banco de dados próprio. Esse cliente se comunica com o servidor do
aplicativo, enviando e recebendo dados. O servidor do aplicativo pode consultar a camada
do servidor das regras de negócio se for preciso, sendo que o servidor das regras do negó-
cio pode fazer uso do servidor de dados. É importante saber ainda que o servidor de dados
possui vários bancos de dados que podem armazenar categorias de dados distintas.
Essa arquitetura permite a escalabilidade, ou seja, podemos adicionar um balancea-
dor de carga no servidor do aplicativo e replicar esse servidor em diversas outras máquinas.
O balanceador de carga, então, vai enviando as requisições para o servidor que estiver mais
ocioso.
Do lado do cliente, também podemos ter diversas arquiteturas distintas: thin clients
(clientes magros); fat clients (clientes gordos) e a hospedagem total no cliente. Os clientes
magros não possuem código específico para executar o aplicativo, pois eles simplesmente
são feitos para mostrar, ao usuário, os resultados do processamento no servidor. Esse
tipo de cliente possui uma grande vantagem: são independentes de sistema operacional
e muito leves, característica importantíssima nos dispositivos móveis. Geralmente os
clientes magros são acessados por meio da utilização da web, seja por meio de um browser
nativo ou por um aplicativo que lê os dados do HTTP, por exemplo, e os mostra na tela.
Já os clientes gordos podem possuir de uma até três camadas. Esse tipo de cliente
é útil quando não se tem acesso irrestrito à rede de dados ou quando não há garantia de
uma comunicação permanente com o servidor. Além disso, esse tipo de cliente armazena
os dados, de forma local, até que haja possibilidade de enviá-los ao servidor.
Dessa forma, escolher a arquitetura correta para um determinado cliente é uma
importante decisão, pois, se houver equívocos, isso pode levar o sistema ao fracasso. Por
exemplo, se instalarmos um cliente gordo em um smartphone que carece de recursos de
processamento e memória, provavelmente ele irá apresentar travamentos e execução
errada do software, levando o usuário à frustração.
Do mesmo modo, se modelarmos de forma errada o lado do servidor, colocando uma
infraestrutura simplória e exigindo que sejam feitas milhões de requisições, teremos uma
disponibilidade baixa desse servidor, com alto índice de rejeição de requisições. Assim, é
preciso analisar bem as premissas e restrições das arquiteturas móveis.

Arquitetura de software 121


6.2.2. Premissas e restrições de uma arquitetura móvel

A construção da arquitetura de um sistema deve levar em consideração os compo-


nentes que a integram, além da utilização do sistema. Quando falamos em arquitetura
móvel, lembramo-nos dos dispositivos móveis, dentre eles os smartphones, sensores sem
fio, internet das coisas, dentre outros dispositivos que possuem mobilidade.
Os dispositivos móveis, entretanto, possuem algumas restrições devido a sua natu-
reza, pois são dispositivos dependentes de bateria – por isso, deve-se gerenciar o consumo
energético, de forma a prolongar ao máximo o tempo de uso da bateria, mas sem afetar
consideravelmente o desempenho do dispositivo. Se o desempenho for comprometido, o
dispositivo pode começar a travar, não executar os aplicativos de forma correta, reiniciar,
dentre outras anomalias.
Além disso, os dispositivos móveis também possuem restrição de processamento,
memória de processamento, armazenamento e outras desvantagens. Como exemplo de
algumas dessas restrições, podemos citar os processamentos decorrentes da energia limi-
tada e dos componentes que são utilizados no seu hardware para manter um dispositivo
pequeno e móvel.
Consideradas essas restrições, é necessário que a arquitetura que envolve esses dis-
positivos, ou seja, as arquiteturas móveis, levem em consideração essas restrições. Além
disso, os sistemas devem ser projetados de forma que seja facilitada a manutenção e evo-
lução. A abordagem utilizando serviços é uma boa solução por seu baixo acoplamento entre
os componentes e pela independência de hardware específico.
Também é preciso considerar que os sistemas projetados por meio da utilização das
arquiteturas móveis não devem estabelecer relações que façam uso intensivo de transfe-
rência de dados utilizando a rede (tanto as redes locais quanto as redes móveis). A trans-
ferência de dados é um dos principais consumidores de bateria dos smartphones, sendo
comparável ao uso intensivo do processador e ao brilho da tela. Além disso, o uso de sen-
sores e funcionalidades do smartphone (como GPS, bluetooth, wi-fi, redes móveis etc.) deve
ser gerenciado com cautela.
Por fim, vale relembrar que uma arquitetura que faça uso de clientes magros é mais
indicada para uma aplicação que será executada em um dispositivo móvel. Além disso, essa
aplicação deve fazer uso de mensagens pequenas devido às restrições energéticas e de
tarifação das redes móveis do dispositivo.

122 Arquitetura de software


Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa,
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.

Agora é a hora de recapitular tudo o que você aprendeu nesse capítulo! Descreva uma arqui-
tetura simples que envolva um sistema móvel, um servidor e alguns serviços. Ao descrever
a arquitetura, siga todos os princípios que vimos neste capítulo. Além disso, aplique todo o
conhecimento adquirido nos capítulos da disciplina e considere as leituras básicas e comple-
mentares realizadas para ampliar seu conhecimento.

Recapitulando

Ao longo do capítulo, vimos que a etapa de definição da arquitetura de um sistema é


primordial para o processo de desenvolvimento e muito importante para garantir os requi-
sitos não funcionais a um sistema. A arquitetura ainda permite definir com clareza os ele-
mentos que irão compor o sistema, bem como seus relacionamentos. Como nosso foco
esteve em arquiteturas para sistemas móveis, vimos alguns exemplos para firmar os con-
ceitos estudados.
Além disso, estudados alguns conceitos que auxiliam na divisão dos componentes do
sistema para gerar módulos, vimos que esse não é um processo determinístico. Há diver-
sas características que podem afetar essa agregação, porém, seguindo algumas recomen-
dações, é possível criar módulos com baixo acoplamento entre os serviços ofertados.
Por fim, vimos o paradigma REST, que impõe regras que devem ser seguidas para
garantir a qualidade do software produzido, permitindo baixa manutenibilidade, facilidade
de uso e descoberta de serviços facilitada. No momento da definição da arquitetura, deve
ser definido se os serviços criados irão seguir o paradigma REST, o padrão SOAP ou outros,
dependendo da aplicação do software e dos seus requisitos.

Arquitetura de software 123


Referências

BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. 3. ed. Upper
Saddle River: Addison-Wesley, 2013.
ERL, T. SOA design patterns. Boston: Prentice Hall, 2009.
FIELDING, R. T. Architectural Styles and the Design of Network-based Software Archi-
tectures. 2000. Disponível em: <www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dis-
sertation.pdf>. Acesso em: 24 out. 2018.
FOWLER, M. Padrões de arquitetura de aplicações corporativas. Porto Alegre: Bookman,
2006.
NAKAGAWA, E. Y.; OQUENDO, F.; MALDONADO, J. C. Reference architectures. Software
Architecture 1. United Kingdom, ISTE Ltd / John Wiley & Sons, Inc., pp. 55-82, 2014.
PIRES, P. F.; DELICATO, F. C.; BATISTA, T.; BARROS, T., CAVALCANTE, E.; PITANGA, M.
Plataformas para a Internet das Coisas. Minicursos SBRC-Simpósio Brasileiro de Redes
de Computadores e Sistemas Distribuídos. 2015. Disponível em: < sbrc2015.ufes.br/
wp-content/uploads/Ch3.pdf>. Acesso em: 14/08/2017.

124 Arquitetura de software


CAPÍTULO 7

Arquitetura de aplicações ricas (RIA)


Jeanfrank Teodoro Dantas Sartori

OBJETIVOS DO CAPÍTULO
• Aplicar uma arquitetura de aplicação rica, compreendendo as restrições e benefí-
cios através de modelos e exemplos de aplicação.

TÓPICOS DE ESTUDO

1 Visão geral 3 Aplicação

• Benefícios. • Utilização de Java Script.


• Deficiências e restrições. • Utilização de Angular JS.
• Dificuldades de gerenciamento.

2 Tecnologia

• Chamada assíncrona.
• Tecnologias de apresentação.
• Interfaces Web Mobile responsivas.

Arquitetura de software 125


Contextualizando o cenário

A figura a seguir ilustra uma das primeiras versões de mapas online. Apesar de, em linhas
gerais, ela apresentar algumas das funcionalidades que permanecem até hoje, há uma
grande diferença com relação às interfaces de mapas das quais estamos acostumados.

Fonte: Library of the United States Congress, 2005

Observe que, no entorno do mapa, há botões indicando as direções em formato de setas direcio-
nais. Nesse tipo de interface, ao clicar nessas setas para escolher uma direção, a página era recar-
regada com um novo mapa da área selecionada. Portanto, era bem diferente dos mapas online
dos quais estamos habituados, em que podemos simplesmente arrastar o mouse, ou nossos
dedos pelo touchpad, e deslocar para qualquer direção sem que a página precise ser recarregada.

No entanto, a partir dos anos 2000, as aplicações web de navegação começaram a oferecer
inúmeros recursos e funcionalidades sem que fosse preciso sair da aplicação ou recarregar a
página. Nesse sentido, a interface passou a ser amigável e interativa - progresso alcançado
através dos avanços tecnológicos.

Esses recursos e funcionalidades foram agrupados no conceito de Internet Rica (RIA, Rich
Internet Applications, em inglês), e estudá-lo é importante, pois trata-se de uma forma muito
mais rica e interativa de disponibilizar conteúdos para os usuários.

Dito isso, cabe a pergunta: como funciona uma aplicação rica e como ela pode tornar a
interação dos usuários mais atrativa e amigável?

126 Arquitetura de software


7.1. Visão geral

A disponibilidade e a popularidade de aplicativos executados na web cresceu expo-


nencialmente desde seu surgimento. Partindo de páginas com simples conteúdos em texto
e poucas imagens - predominantes na década de 1980 e no início dos anos 1990 - viu-se o
crescimento gradativo das aplicações web.
Já a partir dos anos 2000, houve um
significativo incremento na qualidade e
na interatividade das interfaces dos apli-

© Kheng Guan Toh / / Shutterstock (adaptado).


cativos. Parte dessa evolução aconte-
ceu pelo desenvolvimento das aplicações
ricas (RIA), que permitiu que funções - até
então acessíveis apenas aos softwares ins-
talados diretamente em um computador
– fossem executas diretamente em um
navegador web, sem instalação.
A rápida expansão das aplicações ricas se justifica pelos inúmeros benefícios que ela
oferece. Assim, estudaremos alguns deles a seguir, acompanhe!

7.1.1. Benefícios

Pode parecer natural uma página web acessar conteúdo em um banco de dados, efetuar
processamentos complexos ou, até mesmo, exibir gráficos 3D avançados, mas nem sempre foi
assim. A linguagem HTML, por exemplo, que era amplamente utilizada antes das aplicações
ricas, oferecia – e ainda oferece – poucos recursos nesse sentido (PINA e OLIVEIRA, 2013).
As funcionalidades introduzidas pelo conceito
de RIA, então, trouxeram diversos benefícios para as
aplicações web. Primeiramente, como o próprio nome
sugere, as aplicações se tornaram mais ricas, possi-
bilitando recursos de interação - como manipulações
feitas com mouse ou com touchpad -, além um visual
mais amigável e intuitivo. Ademais, a capacidade de
© Olibaba / / Shutterstock..

realizar diversas operações diretamente no navegador


do usuário, sem a necessidade de enviar requisições
para os servidores web, foi outra melhoria alcançada
através das aplicações ricas (PINA e OLIVEIRA, 2013).

Arquitetura de software 127


Outro benefício é uma melhor resposta aos comandos. Isto porque as funcionalida-
des já estão na página do navegador, apresentando um comportamento muito semelhante
a um aplicativo instalado no computador. Você pode perceber isso ao observar que mui-
tas interações que você faz em páginas de e-mail ou de mapas, por exemplo, possuem uma
resposta imediata.
Em tempos de amplo acesso global à internet, outro benefício importante é uma
melhor distribuição entre os processamentos realizados localmente e aqueles que ficam à
cargo dos servidores web. Se tudo fosse processado somente pelos servidores, certamente
teríamos um volume muito maior de tráfego de rede, além da necessidade de uma estru-
tura muito maior de processamento. Isso poderia tornar inviável a existência de algumas
aplicações disponíveis. Mas, como as aplicações RIA conseguem realizar inúmeros proces-
samentos de forma local - no dispositivo do usuário - há um melhor equilíbrio em relação
ao volume de processamentos efetuados nos servidores.
Adicionalmente, através das aplicações ricas, temos navegação e interação mais flui-
das e menos cadenciadas, uma vez que não é necessário um novo processamento e nem
uma nova requisição ao servidor à cada nova interação. Além disso, é comum que essas
aplicações carreguem conteúdos relacionados ao que está sendo exibido de forma anteci-
pada, o que permite serem acionados e visualizados de forma mais imediata pelo usuário,
como ocorre nos mapas.
Dito isso, observe o quadro a seguir que ilustra os principais benefícios do RIA:

Principais Benefícios das Aplicações Ricas

Interfaces mais ricas e intuitivas

Melhor resposta aos comandos dos usuários

Processamento local, menor tráfego e menos processamento nos servidores

Navegação e interação mais fluidas

Capacidade de carregamento de conteúdos relacionados de forma antecipada

No entanto, as aplicações ricas também apresentam algumas limitações, das quais


passaremos a estudar a seguir.

128 Arquitetura de software


7.1.2. Deficiências e restrições

As deficiências e restrições são mais facilmente compreendidas quando se compara


as aplicações ricas da web com softwares efetivamente instalados em um computador.
Nesse âmbito, o RIA, por exemplo, tem acesso limitado e restrito aos recursos do sistema
local, o que impede alguns tipos de funcionalidades acessíveis apenas por aplicações insta-
ladas no equipamento. Isso pode ser ainda mais restritivo em alguns navegadores, ou con-
forme as configurações personalizadas do usuário. Um exemplo prático seria a eventual
necessidade de acesso a arquivos ou pastas locais, que seria nativo para um programa ins-
talado no computador, mas que é restringido para aplicações web - exceto via download e
upload individuais e intermediados pelo próprio usuário, o que inviabiliza diversas funciona-
lidades. (PINA e OLIVEIRA, 2013; NODA e HEWIG, 2005).

© Akira Kaelyn / / Shutterstock.

Outra limitação das aplicações ricas são que suas tecnologias de sustentação, como
Javascript ou Flash Player, podem estar desabilitadas no navegador do cliente, o que signi-
fica que não poderão ser executadas. Aplicações desenvolvidas utilizando esse recurso, na
maioria dos casos, seriam complexas ou inviáveis de serem oferecidas em uma versão equi-
valente utilizando apenas os recursos nativos do HTML.

Arquitetura de software 129


Apesar de menos frequente, tendo em vista o avanço da velocidade das conexões
(inclusive móveis) e da capacidade de armazenamento e processamento, o tempo de car-
regamento local das aplicações ricas também pode corresponder à uma restrição, que é o
caso de uma conexão lenta. Essa lentidão pode acontecer porque é necessário que todos
os scripts e conteúdos envolvidos sejam trazidos para o dispositivo do usuário antes da
sua execução, envolvendo transferência de dados, cache e processamento. Nesse sentido,
como, cada vez mais, os usuários não estão dispostos a esperar para obter uma resposta de
uma funcionalidade da aplicação, essa lentidão pode representar uma grande limitação.
Outra restrição pode se dar quando uma aplicação rica é manipulada ao ser execu-
tada por um cliente com conhecimentos mais avançados de informática. Assim, um script
carregado no dispositivo desse usuário pode, com maior ou menor dificuldade, ser mani-
pulado e causar falhas ou comportamentos indesejados tanto no sistema do usuário como
na aplicação como um todo. Isso pode ser feito com o objetivo simples de ter um melhor
desempenho em um jogo, porém pode ser muito grave quando afeta o comportamento no
próprio servidor, como no caso em que a aplicação acessa ou fornece dados. Essa manipu-
lação, portanto, pode se tornar uma questão de segurança de extrema relevância.

Esclarecimento
O equilíbrio entre segurança e usabilidade no contexto de aplicações ricas pode
ser desafiador. Uma maior segurança restringe funcionalidades ou até desabilita as tecnolo-
gias de sustentação. Mas, por outro lado, menor segurança aumenta os riscos de uso inde-
vido e ações criminosas (MOHAMMAD e OORSCHOT, 2007).

Além disso, os conteúdos executados em uma RIA podem ser mais difíceis de serem
mapeados por sites de busca, dificultando a capacidade da aplicação ser descoberta e loca-
lizada por novos usuários. Isso acontece pelo fato de o conteúdo da aplicação não estar
somente nos códigos, sendo dependente, portanto, da execução humana para fazer sentido.
Isso dificulta a busca de conteúdo web feita pelos bots (códigos-robôs) de rastreamento.
Por fim, a necessidade de manter-se conectado à web para que a aplicação funcione
ou para que se mantenha atualizada pode ser considerada outra restrição. Todavia, essa
questão tem cada vez menor relevância, tendo em vista a expansão cada vez maior da dis-
ponibilidade da internet, inclusive móvel.

130 Arquitetura de software


Principais Restrições das Aplicações Ricas

Acesso limitado à recursos locais do dispositivo

Configurações restritivas ou desabilitadas que podem impedir o funcionamento

Conexões lentas que podem causar lentidão na resposta ao usuário

Riscos de segurança e de manipulação dos códigos carregados no cliente

Menor visibilidade em buscadores

Dependência da conexão à internet

Além dessas questões, há fatores de gerenciamento que também geram dificuldades


no desenvolvimento de aplicações ricas. Trataremos dessas restrições a seguir, acompanhe!

Pausa para refletir

Você consegue imaginar alguma outra dificuldade ou restrição prática das aplicações ricas?

7.1.3. Dificuldades de gerenciamento

No contexto de aplicações ricas, as preocupações se voltam para os navegadores e


para os eventuais plug-ins que são requeridos para o funcionamento adequado da aplicação.
Nesse sentido, a questão mais relevante em
termos da dificuldade de gerenciamento é do con-
trole de versões. Isto porque, por de ser dependente
de plug-ins, a versão executada no navegador do
© Gorodenkoff / / Shutterstock.

cliente pode afetar o funcionamento da aplicação.


Apesar dos fornecedores se empenharem para man-
ter os usuários com a versão mais atual do plugin, a
instalação dessas atualizações depende da autoriza-
ção do usuário (NODA e HEWIG, 2005).
Desse modo, é necessário lidar com cenários de diferentes versões de plugin e garan-
tir que a aplicação funcione em todas elas, ou pelo menos nas mais recentes e com maior
taxa de utilização, uma vez que inviável exigir que todos os clientes possuam a versão mais
recente (NODA e HEWIG, 2005).

Arquitetura de software 131


É difícil garantir que um usuário esteja, efetivamente, utilizando a versão mais atual
dos códigos da aplicação. Primeiramente, porque a aplicação pode ser manipulada - con-
forme abordamos anteriormente - e também porque os scripts podem ser, em boa parte
dos casos, copiados para um armazenamento local do usuário. Mas, isso pode acarretar em
questões de segurança relevantes, tanto para usuário quanto para a empresa que sustenta
a aplicação. Isto porque uma falha corrigida em uma versão mais recente do aplicativo, por
exemplo, continuará presente para aqueles que permaneçam utilizando versões anteriores.
Além disso, erros na execução de funções podem acontecer pois, campos de uma tabela,
por exemplo, podem ter sido modificados ou até excluídos, endereços de dados ou páginas
podem não mais existir, assim como diversas outras falhas.
Conhecidas as definições gerais das aplicações ricas, juntamente com seus benefícios
e restrições, vamos, a seguir, conhecer as tecnologias que possibilitam implementação des-
sas aplicações.

7.2. Tecnologia

Diretamente ligada aos benefícios de RIA, temos a tecnologia que a torna possível.
São, na essência, essas funcionalidades tecnológicas que dão sustentação a tudo o que
torna as aplicações RIA o que são: ricas.
Assim, estudaremos a seguir algumas dessas questões e como elas contribuem para
que o desenvolvedor possa construir aplicações úteis, agradáveis e interativas, atendendo
às necessidades e anseios dos usuários.

7.2.1. Chamada assíncrona

Assíncrona, segundo o dicionário Aurélio (Ferreira, 2009), traz a ideia daquilo que não
ocorre simultaneamente, ou seja, algo que não é sincronizado. Mas como isso se relaciona
com aplicações ricas?
Nas aplicações ricas, as chamadas assíncronas correspondem a um comando que
não precisa ser processado pelo servidor para que o usuário possa continuar a navegação.
Isso ocorre por ser possível enviar uma solicitação ao servidor e fazer outras atividades
enquanto a requisição é executada.

132 Arquitetura de software


© TechnoVectors / / Shutterstock (adaptado).
Para exemplificar esse assincronismo, imagine o uso de um armazenamento em nuvem
(como Google Drive, OneDrive ou DropBox). Neste contexto, você deseja fazer o upload (car-
regamento) de um conjunto de novos arquivos. Ao selecioná-los e solicitar o envio, a apli-
cação (que é rica) não exige que você pare o que está fazendo enquanto os arquivos estão
sendo carregados. Desse modo, você pode realizar outras atividades sem que essa solicita-
ção interfira na transferência de dados, uma vez que ela está sendo feita em segundo plano.
Essa capacidade enriquece a experiência do usuário, uma vez que permite a reali-
zação de diferentes atividades simultaneamente. Além disso, ela torna a aplicação mais
rápida e interativa, sem os tempos de espera que hoje em dia são cada vez menos tolera-
dos pelos usuários.
Ademais, toda aplicação rica tem um outro fundamento igualmente importante: a
forma com que sua interface é disponibilizada aos usuários. É sobre isso que estudaremos
juntos a seguir, acompanhe!

Arquitetura de software 133


7.2.2. Tecnologias de apresentação

As tecnologias de apresentação correspondem à forma como os dados e funcionali-


dades são exibidas para os usuários. Na perspectiva MVC (Model, View, Controller - Modelo,
Vista e Controlador, em português) - um dos padrões de arquitetura de software - essas tec-
nologias correspondem às vistas. As vistas são as diferentes formas que um modelo (dados)
pode ser disponibilizado para o usuário, conforme ilustra a figura a seguir (GAMMA, 2000):

Vistas

a b c
b
x 60 30 10
y 50 30 20 a
c
z 80 10 10
a b c

a = 50%
b = 30%
c = 20%

© DTCOM
modelo

Fonte: Adaptado de Gamma, 2000, p.21

As aplicações ricas, nesse sentido, são responsáveis por garantir maior interatividade
à essas tecnologias. Isto porque o conteúdo exibido não é somente um elemento gráfico,
sendo somados a ele funções de navegação e de execução de comandos, o que fornecendo
uma grande gama de funções e recursos ao usuário.
Para ilustrar essa interatividade, podemos voltar aos mapas online. É possível deslocar o
mapa e alterar o zoom, por exemplo, utilizando o próprio conteúdo exibido (mapa) para realizar
essa interação, sem a necessidade de carregar uma nova página, como ocorria antigamente.
Além disso, o contexto de aplicações ricas produziu um conjunto cada vez mais avan-
çado de elementos gráficos, como objetos vetoriais em duas ou três dimensões. Desse
modo, permitiu-se a inserção de imagens, inclusive sobre a forma de texturas de conteú-
dos vetoriais, abrindo um leque enorme de possibilidades de uso, inclusive em jogos online.
Esse conjunto avançado de elementos gráficos também pode ser observado nos mapas
online. Observe o mapa a seguir que ilustra a Praça dos Três Poderes, em Brasília (DF):

134 Arquitetura de software


Note que as vias, que normalmente
são representadas como elementos grá-
ficos em duas dimensões (2D), também

Imagens ©2018 CNES / Airbus, DigitalGlobe.


podem ser visualizadas em três (3D) atra-
vés de imagens de satélite, como ilustra
a figura anterior. Esse tipo de represen-
tação seria impossível de ser disponibili-
zada em um navegador fora do contexto
de aplicações ricas.
Mas não é somente na tela de um computador que podemos visualizar e utilizar RIA.
Veremos a seguir um pouco de sua aplicação em dispositivos móveis.

7.2.3. Interfaces Web Mobile responsivas

O desenvolvimento de conteúdo web tem sido intensamente influenciado pela grande


expansão de dispositivos móveis e pela conexão de dados feita por operadoras de telefo-
nia. Assim, boa parte do desenvolvimento para a internet tem focado nos usuários por meio
desses tipos de acessos, e com as aplicações ricas não foi diferente (NODA e HEWIG, 2005).
Nesse sentido, tem-se o conceito de responsividade, que corresponde a capacidade
de adaptar o conteúdo em função do tipo de dispositivo que o acesso é feito. Esse conceito
é facilmente percebido quando se entra em uma página a partir de um celular, por exem-
plo, e ela apresenta letras pequenas, obrigando o usuário a dar zoom para poder enfrentar
dificuldades de navegação. Trata-se, neste caso, de uma página não-responsiva ou clássica.

Esclarecimento
A responsividade consiste na utilização de um conjunto de recursos que permite
que a página se reformate sozinha. Ou seja, ela foca na mudança visual das páginas man-
tendo as mesmas informações, ao invés de produzir páginas específicas para cada tipo de
dispositivo (Leiva, 2018).

Já um site de banco, por exemplo, costuma ser responsivo, ou seja, ao acessar o


mesmo endereço, mas a partir de dispositivos diferentes, tem-se a visualização mais ade-
quada para cada contexto.

Arquitetura de software 135


Essa responsividade não é automática e depende, em maior ou menor grau, que a
equipe de desenvolvimento configure e programe adequadamente as questões envolvi-
das, como adaptações no layout e formatação do conteúdo de forma a ser apresentado em
diferentes tamanhos. Por isso, muitas vezes, essa configuração corresponde a uma versão
distinta e melhor adequada para cada uma das formas de utilização.
Após estudar as diferentes tecnologias utilizas nas aplicações ricas, a seguir, observe
o quadro que as compara com as tecnologias utilizadas em aplicações web ditas clássicas:

Aplicações Web Clássicas Aplicações Web Ricas

Chamada Sincronizada: o próximo passo só Chamada Assíncrona: o usuário pode realizar


pode ser iniciado após a resposta da primeira outras ações enquanto aguarda um retorno
solicitação. da aplicação.

Apresentações simples, pobres, com pouca


Apresentação rica e complexa.
qualidade visual e reduzida interação

Interfaces padronizadas, independentemente Interfaces Responsivas que se adequam aos


do dispositivo. diferentes dispositivos.

Pausa para refletir

Para criarmos interfaces responsivas, você consegue imaginar uma linguagem de programa-
ção que possa ser adotada em conjunto com o HTML no contexto de desenvolvimento de
aplicações ricas?

Mas como um RIA pode ser efetivamente adotada e implantada? É isso que veremos,
em linhas gerais, a seguir. Acompanhe!

7.3. Aplicação

Criar uma aplicação rica para a web requer, necessariamente, a adoção de uma plataforma
sobre a qual ela será construída. Essa é uma decisão importante, uma vez que a escolha da
plataforma impacta na continuidade e a longevidade de seu RIA.
Nesse sentido, podemos citar o Adobe Flash Player como exemplo de plataforma, que foi extre-
mamente popular nos anos 90 e 2000, tendo contribuído muito para a melhoria da interação e
do uso de recursos gráficos em aplicações ricas. Apesar dessa história de sucesso, o Adobe Flash
está com seus dias contatos, com previsão de ser definitivamente descontinuado até 2030. A
razão disso está nas inúmeras falhas de segurança e vulnerabilidades que a plataforma oferece.

136 Arquitetura de software


Pode-se dizer que adotar uma plataforma amplamente utilizada e validada é uma peça fun-
damental e, dentre as opções disponíveis, o Java Script é uma das mais recomendáveis,
uma vez que apresenta menor risco (porém, não ausente) de tornar-se obsoleto ou ser des-
continuado. Além disso, por já estar integrado à maioria absoluta dos navegadores, essa
plataforma também oferece maior segurança.
Dito isso, a seguir iremos entender como essa plataforma é utilizada. Acompanhe!

7.3.1. Utilização de Java Script

A linguagem Java Script surgiu na década de 90, entre 1995 e 1996, e inicialmente
levava o nome de LiveScript. Essa mudança de nome causou uma confusão que ainda persiste:
entre o conceito de JavaScript e o de Linguagem Java. No entanto, são coisas bem diferen-
tes. As aplicações Java na web requerem a prévia de um software específico no computador,
enquanto o JavaScript é nativo em todos os principais navegadores (Suehring, 2013).

Curiosidade
O JavaScript foi desenvolvido por Brendan Eich, da Netscape, na década de
1990. A capacidade potencial que essa plataforma tinha na época fez com que Microsoft
enxergasse a empresa como uma grande ameaça. (SUEHRING, 2013; NODA e HEWIG, 2005).

Inicialmente, JavaScript foi amplamente utilizado para validação de formulários, o


permitiu que diversos erros passassem a ser verificados no navegador do usuário antes
mesmo de serem postados ao servidor web. Além disso, essa plataforma logo permitiu o
uso de imagens e de funções de interatividade (Suehring, 2013).
Com o passar do tempo, o JavaS-
cript passou a ampliar sua capacidade
de recursos e de possibilidades, repre-
© fatmawati achmad zaenuri / / Shutterstock.

sentando assim uma ótima escolha para


o desenvolvimento de aplicações ricas.
Essa plataforma é, portanto, ampla-
mente acessível em uma infinidade de
dispositivos, o que torna sua adoção
ainda mais atrativa.

Arquitetura de software 137


A adoção do JavaScript, no entanto, envolve a codificação das funções a serem ado-
tadas. Apesar de existirem uma infinidade de livros, de tutoriais e de códigos prontos (que
podem ser usados como referência ou mesmo como base inicial), essa codificação ainda
pode ser uma tarefa complexa em alguns cenários.
Contudo, há como facilitar esse desenvolvimento e é sobre isso que discorreremos a
seguir.

7.3.2. Utilização de Angular JS

Angular JavaScript, ou Angular JS, é um framework de código aberto desenvolvido e


mantido pela Google. Em sua versão inicial, possuía um foco maior em dispositivos móveis,
como celulares, mas com fraco desempenho. No entanto, devido à grande aceitação entre
os desenvolvedores e à evidente vulnerabilidade observada, diversas melhorias foram
implementadas nas versões posteriores.
Essas nova versões permitem a integração de HTML e JavaScript de forma a tornar
mais fácil, direta e prática a criação de aplicações ricas, sendo bastante útil para a progra-
mação de diversos conteúdo a serem disponibilizados na web. Grande parte das páginas
acessadas por usuários fazem uso dessa integração sem que eles percebam, uma vez que
funcionam quase como que se fossem uma linguagem só.
O Angular JS pode ser baixado a partir de seu site oficial, em que se obtém um
arquivo chamado “angular.min.js”. Para que sua página possa começar a usá-lo, o primeiro
passo é incluí-lo no código HTML, como o exemplo a seguir ilustra:

Código html Resultado no navegador

<!DOCTYPE html>
<html ng-app>
<head>
<title>Meu Primeiro Angular JS</title>
<script src=”js/angular.min.js”></script>
Olá Brasil!
</head>
<body>
<p>Olá {{’Bra’ + ‘il!’ }}</p>
</body>
</html>

138 Arquitetura de software


Note que, nesse exemplo, estamos considerando que o arquivo Angular JS baixado
encontra-se salvo dentro de uma pasta “js”, na raiz da pasta pública do site. Outro ponto
importante é que, conforme o padrão em JavaScript, a inclusão deve ser feita entre os cam-
pos <head> e </head>, portanto antes do início do corpo (<body>) da página.
A partir desse exemplo, pode-se observar que os códigos se encontram dentro de
uma sequência de duas chaves, e é justamente nelas que temos o uso do Angular JS. Ou
seja, a junção dos caracteres ‘Bra’ e ‘sil!’, feita de modo simples com o operador “+”, já
toma uso do framework Angular JS.
Apesar do exemplo ser bastante simples, o equivalente em JavaScript nativo certamente
exigiria um pouco mais de trabalho por parte do programador. No mínimo, seria necessário o
uso de “<script>” e “</script>” e, além da soma, efetuar a inserção do resultado na página.
Observe que, ao contrário do JavaScript “puro”, ao utilizar o Angular JS não é preciso
fazer indicação explícita, como <script> e <script>, nem evocar algum nome específico de
função. Desse modo, pode-se perceber como esse framework simplifica o desenvolvimento
de aplicações ricas com JavaScript.
Além disso, o Angular JS possui uma infinidade de funções pré-programadas e que
podem ser simplesmente evocadas (ao invés de codificadas). Essa característica facilita
a construção rica, uma vez que lida de forma simplificada com diversas funcionalidades,
interfaces e interações, garantindo, assim, um desenvolvimento eficiente.
Após conhecer o conceito de aplicações ricas, juntamente com sua origem, benefícios
e restrições, vamos, em seguida, realizar a atividade proposta e colocar em prática os estu-
dos realizados.

Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa,
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.

Agora é a hora de recapitular tudo o que você aprendeu nesse capítulo! Faça uma captura ou
fotografia (print) de uma aplicação rica web e aponte as principais características que a faz
ser classificada de tal modo, destacando as principais ideias abordadas ao longo do capítulo.
Ao produzir seu esboço, considere as leituras básicas e complementares realizadas.

Arquitetura de software 139


Recapitulando

Ao longo do presente capítulo estudamos diversos aspectos de aplicações ricas, cuja


compreensão é importante para a atuação como arquiteto de sistemas e desenvolvedor,
dado a sua relevância e ampla utilização.
Vimos que RIA permite um conjunto de benefícios e funcionalidades que não seriam
possíveis em aplicações da web somente mediante o uso de linguagem HTML. Além disso,
por meio de exemplos, vimos como elas estão inseridas em nosso cotidiano.
Estudamos como as aplicações ricas tornam as aplicações mais atrativas por meio de
interfaces mais amigáveis e interativas. Além disso, podemos perceber como RIA possibi-
lita que várias atividades sejam realizadas simultaneamente, o que garante uma melhor
experiência ao usuário.
Por fim, aprendemos, em linhas gerais, como JavaScript pode ser uma ótima escolha
para o desenvolvimento de aplicações ricas e como isso pode ser ainda mais facilitado com
o uso do Angular JS.
No mais, não deixe de aprofundar seus conhecimentos por meio da leitura das biblio-
grafias recomendadas e de outras fontes confiáveis na internet.

140 Arquitetura de software


Referências

ANGULAR JS. 2018. Disponível em: <angularjs.org>. Acesso em: 17 de dezembro de 2018.
FERREIRA, A.B.H. Mini Aurélio: o dicionário da língua portuguesa. Positivo, 2009.
GAMMA, E. et al. Padrões de projeto: soluções reutilizáveis de software orientado a obje-
tos. Porto Alegre: Bookman, 2000.
GOOGLE EARTH. Disponível em: <www.google.com/maps/place/Pra%C3%A7a+dos+Tr%-
C3%AAs+Poderes+-+Bras%C3%ADlia,+DF,+70297-400/@-15.8006763,-47.8632637,719m/
dat a = !3 m1!1e3 !4 m5!3 m4!1s 0 x 93 5 a3 b 47 7a9 8 47 1b: 0 x b 8 012 28 ac 3 432 2d! 8 m2!3 d -
-15.8003048!4d-47.8626804>. Acesso em 17 de dezembro de 2018.
LEIVA, L. A. Responsive text summarization. Information Processing Letters. v. 130,
p. 52-57. 2018. Disponível em: <doi.org/10.1016/j.ipl.2017.10.007>. Acesso em: 17 de dezem-
bro de 2018.
LIBRARY OF THE UNITED STATES CONGRESS. Library of Congress Web Archives Col-
lection. 2005. Disponível em: <webarchive.loc.gov/all/20050530043815/http://maps.yahoo.
com/py/ddResults.py?&newcountry=us&newtcountry=us&fuz=&tuz=&im=&Ed=_y3rCep_
0TpnFDMLv8Vhsp45L1BRfPLm8DRzsy6QDdM_zrqzeD2LUZrYj432Qd4-&tarcsz=Ponca+-
City,+OK>. Acesso em: 17 de dezembro de 2018.
MANNAN, M.; OORSCHOT, P.C. Security and Usability: The Gap in Real-World Online
Banking. 2008. Disponível em: <www.researchgate.net/publication/228730162_Security_
and_usability_The_gap_in_real-world_online_banking>. Acesso em: Acesso em: 17 de
dezembro de 2018.
NODA, T., & HEWIG, S. Rich Internet Applications: Technical Comparison and Case
Studies of AJAX, Flash, and Java based RIA. Best Practice Reports, 2005. Disponível em:
<www.researchgate.net/publication/277286833_Rich_Internet_Applications_Technical_
Comparison_and_Case_Studies_of_ AJAX_Flash_and_Java_based_RIA _EXE<CUTIVE_
SUMMARY_WEB_APPLICATIONS_NEW_TRENDS>. Acesso em 17 de dezembro de 2018.
PINA, D. S. A.; OLIVEIRA, L. E. M. C. RIA – Rich Internet Applications: uma revisão dos
principais expoentes da área. União dos Institutos Brasileiros de Tecnologia (UNIBRATEC).
Tecnologus. 7 ed. 2013. Disponível em: <www.unibratec.edu.br/tecnologus/wp-content/
uploads/2013/10/tecnologus_edicao_07_artigo_05.pdf>. Acesso em: 17 de dezembro de 2018.
SUEHRING, S. JavaScript Step by Step. 3 ed. Microsoft Press, 2013.

Arquitetura de software 141


CAPÍTULO 8

Computação em nuvem e softwares adaptativos


Sidartha Azevedo Lobo de Carvalho

OBJETIVOS DO CAPÍTULO
• Identificar os benefícios, premissas e restrições na implementação de uma arquite-
tura de software em nuvem, empregando os recentes estilos arquiteturais.

TÓPICOS DE ESTUDO

1 Introdução à computação em nuvem 3 Arquitetura adaptativa

• Tipologia da computação em nuvem. • Habilidade de mudança.


• Desenho da arquitetura. • Exemplo de aplicação.
• Modelo de implantação.

2 Arquitetura reativa

• Manifesto reativo.
• Decisões arquiteturais.

Arquitetura de software 143


Contextualizando o cenário

A oferta de produtos disponível por meio da internet vem crescendo de forma exponencial nos
últimos anos, tornando esses produtos acessíveis à população que tem o mínimo de conheci-
mento em computação. Para a oferta desses produtos, é necessário que quem oferece o pro-
duto tenha uma infraestrutura computacional para dar suporte aos pedidos dos seus clientes.

A partir dessa grande demanda por computação e da competitividade do mercado, é neces-


sário prover produtos melhores com baixo custo. As nuvens oferecem o serviço de compu-
tação de forma facilitada, não sendo necessário um investimento inicial muito grande com
infraestrutura. Além disso, as nuvens computacionais servem para prover a computação
como um serviço. Nesse contexto, podem ser adquiridos: computação de processamento,
armazenamento, transferência de dados, dentre outros serviços.

Dada a grande demanda e realocação de recursos para manter os sistemas, é necessário prover
arquiteturas e sistemas adaptáveis, permitindo que eles se adaptem aos diferentes contextos.
Por exemplo, há situações nas quais é necessário muito poder computacional por alguns poucos
dias ou meses, sendo necessário ter uma infraestrutura cara e disponível para poder prover esses
serviços. Assim, as nuvens servem para resolver esses problemas, oferecendo computação como
um serviço e usando a tarifação pay as you go, ou seja, só paga por aquilo que utilizar.

Diante desse cenário, questiona-se:


Como fazer uso da computação em nuvem como um serviço para o meu sistema?

144 Arquitetura de software


8.1. Introdução à computação em nuvem

Desde muitos anos atrás, a arquitetura-padrão para a produção de sistemas que utili-
zam redes (inclusive a internet) vem sendo a do tipo Cliente-Servidor. Nos últimos anos,
esse paradigma tem mudado, e as organizações estão implantando um novo conceito cha-
mado de nuvem – daí o nome computação em nuvem.
Com a expansão e popularização do acesso
à internet, aumento nas taxas de transferência de
dados e infraestrutura de hardware mais barata,

© makeitdouble / / Shutterstock. (Adaptado)


as organizações começaram a expandir seus negó-
cios para infraestruturas especializadas em pro- COMPUTAÇÃO
cessar e armazenar grande quantidade de dados. EM NUVEM
Essas infraestruturas são chamadas de nuvens.
A ideia inicial da nuvem era a de armazenar
os dados e realizar o processamento das aplica-
ções fora do ambiente organizacional, otimizando o uso de recursos. Esses locais próprios
para processamento e armazenamento são chamados de datacenters, também chamados
de nuvem pública.
A nuvem pública permite que as organizações executem todos (ou grande parte)
dos serviços ofertados pela rede em estruturas físicas mantidas por outras organizações,
reduzindo a complexidade dentro da organização e permitindo que ela foque sua visão em
estratégias de evolução. Os fornecedores dessa nuvem pública podem tarifar as organi-
zação de várias formas, dentre elas, a quantidade de uso de dados ou horas de processa-
mento. Para as organizações mantenedoras das nuvens, é uma abordagem que as permite
faturar dinheiro investindo em larga escala.
Como exemplo disso, podemos imaginar o seguinte: uma determinada organiza-
ção precisa de uma grande demanda de processamento e armazenamento por um ou dois
meses no ano (os meses nos quais há mais vendas). No restante do ano, essa organização
ficará com a infraestrutura subutilizada, ou seja, estará perdendo dinheiro. Uma forma de
contornar esse problema é fornecer esse poder de processamento para outras organiza-
ções – foi nesse contexto que surgiram as nuvens.
Atualmente, o conceito de nuvem é mais genérico, podendo haver nuvens públicas
(nas quais há compartilhamento de recursos) ou nuvens privadas. Nas nuvens privadas, os
dados e o processamento fazem parte de uma única organização. Além disso, também po-
demos ter as nuvens híbridas, formadas por privadas e públicas.

Arquitetura de software 145


Vale ressaltar que o conceito de nuvem parte basicamente do princípio de trocar a aqui-
sição de infraestrutura de tecnologia para a organização pelos serviços de processamen-
to e armazenamento. As principais operadoras de tecnologia do mundo (Google, Amazon,
Microsoft etc.) possuem infraestrutura de nuvem, permitindo a venda desse serviço.

Curiosidade
A Amazon é uma empresa americana de comércio de diversos itens, incluindo
eletrônicos, livros etc. Além disso, a Amazon fornece o serviço de computação em nuvem,
vendendo infraestrutura e plataforma como serviços (AMAZON, 2018).

Ademais, há diferentes tipos de computação em nuvem, envolvendo infraestrutura,


plataforma e software como serviços.

8.1.1. Tipologia da computação em nuvem

A computação em nuvem pode ser classificada de acordo com o serviço que é ofe-
recido, podendo ser fornecidos a infraestrutura, a plataforma ou o software. Esse tipo de
oferta de produto também é chamado de pilha de computação em nuvem – recebe esse
nome porque um serviço é apoiado em cima do outro (MICROSOFT AZURE, 2018).

© Bakhtiar Zein / / Shutterstock.

O primeiro tipo de computação em nuvem é a infraestrutura como serviço (Infras-


tructure as a Service - IaaS), cujo exemplo é locar um computador Pentium 4, 3.0 GHz, com
16GB de memória RAM, com Linux Debian. Nesse exemplo, essa infraestrutura citada
estará disponível para que o locador faça o que desejar com ela, sendo que a manipulação
da máquina virtual geralmente é feita por uma conexão SSH.

146 Arquitetura de software


A IaaS é a categoria mais básica que estudaremos, pois é como se fosse um aluguel
de uma infraestrutura de forma facilitada. Além disso, a IaaS pode ser utilizada para locar
servidores e máquinas virtuais em geral, armazenamento de dados, tráfego de rede e siste-
mas operacionais.
Quando a plataforma é ofertada como um serviço, temos a Platform as a Service
(PaaS). Esse tipo de oferta permite que os desenvolvedores façam uso de ferramentas,
criem e hospedem aplicativos na web. O PaaS é mais específico que a IaaS, pois oferta uma
camada a mais de infraestrutura, contando com as camadas de ferramentas e aplicativos.
A PaaS tem o objetivo de proporcionar acesso facilitado para desenvolver e operar
rapidamente aplicativos baseados na web, sem que o usuário tenha que se preocupar, por
exemplo, com os problemas de configuração e gerenciamento da infraestrutura nos servi-
dores, armazenamento dos dados ou tráfego da rede.
O terceiro tipo de computação na nuvem é a oferta de software como serviço, Soft-
ware as a Service (SaaS). Como o nome já diz, essa abstração é a de mais alto nível,
fazendo entrega de software, diferentemente da IaaS e PaaS. Na SaaS, são entregues apli-
cativos de software baseados na web, nos quais a hospedagem e o gerenciamento dos apli-
cativos são feitos pela infraestrutura contratada.
A SaaS é um tipo de oferta utilizada quando é necessário acessar serviços bem definidos
na nuvem: por exemplo, realizar um tipo de processamento em específico; fazer a conversão
de um valor monetário em diferentes moedas; converter uma foto JPEG para PNG etc.

Pausa para refletir

De que forma podemos escolher a melhor tipologia da nuvem para o nosso problema?

Essas ofertas de serviços possuem


diversos tipos de tarifação, mas a mais
© designer491 / / Shutterstock. (Adaptadao).

comum é a tarifação por uso, chamada de


pay as you go, ou seja, pague o quanto usar.
Esse modelo de tarifação beneficia o usuá-
rio do serviço, pois há situações em que
precisamos de muita demanda de processa-
mento ou armazenamento, embora a maior
parte do tempo isso não seja necessário.
Sem esse tipo de tarifação, teríamos que pagar de forma completa tudo o que gostaríamos
que ficasse disponível para nosso uso, o que levaria à subutilização do produto locado.

Arquitetura de software 147


O dimensionamento do processamento e do armazenamento permite aos usuários
projetarem sistemas que se beneficiem desse tipo de estrutura. Vamos exemplificar por
meio de um problema corriqueiro no Brasil: a emissão do Imposto de Renda brasileiro. Essa
emissão é realizada durante poucos dias do ano e utiliza uma grande quantidade de pro-
cessamento de requisições e armazenamento das declarações. Esse serviço, para ser ofer-
tado sem as nuvens, necessitaria de toda essa infraestrutura para dar suporte a milhões de
requisições e passar todo o restante do ano ociosa.
Ademais, os diferentes tipos de computação em nuvem também possuem um dese-
nho arquitetural.

8.1.2. Desenho da arquitetura

Para Fowler (2006), a arquitetura de um sistema deve ser guiada por dois objetivos
principais: servir de instrumento para a decomposição do sistema, de forma a melhorar sua
representação; e ter uma representação estável, ou seja, a arquitetura deve ser definida de
uma forma que as mudanças sejam mínimas até a finalização da construção do sistema.
Vamos aplicar esse conceito para definir alguns exemplos de arquiteturas que utili-
zam computação em nuvem. A figura a seguir ilustra a representação dos tipos de com-
putação: na base, temos a IaaS; no meio, a PaaS; e, no topo da representação, a SaaS. Os
níveis que estão abaixo fornecem a estrutura para os níveis superiores, ou seja, a IaaS for-
nece a infraestrutura necessária para fornecer a plataforma fornecida no nível acima, que,
por sua vez, fornece a arcabouço para poder oferecer o software como um serviço.

Oferta de serviços pela nuvem

Saas

Paas
© DTCOM

Iaas

Além da tipologia, uma nuvem pode apresentar alguns recursos. A figura a seguir ilus-
tra os recursos que podem estar presentes em uma nuvem. Primeiramente, temos o autoa-
tendimento sob demanda, no qual somente os recursos requisitados são reservados para o
uso. Essa característica se complementa com a elasticidade rápida: com a elasticidade, é pos-
sível alocar mais recursos (processamento, armazenamento etc.) em tempo de execução,
permitindo atender à demanda sem comprometer o desempenho da aplicação.

148 Arquitetura de software


Características de um sistema baseado na nuvem

Autoatendimento sob Pool de recurso


demanda

Computação em nuvem

Elasticidade
Amplo acesso a rápida
serviços de rede
Serviços
mensuráveis

© DTCOM
Fonte: NETO, 2018, s.p.

O pool de recursos fornece a funcionalidade de alocar os recursos computacionais


para diferentes usuários, permitindo que sejam alocados, de forma dinâmica, de acordo
com a demanda. Além disso, o amplo acesso a serviços de rede significa que os recursos
computacionais estão disponíveis para serem acessados utilizando-se a internet, por meio
de mecanismos padronizados de acesso a esses recursos (por exemplo, permitindo que
computadores desktop, dispositivos móveis e outros sistemas acessem os recursos inde-
pendentemente da plataforma utilizada).
Nossa última característica refere-se ao serviço mensurável: para manter o sistema
sempre apto a receber novos clientes e a gerenciar os recursos, é utilizada uma estratégia
automática, na qual há processos de monitoramento individual para armazenamento, pro-
cessamento etc. Esse monitoramento é transparente para o usuário e permite que a otimi-
zação do uso dos recursos seja alcançada.
Partindo dessas características, a computação em nuvem tem o intuito de criar a ilusão
da computação ilimitada, ou seja, os usuários poderão ter o quanto de processamento ou arma-
zenamento desejem sem se preocupar com as limitações da infraestrutura. Além disso, é pre-
gada a política de se pagar somente pelo que for utilizado, abordagem atrativa ao usuário.

8.1.3. Modelo de implantação

Os modelos de implantação representam as formas de implantar as nuvens computa-


cionais. Neto (2018) classifica os modelos em quatro tipos principais:

Arquitetura de software 149


• Nuvem privada (private cloud): esse modelo de implantação é utilizado geral-
mente por organizações que desejam ter controle total sobre o gerenciamento dos
recursos da nuvem, podendo garantir maior segurança nos dados. Na nuvem pri-
vada, a operação e o gerenciamento geralmente são feitos pela própria organiza-
ção, mas pode-se terceirizar esse serviço. O que caracteriza a nuvem privada é,
basicamente, o fato de ela ser utilizada por uma única organização, ou seja, não
está publica para uso geral. Dito isso, a nuvem privada pode ser classificada de
duas formas: nuvem privada hospedada pela organização e nuvem privada hospe-
dada por um provedor de serviço.
• Nuvem pública (public cloud): é um dos modelos mais utilizados. Nesse tipo de
nuvem, os serviços são disponibilizados de forma pública e tarifados na forma de
pague pelo uso (pay as you go). Geralmente, a nuvem pública é oferecida por gran-
des instituições, públicas ou privadas. Como exemplo disso, temos a empresa Ama-
zon, que oferece o serviço Amazon Web Service (AWS) para computação na nuvem.
• Nuvem comunitária (community cloud): nesse tipo de organização de nuvem,
geralmente a infraestrutura é montada e gerenciada por um grupo de organiza-
ções que compartilham os recursos fornecidos pela nuvem. Geralmente as orga-
nizações que compõem a nuvem comunitária partilham dos mesmos interesses,
podendo reduzir os custos com o compartilhamento. Além disso, também é pos-
sível que a infraestrutura esteja dentro de uma das organizações ou que seja insta-
lada em um provedor de serviços.
• Nuvem híbrida (hybrid cloud): nesse tipo de abordagem, há um conjunto dos tipos de
nuvens. Nesse conjunto, há uma agregação dessas nuvens para formar uma única.
Essa abordagem enfrenta um empenho extra para realizar o gerenciamento das diver-
sas nuvens e convertê-las em uma única, oferecendo transparência ao prover o serviço.
Cada modelo de nuvem possui suas
© Bakhtiar Zein / / Shutterstock. (Adaptado).

vantagens e desvantagens. Começare-


mos por algumas das vantagens, tanto
NUVEM HÍBRIDA das nuvens privadas quanto das públi-
cas: alta eficiência, alta disponibilidade,
NUVENS PRIVADAS NUVENS PÚBLICAS
elasticidade e rápida implementação.
Quanto aos benefícios únicos a redes
públicas, podemos citar: custos iniciais
reduzidos, economia proporcionada pela grande escala da nuvem, simplicidade de geren-
ciamento ao usuário, pagamento de acordo com o uso.

150 Arquitetura de software


Já a nuvem privada provê as seguintes vantagens: maior controle de segurança e qua-
lidade do serviço, integração facilitada, custos totais mais baixos (porém exige maior inves-
timento inicial) e por custos operacionais (uso mensal).
A figura a seguir sintetiza os tipos de oferta de serviços (IaaS, PaaS e SaaS) e sua
relação com os modelos de nuvem.

Tipologia de uso e nuvens

Iaas Paas Saas

Pública Privada Híbrida Comunitária

© DTCOM
Podemos perceber, nessa figura, que qualquer tipo de nuvem pode prover qualquer
dos serviços: tudo vai depender da forma como a oferta do serviço é organizada.

8.2. Arquitetura reativa

Uma arquitetura reativa é um tipo de arquitetura que segue as características defini-


das pelo manifesto reativo (MANIFESTO REATIVO, 2014). Essa abordagem surgiu de uma
necessidade das organizações, pois cada vez mais são necessários sistemas que respondam
a requisições em um menor tempo – antigamente, falávamos de segundos; atualmente,
estamos falando de milissegundos ou menos.
Além disso, em tempos passados, as organizações possuíam dezenas de servidores
para poder prover alguns poucos serviços, demorando vários segundos para responder a
requisições. Ainda havia manutenção que era cara e demorada, deixando o sistema indis-
ponível por várias horas ou até dias.
Quanto à granularidade dos dados, os sistemas, atualmente, podem trabalhar na
ordem dos petabytes (até poucos anos atrás, o máximo que se podia alcançar estava na
ordem dos gigabytes).
Por conta dessa mudança nos requisitos dos sistemas, foi preciso redefinir suas arqui-
teturas. A partir disso, surgiram as arquiteturas reativas, permitindo criar sistemas mais
robustos, mais resistentes e mais flexíveis do que os de antigamente.

Arquitetura de software 151


Pausa para refletir

Qual é a relação da arquitetura reativa com a computação em nuvem?

Atualmente, conseguimos ter sistemas que podem estar disponíveis 100% do tempo,
ficando apenas alguns minutos fora do ar por ano. Esse avanço é, em parte, provido pelo
uso das nuvens.
As nuvens, para serem atingirem uma boa qualidade na oferta dos seus recursos,
devem possuir as características dos sistemas reativos. Segundo os representantes do mani-
festo reativo, Sistemas Reativos são definidos como (MANIFESTO REATIVO, 2014, s.p.):
Nós acreditamos que é necessária uma abordagem coerente para arquitetura de sistemas,
e acreditamos que todos os aspectos necessários já são reconhecidos individualmente: nós
queremos sistemas Responsivos, Resilientes, Elásticos e Orientados a Mensagens.

Além disso, complementam:

Sistemas criados como Reativos são muito mais flexíveis, desacoplados e escalá-
veis. Isso os torna mais fáceis de desenvolver e manter. São mais tolerantes a falhas
e quando elas ocorrem são tratadas com elegância ao invés de desastre. Sistemas
Reativos são responsivos, dando aos usuários feedbacks mais interativos.

O sistema reativo também tem características próprias, definidas no manifesto reativo.

8.2.1. Manifesto reativo

O manifesto reativo é um documento que contempla algumas características de siste-


mas que devem ser aplicadas para garantir a construção de sistemas melhores. Essas caracte-
rísticas foram coletadas em grandes sistemas pelo mundo e sintetizadas nesse documento. O
manifesto conta com a colaboração de diversas pessoas de todo o planeta. Em analogia, pode-
mos comparar o manifesto reativo com o código do Linux ou do Android, que é construído por
diversas pessoas do mundo todo, agregando as melhores ideias e tornando-as públicas.

Dica
O Linux é a base do sistema operacional Android, que é utilizado na maioria dos
smartphones e sistemas embarcados atualmente. O Android herda várias características do
sistema Linux, como: sistemas de segurança, gerenciamento de energia, dentre outras.

152 Arquitetura de software


Os principais autores do manifesto (Jonas Bonér, Dave Farley, Roland Kuhn, e Martin
Thompson) sintetizaram as ideias de toda a comunidade.
Vale ressaltar, ainda, que há decisões arquiteturais que podem ser feitas para cons-
truir sistemas melhores, aplicando os conceitos aprendidos com o manifesto reativo.

8.2.2. Decisões arquiteturais

Segundo o manifesto reativo, um sistema reativo deve possuir as seguintes caracte-


rísticas: ser responsivo, resiliente, elástico e orientado a mensagens.
A responsividade de um sistema é a característica que representa quão rápido um
sistema é para responder a alguma solicitação. O sistema deve responder em tempo hábil:
por exemplo, se temos um sistema crítico, no qual uma requisição não pode exceder tan-
tos milissegundos, o sistema só é hábil se consegue responder antes desse tempo máximo
estabelecido. Se for responsivo, auxilia no tratamento de erros, pois permite conhecê-los
mais rapidamente. Além disso, de forma geral, o sistema deve ter um tempo reduzido de
resposta em todos os sentidos possíveis.

Dica
Os sistemas críticos também são chamados de sistemas rígidos de tempo real
(hard real time system - HRTS). São sistemas que devem obedecer a um tempo máximo de
resposta para serem úteis, como, por exemplo, sistemas de uso espacial.

Outra característica de um sistema reativo é ser resiliente. Se um sistema é resi-


liente, ele deve continuar a responder a requisições mesmo diante de falha. Além disso, é
preciso que haja um tratamento dessa falha, de modo que não impeça, de forma total, o
seu funcionamento. Essa característica permite a criação de sistemas com alta disponibi-
lidade. A resiliência pode ser alcançada com a replicação de servidores, contenção e isola-
mento da infraestrutura e delegação de responsabilidades.
O sistema também deve ser elástico, ou seja, mesmo sob variações na demanda pelo sis-
tema, ele deve continuar respondendo, de forma adequada, a requisições. De forma automa-
tizada, um sistema elástico deve aumentar ou diminuir a alocação de recursos de acordo com
as entradas que recebe. Em outras palavras, se recebe muitas requisições, deve aumentar os
recursos para poder responder a todos de forma hábil. Uma arquitetura elástica não pode con-
ter gargalos, deve permitir que a computação possa ser dividida entre outros recursos.

Arquitetura de software 153


Por último, um sistema reativo deve ser orientado a mensagens. Os sistemas reativos
devem utilizar mensagens assíncronas para trocar informações, já que esse tipo de mensagem
garante um baixo acoplamento entre os componentes, isolamento e transparência na locali-
zação. Ademais, a comunicação não bloqueante (assíncrona) permite que a infraestrutura seja
melhor utilizada, pois não fica ociosa esperando a resposta (no caso da comunicação síncrona).
A figura a seguir ilustra esses conceitos.

Características de um sistema reativo

Sustentável Extensível
Responsivo
Valor

Formato Elástico Resiliente

Significa Orientado a

© DTCOM
mensagens

Fonte: MANIFESTO reativo, 2014, s.p.

Os maiores sistemas do mundo são construídos seguindo essas propriedades, ser-


vindo a necessidades de bilhões de usuários diariamente (MANIFESTO REATIVO, 2014).
Aplicar esses conceitos já validados pelo mundo auxilia na construção de sistemas melho-
res desde a sua concepção.

8.3. Arquitetura adaptativa

Uma arquitetura adaptativa deve permitir ser adaptada de acordo com o contexto
em que está inserida, sendo a sua principal característica a habilidade de mudança. De
forma mais específica, uma arquitetura adaptativa é um sistema que muda sua própria
estrutura, comportamento ou alocação de recursos de acordo com a demanda recebida.
Essa adaptação geralmente é feita para suprir requisitos não funcionais, mas também pode
ser utilizada para agregar funcionalidades – embora exija uma inteligência computacional
bem mais sofisticada, sendo objeto de pesquisa atualmente.
Essas mudanças podem ocorrer de várias formas, mas sempre considera-se a habili-
dade de mudança na arquitetura de um sistema funcional. Um exemplo disso é a Black Friday,
dia do ano em que há uma grande quantidade de descontos no comércio do mundo todo.
Isso sobrecarrega os sistemas que realizam as vendas através da internet, sendo necessário
que esses sistemas se adaptem às demandas maiores.

154 Arquitetura de software


8.3.1. Habilidade de mudança

A habilidade de mudança em um sistema é essencial para a sua adaptação a diferen-


tes cenários. Como cenários, podemos ter situações nas quais um sistema seja mais requi-
sitado em alguns dias ou meses específicos do que em outros. Para pensar nisso, vamos
aprofundar o exemplo da Black Friday, que é um dia mundial de compras cujos descontos
são nosso cenário. Nesse cenário, temos uma alta demanda de transações de pedidos em
sites de vendas, aprovações de transações pelos cartões de crédito, demanda de entregas
nos sistemas de logísticas, dentre várias outras categorias que são afetadas com esse cres-
cimento nas vendas.
Além disso, há sistemas imprevisíveis, ou seja, não sabemos quando vai haver uma
grande demanda por infraestrutura. Nesses casos, é necessário que o sistema seja autoa-
daptável, ou seja, consiga se adaptar a diferentes cargas computacionais sem perder sua
disponibilidade.
Ademais, vale ressaltar que a habilidade de mudança é a principal característica de
uma arquitetura adaptativa.

8.3.2. Exemplo de aplicação

Como exemplo de uso de arquiteturas adaptativas, vamos aprofundar nosso cenário


relativo ao grande dia de vendas chamado de Black Friday. Primeiramente, vamos descre-
ver a arquitetura comum de uma loja on-line onde não há muitas requisições. A partir disso,
podemos perceber que um servidor simples consegue manter a disponibilidade do sistema
e atender a todas as requisições em tempo hábil. Depois disso, vamos demonstrar a adap-
tação dessa arquitetura para o dia da Black Friday, quando temos uma grande demanda por
computação, como: processamento, armazenamento e transferência de dados.
A figura a seguir ilustra uma arquitetura na qual há poucas requisições dos usuários.
Desse modo, é possível suprir todas as requisições com apenas um servidor e um sistema
de banco de dados que está associado a esse servidor em uso. Na próxima figura, temos
um item central chamado de balanceamento de carga: esse componente deve ter uma
certa inteligência para adaptar a infraestrutura de acordo com as entradas dos usuários. O
balanceador de carga deve monitorar a carga computacional para que não sobrecarregue
os servidores, permitindo elasticidade na infraestrutura e alta disponibilidade do sistema.

Arquitetura de software 155


Exemplo de arquitetura com baixa quantidade de requisições

Na figura a seguir, temos um cenário: há uma arquitetura que foi redimensionada


para uma alta demanda de usuários. Podemos perceber, no lado esquerdo da figura, que
há várias requisições de usuários. Após a detecção da grande quantidade de requisições,
por parte do balanceador de carga, a adaptação da arquitetura é feita de forma dinâmica
(usando nuvem, por exemplo), aumentando a quantidade de servidores e de bancos de
dados para armazenar as transações.

Exemplo de arquitetura com alta quantidade de requisições

Bancos de dados

Balanceamento de carga

Usuários
© DTCOM

Servidores

Em contrapartida, essa expansão adaptável caracteriza a elasticidade desse sistema,


no qual é possível expandir a arquitetura, de forma a receber mais requisições, ou seja, é
um sistema escalável. Além disso, utilizando o sistema de tarifação pay as you go, é possí-
vel ter acesso a um grande poder computacional e só pagar pelo que for utilizado.

156 Arquitetura de software


Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa,
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.

Agora é a hora de recapitular tudo o que você aprendeu neste capítulo! Descreva a arquite-
tura de um sistema baseando-se numa nuvem que envolva algumas escolhas (por exemplo,
qual tipo de nuvem é mais indicado para o seu sistema, quais características de um sis-
tema reativo ela deve conter, dentre outras características vistas no capítulo). Ao descrever
a arquitetura, siga todos os princípios que vimos neste capítulo. Além disso, aplique todo o
conhecimento adquirido nos capítulos da disciplina e considere as leituras básicas e comple-
mentares realizadas para ampliar seu conhecimento.

Recapitulando

Vimos, ao longo do capítulo, que a computação em nuvem pode servir aos diferentes
sistemas de diversas formas. Por exemplo, se precisamos da locação de recursos de forma
rápida e com baixo custo, é mais indicada a aquisição de serviços em nuvens públicas. Por
outro lado, se precisamos de maior segurança e maior poder de gerência dos nossos dados,
sem nos preocuparmos com os custos, é mais recomendada a construção de uma nuvem
privada ou comunitária (empresas parceiras).
Além disso, as diversas organizações de nuvem (pública, privada, comunitária e
híbrida) podem ser utilizadas como IaaS, PaaS ou SaaS. Vamos pensar na seguinte situa-
ção: se nosso sistema somente precisa de um hardware para executar o software e nós é
que vamos implementar todos os recursos que serão usados, o mais indicado é a IaaS, pois
temos maior poder de gerência do hardware locado.
Em outra situação, se vamos fazer uso de um sistema comum (por exemplo, uma pla-
taforma de vendas on-line) e precisamos de uma infraestrutura para receber muitas requi-
sições, o mais indicado é o PaaS ou o SaaS. O PaaS já conta com as ferramentas mais
comuns para pôr um site para funcionar – já o SaaS pode oferecer o serviço do site pronto,
só para pôr seus produtos à venda.
Por fim, vimos as características de uma arquitetura/sistema reativo. Esses princípios
são aplicados nas nuvens, ou seja, as nuvens precisam possuir essas características para
serem consideradas “boas”. Essas características permitem escalabilidade, elasticidade,
resiliência e orientação a mensagens.

Arquitetura de software 157


Referências

AMAZON. Amazon webstore. Disponível em: <www.amazon.com/>. Acesso em: 29/10/2108.


FOWLER, M. Padrões de arquitetura de aplicações corporativas. Porto Alegre: Bookman,
2006.
MANIFESTO reativo. O Manifesto Reativo. 2014. Disponível em: <www.reactivemanifesto.
org/pt-BR>. Acesso em: 26 out. 2018.
MICROSOFT Azure. Quais são os diferentes tipos de serviços de computação em
nuvem?. S.d. Disponível em: <azure.microsoft.com/pt-br/overview/types-of-cloud-compu-
ting/>. Acesso em: 24/10/2018.
NETO, M. V. S. Computação em nuvem. Rio de Janeiro: Brasport Livros e Multimídia Ltda,
2018.

158 Arquitetura de software


UNIVERSIDADE

160 Arquitetura de software