Qual das respostas abaixo está correta quando quero afirmar que são padrões arquiteturais

Você já parou para pensar o que se passa por trás de uma tela de login de um software? Em frações de segundos a página é capaz de absorver as informações que foram digitadas no campo de email e senha, realizar a validação e entregar uma resposta positiva ou negativa. 

Esse processo só se torna possível quando existe um padrão de arquitetura de software adequado. Embora exista vários que podem ser utilizados, o MVC é o mais conhecido e empregado entre os desenvolvedores profissionais.

Se você quer saber como melhorar a usabilidade do seu software e otimizar o tempo de resposta entre o banco de dados e a interface de usuário, continue a leitura que vamos explicar todos os detalhes neste artigo. 

Apesar de muitas pessoas considerarem essa sigla como um padrão de design de interface, na verdade ele é um padrão de arquitetura de software responsável por contribuir na otimização da velocidade entre as requisições feitas pelo comando dos usuários. 

Com quase 50 anos de formulação, a arquitetura MVC é dividida em três componentes essenciais: Model, Controller e View. 

Um dúvida muito recorrente na programação é se no processo de desenvolvimento pode ter apenas esses 3 componentes ou se é possível acrescentar mais alguns. A resposta é sim para a possibilidade de inserir uma camada extra. Essa sequência de códigos pode ser alterada conforme a necessidade do projeto. 

Mas um código com muitas camadas se torna muito confuso e por isso, o ideal é manter o padrão original. A seguir vamos explicar os conceitos e aplicações dos componentes que acompanham essa arquitetura de software.

Essa classe também é conhecida como Business Object Model (objeto modelo de negócio). Sua responsabilidade é gerenciar e controlar a forma como os dados se comportam por meio das funções, lógica e regras de negócios estabelecidas. 

Ele é o detentor dos dados que recebe as informações do Controller, válida se ela está correta ou não e envia a resposta mais adequada. 

A camada de controle é responsável por intermediar as requisições enviadas pelo View com as respostas fornecidas pelo Model, processando os dados que o usuário informou e repassando para outras camadas. 

Numa analogia bem simplista, o controller  operaria como o ‘’maestro de uma orquestra’’  que permite a comunicação entre o detentor dos dados e a pessoa com vários questionamentos no MVC. 

Essa camada é responsável por apresentar as informações de forma visual ao usuário. Em seu desenvolvimento devem ser aplicados apenas recursos ligados a aparência como mensagens, botões ou telas. 

Seguindo nosso processo de comparação o View está na linha de frente da comunicação com usuário e é responsável transmitir questionamentos ao controller e entregar as respostas obtidas ao usuário. É a parte da interface que se comunica, disponibilizando e capturando todas as informação do usuário.

Tudo começa com a interação do usuário na camada View. A partir daí o controlador pega essa informações e envia para o Model que fica responsável por avaliar aqueles dados e transmitir uma resposta. 

O controlador recebe essas respostas e envia uma notificação de validação daquela informação para a camada visão, fazendo com a mesma apresente o resultado de maneira gráfica e visual.

Todo esse processo leva em consideração as regras de negócio aplicadas na construção de todo projeto.

Muitos bootcamps de programação ensinam esse padrão de arquitetura de software por alguns benefícios que justificam o MVC como uma das mais escolhidas no processo de desenvolvimento. Esses benefícios são: 

• Segurança: O controller funciona como uma espécie de filtro capaz de impedir que qualquer dado incorreto chegue até a camada modelo. 
• Organização: Esse método de programação permite que um novo desenvolvedor tenha muito mais facilidade em entender o que foi construído, assim como os erros se tornam mais fácil de serem encontrados e corrigidos.
• Eficiência: Como a arquitetura de software é dividida em 3 componentes , sua aplicação fica muito mais leve, permitindo que vários desenvolvedores trabalhem no projeto de forma independente.
• Tempo: Com a dinâmica facilitada pela colaboração entre os profissionais de desenvolvimento, o projeto pode ser concluído com muito mais rapidez, tornando o projeto escalável.  
• Transformação: As mudanças que forem necessárias também são mais fluidas, já que não será essencial trabalhar nas regras de negócio e correção de bugs.

Além disso, um software precisa ter estabilidade no processo de comunicação entre seus elementos de maneira dinâmica para que a experiência do usuário não seja prejudicada. 

Essa arquitetura de software pode ser utilizada no programação web, mobile ou desktop e ela pode ser implementada através de diversos frameworks de Java como o Spring MVC ou Play Framework ou também em frameworks mais modernos de Ruby como Ruby on Rails.

Cada um tem suas diferenças, portanto o ideal é que o programador entenda os recursos disponíveis no processo de desenvolvimento e adote o mais adequado a sua necessidade. 

Quer aprender e não sabe por onde começar? Se liga nesses conteúdos que vão te ajudar a definir os próximos passos para alavancar sua carreira!:

O MVC funciona como um padrão de arquitetura de software que melhora a conexão entre as camadas de dados, lógica de negócio e interação com usuário. Através da sua divisão em três componentes, o processo de programação se torna algo mais simples e dinâmico.

Por padrão existem a camada Model, Controller e View que deram origem a sigla dessa arquitetura de software mais utilizado entre os desenvolvedores.  

Algumas empresas podem até cobrar o conhecimento de determinados frameworks para sua aplicação no dia-a-dia, por isso é interessante que o candidato participe de bootcamps que explorem o assunto de maneira adequada, a fim de melhorar a curva de aprendizado de quem quer explorar a área. 

Desse modo, o ideal é escolher um curso que seja líder de mercado e tem uma ótima avaliação pelos usuários. A Le Wagon prepara sua mente para o desenvolvimento das habilidades essenciais para alcançar o sucesso. Escolha sua cidade e faça sua inscrição em nosso curso de Desenvolvimento Web e comece sua jornada de conhecimento. 

Deseja saber mais sobre os nossos bootcamps?

Baixe o programa do curso

A arquitetura de software é um conceito de fácil compreensão e que a maioria dos engenheiros entende de modo intuitivo, especialmente quando se tem um pouco de experiência. No entanto, é difícil defini-lo com precisão. Em particular, é difícil desenhar uma linha bem definida entre o design e a arquitetura - a arquitetura é um aspecto do design que se concentra em alguns recursos específicos.

Em An Introduction to Software Architecture, David Garlan e Mary Shaw sugerem que a arquitetura de software é um nível de design voltado para problemas: "Além dos algoritmos e das estruturas de dados da computação; o design e a especificação da estrutura geral do sistema emergem como um novo tipo de problema. As questões estruturais incluem organização total e estrutura de controle global; protocolos de comunicação, sincronização e acesso a dados; designação de funcionalidade a elementos de design; distribuição física; composição de elementos de design; escalação e desempenho; e seleção entre as alternativas de design." [GAR93]

Mas há mais a arquiteturar do que apenas a estruturar; o artigo Working Group on Architecture da IEEE define isso como "o conceito de nível mais alto de um sistema em seu ambiente" [IEP1471]. Também abrange o "ajuste" à integridade do sistema, às restrições econômicas, às preocupações estéticas e ao estilo. Ele não se limita a um enfoque interno, mas leva em consideração o sistema como um todo em seu ambiente de usuário e de desenvolvimento, ou seja, um enfoque externo.

No RUP, a arquitetura de um sistema de software (em um determinado ponto) é a organização ou a estrutura dos componentes significativos do sistema que interagem por meio de interfaces, com elementos constituídos de componentes e interfaces sucessivamente menores.

Descrição de Arquitetura

Para falar e tirar conclusões sobre a arquitetura do software, primeiro defina uma representação de arquitetura, uma forma de descrever aspectos importantes de uma arquitetura. No RUP, esta descrição é capturada no Documento de Arquitetura de Software.

Visualizações Arquiteturais

Escolhemos representar a arquitetura de software em várias visualizações arquiteturais. Cada visualização arquitetural trata de um conjunto específico de interesses, específicos dos envolvidos no processo de desenvolvimento: usuários, designers, gerentes, engenheiros de sistema, mantenedores e assim por diante.

As visualizações capturam as principais decisões de design estruturais, mostrando como a arquitetura de software é decomposta em componentes e como os componentes são conectados por conectores para produzir formulários úteis [PW92]. As opções de design devem estar associadas aos Requisitos, tanto funcionais quanto suplementares, e a outras restrições. Mas essas opções, por sua vez, impõem restrições adicionais aos requisitos e às futuras decisões de design em um nível inferior.

Um Conjunto Típico de Visualizações Arquiteturais

A arquitetura é representada por várias visualizações arquiteturais diferentes, que, em sua essência, são extrações que ilustram os elementos "arquiteturalmente significativos" dos modelos. No RUP, você inicia em um conjunto típico de visualizações, denominado "modelo de visualização 4+1" [KRU95]. Ele é composto de:

As visualizações arquiteturais estão documentadas em um Documento de Arquitetura de Software. Você pode prever visualizações adicionais para expressar várias questões especiais: visualização da interface com o usuário, visualização de segurança, visualização de dados e outras. No caso dos sistemas simples, você pode omitir algumas das visões contidas no modelo de visão 4+1.

Foco Arquitetural

Embora as visões acima possam representar todo o design de um sistema, a arquitetura se preocupa somente com alguns aspectos específicos:

• A estrutura do modelo - os padrões organizacionais, por exemplo, Divisão em Camadas.
• Os elementos essenciais - casos de uso críticos, classes principais, mecanismos comuns, etc., em oposição a todos os elementos presentes no modelo.
• Alguns cenários-chave mostrando os principais fluxos de controle em todo o sistema.
• Os serviços para capturar a modularidade, os recursos opcionais e os aspectos de linha de produto.

Basicamente, as visualizações arquiteturais são abstrações ou simplificações do design inteiro, em que características importantes são ressaltadas, deixando os detalhes de lado. Essas características serão importantes quando os seguintes aspectos estiverem em discussão:

• Evolução do sistema - passagem para o próximo ciclo de desenvolvimento.
• Reutilização da arquitetura, ou de partes dela, no contexto de uma linha de produto.
• Avaliação das qualidades suplementares, como desempenho, disponibilidade, portabilidade e segurança.
• Atribuição do trabalho de desenvolvimento a equipes ou subcontratantes.
• Decisões sobre a inclusão dos componentes desenvolvidos internamente e adquiridos prontos para serem usados.
• Inserção em um sistema mais amplo.

Padrões Arquiteturais

Os padrões arquiteturais são formulários prontos que solucionam problemas arquiteturais recorrentes. Uma estrutura arquitetural ou uma infra-estrutura arquitetural (middleware) é um conjunto de componentes em que você pode construir um determinado tipo de arquitetura. Muitas das maiores dificuldades arquiteturais devem ser resolvidas na estrutura ou na infra-estrutura, geralmente, direcionadas a um domínio específico: comando e controle, departamento de informática, sistema de controle, etc.

Exemplos de Padrões de Arquitetura

[BUS96] agrupa padrões arquiteturais de acordo com as características dos sistemas em que eles são mais aplicáveis, com uma categoria tratando de problemas gerais de estruturação. A tabela mostra as categorias apresentadas em [BUS96] e os padrões nelas contidos.

Duas dessas categorias são apresentadas mais detalhadamente aqui, a fim de esclarecer essas idéias. Para obter uma abordagem completa, consulte [BUS96]. Os padrões são apresentados neste formulário amplamente utilizado:

• Nome do padrão
• Contexto
• Problema
  • Impõe a descrição de vários aspectos problemáticos que devem ser considerados
• Solução
  • Fundamentos
  • Contexto resultante
  • Exemplos

Nome do Padrão

Camadas

Contexto

Um sistema grande que requer decomposição.

Problema

Um sistema que deve manipular problemas em diferentes níveis de abstração.  Por exemplo: problemas de controle de hardware, problemas de serviços comuns e problemas específicos do domínio. Seria extremamente indesejável escrever componentes verticais que lidem com essas questões em todos os níveis. O mesmo problema teria que ser manipulado (possivelmente de modo inconsistente) várias vezes em diferentes componentes.

Força

• Peças do sistema devem ser substituídas.
• Alterações efetuados nos componentes não devem ser irregulares.
• Responsabilidades similares devem ser agrupadas juntas.
• Tamanho dos componentes - pode ser necessário decompor os componentes complexos.

Solução

Estruture os sistemas em grupos de componentes que formem camadas umas sobre as outras. Faça com que as camadas superiores utilizem os serviços somente das camadas abaixo (nunca das camadas acima). Tente não utilizar serviços que não sejam os da camada diretamente abaixo (não ignore camadas, a menos que as camadas intermediárias somente incluam componentes de passagem).

Exemplos:

1. Camadas Genéricas

Uma arquitetura estritamente em camadas estabelece que os elementos de design (classes, pacotes, subsistemas) utilizem apenas os serviços da camada abaixo deles.  Os serviços podem incluir identificação de erros, acesso ao banco de dados e outros. Ela contém mecanismos mais palpáveis, em oposição às chamadas brutas em nível de sistema operacional documentadas na camada inferior.

2. Camadas de Sistema de Negócios

O diagrama acima mostra um outro exemplo de divisão em camadas, onde há camadas verticais específicas de aplicativo e camadas horizontais de infra-estrutura. Observe que a meta é ter "chaminés" muito curtas de negócios e alavancar a freqüência entre aplicativos.  Do contrário, é provável que várias pessoas resolvam o mesmo problema, possivelmente de maneira diferente.

Consulte a Diretriz: Divisão em Camadas para obter uma discussão adicional sobre este padrão.

Nome do Padrão

Quadro-negro

Contexto

Um domínio em que nenhuma abordagem fechada (algorítmica) para resolver um problema é conhecida ou viável. Exemplos são os sistemas de IA, o reconhecimento de voz e os sistemas de inspeção.

Problema

Vários agentes de resolução de problemas (agentes de conhecimento) devem cooperar para resolver um problema que não pode ser resolvido por agentes individuais. Os resultados do trabalho de cada agente devem estar acessíveis a todos os outros agentes. Assim, eles poderão avaliar se podem ou não contribuir para encontrar uma solução e divulgar os resultados de seus trabalhos.

Força

• A seqüência em que os agentes de conhecimento podem contribuir para resolver o problema não é determinista e talvez dependa das estratégias de solução de problemas.

• A entrada de diferentes agentes (resultados ou soluções parciais) pode ter diferentes representações.

• Os agentes não sabem da existência um do outro diretamente, mas podem avaliar as contribuições divulgadas de cada um deles.

Solução

Vários Agentes de Conhecimento têm acesso a um data store compartilhado denominado Quadro-negro. O quadro-negro fornece uma interface para inspecionar e atualizar seu conteúdo. O módulo/objeto Controle ativa os agentes seguindo algumas estratégias. Após a ativação, um agente inspeciona esse quadro-negro para ver se ele pode contribuir na resolução do problema. Se o agente determinar que é possível contribuir, o objeto Controle poderá permitir que os agentes coloquem sua solução parcial (ou final) no quadro.

Exemplo:

Este exemplo mostra a visão estrutural ou estática modelada através da UML. Ele será parte de uma colaboração parametrizada, que será restringida a parâmetros reais para instanciar o padrão.

Estilo Arquitetural

Uma arquitetura de software, ou somente uma visualização arquitetural, pode ter um atributo chamado estilo arquitetural, que reduz o conjunto de formulários que podem ser escolhidos e impõe um determinado grau de uniformidade à arquitetura. O estilo pode ser definido por um conjunto de padrões, ou pela escolha de componentes ou conectores específicos que funcionarão como os tijolos básicos da construção. Em um determinado sistema, alguns estilos podem ser capturados como parte da descrição arquitetural em um guia de estilo de arquitetura-fornecido por meio do produto de trabalho Diretrizes Específicas do Projeto no RUP. O estilo desempenha um papel vital na compreensão e integridade da arquitetura.

Plantas Arquiteturais

A representação gráfica de uma visualização arquitetural é denominada planta arquitetural. Nas várias visualizações descritas acima, as plantas são compostas pelos seguintes diagramas da Unified Modeling Language [UML01]:

O Processo de Arquitetura

No RUP, a arquitetura é basicamente um resultado do fluxo de trabalho de análise e design. Como o projeto restabelece esse fluxo de trabalho a cada iteração, a arquitetura se desenvolve e torna-se refinada e aprimorada. Como cada iteração inclui a integração e o teste, a arquitetura é bastante sofisticada pelo tempo que o produto é liberado. Esta arquitetura é o foco principal das iterações da fase de Elaboração, no final da qual a arquitetura normalmente serve como linha de base.