Veri Ambarı Üzerinde Küp ve Boyutların Tanımlanması

O PARNAFOA tem o objetivo de integrar interesses transversais e não- transversais não-funcionais ao modelo de casos de uso de sistemas de software. Isso é obtido através de um conjunto de atividades para a identificação, separação e composição de interesses não-funcionais, sejam eles transversais ou não, e a incorporação dos resultados no modelo de casos de uso de um sistema de software. Obtém-se, com isso, um modelo de casos de uso que contém interesses funcionais e não-funcionais integrados, sendo que, os interesses não-funcionais são identificados e tratados desde as fases iniciais do desenvolvimento.

O PARNAFOA utiliza softgoals e casos de uso para representar interesses não-funcionais e funcionais, assim como diversos trabalhos da literatura (CHITCHYAN et al., 2006), (ARAÚJO; MOREIRA, 2003), (BRITO; MOREIRA, 2003), (BRITO; MOREIRA, 2004), (SOUSA, 2004), (SOUSA; SILVA; CASTRO, 2003), (MOREIRA; ARAÚJO; RASHID, 2005).

As abordagens, modelos e processos apresentados no capítulo 3 contribuíram para a definição da estrutura de sub-processos do PARNAFOA. Em especial destaca-se o processo da engenharia de requisitos orientada a aspectos AOSD-Europe (CHITCHYAN et al., 2006) que apresenta uma proposta consolidada a partir de vários trabalhos da área.

Estes trabalhos consideram a incorporação de aspectos nas fases iniciais do desenvolvimento através do modelo de casos de uso. A decisão a respeito do tratamento de aspectos como novos casos de uso, neste trabalho, foi baseada no modelo de engenharia de requisitos orientado a aspectos com

UML (RASHID et al., 2002), (ARAÚJO et al., 2002), no modelo de atributos de qualidade transversais para a engenharia de requisitos (BRITO; MOREIRA; ARAÚJO, 2002), (MOREIRA; ARAÚJO; BRITO, 2002) e na abordagem direcionada a casos de uso aspectuais (ARAÚJO; MOREIRA, 2003).

A decisão da utilização do relacionamento de inclusão entre novos casos de uso a serem incorporados no modelo de casos de uso foi motivada pelo modelo de atributos de qualidade transversais para a engenharia de requisitos (BRITO; MOREIRA; ARAÚJO, 2002), (MOREIRA; ARAÚJO; BRITO, 2002). A proposta deste trabalho é não introduzir novos tipos de relacionamento no modelo de casos de uso. Demais abordagens propõem o uso de novos tipos de relacionamentos como sobreposição, substituição, empacotamento, restrição e

crosscuts, que não foram utilizados neste trabalho.

Os dados obtidos na modelagem dos requisitos funcionais e não-funcionais ficam presentes no modelo de casos de uso e nos SIGs, respectivamente. Desta forma, o uso de formulários para descrição de interesses, conforme propostas do modelo de engenharia de requisitos orientado a aspectos com UML (RASHID et al., 2002), (ARAÚJO et al., 2002), modelo de atributos de qualidade transversais para a engenharia de requisitos (BRITO; MOREIRA; ARAÚJO, 2002), (MOREIRA; ARAÚJO; BRITO, 2002), abordagem direcionada a casos de uso aspectuais (ARAÚJO; MOREIRA, 2003) e integração do NFR

Framework no modelo de engenharia de requisitos (BRITO; MOREIRA, 2004),

(BRITO; MOREIRA, 2003) não foram utilizados neste trabalho para evitar redundância de informações.

Informações sobre relacionamentos positivos e negativos entre interesses estão presentes nos SIGs na forma de correlações positivas e negativas. Tabelas de contribuições, positivas e negativas, entre interesses provenientes das propostas de integração do NFR Framework no modelo de engenharia de requisitos (BRITO; MOREIRA, 2004), (BRITO; MOREIRA, 2003) e, do modelo de engenharia de requisitos orientado a interesses (RASHID; MOREIRA; ARAÚJO, 2003), (MOREIRA; ARAÚJO; RASHID, 2005), (MOREIRA; RASHID; ARAÚJO, 2005), não foram utilizadas para que a informação não fosse duplicada.

O PARNAFOA utiliza o NFR Framework desde a identificação dos NFRs até a definição de metas. Isto não ocorre na maioria das abordagens e modelos

apresentados, a qual utiliza o NFR Framework somente para a decomposição de tipos de RNFs. A exceção é feita na abordagem direcionada a casos de uso para o desenvolvimento de software orientado a aspectos (SOUSA, 2004), (SOUSA et al., 2004), (SOUSA; SILVA; CASTRO, 2003), a qual utiliza o NFR

Framework para detalhar e analisar os requisitos não-funcionais.

A escolha das regras de composição do PARNAFOA foi baseada na abordagem direcionada a casos de uso para o desenvolvimento de software orientado a aspectos (SOUSA, 2004), (SOUSA et al., 2004), (SOUSA; SILVA; CASTRO, 2003), por serem de fácil manipulação e entendimento. As definições da integração do NFR Framework no modelo de engenharia de requisitos (BRITO; MOREIRA, 2004), (BRITO; MOREIRA, 2003) e do modelo de engenharia de requisitos orientado a interesses (RASHID; MOREIRA; ARAÚJO, 2003), (MOREIRA; ARAÚJO; RASHID, 2005), (MOREIRA; RASHID; ARAÚJO, 2005) não são utilizados neste trabalho. Apesar de tornarem o processo de composição mais preciso, estes trabalhos tornam a atividade de composição de interesses demasiadamente complexa pela inclusão de uma quantidade excessiva de regras e operadores.

O PARNAFOA considera restrições de projeto e restrições operacionais identificados durante a construção dos SIGs. Restrições de projeto estão fora do escopo da abordagem direcionada a casos de uso para o desenvolvimento de software orientado a aspectos (SOUSA, 2004), (SOUSA et al., 2004), (SOUSA; SILVA; CASTRO, 2003).

Para a resolução de conflitos com a definição de regras de precedência, a proposta apresentada na abordagem direcionada a casos de uso para o desenvolvimento de software orientado a aspectos (SOUSA, 2004), (SOUSA et al., 2004), (SOUSA; SILVA; CASTRO, 2003) foi considerada apropriada. A proposta do modelo de engenharia de requisitos orientado a interesses (RASHID; MOREIRA; ARAÚJO, 2003), (MOREIRA; ARAÚJO; RASHID, 2005), (MOREIRA; RASHID; ARAÚJO, 2005) traz benefícios na priorização de interesses durante a resolução de conflitos para a composição, porém, sua utilidade seria maior se aplicada inicialmente na priorização de interesses. Durante a composição de interesses, as prioridades e regras de precedência devem ser definidas a partir do entendimento do sistema de software e seus requisitos. A utilização de métodos de análise para a priorização podem

auxiliar, mas não são suficientes para decidir o que deve ser priorizado durante a composição. Esta análise deve contar com o apoio de especialistas.

O modelo de engenharia de requisitos orientado a interesses (RASHID; MOREIRA; ARAÚJO, 2003), (MOREIRA; ARAÚJO; RASHID, 2005), (MOREIRA; RASHID; ARAÚJO, 2005) utiliza XML na especificação e composição de interesses, com o objetivo de torná-las mais flexíveis, porém, traz maior complexidade no entendimento e manipulação das especificações pelas partes interessadas.

Com relação às demais abordagens, a proposta de (JACOBSON; NG, 2004), (JACOBSON, 2003a, 2003b) não dá ênfase ao tratamento de interesses não-funcionais durante as fases iniciais de desenvolvimento.

A proposta de temas para especificar aspectos (CLARKE; BANIASSAD, 2005) requer o uso de ferramentas de apoio que auxiliem na representação dos temas, pois em sistemas de grande porte, as representações podem tornar-se demasiadamente complexas. A falta de suporte ferramental pode inviabilizar sua aplicação dependendo do porte do projeto.

O uso de uma linguagem definida com base em conceitos da programação orientada a aspectos e XML, proposta por Silva (2006) e Silva e Leite (2005a, 2005b) são fatores que agregam maior complexidade para o processo de identificação e composição de aspectos na fase de requisitos.

Os trabalhos de Mussbacher (2008) e Mussbacher, Amyot e Weiss (2007) apresentam uma linguagem que enfatiza a importância das partes interessadas na definição dos sistemas de software. Adaptações da representação do NFR

Framework são propostas, bem como o uso das representações do framework

I*. Neste trabalho, optou-se pelo uso da representação original do NFR

Framework, o que inviabiliza a adoção desta proposta.

A definição do PARNAFOA conta com o detalhamento de métodos relacionados ao tratamento de requisitos não-funcionais, descritos no capítulo 2 e abordagens orientadas a aspectos, descritas no capítulo 3. Este tratamento foi necessário, para que os métodos utilizados apresentassem o mesmo nível de detalhamento para sua inclusão no processo.