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:
- 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.
- 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.
- 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.
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…
Este é o primeiro artigo de uma série no qual exponho um resumo dos principais conceitos contidos no livro “Software Architecture in Practice” (Bass, Clements e Kazman, 2013–3rd ed.) da SEI SERIES IN SOFTWARE ENGINEERING.