0.6 Técnicas de design arquitetural  (Page 2/10)

Um problema recorrente ao se aplicar a estratégia top-down é o de quando parar . Afinal, podemos notar que o arquiteto poderia seguir indefinidamente adicionando detalhes à arquitetura até que o design deixe de ser um modelo para ser o próprio sistema. Para definir o ponto de parada do processo de adição de detalhes, o arquiteto deve avaliar se o nível atual de abstração contém ou não informações suficientes para guiar o time de desenvolvimento na implementação dos requisitos de qualidade do software. Devemos ainda observar que os dois extremos da condição de parada podem trazer desvantagens: se as informações presentes na arquitetura são insuficientes, a liberdade proporcionada ao design de baixo nível pode resultar numa solução que não implementa os requisitos de qualidade esperados. Por outro lado, se são excessivas, a arquitetura pode: (1) custar mais tempo do que o disponível para ser projetada; (2) desmotivar o time de desenvolvimento, por “engessar” o design de baixo nível pela grande quantidade de restrições; e (3) ser inviável, por ter sido projetada sem o conhecimento que muitas vezes só pode ser obtido durante o processo de implementação Devemos nos lembrar que alguns requisitos de qualidade não são completamente conhecidos em etapas iniciais do ciclo de desenvolvimento. Por exemplo, a tolerância a faltas ou o tempo de recuperação podem ser muito dependentes da solução de design de baixo nível. .

A outra estratégia, mais usada por quem possui experiência no domínio do problema, é a bottom-up . Esta estratégia consiste em definir elementos arquiteturais básicos e com maior nível de detalhe (serviços ou funções de infraestrutura, por exemplo), e compor serviços presentes em maiores níveis de abstração a partir desses elementos. A experiência no domínio do problema é necessária justamente na definição dos elementos mais detalhados, ou seja, experiência é necessária para definir o nível de abstração mais baixo que servirá de ponto de partida do processo de design. Nesta estratégia, detalhes excessivos ou insuficientes no nível mais baixo de abstração trazem as mesmas desvantagens já apresentadas quando falamos sobre o ponto de parada da estratégia top-down .

Separação de preocupações

A separação de preocupações é a divisão do design em partes idealmente independentes. Entre estas partes, podemos citar aspectos funcionais e não-funcionais do sistema. Os aspectos funcionais, como é de se esperar, são o que o sistema é capaz de fazer. Já os não-funcionais são os aspectos de qualidade do sistema, como desempenho, segurança, monitoração, etc. A separação dos diferentes aspectos permite que cada uma das partes seja um problema de design a ser resolvido de forma independente, permitindo maior controle intelectual por parte do arquiteto, uma vez que agora ele só precisa se focar em um aspecto da arquitetura de cada vez.

Vale observar que a separação completa das diferentes preocupações (ou dos diferentes aspectos) da arquitetura do software é o caso ótimo da aplicação deste princípio, mas não é o caso comum. Isto ocorre porque, como já vimos anteriormente, diferentes funcionalidades e qualidades do software se relacionam entre si. Portanto, apesar de ser vantajoso pensar na solução de design de cada aspecto separadamente, o arquiteto deve também projetar a integração desses aspectos. Esta integração é fundamental por dois motivos. O primeiro, mais óbvio, é que o software é composto por seus aspectos trabalhando em conjunto – e não separadamente. Já o segundo motivo é que a própria integração influencia nas diferentes soluções de design dos aspectos do software. Por exemplo, aspectos de armazenamento devem estar de acordo com aspectos de segurança do software, ou aspectos de desempenho devem trabalhar em conjunto com aspectos de comunicação ou mesmo localização dos elementos da arquitetura.