Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.124 seguidores
Pré-visualização50 páginas
Uma vez que não especi\ufb01ca nenhuma funcionalidade,
esse pode ser considerado um requisito não-funcional.
Por outro lado, poderíamos deixar essa evidente car-
acterística de requisito não-funcional um pouco mais
turva se adicionarmos um pouco mais de detalhes a
ele:
(RF-01): O sistema deve permitir aos usuários que
criptografem suas mensagens usando as chaves
públicas dos destinatários.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
133
Agora, esse requisito seria melhor classi\ufb01cado como
funcional, uma vez que especi\ufb01ca uma função do sis-
tema, apesar do atributo de qualidade exibido pelo
software ao \ufb01nal do desenvolvimento será o mesmo:
segurança, mais especi\ufb01camente con\ufb01dencialidade das
mensagens enviadas.
Já quando mencionamos que o tipo do sistema pode in\ufb02uenciar
em como classi\ufb01camos um requisito, basta apenas lembrarmos
dos sistemas de tempo-real. Neles, a corretude do comporta-
mento do sistema não depende só do resultado lógico da função,
mas também quando esse resultado é obtido. Portanto, uma
resposta cedo ou tarde demais pode estar tão incorreta quanto
uma resposta logicamente errada.
Exemplo 6.5
Em um sistema de informação, consideramos o requi-
sito não-funcional:
(RNF-01): A busca por nome deve retornar os resul-
tados em no máximo 100 milissegundos.
Já em um sistema de controle de voo \ufb02y-by-wire, de-
vemos considerar o requisito a seguir como funcional,
uma vez que respostas que não respeitam o intervalo
de tempo especi\ufb01cado são tão inúteis quanto a falta de
resposta dos sensores (podem causar a queda do avião):
(RF-01): Novas amostras de dados dos sensores da
aeronave devem ser obtidas a cada 20 milisse-
gundos.
Apesar disso, vale notar que ambos os requisitos presentes no
Exemplo 6.5 ditam que tanto o sistema de informação quanto
o sistema \ufb02y-by-wire devem exibir o atributo de qualidade de-
sempenho, mesmo que em graus diferentes.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
134
CHAPTER 6. ATRIBUTOS DE
QUALIDADE
6.1.2 Con\ufb02itos entre requisitos
Como requisitos de software têm impacto em um ou mais atrib-
utos de qualidade, pode acontecer de impactarem em atributos
relacionados a outros requisitos. Quando isso ocorre, o impacto
pode resultar em reforço do atributo ou em con\ufb02ito.
Podemos perceber que não surgem grandes problemas quando
dois ou mais requisitos reforçam o mesmo atributo de quali-
dade. A\ufb01nal, caso isso ocorra, o design da solução que atenda
a um dos requisitos afetará apenas positivamente o design da
solução que atenda aos outros requisitos.
Apesar do caso de requisitos que se reforçam não ser muito
comum, podemos ilustrá-lo com requisitos que afetam à segu-
rança do software, mais precisamente autenticidade e con\ufb01den-
cialidade:
Exemplo 6.6
Se temos um sistema de mensagens instantâneas com
os seguintes requisitos:
(RNF-01): O sistema deve prover meios de autenticar
os seus usuários.
(RNF-02): Uma mensagem enviada a um usuário não
pode ser lida a não ser pelo destinatário.
Podemos observar que os requisitos RNF-01 e RNF-02
se relacionam, uma vez que afetam a alguns aspectos
de segurança do sistema. Eles se reforçam visto que é
possível encontrarmos uma solução para RNF-01 que
facilite RNF-02 e vice-versa. A solução no caso é a
utilização criptogra\ufb01a de chave pública: tanto ela pode
ser usada para autenticação de usuários quanto pode
ser usada para encriptação de mensagens.
Por outro lado, requisitos con\ufb02itantes são mais comuns e adi-
cionam di\ufb01culdade durante o design das soluções. Isso ocorre
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
135
porque a solução para um requisito con\ufb02itante afeta negativa-
mente outro requisito. Assim, o design do software terá que
considerar diversos trade-o\ufb00s a \ufb01m satisfazer melhor aos requi-
sitos mais importantes, já que atender a todos de forma ótima
não é possível.
Se adicionamos alguns requisitos de usabilidade ao Exem-
plo 6.6, esses novos requisitos certamente afetarão negativa-
mente à solução apresentada. Isso ocorre porque é comum
que soluções de segurança afetem aos requisitos de usabili-
dade, visto que essas soluções adicionam conceitos não famil-
iares aos usuários (por exemplo, chaves criptográ\ufb01cas) ou adi-
cionam mais passos para que os usuários realizem suas tarefas
(por exemplo, inserir login e senha).
6.1.3 Expressando requisitos não-funcionais
Grande parte do trabalho de um arquiteto consiste em pro-
jetar sistemas que devem satisfazer requisitos não-funcionais.
No entanto, a Engenharia de Requisitos é limitada quanto a
métodos de análise e derivação de requisitos não-funcionais.
Essa limitação, muitas vezes, obriga ao arquiteto a trabalhar
com requisitos que carecem de métricas e valores-alvo. Isso
di\ufb01culta o processo de design, uma vez que desconhecer requi-
sitos é o mesmo que desconhecer os objetivos do design. Por
este motivo, recomenda-se aos arquitetos que sempre busquem
por requisitos que possuam valores e métricas bem de\ufb01nidos
e, desta maneira, conheçam e possam medir os objetivos e o
sucesso de seu design.
Todavia, nem sempre é possível trabalhar com requisitos bem
de\ufb01nidos, uma vez que encontramos alguns problemas ao
expressá-los. Os principais motivos da di\ufb01culdade de expressar
requisitos não-funcionais são os seguintes:
\u2022 Alguns requisitos simplesmente não são conhecidos em
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
136
CHAPTER 6. ATRIBUTOS DE
QUALIDADE
etapas iniciais do ciclo de desenvolvimento. Por exemplo,
a tolerância a faltas ou o tempo de recuperação pode ser
muito dependente da solução de design.
\u2022 Alguns requisitos, como alguns relacionados à usabil-
idade, são muito subjetivos, di\ufb01cultando bastante a
medição e o estabelecimento de valores-alvo.
\u2022 E, por \ufb01m, há os con\ufb02itos entre requisitos. Como já foi
apresentado, requisitos podem in\ufb02uenciar 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
\ufb01m do desenvolvimento, este exiba os atributos de qualidade
esperados pelos stakeholders.
6.2 Atributos de qualidade
Apesar de a\ufb01rmarmos que o software possui requisitos não-
funcionais
5
a serem atendidos, é comum dizermos que o soft-
ware exibe atributos de qualidade que atendem aos requisitos
em questão. Portanto, atributos de qualidade estão mais rela-
cionados 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:
\u2022 capacidades ou restrições de suas funções. Por exemplo,
tempo de resposta de uma determinada função ou ca-
pacidade de execução de certa quantidade de chamadas
simultâneas;
5
Alguns autores preferem o termo requisitos de qualidade.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
137
\u2022 características não diretamente relacionadas às suas
funções. Por exemplo, usabilidade ou adoção de padrões
para interoperabilidade; ou ainda
\u2022 características relacionadas ao ciclo de desenvolvimento.
Por exemplo, testabilidade ou mesmo a capacidade de
facilitar o desenvolvimento por múltiplos times geogra\ufb01-
camente distribuídos.
De\ufb01nição 6.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í\ufb01ca ou de um conjunto de funções do soft-