2.3 Estratégias da Engenharia de Software para promover a Acessibilidade Web
2.3.2 O uso de abordagens orientadas a metas
A estratégia da Engenharia de Requisitos adotada por esta pesquisa engloba o uso de Abordagens orientadas a metas, que são caracterizadas pela construção de modelos intencionais, onde podemos definir e refinar as metas que os usuários possuem em relação ao sistema a ser desenvolvido (Mylopoulos et al., 1999). No
contexto desta dissertação as metas compreendem os RNFs, onde a meta mais abstrata a ser alcançada será a acessibilidade.
A abordagem orientada a metas utilizada por esta pesquisa é o NFR framework, que é uma abordagem onde os requisitos não funcionais são trabalhados como metas suaves (Softgoals) a serem atingidas (Chung et al., 2000). Uma meta suave pode ser interdependente e, ao mesmo tempo, pode impactar em outras metas, representando um objetivo, que não tem definição e/ou critério bem definido, no que diz respeito à sua satisfação, ou não. O NFR framework utiliza relações de contribuição entre as metas para auxiliar o desenvolvedor no processo de avaliação de impactos (Chung, L.; LEITE, J. C., 2009). Existem três tipos de representações para as relações entre metas, sendo elas:
o Refinamentos de metas suaves utilizando AND e OR, onde o elemento de contribuição AND obriga a implementação do refinamento, enquanto no caso do elemento OR, esta implementação é opcional.
o Contribuição entre metas suaves, podendo ser negativas e positivas, apresentando possíveis soluções para a satisfação do objetivo.
o Alegação (Claim) para considerar uma meta suave e respectivas operacionalizações.
O NFR Framework contribui para que os desenvolvedores tratem os requisitos não funcionais, auxiliando a expressá-los sistematicamente, servindo como base para guiar o processo de elicitação de forma racional. Para isso, o NFR Framework utiliza uma representação gráfica chamada “Softgoal Interdependency Graphs (SIGs)”. Essa estrutura permite armazenar e tratar as alternativas levantadas para alcançar a implementação dos RNFs, levando em consideração o contexto da aplicação.
A Figura 2 mostra um exemplo básico de um SIG do NFR Framework, nessa estrutura é mostrado o requisito não funcional de usabilidade e as possibilidades para sua operacionalização.
Figura 2 - Exemplo de um SIG baseado na abordagem NFR Framework
No exemplo da Figura 2, a meta suave usabilidade foi refinada ou decomposta em outras duas metas suaves, Cognoscibilidade e Operabilidade. Por sua vez, para estas novas metas suaves foram criadas operacionalizações a serem implementadas como, por exemplo, no caso da Cognoscibilidade foi criada a operacionalização “Fornecer interface amigável com feedback para cada ação do usuário”.
A premissa do NFR framework diz que as decisões devem ser baseadas em argumentos bem justificados (Chung et al., 2000), nesse contexto o elemento de alegação é o responsável direto para indicar a razão (rationale) por trás de algumas decisões tomadas.
Outra abordagem que faz parte do contexto orientado a metas é o framework i* (i-estrela), proposto por Yu em (Yu, 1995) e trata a modelagem intencional de software, especificamente na fase de requisitos, considerando contextos organizacionais. Essa abordagem permite a análise dos relacionamentos de dependência entre os atores, facilitando a compreensão sobre os relacionamentos organizacionais, analisando os vários agentes que fazem parte do ambiente em questão. No i*, há a ideia de componentes conhecidos como atores, de acordo com Yu (1995), atores são entidades ativas que efetuam ações para alcançar metas através
do exercício de suas habilidades e conhecimentos, podendo ter dependências intencionais entre si. Além dos atores, os elementos básicos que compõe o i* são: Metas: representados pelos objetivos que os atores possuem em relação as
funcionalidades do sistema;
Tarefas: são as ações que os atores podem realizar dentro da organização para atingir suas metas;
Metas suaves ou flexíveis: são qualidades ou situações desejáveis, geralmente são referenciados como requisitos não funcionais do sistema. Estas metas não possuem critérios claros para sua satisfação, ou seja, são subjetivas e dependentes dos pontos de vista dos stakeholders.
Assim como o NFR Framework, o framework i* também é composto por variados elos de associações entre os atores i*, tais como: “é parte de”, “é um”, “desempenha” e “ocupa”. Há também as dependências estratégicas entre atores e elos que relacionam com o cumprimento das metas, chamados de elos “meio-fim”. O framewok i*, como originalmente proposto por Yu (1995), usa dois modelos, sendo estes: Modelo SD (Strategic Dependency) e Modelo SR (Strategic Rationale). A Figura 3 ilustra um exemplo do modelo SD do framework i*.
Figura 3 - Exemplo de um modelo SD do framework i*
No exemplo da Figura 3 é mostrada uma situação sobre pagamento de contas, envolvendo os atores Cliente e Banco. Nesse modelo o cliente deseja efetuar pagamentos de contas diversas e para atingir essa meta, duas tarefas são definidas para possibilitar esses pagamentos, sendo estas: “Usar débito automático” e “Usar
cartão de crédito”. A tarefa “Usar débito automático” ajuda na meta flexível “Prevenção contra atrasos”, já a segunda tarefa “Usar cartão de créditos” auxilia “Gerenciar dívidas”, ambas ainda auxiliam uma terceira meta flexível chamada “Conveniência”. No contexto do ator Banco existe uma meta que é “Obter novos clientes” e para alcançá-la existem duas tarefas, sendo estas: “Oferecer serviço de débito automático” e “Oferecer cartão de crédito”. A primeira tarefa auxilia na meta “Aumentar comodidade do cliente”, a segunda ajuda a “Aumentar lucros”. Na interação entre esses dois atores, suas tarefas dependem de dois recursos, o primeiro é o “Cartão de crédito” e o segundo é “Serviço de débito automático”.
Além de utilizar elementos gráficos em forma de nuvens para indicar os componentes, a representação SIG do NFR Framework possui outras diferenças em relação aos modelos existentes no i* (Chung et al., 2000;
Lamsweerde, 2001
), tais como: a ausência do elemento ator; as operacionalizações no i* são abordadas pelas tarefas (elemento gráfico hexágono), já no NFR framework é utiliza-se a notação de nuvens com bordas em negrito indicando formas de refinamentos para as metas suaves; e a existência de elementos de argumentação que representam as alegações, oferecendo noções sobre o rationale da estrutura.Em resumo tanto a abordagem i* como o NFR Framewok permitem ao engenheiro de requisitos a elaboração e manutenção de catálogos de requisitos não funcionais, permitindo assim trabalhar as decisões através de análises sobre os impactos apresentados entre os requisitos do sistema. Essas abordagens permitem também que os aspectos de subjetividade e interatividade, relacionados aos atributos de qualidades de um software, sejam mais compreensíveis.