Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.123 seguidores
Pré-visualização50 páginas
ware.
Podemos perceber a importância dos atributos de qualidade,
em especial, quando comparamos dois produtos de software
que têm as mesmas funcionalidades, como fazemos no exemplo
a seguir:
Exemplo 6.7
Vamos considerar um projeto para construção de sis-
temas de buscas de sites web chamado Hounder
6
.
Para deixarmos nosso exemplo ainda mais signi\ufb01ca-
tivo em termos de diferenças entre atributos de quali-
dade, vamos considerar um sistema construído usando
o Hounder, mas em que todos os seus módulos exe-
cutam em apenas um servidor. Vamos chamar esse
serviço de busca de HSearch
7
.
Uma vez que o Google Web Search
8
também é um
6
http://hounder.org/ (<http://hounder.org/>)
7
Caso 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
(<http://code.google.com/p/hounder/wiki/5minuteTutorial>)
8
http://www.google.com (<http://www.google.com>)
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
138
CHAPTER 6. ATRIBUTOS DE
QUALIDADE
serviço de busca de web sites, podemos a\ufb01rmar 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 inseri-
das pelo usuário.
Já que ambos os serviços funcionam, percebemos que
ambos atendem ao requisito (RF-01), o que poderia
signi\ufb01car 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 atividades: (a) crawling,
que é a coleta de páginas que servirão de resulta-
dos, (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 com-
putacionais em que executam.
Se compararmos as capacidades de ambos os sistemas,
o HSearch está limitado à capacidade do único com-
putador em que está executando. Isso signi\ufb01ca 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 diver-
sos data centers ao redor do mundo, usando muitos mil-
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
139
hares de processadores simultâneos e, assim, podendo
dividir a execução das três atividades entre esses recur-
sos. Por essa diferença de utilização de recursos, algu-
mas métricas de vários atributos de qualidade, como
tempo de resposta, capacidade de atender a buscas si-
multâ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, dize-
mos que o desempenho do primeiro é melhor. Mas o
desempenho não é diferente apenas em termos de op-
eraçõ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 con-
siderarmos que o Google Web Search realiza um bilhão
de buscas por dia e cada busca dura em torno de 300
milissegundos, pela Lei de Little [67], 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 menciona-
dos. O HSearch é dependente do funcionamento de um
único servidor. Portanto, se esse servidor falhar, todo
o sistema \ufb01cará 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 con\ufb01abilidade ou tolerân-
cia a falhas do Google Web Search é maior que o do
HSearch. As respostas do HSearch são formadas ape-
nas pelo título e pequenos trechos dos web sites que
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
140
CHAPTER 6. ATRIBUTOS DE
QUALIDADE
contêm as palavras-chave. Já o Google Web Search
ajuda ao usuário também mostrando imagens contidas
no site ou mesmo trechos de vídeo, contribuindo assim
para sua usabilidade. Por \ufb01m, citamos também que o
Google Web Search apresenta o atributo de integrabil-
idade, 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, de\ufb01nição de
palavras, busca de sinônimos, entre outros.
É a arquitetura que permite que o software exiba os atributos
de qualidade especi\ufb01cados. Já que a especi\ufb01cação dos atributos
é feita pelos requisitos (normalmente não-funcionais), requisi-
tos e atributos de qualidade partilham diversas características.
Tanto que alguns autores usam ambas as expressões com o
mesmo sentido.
As principais características dos atributos de qualidade são as
seguintes:
\u2022 Atributos de qualidade impõem limites às funcionali-
dades;
\u2022 Atributos de qualidade se relacionam entre si; e
\u2022 Atributos de qualidade podem tanto ser de interesse dos
usuários quanto dos desenvolvedores.
6.2.1 Limites às funcionalidades
Os limites às funcionalidades acontecem da mesma forma que
os requisitos podem restringir ou mesmo impedir funcionali-
dades, pois atributos de qualidade não se manifestam isolados
no ciclo de vida do software, mas in\ufb02uenciam e são in\ufb02uencia-
dos 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
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
141
para implementar essa funcionalidade em outras versões. Isso
é uma limitação na funcionalidade de transmissão de \ufb01lmes em
benefício do atributo de qualidade custo e planejamento. É
também bastante comum encontrarmos sistemas que têm fun-
cionalidades podadas simplesmente porque, se estas existissem,
o software não exibiria os atributos de segurança esperados.
6.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 tam-
bém outros atributos de qualidade. Eis que surgem os trade-
o\ufb00s 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 abstraiam 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 é prejudicada, uma
vez que o usuário deve ser obrigado de lembrar sua senha ou
mesmo ter o \ufb02uxo de ações interrompido para que insira suas
credenciais.
É papel do arquiteto conhecer e resolver os trade-o\ufb00s entre os
atributos de qualidade durante as fases de design e implemen-
tação. Por isso, ao apresentar algumas técnicas para alcance
da qualidade, apresentaremos também quais atributos são in-
\ufb02uenciados positiva e negativamente.
6.2.3 A quem interessa os atributos de quali-
dade
Uma grande gama de atributos podem ser citados. Tanto que,