Arquitetura de Software Material Apoio AOL 1

Prévia do material em texto

Arquitetura de software
A arquitetura de software é um conceito que vem sendo muito discutido na última década pelo meio relacionado ao desenvolvimento de software, muito embora o conceito permeie os profissionais desta área bem antes disso.
Muitas vezes, quando começamos o trabalho em uma aplicação legada, ou até mesmo quando utilizamos uma solução, sentimos alguns desconfortos com algumas de suas características. Esse sentimento se trata de um alerta natural que, muitas vezes, pode indicar uma falha arquitetural no software.
A arquitetura de software tem como princípio a estruturação de soluções que possibilitam o atendimento de todos os requisitos técnicos e operacionais definidos pelo requerente. Tais requisitos buscam otimizar outras características importantes presentes nas soluções de software, representados, em sua maioria, pelos requisitos não funcionais (performance, segurança, disponibilidade, etc.).
Além disso, a arquitetura de um software busca definir e agrupar o conjunto de decisões técnicas e estruturais que irão permear a confecção dos componentes de software.  Junto a isto, utiliza-se um mapeamento do impacto que cada decisão terá na solução final.
ASSISTA
Assista à palestra ministrada por André Paulovich, em um evento sobre Arquitetura de Software. Nesta palestra, ele fala sobre a importância de se pensar a arquitetura e sobre como a montagem e evolução da arquitetura no ciclo de vida de um software são importantes.
ASSISTA
REQUISITOS NÃO FUNCIONAIS
Como vimos até este momento, podemos identificar a importância de se utilizar a arquitetura de software no desenvolvimento de softwares complexos e de grande porte. Essa importância é facilmente identificada em casos como o desenvolvimento de linhas de produção, nos quais um conjunto de estilos, prerrogativas arquiteturais e funcionalidades são utilizados como base nas arquiteturas de softwares. Entretanto, antes mesmo do design da arquitetura e de sua definição, temos um player importante a ser considerado, denominados requisitos não funcionais. 
Durante a fase de levantamento dos requisitos do sistema, o arquiteto de software utiliza seus conhecimentos e sua experiência para recuperar requisitos e identificar as características que não são consideradas diretamente funcionais, ou ligadas a uma funcionalidade de negócio. Basicamente, esse tipo de requisito não informa o que o sistema deve fazer, mas sim como ele deve realizar essas ações e funcionalidades.
Alguns exemplos de requisitos não funcionais que são importantes em grande parte das soluções de software são:
Clique nos cards para saber mais
É um dos conceitos mais entrelaçados com a arquitetura de um software, pois a definição da arquitetura impacta diretamente no nível de dificuldade que um sistema tem em ser corrigido em caso de um bug ou de uma nova implementação.
Este conceito abrange vários tipos de métricas que auxiliam a medir se o sistema é capaz de se manter em execução sem apresentar falha, dado um período de tempo definido.
O conceito de performance é um dos mais importantes e normalmente está presente como requisito obrigatório em todos os softwares desenvolvidos. Sua principal característica é garantir que o software tenha um bom tempo de resposta/processamento nas funcionalidades do sistema, principalmente nas funcionalidades críticas. Dentre as métricas normalmente acompanhadas, estão: latência, capacidade de throughput, tempo de resposta e velocidade de processamento.
Este conceito envolve o trabalho em projetar um sistema/solução no qual o usuário tenha a facilidade de utilizá-lo, tornando agradável o seu uso.
Outros requisitos não funcionais são muito importantes também, tais como segurança, interoperabilidade, testabilidade e outros.
Outros requisitos não funcionais são muito importantes também, tais como segurança, interoperabilidade, testabilidade e outros.
O PAPEL DO ARQUITETO DE SOFTWARE
No desenvolvimento de softwares, é necessário levar em consideração três tipos de informações/requisitos para que se possa desenvolver uma solução de software:
· Requisitos de negócio;
· Requisitos de usuário;
· Requisitos não funcionais.
Pensando neste ponto, é necessário que haja um ou mais profissionais da área de desenvolvimento que tenha a capacidade e a expertise de trabalhar com todos os requisitos necessários. Esse papel é desempenhado pelo arquiteto de software.
O arquiteto de software deve levar em consideração os três tipos de requisitos ao realizar o design da arquitetura e o mapeamento das decisões e tecnologias utilizadas. A Figura 1 demonstra a variação e o entrelaçamento desses requisitos.
Figura 1. Entrelaçamento de requisitos.
O arquiteto de software tem a responsabilidade de desenvolver uma arquitetura viva e evolutiva, com capacidade de suportar as necessidades do cliente. Desse modo, ele deve refletir bem sobre as decisões técnicas relacionadas ao hardware, componentes externos e outros recursos que possam ser importantes para o desenvolvimento da solução. Seguindo o processo evolutivo e incremental, o arquiteto de software pode criar sua primeira versão da estrutura arquitetural a ser utilizada, provendo detalhes de mais alto nível que, posteriormente, serão incrementados e detalhados.
Ao final do trabalho do arquiteto de software, ele produz alguns artefatos importantes que irão permear o desenvolvimento do software, tais como:
· Documentação arquitetural (em maior ou menor nível de detalhe, dependendo do projeto, metodologia e necessidade);
· Definição dos atributos de qualidade a serem seguidos;
· Requisitos de segurança;
· Plano de implantação;
· Documento de padrões técnicos de desenvolvimento;
· Plano de testes.
RECUPERAÇÃO ARQUITETURAL DE SOFTWARE
Dentro da disciplina da arquitetura de software, vemos cenários dos quais é necessário extrair a arquitetura de um software legado para que se possa entender tanto sua estrutura quanto o modo como ele foi concebido.
A recuperação de arquiteturas (ou arqueologia arquitetural) é um viés da disciplina de arquitetura de software que permite ao arquiteto realizar tal tarefa. Sua metodologia é composta por um conjunto de métodos para a extração de diversas informações arquiteturais, com representações da aplicação de mais baixo nível (como o código-fonte).
Muitas vezes o processo de extração desses elementos arquiteturais envolve o agrupamento de partes do código-fonte em partes menores (subsistemas), seguindo um conjunto de definições e critérios que definem o escopo e tamanho de cada parte. Isso ocorre porque nesses sistemas legados normalmente a documentação arquitetural é ausente ou está desatualizada em relação ao que está implementado no sistema.
Para realizar este tipo de análise e executar a recuperação da arquitetura, é utilizada, na maioria dos casos, a análise estática de sistemas (static analysis of systems), que consiste em realizar a análise do sistema sem executar a aplicação. A engenharia reversa e as métricas de software são formas de realizar essa análise estática.
Outra forma de se realizar essa recuperação é utilizando análise dinâmica de sistemas (dynamic analysis of systems). Neste caminho, normalmente utilizado em sistemas baseados em orientação por objetos, a análise é realizada na execução da aplicação, observando seu comportamento durante este período.
Alguns tipos de implementações da análise dinâmica são:
· Cobertura de código (Code Coverage);
· Detecção de erros de memória;
· Erros de concorrência;
· Análise de performance.
Para todos os cenários, a utilização de ferramentas é necessária para a aquisição de dados e sua posterior análise. Um exemplo seria a utilização da ferramenta PurifyPlus, da Pure Software, para análise de memória, ou o Jmeter, para avaliação de performance.
EROSÃO ARQUITETURAL
Nesta parte da disciplina de arquitetura de software, o objetivo é identificar o gap entre o que foi inicialmente planejado e o que foi realizado em sua implementação. A erosão arquitetural ocorre quando a implementação viola as regras e decisões definidas no design da arquiteturaou na implementação parcial de algum requisito. Este gap identificado entre o planejado e o implementado é chamado de débito técnico (Technical Debt).
Basicamente, podemos utilizar duas técnicas para identificar as violações arquiteturais:
· Modelos de reflexão (Reflection Models): técnica que compara um modelo arquitetural disponibilizado pelo arquiteto de software com o código-fonte implementado;
· Linguagens de domínio (Domain Languages): tipo de linguagem com abordagem específica para identificar as violações arquiteturais. Linguagens de domínio são específicas para um domínio de negócio, por exemplo:
MATLAB: linguagem para programação de matrizes;
MAPLE: linguagem para matemática simbólica;
SQL: linguagem para banco de dados relacionais.
Como falado por De Silva & Balasubramaniam et. al.,
Essas abordagens, que incluem ferramentas, técnicas e processos, são principalmente classificadas em três categorias gerais que tentam minimizar, prevenir e reparar a erosão da arquitetura. Dentro dessas categorias amplas, cada abordagem é subdividida refletindo as estratégias de alto nível adotadas para combater a erosão. Estas são a conformidade com a arquitetura orientada a processos, gerenciamento de evolução de arquitetura, aplicação de projeto de arquitetura, arquitetura para implementar integração, técnicas de auto-adaptação e restauração de arquitetura, consistindo em recuperação, descoberta e reconciliação (DE SILVA; BALASUBRAMANIAM, 2012, tradução livre). 
Desse modo, é possível ver que vários diferentes tipos de abordagens foram propostos para auxiliar na solução de problemas e cenários relacionados à erosão de arquitetura de software.
DICA
Um dos melhores livros sobre arquitetura é o livro Software Architecture in Practice – 2nd Edition,  do escritor Len Bass. Este livro também é conhecido como Yellow Book Of Software Architecture.
Conectores arquiteturais
Dentro do universo da arquitetura de software, temos a necessidade de realizar “conexões” com elementos externos a fim de garantir o fluxo da informação e das ações necessárias para que o sistema funcione corretamente. Neste contexto, utilizamos o conceito de conectores, que tem por definição a capacidade de realizar a transferência de controle e dados entre as partes.
Com a utilização de conectores, os arquitetos podem realizar a integração entre elementos heterogêneos que fazem parte da macroarquitetura da solução, onde estas peças externas podem ter sido desenvolvidas em tecnologias e momentos diferentes. Desta forma, os conectores permitem aos arquitetos e ao sistema coexistirem com componentes legados e em diferentes tecnologias. 
Algumas características que indicam o que os conectores podem fazer são:
· Realizar a distribuição de requisições entre componentes específicos;
· Realizar o broadcast de notificações de eventos para componentes que possam escutar esse tipo de evento;
· Realizar o controle transacional de processamento entre as partes, utilizando bloqueio síncrono (por meio de notificações de ACK) ou não;
· Roteamento das requisições entre as partes;
· Realizar o enriquecimento do contexto da requisição por meio de regras previamente definidas.
Basicamente, podemos definir os conectores em simples e compostos. Os conectores simples normalmente fazem sua lógica utilizando dutos de comunicação simples entre as partes. Alguns componentes podem enriquecer esses conectores, introduzindo alguns controles de dados simples aos dutos. Os conectores mais complexos podem introduzir uma arquitetura interna para processamento e armazenamento mais elaborados da informação. Um exemplo que se pode utilizar é um conector de balanceamento de carga, que realiza o balanceamento da carga com base na utilização dos componentes.
Os conectores simples disponibilizam apenas um tipo de serviço/funcionalidade, enquanto os conectores compostos podem agrupar outros conectores e componentes, proporcionando um poder maior para cumprir os requisitos e necessidades mais complexas. Os componentes compostos, devido à sua estrutura e complexidade, são disponibilizados como bibliotecas, ou até mesmo como frameworks.
Um conector, independentemente de qual tipo, deve disponibilizar suas características por meio de serviços de interação.
Os tipos disponíveis são:
Clique nos botões para saber mais
Comunicação
–
Disponibilizam suporte à transmissão de dados entre componentes, utilizando blocos simples para a interação entre os componentes. Como exemplo podemos citar os dados simples de mensagens textuais e os resultados de processamento computacional;
Coordenação
–
Neste tipo de serviço, o suporte à transferência de controle entre os componentes é disponibilizada e a thread de execução é “trocada” entre as partes. As chamadas RPC são um exemplo deste tipo de serviço;
Conversão
–
Serviços deste tipo permitem a interação entre componentes heterogêneos que, inicialmente, não são compatíveis. As incompatibilidades são normalmente causadas por uma divergência no tipo, na ordem ou na estrutura dos dados. Um exemplo clássico é a utilização de conectores ETL ou de conectores que realizam wrappers de componentes legados.
Facilitação
–
Este tipo de serviço visa realizar a mediação entre os componentes que fazem a interação. Em alguns cenários, essa mediação é necessária para aprimorar a gestão dos dados e reduzir a interdependência entre as partes. Exemplo disto são os conectores de balanceamento de carga e de controle de processos.
Dependendo da complexidade da ação e interação entre os componentes, a combinação de mais de um conector (ou serviço) pode ser necessária.
Depois de entendermos os tipos de serviços disponibilizados pelos conectores, é necessário entendermos como os conectores são classificados da forma como os serviços são realizados. Os tipos utilizados para esta classificação são:
· Procedure call;
· Event;
· Data Access;
· Linkage;
· Stream;
· Arbitrator;
· Adaptor;
· Distributor.
// Procedure call
Estes tipos de conectores, realizam a modelagem do fluxo de controle entre os componentes (coordenação) e possuem a capacidade de realizar a transferência de dados entre os componentes através de parâmetros e valores de retorno (comunicação).
São conhecidos como call-backs e são amplamente utilizados em componentes que realizam Remote Procedure Call (RPC). 
Diagrama 1. Conectores Procedure Call. Fonte: TAYLOR, 2009, p. 166. (Adaptado).
// Events
Neste caso, o fluxo de controle é disparado por um evento ocorrido, que é identificado pelo conector que irá gerar mensagens para os ouvintes. Este tipo de conector realiza a criação de “conectores virtuais”, que são gerados dinamicamente.
Diagrama 2. Conectores Event. Fonte: TAYLOR, 2009, p. 167. (Adaptado).
// Data access
Neste tipo de conector, temos a possibilidade de interagir com componentes de armazenagem de dados (Data Stores), de forma temporária ou persistente.
Diagrama 3. Conectores Data Access. Fonte: TAYLOR, 2009, p. 168. (Adaptado).
// Linkage
São conectores utilizados para unir componentes e mantê-los durante toda a duração de sua interação. Estes conectores criam canais de comunicação que são utilizados por outros tipos e conectores (facilitação).
Diagrama 4. Conectores Linkage. Fonte: TAYLOR, 2009, p. 169. (Adaptado).
// Stream
Este tipo de conector é utilizado quando há a necessidade de se transferir uma grande quantidade de dados ou em transmissões de soluções cliente-servidor para entregar informações entre as partes. Um exemplo clássico são os pipes do UNIX e os sockets de comunicação TCP/UDP.
Diagrama 5. Conector Stream. Fonte: TAYLOR, 2009, p. 170. (Adaptado).
// Arbitrator
Este conector tem a capacidade de resolver situações de conflito (facilitação) e de controle de fluxo (comunicação) em cenários nos quais a presença e outras partes são conhecidas por um componente, mas não há garantias sobre o estado das partes. Um exemplo comum deste tipo de conector são os balanceadores de carga e escalonamento.
Diagrama 6. Conector Arbitrator. Fonte: TAYLOR, 2009, p. 171. (Adaptado).
// Adaptor
Esse tipode conector tem uma finalidade muito clara: permitir a interação entre componentes que, originalmente, não são compatíveis ou não foram desenhados para serem convertidos. Um exemplo de conectores do tipo adapter são os frameworks ORM, ou os componentes de ETL em service bus.
Diagrama 7. Conector Adaptor. Fonte: TAYLOR, 2003, p. 171. (Adaptado).
// Distributor
Estes tipos de conectores possuem a característica de mapeamento dos paths presentes na interação e o roteamento de informações de objetos durante o processo de comunicação (facilitação). Normalmente, esse tipo de conector coexiste com outros conectores, como Stream e/ou Procedure Call, para enriquecer seu funcionamento. Um exemplo clássico deste tipo de conector são os serviços de DNS.
Visões arquiteturais
Dentro do contexto da arquitetura de software, é necessário existir uma forma de representar a arquitetura para que ela seja compreensível e explicável. Pensando nessa necessidade, a arquitetura de software foi dividida em visões arquiteturais.
Cada visão arquitetural irá lidar com um conjunto específico de informações e interesses envolvidos no processo de desenvolvimento. Basicamente, pode-se dizer que essas visões da arquitetura tentam capturar as principais decisões ligadas ao design, apresentando sua decomposição em componentes e a interação entre eles, utilizando conectores e formulários úteis.
A UML
Atualmente, existem algumas opções para representar essas visões a fim de facilitar sua confecção e compartilhamento entre as partes. Uma das formas mais utilizadas para isso é a linguagem de modelagem chamada UML (Unified Modeling Language).
A UML é uma linguagem de notação que expressa, por meio de diagramas, as informações que se deseja expor. Esses diagramas podem ter relação entre si ou não. A UML é uma linguagem baseada nos princípios da orientação por objetos e utiliza essa prerrogativa para expor seus diagramas.
A seguir, é possível conhecer alguns conceitos fundamentais do mundo orientado a objetos e utilizados na UML:
Clique nos botões para saber mais
Objetos
+
Classes
+
Abstração
+
Encapsulamento
+
Herança
+
Polimorfismo
+
A UML se tornou um ativo importante na arquitetura de software, pois ela permite expressar as diversas visões de uma arquitetura por meio de diagramas.
Os principais diagramas que podemos utilizar da UML e os tipos de modelagem suportados são:
· Modelagem Estrutural
Diagrama de Classes – nesse diagrama são definidas as estruturas de classes e seus relacionamentos. Além disso, são mapeadas as propriedades e os métodos associados a cada classe a fim de melhorar o entendimento das informações. É o diagrama mais utilizado e serve como guia para outros diagramas. 
Diagrama de Objetos – este diagrama funciona como um snapshot de um momento de execução de um determinado processo do software e seus valores armazenados pelos objetos. Ele funciona como um complemento do diagrama de classes.
Diagrama de Implantação – este tipo de diagrama traz para a arquitetura uma visão estrutural sobre as necessidades físicas (hardware) necessárias para o software. Com ele, conseguimos obter informações como protocolos utilizados, servidores e outros.
Diagrama de Componente – este tipo de diagrama proporciona uma visão geral dos componentes que serão implementados pelo sistema e como eles serão distribuídos em sua estrutura. Ele está fortemente ligado ao tipo de tecnologia utilizado. Além disso, ele apresenta a visão das interações entre os componentes e suas estruturas.
· Modelagem Comportamental
Diagrama de casos de uso – o diagrama de casos de uso é, normalmente, um dos primeiros diagramas a serem construídos, pois são realizados nas fases de levantamento e análise de requisitos.  Eles representam a visão das interações entre cenários e atores do sistema e servem de base para vários outros diagramas.
Diagrama de sequência – o diagrama de sequência é a representação temporal de um conjunto de eventos ocorridos em um determinado cenário do sistema, normalmente expresso inicialmente em um caso de uso. 
Diagrama de colaboração – esse diagrama é um complemento do diagrama de sequência onde sua maior preocupação é com os eventos de vinculação entre os componentes e os tipos de mensagens trocadas entre eles durante o processo.
Diagrama de atividade – esse diagrama tem como principal objetivo mapear e demonstrar, de forma direta e simples, todos os passos necessários para que uma atividade do sistema seja executada.
Diagrama de estado – esse diagrama tem o foco é um determinado componente do sistema e visa demonstrar o conjunto de estados pelo qual este componente passa dentro do sistema. 
TIPOS DE VISÃO E SUAS UTILIZAÇÕES
Uma das formas mais conhecidas de se representar as visões de uma arquitetura de software é a 4+1. Ela foi, inclusive, base do processo RUP e é muito utilizada nas definições, nas estruturas arquiteturais e nas documentações provenientes da criação da arquitetura de software. 
Este modelo de visão arquitetural, como o próprio nome indica, é dividido em 4 tipos de visões: lógica, processo, desenvolvimento e física. O que representa o “+1” é uma visão de sumarização, que ilustra de forma objetiva os cenários mais importantes e críticos, baseando-se em pequenos conjuntos de casos de uso. Essa última visão é muito utilizada para validação do design arquitetural e para um entendimento macro dos cenários mais críticos e/ou importantes.
Figura 2. Visão "4+1".
// Visão lógica (Logical View)
Essa visão tem como objetivo primário representar os requisitos comportamentais. Em outras palavras, ela basicamente mostra os serviços fornecidos aos usuários finais. Os arquitetos de software ou os analistas de projetos decompõem o sistema em abstrações, baseando-se no conjunto de domínio do problema ou cenário. Essa visão, além de auxiliar na análise de negócio (funcional), permite a identificação de elementos dentro do projeto que podem se tornar comuns ao longo do ciclo de vida do sistema.
Os diagramas UML associados a esta visão incluem:
· Diagrama de classes;
· Diagrama de estado;
· Diagrama de objetos;
· Diagrama de sequência;
· Diagrama de colaboração/comunicação.
// Visão de processo (Process View)
Essa visão permite o entendimento de como os processos do sistema interagem com os componentes existentes, sua resiliência e tolerância a falhas. Neste tipo de visão, é possível identificar as possíveis threads de execução de um cenário e ver a interação entre o possíveis caminhos que irão ser executados.
O diagrama UML que representa a visão de processo é o diagrama de atividades.
// Visão de desenvolvimento (Development View)
Essa visão foca na organização modular da aplicação, na qual os elementos são pequenas partes do software, podendo ser bibliotecas ou subsistemas, que poderão ser desenvolvidos por múltiplos profissionais. Além disso, ela proporciona a capacidade de avaliar o custo de produção, monitoração do progresso e visão da reutilização de código.
Um dos diagramas que faz parte desta visão é o diagrama de componentes.
// Visão física (Physical View)
Essa visão possui uma integração maior com os requisitos não funcionais e com as características relacionadas à qualidade do software, mapeando os vários elementos identificados nas outras visões em nós de processamento.
O diagrama UML que representa a visão deste processo é o diagrama de implantação.
Padrões arquiteturais de software
Os padrões arquiteturais são soluções já comprovadas e comumente utilizadas para problemas recorrentes no desenvolvimento de uma arquitetura de um software. Vários destes padrões arquiteturais se tornaram verdadeiros coringas nas mãos dos arquitetos de software, mas é importante analisar bem a aderência do padrão escolhido junto ao cliente.
A escolha de um padrão arquitetural está entre uma das primeiras decisões a serem tomadas quando se está desenvolvendo uma arquitetura de software. Os padrões arquiteturais auxiliam o arquiteto de softwares a definir:
· O possível conjunto de subsistemas;
· Suas responsabilidades;
· Suas regras de relacionamentoe integração.
Mesmo que os padrões se provem úteis e essenciais, eles não são responsáveis pela definição completa da arquitetura de um sistema. Os padrões devem ser utilizados como templates, moldes a serem utilizados e refinados no desenvolver da arquitetura da solução em questão. Dentre estes refinamentos, podemos incluir novos componentes e integrações, novos padrões de projetos e modelos de conversação.
Ao se escolher um padrão de projeto, deve-se levar em consideração os seguintes fatores:
· Requisitos não funcionais;
· Perfil do sistema a ser desenvolvido;
· Expertise da equipe de desenvolvimento.
Neste caso, se torna interessante mapear algumas perguntas iniciais para auxiliar no entendimento. Alguns exemplos de perguntas são:
· Quais são os principais requisitos não funcionais de acordo com a visão do cliente?
· Qual a expertise técnica do time de desenvolvedores e testadores?
· O sistema possui muitas interações externas?
· O sistema deve suportar multithreading ou processamento distribuído?
Atualmente, temos uma gama interessante de padrões de projeto já concretizados no mercado. A seguir, iremos falar dos principais deles e como eles podem ser úteis no desenvolvimento de uma arquitetura de software.
CLIENTE-SERVIDOR (CLIENT-SERVER)
Este é, provavelmente, o padrão mais conhecido dentre todas as opções disponíveis. Este padrão tem como característica a apresentação do relacionamento entre componentes (programas) dentro de uma aplicação. Neste caso, o componente servidor irá expor uma funcionalidade ou um tipo de serviço que será consumido por um ou mais componentes clientes.
Neste tipo de padrão arquitetural, as funcionalidades são abstraídas entre o servidor e o cliente, de forma que o cliente não precisa saber como a funcionalidade é executada no servidor, ele precisa apenas interpretar o retorno da funcionalidade. Normalmente, o cliente e o servidor realizam a troca das mensagens por meio de um processo atômico chamado request-response message pattern.
Um servidor tem a capacidade de suportar múltiplas conexões de vários clientes diferentes, mas isso é limitado pelo poder de processamento do computador/servidor que está hospedando a aplicação server side. Vendo este cenário, é muito comum que o servidor realize o controle da quantidade de clientes que podem interagir com ele, evitando, assim, a exaustão de recursos computacionais para o processamento server side e, posteriormente, a sua indisponibilidade.
ARQUITETURA MULTICAMADAS (MULTILAYERED)
Basicamente, podemos dizer que arquiteturas multicamadas são arquiteturas do tipo cliente-servidor nas quais as camadas de apresentação, aplicação e dados são fisicamente separadas. O uso mais comum e popular deste tipo de arquitetura se aplica em arquiteturas de 3 camadas ou n-camadas.
Aplicações multicamadas se propõem a flexibilizar a criação de arquiteturas com maior propensão de reuso de seus componentes. Com a segregação da aplicação em camadas distintas, os profissionais de desenvolvimento têm a opção de trabalhar as camadas de forma independente, reduzindo o retrabalho em mudanças e implementações realizadas.
Voltando a falar de aplicações que utiliza o padrão de três camadas, um dos pontos importantes que vale a pena ressaltar são as camadas que compõem este tipo de padrão:
Clique nos botões para saber mais
DUTOS E FILTROS (PIPES AND FILTERS)
Esse tipo de padrão de arquitetura é peculiar, pois sua estrutura é composta por uma cadeia de elementos de processamento, posicionados de forma que a saída de cada componente seja a entrada do próximo. Esse perfil de montagem traz a característica de rede para o processamento dos dados para quem adota este tipo de padrão arquitetural.
Ainda neste tipo de padrão, os dutos (pipes) são os responsáveis por transportar a informação, enquanto os filtros (filters) se responsabilizam pelo processamento desta informação e a direcionam para os próximos dutos do fluxo.  Desta forma, conseguimos identificar que esse padrão é interativo e que a regra essencial é que um duto não pode se conectar a outro duto diretamente, apenas por meio dos filtros.
A utilização desse tipo de padrão vem muito em conjunto com a ideia de segregação das funcionalidades de um sistema. Neste caso, a ideia é particionar processos mais complexos, em pedaços menores, em sequências de processamentos mais simples e reduzidos, conectados pelos dutos e filtros do padrão de arquitetura tratado nesta parte.
MICROSSERVIÇOS (MICROSERVICES)
Este padrão de arquitetura vem sendo cada vez mais comentado e adotado por arquitetos e empresas devido à sua estrutura. Neste tipo de arquitetura, ocorre a quebra da aplicação em uma coleção de serviços de baixo acoplamento, possibilitando serviços de granulagem fina e com protocolos de comunicação leves. Uma das grandes vantagens deste tipo de abordagem é que a quebra em serviços menores aumenta a modularidade do sistema. Dessa forma, a manutenção se torna mais fácil, os serviços são mais fáceis de entender e a adoção de implantação contínua se torna mais fácil.
Ao se trabalhar com a arquitetura de microsserviços, é importante termos alguns guidelines para auxiliar no caminho a ser trilhado na utilização deste padrão arquitetural. Algumas ações importantes que podem ser consideradas são:
· Tenha certeza que os serviços foram desenhados e desenvolvidos de modo que eles possam ser implantados individualmente,
· Cada serviço desenvolvido deve atender apenas a uma funcionalidade,
· A comunicação entre os microsserviços deve ser feita, preferencialmente, por servidores que não armazenam estado (stateless).
Como todo padrão arquitetural, a estrutura de microsserviços possui suas vantagens e desvantagens. No quadro 1 é possível ver um comparativo entre estas características.
ASSISTA
Assista à apresentação de Martin Fowler, Microservices, sobre o padrão arquitetural dos microsserviços e veja quais são suas principais características e como é sua estrutura.
ASSISTA
Quadro 1. Vantagens e desvantagens dos microsserviços.
ARQUITETURA ORIENTADA A SERVIÇOS (SOA)
Esse tipo de arquitetura é baseado no conceito em que serviços são disponibilizados para outros componentes por meio de um protocolo de comunicação sobre uma rede. Os princípios básicos deste tipo de arquitetura é sua independência de provedor tecnológico e de produtos. Um serviço nada mais é do que uma unidade de implementação relacionada a uma funcionalidade que pode ser acessada remotamente e atualizada de forma independente.
Basicamente, um serviço implementado neste padrão arquitetural, possui quatro propriedades, que seguem as definições da especificação SOA (BELL, 2008):
· O serviço representa uma funcionalidade de negócio específica com uma resposta específica;
· O serviço deve ser autocontido;
· Para os clientes que o consome, sua estrutura é uma caixa-preta;
· Internamente, ele pode ser composto de outros serviços para atender a funcionalidade requisitada.
Figura 3. Estrutura SOA. Fonte: Shutterstock. Acesso em: 11/07/2019.
O padrão arquitetural SOA visa promover a integração entre três partes fundamentais no desenvolvimento de software: o negócio, a tecnologia e os serviços. A adoção deste padrão pode trazer alguns benefícios, tais como:
· Agilidade no atendimento de novas features a serem desenvolvidas;
· Maior flexibilidade para a adequação às mudanças que podem ocorrer;
· Redução dos custos, pois facilita a manutenibilidade;
· Aumenta a possibilidade de reuso de componentes e serviços.
BARRAMENTO DE SERVIÇOS (ESB)
Dentro do padrão arquitetural SOA, uma das partes importantes é o ESB (Enterprise Service Bus). O ESB tem como funcionalidade atuar na intermediação de serviços expostos, provendo conectores e estruturas que permitam vários tratamentos e lógicas nas informações que serão intermediadas por ele, tais como:
· Enriquecimento da informação;
· Roteamento;
· Transformação da informação (muito usado com ETL’s);
· Validações.
Um erro muito comum em relação aos ESBs é associar a sua existência ao SOA ou afirmar que apenas o fato de utilizaro software já utiliza o padrão orientado a serviços. O que ocorre com o barramento é que o mesmo possui em sua origem várias implementações e estruturas que, naturalmente, suportam um conjunto considerável de conceitos e funcionalidades do SOA.
PADRÃO DO QUADRO NEGRO (BLACKBOARD PATTERN)
Este é um tipo de padrão arquitetural que tem sua utilidade muito voltada para problemas nos quais nenhuma solução determinística foi encontrada. Sua utilização é muito comum nas seguintes situações:
· Reconhecimento de fala necessário;
· Identificação de tráfego em veículos;
· Identificação de cadeias proteicas;
· Interpretação autônoma de sinais de sonar.
PADRÃO PONTO-A-PONTO (PEER-TO-PEER PATTERN)
Este padrão representa uma arquitetura distribuída que tem como princípio a quebra de tarefas ou atividades de trabalho entre os pontos da estrutura. Os pontos (peers) possuem um perfil de equivalência estrutural e são todos participantes da aplicação. Desse modo, é formada uma rede de nós de um ponto para outro.
Uma rede ponto-a-ponto é definida a partir da noção de que todos os pontos devem ser equivalentes e devem funcionar como clientes e servidores ao mesmo tempo. Nesse sentido, o direcionamento da comunicação entre os nós se torna bidirecional.
Figura 4. Estrutura Peer-to-Peer. Fonte: Shutterstock. Acesso em: 10/07/2019.
A Figura 4 mostra que os nós dentro da rede ponto-a-ponto interagem entre si com pares, executando o papel de cliente e servidor ao mesmo tempo. Uma coisa importante dentro desta arquitetura é a forma como os nós são localizados. Neste contexto, é criada uma camada virtual de rede, chamada overlay network, sobre a camada física, e os nós usam uma estratégia de links para se identificarem e realizarem a comunicação. Esta overlay network é usada para indexar os nós e para descobrir os pontos disponíveis.
MODELO MVC (MVC PATTERN)
A arquitetura MVC (Model-View-Controller) é um padrão arquitetural que tem como maior característica definir uma clara separação entre as camadas de visão do usuário, controle e modelos utilizados. Como padrão arquitetural, seu uso é mais frequente no desenvolvimento de interfaces de usuários mais elaboradas, permitindo maior controle entre as informações internas utilizadas e as representações expostas ao usuário.
Basicamente, esta abordagem realiza a separação destes componentes em três tipos:
· Modelo (Model): são as regras de negócio, lógicas, funções e os dados da aplicação.
· Visão (View): representação das visões para o usuário, como tabelas, diagramas ou formulários.
· Controlador (Controller): lógica responsável pela mediação entre a camada de visão e a camada de modelo. Neste ponto, podemos ter ações de transformação e enriquecimento de dados.
Diagrama 9.  Estrutura MVC.
Clique nos cards para saber mais
• Fácil manutenção, pois o MVC pode gerenciar várias visões com o mesmo modelo;
• A aplicação é mais escalável, pois a separação flexibiliza isso;
• Aumenta a reutilização do código;
• Possibilita o desenvolvimento em paralelo e reduz a interdependência entre as partes;
• Melhor performance, pois a separação de camadas reduz o peso de processamento e a quantidade de código nas camadas.
• Maior tempo para navegar no código e entender as ligações;
• Maior especialização do profissional;
• Com o aumento do tamanho do software e sua complexidade, aumenta também a complexidade da estrutura MVC, bem como dos arquivos relacionados a ele e suas pastas.
Por fim, várias tecnologias implementam este modelo arquitetural em seus frameworks, a fim de aproveitar seus benefícios e características. Alguns exemplos são:
· Java
    • Java Server Faces (JSF)
    • Spring MVC
    • VRaptor
· .NET
    • ASP.NET MVC
· PHP
    • Laravel
    • Symfony
Agora é a hora de sintetizar tudo o que aprendemos nessa unidade. Vamos lá?!
SINTETIZANDO
Nesta unidade, tivemos a oportunidade de conhecer um pouco mais sobre as ferramentas de arquitetura de software com o objetivo de utilizá-las de forma efetiva e concisa no desenvolvimento de soluções.
Aprendemos que a arquitetura é dividida em algumas partes e que suas visões possibilitam trabalhar diferentes pontos de vista em relação a sua estrutura e seudesign. Também vimos que dentro da arquitetura de software, há a opção de utilizar diferentes tipos de conectores para realizar a integração e a otimização de comunicação entre os diferentes tipos de componentes que compõem o ecossistema arquitetural.
Entendemos que é necessário formas produtivas e simples de expressar as ideias e definições necessárias na arquitetura. Para isto, foi apresentado a UML, linguagem de notação que dispõe de uma série de diagramas realizadores deste trabalho de tradução das informações em um formato mais fácil e compreensível.
Ainda dentro deste contexto arquitetural, foi possível visualizar a importância de se saber os tipos de padrões arquiteturais mais comuns.
Assim sendo, vimos como a arquitetura de software é importante dentro do ciclo de vida de concepção e desenvolvimento de software e que sua utilização agrega, cada vez mais, qualidade e vantagens em sua adesão.