Avaliar se uma arquitetura possui riscos para certos atributos de

qualidade, ou seja, não os satisfazem. Avaliações de arquitetura de

software podem ser usadas em um ou mais estágios do processo de desenvolvimento de software, podendo ser empregadas para comparar e identificar pontos fortes e fracos de diferentes situações arquiteturais no processo de desenvolvimento de software. Podem, também, ser utilizadas para avaliação de sistemas já ativos, antes que manutenções ou novas melhorias sejam implementadas (MATTSSON; GRAHN; MÅRTENSSON, 2006).

Ainda segundo Mattsson; Grahn e Mårtensson (2006), os métodos de avaliação de arquitetura de software podem ser divididos em quatro categorias:

 Baseados em experiência: este método se baseia na experiência prévia ou conhecimento do assunto dos desenvolvedores ou consultores;

 Baseados em simulação: este método de avaliação depende da implementação de componentes da arquitetura de software a ser avaliada. A simulação pode ser usada para a avaliação de requisitos de qualidade;

 Modelagem matemática: baseiam-se em provas ou métodos matemáticos para, principalmente, avaliações em atributos como desempenho ou confiabilidade dos componentes da arquitetura. Modelagens matemáticas podem ser combinadas com simulações para estabelecer estimativas mais precisas de desempenho dos componentes do sistema;

 Baseados em cenários: métodos baseados em cenários tendem a avaliar requisitos de qualidade específicos, caracterizando situações que forçam a descrição desses requisitos de qualidade. Os cenários das situações desejadas são usados para se abordar uma vasta gama de requisitos de qualidade, documentando-se as respostas obtidas. Bachmann et al. (2005) destaca a importância do uso de cenários na avaliação de soluções arquiteturais, avaliações essas baseadas em cenários de atributos de qualidade. Brito et al. (2009) afirma que cenários comportamentais possibilitam a realização de análises de trade-offs entre os atributos de qualidade, com o objetivo de identificar quais atributos de qualidade influenciam diretamente as metas de negócio, podendo, por conta disto, ser priorizados durante a avaliação da

arquitetura e, posteriormente, durante a construção do sistema. Bass; Clements e Kazman (2012) afirmam que há dois tipos de cenários:

 Cenários gerais: são independentes do sistema a ser avaliado, podendo pertencer a qualquer sistema. Um dos usos de cenários gerais é habilitar a comunicação entre participantes sobre requisitos de qualidade;

 Cenários concretos: são caracterizações dos cenários gerais, e são específicos para um sistema em particular. Cada cenário concreto pode ser significativo no projeto de software e detalhes de resposta para estímulos são suficientes para possibilitar a execução de testes em relação a um determinado requisito não funcional.

Esta divisão em categorias não busca elencar se existe superioridade de uma categoria em relação às outras, mesmo porque métodos que nelas se baseiam têm aplicações diferentes, visando à avaliação de um requisito de qualidade específico ou todo um conjunto deles.

Avaliar ou reavaliar uma arquitetura de software é uma forma de se evitar tais problemas e, para que a avaliação possa acontecer, devem-se envolver dois grupos de pessoas, que seriam a equipe de avaliação e os interessados na arquitetura. Desse modo, os três principais objetivos de uma avaliação de arquitetura de software são (NASCIMENTO NETO, 2012):

 Identificar e refinar os atributos de qualidade;

 Identificar e refinar as decisões arquiteturais do projeto;

 Avaliar as decisões arquiteturais para determinar se satisfazem aos atributos de qualidade.

Há vários métodos de avaliação de arquitetura de software. O estudo de Babar; Zhu e Jeffery (2004) apresenta alguns dos principais métodos que são comparados segundo um conjunto de critérios.

Métodos de avaliação de arquitetura podem ser aplicados em duas fases do projeto, segundo Clements; Kazman e Klein (2002):

Em estágios iniciais do projeto: é realizada quando existem apenas

fragmentos da descrição arquitetural de forma que questionários, checklists e métodos baseados em cenários são mais usados para avaliação porque, nessa fase, não há informação tangível suficiente disponível para a coleta de medições ou para simular o comportamento do software. As bases principais desse tipo de avaliação são a experiência dos desenvolvedores e cenários baseados em requisitos que estão nos documentos de requisitos;

Em estágios finais do projeto: é realizada em estágios mais tardios do

processo de desenvolvimento, quando há ao menos um projeto detalhado disponível, no qual métricas mais concretas possam ser coletadas, o que significa que técnicas de métricas arquiteturais são usadas para avaliar a arquitetura de software com respeito a um ou mais atributos de qualidade.

Devem-se usar técnicas de avaliação pelo menos nas fases iniciais e finais para acompanhar o controle de qualidade do software. Por meio dessas avaliações, busca-se evidenciar que os requisitos de qualidade foram considerados e implementados na arquitetura.

O resultado final de uma avaliação de arquitetura de software é um documento cuja forma e conteúdo podem variar, mas que deve responder a duas questões essenciais: (1) se a arquitetura está adequada para o projeto para o qual foi projetada, e (2) qual de duas ou mais arquiteturas seria a mais apropriada para o sistema em questão (CLEMENTS; KAZMAN; KLEIN, 2002).

2.11 ARCHITECTURE TRADE-OFF ANALYSIS METHOD (ATAM)

Todo projeto, em qualquer disciplina, envolve o conceito de trade-off. Apesar disso, técnicas para otimização dos trade-offs são raramente utilizadas. Decisões arquiteturais geralmente são feitas baseadas em razões não técnicas, como por exemplo: estratégia de negócio, número de usuários que o sistema deve atender, tempo de resposta esperado, restrições de tempo, custo e escopo, etc. Grande parte do trabalho do arquiteto de software está relacionado com a definição e com o projeto de arquitetura que possa atingir os requisitos de qualidade demandados pelo processo de negócio. Para ser significativo, o requisito de qualidade deve ser específico de

como a aplicação deve atingir um determinado objetivo do negócio (GORTON, 2011). Um problema comumente encontrado na documentação de arquitetura de software é o uso de sentenças genéricas, como por exemplo: “a aplicação deve ser escalável”. Essa sentença, além de ser imprecisa, pode suscitar diferentes interpretações, pois nesse sistema hipotético, a escalabilidade está relacionada às conexões simultâneas feitas pelo usuário? Ou refere-se a escalabilidade do volume de dados gerenciado por esta aplicação? Ou ainda a implantação para uma base maior de usuários? Ou a todas as três alternativas? Sem a elaboração precisa, a interpretação de sentenças como essa são deixadas no campo da intuição (CLEMENTS; KAZMAN; KLEIN, 2002). A definição de como a escalabilidade deve ser suportada no sistema em questão é crucial do ponto de vista arquitetural, dado que diferentes soluções podem ser construídas de acordo com o que o processo de negócio necessita. Uma sentença mais elaborada seria: “deve ser possível escalar a implantação de um parque de inicialmente 100 estações de trabalho, geograficamente distribuídas, para 10.000 estações sem um aumento de esforço e custo para a instalação e configuração”. Essa sentença representa um cenário arquitetural, que além de preciso, é mensurável e já endereça um possível conjunto de táticas e tecnologias que podem ser utilizadas na implementação da arquitetura (CHUNG; NIXON; YU, 1995).

Um método de avaliação de arquitetura que tem como base a utilização de cenários de atributos de qualidade é o ATAM (Architecture Trade-off Analysis Method) (CLEMENTS; KAZMAN; KLEIN, 2002). O método consiste na avaliação de arquitetura baseando-se em requisitos não funcionais. Seu principal objetivo é identificar as consequências de decisões arquiteturais nos atributos de qualidade do sistema, identificando possíveis trade-offs entre esses diferentes atributos. Vale ressaltar que o ATAM não é feito para prover análises precisas, pois o seu propósito é descobrir riscos decorrentes de decisões arquiteturais.

O resultado da análise arquitetural em relação a um determinado requisito não funcional é composto por riscos, não-riscos, pontos de sensibilidade de arquitetura e pontos de trade-off, descritos a seguir (CLEMENTS; KAZMAN; KLEIN, 2002):

 Riscos: decisões de arquitetura que podem provocar efeitos negativos em relação a um determinado atributo de qualidade;

 Não-riscos: decisões de arquitetura que podem provocar efeitos positivos em relação a um determinado atributo de qualidade;

 Pontos de sensibilidade de arquitetura: são propriedades críticas para alcançar um determinado atributo de qualidade. Na área de segurança (security), por exemplo, o nível de confidencialidade em uma rede virtual privada pode apresentar como ponto de sensibilidade a quantidade de bits utilizada na criptografia;

 Pontos de trade-off: são propriedades de uma decisão de arquitetura que afetam mais de um atributo de qualidade. Pontos de trade-off são importantes para a análise da arquitetura, pois devem ser analisados os efeitos de uma determinada decisão em mais de um atributo de qualidade.

Na aplicação do método, é destacada a importância do envolvimento dos participantes durante a geração de cenários de atributo de qualidade, dado que os cenários de qualidade são priorizados em função dos processos de negócio. Em Clements; Kazman e Klein (2002), é citado que a qualidade da avaliação de uma arquitetura de software depende em grande parte da capacidade dos participantes atuarem ativamente na identificação e avaliação cenários de atributos de qualidade mais importantes. O resultado de uma avaliação baseada em cenários de atributos de qualidade depende da seleção dos cenários e de sua relevância para identificar suposições críticas a respeito da arquitetura de software (DOBRICA; NIEMELÁ, 2002).

O método ATAM é composto de nove etapas, detalhadas a seguir, conforme a referência descrita em Software Engineering Institute (2003):