Sistemas são construídos para satisfazer objetivos das organizações. Por sua vez, a arquitetura de software é a ponte entre esses objetivos (abstração) e o sistema resultante (concreto). Esse caminho do abstrato para o concreto pode ser complexo, a boa notícia é que ele é passivo de design, análise, documentação e implementação, através de técnicas que suportam a compreensão do negócio e seus objetivos.

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…


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.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s