A RQUITETURA DE SOFTWARE E REQUISITOS NÃO FUNCIONAIS

A arquitetura de software pode ser vista como uma ferramenta de gerência da complexidade do software, tendo um papel fundamental na satisfação dos requisitos funcionais e não funcionais (JAZAYERI; RAN; LINDEN, 2000).

A arquitetura de software é também um ponto de referência comum para as demais atividades que são executadas após sua definição, pois a arquitetura é a manifestação antecipada das decisões de projeto. Deve-se ocupar de fatores como tempo de desenvolvimento, custo de desenvolvimento e manutenção e das restrições de implementação, enfatizando os atributos de qualidade que o sistema deve ter e medindo-os através de avaliações, visando a satisfação das qualidades necessárias (BASS; CLEMENTS; KAZMAN, 2012).

A arquitetura de software abrange não somente os requisitos funcionais. Alguns requisitos são implícitos nos objetivos do processo de negócio de uma organização, pois considerações do negócio devem ser acomodadas na arquitetura de software. Esses requisitos implícitos englobam os requisitos funcionais que, em suma, relacionam-se com as capacidades do sistema e influenciam a qualidade do sistema resultante (BASS; CLEMENTS; KAZMAN, 2012). Segundo Gorton (2011), os requisitos não funcionais definem como os requisitos funcionais serão atendidos.

Bosch e Molin (1999) definem um método para obtenção da qualidade de arquitetura por meio de transformações sucessivas da arquitetura de software de um sistema realizadas em uma sequência de iterações nas quais avaliam-se os requisitos não funcionais. Baseada na especificação de requisitos de um sistema, que servem de entrada no método proposto, um projeto arquitetural é elaborado considerando os

requisitos funcionais, o que resulta em uma primeira versão do projeto da arquitetura de software do sistema.

Esse projeto é avaliado em relação aos requisitos não funcionais e, para cada um deles, um valor estimado é dado, por meio de técnicas qualitativas ou quantitativas. Compara-se os valores estimados de cada requisito não funcional com os valores da especificação de requisitos.

Se todas as estimativas forem iguais ou superiores às requeridas pelo sistema, o método é finalizado. Caso contrário, inicia-se a etapa de transformação arquitetural. Nesta etapa, definem otimizações para os requisitos não funcionais requeridos pelo sistema. O conjunto de uma ou mais otimizações resultam em uma nova versão do projeto da arquitetura de software, que passa por nova avaliação.

O método é repetido até que que o projeto da arquitetura resultante atenda aos requisitos não funcionais ou até que não seja mais possível otimizar a solução. Esse método, conforme representado na Figura 9, é executado idealmente até que todos os requisitos não funcionais sejam atendidos.

Figura 9 - Método iterativo para projeto de arquitetura de software

Fonte: adaptado de Bosch e Molin (1999)

Entretanto, ao tratar cada atributo de qualidade de forma isolada em uma iteração, não analisando conjuntamente os trade-offs envolvidos nas decisões de arquitetura, o processo de Bosch, embora de simples compreensão, é de difícil execução, podendo consumir muito tempo até que a arquitetura satisfaça a todos os requisitos (GRUNSKE, 2006).

Quando o usuário estabelece os requisitos de um software, em geral, ele se preocupa com as funcionalidades de negócio, pois são estas que atendem diretamente suas necessidades. No entanto, os requisitos não funcionais, ou requisitos intrínsecos, são de fundamental importância para garantir a qualidade do produto de software como um todo, tais como infraestrutura de hardware, software, comunicação e segurança (PINNA, 2004).

Lattanze (2009) considera que a arquitetura de software pode ser definida principalmente em função dos requisitos não funcionais, que por sua vez suportam os requisitos funcionais. Tanto Bass, Clements e Kazman (2012) como Qin; Xing e Zheng

(2008) afirmam que a arquitetura de software reflete as primeiras decisões do projeto que repercutirão em todo o sistema, principalmente nos requisitos de qualidade. Portanto, a arquitetura é um artefato de software que permite representar as características gerais do sistema e analisar e avaliar a qualidade do sistema.

Há um consenso sobre o fato de que os atributos de qualidade de um sistema de software são em grande parte restringidos por sua arquitetura. Como consequência, os requisitos de qualidade mais importantes para o sucesso de um sistema de software devem orientar o projeto da arquitetura de software (BOSCH; MOLIN, 1999).

Usualmente, as necessidades de negócio determinam quais atributos de qualidade devem ser atingidos e, consequentemente, considerados na arquitetura de um sistema de software. Frequentemente a funcionalidade do sistema abrange implicitamente vários requisitos não funcionais. Desse modo, pode-se afirmar que os requisitos de qualidade funcionais e os não funcionais são ortogonais, visto que uma dada funcionalidade pode ser alcançada por vários requisitos não funcionais (BASS; CLEMENTS; KAZMAN, 2012).

Como a arquitetura influencia a qualidade do software, o uso de métricas para avaliação arquitetural é de fundamental importância para avaliar uma arquitetura de software. Definir a qualidade de software de um sistema é equivalente a definir uma lista de atributos de qualidade de software para este sistema e identificar um conjunto de métricas de software associadas.

Dessa forma, a lista desejada de atributos de qualidade deve ser claramente definida, senão a avaliação da qualidade torna-se subjetiva (BROY, 2013). Verifica-se que, sem a devida elaboração, os requisitos de qualidade ficam sujeitos à má interpretação, uma vez que conceito de qualidade é subjetivo. Assim, o uso de métricas de software pode ajudar a reduzir essa subjetividade. O propósito de métricas de software é fazer avaliações por todo o ciclo de vida do software para verificar se os requisitos de qualidade de software estão sendo atendidos. O uso de métricas de software reduz a subjetividade na avaliação e controla a qualidade do software, porque fornece uma base quantitativa para tomar decisões quanto à qualidade do software. Porém, o uso de métricas de software não elimina a necessidade de

julgamento humano nas avaliações de um software (CLEMENTS; KAZMAN; KLEIN, 2002).

Projetar uma arquitetura que atinja os requisitos de qualidade demandados pelo processo de negócio é uma das tarefas que mais demanda esforços de um arquiteto de software. Por essa razão, faz-se necessário que o arquiteto de software tenha um ótimo conhecimento sobre requisitos de qualidade e as abordagens arquiteturais para implementar sistemas que os satisfaçam (HARRISON; AVGERIOU, 2007).

2.9 O CICLO DE VIDA DO REQUISITO NÃO FUNCIONAL

O ciclo de desenvolvimento de software é iniciado com a elicitação dos requisitos da aplicação, que podem ser classificados em funcionais, relacionados com as funções do sistema, e não funcionais, definidos pelas características da solução que são necessárias para atendimento dos requisitos funcionais. Apesar de não estarem diretamente relacionadas aos requisitos funcionais explicitamente solicitados pelo usuário, muitas vezes a implementação dos requisitos não funcionais definem as características de qualidade externa, ou seja, visíveis pelos usuários.

Por essa interdependência entre requisitos funcionais e não funcionais, ambos devem ser considerados desde o início do desenvolvimento do sistema. Entretanto, na prática, os requisitos não funcionais geralmente não são levados em consideração ou em casos melhores são considerados em fases tardias do processo de desenvolvimento de software, enquanto os requisitos funcionais são considerados durante todo o processo, o que torna mais difícil a satisfação dos requisitos não funcionais, visto que são suportados por requisitos não funcionais (KIM et al., 2008).

Segundo Chung e Leite (2009), muitas vezes os requisitos não funcionais não são levados em consideração adequadamente por três principais razões:

 A disciplina de Engenharia de Software ainda é uma área relativamente nova, não tendo ainda a cultura da preocupação com os atributos não funcionais de forma consolidada, se comparada às engenharias mais tradicionais;

 A pressão pela construção de sistemas cada vez mais rápida, para atender às necessidades do mercado, fazem com que os profissionais de TI preocupem-se apenas com a parte funcional do sistema, visando atender ao time-to-market9_;

 Devido à natureza mais abstrata dos requisitos não funcionais, a maior parte da atenção dos engenheiros de computação foca-se principalmente nas notações e técnicas para definição e implementação dos requisitos funcionais que um sistema deve prover.

Como uma prática frequentemente observada, os requisitos não funcionais são deixados em segundo plano, ou mesmo ignorados, em relação aos requisitos funcionais, porque são vistos como questões de natureza estritamente técnica ou consideradas óbvias, que devem ser avaliadas somente em um sistema já implementado (HRUSCHKA, 2012).

Essa prática tem se mostrado inadequada, visto que não faz sentido a realização de testes dos requisitos não funcionais sem que os mesmos tenham sido previamente entendidos e implementados de forma planejada e com frequentes avaliações.

Ainda, segundo Chung; Nixon e Yu (1995), a maioria dos problemas reais tem mais características diretamente relacionadas aos requisitos não funcionais do que a funcionais, como por exemplo: baixa produtividade, processamento lento, alto custo, baixa qualidade e clientes insatisfeitos.

Essa negligência no tratamento dos requisitos não funcionais geralmente resulta no desenvolvimento de sistemas de má qualidade e de difícil manutenção, dado que a arquitetura de software não foi planejada para atender a esses requisitos (FRANCH; BOTELLA, 1998). Além disso, os efeitos dessa negligência no tratamento de requisitos não funcionais são muitas vezes observados quando o sistema já se encontra em produção, ou seja, muito tarde para corrigir. Nesses casos, a percepção

9 _{Time-to-market: período de tempo necessário para projetar e fabricar um produto antes que o mesmo esteja disponível no}

do usuário da qualidade do sistema como um todo não é boa, mesmo que os requisitos funcionais estejam satisfeitos.

Para evitar essa negligência em relação aos requisitos não funcionais, os mesmos devem ser elicitados segundo as necessidades do processo de negócio, desde o início da fase de elicitação de requisitos. Dessa forma, será maior a probabilidade de o sistema satisfazer às necessidades de negócio e aos requisitos não funcionais que os apoiam. Como esteio conceitual para auxiliar no ensino orientada pelos processos de negócio, utilizou-se a norma ISO/IEC 10746 (Reference

Model - Open Distributed Processing - RM-ODP) (ISO/IEC, 1998b), descrita no item

2.4, na elaboração do roteiro.

2.10 MÉTODOS DE AVALIAÇÃO DE ARQUITETURA DE SOFTWARE

Segundo Clements; Kazman e Klein (2002), uma implementação de uma arquitetura abrange praticamente todos os atributos de qualidade de um sistema. Sendo assim, se as decisões arquiteturais determinam os atributos de qualidade de um sistema, então é possível avaliar essas decisões e seus impactos nos atributos de qualidade. Uma arquitetura inadequada precipitará o desastre em um projeto de software, dado que os requisitos de qualidade não serão atingidos, além dos estouros de prazos e orçamentos. Consequentemente, a avaliação arquitetural é a forma mais barata de se evitar um desastre em um projeto de software.

A complexidade de um software é determinada não somente por seus requisitos funcionais, definidos na norma IEEE 830 (1998) - Recommended Practice

for Software Requirements Specifications como o conjunto de ações fundamentais

que ocorrem no software ao aceitar e processar entradas e processar e gerar saídas, mas também por seus requisitos não funcionais (IEEE, 1998b).

Os requisitos não funcionais, tais como desempenho, disponibilidade, usabilidade, modificabilidade, entre outros, devem ser considerados durante o processo de desenvolvimento de sistemas, constituindo um importante critério para decisões de projeto. No contexto da disciplina de Engenharia de Software, um requisito não funcional consiste em um requisito que não descreve as funcionalidades que o software realiza, mas como o software as realiza. Cabe ressaltar que a

importância de um determinado requisito não funcional pode ser considerada relativa, dependendo do sistema a ser considerado. A prioridade atribuída a um requisito não funcional depende da importância deste requisito em relação ao contexto de negócio no qual o software será utilizado (CHUNG; LEITE, 2009).

Cabe à arquitetura de software orientar a implmentação dos atributos de qualidade dos sistemas de software, independentemente de sua categoria. As decisões arquiteturais têm um profundo impacto no alcance dos atributos de qualidade. Assim, para que possa haver uma avaliação de arquitetura de software, é necessário ter se estabelecido previamente os atributos de qualidade desejados motivados pelas regras de negócio (BARBACCI et al., 2003).

Segundo Clements; Kazman e Klein (2002), os principais objetivos da avaliação de arquitetura de software são: