dem influenciar atributos de qualidade comuns ou relacionados, até fazendo com que requisitos sejam contraditórios.
Mesmo sendo difícil lidar com os requisitos não-funcionais, é obrigação do arquiteto projetar o software de modo que, ao fim do desenvolvimento, este exiba os atributos de qualidade esperados pelos stakeholders.
F.2 Atributos de qualidade
Apesar de afirmarmos que o software possui requisitos não-funcionais4 a serem atendidos,
é comum dizermos que o software exibe atributos de qualidade que atendem aos requisi- tos em questão. Portanto, atributos de qualidade estão mais relacionados aos objetivos já alcançados, enquanto requisitos são os objetivos propostos.
Podemos chamar de atributos de qualidade do software suas propriedades externamente visíveis. Essas propriedades podem se manifestar como:
• capacidades ou restrições de suas funções. Por exemplo, tempo de resposta de uma determinada função ou capacidade de execução de certa quantidade de chamadas si- multâneas;
• características não diretamente relacionadas às suas funções. Por exemplo, usabili- dade ou adoção de padrões para interoperabilidade; ou ainda
• características relacionadas ao ciclo de desenvolvimento. Por exemplo, testabilidade ou mesmo a capacidade de facilitar o desenvolvimento por múltiplos times geografi- camente distribuídos.
Definição F.6. (atributo de qualidade). É uma propriedade de qualidade do software ou de seu ciclo de desenvolvimento, podendo se manifestar como características, capacidades ou restrições de uma função específica ou de um conjunto de funções do software.
F.2 Atributos de qualidade 136 Podemos perceber a importância dos atributos de qualidade, em especial, quando com- paramos dois produtos de software que têm as mesmas funcionalidades, como fazemos no exemplo a seguir:
Exemplo F.7. Vamos considerar um projeto para construção de sistemas de buscas de sites web chamado Hounder5. Para deixarmos nosso exemplo ainda mais significativo em termos
de diferenças entre atributos de qualidade, vamos considerar um sistema construído usando o Hounder, mas em que todos os seus módulos executam em apenas um servidor. Vamos chamar esse serviço de busca de HSearch6.
Uma vez que o Google Web Search7também é um serviço de busca de web sites, podemos
afirmar que ambos os serviços têm o principal requisito funcional em comum:
(RF-01) O sistema deve retornar endereços de web sites que se relacionem às palavras-chave inseridas pelo usuário.
Já que ambos os serviços funcionam, percebemos que ambos atendem ao requisito (RF- 01), o que poderia significar algum grau de equivalência entre os serviços. No entanto, se compararmos como ambos os sistemas atendem a esse requisito, perceberemos que eles são bem diferentes, justamente pela diferença entre os atributos de qualidade que exibem.
Para funcionar, um serviço de busca de web sites deve executar basicamente três ativida- des: (a) crawling, que é a coleta de páginas que servirão de resultados, (b) indexação, que é a organização da informação obtida na atividade de crawling de forma que facilite a busca (principalmente em termos de desempenho), e (c) busca, cujo resultado é a realização do requisito RF-01. Note que as três atividades são I/O bound, ou seja, as atividades têm uso intensivo de entrada e saída. Portanto, elas têm seu desempenho limitado pela capacidade de entrada e saída dos recursos computacionais em que executam.
Se compararmos as capacidades de ambos os sistemas, o HSearch está limitado à capa- cidade do único computador em que está executando. Isso significa que ele executa as três atividades usando o mesmo recurso. Por outro lado, é bem conhecido que a arquitetura do Google Web Search permite que o sistema utilize diversos data centers ao redor do mundo,
5Hounder: http://hounder.org/
6Caso o leitor deseje criar um clone do HSearch, basta seguir o tutorial de cinco minutos presente em http://code.google.com/p/hounder/wiki/5minuteTutorial
F.2 Atributos de qualidade 137 usando muitos milhares de processadores simultâneos e, assim, podendo dividir a execução das três atividades entre esses recursos. Por essa diferença de utilização de recursos, algumas métricas de vários atributos de qualidade, como tempo de resposta, capacidade de atender a buscas simultâneas, tamanho do índice de busca ou tolerância a falhas de hardware serão bem diferentes entre os dois sistemas.
Quando comparamos as bilhões de consultas diárias que o Google Web Search é capaz de realizar com as apenas milhares ou poucos milhões do HSearch, dizemos que o desempenho do primeiro é melhor. Mas o desempenho não é diferente apenas em termos de operações por unidade de tempo, mas também quando comparamos os tempos de resposta para cada operação ou número de usuários simultâneos no sistema. Se considerarmos que o Google Web Search realiza um bilhão de buscas por dia e cada busca dura em torno de 300 milisse- gundos, pela Lei de Little [65], temos cerca de 3500 buscas simultâneas a qualquer momento ao longo da vida do sistema. Já o HSearch só consegue realizar 3,5 buscas simultâneas ao realizar 1 milhão de buscas por dia a 300 milissegundos cada.
Mas há outros atributos que podem ser mencionados. O HSearch é dependente do funcio- namento de um único servidor. Portanto, se esse servidor falhar, todo o sistema ficará fora do ar. Já o Google Web Search é capaz de tolerar falhas de hardware, uma vez que não depende de apenas um servidor para funcionar. Assim, podemos dizer que o grau de confiabilidade ou tolerância a falhas do Google Web Search é maior que o do HSearch. As respostas do HSearch são formadas apenas pelo título e pequenos trechos dos web sites que contêm as palavras-chave. Já o Google Web Search ajuda ao usuário também mostrando imagens con- tidas no site ou mesmo trechos de vídeo, contribuindo assim para sua usabilidade. Por fim, citamos também que o Google Web Search apresenta o atributo de integrabilidade, dado que ele contém diversos serviços além da busca numa mesma interface: entre eles calculadora, previsão do tempo, conversão de medidas, definição de palavras, busca de sinônimos, entre
outros. !
É a arquitetura que permite que o software exiba os atributos de qualidade especificados. Já que a especificação dos atributos é feita pelos requisitos (normalmente não-funcionais), requisitos e atributos de qualidade partilham diversas características. Tanto que alguns auto- res usam ambas as expressões com o mesmo sentido.
F.2 Atributos de qualidade 138 • Atributos de qualidade impõem limites às funcionalidades;
• Atributos de qualidade se relacionam entre si; e
• Atributos de qualidade podem tanto ser de interesse dos usuários quanto dos desenvol- vedores.
F.2.1 Limites às funcionalidades
Os limites às funcionalidades acontecem da mesma forma que os requisitos podem restringir ou mesmo impedir funcionalidades, pois atributos de qualidade não se manifestam isolados no ciclo de vida do software, mas influenciam e são influenciados pelo meio. Por exemplo, para que o SASF tenha um time to market pequeno, ele deve ser lançado inicialmente sem possuir um cliente de streaming para dispositivos móveis, deixando para implementar essa funcionalidade em outras versões. Isso é uma limitação na funcionalidade de transmissão de filmes em benefício do atributo de qualidade custo e planejamento. É também bastante comum encontrarmos sistemas que têm funcionalidades podadas simplesmente porque, se estas existissem, o software não exibiria os atributos de segurança esperados.
F.2.2 Relações entre atributos de qualidade
Como já foi observado, os atributos não existem isoladamente e, por afetarem partes em comum da arquitetura, afetam também outros atributos de qualidade. Eis que surgem os
trade-offs entre os atributos de qualidade. Por exemplo, um sistema mais portável terá seu
desempenho afetado negativamente, pois necessita de mais camadas de software que abs- traiam o ambiente que pode ser mudado. Já no caso do SASF, para se obter um nível de segurança capaz de realizar autorização e autenticação, a usabilidade do software é prejudi- cada, uma vez que o usuário deve ser obrigado de lembrar sua senha ou mesmo ter o fluxo de ações interrompido para que insira suas credenciais.
É papel do arquiteto conhecer e resolver os trade-offs entre os atributos de qualidade durante as fases de design e implementação. Por isso, ao apresentar algumas técnicas para alcance da qualidade, apresentaremos também quais atributos são influenciados positiva e negativamente.
F.3 Modelo de Qualidade 139