1.

Introdução
Sistemas Distribuídos e Mobiles são sistemas que permitem acesso rápido e
eficiente às informações. O desenvolvimento de sistemas Distribuídos e Mobiles é
semelhante ao desenvolvimento de softwares convencionais, assim, antes de “mergulhar
de cabeça” em sistemas distribuídos e Mobiles se faz necessário o estudo de alguns
artifícios, técnicas, modelos e padrões de desenvolvimento de software. Dessa forma,
vamos começar o estudo abordando um assunto muito importante no desenvolvimento de
software, “Arquitetura de Software”.
A complexidade dos sistemas de software tem aumentado consideravelmente nas
últimas décadas devido à inclusão de novas interfaces, integração de várias mídias e novas
tecnologias de armazenamento e distribuição de dados. Nesse sentido, os
desenvolvedores de softwares têm utilizado novas abordagens, a fim de desenvolver
sistemas com alto desempenho.
2.1.Arquitetura de Software
Ao logo dos anos, novas tecnologias, abordagens, métodos e ferramentas vem
surgindo para auxiliar os desenvolvedores de softwares a criar softwares com qualidade.
A utilização e compreensão de tais tecnologias ajuda a criar softwares com qualidades,
softwares robustos. Todavia, o grande primeiro passo para criar softwares com qualidade
é entender a sua arquitetura. Esse é o primeiro passo no desenvolvimento de software.
Talvez você possa estar se perguntando, qual o papel da arquitetura de software? Quais
são os modelos de arquitetura? Como a implantação de um modelo de arquitetura de
software pode melhorar a qualidade dos sistemas de informação?
Antes de responder a essas questões, é importante relembrarmos que a arquitetura
de software é considerada a área de conhecimento da Computação na qual são aplicadas
práticas da engenharia de software e da gerência de projetos, procurando obter melhor
organização dos sistemas e com alta produtividade. No estudo de “arquiteturas de
softwares” é que encontramos os modelos para especificar, projetar, implantar e manter
sistemas com qualidade.
Assim, podemos abstrair que; arquitetura de software consiste da definição dos
componentes, bem como, suas propriedades externas e seus relacionamentos com outros
softwares. Mas afinal, qual o verdadeiro propósito da arquitetura de software? Para alguns
autores na literatura, tal como, Galloti, o propósito da arquitetura de software é o de “criar
soluções [...] cada vez mais simples, rápidas e eficientes”. Além do exposto pelo autor,
devemos ir além, ou seja, não somente resolver problemas, mas também prevenir a
ocorrência deles e aperfeiçoar as soluções já existentes.
A história recente da Computação mostra a evolução das técnicas e dos métodos
de desenvolvimento de sistemas, passando pela programação estruturada, orientada a
evento até a orientação a objeto, assim como a evolução da lógica dos algoritmos e da
estrutura de dados.
Diante da complexidade dos sistemas atuais, é inevitável que tenhamos estilos de
arquitetura acompanhando tal evolução. É necessário ter um conhecimento bastante
sólido dos fundamentos e conceitos básicos da arquitetura de software para compreender
a evolução dos sistemas de informação e a estruturação lógica e abstrata deles, além de
desenvolvê-los com confiabilidade e alta qualidade.
Entendemos o que é a arquitetura de software, todavia, precisamos entender qual
o sentido fundamental de arquitetura de software. Para Galloti (2016, p. 10), ela “[...]
explica a forma como [ele] se organiza e funciona, além de seu modo de implementação”.
Portanto, agrega os componentes denominados elementos arquiteturais (dados,
processamentos e conexão), que se organizam de maneira lógica para atender aos
requisitos funcionais e não funcionais. Para tal, a arquitetura de software deve ser clara,
a fim de atingir o máximo da simplicidade, tendo o software as seguintes características:
• flexível: deve permitir as mudanças que se façam necessárias em
decorrência das alterações de requisitos;
• extensível: deve ter a capacidade de incorporar novos elementos,
permitindo que a estrutura do sistema como um todo se estenda;
• portabilidade: permite que ele seja executado em mais de uma
plataforma;
• reutilizável: é possível adaptar componentes de um software para outro.
O projeto de arquitetura é o primeiro passo no processo de implantação de um
modelo de arquitetura de software: ele a conecta com a engenharia de requisitos – esta
última é o processo que elabora os documentos dos requisitos funcionais e não funcionais
durante todo o ciclo de vida do sistema. É nesta parte do processo que são identificados
os componentes estruturais e os seus relacionamentos.
A arquitetura de software se altera na mesma medida em que ele evolui e se ajusta
às novas demandas e evoluções tecnológicas. Portanto, ela é parte integrante da
engenharia de software, que é uma abordagem sistemática e formal de desenvolvimento
dos sistemas de informação. Estudar e determinar a arquitetura de software é uma tarefa
fundamental para o desenvolvimento de um sistema, pois integra o desempenho, a
robustez e a capacidade do sistema de sua manutenibilidade.
Um software de qualidade deve possui determinadas características. Tais como
apresentadas na Figura 1. Estas características terão maior ou menor relevância
dependendo do propósito do software e do contexto no qual ele está inserido. Por
exemplo, softwares de transações informacionais básicas (como, por exemplo, um
sistema de cadastro de clientes de uma loja) terão atributos de qualidade diferentes de
sistemas mais complexos como, por exemplo, um software de controle de uma fábrica.
No primeiro caso, o foco do sistema estará mais atrelado à interface do cliente, e fatores
como usabilidade e acessibilidade serão mais críticos. Por outro lado, nos sistemas de
controle industrial, por exemplo, os atributos de confiança e proteção serão mais críticos
devido à natureza e finalidade deste sistema.
Figura 1: Atributos essenciais de qualidade de um software, sendo parte integrante da
elaboração da arquitetura de um sistema de informação.
Fonte: SOMMERVILLE, 2011, p. 5.
Um projeto de arquitetura de software visa desenvolver softwares com qualidades.
A seguir, veremos os principais tipos de arquitetura de softwares.
2.2.Tipos de Arquitetura de Softwares
Podemos conceituar o projeto de arquitetura, segundo Sommerville (2011, p. 105),
como “[...] um processo criativo no qual você projeta uma organização de sistema para
satisfazer aos requisitos funcionais e não funcionais de um sistema”. Baseando-nos na
afirmativa do autor, podemos perguntar: existe uma arquitetura genérica que pode atuar
como um modelo para o sistema que está sendo projetado? Quais padrões de arquitetura
podem ser usados
A arquitetura de um software pode ser baseada em um determinado padrão ou
estilo. Um padrão de arquitetura significa como o software é organizado: por exemplo,
existe o padrão de organização cliente-servidor e um padrão de arquitetura em camadas.
Esses padrões mostram o objetivo de uma arquitetura que foi utilizada em sistemas de
software diferenciados. Nesse sentido, o desenvolvedor, ao tomar decisões sobre qual a
arquitetura de um sistema, deve conhecer os padrões mais comuns e saber onde eles
podem ser usados e quais são seus prós e contras. A seguir, iremos estudar os principais
tipos de arquitetura de softwares. Começando pela “abordagem em camadas”.
2.2.1. Abordagem em camadas.
Esta arquitetura sustenta o desenvolvimento de um sistema de forma incremental.
Quando uma camada é desenvolvida, alguns serviços podem ficar disponíveis para os
usuários. A arquitetura também tem como características a mutabilidade e a
portabilidade. Se a interface ficar inalterada, uma camada pode ser substituída por outra
equivalente, ou seja, quando uma camada de interfaces é alterada ou tem novos recursos
incluídos, somente a camada adjacente é afetada. Portanto, este padrão se caracteriza pela
organização do software em camadas, cuja funcionalidade é associada a cada uma delas.
Desse modo, uma camada deve fornecer serviços à camada acima dela, e os níveis mais
baixos de camadas representam os principais serviços utilizados no sistema.
Sua vantagem é permitir a substituição de camadas inteiras, mas, por outro lado, é
difícil ter clara a separação entre as camadas e como interagem camadas de níveis mais
alto e mais baixo, impactando o desempenho geral do sistema.
2.2.2. Repositório
Esta arquitetura tem como característica que todos os dados do sistema são
gerenciados em um repositório central, ficando acessível a todos os componentes do
sistema. Neste padrão, existe a vantagem de os componentes serem independentes. Mas,
por outro lado, o repositório se torna um ponto único de falha.
2.2.3. Cliente e servidor
Cliente-servidor: é organizado segundo um conjunto de serviços e servidores ligados
aos clientes. Segundo Sommerville (2011, p. 113, grifos nossos), os principais
componentes deste modelo são:
• Um conjunto de servidores que oferecem serviços a outros componentes.
Exemplos de servidores incluem: servidores de impressão que oferecem serviços
de impressão; servidores de arquivos que oferecem serviços de gerenciamento de
arquivos; e um servidor de compilação, que oferece serviços de compilação de
linguagens de programação.
• Um conjunto de clientes que podem chamar os serviços oferecidos pelos
servidores. Em geral, haverá várias instâncias de um programa cliente executando
simultaneamente em computadores diferentes.
• Uma rede que permite aos clientes acessar esses serviços. A maioria dos sistemas
cliente-servidor é implementada como sistemas distribuídos, conectados através
de protocolos de Internet.
Esse modelo geralmente é utilizado quando os dados compartilhados precisam ser
acessados de vários locais. Na figura a seguir, demonstraremos esse modelo-padrão.
 Figura 2: Modelo cliente-servidor, demonstrando a relação entre clientes, internet e
serviços disponíveis
.Fonte: Elaborada pelo autor, baseado em SOMMERVILLE, 2011.
A vantagem desse modelo é a característica de distribuição por meio de uma rede,
podendo estar disponível para todos os clientes. Porém, cada serviço se torna um ponto
de falha, tornando o desempenho imprevisível.
2.2.4. MVC (Modelo-Visão-Controlador)
Esta arquitetura é considerada a base do gerenciamento de interação, separa a
apresentação e a interação dos dados do sistema, sendo que o sistema é estruturado em
três componentes lógicos que se comunicam entre si: o componente Modelo é
responsável por gerenciar o sistema de dados e as operações associadas aos dados; o
componente Visão é responsável por definir e gerenciar a forma de os dados se
apresentarem; o componente Controlador é responsável por gerenciar a interação do
usuário e passá-la para a Visão e o Modelo.
Geralmente, este padrão pode interagir e visualizar os dados de diversas maneiras,
sendo que sua vantagem é permitir que os dados podem ser alterados de forma
independente da sua representação. Por outro lado, quando o modelo de dados é muito
simples, pode envolver complexidade adicional desnecessária. Na figura a seguir,
demonstraremos este modelo.
 Figura 3: Modelo da organização MVC com a demonstração do fluxo de ações e das
mudanças de estado.
Fonte: Elaborada pelo autor, baseado em SOMMERVILLE, 2011.
Existem padrões que se baseiam no padrão MVC, ou melhor, existem variantes do
MVC, tais como MVP (Model View Present) e MVVM (Model-View-ViewModel), tais
padrões são apresentados a seguir.
2.2.5. Padrões MVP e MVVM
Sendo variantes do MVC, MVP (Model View Present) e MVVM são arquiteturas
bastante utilizadas atualmente. Vamos começar o estudo pelo MVP.
2.2.5.1.Model View Present (MVP)
Dividido em três partes; Model, View e Presenter, o MVP visa separar a camada
de apresentação das camadas de dados e das regras de negócios da aplicação. Este padrão
visa separar os dados, das regras de negócios, como também, será a apresentação. Os 3
elementos do MVP é:
Model – Representa os objetos que serão manipulados. Assim, um Objeto Model
possui uma interface que mostra os campos que o elemento Presenter atualizará quando
o View sofre alterações. Em palavras mais simples, podemos dizer que o Model é uma
simples interface que expõe o modelo de dados que será exibido ou alterado na interface
do usuário.
View: Uma View é uma interface que apresenta os dados (Modelo). A View
também é responsável por “guiar” os comandos dos usuários (eventos) à camada
Presenter que atua sobre os dados.
 Presenter: atua sobre o Model e a View. O Presenter recupera os dados dos
repositórios (modelos) e os formata para apresentações na View. Podemos dizer que o
Presente faz a ligação entre a View e o Model.
A Figura 4 ilustra a interação entre View, Presenter e Model.

Figura 4: MVP
Fonte: Próprio Autor
Neste modelo a View recebe os eventos dos usuários e encaminha as operações
para o Presenter. O Presenseter por sua vez obtém os dados do Model, atualiza tais dados
recebidos e atualiza a View.
Pode parecer ser confuso, todavia, é simples de compreender. Vai um resuminho
para você entender mais fácil. O padrão MVP é composto por Model, View e Presenter.
O Model basicamente representa o modelo de dados, O Presenter atua sobre os dados do
Model e os preparam para serem apresentados na View. Simples assim
2.2.5.2.Model-View-ViewModel (MVVM)
O Modelo MVVM (Model-View-ViewModel) é considerado uma pequena
variação do modelo MVP e do MVC. Na verdade, o MVVM é uma adaptação do MVP
para a arquitetura WPF (Windows Presentation Foundation) e Silverlight. Podemos até
dizer que MVVM e o MVP são conceitualmente semelhantes, a diferencia entre os dois
é que MVVM é especifico para WPF e Silverlight, já MVP é independente de plataforma,
ou tecnologia.
O padrão MVVM possui 3 elementos: Model, View e ViewModel. Podemos dizer
ainda que, o MVVM também se baseia no padrão MVC, ambos possuem Model-View,
mas são diferenciados pelo ViewModel do MVVM. A arquitetura MVVM foi
desenvolvida para implementar a vinculação de dados entre o o ViewModel e sua View.
3. Principais padrões de projeto do GoF (Gang of Four).
Agora, vamos falar um pouco mais sobre padrões de projetos para projetos orientados
a objetos. Todavia, vale relembrar, o que é um padrão de projeto? Um padrão de projeto
(Design Patterns) pode ser compreendido como descrição de uma solução comprovada
para um problema em um projeto de desenvolvimento de software orientado a objeto.
Porquê padrões de projetos são importantes? Porquê usa-los? Padrões de projetos são
excelentes formas de expor o conhecimento no projeto de forma simples e que
principalmente, agregue benefícios ao projeto.
Historicamente, o Design Patterns começou em 1970 com dois livros de Christopher
Alexander, “A Pattern Language” e “Timeless Way of Building”. Nestes livros
Christopher descrevia seus pensamentos para documentar padrões.
Devemos também, lembrar que Erich Gamma, Richard Helm, Ralph Johnson, e John
Vlissides escreveram o livro “Design Patterns” com 23 padrões de projetos. Para eles,
“Conhecer tais padrões é fundamental para entender os modernos frameworks e as novas
tecnologias que surgem a todo o momento no desenvolvimento de software e
consequentemente, obter qualidade no desenvolvimento de software”. Interessante
observar que muitos conhecem esses padrões por “padrões de projeto do GoF (Gang of
Four, português, gangue dos 4)”, pelo fato de 4 amigos terem escritos o livro.
Os padrões são uma forma de reutilizar o conhecimento e a experiência de outros
projetos. Os quatro elementos essenciais dos padrões de projeto são definidos como:
• Um nome que seja uma referência significativa para o padrão.
• Uma descrição da área de problema que explique quando o modelo pode ser
aplicado.
• A descrição da solução das partes da solução de projeto, seus relacionamentos
e suas responsabilidades. Essa não é uma descrição do projeto concreto; é um
modelo para uma solução de projeto que pode ser instanciado de diferentes
maneiras. Costuma ser expresso graficamente e mostra os relacionamentos
entre os objetos e suas classes na solução.
• Uma declaração das consequências — os resultados e compromissos — da
aplicação do padrão. Pode ajudar os projetistas a entenderem quando um
padrão pode ou não ser usado em uma situação particular.
Sommerville (2011) explica que, para podermos ilustrar a descrição de padrão,
devemos utilizar o padrão ‘Observer’, conforme demonstraremos no quadro a seguir.
 Figura 5: Descrição do padrão ‘Observer’, demonstrando suas características, suas
descrições, seus problemas, suas soluções e suas consequências. Fonte: Elaborado pelo
autor, baseado em SOMMERVILLE, 2011

Os padrões estabelecidos por GoF são basicamente divididos em 3 grupos:

• Padrão de Criação:
o Padrões que são relacionados com criação de classes e objetos.
o Padrões que são ligados ao processo de instanciação de objetos.
• Padrão Estrutural:
o Padrões que tratam da alteração da estrutura de um software, isto é,
padrões que se preocupam com as associações entre classes e objetos.
• Padrão Comportamental:
o Padrões que descrevem como as classes e objetos podem interagir.
No grupo de “Padrão de criação” temos os padrões:
 • Singleton: este padrão garante que somente um objeto de uma classe especifica
seja criado em todo o projeto.
• Factory: Permite a criação de famílias de objetos relacionados ou dependentes,
através de uma única interface e sem que a classe concreta seja especificada.
• Abstract Factory: este padrão permite criar “família” de objetos sem especificar
a classe concreta.
• Builder: já este padrão permite a separação da construção de um objeto complexo
da sua representação.
• Prototype: visa a criação de objetos a partir de um modelo original, ou protótipo.
No grupo de “Padrões Estruturais” temos:
• Bridger: este padrão visa desacopla a interface da implementação, isto é, ocultar
detalhes das aplicações.
• Proxy: este padrão visa fornecer objeto representante de outro objeto para
controlar o acesso ao mesmo.
• Flyweight: este padrão permite que vários objetos devem ser manipulados, mas
não suportam dados adicionais.
• Composite: permite que o objeto seja desconstituído pela composição de objetos
semelhantes.
• Decorator: visa definir responsabilidade adicionais a um objeto dinamicamente
da classe.
• Façade: visa permiti que as interfaces sejam unificadas para um subsistema,
tornando o subsistema mais fácil de usar e simples.
• Adapter: que possibilita que classes com interfaces que não são compatíveis
interagem.
No último grupo, “Padrões Comportamentais” temos:
• State: visa permiti que objetos alterarem seus comportamentos quando seus
estados internos mudarem.
• Visitor: este padrão visa defini operações independentes a serem realizadas sobre
elementos de uma estrutura.
• Strategy: estabelece uma família de algoritmos que sejam utilizados de modo
independente e seletivo.
• Template: visa defini o esqueleto de um algoritmo em uma operação adiando a
definição de alguns passos para a subclasse.
• Observer: a função deste padrão é defini uma relação de dependência 1:N de
forma que quando um objeto tem seu estado modificado os demais são
notificados.
• Chain of Responsibility: este padrão evita dependência do remetente de uma
requisição ao seu destinatário.
• Command: este padrão defini uma associa entre ações a diferentes de objetos
através de uma interface conhecida.
• Interpreter: visa ajudar uma aplicação a entender uma declaração de linguagem
natural e executar a funcionalidade da declaração.
 • Iterator: este padrão defini uma forma de percorrermos elementos de uma
coleção sem violar o seu encapsulamento.
• Mediator: visa desacoplar e gerenciar as colaborações entre um grupo de objetos
instanciados.
• Memento: este padrão visa capturar o estado interno de um objeto.

A figura a seguir, apresenta os padrões de forma resumida ressaltando as suas funções.

Figura 6: Padrões de Projetos

Fonte: extraído de FERREIRA, 2019
Em suma, padrões de projetos são importantes para manter a qualidade no
desenvolvimento de software.
3.1.Projeto de software baseado em padrões
Qual o objetivo de construirmos projetos de software baseando-se em padrões?
Fundamentalmente, baseia-se nas boas práticas de reuso de soluções, porém vai além
disso: projetos baseados em padrões auxiliam no entendimento da arquitetura pelos
desenvolvedores, firmam a conformidade entre a arquitetura proposta e efetivamente
implantada e, consequentemente, reduzem o tempo de implantação. Portanto, quando
desenvolvemos projetos de sistemas baseados em padrões, temos uma prática de uso dos
atributos de qualidade, contando que as características de qualidade de uma determinada
arquitetura estão descritas no próprio padrão.
 3.1.1. Contexto do projeto baseado em padrões
Conforme demonstrado por Azevedo (2014, p. 23), as decisões arquiteturais
compreendem decisões estratégicas feitas durante o projeto de arquitetura. Estas
decisões possuem alto impacto sobre o alcance de metas do negócio que o software se
propõe. Estas decisões também possuem impacto sistêmico, quer dizer, impactam em
mudanças na estrutura e no comportamento de todo o sistema. As decisões tomadas sobre
o contexto do projeto envolvem criação de regras de projeto e de restrições aos
componentes, pois define o que o sistema ou partes dele não poderá realizar e inclusive
como não poderá ser utilizado.
O que temos é que padrões de projeto não possuem, necessariamente, um foco em
preocupações de arquitetura, mas podem ser interpretados de um ponto de vista
arquitetural. Na verdade, vários pesquisadores argumentam que é difícil conhecer um
limite entre padrões arquiteturais e padrões de projeto.
4. Injeção de dependência e Inversão de controle
Agora, vamos falar de outro assunto muito importante no desenvolvimento de
software, “Injeção de dependência e Inversão de controle”. Vamos primeiro entender o
que é inversão de controle, também chamada de IoC (Inversion of Control). De forma
simples, inversão de controle pode ser compreendida como uma forma diferente de
manipular um objeto. IoC é um padrão que permite inverter o controle de uma classe
delegando para outra classe, interface, componente e entre outros.
Agora a Injeção de dependência também chamada de (Dependency Injection, ou
simplesmente de DI). Injeção de Dependência é uma das formas de se realizar a Inversão
de Controle. DI passa a dependência (o serviço) para o dependente (o cliente). Isso é a
chamada injeção. O importante é entender que injetamos o serviço no cliente, ao invés de
o próprio cliente procurar e construir o serviço que irá utilizar.
DI é uma eficiente e elegante para programar. Quando usamos DI no código, facilita
a testabilidade do software, visto que apenas uma classe específica precisa ser testada, e
as dependências podem ser substituídas por uma classe simulada que contém dados de
teste. Dessa forma, DI é o padrão básico do desenvolvimento ágil de software e de práticas
contínuas de entrega de software.
Referências:
CAGNIN, R. L. Uma arquitetura multiagente para gerenciamento de dispositivos em
ambientes da internet das coisas. 2015. 123 f. Dissertação (Mestrado em Ciência da
Computação) – Universidade Estadual Paulista, São José do Rio Preto, 2015. Disponível
em: <http://www.athena.biblioteca.unesp.br/exlibris/bd/cathedra/02-08-
2017/000868971.pdf>. Acesso em: 15/5/2018.
CUNHA, D.; FILGUEIRA, A; VIANA, G. Arquitetura de software voltada para a
avaliação contínua do processo de ensino-aprendizagem. Revista HOLOS, Natal, IF-RN,
ano 33, v. 1, p. 43-56, 2017. Disponível em:
<http://www2.ifrn.edu.br/ojs/index.php/HOLOS/article/view/5335/pdf>. Acesso em:
15/5/2018.
FONSECA FILHO, C. História da computação: o caminho do pensamento e da
tecnologia. Porto Alegre: PUC-RS, 2007. Disponível em:
<http://www.pucrs.br/edipucrs/online/historiadacomputacao.pdf>. Acesso em:
15/5/2018.
GALLOTI, G. M. A. Arquitetura de software. São Paulo: Pearson Education do Brasil,
2016.
HOFMEISTER, C.; NORD, R.; SONI, D. Applied Software Architecture. Boston:
Addison-Wesley, 2000.
HUZITA, E. H. M.; OLIVEIRA, H. M.; LAINE, J. M. Uma proposta de arquitetura de
software baseada em agentes. Acta Scientiarum - Technology, Maringá, UEM, v. 22, n.
5, p. 1339-1346, 2000. Disponível em:
<http://periodicos.uem.br/ojs/index.php/ActaSciTechnol/article/view/3131/2252>.
Acesso em: 15/5/2018.
PRESSMAN, R. Engenharia de software: uma abordagem profissional. 8. ed. Porto
Alegre: McGraw Hill, 2016.
SIZO, A. M.; LINO, A. D. P.; FAVERO, E. L. Uma proposta de arquitetura de software
para construção e integração de ambientes virtuais de aprendizagem. Revista Ibérica de
Sistemas e Tecnologias de Informação (RISTI), Porto, n. 6, p. 17-30, dez. 2010.
Disponível em: <http://www.scielo.mec.pt/pdf/rist/n6/n6a03.pdf>. Acesso em:
15/5/2018.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall,
2011.
TYLDUM, M.; MOORE, G. O jogo da imitação. Direção: Morten Tyldum. Produção:
Morten Tyldum. Estados Unidos: Warner Bros, 2014.
FERREIRA, F. H. – Design Patterns. Disponível em:
https://ferhenriquef.com/2012/08/27/design-patterns/