Software Architecture in Practice: O que é Arquitetura de Software? (Parte 1)

O que é e o que não é Arquitetura de Software

Existem muitas definições para arquitetura de software. Uma simples busca na internet nos traz facilmente um massivo número delas. Analisemos uma que nos agrada: A arquitetura de software é um conjunto de estruturas necessárias para racionalizar um sistema, compreendidas por elementos de software, as relações entre eles e suas propriedades. Observemos algumas implicações dessa definição:

Arquitetura é um conjunto de estrutura de software

Sistemas de software são composto por muitas estruturas, e uma única estrutura por si só não pode reivindicar o status de arquitetura. Sendo assim, existem três categorias de estruturas arquiteturais:

1. estrutura de decomposição modular: Módulos são rotulados com específicas responsabilidades computacionais e são a base das atribuições do trabalho de programação. Além disso, são estruturas estáticas cujo foco é a divisão de funcionalidades do sistema para implementação por parte dos times.
2. estrutura de Componentes-e-conectores (C&C): Estruturas dinâmicas cujo o foco é a interação entre elementos em tempo de execução para realizar funções do sistema.
3. estrutura de alocação: Descreve o mapeamento da estrutura de software para descrever sua entrega nos diversos ambientes a nível organizacional, de desenvolvimento, de instalação e execução.

Embora o software inclua um grande fornecimento de estruturas, nem todas são arquiteturais. Por exemplo, o conjunto de linhas de um código-fonte que contém a letra “z”, ordenadas pelo tamanho da mais curta para a mais longa, é uma estrutura de software; mas isso não é nada interessante e muito menos é uma estrutura arquitetural. Ou seja:

Uma estrutura é arquitetural se suportar a racionalização sobre o sistema e suas propriedades. Isso inclui funcionalidades alcançadas pelo sistema, a tolerância mediante a falha, a dificuldade para realizar mudanças específicas, a responsividade às requisições de usuários etc.

Arquitetura é uma abstração

Arquitetura de software antes de tudo é uma abstração de um sistema que seleciona certos detalhes e suprime outros. Em sistemas modernos, elementos interagem com outros intermediados por interfaces que divide os detalhes desses elementos em partes públicas e privadas.

Arquitetura está preocupada com esse lado público da divisão; os detalhes privados dos elementos — detalhes que tendem a ser implementações internas — não são arquiteturais. Esta abstração é essencial para domar a complexidade de um sistema . Afinal, não queremos e nem podemos lidar com todas as complexidades o tempo todo.

Todo sistema possui uma Arquitetura

Numa visão mais trivial, o sistema por sí só é um elemento singular — uma incompreensível e provavelmente uma manifestação arquitetural não usual, mesmo assim uma arquitetura.

Apesar de todo sistema ter uma arquitetura, isso não significa que ela é conhecida por alguém. Talvez seus criadores tenham partido, não possua documentação alguma, o código-fonte tenha sido perdido, restando apenas os binários de execução.

Isso revela a diferença entre a arquitetura do sistema e a representação desta arquitetura. Uma vez que uma arquitetura existe independente de sua descrição ou especificação, isso reforça a importância da documentação da arquitetura e da reconstrução da arquitetura.

Arquitetura inclui comportamento

O comportamento de cada elemento é parte da arquitetura na medida que um comportamento pode ser usado para pensar sobre o sistema. Este comportamento corporificado demonstra como elementos interagem com outros e qual, claramente, faz parte de nossa definição arquitetural.

Isso explica porque caixas e linhas desenhadas num papel por si só não são de fato arquitetura. Ao olhar para o nome das caixas (database, GUI, execução, etc), um leitor pode evocar imagens de funcionalidades e comportamentos desses elementos.

Mas isso não significa que o exato comportamento de cada elemento precisa ser documentado em todas as circunstâncias, e sim que a extensão de um comportamento que pode influenciar o sistema pode ser considerada e documentada como arquitetura de software.

Nem toda Arquitetura é uma boa Arquitetura

Uma arquitetura pode permitir ou impedir um sistema de alcançar seus requisitos comportamentais, de qualidade e de ciclo de vida. Supondo que não aceitamos teste e erro como a melhor maneira de escolher uma arquitetura para um sistema, isso levanta a importância do design de arquitetura e avaliação de arquitetura.

Concluindo

Nesse primeiro artigo introduzimos uma definição de Arquitetura de Software e ressaltamos alguns conceitos importantes como “estrutura arquitetural” e suas categorias. Além disso, refletimos sobre o caráter abstrato de uma arquitetura de software; o porquê todo sistema possui uma arquitetura; que arquiteturas de software podem incluir comportamento; e que nem toda arquitetura é uma boa arquitetura.

Espero que você tenha gostado e que continue acompanhando os próximos posts dessa série. Até a próxima…