O que é Arquitetura de Software (segundo o Application Architecture Guide da Microsoft)

Olá.

Existe um grande equívoco pairando no mercado a respeito de Arquitetura de Software e o Papel do Arquiteto de Software em uma equipe de desenvolvimento.

Alguns destes equívocos são baseados no mal-entendimento de alguns conceitos, outros baseados em mal-conceitos (ou má-padronização) de alguns entendimentos (se é que é certo falar assim). Mesmo entre os grandes arquitetos da comunidade, existem algumas divergências de opiniões sobre a definição da arquitetura e do papel do arquiteto, mas é certo dizer que, no geral, existe um consenso a respeito do essencial.

O Application Architecture Guide da Microsoft faz uma enumeração das definições mais coerentes e tenta relacioná-las.

O trecho a seguir é tradução do livro.

O que é Arquitetura de Software?

Arquitetura de Software é frequentemente definida como a estrutura ou estruturas de um sistema. Diversos experts conhecidos da indústria tem expandido esta definição com as informações baseadas nas decisões que precisam ser tomadas relacionadas à arquitetura. Aqui nós vemos um pouco de algumas definições formais de arquitetura, e então teremos uma visão mais informal.

Arquitetura segundo Kruchten, Booch, Bittner e Reitman

Philippe Kruchten, Grady Booch, Kurt Bittner e Rich Reitman derivaram e redefiniram a definição de arquitetura baseada na obra de Mary Shaw e David Garlan (Shaw and Garlan 1996). A definição deles é:

Arquitetura de Software engloba todas as decisões significantes sobre a organização de um sistema de software, inclusive:

• Escolha dos elementos estruturais e suas interfaces pelos quais o sistema será formado.
• Comportamento como especificado na colaboração entre estes elementos.
• Composição dos elementos estruturias e comportamentais em subsistemas maiores.
• Estilo arquitetônico que orienta esta organização.

Arquitetura de software também envolve  questões de funcionalidade, usabilidade, resiliência (escalabilidade), performance, reusabilidade, compreensividade, constraints tecnológicas e econômicas (esta nós conhecemos bem), trade-offs (problemas causados pela resolução de outros problemas) e estética.

Arquitetura segundo Fowler

Em seu livro, Patterns of Enterprise Application Architecture (Padrões de Arquitetura para Aplicações Empresariais), Martin Fowler destaca alguns temas comumente recorrentes quando explica arquitetura:

•  
  • O mais alto nível de quebra do sistema em suas partes.
  • As decisões que são difíceis de mudar.
  • Existem muitas arquiteturas em um sistema.
  • O que for arquitetonicamente significante pode mudar durante o tempo de vida de um sistema
  • No fim, arquitetura se resume ao que quer que seja importante.

Arquitetura segundo Bass, Clements e Kazman

Em Software Architecture in Practice (Arquitetura de Software na Prática) – Segunda Edição, Bass, Clements e Kazman definem arquitetura da seguinte forma:

A arquitetura de um software de um programa ou sistema computacional é a estrutura ou estruturas de um sistema, que inclui os elementos de software, as propriedades externamente visíveis destes elementos, e os relacionamentos entre eles. Arquitetura é responsável pelas interfaces públicas dos elementos. Seus detalhes privados (detalhes que tenham a ver somente com a implementação interna) não fazem parte da arquitetura.

Por que precisamos de Arquitetura?

Como em qualquer outra estrutura complexa, o software precisa ser construído sobre uma fundação sólida. Falhar em considerar cenários-chave, falhar no design de prolemas comuns ou falhar na consideração das consequências em longo-prazo de decisões-chave pode colcoar toda a aplicação em risco. Ferramentas e plataformas modernas ajudam a simplificar as tarefas de construção de aplicações, mas elas não substituem a necessidade do haver um design da sua aplicação baseado nos seus cenários específicos. Os riscos expostos por uma arquitetura pobre podem levar a um software instável, incapaz de suportar requisições de negócio, ou poderiam ainda impedir a aplicação de funcionar quando publicada no ambiente de produção.

Considere as seguintes questões de auto-nível quando estiver pensando sobre a arquitetura de software:

• Como a aplicação será publicada em produção?
• Como os usuários usarão a aplicação?
• Quais são os atributos de qualidade exigidos, tais como segurança, performance, concorrência, internacionalização e configuração?
• Quais são as tendências arquitetonicas que podem impactar na sua aplicação agora ou depois dela ser publicada?

Arquitetura x Design

De acordo com Martin Fowler em “Quem precisa de um arquiteto?”:

…Os desenvolvedores que estão trabalhando em um projeto tem um entendimento compartilhado do design do sistema. Este entendimento compartilhado é chamado de “Arquitetura”. Este entendimento inclui como o sistema é dividido em componentes e como os componentes interagem através de interfaces. Estes componentes são normalmente compostos de componentes menores, mas a arquitetura inclui somente os componentes e interfaces que são entendidos por todos os desenvolvedores.

Portanto, a arquitetura foca em como os componentes e as interfaces são usadas ou interagem com outros componentes. Escolher estruturas de dados ou algoritmos a serem implementados dentro do componente não é uma questão de arquitetura. Invés de usar regras rápidas e difíceis para distinguir arquitetura de design, faz mais sentido combinar estas duas áreas. Em alguns casos, as decisões são claramente mais arquitetônicas por natureza. Em outros casos, as decisões são mais sobre o design, e como elas te ajudam a visualizar esta arquitetura.

Objetivos do Usuário, do Negócio e do sistema

Os sistemas deveriam ser arquitetados considerando os objetivos do Usuário, do sistema e do negócio. Para cada uma destas áreas se destacam cenários-chave, atributos de qualidade importantes (por exemplo, manutenabilidade), satisfatores-chave e dissatisfatores-chave. Quando possível, desenvolva e considere medidas que te ajudam a medir o sucesso de cada uma destas áreas.

Figura 1 - Objetivos do Usuário, do Negócio e do Sistema

Trade-offs são semelhantes entre cada área, e um ponto de equilíbrio precisa ser encontrado. Por exemplo, responsividade pode ser o maior objetivo do usuário, mas o admnistrador do sistema não vai investir no hardware exigido para atender a demanda o 100 porcento do tempo de execução. Um ponto de equilíbrio precisa existir para atender o objetivo em somente 80 porcento do tempo.

Os objetivos da Arquitetura

A Arquitetura da aplicação procura construir uma ponte entre os requisitos de negócio e os requisitos técnicos, entendendo os casos de uso, e então encontrando maneiras de implementar estes casos de uso no software. O objetivo da arquitetura é identificar os requisitos que impactam na estrutura da aplicação. Uma boa arquitetura reduz os riscos de negócio com a construção de uma solução técnica. Um bom design é flexível o suficiente para ser capaz de lidar com as mudanças naturais que podem surgir com o passar do tempo em tecnologia de Hardware e Software, bem como em cenários e requisitos de usuário. Um arquiteto deve considerar o impacto global das decisões de design, os trade-offs herdados entre atributos de qualidade (tais como performance e segurança), o os trade-offs necessários para atender requisitos de Usuário, de Negócio e de Sistema.

Tenha em mente que a arquitetura deveria:

• Expôr a estrutura do sistema mas esconder os detalhes de implementação.
• Compreender todos os cenários de Casos de uso.
• Tentar identificar as preocupações de vários stakeholders.
• Lidar com ambos os requisitos: funcionais e de qualidade.

–

Para quem quiser ler mais, o Application Architecture Guide da Microsoft está disponível para Download gratuito no site do Patterns and Practices.

Aqui no blog eu irei postar mais a respeito de Arquitetura de Software e o Papel do Arquiteto.

Até logo.