Arquitetura de Software e Design – Objetivos, Princípios e Algumas Considerações-Chave

Software Architecture

Uma das definições correntes de Arquitetura de “software” apresenta-a como um conjunto de decisões significativas sobre a organização de um sistema, incluindo a seleção dos elementos estruturais e as suas “interfaces”. Refere-se também ao comportamento entre estes elementos, à sua integração em subsistemas mais amplos e ao estilo arquitetónico que subjaz a uma organização.

A Arquitetura de aplicação de “software” é o processo de definir uma solução bem estruturada, que tenha em conta os requisitos técnicos e operacionais da empresa, melhorando vetores como o desempenho, a segurança e a gestão. O seu principal foco reside na forma como os maiores elementos e componentes de uma aplicação são utilizados ou interagem com outros.

Já a seleção de estruturas de dados e de algoritmos, bem como os detalhes de implementação de componentes individuais, são visados pelo “design”, embora por vezes os âmbitos do “design” e da Arquitetura se sobreponham.

Antes de desenvolver qualquer “software”, existem algumas questões fundamentais em que ponderar, nomeadamente:

  • Como é que os utilizadores do sistema vão interagir com ele?
  • Como é que a aplicação pode ser inserida na produção e gerida?
  • Quais são os seus requisitos não funcionais, tais como segurança, desempenho e configuração?
  • Como é que a aplicação pode ser concebida para que seja flexível e sustentável ao longo do tempo?
  • Quais são as tendências arquiteturais que possam ter impacto sobre ela, no momento ou após a implementação?

Sendo esperada uma evolução contínua, o sistema deve ser construído para mudar, e não para durar; deve ser planeado de modo a reduzir os riscos; os modelos e as visualizações devem ser utilizados como ferramenta colaborativa.

Quanto aos princípios do “design”, identificamo-los, em síntese, como:

  • Separação de interesses: Minimização de pontos de interação entre os conjuntos de recursos, para se atingir elevada coesão e baixa acoplagem.
  • Princípio da Única Responsabilidade: Cada componente ou módulo deve ser independente em si e responsável por uma característica específica ou funcionalidade.
  • Não-repetição: A implementação de qualquer funcionalidade deve ocorrer num único local e não ser repetida.
  • Princípio do Menor Conhecimento: Cada componente ou objeto não deve conhecer os detalhes internos dos restantes.