FMIT: Feature Model Integration Techniques

09/27/2018
by   Vinicius Bischoff, et al.
0

Although feature models are widely used in practice, for example, representing variability in software product lines, their integration is still a challenge. Many integration techniques have been proposed, although none of these have proven to be fully effective. Integrating feature models becomes a difficult, costly, error-prone task. Since their transition occurs in a generalized and automated way, the techniques applied to compose the models end up giving rise to a final model, in many cases undesired, without taking into account the specific needs arising from the requirements determined by the analysts and developers. Therefore, this work proposes FMIT, a technique for integrating feature models. The FMIT is based on contemporary model integration strategies to increase the accuracy and quality of the integrated feature model. In this way, it will be possible to identify the degree of similarity between composite feature diagrams, to verify their accuracy, as well as to identify conflicts. In addition, this work proposes the development of a prototype based on the set of strategies, used to take decisions according to the requirements established during the integration of feature models, whether this is semi-automatic or automatic. To evaluate FMIT, experimental studies were conducted with 10 participants, including students and professionals. Participants performed 12 integration scenarios, 6 using the FMIT and 6 manually. The results suggest that FMIT improved accuracy by 43% of the cases, as well as reduced the effort by 70% to perform the integrations.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 21

04/28/2019

Requirements variability specification for data intensive software

Nowadays, the use of feature modeling technique, in software requirement...
08/31/2018

Automated Prototype Generation from Formal Requirements Model

Prototyping is an effective and efficient way of requirement validation ...
07/01/2021

IsiSPL: Toward an Automated Reactive Approach to build Software Product Lines

Over the past decades, Software Product Lines (SPLs) have demonstrated t...
04/04/2019

Is it Possible to Disregard Obsolete Requirements? - An Initial Experiment on a Potentially New Bias in Software Effort Estimation

Effort estimation is a complex area in decision-making, and is influence...
01/13/2018

Semantic integration of UML class diagram with semantic validation on segments of mappings

Recently, attention has focused on the software development, specially b...
02/12/2021

What helped, and what did not? An Evaluation of the Strategies to Improve Continuous Integration

Continuous integration (CI) is a widely used practice in modern software...
03/09/2021

Symbolic integration by integrating learning models with different strengths and weaknesses

Integration is indispensable, not only in mathematics, but also in a wid...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1.1 Problemática

Considerando que os Modelos de Features (MF) podem ser criados em colaboração por diferentes equipes de desenvolvimento de software ČAVRAK; ORLIĆ; CRNKOVIĆ (2012); werner2003, em algum momento os modelos criados em paralelo devem ser integrados para formar uma visão geral das variablilidades da LPS. Por esta razão, várias técnicas de integração de modelos de features, têm sido propostas nos últimos anos, tais como, BENAVIDES; SEGURA; RUIZ-CORTÉS (2010); ACHER et al. (2010); THUM; BATORY; KASTNER (2009); APEL et al. (2014).

A integração de modelos de features pode ser brevemente definida neste trabalho como uma operação em que um conjunto de tarefas deve ser executado em dois modelos de features de entrada, (MF) e (MF), a fim de produzir um modelo de saída, (MF). Enquanto MF representa o modelo base (origem), MF, consiste no modelo delta (destino) com todos os incrementos que devem ser inseridos, excluídos ou alterados em MF para transformá-lo em MF. As técnicas de integração normalmente produzem um modelo integrado, (MF) que muitas vezes não corresponde ao modelo de saída pretendido, MF, isto é, MF MF.

Este fato ocorre porque os elementos dos modelos de entrada, (MF) e (MF) geralmente apresentam informações conflitantes, e essas técnicas acabam sendo incapazes de solucionar todos os conflitos corretamente.

Essa situação está representada na Figura 1.1, a qual exibe a dificuldade da integração dos modelos, em um cenário simples formado por dois modelos de features de entrada, MF e MF, produzindo o modelo de saída MF, ou seja, o modelo pretendido e o modelo integrado, MF, o qual exibe sua respectiva saída. Pode-se observar os conflitos semânticos e sintáticos entre os modelos, MF e MF, ao realizar a comparação sintática há um único conflito a features [B] e a features [S] ambas assinaladas com um "X"e ao comparar os relacionamentos entre as features são identificados três conflitos, (obrigatório, um circulo preto; opcional, um circulo branco; ou-inclusivo, arco preto e, por fim, ou-exclusivo, arco branco) ambos identificados com um "X", já as features assinaladas com um "V"são similares. Neste exemplo exibi-se duas saídas: (1) o modelo pretendido MF, isto é, o modelo que deveria ser produzido e o (2) modelo integrado, MF, percebe-se as inconsistências decorridas de uma má integração assinaladas com um "X", já as assinaladas com um "V"são similares. Assim, surge a necessidade de promover melhorias nas técnicas aplicadas e nas ferramentas que auxiliam as equipes de desenvolvimentos na condução de se obter o modelo pretendido.

Elaborado pelo Autor.
Figura 1.1: Exemplo de uma integração de modelo de feature.

Na verdade, é muito difícil solucionar conflitos automaticamente FARIAS et al. (2015a); OLIVEIRA (2012), porque a resolução destes depende de um entendimento que o modelo de features realmente significa, e tal informação raramente é representada de uma maneira formal, afetando o comportamento de outras features de forma inadequada. Consequentemente, analistas e desenvolvedores acabam por ter de investir algum esforço extra para rever e alterar modelos inconsistentes e torná-los compatível como o modelo desejado.

Conforme mencionado anteriormente, a literatura reporta que as técnicas de integração de modelos de features disponíveis na academia não são precisas. Isto é, as técnicas disponíveis são inflexíveis, não permitindo a interação durante o processo de integração, tornando esta atividade complexa, dispendiosa e condizente a propensão de erros, bem como eleva o esforço das equipes de desenvolvimento em sua correção.

Deste modo, surgem demandas que caracterizam os problemas abordados, a seguir.

  • P-1: A integração de modelos de features conduzida de forma manual, bem como as ferramentas propostas na literatura que dão suporte a composição, acabam em muitos casos produzindo como saída um modelo indesejado, devido a sua inflexibilidade durante o processo de integração, gerando assim, modelos imprecisos e possivelmente propagando erros para outras fases do desenvolvimento, impactando diretamente na qualidade final dos produtos.

  • P-2: Há uma serie de ações necessárias na correção dos modelos produzidos inadequadamente, reduzindo desempenho da força de trabalho e elevando esforços na detecção das inconsistências anteriormente produzidas, ocorrendo a execução deste processo manualmente, o que o torna ineficiente, portanto reduzindo a capacidade produtiva das equipes de desenvolvimento, elevando os custos de produção.

1.2 Questões de Pesquisa

A partir dos problemas investigados fica evidente a necessidade de propor melhorias nas técnicas de integração e no aprimoramento das técnicas de comparação de modelos de features, bem como a obtenção de soluções funcionais que auxiliem as equipes de desenvolvimento. Os trabalhos investigados na literatura representam um avanço não só para a academia, mas também para a indústria de software, contudo há algumas limitações nas abordagens utilizadas. Sendo assim, a questão de pesquisa chave desta proposta é apresentada a seguir.

Questão de Pesquisa Geral: Como aprimorar as técnicas de integração de modelos de features para obter como saída o modelo mais próximo do desejado, sendo esta técnica uma facilitadora para as equipes de desenvolvimento?


Depois de definir a questão chave, surge a primeira questão de pesquisa, onde realizou-se uma análise entre as abordagens manual e semiautomática. Visto que a técnica automática acaba em alguns casos produzindo modelos imprecisos os quais necessitam de ajustes para se obter o modelo pretendido. Sendo este processo executado de forma manual, surge a seguinte questão de pesquisa:

  • QP-1: Aplicação da técnica semiautomática em relação a técnica manual melhora a corretude dos modelos de features integrados?

A segunda questão de pesquisa procura identificar e reduzir os esforços na resolução de conflitos, assim como verificar a compreensão das equipes de desenvolvimento na tomada de decisão.

  • QP-2: Qual o impacto da aplicação técnica semiautomática em relação a técnica manual no que diz respeito ao esforço na resolução de conflitos?

1.3 Objetivos

Após contextualizar este estudo, apurar os principais problemas pesquisados, e abordar algumas das limitações dos trabalhos investigados, se estabeleceu o objetivo principal deste trabalho, podendo a partir deste elaborar as ações necessárias para o seu cumprimento, isto é, os objetivos específicos.

Objetivo principal: propor uma técnica que auxilie as equipes de desenvolvimento na integração de modelos de features, reduzindo os esforços de produção, a propensão a erros, e por fim, elevar a precisão dos modelos integrados.

Além do objetivo principal, definiu-se os seguintes objetivos específicos: (1) obter um panorama atual sobre o estado da arte, procurando entender como esta área tem se desenvolvido e quais as principais abordagens são utilizadas em sua implementação; (2) realizar estudos experimentais para avaliar a abordagem da técnica manual, ou seja, o modelo integrado em comparação ao modelo pretendido, para analisar como os analistas e desenvolvedores investem os esforços na composição dos modelos e na resolução de conflitos, bem como mensurar inconsistências surgidas durante a integração; (3) propor uma técnica para melhorar a precisão dos modelos integrados, com ênfase nas técnicas já documentadas na literatura que compreende as atividades de identificação de similaridade entre os elementos do modelo composto; (4) projetar e desenvolver um protótipo, com a finalidade de carregar os modelos, persistir, comparar sua equivalência e integrar os modelos de features. Ao implementar o protótipo, espera-se que o mesmo seja um facilitador na tomada de decisões, visto sua flexibilidade podendo adaptar-se de acordo com as necessidades, quando há algum elemento conflitante; (5) realizar estudos empíricos para avaliar e mensurar a efetividade da técnica proposta, tendo em vista produzir conhecimento sobre sua aplicação.

1.4 Metodologia

A viabilização deste trabalho ocorreu através de uma metodologia cuja primeira etapa consiste na realização de uma revisão da literatura através de um mapeamento sistemático sobre as técnicas de integração de modelos de features, respeitando um conjunto de passos, ou seja, uma revisão planejada com o intuito de responder questões específicas e que utilizam métodos explícitos e sistemáticos para selecionar, identificar e avaliar os estudos incluídos na revisão KITCHENHAM et al. (2010); KITCHENHAM; BUDGEN; BRERETON (2011). Essa revisão tem por objetivo analisar as técnicas disponíveis na academia e na indústria, bem como identificar as principais dificuldades enfrentadas por pesquisadores e profissionais, com a finalidade de elencar novas oportunidades de pesquisa. De acordo com Marconi2003 a revisão da literatura é usada para reunir informações sobre determinados tópicos, uma vez que procura propiciar maior familiaridade com o tema, além de aprofundar seus conceitos preliminares.

A segunda etapa consiste em estudos empíricos de integração de modelos de features manualmente. Os estudos procuram os fatores que afetam o processo de composição de modelos quando conduzido de forma manual a partir da realização experimentos com a finalidade de mensurar o esforço que as equipes de desenvolvimento investem para integrá-los, assim como verificar a ocorrência de conflitos nos modelos produzidos.

Na terceira etapa ocorre a especificação da arquitetura proposta, detalhando seus componentes principais tendo como finalidade determinar quais os elementos são necessários para o modelo e a interação entre estes. Em seguida, na quarta etapa foi desenvolvido um protótipo com todos os componentes necessários á sua execução. Na quinta etapa foram definidos possíveis cenários para aplicação da técnica de integração, bem como a definição de sua execução, isto é, um experimento controlado.

Finalmente, a última etapa compreende a execução de novos experimentos de integração de modelos de features com o suporte do protótipo desenvolvido, com a finalidade de analisar dados comparativos do esforço aplicado e a corretude entre a integração manual e a integração semiautomática de modelos features. Conforme gil2002, os experimentos caracterizam a pesquisa como quantitativa quanto ao método, visto que expõem a comparação de medidas e uso de técnicas estatísticas para avaliação dos resultados.

1.5 Organização do Trabalho

Este trabalho está organizado em sete capítulos, conforme descrito a seguir: o Capítulo 2 que relaciona os conceitos fundamentais para o entendimento deste trabalho. O Capítulo 3 apresenta as principais abordagens que possuem relação com a proposta desta pesquisa, relacionando suas principais características e descreve as oportunidades de pesquisa. O Capitulo 4 apresenta as técnicas de integração propostas neste trabalho. O Capítulo 5 introduz o protótipo de integração de modelo de feature que implementa a técnica descrita no Capitulo 4. O capitulo 6 descreve a avaliação da técnica e do protótipo proposto. Por fim, a conclusão deste trabalho é apresentada no Capítulo 7, bem como as contribuições as limitações e sugestões de trabalhos futuros desta pesquisa.

2.1 Reutilização de Software

A reutilização de software é amplamente utilizada na indústria de software tendo com princípio reduzir os esforços aplicados no processo produtivo de desenvolvimento de software, assim como minimizar os custos de operação. De acordo com krueger1992, reutilização de software é o processo de criação de software a partir de um software já existente, ao invés de sua construção inicial. Algumas motivações em se reutilizar software são a redução de tempo e esforço no desenvolvimento, impactando diretamente na qualidade do produto gerado KRUEGER (2006); POHL; BÖCKLE; DER LINDEN (2005); KRUEGER (2010).

Porém, a realidade nos ambientes empresariais, demostrou que os desafios a serem enfrentados são mais abrangentes do que a simples execução das técnicas de reutilização DESOUZA; AWAZU; TIWANA (2006). Tendo em vista esta afirmação, a reutilização de software não apresenta sua efetividade na prática, a grande questão é que a reutilização é realizada de forma ad hoc, ou seja, não sistemática, dependente de iniciativa e do conhecimento intelectual individual dos colaboradores. As empresas não implantam de forma consistente as técnicas propostas, e estão sujeitas a pouco ou sequer a nenhum tipo de controle e planejamento gerencial EZRAN; MORISIO; TULLY (2002).

A reutilização sistemática consiste no entendimento sobre como é possível contribuir para os objetivos do negócio, na definição das estratégias técnicas e gerencias para se extrair o máximo da reutilização, na integração com os processos de software e de melhoria que fazem com que a reutilização ocorra de forma controlada EZRAN; MORISIO; TULLY (2002); KRUEGER (2010).

2.2 Linhas de Produto de Software

As Linhas de Produto de Software (LPS) permitem a reutilização sistemática de software, através do desenvolvimento de famílias de produtos que compartilham características comuns BERG; BISHOP; MUTHIG (2005). Segundo pohl2005, as LPS referem-se à técnica de engenharia para a criação de sistemas de software similares a partir de um conjunto compartilhado de partes do software, usando uma forma sistemática para a construção de aplicações. A definição de clements2002, descreve a LPS como um conjunto de sistemas intensivos de software e que compartilham um conjunto comum de features gerenciáveis, as quais satisfazem necessidades específicas de um segmento, que são desenvolvidas a partir de um conjunto de recursos comuns segundo um processo definido. Uma feature é definida como uma propriedade do sistema relevante para os analistas e que é usada para capturar semelhanças e variabilidade entre produtos de uma LPS CZARNECKI et al. (2002); CZARNECKI; HELSEN; EISENECKER (2005).

As diferenças entre os produtos são denominados de variabilidade. Para berg2005 o nível de variabilidade determina a capacidade de um sistema ser personalizado de acordo com um contexto específico, possibilitando a produção em larga escala. Produtos que incorporam variabilidade podem apresentar vantagens como abordar vários segmentos e fornecer conjuntos de diversas características para diferentes necessidades.

O desenvolvimento de uma LPS envolve três atividades básicas CLEMENTS; NORTHROP (2002): (1) o desenvolvimento de recursos do núcleo (core assent development), os recursos de núcleo são os artefatos e recursos reusáveis que formam a base da LPS e podem incluir a arquitetura, documentação, especificações, componentes reusáveis de software e casos de teste. O objetivo desta atividade é o estabelecimento de uma capacidade produtiva, conhecida por engenharia de domínio; (2) o desenvolvimento do produto (product development), aborda a criação de um produto que atenda a uma determinada demanda de mercado ou consumidores. É composto por três fatores, o escopo de linha de produção a base de recursos do núcleo e do plano de produção, conhecida por engenharia de aplicação; e por fim, (3) o gerenciamento (management), responsável pela supervisão, coordenação e distribuição de recursos. Abrange o gerenciamento organizacional o qual identifica as restrições de produção, assim como suas estratégias e o gerenciamento técnico, que por sua vez supervisiona as demais atividades apara manter o controle de todo o processo.

Clements; Nortthrop, 2002.
Figura 2.1: Atividades para o desenvolvimento de uma LPS.

Na Figura 2.1 cada círculo representa uma das atividades necessárias para o desenvolvimento da LPS, as três atividades estão inter-relacionadas, ou seja, não há como determinar qual das atividades vem primeiro. Estes fatos decorrem de que os recursos do núcleo são formados a partir de produtos já existentes (abordagem reativa) e em outras ocasiões os recursos do núcleo que são desenvolvidos antes de qualquer produto (abordagem proativa), ou também se pode executar ambas as combinações intensificando as interações entre as atividades (abordagem extrativa) extraindo características comuns e variáveis de sistemas existentes para formar uma nova LPS KRUEGER (2006); CLEMENTS; NORTHROP (2002).

A adoção dos procedimentos no desenvolvimento das LPS procura identificar melhorarias atreladas a qualidade e manutenibilidade, bem como reduzir o custo e o tempo. Permite aos analistas e desenvolvedores utilizar componentes reutilizáveis e aumentar a capacidade de produção das organizações tendo em vista atender as mudanças de mercado, introduzindo novos produtos de forma mais rápida e eficiente, adequando aos componentes reutilizáveis REINHARTZ-BERGER; STURM; TSOURY (2011); DURSCKI et al. (2004).

As dificuldades na escolha da abordagem para trabalhar em LPS ocorrem em sua maioria devido à mudança cultural, sendo que os desenvolvedores estão acostumados a trabalhar com um sistema por vez BERGEY; O’BRIEN; SMITH (2000), bem como os problemas para a extensão do mapeamento do domínio, ou seja, a construção de uma arquitetura básica, devido às inconstâncias entre os componentes desenvolvidos o gerenciamento incorreto do conhecimento, assim como, a evolução dos componentes sem armazenar suas modificações JANSEN et al. (2004); JANSEN; BOSCH (2005).

De acordo com durscki2004, os problemas de implantação de uma LPS são relevantes. Se destaca: (1) abordagem inadequada frente ao foco de elevar a produtividade; (2) caso os produtos gerados não possuam semelhança não garantem a viabilidade do projeto; (3) interação insuficiente entre as equipes de desenvolvimento, ou seja, a LPS necessita de colaboração entre os envolvidos no projeto.

2.3 Variabilidade e Modelos de Features

A variabilidade é fundamental para o gerenciamento e desenvolvimento de linhas de produto de software. Podem conter conceitos relacionados a decisões, features ou pontos de variação. Modelo de features é uma das notações mais expressivas aplicadas para a modelagem de variabilidade ANDERSEN et al. (2012). Portanto, no desenvolvimento de uma LPS, uma das primeiras atividades a serem executadas é a análise de feature, que identifica as características visíveis dos produtos da LPS e as organizam em modelos de features ACHER et al. (2010); LEE; MUTHIG (2006). Através da modelagem de feature onde são especificadas as funcionalidades comuns e variáveis da família de produtos a serem produzidas.

O modelo de features é considerado um modelo de alto nível empregado para expressar os produtos de uma linha de produto de software representando as características de um domínio específico, suas variabilidades e semelhanças, assim como seus relacionamentos KANG et al. (1990). O principal objetivo do modelo de features é a modelagem das propriedades comuns e as variáveis dos produtos possíveis de uma linha de produção, incluindo suas interdependências. As features representam os atributos da aplicação de um dado domínio, estando diretamente relacionadas e visíveis ao cliente final KANG et al. (1990). Nesta proposta de dissertação, a definição de feature é dada como sendo uma funcionalidade de comportamento específico para os analistas e desenvolvedores. Diversas definições são apresentadas na literatura para o termo features CLASSEN; HEYMANS; SCHOBBENS (2008).

  • "Uma estrutura que amplia e modifica a estrutura de um determinado programa, a fim de satisfazer um requisito das partes interessadas, para implementar e encapsular um decisão de design e oferecer uma opção de configuração"APEL; KÄSTNER (2009);

  • "Uma característica do produto a partir de visões do usuário ou cliente, determinado a partir de um conjunto de requisitos individuais"CHEN et al. (2005); e

  • "Um aspecto importante para um cliente"RIEBISCH et al. (2002).

O primeiro modelo de features foi proposto por KANG et al. (1990), como parte do método Feature Oriented Domain Analysis – FODA. Desde então vários outros métodos foram propostos na literatura, Feature-Oriented Reuse Method – FORMKANG et al. (1998), Feature Reuse-Driven Software Engineering Business - FeatuRSEB GRISS; FAVARO; D’ALESSANDRO (1998),1998), Product Line UML-Based Software Engineering – PLUS ERIKSSON; BÖRSTLER; BORG (2005) Cardinality-based Feature Models - CBFM CZARNECKI; HELSEN; EISENECKER (2005).

O resultado deste processo é uma representação compacta das possíveis derivações de um determinado domínio ou produto, através de um conjunto de características dispostos hierarquicamente, demostrando os relacionamentos existentes entres os elementos e suas possíveis restrições.

O modelo de features é uma árvore, em que a raiz representa conceito e suas folhas são as features conectadas por arestas que representam o seu estado CZARNECKI; HELSEN; EISENECKER (2004). O seu estado é exibido através de notações intuitivas para representar os pontos de variações. A Figura 2.2 apresenta um modelo de features e suas notações. O exemplo ilustra as notações tipicamente utilizadas para representar os relacionamentos entre as features, obrigatório, opcional, alternativa exclusiva e inclusiva, e os relacionamentos transversais, exclusão e dependência. O relacionamento hierárquico é definido entre uma feature ancestral e suas features descendentes. Uma feature descendente só poderá fazer parte de um produto em que sua feature ancestral aparece.

Elaborado pelo Autor.
Figura 2.2: Exemplo de um modelo de features e seus relacionamentos.
  • Obrigatória. Uma feature filha que tem um relacionamento obrigatório, ela é incluída em todos os produtos em que feature pai aparece. No exemplo a features raiz "A"obrigatoriamente será criada a feature "B".

  • Opcional. A feature filha tem uma relação definida como opcional, poderá ser incluída facultativamente em todos os produtos em que sua funcionalidade principal é exibida. No exemplo acima a feature “G” poderá ser incluída ou não no modelo de features selecionado.

  • Alternativa-Exclusiva. Um conjunto de features filhas é definido como alternativa, quando somente uma feature poderá ser selecionada, as demais são excluídas, a feature pai faz parte do produto. No exemplo acima poderá ser selecionada somente uma das features,“E” ou “F”.

  • Alternativa-Inclusiva. Um conjunto de features filhas poderá ser incluído adicionalmente nos produtos em que a feature pai aparece. No exemplo acima poderá ser selecionada as features, “C” ou feature “D” ou ambas.

  • Dependência. Quando uma feature sempre que selecionada requer a presença de outra.

  • Exclusão. A seleção de uma feature impede a seleção de outra feature.

De acordo com a Figura 2.2, a feature raiz A, representa um conceito, ou seja, um produto A. As subfeatures definidas abaixo dela representam as possibilidades de variação existentes neste domínio. Conforme pode ser visualizado, a feature B é obrigatória. Implicando que o domínio A, deve definir feature B a ser utilizada. Como subfeatures de B, têm-se as features C e D. Por serem features alternativas inclusivas, poderão ocorrer à seleção de ambas as features. Porém, as subfeatures alternativas exclusivas E e F, quando selecionada uma delas, implica na exclusão de outra. Como exemplo de feature opcional, tem-se a feature G, além disso, a notação FODA KANG et al. (1990), permite a utilização dependência e exclusão entre as features.

2.4 Configuradores e Integração de Modelos de Features

O modelo de feature apresentado na seção anterior protocola a geração de produtos, permitindo o relacionamento entre as features e os recursos do núcleo. Essa integração ocorre dos processos de desenvolvimento de domínio e aplicação. As dificuldades inerentes dos processos de criação das LPS ocorridos durante integração decorrentes das fases de desenvolvimento de recursos do núcleo e desenvolvimento de produtos são oriundas da necessidade de uma configuração especifica para cada produto tendo um contexto isolado para os recursos do núcleo causando interesses conflitantes entre as equipes de desenvolvimentos, isto é, o domínio versus aplicação KRUEGER (2006).

A sistematização da construção destas atividades surgiu para superar estes conflitos (domínio e aplicação) são os configuradores automáticos KRUEGER (2006). A figura 2.3 exibe o configurador que recebe duas entradas: as partes centrais e modelos de produtos, criando automaticamente instâncias de produtos.

Adaptado de Krueger (2006).
Figura 2.3: Configurador de LPS.

O configurador automático para a LPS deverá gerar produtos para a LPS de forma segura, verificando as propriedades dos produtos TEIXEIRA; BORBA; GHEYI (2013) para verificar a consistência ou presença de erros. Uma das formas existentes para facilitar o processo de derivação de produtos de uma LPS é através da utilização de ferramentas de instanciação, que facilitam a seleção, a composição e a configuração dos artefatos do núcleo e de suas respectivas variabilidades. Algumas ferramentas para derivação automática de produtos são propostas destas. Cita-se: Gen-Arc CIRILO; KULESZA; LUCENA (2007), pure::variants BEUCHE (2012) e Gears KRUEGER (2010).

Os defeitos de um software podem ser introduzidos em qualquer instante durante o processo de desenvolvimento. Portanto, as atividades de desenvolvimento do modelo de features ocorrem nos estágios iniciais do processo de desenvolvimento de software CZARNECKI; HELSEN; EISENECKER (2005). A reutilização de modelos features, quando executada de forma inadequada poderá gerar inconsistências no modelo pretendido, bem como causar retrabalho.

As dificuldades existentes na verificação de erros e inconsistência do modelo é uma tarefa dispendiosa e inviável para modelos de grande escala manualmente. TEIXEIRA; BORBA; GHEYI (2013); FARIAS et al. (2015a). Contudo, as técnicas e métodos de integração não são suficientemente eficazes e resultam tipicamente em modelos inadequados, apresentando eventuais incoerências e se tornando distinto do modelo desejado. Ou seja, ao realizar um processo de forma automática de integração sobre dois modelos de entrada (MF e MF), obtido através das iterações, espera-se produzir o modelo pretendido, MF. Entretanto este modelo não é atingido, resultando em um modelo inadequado, contendo inconsistências FARIAS et al. (2015a). As incoerências apresentadas são derivadas de deliberações errôneas ou equivocadas e exige a iteração manual sobre o modelo de features, assim determinado o modelo de features pretendido.

O processo de integração apresentado na Figura 2.4 é executado em duas etapas:A primeira etapa, corresponde em aplicar a (1) técnica de comparação sob o MF, e o MF, obtendo o MF, representado pela equação (MF, MF). A realização do esforço adicional para analisar as incoerências do modelo resultante é representada por (MF, MF). Após, aplicando as (2) técnicas de integração de forma a solucionar os conflitos (MF) OLIVEIRA (2012).

Adaptado de Oliveira (2012).
Figura 2.4: Processo de integração de modelo de features.

A integração entre dois modelos de features é dada pela comparação entre os modelos de modo a verificar as diferenças dos conjuntos, logo após é aplicado a sua composição, ou seja, a união entre os modelos, gerando um novo modelo, o modelo pretendido. A Figura 2.5 apresenta um exemplo de integração entre dois modelos, bem como o resultado desta união. Nesse exemplo conforme mencionado anteriormente, o processo de integração ocorre, na entrada de dois modelos (MF e MF), ou seja, quando pretende-se derivar um novo modelo o MF. Um fato que deve-se levar em consideração durante o processo de integração é que todas as subfetures derivadas da integração destes produtos devem ser obrigatórias, sendo o passo seguinte a comparação entre os dois modelos o qual pode-se observar que o primeiro modelo, MF a feature raiz é representada pelo produto A e subfeature B, D e E, que apresenta um relacionamento obrigatório e outro opcional, já o segundo modelo, MF, apresenta o produto A e subfeatures C, D e E ambas obrigatórias, durante esta etapa ocorre a verificação de similaridade entre os modelos.

Elaborado pelo Autor.
Figura 2.5: Exemplo de integração de modelo de features.

A Figura 2.6 exibe a comparação entre os dois modelos verifica aspectos sintáticos e semânticos; os sistemas de configuração de produto são baseados na variabilidade do modelo e seu desenvolvimento é um processo demorado e sujeito a erros ACHER et al. (2010); OLIVEIRA (2012); LESTA; SCHAEFER; WINKELMANN (2015) considerando o desenvolvimento contínuo de produtos deve-se adaptar frequentemente os modelos, elevando a possibilidade de erros em sua integração, gerando produtos indesejáveis. O primeiro aspecto considerado neste exemplo refere-se à similaridade sintática entre os modelos, MF e MF.

Elaborado pelo Autor.
Figura 2.6: Exemplo de integração de modelo de features conflitante.

As contradições surgidas durante a integração quando executadas automaticamente sem a intervenção humana acabam por propagar erros, impactando diretamente na qualidade do produto, assim como no esforço e custos para refazer a tarefa. Assim, verifica-se a ausência de ferramentas que deem suporte, bem como heurísticas para determinar restrições de integração de modelos LESTA; SCHAEFER; WINKELMANN (2015), diagnosticando a similaridade entre os produtos.

O grande diferencial da abordagem da LPS é a apreensão na definição do escopo de produtos derivados de outras linhas conforme as estratégias de mercado e negócios, prospectando vantagens em curto prazo. Deste modo as familiais de produtos tornam-se atrativas para indústria, conforme é apresentado no hall of fame111http://www.splc.net/fame.html em Software Product Line Conferences, o principal fórum na área de engenharia de software de linhas de produto, que fazem parte empresas como Bosch Group, Hewlett Packard, Siemens entre outros.

3.1 Mapeamento Sistemático da Literatura

No âmbito deste trabalho, aplicou-se um estudo de mapeamento sistemático, metodologia proposta através do paradigma baseado em evidências que orienta na análise e desenvolvimento de um tema de pesquisa KITCHENHAM et al. (2010), visando apresentar uma visão geral de uma área de pesquisa, identificando o tipo de pesquisa, seus resultados e a quantidade de publicações disponíveis GONÇALES et al. (2015).

Na execução da busca pelos artigos candidatos, no âmbito de responder as questões de pesquisa localizou-se 775 estudos sendo estes pesquisados em 06 bases cientificas para obter uma classificação com maior relevância, após aplicação dos filtros através de palavras-chave e uma leitura densa dos artigos finais selecionou-se 34 publicações.

Nas subseções subsequentes apresentamos as diretrizes estabelecidas, detalhado as questões de pesquisa investigadas, definição dos critérios de inclusão e exclusão utilizados para a seleção dos estudos primários, os procedimentos de extração dos dados, assim como, as estratégias de pesquisa descrita no decorrer desta leitura, e por fim, apresentamos os resultados obtidos através desta pesquisa.

3.1.1 Questões de Pesquisa

Para investigar as abordagens existentes sobre integração de modelos de features, no contexto de Linhas de Produto de Software, especificamente na derivação de produtos, no que tange à definição, do uso de processos e métodos empregados para implantação e execução das atividades de integração entre os modelos, definiram-se seis Questões de Pesquisa (QP) para serem investigadas. Assim, este estudo essencialmente tenta criar uma visão panorâmica do estado da arte sobre integração de modelos de features.

  • QP1: Quais são as notações usadas para modelar features?

  • QP2: Quais são as estratégias de comparação utilizadas para identificar a equivalência entre os modelos de features?

  • QP3: Quais são as técnicas utilizadas para realizar a integração entre os modelos de features?

  • QP4: Quais são as técnicas utilizadas para configurar e validar inconsistências do modelo de features?

  • QP5: Quais são os tipos de ferramenta que suportam as técnicas de integração de modelos de features?

  • QP6: Quais são os tipos de métodos de pesquisa mais utilizados?

Estas questões de pesquisa são motivadas pela necessidade de: Analisar as notações usadas para representar modelos que expressam variabilidade. (QP1) - Notações de Feature; Mapear e descobrir quais técnicas e os aspectos de comparação são usadas para identificar equivalências entre os elementos do modelo de entrada. (QP2)- Técnicas de Comparação; Conhecer e classificar as técnicas para integrar modelos de features (QP3) - Técnicas de Integração; Verificar quais as técnicas adotadas para validar e configurar a variabilidade os modelos de features (QP4) - Técnicas de Verificação e Validação; Examinar quais técnicas de suporte são empregadas para integrar modelos de features (QP5) - Técnicas de Integração; Por fim, identificar os métodos de pesquisa utilizados para investigar os modelos de integração (QP6)- Métodos de Pesquisa.

3.1.2 Estratégia de Pesquisa

A próxima etapa realizada foi a busca de estudos primários, sendo que estes estão relacionados diretamente com as questões de pesquisa investigadas, explicadas anteriormente. As estratégias de busca foram imparciais e iterativas sendo estas definidas com base nas orientações estabelecidas na literatura, conforme KITCHENHAM et al. (2010), que explica os procedimentos relacionados com a construção de string de busca e as definições do escopo da pesquisa. A estratégia de pesquisa visa elaborar de forma interativa uma lista de estudos primários, incluindo revisões sistemáticas da literatura, estudos de mapeamento e pesquisas.

Executaram-se as seguintes etapas para definir a string de busca: (1) definir as principais palavras-chave; (2) identificar palavras alternativas, sinônimos ou termos relacionados com as principais palavras-chave; (3) verificar se as principais palavras chave estão contidas nas estratégias de busca e categorias de pesquisa; e (4) sinônimos associados, palavras alternativas ou termos com os operadores lógicos "AND"e "OR".

As principais palavras chaves investigadas neste estudo são “Integrate”, “Feature”, “Model” e “Tools”. Apresentasse a seguir a string de busca que retornou os melhores resultados na sua aplicação a seguir:

((Merging OR Integration OR Composition) AND

(Feature OR Functionality OR Characteristic) AND

(Model OR Design OR Diagram) AND

(Tools OR Applicable OR Procedure OR Techniques))

Selecionaram-se as seis principais bases eletrônicas (ACM Digital Library, IEEE, Google Scholar, Scopus, Springer Link e Science Direct) para realizar a pesquisa para os estudos primários. Ressalta-se que a pesquisa realizada com a string de busca levou em consideração artigos, relatórios técnicos, trabalhos em curso, anais de conferências, revistas, e listas de referência de estudos primários relevantes, portanto, a busca inicial encontrou 775 estudos potencialmente relevantes. As fontes de pesquisa de dados citadas na Tabela 3.1, em sua grande maioria destacam-se por serem amplamente utilizadas para pesquisa na área da computação, sendo estas reconhecidas por sua abrangência e relevância significativa na área de estudo.

Fontes de Dados Endereço Eletrônico 1 - ACM Digital Library http://portal.acm.org/ 2 - IEEE Xplore http://ieeexplore.ieee.org/ 3 - Google Scholar https://scholar.google.com 4 - Scopus http://www.scopus.com/ 5 - Springer Link http://www.springerlink.com/ 6 - Science Direct http://www.sciencedirect.com Elaborada pelo autor.
Tabela 3.1: Fonte de dados científicos.

3.1.3 Critérios de Inclusão e Exclusão

Esta seção define os critérios utilizados para incluir e excluir os estudos, considerados relevantes às questões de pesquisa investigados. Como Critérios de Inclusão (CI), foram considerados os estudos que: propõem técnicas de integração de modelos de features (CI1); publicações escritas em Inglês (CI2); estudos publicados entre janeiro/2004 e dezembro/2015 (CI3); e disponíveis em bibliotecas digitais e eletrônicas (CI4).

Em seguida, aplicaram-se os Critérios Exclusão (CE), desconsiderando-se as publicações que: encontrem-se duplicadas em mais de uma fonte de busca, onde será considerada a versão atual; (CE1); publicações que não são publicadas em inglês (CE2); publicações que não mencionem as palavras-chave da pesquisa no título, resumo ou palavras-chave do artigo (CE3); publicações consideradas como resumo, chamadas de conferência ou patentes (CE4); publicações que estejam fora do contexto de engenharia de linhas de produtos (CE5); e finalmente, publicações que não cumpram a motivação das questões de pesquisa descritas na subseção 3.1.1(CE6).

3.1.4 Extração de Dados

Esta etapa está concentrada na extração de dados a partir de estudos preliminares para análise posterior, uma vez que um dos propósitos do estudo de mapeamento sistemático é produzir provas na área sobre o estudo investigado KITCHENHAM; BUDGEN; BRERETON (2011). A extração dos dados visa identificar, avaliar e analisar os estudos primários sobre as questões de pesquisa discutidas anteriormente na subseção 3.1.1.

Utilizou-se de planilhas em Excel através de um formulário proposto por fernandez2013 para armazenar os dados coletados com o objetivo de produzir informação para implementar uma análise estatística dos estudos de acordo com a Figura 3.1. Conforme mencionado anteriormente, o objetivo deste estudo é entender, caracterizar e resumir o estado da arte das técnicas de integração de modelos de features. A análise dos dados foi realizada em ciclo de revisão, com o pesquisador e o auxílio dos professores orientadores para evitar falsos positivo/negativo e para cobrir as questões relevantes e ainda em aberto.

Adaptado de Fernández (2013).
Figura 3.1: Fonte de dados científicos.

Notações de Features (QP1). Os modelos de features exibem um conjunto de diagramas, formando uma arvore conectando-se por meio das relações entre seus nós, isto é, features. A seguir são apresentadas as notações derivadas dos estudos investigados, incluindo Feature-Oriented Domain Analysis (FODA), Feature-Oriented Reuse Method (FORM), Cardinality-based Feature Modeling (CBFM), Reuse-Driven Software Engineering Business Features (RSEB), Product Line Use Case Modeling for Systems and Software Engineering (PLUSS), Common Variability Language (CVL), Text-based Variability Language (TVL), AoURN-based Software Product Line (AoURN), Orthogonal Variability Model (OVM), the Model-Driven Product Lines Engineering (AMPLE), Generative Programming (GP) and Feature Oriented Product Line Software Engineering (FOPLE).

Técnicas de Comparação (QP2). A literatura propõe um conjunto de operações para comparação e avaliação das diferenças encontradas entre os modelos de features. Deste modo identificaram-se as seguintes técnicas recomendadas pela literatura: (1) sintática, para equiparar a sintaxe entre as features; (2) semântica com a finalidade de comparar estrutura bem como o significado dos elementos presentes entre os modelos; (3) multi-estratégias, que abordam varias estratégias para melhorar o resultado final da similaridade entre os modelos comparados.

Técnicas de Integração (QP3). A integração entre dois modelos de features é o resultado da combinação de ambos os elementos presentes nos diagramas de features com a finalidade de produzir um novo modelo. Identificaram-se as seguintes operações responsáveis por executar a integração entre os modelos. (1) união, as diferenças entre os modelos de entrada são inseridos no modelo integrado e as semelhanças encontradas são adicionadas sem a repetição dos elementos comuns, por exemplo, MF MF; (2) intersecção, o modelo integrado tem apenas os elementos comuns entre os diagramas de features, desconsiderados os elementos incomuns entre os modelos comparados, por exemplo, MF MF ; (3) diferença, verifica a diferença entre os diagramas features comparados, retornando os elementos pertencentes MF incomuns a MF, isto é, MF - MF. Observou-se que nos estudos investigados em alguns casos há pelo menos a aplicação de duas abordagens para melhorar a precisão das técnicas de integração.

Técnicas de Configuração e Validação (QP4). A formalização bem como a validação dos modelos de features nos estudos investigados assinalam as seguintes técnicas usadas na formalização dos modelos, (1) lógica proposicional, (2) lógica descritiva ou (3) programação restritiva assim como se utiliza de solucionadores e algoritmos para detectar possíveis inconsistências encontradas na formação do modelo em análise. Através dos estudos analisados identificaram-se os seguintes algoritmos aplicados na verificação dos modelos: (1) Famílias de Produtos da Álgebra (FPA); (2) Diagramas de Decisão Binária (BDD); (3) Problema de Satisfação Booleana (SAT); (4) Problemas de Satisfação de Restrições (CSP); (5) Forma Normal Conjuntiva (FNC), (6) Forma Normal Disjuntiva (FND); e (7) Multicritério, estudos que combinam diversas estratégias abordas para melhorar os resultados de integração.

Suporte Ferramental (QP5). A fim de conhecer os tipos de apoio ferramental fornecido para as equipes de desenvolvimento, investigou-se os trabalhos a partir de três perspectivas: 1) automático, que não requer qualquer interação humana; (2) semiautomático, ele requer que os desenvolvedores especifiquem os parâmetros de configuração diferenciando os elementos de entrada do modelo. Esta abordagem requer intervenção do desenvolvedor para o tratamento de procedimento de avaliação; e (3) etapas manuais para listar como as boas práticas conduzem o processo de integração dos elementos do modelo (por exemplo, features e suas notações).

Métodos de Pesquisa (QP6). Esta questão de pesquisa fornece uma visão geral sobre o direcionamento dos estudos atuais, ou seja, quais os tipos de estudos investigados foram produzidos ao longo destes anos. Devido a grande quantidade de estudos para serem classificados nos estudos primários a abrangência dos métodos de pesquisa é definida conforme as categorias propostas em KITCHENHAM et al. (2010); WIERINGA et al. (2006). Este estudo é classificado da seguinte forma: (1) solução proposta, propõe uma solução baseada em novos estudos ou estudos anteriores; (2) pesquisa de avaliação, avalia a aplicação de técnicas e os conceitos de estudos empíricos; (3) pesquisa de validação, concentra seus esforços em avaliar as técnicas desconhecidas pela indústria; (4) artigos de opinião, estudos que ampliam a discussão abordando o ponto de vista de seus autores sobre o problema de pesquisa e as possíveis soluções; (5) artigos filosóficos, aborda novas técnicas e estudos inéditos, propondo uma discussão sobre a metodologia aplicada; e (6) artigos de experiência, abordam estudos de experiência pessoal, investigações de ferramentas próprias aplicadas no contexto do autor, evidenciando seu aprendizado.

3.1.5 Seleção dos Estudos

Esta subseção apresenta o processo de execução dos filtros dos estudos selecionados, descrevendo os passos para alcançar os estudos primários. Aplicaram-se sete etapas para filtrar os estudos relevantes depois de fazer uma pesquisa inicial. A busca e filtragem foram executadas entre janeiro e fevereiro de 2016. A Figura 8 exibe as etapas do processo de seleção dos estudos relevantes, bem como da execução dos filtros, que são descritos da seguinte forma:

  • Etapa 1: pesquisa inicial. Reúne uma lista ampla de estudos após a aplicação da estratégia de pesquisa, conduzida através da busca de palavras-chave, realizado nas seis bibliotecas digitais definidas de acordo com a Tabela 1. Ao todo foram identificados 775 estudos;

  • Etapa 2: remoção dos artigos duplicados. Consiste na aplicação do critério de exclusão CE1, ou seja, estudos repetidos foram descartados em cada uma das bibliotecas pesquisadas;

  • Etapa 3: filtro por título: Este filtro procura estabelecer uma analise introdutória através dos títulos das publicações investigadas verificando sua relação com a linha de pesquisa em curso, ou seja, integração de modelos de features, aplicaram-se os seguintes critérios de exclusão CE2 e CE3.

  • Etapa 4: filtro por resumo: Este filtro é fundamental para determinar os estudos relevantes para esta pesquisas, pois apresenta um visão panorâmica dos estudos investigados. Aplicaram-se os critérios de exclusão CE4 E CE5.

  • Etapa 5: combinação: Todos os estudos filtrados a partir das fases anteriores foram agrupados em um novo diretório. Aplicou-se novamente o critério de exclusão CE1, para remoção de publicações duplicadas;

  • Etapa 6: filtro por texto completo: Selecionou-se os estudos através da leitura completa dos textos, a fim de verificar o conteúdo definido na seção de extração de dados, com ênfase em responder às questões de pesquisa inerente a este estudo, a aplicação do critério de exclusão CE 6;

  • Etapa 7:estudos representativos: A lista final dos estudos primários é definida após revisar todas as etapas anteriores e os critérios de inclusão e exclusão.

Elaborado pelo autor.
Figura 3.2: Processo de seleção dos estudos relevantes.

Após a aplicação das etapas inerentes a execução dos filtros, os resultados retornados na primeira etapa, (Etapa 1) totalizaram-se 775 (100%) publicações, já a segunda etapa (Etapa 2), removem-se as publicações duplicadas obtendo 739 (95,35%) publicações, isto é, reduzindo-se 36 publicações (4,65%) a partir do total de 775. Seguindo a terceira etapa (Etapa 3), aplicaram-se os critérios de inclusão e exclusão aos demais estudos, filtrando 417 publicações (56,42%), assim como, analisaram-se os títulos das publicações, reduzindo 322 (43,57%) publicações de um total de 739 publicações e finalmente 97 (13,13%) publicações após executar filtro do resumo (Etapa 4 e Etapa 5) das publicações analisadas, removendo 320 (76,73%) publicações de 417. Na etapa consecutiva (Etapa 6) realizou-se uma análise criteriosa destas publicações de modo geral, sendo desconsideradas as publicações irrelevantes as questões de pesquisa formulada anteriormente, reduzindo 63 (64,94%) publicações. Finalmente, selecionou-se 34 publicações, as publicações mais representativas (Etapa 7), constituindo 4,60% a partir de 775 publicações iniciais localizadas. A lista completa dos estudos primários selecionados encontra-se no apêndice A deste trabalho.

3.2 Resultados

Após a análise dos 34 estudos primários selecionados aplicando as etapas de filtragem anteriormente descritas, nesta seção são apresentados e interpretados os dados obtidos. O objetivo deste estudo procura entender, caracterizar e resumir o estado da arte sobre os assuntos relacionados à integração de modelos de features. Assim, aborda-se cada questão de pesquisa conforme sua descrição na subseção 3.1.1.

QP1: Notações de Features. Esta questão de pesquisa busca investigar as notações usadas para representar os modelos de features. O objetivo da modelagem das features é exibir as propriedades comuns e variáveis dos produtos possíveis de uma LPS. A Tabela 3.2 apresenta os dados obtidos em relação ás expressões utilizados na representação dos diagramas de features. Os dados indicam que a FODA é a notação preferida de modelagem para representar os diagramas de features, 44% (15/34) dos estudos primários. A notação FORML foi utilizada em apenas 3% (1/34) dos estudos investigados. Além disso, as demais notações investigadas, FORM, CBFM, RSEB, PLUSS, CVL, TVL, entre outras são distribuídas em ambos os estudos, isto é, apresentam-se em mais de um estudo, representando 32% (11/34) dos estudos primários. Finalmente, 21% (7/34) dos artigos não mencionaram ou sugeriu qualquer notação.

Notação Número Percentual ID Artigos
FODA 15 44% [S01],[S03],[S04],[S05],[S06], [S09],[S17],[S19],[S20],[S22], [S23],[S24],[S28],[S29],[S34]
FORML 1 3% [S07]
Outras Notações 11 32% [S02],[S10],[S11],[S14],[S16], [S21],[S25],[S26],[S27],[S30], [S32]
Notações não especificadas 7 21% [S08],[S12],[S13],[S15],[S18], [S30],[S32]
Total 34 100%
Elaborada pelo autor.
Tabela 3.2: Notações de features

A Figura 3.3 apresenta uma árvore com a evolução das técnicas empregadas para modelagem dos diagramas de features, onde a notação FODA foi a primeira técnica proposta por kang1990, sendo que as demais técnicas empregadas ao longo dos anos foi uma mutação desta, como por exemplo, RSEB GRISS; FAVARO; D’ALESSANDRO (1998), FORM KANG et al. (1998), GP CZARNECKI; EISENECKER (2000), Hein HEIN; SCHLICK; VINGA-MARTINS (2000), Gurp VAN GURP; BOSCH; SVAHNBERG (2001), GPEXT CZARNECKI et al. (2002), Riebisch RIEBISCH et al. (2002), CMBF CZARNECKI; HELSEN; EISENECKER (2004), Benavides BENAVIDES; TRINIDAD; RUIZ-CORTÉS (2005), PLUSS ERIKSSON; BÖRSTLER; BORG (2005), OVM POHL; BÖCKLE; DER LINDEN (2005), TVL CLASSEN; BOUCHER; HEYMANS (2011), CVL REINHARTZ-BERGER; FIGL; HAUGEN (2014), que sugere a necessidade de melhorias aplicadas à modelagem de features nas LPS ao longo dos anos.

Fonte: Elaborado pelo autor.
Figura 3.3: Representação hierárquica das notações de features.

QP2: Técnicas de Comparação. Esta questão investiga as estratégias utilizadas na literatura para comparar e identificar a equivalência entre os dois modelos features de entrada. A saída desta etapa serve como base para a próxima etapa de composição. Em seguida, os aspectos utilizados nesta etapa têm um forte impacto nos resultados da composição. A técnica de composição irá integrar elementos dos modelos de features incorretamente se forem definidas relações de equivalência incorretas.

Técnicas de Comparação Número Percentual ID Artigos
Sintática 4 12% [S02],[S20],[S21],[S22]
Semântica 7 21% [S03],[S11],[S14],[S18],[S24], [S29],[S31]
Multi-estratégia 4 12% [S09],[S17],[S32],[S34]
Não especificado 19 55% [S01],[S04],[S05],[S06],[S07], [S08],[S10],[S12],[S13],[S15], [S16],[S19],[S23],[S25],[S26], [S27],[S28],[S30],[S33]
Total 34 100%
Elaborada pelo autor.
Tabela 3.3: Técnicas de comparação.

A Tabela 3.3 apresenta os dados obtidos nesta pesquisa sobre as técnicas de comparação. Em primeiro lugar, poucas técnicas de comparação foram propostas para avaliar as equivalências entre os modelos de características de entrada. Em suma, apenas as estratégias semântica e sintática foram propostas. Os resultados mostram que 21% (7/34) dos estudos primários se concentram na proposição de estratégia semântica, e 12% (4/34) visam à estratégia sintática. Além disso, 12% (4/34) dos artigos propõem ambas as técnicas denominadas de multi-estratégia, isto é, aplicam estratégias semânticas e sintáticas para definir a similaridade. Finalmente, a maioria dos estudos 55% (19/34) não propõe qualquer técnica de comparação.

QP3: Técnicas de Integração. Esta questão investiga as técnicas atuais aplicadas à integração de modelos de recursos. Conforme mencionado anteriormente, a etapa de integração combina as features equivalentes e, em seguida, produz o modelo de features integrado (MF,). Em geral, existem heurísticas de composição bem conhecidas para a composição do modelo. Contudo, até onde se sabe as heurísticas de composição específicas para a integração de features não têm sido amplamente discutidas até agora.

Técnicas de Integração Número Percentual ID Artigos
União 7 21% [S03],[S04],[S07],[S08],[S09], [S15],[S23]
Interseção - - [S03],[S04],[S07],[S08],[S09], [S15],[S23]
Diferença - - [S04],[S09]
Não especificado 27 79% [S01],[S02],[S05],[S06],[S10], [S11],[S12],[S13],[S14],[S16], [S17],[S18],[S19],[S20],[S21], [S22],[S24],[S25],[S26],[S27], [S28],[S29],[S30],[S31],[S32], [S33],[S34]
Total 34 100%
Elaborada pelo autor.
Tabela 3.4: Técnicas de integração.

A Tabela 3.4 mostra os resultados obtidos nesta pesquisa sobre as técnicas de integração. Os resultados demonstram que três técnicas são comumente usadas em conjunto para integrar modelos de features. As técnicas correspondentes são a união, a intersecção e diferença especificamente. Os resultados mostram que 21% (7/34) dos estudos primários fazem uso da estratégia de união, estratégia de interseção, e estratégia de diferença como uma forma de compor os modelos de features. Uma minoria de estudos (6%, 2/34) adiciona especificamente a técnica de diferença. Finalmente, a maioria dos estudos (79%, 27/34) não propõe nenhuma técnica de integração. Esse resultado sugere que trabalhos recentes não estão se concentrando em propor técnicas de integração para modelos de recursos.

QP4: Técnicas de Configuração e Validação. A etapa de validação é responsável pela identificação de inconsistências no modelo de feature integrado. Para resolver esse problema, os modelos de features são analisados para verificar se as regras de formação são satisfeitas ou não. Técnicas como solucionador SAT e solucionador CSP são alguns exemplos.

A Tabela 3.5 mostra as técnicas aplicadas na literatura para validação e verificação de modelos de features. Pôde-se observar que 3% (1/34) investigaram o algoritmo do problema de satisfação de restrições (CSP) e 6% (2/34) de estudos primários aplicaram o algoritmo do problema de satisfação booleana (SAT). Estudos multicritérios são aqueles que se aplicam ou sugerem mais de uma estratégia, correspondendo a 24% (8/34) dos estudos investigados.

Estratégias de Validação Número Percentual ID Artigos
CSP 1 3% [S14]
SAT 2 6% [S18],[S29]
Multicritério 8 24% [S02],[S09],[S20],[S24],[S25], [S30],[S32],[S34]
Não especificado 23 68% [S01],[S03],[S04],[S05],[S06], [S07],[S08],[S10],[S11],[S12], [S13],[S15],[S16],[S17],[S19], [S21],[S22],[S23],[S26],[S27], [ S28],[S31],[S33]
Total 34 100%
Elaborada pelo autor.
Tabela 3.5: Técnicas de configuração e validação.

Essas técnicas geralmente combinam SAT, CSP e outras estratégias de validação para melhorar a análise de inconsistência. Pesquisas e revisões da literatura são também alguns dos estudos que são relatados aqui, e cobrem mais de uma técnica da validação. Finalmente, a maioria dos estudos (68%, 23/34) não propõe nenhuma técnica de validação. Alguns estudos alegaram que o número de trabalhos sobre a abordagem de validação de modelos de features aumentou BENAVIDES; SEGURA; RUIZ-CORTÉS (2010); ANDERSEN et al. (2012); BENAVIDES et al. (2013); EICHELBERGER; KRÖHER; SCHMID (2013). Embora tenha sido encontrado um número relevante de abordagens para validar os modelos neste estudo, à maioria deles (68%, 23/34) não mencionou qualquer tipo de técnica de validação. Finalmente, também é importante ressaltar que uma execução eficiente da etapa de validação depende do tamanho do modelo analisado. Então, melhorar a eficiência na validação de grandes modelos é um importante desafio de pesquisa.

QP5: Suporte Ferramental. Esta questão tem como objetivo investigar os tipos de ferramentas de suporte fornecidas para todo o processo de integração de modelos de features. Identificaram-se três categorias: (1) automáticas, isto é, aquelas ferramentas que não suportam interferência humana; (2) semiautomáticas, as técnicas que permitem a interação entre o homem e a máquina; (3) o processo de integração é conduzido sem qualquer tipo de suporte ferramental, ou seja, é executado de forma manual.

Suporte Ferramental Número Percentual ID Artigos
Automático 20 59% [S01],[S02],[S04],[S06],[S07], [S09],[S12],[S13],[S14],[S15], [S18],[S19],[S20],[S21],[S22], [S24],[S25],[S29],[S30], [S34]
Semiautomático 2 6% [S05],[S28]
Manual 0 0%
Não especificado 12 35% [S03],[S08],[S10],[S11],[S16], [S17],[S23],[S26],[S27],[S31], [S32],[S33]
Total 34 100%
Elaborada pelo autor.
Tabela 3.6: Suporte ferramental.

A Tabela 3.6 apresenta as categorias de automação propostas pela literatura. Os resultados mostram que 59% (20/34) dos estudos primários apresentam ferramentas que fornecem suporte automatizado, 6% (2/34) dos estudos propostos apresentam ferramentas com apoio semiautomático. Além disso, não foi encontrado nenhum estudo sobre técnicas manuais. Finalmente, 35% (12/34) dos estudos investigados não propõem suporte à ferramenta.

É importante ressaltar que não foi encontrado nenhum experimento para avaliar os desenvolvedores durante a aplicação das técnicas de integração manual. Esse tipo de experimento seria importante para demonstrar empiricamente a importância do auxílio computacional na integração de modelos de features. Embora as ferramentas automáticas sejam as mais aplicadas não foi encontrada nenhuma evidência que comprove sua eficácia. O algoritmo aplicado para resolver modelos indesejados e erros propagados durante uma má integração pode ter impacto nos custos de produção. Por fim, as ferramentas semiautomáticas propostas na literatura não fizeram um diagnóstico de conflitos durante a comparação e também não permitem a edição de modelos de features durante o processo de integração.

QP6: Métodos de Pesquisa. Classificam-se os estudos primários com base nos métodos de pesquisa definidos em WIERINGA et al. (2006); PETERSEN et al. (2008) tais como: (1) Proposta de solução, propõe uma nova solução; (2) Pesquisa de avaliação, realiza estudos empíricos; (3) A pesquisa de validação, valida técnicas em um ambiente da indústria; (4) Artigos de opinião, uma opinião pessoal sobre um assunto específico em questão; (5) Artigo filosófico, propõe uma nova maneira de esboçar soluções; e (6) Artigos de Experiência, relata experiência ou lições aprendidas após usar uma técnica particular.

Métodos Número Percentual ID Artigos
Solução Proposta 24 70% [S01],[S02],[S03],[S04],[S06], [S07],[S08],[S09],[S11],[S12], [S14],[S15],[S17],[S18],[S20], [S23],[S24],[S25],[S26],[S27], [ S29],[S30],[S31],[S34]
Pesquisa de Avaliação 6 18% [S05],[S16],[S19],[S21],[S28], [S32]
Pesquisa de Validação 1 3% [S33]
Artigos de Opinião 1 3% [S10]
Artigos Filosóficos 1 3% [S22]
Artigos de Experiência 1 3% [S13]
Total 34 100%
Elaborada pelo autor.
Tabela 3.7: Métodos de pesquisa

A Tabela 3.7 mostra a classificação de estudos primários dos métodos de pesquisa. Os resultados indicam que a área de pesquisa com maior concentração de investigação dos estudos são as soluções propostas, com 70% (24/34), dos trabalhos analisados. Além disso, pouco tem sido feito para avaliar empiricamente as atuais técnicas de integração. As pesquisas e avaliação são apenas 18% (6/34) dos estudos investigados. Finalmente, pesquisa de validação, artigo de opinião, artigo filosófico e artigo de experiência compreendem em 12% (4/34) dos estudos investigados, evidenciando que a avaliação das técnicas tem sido amplamente baseada em reflexão e opinião de especialistas, e não em evidências empíricas.

3.3 Discussão Adicional

Esta seção tem duplo objetivo: (1) revelar quando e onde os estudos primários foram publicados, revelando assim tendências de pesquisa e explorando como os estudos primários são distribuídos considerando as questões de pesquisa específicas nos últimos anos; e (2) esboçar uma visão panorâmica destacando alguns desafios adicionais, que podem ser tomados como base para construir uma agenda de pesquisa. Como tal, isso pode ajudar a aumentar a literatura, ilustrando um grande quadro sobre o estado da arte.

Distribuição dos Estudos Primários. Para abordar o primeiro objetivo, obtivemos o ano de publicação e a fonte (ou seja, local) para cada estudo primário. Para isso, categorizamos todos os estudos primários para tipos de publicação: conferência, revista e workshop. A Figura 3.4 mostra uma cronologia para todos os estudos primários, a quantidade de estudos publicados por ano e o local usado para publicar o artigo (por exemplo, conferência, revista e workshop). Observe que o gráfico mostra a abreviatura da conferência, jornal e workshop em que o artigo foi publicado ao lado da identificação do artigo. A abreviatura ajuda a simplificar o gráfico e a linha tracejada encontrada na Figura 3.4 resume o número de estudos primários publicados entre os anos de 2004 a 2015.

Elaborado pelo autor.
Figura 3.4: Distribuição dos estudos primários.

Dado que em nenhum artigo foi identificado entre os anos de 2005 a 2008, o gráfico não descreve os resultados nesses anos. A partir de 2009, foram selecionados entre um a sete estudos primários por ano, demonstrando uma tendência ascendente gradual. De fato, de 2010 a 2015 pelo menos quatro artigos foram publicados. Isto significa que a academia investiu certo esforço para promover este campo de pesquisa, alcançando um pico de 7 artigos publicados em 2012 e 2013. Estes resultados ajudam a compreender o quanto a atividade de pesquisa sobre a integração de modelos de features ocorreu nos últimos anos, bem como o local onde os pesquisadores têm procurado publicar seus resultados de pesquisa.

Considerando o local onde os estudos primários foram publicados, há uma predominância de publicação em conferência (67,6%). Foram publicados onze artigos no SPLC (S02, S03, S10, S11, S13, S14, S16, S19, S26, S27, S31), sendo o local mais proeminente avaliado pelos pesquisadores para publicar seus artigos. O restante dos artigos foi publicado em diversas conferências. Dois estudos foram publicados em GPCE (S15, S18), CAISE (S13, S22), ICSR (S25, S30) e um estudo em ICSE (S05), RCIS (S33), MODELSWARD (S08), ICICS IRI (S20). Em seguida, uma menor quantidade de estudos primários foi publicada em Jornais (17,6%). Dois artigos foram encontrados a partir de SCP (S21, S32), e um artigo de IS (S20), JSS (S29), JCC (S23) e SOSYM (S12). Finalmente, 14,7% foram publicados em diferentes workshops, sendo dois publicados em MISE (S01, S07) e uns publicados em ME (S04), VAMOS (S28) e FMSPLE (S34).

Com base nos dados coletados, podemos elaborar duas observações. Em primeiro lugar, a falta de estudos primários em locais de topo (por exemplo, TSE, TOSEM) pode ser motivada, por sua vez, devido à ausência de resultados com base em uma série de estudos empíricos controlados, em vez de baseados em exemplos-brinquedos e preliminares estudos casos. Em segundo lugar, a pesquisa sobre o tema da integração de modelos de features tem mostrado uma tendência ascendente; No entanto, o número de publicações é ainda pequeno, por vezes inexistente em determinado período de tempo. Isto pode indicar duas direções possíveis: (1) uma vez que a integração de artefatos de software (por exemplo, código fonte, modelos conceituais, entre outros) é amplamente conhecida como um problema severo SCHAEFER et al. (2012), e o número de lacunas abertas é enorme, mais trabalhos de pesquisa devem estar em andamento. Portanto, novas publicações devem ocorrer nas próximas edições de conferências, workshops e revistas; (2) a saída de potenciais técnicas eficazes e revolucionárias deve ocorrer nos próximos anos, derivadas de técnicas teóricas, que não são sólidas. Hoje, não existe uma ferramenta fácil de usar e pronta para produção, enquanto a viabilidade comercial não está comprovada.

Vista panorâmica e outros desafios. Abordando o segundo objetivo, a Figura 6.3 apresenta um gráfico de bolhas, que é uma variação de um gráfico de dispersão. O eixo-x representa as questões de pesquisa consideradas, ou seja, a amplitude do método de pesquisa utilizado (à esquerda) e o tipo de técnicas propostas (à direita). O eixo-y representa o ano de publicação. Uma dimensão adicional dos dados é representada no tamanho das bolhas, o que representa o número de estudos primários publicados. A característica principal observada neste gráfico é a presença de um padrão de distribuição considerando o uso de métodos de pesquisa ao longo dos anos. Os trabalhos de "proposta de solução"têm sido os métodos de pesquisa mais adotados, sendo encontrados em 70% (24/34) dos estudos primários, enquanto que os demais métodos de pesquisa utilizados registraram os 30% dos casos restantes (10/34), distribuídos da seguinte forma: (3%, 1/34), artigos de experiência, (3%, 1/34), artigos de opinião, (3%, 1/34), pesquisa de validação (3%, 1/34) e pesquisa de avaliação (17%, 6/34). Esta superioridade pode significar que este campo de pesquisa ainda está em uma fase inicial, em que o número de trabalhos é predominantemente maior do que um relacionado à avaliação empírica. Além disso, observou-se que os estudos primários se concentraram principalmente na proposição de técnicas de verificação e validação (47%, 16/34), técnicas de comparação (33%, 11/34) e técnicas de integração representando (20%, 7/34 ).

Elaborado pelo autor.
Figura 3.5: Evolução das publicações em termos de temas de pesquisa ao longo dos anos.

Em 2012, apenas um dos sete artigos relacionados à execução da pesquisa de avaliação foi proposto, enquanto seis artigos publicados foram "proposta de solução", sendo quatro estudos sobre técnicas de integração, dois estudos explorando técnicas de verificação e validação e um estudo sobre técnicas de comparação. Além disso, sete estudos propõem técnicas de integração de modelos de features, abordando as técnicas de união, a interseção e diferença. Ressaltamos também que os estudos sobre integração de modelos de features são recentes, uma vez que foram publicados predominantemente nos últimos anos. Isso reforça que os estudos primários selecionados são pioneiros. De fato, apenas técnicas de conceito de projeção foram propostas, ao invés de técnicas conviviais e práticas, apoiadas em dados empíricos derivados de projetos de desenvolvimento de software convencionais. Esses dados são essenciais para apoiar os desenvolvedores a tomar decisões sobre a adoção (ou não) de tais técnicas em projetos de software convencionais, onde o tempo e o custo são apertados.

Analisando mais de perto as técnicas de integração, a maioria delas fornece abordagem primitiva. Mesmo que eles possam lidar com um conjunto de casos de integração elementar, suportando questões estruturais, sintáticas e semânticas, eles ainda são propensos a erros como casos de integração mais crítica não são devidamente apoiados. Na verdade, geralmente eles são incapazes de identificar a similaridade, ou diferenças, causada por mudanças de reestruturação. Este tipo de modificações é tipicamente encontrado em casos mais severos de evolução de modelos de features, que podem aparecer a partir das tarefas de refatoração ou do refinamento de features principais no SPL (por exemplo, incluindo, alterando ou excluindo features devido à mudança de requisitos do projeto). Uma direção de pesquisa muito interessante é sobre como melhorar a comparação técnica entre os modelos de features, que estão cientes das mudanças estruturais, sintáticas e semânticas na evolução de novos modelos.

Observa-se que a integração de modelos de features depende de uma etapa crítica, a saber, a comparação entre os elementos do modelo seguindo uma abordagem única e multi-estratégica, onde se podem contemplar questões estruturais, sintáticas, semânticas, léxicas e de layout. Se o nível de detalhe para comparar modelos de features puder ser ajustado, os desenvolvedores comparariam modelos de fetaures em diferentes níveis de abstração. Isso permitiria ter um melhor controle sobre os tipos de alterações conflitantes que poderiam ocorrer.

Além disso, outra direção de pesquisa interessante seria a falta de conhecimento empírico sobre a aplicação das técnicas atuais. A avaliação tem sido largamente baseada na reflexão e na opinião de especialistas, em vez de provas derivadas de estudos empíricos (por exemplo, estudos de caso, experiência controlada e quase experimental). Em kleinner2012, farias2015, os autores apontam que as técnicas de integração têm sido largamente baseadas na opinião de especialistas (evangelista), em vez de experiências de conhecimento prático. Infelizmente, as opiniões dos especialistas geralmente divergem. Como tal, questões mais práticas sobre a integração de modelos de features devem ser exploradas em ambientes reais. Ou seja, pouco se sabe sobre o esforço que os desenvolvedores investem para integrar modelos de features, bem como eles lidam com conflitos entre os elementos dos modelos de features a serem integrados.

Se os conflitos entre os elementos de entrada dos modelos de features forem resolvidos de forma inadequada, os desenvolvedores serão capazes de lidar com defeitos (ou inconsistências). Dado que as técnicas atuais de modelagem não são para detectar e resolver um amplo espectro de conflitos, os desenvolvedores acabam tendo que lidar com modelos de features com problemas. Com isso em mente, uma lacuna importante no conhecimento sobre o uso de modelos de features está relacionada aos efeitos na produção de modelos de má qualidade (por exemplo, esforço, compreensibilidade e reutilização) na prática.

3.4 Ameaças à Validade

Esta seção discute as estratégias utilizadas para mitigar algumas ameaças à validade, ou seja, a confiabilidade dos resultados obtidos no processo de investigação, sendo considerada a validade de construção, validade externa e interna, e por fim, a validade de conclusão WOHLIN et al. (2000); KITCHENHAM et al. (2010); KITCHENHAM; BUDGEN; BRERETON (2011).

Validade de construção. Considera os relacionamentos entre a teoria e a observação, consiste em evidenciar os resultados obtidos durante a investigação com os resultados pretendidos em sua elaboração. Dado que a execução de um estudo de mapeamento sistemático retorna uma extensa lista de artigos publicados, um risco comum é não incluir todos os estudos relevantes. Para atenuar esta ameaça, seguiram-se as diretrizes estabelecidas para definir palavras-chave e a string busca, aplicando estas às bases de dados eletrônicas (Biblioteca Digital ACM, IEEE, o Google Scholar, Scopus, Springer Link e Science Direct).

Validade interna. Poderá ser influenciada por medições incorretas ou instrumentos inadequados prospectando possíveis diferenças entre os resultados. A validação esta relacionada aos filtros de investigação que determinam a análise desta pesquisa, para evitar esta ameaça, aplicou-se seis etapas conforme segue: (1) pesquisa inicial, através da string de busca (2) remoção dos artigos duplicados, (3) filtro por título das publicações conforme palavras-chave, (4) filtro por abstrato das publicações, realizando uma leitura previa destas verificando já as questões de pesquisa investigadas, (5) combinação das publicações, ou seja, agrupamentos após a execução filtros e finalmente (6) filtros por texto, isto é, uma densa leitura dos artigos selecionados, para após obter o numero de artigos selecionados, dos quais as questões de pesquisa investigadas estão relacionadas diretamente a estas.

Validade externa. Considera até que ponto os resultados são generalizáveis, limitando os resultados do estudo para contextos dentro do ambiente avaliado. As ameaças mais comuns à validade externa são selecionar amostras não representativas quantitativamente ou qualitativamente e adotar matérias ou instrumentos distantes da realidade. Para evitar estas ameaças seguiram-se as etapas descritas na literatura sobre revisão sistemática, definindo um escopo apresentado neste trabalho, no contexto de integração entre modelos de features, desta forma minimizando as dificuldades em reproduzir as etapas de investigação próprias deste trabalho, ou seja, dentro deste universo restrito.

Validade de conclusão. Por fim, realizou-se um diagnóstico dos resultados da investigação, apurando a confiabilidade destes, intensificando sua veracidade, garantido a consistência e a precisão desta investigação. Para isso, seguiram-se rigorosamente os passos descritos na literatura PETERSEN et al. (2008); KITCHENHAM et al. (2010); KITCHENHAM; BUDGEN; BRERETON (2011) para uma boa condução deste estudo de mapeamento sistemático, assim como a correta análise e interpretação das questões de pesquisa investigadas.

3.5 Novas Direções de Pesquisa

Este trabalho procurou compreender, caracterizar e resumir o estado da arte sobre técnicas de integração de modelos de features. Para isso, realizamos um estudo de mapeamento sistemático para investigar seis questões de pesquisa. Selecionou-se 34 estudos primários aplicando um cuidadoso processo de filtragem em uma amostra de 775 estudos pesquisados em 6 bases de dados eletrônicas (escopo de pesquisa).

Resumisse os principais achados da seguinte forma. Em relação às notações utilizadas, a maioria (44%, 15 de 34) dos estudos escolheu a Análise de Domínios Orientada a Features (Feature-Oriented Domain Analysis – FODA) para modelagem de diagramas de features. Este resultado mostra uma forte preferência do meio acadêmico em usar esta notação. Portanto, ainda não existem investigações que considerem tanto as etapas de comparação como as de integração. A comparação das técnicas dos modelos propostos na literatura abrangeu estratégias sintáticas (12%, 4 de 34 estudos) e semânticas (21%, 7 de 34 estudos). Em relação às técnicas de integração de modelos de features, verificou-se que a maioria dos estudos se concentra na proposição de estratégias de união (21%, 7 de 34) e interseção (21%, 7 de 34). Além disso, uma pequena parte dos trabalhos 6% (2 de 34 estudos) propôs a estratégia de diferenciação.

Os resultados referentes às técnicas de validação mostraram que existem diversos tipos de estratégias de validação, isto é, técnicas como SAT, CSP, BDD, CNF e DNF foram discutidas em 24% (8 de 34) dos estudos em conjunto. Além disso, há também artigos argumentando sobre SAT (6%, 2 de 34 estudos) e CSP (3%, 1 de 34 estudos) exclusivamente. Os resultados relacionados ao suporte de ferramentas apontam que a maioria (56%, 19 de 34 estudos) de técnicas de integração é automática. Além disso, o apoio semiautomático é coberto por uma minoria (9%, 3 de 34) dos estudos. No entanto, uma grande parte (35%, 12 de 34) de obras não propõe qualquer ferramenta. Além disso, o suporte de ferramentas para todas as etapas de integração propostas não foi encontrado na literatura atual. Quanto aos métodos de pesquisa, os resultados mostraram que a maioria (67%, 23 de 34) dos estudos investigados foi à proposta de soluções, ou seja, é importante notar a falta de estudos empíricos em condições reais. Assim, mais experimentos e estudos de caso devem ser validados no contexto industrial.

Como trabalho futuro, é necessária realizar estudos experimentais, ou seja, experiência controlada para verificar o esforço empregado dos pelos desenvolvedores na detecção de conflitos e o grau de precisão das integrações, bem como o requisito necessário para integrar modelos de features em configurações do mundo real. Além disso, é necessário implementar e propor uma técnica de integração de modelos de features aplicando todos os passos de integração propostos neste trabalho. Finalmente, espera-se que os comentários discutidos ao longo do estudo possam encorajar pesquisadores e profissionais a explorar as informações relatadas. Além disso, este estudo pode ser visto como um primeiro passo para uma agenda mais ambiciosa sobre como caracterizar e melhorar as técnicas de integração de modelos de features.

4.1 Processo de Integração do Modelos de Features

A composição de modelos desempenha um papel fundamental no desenvolvimento de software dirigido a modelos, para adicionar novos elementos ou reconciliar modelos desenvolvidos em paralelo por diferentes equipes FARIAS et al. (2015a). A integração e a automação de processos estão entre os fatores mais significativos dirigidos a indústria de software, devido aos multiplos desafios tecnológicos voltados a integração e automatização de modelos, concentrando seus esforços na obtenção de melhorias no processo KOEHLER et al. (2005). Conforme bezivin2006, não há um consenso sobre as atividades e suas transições, bem como os artefatos gerados a partir da execução das mesmas para dar suporte a integração de modelos.

Em OLIVEIRA; OLIVEIRA (2007), os autores reconhecem essa necessidade e propõem um guia para integração de perfis UML. Entretanto os autores em OLIVEIRA; OLIVEIRA (2007) apresentam um guia para auxiliar na composição de modelos, orientando as atividades, assim como os procedimentos que devem ser adotados a fim de obter uma completa iteração e alinhamento entre as atividades desenvolvidas

Há peculiaridades inerentes à integração de modelos, bem como uma metodologia que auxilia na elaboração dos processos decorrentes para executar e integrar especificamente modelos de features. Isso pode ser motivado pela área de integração de modelos de features não ter ainda sido explorada.

O modelo de composição proposto por OLIVEIRA; OLIVEIRA (2007) pode ser aplicado em diferentes domínios e plataformas, sendo assim o modelo é aplicado à composição de modelos de features, o qual passa por pequenos ajustes exibido na Figura 4.1. O processo proposto é organizado em quatro fases, as quais são apresentadas a seguir:

  1. Análise dos modelos de entrada. Esta primeira fase consiste em identificar e analisar os modelos de features de entrada, MF e MF, buscando garantir a compatibilidade para sua integração, bem com prevenir a entrada de modelos de features inconsistentes OLIVEIRA; GARCIA; WHITTLE (2008). Esta fase procura verificar os seguintes critérios: (1) os modelos de features de entrada são do mesmo formato, isto é, um arquivo XML; e (2) os modelos de features de entrada apresentam inconsistências. Caso os modelos de entrada não atendam aos critérios estabelecidos, a integração é considerada invalidada, finalizando o processo de integração.

  2. Comparação dos modelos de entrada. A segunda fase incide em comparar os modelos de features de entrada para determinar a semelhança entre seus elementos. Para isso, têm-se como entrada as (1) estratégias de comparação, sejam estas sintáticas ou semânticas; e o (2) limiar. A comparação gera os seguintes resultados: 1) similaridade, especificando o grau de similaridade entre os elementos dos diagramas de features de entrada com um valor de 0 (zero) a 1 (um); (2) descrição de equivalência , umas descrição dos elementos dos modelos comparados, MF e MF, sendo considerados equivalentes; (3) descrição dos elementos não correspondentes, isto é, a descrição dos elementos dos modelos, MF e MF que não são equivalentes. Os elementos dos modelos MF e MF que tiverem um grau de similaridade acima do limiar definido, eles serão considerados equivalentes. Dessa forma, o limiar pode ser considerado como um mecanismo para estabelecer uma relação de equivalência entre os elementos de entrada. Além disso, ele permite que os usuários da técnica atue diretamente na definição da equivalência.

    Adaptado de Oliveira (2007).
    Figura 4.1: Processo de integração de modelos de features proposto.
  3. Integração dos modelos. A terceira fase consiste em integrar os elementos dos modelos de entrada, considerando a descrição de equivalência e a similaridade produzida na fase anterior. Essa integração irá gerar um modelo integrado, MF. Se dois elementos dos modelos de entrada não forem definidos como equivalentes, então uma abordagem semiautomática de integração será executa, a qual permite o usuário da técnica definir se os dois modelos serão integrados ou não. Caso contrário, os elementos definidos na fase anterior serão integrados automaticamente. Sendo assim, baseado na equivalência entre os elementos de entrada, uma abordagem automática ou semiautomática será seguida. Em outras palavras, esta fase decorre principalmente de quais estratégias de integração será seguida: (1) automática, sendo os modelos de features totalmente correspondentes, ou seja, grau de equivalência é igual a 1, ou sendo os modelos não correspondentes, isto é, o grau de equivalência igual a 0, aplica-se múltiplas estratégia de integração a qual acomoda em sua saída quatro prospecções de integração (adicional, formal, parcial e complementar) ACHER et al. (2010, 2009); THUM; BATORY; KASTNER (2009); (2) semiautomático, decorre dos modelos comparados não correspondentes possuírem um grau de equivalência que varia entre 0.2 a 0.9 FARIAS et al. (2015a, b), sendo que esta fase requer intervenção humana, devido aos conflitos detectados entre os modelos. A fase seguinte é responsável por gerenciar os modelos de saída, MF e MF, sejam estes equivalentes ou não.

  4. Avaliação da integração realizada. A quarta fase analisa a saída do modelo produzido, ou seja, o modelo de integrado é igual ao modelo pretendido, MF = MF. Inconsistências inerentes de uma má integração podem surgir, isto é, o modelo de feature é diferente do pretendido, MF MF. Assim o modelo , MF, precisa ser manipulado para que os conflitos identificados possam ser resolvidos. Para isso, o processo passa a ser realizado de forma semiautomática, verificando as inconformidades na fase anterior, ou seja, durante o processo de integração retomando o processo decisório para que analistas ou desenvolvedores atuem pontualmente nos conflitos, deste modo, transformando MF em MF.

Em síntese, a técnica lê e avalia dois modelos de entrada, realizando os procedimentos de comparação e integração dos elementos que compõe os diagramas, produzindo um modelo feature composto. Na próxima Seção são apresentadas as propostas de comparação dos modelos: (1) sintática, (2) semântica e (3) estrutural, os quais definem e estabelecem os critérios de similaridade entre os modelos, assim como os procedimentos integração.

4.2 Estratégias de Comparação

As estratégias de comparação definem os métodos aplicados para verificar o grau de equivalência entre os modelos de features. No Capítulo 2 é citado os elementos necessários para desenvolver os diagramas de features, nesta Seção são relembrados alguns deste fundamentos, para uma melhor compreensão das técnicas que virão a ser propostas.

O modelo features é arquitetado visualmente através de notações gráficas, sendo suas features representadas por retângulos e seus elementos gráficos através círculos (preenchido ou vazado), triângulos (preenchido ou vazado) e setas (simples, tracejada ou bidirecional), sua variabilidade é representada pelos relacionamentos entre as features, conforme demostrado na Figura 4.2.

O conjunto de features forma uma hierarquia contendo um elemento principal (feature-pai) e elementos secundários (features-filhos) conectados através de relacionamentos (opcional, obrigatório, alternativo, dependência e exclusão), sendo possível formalizar sua configuração, a qual pode ser representada através da semântica formal OLIVEIRA; BREITMAN; OLIVEIRA (2009a). Considerando que os modelos de features seguem uma linguagem natural, diferentes interpretações são aceitáveis, ocasionando ambiguidade. Buscando verificar esta equidade entre os significados são aplicadas estratégias de comparação. Embora ontologias possam ser utilizadas na comparação de modelos, eles precisam ser atualizados frequentemente, inviabilizando seu uso em ambientes reais de desenvolvimento de software.

Em FARIAS et al. (2015a) os autores relatam que a principal deficiências é a adoção de técnicas generalizadas na composição de modelos e a falta de conhecimento empírico sobre seus efeitos no esforço dos desenvolvedores na resolução de conflitos. A comparação tem como parte de seus objetivos verificar a existência de sobreposição semântica e sintática nos modelos de entrada OLIVEIRA et al. (2008). Tais sobreposições devem ser evitadas, devido a necessidade do modelo final produzido representar seus conceito, por exemplo o modelos de features descritos anteriormente, a fim de evitar conflitos e transformações de modelos ineficientes.

4.2.1 Estratégia Semântica

A estrutura para representar o modelo de feature ocorre através de um conjunto de símbolos e regras de formação, constituindo assim um conjunto de configurações. Na Figura 4.2 é possível visualizar as regras de derivação do modelo defeatures estabelecendo as fórmulas de conectividade. Cada feature corresponde a uma variável booleana (0 ou 1) capturada através da lógica proposicional (, , , e negação ).

Elaborado pelo Aultor.
Figura 4.2: Mapeamento de definições: modelo de features e lógica proposicional.

O modelo de features é definido como segue:
Modelo de Features MF = (G, r, Eobr, FXOR, FOR, Depen, Excl)

  • G = (F,E) é a formação de uma árvore que contém uma raiz, onde F é um conjunto finito de features, e E F x F é um conjunto finito de arestas (subfeatures), ou seja, é a decomposição hierárquica entre as features, pai-filhos e seus relacionamentos;

  • r F é feature raiz;

  • Fetures que não são obrigatórias e que não fazem parte de um grupo de features são features opcionais;

  • Uma feature pai poderá ter vários grupos de feature, mas uma feature deve pertencer apenas a um grupo feature;

  • FXOR P (F) x F e FOR P (F) x F define os grupos de features, os quais são um conjunto de pares filhos junto com feature pai. As features filhas são grupos exclusivos (XOR) ou inclusivos (OR).

  • Conjunto de restrições que implica Depen (uma feature depende de outra feature) e Excl (exclusão entre features) em que A F e B F.

A partir desta estrutura se estabelece um conjunto de configurações válidas para o modelo de features, ou seja, são estabelecidas as regras de boa formação. A Figura 4.3 apresenta um modelo de features, sendo o mesmo mapeado para a fórmula proposicional. Cada feature corresponde a uma variável da lógica proposicional e suas possíveis configurações derivadas. O modelo de features 1 apresenta três níveis hierárquicos, sete relacionamentos e oito features. Sua representação contextual, [MF1], demostra seis possíveis configurações de uma linha de produto. Por fim, o modelo lógico proposicional é MF.

Elaborado pelo Aultor.
Figura 4.3: Modelo de features representação gráfica para transformação lógica proposicional.

A estratégia semântica apresenta seis tipos de relacionamento, obrigatória, opcional, alternativa inclusiva e exclusiva, e os relacionamentos transversais que são exclusão e dependência, os quais são aplicados às fórmulas de conectividade, cada relacionamento corresponde a uma variável booleana (0 ou 1). A fórmula para identificar a similaridade entre conectividade das features é subdividida em duas etapas:

  • A primeira etapa consiste em verificar a diferença entres os relacionamentos dos modelos de features.

  • A segunda etapa consiste na aplicação da fórmula da estratégia semântica para se obter a similaridade que determina a equidade entre os modelo de features.

A estratégia semântica para verificar a diferença é representada por “difSem” o qual recebe a diferença entre conectividade da Feature Referência representada por “ frdif” e a conectividade da Feature Comparada representada “fcdif”, ou seja:

Equação 1.

difSem = frdif – fcdif, onde:

difSem = 1.00 se ambos os relacionamentos apresentarem a mesma conectividade;
difSem = 0.00 caso os relacionamentos entre as features não apresentem a mesma conectividade.

Na Figura 4.4, ilustra-se a comparação entre dois modelos de features, o referência, MF, e comparado, MF. É possível observar no exemplo, o relacionamento em ambos os modelos de features, seja este opcional, obrigatório, alternativo inclusivo ou exclusivo, dependência e exclusão. Os modelos exibem o número de relacionamentos, onde o modelo referência possui 7 notações e o modelo comparado exibe 8 notações, conforme a Tabela 4.1. A comparação entre os elementos correspondentes conforme demostra a Tabela 7 expõe o escore de pontuação sendo similar igual a 1 e diferente igual 0. Por exemplo, na Figura 14, ao comparar a conectividade entre os pares A, B de ambos os modelos, verifica-se que a similaridade é igual a 1, entretanto a conectividade entre A, E, F não é similar, isto é, implica em 0 e assim sucessivamente verifica-se todos os relacionamentos conforme demostra-se na figura abaixo, o modelo comparado, MF, exibe com um “x” os relacionamentos que não são similares e com “v” os relacionamentos similares. Aplicando a fórmula da diferença semântica, difSem, obtêm-se o resultado demostrado na Tabela 4.1, onde o escore da pontuação é obtido após a comparação entre os modelos de features.

Elaborado pelo Aultor.
Figura 4.4: Comparação entre relacionamentos de modelos de features.
Conectividades
MF Referência Obr Aex Ain Obr Opc Obr Dep -
MF Comparado Obr Ain Ain Opc Obr Opc Dep Exc
Escore 1 0 1 0 0 0 1 0
Lengenda
Obrigatório = Obr Alternativo Inclusivo = Ain
Opcional = Opc Alternativo Exclusivo = Aex
Exclusão = Exc Dependência = Dep

Elaborado pelo Autor.

Tabela 4.1: Escore de pontuação relacionamentos entre as features.

A segunda etapa consiste na aplicação da fórmula para calcular a estratégia semântica retornando o resultado da equivalência entre os modelos de features comparados:

Equação 2.

 onde:

difSem é o somatório total do escore obtido, ou seja, somatório das diferenças contidas entre os relacionamentos;
c é numero de conectividade existente.

Após aplicar a fórmula para calcular a estratégia semântica, ESTSEM, verifica-se uma parte do conjunto das estratégias para formular o cálculo de efetividade estratégica, CEE, ou seja, o escore de pontuação exibido a partir dos dados contidos na Tabela 4.1 entre os modelos de features, MF e MF, no exemplo acima ESTSEM é representado por difSem igual 3, dividido pela número de conectividades existentes. Neste exemplo, c é igual a 8, retornando como resultado o grau de equivalência entre as conectividades das features, ESTSEM é igual 0.37.

= 1+0+1+0+0+0+1+0  logo, ESTSEM = 0,37

4.2.2 Estratégia Estrutural

A similaridade estrutural procura analisar a hierarquia entre os elementos dos modelos de features, examinando o nível hierárquico em que as features se encontram BÉCAN et al. (2015); OLIVEIRA; BREITMAN; OLIVEIRA (2009b). Com a aplicação desta técnica, investiga-se o grau de disponibilidade de configuração de possíveis produtos que podem sofrer alterações conforme o nível hierárquico em que se encontra. A fórmula para identificar a similaridade entre os níveis hierárquicos dos modelos de features é subdividida em duas etapas. A primeira etapa consiste em verificar a diferença entres os níveis hierárquicos dos modelos de features. A segunda etapa consiste na aplicação da fórmula para calcular estratégia estrutural para se obter a similaridade que determina a equidade entre os modelo de features.

O Cálculo da Diferença Estrutural (difEst) é calculado de acordo com a equação ESEST: Entre as hierarquias recebe no máximo 1 ponto, estando os dois elementos (fetaures) no mesmo nível hierárquico. Considera-se 0.5 ponto, para elementos (features) que se encontram em um nível hierárquico abaixo ou acima do seu similar, aplica-se 0.25 pontos para elementos (features) que se encontram dois ou mais níveis hierárquicos acima ou abaixo ao seu similar. Por fim, o valor 0 (zero) é atribuído, caso a feature não encontre outra feature similar nos níveis hierárquicos. Apresenta-se a fórmula para identificar o cálculo estrutural de diferença hierárquica entre as features, sendo a diferença estrutural representada por “difEst”, a qual recebe a diferença entre nível hierárquico da feature referência representada por “ frn” e o nível hierárquico da feature comparada representada “fcn” ou seja:

Equação 3. difEst = frn – fc —————————————————————————————————— Onde: difEst = 1,00, se ambas as features estiverem no mesmo nível hierárquico; difEst = 0,50, caso as features encontram-se um nível hierárquico abaixo ou acima; difEst = 0.25, caso as features encontram-se dois ou mais níveis hierárquico abaixo ou acima; difEst = 0,00, caso não encontre features similar relacionadas aos níveis hierárquico abaixo ou acima

Na Figura 4.5, ilustra-se a comparação entre dois modelos defeatures, o modelo referência, MF, e modelo comparado, MF. O nível hierárquico entre os modelos comparados, neste exemplo, é de 0 a 3, isto é, quatro níveis hierárquicos. O exemplo ilustra abaixo, a feature A exibida no MF, encontra-se no nível zero, porém no modelo comparado, MF, a feature A encontra-se no terceiro nível, conforme demostrado na Tabela 4.2. O escore de pontuação, difEst é igual a 0.25, devido a diferença dos níveis. Assim, sucessivamente verifica-se em que nível hierárquico, encontram-se as features conforme demostra-se na figura abaixo, o modelo comparado, MF, exibe com um “x” os níveis hierárquicos que não são similares e com “v” os níveis hierárquicos similares. Aplicando a fórmula da diferença estrutural, difEst, obtêm-se o resultado demostrado na Tabela 4.2, cujo escore da pontuação é obtido após a comparação entre os modelos de features.

Elaborado pelo autor.
Figura 4.5: Comparação entre o nível hierárquico de features.
Features A B C D E F G H I
Escore 0,25 1 1 1 1 0,5 1 0,5 0,25

Elaborado pelo autor.

Tabela 4.2: Escore de pontuação nível hierárquico.

A segunda etapa consiste na aplicação da fórmula da estratégia estrutural para calcular o nível da estrutura hierárquica, retornando o resultado da equivalência dos níveis hierárquicos entre os modelos de features comparados:

Equação 4.

 onde:

difEst é o somatório total do escore obtido através das diferenças estruturais;
f é número de features existente.

O grau máximo de similaridade obtido na estratégia estrutural é 1, para os casos em que as features f estejam todas contidas no mesmo nível hierárquico n.

Após aplicar a fórmula para calcular a estratégia estrutural, ESTEST, verifica-se uma parte do conjunto das estratégias para formular o Cálculo de Efetividade Estratégica, CEE. O escore de pontuação é exibido a partir dos dados contidos na Tabela 4.2 entre os modelos de features, MF, e MF. No exemplo acima ESTEST é representado por difEst igual 6.5, dividido pela número de features existentes e neste exemplo, f é igual a 9, retornando como resultado o grau de equivalência entre os níveis hierárquicos das features, onde ESTEST é igual 0.72.

= 0,25+1+1+1+1+0,5+1+0,5+0,25  logo, ESTEST = 0,72

4.2.3 Estratégia Sintática

Considerando que os modelos de features seguem uma linguagem natural é aceitável diferentes interpretações ocasionando ambiguidade na comparação entre modelos, buscando verificar esta equidade entre os significados das palavras procura-se aplicar um dicionário de sinônimos em conjunto com uma técnica para comparação de string.

O algoritmo Jaro distance é formado através de uma matriz, sua aplicação foi desenvolvida para comparação de pequenas strings COHEN; RAVIKUMAR; FIENBERG (2003), e baseia-se no número de caracteres comuns entre duas strings e sua ordem sequencial. A métrica da distância projetada se adapta melhor a distâncias curtas, e a pontuação normalizada para o seu algoritmo é 0, quando não apresenta nenhuma similaridade e 1 quando o mesmo apresenta similaridade. A fórmula para identificar a similaridade entre as features é subdividida em duas etapas:

  • A primeira etapa consiste em verificar a diferença gramatical entres as features que compõem os modelos.

  • A segunda etapa consiste na aplicação da fórmula estratégia sintática para se obter a similaridade que determina a equidade entre os modelo de features.

A distância de Jaro dj entre duas strings é produzida através da comparação da string 1 representada por |s1| e da string 2 representada por |s2|, conforme segue sua fórmula:

m

é o número de caracteres correspondente;

t

é o número de transposições suportadas.

Quando o valor de m for igual a 0, não existe similaridade entre as strings. As strings não correspondentes, ou seja, aquelas que têm sua ordem de sequencia encontra-se diferente entre s1 e s2, onde aplica-se a fórmula de transposição, contendo o valor máximo dos seus caracteres entre |s1| e |s2| que é a divisão por 2, definindo, desta forma, o número de transposições suportadas.

Na Figura 4.6, é apresentado um exemplo de comparação entre dois modelos de features, o modelo referência, MF, e o modelo comparado, MF. A similaridade entre a feature fone no modelo MFR, e a feature ofne no modelo MF, demostra que não há uma similaridade, entretanto a feature ofne tem o mesmo significado contento um erro de grafia, conforme demostrado na Tabela 4.3, o escore de pontuação, dj é igual a 0.91, devido a diferença entre as strings. Assim, sucessivamente verifica-se a sintaxe entre as features conforme demostra-se na figura abaixo, o modelo comparado, MF, exibe com um “x” a sintaxe que não são similares e com “v” a sintaxe similares. Aplicando a fórmula da diferença entre as features, isto é, a fórmula de Jaro Distance, com o objetivo de verificar a ortografia entre os modelos, obtêm-se o resultado demostrado na Tabela 4.3, onde se tem o escore da pontuação obtido após a comparação entre os modelos de features.

A aplicação da fórmula de Jaro Distance para comparar as strings “fone” e “ofen”, é apresentada abaixo. Para obter os dados correspondentes aplicam-se as strinsg, |s1|, e |s2| na matriz para verificar sua similaridade, onde m = 4, S1 = 4, S2 = 4 e t = 1. O resultado retornado através da aplicação da fórmula corresponde a 91% de similaridade entre as strings |s1| e |s2|.

d = 0,916

Elaborado pelo autor.
Figura 4.6: Comparação gramatical entre features.
Features Fone Ligação
Escore 0,91 1

Elaborado pelo autor.

Tabela 4.3: Escore de pontuação de similaridade entre strings.

A segunda etapa consiste na aplicação da fórmula da estratégia sintática para calcular a similaridade entre as strings que compõem o modelo de feature, retornando o resultado da equivalência entre os modelos comparados:

Equação 5.

 onde:

dj é o somatório total do escore obtido através da diferença entre as strings; f é número de features existente.

O grau máximo de similaridade obtido na estratégia sintática é 1, para os casos em que o conjuntos de string de dj é igual a número de features de f, isto é, todos as features sejam iguais. Após a aplicar a fórmula para calcular a estratégia sintática, ESTSIN, verifica-se uma parte do conjunto das estratégias para formular o cálculo de efetividade estratégica, CEE, ou seja, o escore de pontuação exibido a partir dos dados contidos na Tabela 4.3 entre os modelos de features, MF e MF, no exemplo acima ESTSIN é representado por dj igual 1,91, dividido pela número de features existentes, neste exemplo, f é igual a 2, retornando como resultado o grau de equivalência entre as features, ESTSIN é igual 0,95.

= 0,91+1  logo, ESTSIN = 0,95

4.2.4 Cálculo de Efetividade Estratégica

Após a definição parcial das fórmulas para comparação entre os modelos de features por meio dos cálculos de estratégia estrutural representada por ESTEST, estratégia semântica representada por ESTSEM, e a estratégia sintática representada por ESTSIN, define-se o calculo de efetividade das estratégias, obtendo-se o resultado de similaridade entre os modelos de features comparados. O grau de equivalência é representado por CEE, sendo que sua variação encontra-se entre os valores de 0 a 1, o seu calculo é executado através de uma média aritmética simples, sendo sua pontuação calculada por meio de uma divisão das estratégias somadas por sua quantidade, conforme segue sua fórmula:

Equação 6.

 [0..1]

ste é o somatório das estratégias de comparação;
n é o somatórios do número de estratégias aplicados.

A aplicação para formular o cálculo de efetividade estratégica, CEE, após a comparação modelos, MF, F, conforme os exemplos aplicados a este trabalho apresentam o resultado do somatório das estratégias de acordo com a fórmula CEE, sendo o seu resultado igual a 0.68, isto é, a equivalência entre os modelos é de 68 por cento.

 0,68

Sendo assim, para realizar a integração entre os modelos de features é necessário analisar o cálculo de efetividade estratégica, o qual define o parâmetro de corte, isto é, o limiar que define qual estratégia de integração deverá seguir: automática ou semiautomática.

4.3 Estratégias de Integração

Nesta seção são definidas as estratégias para integração entre os modelos de features, o qual segmenta o entendimento dos processos estabelecidos na Seção 4.1, bem como as diretrizes que determinam a equivalência entre a comparação dos modelos de features fundamentados na Seção 4.2. As estratégias de integração consistem em:

  • Especificar dois modelos de features como entrada;

  • Determinar as estratégias de comparação a ser aplicada, estrutural, semântica e sintática;

  • Definir as estratégias de integração a ser seguida, automática ou semiautomática;

  • Obter o resultado da comparação entre os modelos de features integrados, ou seja, o modelo pretendido como saída.

A partir da entrada dos modelos features a serem comparados, é possível obter uma evolução do modelo de features, isto é, o modelo pretendido, MF, independente da estratégia de comparação a ser seguida sempre originará um modelo como saída. Sendo assim, a comparação entre dois modelos de features pode originar com a saída múltiplas estratégias operacionais, as quais serão acopladas conforme sua especificidade FARIAS et al. (2015a). Retornado o cálculo de efetividade estratégica, CEE, obtém-se o parâmetro de corte, ou seja, limiar que define qual estratégia deverá ser seguida. A similaridade entre os modelos de features é indicada pelo o grau de equivalência. Quanto mais próximo de 1 menor será sua diferença, sendo assim define-se qual estratégia de integração deverá seguir. Os índices estabelecidos para o corte de similaridade variam entre 0.7 e 0.8, conforme farias2015, farias2015b, este trabalho aplica um limiar igual ou superior 0.95, tomando por verdade melhorar a precisão da técnica de integração.

  • CEE = 1. Elementos que compõem os diagramas de features 100% similares aplica-se a estratégia automática, sem a interferência humana.

  • CEE = 0. Elementos que compõem os diagramas de features que não possuem nenhuma similaridade aplica-se a estratégia automática, sem a interferência humana.

  • CEE 0.95 e < 1. Os elementos que compõem os diagramas de features que possuírem um alto índice de similaridade aplica-se a estratégia automática, sem a interferência humana.

  • CEE > 0 e < 0.95. Os elementos que compõem os diagramas de features que possuírem alguma similaridade aplica-se a estratégia semiautomática, o qual requer intervenção humana ou automática, sem a interferência humana.

4.3.1 Múltipla Estratégia de Integração

A definição das estratégias sejam estas automáticas ou semiautomáticas serão vinculadas as técnicas de múltipla estratégia de integração operacional. A entrada ocorre por meio de dois modelos de features definidos como: o modelo referência, MF, e modelo comparado, MF, após realizar a comparação entre os modelos e execução das técnicas de integração obtêm-se como resultado uma saída, o modelo pretendido, MF. Procurando obter o melhor precisão possível entre os modelos de features integrados, produzindo um resultado desejado, classifica-se as seguintes categorias de estratégias operacionais:

Estratégia Comum:

Ao analisar a comparação entre os dois modelos de features obtêm-se como resultado a igualdade entre os modelos, isto é, tudo que contém em um modelo também está em outro, implicando em:

MF = MF MF MF MF MF

Estratégia Adicional:

Ao analisar a comparação entre os dois modelos de features, tudo que contém em um modelo passa a estar contido em outro, implicando em:

MF MF = { MF MF }

Estratégia Formal:

Ao analisar a comparação entre os dois modelos de features verificam-se as features comuns que estão contidas em ambos os modelos, implicando em:

MF MF = { MF MF }

Estratégia Parcial:

Ao analisar a comparação entre os dois modelos de features verifica-se a diferença entre os modelos, isto é, retorna a diferença que contém o modelo referência, implicando em:

MF MF = { MF MF }

Estratégia Complementar:

Ao analisar a comparação entre os dois modelos de features verifica-se a diferença entre ambos os modelos, implicando em:

MF MF = { MF MF MF MF }

Estratégia Nula:

Ao analisar a comparação entre os dois modelos de features estes não possuem fetuares comuns, isto é são disjuntos, implicando em:

MF MF = 0

4.3.2 Estratégia Semiautomática

O modelo semiautomático será introduzido para os desenvolvedores e analistas, após retornar o cálculo de efetividade estratégia, CEE, ou seja, se o grau de equivalência for menor que 0.95. A estratégia semiautomática requer a intervenção humana para garantir que seja realizada a integração entre os modelos de features através da aplicação das estratégias descritas nas Seções anteriores, tendo como fundamento exibir os conflitos existentes no processo de comparação, para que os desenvolvedores ou analistas tendam a decidir qual elemento conflitante será integrado em conformidade com as funcionalidades ou requisitos inerentes ao projeto.

A aplicação da técnica envolve na varredura de ambos os modelos de features, conforme sua entrada, ou seja, modelo referência, MF, e modelo comparado, MF, visando comparar as métricas definidas entre os modelos de features FARIAS; GARCIA; WHITTLE (2008),sintaxe, semântica, notações, número de elementos, sua ordem e seu nível hierárquico. Após realizar o processo de comparação entre os dois modelos de features, são aplicadas as estratégias; (1) estrutural, (2) semântica e (3) sintática, exibindo aos usuários os conflitos existentes para sua alteração. Por fim, são executadas as técnicas de múltipla estratégia de integração operacional para retornar o modelo integrado,ou seja, a saída que deseja, MF. A Figura 4.7 ilustra dois modelos de features que servirão de exemplo para aplicação da técnica de múltipla estratégica de integração operacional, aplicando a técnica semiautomática e automática.

Elaborado pelo autor.
Figura 4.7: Exemplo de integração técnicas - semiautomático e automático

Nesse exemplo são visualizados os conflitos existentes entre o modelo referência, MF, e o modelo comparado, MF a feature Trans exibida no MF, apresenta diferenças (1) sintática quando comparada ao MF, a feature Transporte, Serviços Públicos, exibem com um “x” as features que não são similares e com “v” a sintaxe similar Carro, Outros; (2) Semântica quando comparada ao MF, as notações que compõem o diagrama feature ou Inclusivo, Nulo e por fim (3) estrutural, quando avalia a ordem das features, bem como o número de elementos que compõem o diagrama quando comparada ao MF, a feature Motocicleta, Bicicleta, no que refere ao número de elementos contém diferenças. Após a comparação é apresentado o grau de equivalência para compor o cálculo de efetividade estratégico.

O escore para identificar a equivalência entre os modelos é calculado aplicando as estratégias: sintática, semântica e estrutural entre os modelos de features, o qual possibilita calcular a diferença encontrada entre os dois modelos, obtendo como resultado o percentual de diferença entre os modelos comparados.

Por conseguinte, o grau de equivalência é 0,43. Isto é, os modelos de features apresentam baixa similaridade. Os desenvolvedores e analistas podem optar, neste caso, em aplicar uma das estratégias, pois o limiar é menor que 0.95. A opção indicada neste trabalho para o limiar que varia entre 0.25 a 0.95 é a opção semiautomática, onde a interação com o usuário acontece para que se possa tomar a melhor decisão de acordo com as funcionalidades ou requisitos estabelecidos no projeto de software. O modelo semiautomático permitirá ao usuário que o mesmo altere os conflitos localizados no modelo, comparado ou não. Permanecendo o modelo o mais próximo de desejado, por exemplo, entre o conflito Tran e Transporte a técnica questiona-se junto ao usuário qual das duas opções é a considerada ideal, percorrendo todos os elementos que constituem o diagrama até não encontrar mais conflitos. Assim, o próximo passo é a integração modelo, gerando o modelo pretendido, exibindo um novo grau de equivalência entre o modelo de referência, MF, e o modelo pretendido, MF.

4.3.3 Estratégia Automática

O cálculo de efetividade estratégico, retornado como resultado 1, implica que os dois modelos de features possuem igualdade, aplicando a técnica de múltipla estratégia de integração operacional que melhor ajustar, neste caso a estratégia comum retornando como saída o mesmo modelo, MF. O cálculo de efetividade estratégico, retornado como resultado 0, implicando que não há qualquer similaridade entre os modelos de features, neste caso, aplicada a técnicas de múltipla estratégia adicional, retorna como saída o modelo integrado, MF.

A Figura 4.8 exibe as estratégias geradas quando selecionada pelos analistas ou desenvolvedores a estratégia automática, cuja técnica gera quatro modelos, onde o mesmo poderá ter como parâmetro também quatro modelos, verificando qual o melhor deles para se adaptar às suas necessidades para então executar as alterações.

Elaborado pelo autor.
Figura 4.8: Exemplo de integração com o uso da técnicas automático

5.1 FMIT - Visão Geral

A integração manual de modelos de features trata-se de uma tarefa árdua e propensa a erros BÉCAN et al. (2015); FARIAS et al. (2015a, b). A modelagem de features é uma atividade complexa quando introduzida em grandes LPS TEIXEIRA; BORBA; GHEYI (2013); APEL; KÄSTNER (2009), em consequência da vasta variabilidade que emerge da composição de modelos. A execução de uma integração segura é fundamental na qualidade dos produtos gerados. Deve-se levar em consideração, a quantidade de features, as notações, ou seja, seus relacionamentos, suas dependências e observar a ordem em que os elementos são configurados BÉCAN et al. (2015); TEIXEIRA; BORBA; GHEYI (2013). Além disso, o grande número de técnicas, por exemplo, FODA KANG et al. (1990), RSEB GRISS; FAVARO; D’ALESSANDRO (1998), FORM KANG et al. (1998), CMBF CZARNECKI; HELSEN; EISENECKER (2004), TVL CLASSEN; BOUCHER; HEYMANS (2011), CVL REINHARTZ-BERGER; FIGL; HAUGEN (2014),torna-o um dificultador, o que eleva o risco de más integrações por parte das equipes de desenvolvimento.

Sendo assim, a utilização de uma ferramenta que automatize parcial ou completamente a integração pode trazer melhorias. Neste contexto, a ferramenta FMIT foi desenvolvida com o objetivo de introduzir melhorias no processo de automatização de integração de modelos de features, assim como para auxiliar as equipes de desenvolvimento na atividade de integração. As atividades para a integração de modelos, proposto pelo protótipo, FMIT, compreende uma sequência de passos, conforme ilustra a Figura 5.1.

Elaborado pelo autor.
Figura 5.1: Fluxo de atividades para execução do protótipo FMIT.

Os passos descritos abaixo visam conduzir as atividades inerentes à equipe de desenvolvimento, especificamente aos analistas e desenvolvedores, visto a interação entre o framework, FeatureIDE, que atua como uma ferramenta intermediária, isto é, facilitando a visualização dos modelos features, sua configuração, bem como a criação ou a edição de modelos.

Finalmente, tem-se o protótipo, FMIT, que age como um condutor no processo de integração de modelos, procurando identificar conflitos entre os modelos comparados, sendo capaz de exibir a similaridade destes, pois, em suma, sua diretriz é aperfeiçoar o processo de composição. Resumidamente, os passos incluem importação, seleção, leitura, validação e visualização dos modelos de entrada, a interação com o protótipo, FMIT, tendo em vista aceitar ou rejeitar conflitos identificados e, por fim, a visualização do modelo integrado. Os passos apresentados na Figura 5.1 serão descritos a seguir:

  • Solicitar importação de modelos. O analista importa os modelos de entrada MF e MF, ou seja, importa os arquivos no formato XML para o framework FetureIDE.

  • Importar modelos. O framework analisa os arquivos para importação, executando uma validação interna; os arquivos que se encontram conforme os padrões estabelecidos são importados, caso contrário o processo é finalizado.

  • Importar XML. O protótipo, FMIT, executa uma rotina de leitura e importação dos arquivos XML para que esses sejam validados e estruturados para uso do mesmo.

  • Visualizar modelos. O analista pode visualizar os modelos importados no framework graficamente ou textualmente, bem como fazer uso de todas as funcionalidades que a mesma permita, por exemplo, alterar alguma feature.

  • Selecionar modelos de entrada. O analista executa o método principal do protótipo, onde o mesmo informa o modelo de origem, MF, isto é, modelo referência, bem como o modelo de destino, MF, isto é, o modelo comparado. O sistema executa um método de verificação e análise dos arquivos XML. Se os arquivos de importação não forem localizados o mesmo é finalizado.

  • Comparar modelos. Essa funcionalidade consiste em uma das principais atividades do processo de comparação descrita no Capítulo 4.2. Este método processa uma série de informações referentes aos elementos que constituem o modelo de features, formando a matriz similaridade. É considerado método base para processar a integração de modelos

  • Exibir grau de equivalência. O framework exibe uma serie de informações textuais em seu console para o analista ou desenvolvedor, advindas do protótipo. As informações são inerentes à contextualização da comparação dos elementos dos diagramas de features, por exemplo, o grau similaridade sintática e semântica. Conforme descrito na Seção 4.1, o sistema apresenta o cálculo de efetividade estratégia, CEE, em síntese é o grau de equivalência entre os dois modelos comparados.

  • Executar estratégia de integração. Este método retém as informações advindas da equivalência dos modelos, que consolidam o processo de integração descrito na Seção 4.3 que irá delinear a estratégia a ser seguida de acordo com o limiar estabelecido. Enfim, caso o cálculo de efetividade estratégica, CEE, seja igual a 0 ou 1, executa-se a estratégia automática, sendo menor que 0.95 aplica-se a estratégia semiautomática.

  • Selecionar Automatização. O analista ou desenvolvedor define que tipo de automatização pretende escolher, automático onde o sistema sugere quatro saídas de composição ou semiautomático que necessita de sua intervenção para solucionar os conflitos existentes.

  • Executar estratégia de integração semiautomática. Este método executa as estratégias de composição descritas na Seção 4.3, conforme as regras pré-estabelecidas, ou seja, necessita de intervenção humana.

  • Executar estratégia de integração automática. Este método executa as estratégias de composição descritas na subseção Seção 4.3, conforme as regras pré-estabelecidas, ou seja, sem a intervenção humana.

  • Exibir modelos de features integrado. O framework exibe no console o modelo features integrado, MF, após a conclusão da composição que compreende a integração dos modelos MF e MF.

  • Exibir conflitos. O framework exibe no console os modelos conflitantes, após a comparação dos modelos de entrada, MF e MF.

  • Editar elementos conflitantes. O protótipo identifica os elementos conflitantes, sendo necessária a intervenção do analista no processo decisório em aceitar ou rejeitar as mudanças dos elementos em conformidade com os requisitos de projeto.

  • Alterar elementos do modelo. O protótipo alterar os elementos do modelo de features comparado, isto é MF, conforme a decisão do analista, formando um novo modelo.

  • Exibir modelo de features pretendido. O framework exibe no console o modelo feature pretendido, MF, após a conclusão da composição que compreende a integração dos modelos MF e MF, exibindo o novo grau de equivalência.

  • Salvar modelo. O sistema salva todas as informações exibidas no console em um arquivo textual, modelos de entrada, MFA e MFB, grau de equivalência dos modelos comparados, processos de edição e alterações de elementos do modelo, bem como apresenta os elementos integrados, MF ou MF oriundos da composição dos modelos de entrada.

5.2 Arquitetura do Protótipo FMIT

Análise, comparação, integração, avaliação e persistência, desta forma produzindo uma técnica de integração específica, para a situação proposta. Através da manipulação dos modelos de entrada e aplicação das estratégias de comparação seguidos das técnicas de múltipla estratégia operacional pretende-se obter como saída o modelo mais perto do idealizado entre os analistas e desenvolvedores.

A integração entre os modelos de features é definida através de um conjunto de funcionalidades que tem por finalidade produzir um novo modelo, isto é, o modelo de features pretendido, MF FARIAS et al. (2013). As atividades propostas para o desenvolvimento serão realizadas de forma sequencial, entretanto ocorrerá de forma independente onde cada atividade terá sua função isolada, ou seja, separadamente. Contudo, para a execução de uma atividade, um conjunto de informações deve ser indicado, por exemplo, na análise do modelo de features. Na comparação devem-se informar quais são as features, notações e estrutura equivalentes e qual estratégia integração deverá ser aplicada.

5.2.1 Diagrama de Features da FMIT

O suporte à implementação de funcionalidades da arquitetura FMIT, é proposto devido a várias razões e requisitos identificados em trabalhos anteriores FARIAS et al. (2015a); OLIVEIRA; BREITMAN; OLIVEIRA (2009b). Utilizável, portanto, quando identificanda a necessidade de uma arquitetura para a integração de modelos de features BISCHOFF et al. (2016), reutilizável para suportar e orientar o desenvolvimento de novas ferramentas de integração. É representativo o domínio de integração de modelos, uma vez que seu design decompõe as principais preocupações com features bem modularizados. Por último, permite avaliar os modelos gerados e persistir os resultados. Assim, a arquitetura proposta fornece um conjunto de características fundamentais, incluindo análise dos modelos de entrada, comparação dos modelos de entrada, integração do modelo de entrada equivalente, persistência do modelo de saída gerado e avaliação do modelo de saída.

Bischoff, 2016.
Figura 5.2: Funcionalidades da ferramenta de integração.

A Figura 5.2 mostra uma visão simplificada do modelo de features da FMIT. Assim, para desenvolver ferramentas de integração, os desenvolvedores devem primeiro implementar as features obrigatórias, incluindo análise, comparação, integração, avaliação e persistência. Além de identificar um conjunto de funcionalidades essenciais, as funcionalidades obrigatórias especificam suas dependências de forma fácil e compreensível. Uma preocupação presente em toda a arquitetura do FMIT foi assegurar que os recursos obrigatórios cumpram o processo de integração do modelo descrito na Figura 5.2. Por exemplo, a feature de análise implementa o primeiro passo e a feature de persistência fornece a funcionalidade necessária para manter o modelo integrado de saída gerado no final do processo de integração.

A feature opcional é referente ao formato do arquivo, isto é, um arquivo texto, gerado após finalizar o modelo integrado ou desejado em sua saída. As principais features são representadas pelas estratégias de Comparação que formaliza o Cálculo de Efetividade Estratégica, CEE, definindo a equivalência entre os modelos, descrita no Capítulo 4 e as estratégias de integração, Automática e Semiautomática que segue umas das Múltiplas Estratégias de Operação para conduzir a composição entre os modelos.

5.2.2 Diagrama de Casos de Uso

Esta Seção tem como objetivo descrever os requisitos do protótipo, definindo de que forma deverá funcionar. O diagrama de casos de uso tem o objetivo de auxiliar a comunicação, assim como, descrever os cenários que exibe as funcionalidades do sistema ERIKSSON et al. (2003).

Apresenta-se as funcionalidades básicas do protótipo, FMIT, tendo como referência a visão do usuário. Sendo assim, o protótipo pode ser dividido em três funcionalidades: (1) carregar modelos de features, (2) definir tipo integração e (3) integrar os modelos de features. A Figura 5.3 ilustra estas funcionalidades.

Elaborado pelo Autor.
Figura 5.3: Atividade realizada pelo usuário.

A próxima interação consiste em (1) importar os modelos de entrada, (2) validar o formato dos modelos de entrada, (2.1) enviar mensagem caso os modelos sejam inválidos, (3) comparar os modelos de entrada e (4) exibir os modelos importados e informações sobre a equivalência entre os modelos. Na figura 5.4 é ilustrado o caso de uso para a atividade de configuração dos parâmetros de automatização.

Elaborado pelo Autor.
Figura 5.4: Caso de uso carregar modelos de entrada.

Além disso, será necessário realizar a integração entre os modelos, definindo como a mesma será executada. O usuário poderá optar em executar uma análise mais profunda no caso a opção (1) semiautomática para produzir o modelo pretendido, ou seja, há uma intervenção do usuário em aceitar ou rejeitar um conflito, entretanto ao optar pelo modelo (2) automático, este não requer intervenção do usuário. Na Figura 5.5 é ilustrado o caso de uso para definir o tipo de integração.

Elaborado pelo Autor.
Figura 5.5: Caso de uso definir tipo de integração.

Uma vez definido o parâmetro de integração, será possível integrar os modelos de features de entrada. Para integrar será necessário (1) solucionar os conflitos de integração, (2) Executar as estratégias de Integração e finalmente (3) Salvar as informações do modelo gerado. Na figura 5.6 é ilustrado o caso de uso para a atividade de integração dos modelos de features e persistir na sua saída.

Elaborado pelo Autor.
Figura 5.6: Caso de uso de integração do modelo de features

5.2.3 Componentes Arquiteturais

Os componentes são responsáveis pela implementação de cada atividade ilustrada na Figura 5.2. Os componentes permitem ser utilizados de forma isolada, ou seja, independentemente, de modo a vir modularizar os elementos do protótipo, provendo o reuso dos componentes que virão a ser produzidos, bem como permitem o desenvolvimento e manutenção pontual da ferramenta proposta.

Cada componente será tratado como um módulo independente, que encapsula seu comportamento através de um conjunto de atividades internas. O papel desempenhado pelos componentes ocorre por meio dos módulos e sua interação entre os elementos demostrando o comportamento esperado. Deste modo, a Figura 5.7 ilustra a arquitetura de componentes a ser aplicada, o qual se concentra em apresentar os componentes como um grupo de elementos responsável em desempenhar cada atividade especificamente, ou seja, módulos independentes que desempenham um fator determinante na integração de modelos de features.

Adaptado de Farias (2015b).
Figura 5.7: Arquitetura de componentes.
  • FMIT. O motor principal do protótipo se concentra no componente FMIT, e é responsável por administrar todos os processos do protótipo, iniciar a execução de todas as atividades, bem como exibir e avaliar o retorno dos métodos determinados.

  • Análise. Este componente implica em autenticar os modelos entrada, avaliando se ambos os modelos de features são do mesmo formato e verifica se o processo de comparação poderá ser aplicado sobre os modelos. O componente realiza a leitura dos modelos entrada, ou seja, o Modelo Features Referência, MF e Modelo Features Comparado, MF, executa uma análise das especificações das notações da modelagem utilizada, especificamente a modelagem FODA- Feature-Oriented Domain Analysis KANG et al. (1990), identificando os elementos que compõem o modelo, bem como seus relacionamentos, após agregando os dados no formato XML para o framework FeatureIDE BISCHOFF et al. (2016); FARIAS et al. (2015b); THÜM et al. (2014), responsável por projetar a visualização graficamente dos modelos. Este será o primeiro componente executado pelo motor do FMIT.

  • Comparação. Este componente consiste em analisar as estratégias de similaridade entre os modelos, verificando todos os elementos que compõem o modelo de features, especificando individualmente uma checagem entre ambos os modelos, sobre cada categoria, para verificar o grau de equivalência. As estratégias aplicadas para comparar os modelos de features são aplicadas em três níveis: (1) estratégia estrutural, (2) estratégia sintática e (3) estratégia semântica; são responsáveis por demostrar os conflitos surgidos durante a composição dos modelos para os desenvolvedores e analistas, e por fim, é retornado o Cálculo de Efetividade Estratégico (CEE), que determina o grau de equivalência entre ambos os modelos de features determinando qual estratégia de integração melhor se adapta. Infere, também, no limite a ser aplicado, ou seja, no corte para considerar um modelo de features equivalente ou não.

  • Integração. O componente de integração é invocado após a avaliação das equivalências encontradas e atua na integração do MF, ou MF. Este componente implica em duas estratégias, (1) Automática e (2) Semiautomática, ambas segmentadas por seis técnicas de Múltipla Estratégia de Integração Operacional descritas na Seção 4.3, sendo sua finalidade formar um novo modelo de features, ou seja, o MF como saída. A Estratégia Automática (1) ocorrerá de duas formas: a primeira, sendo ambos os modelos diagnosticados como sendo idênticos é aplicada à Estratégia de Integração Operacional Comum, a segunda etapa consiste em verificar se ambos as modelos serão totalmente diferentes, isto é, não existe nenhuma equivalência entre eles aplicando assim à Estratégia de Integração Operacional Adicional. Por fim, a Estratégia Semiautomática (2), será aplicada, quando o grau de equivalência entre os modelos de features estiver abaixo do limiar, pré-estabelecido, conforme descrito na Seção 4.3. Possibilita ao analista ou desenvolvedor escolher entre uma de duas opções, automático e semiautomático. Caso a escolha seja pelo modo automático o protótipo retorna quatro possíveis soluções integradas em sua saída, MF1… MF4. As estratégias, aplicadas são: Adicional, Formal, Parcial ou Complementar. O modelo semiautomático conecta o componente de comparação e avaliação para produzir o modelo pretendido, MF.

  • Avaliação. O componente de avaliação retorna visualmente os conflitos localizados no componente de comparação, exibindo os mesmos para tomada de decisão do analista ou desenvolvedor, na compreensão de retornar o modelo pretendido, MF., com base na Múltipla Estratégia de Integração Operacional.

  • Persistência. É a camada que armazena os modelos carregados pelo componente de análise e os modelos produzidos durante os processos de comparação, integração e avaliação. Os dados são armazenados em um arquivo texto no disco rígido.

5.2.4 Arquitetura em Camadas

Para atender a funcionalidade especificada FARIAS et al. (2015b); OLIVEIRA; OLIVEIRA (2007) através das estratégias para integração de modelos de features, bem como as características do protótipo propõe-se um design projeto arquitetural modularizado em seis camadas: (1) Infraestrutura, (2) Apresentação, (3) Aplicação, (4) variabilidade, (5) Lógica de Negócios e (6) Plataforma Eclipse conforme a Figura 5.8.

Adaptado de Farias (2015b).
Figura 5.8: Arquitetura de camadas do protótipo.
  • Camada de Apresentação. Representa a camada mais próxima do usuário, ou seja, interface da aplicação. Interage diretamente com os analistas e desenvolvedores onde serão coletados os parâmetros de configuração, bem como as entradas necessárias para a execução das funcionalidades. Além disso, tem como responsabilidade retornar as informações da aplicação: conflitos encontrados na composição e propor um modelo de features como saída, ou seja, o resultado final.

  • Camada da Aplicação. Esta camada abrangerá fluxo de controle das operações, tendo como responsabilidade coordenar e controlar a execução das atividades. Análise, Comparação, Integração, Avaliação e Persistência, onde determinará as chamadas, bem como as repostas das atividades, demandadas em sua execução.

  • Camada de Variabilidade. O objetivo desta camada está em aplicar o comportamento das operações propostas (estratégias de análise, comparação e integração), isto é, executar as operações na camada de aplicação, obtendo o procedimento esperado da camada de negócios.

  • Camada da Lógica de Negócio. A implementação da lógica de negócios será empregadas através dos padrões de projeto GAMMA (1995), evitando que um único objeto seja responsável por manter todas as estratégias de operação .

  • Camada de Infraestrutura. Sua principal responsabilidade será a de fornecer o controle das funcionalidades entre as camadas, bem como realizar o acesso aos dados, sua persistência e a manipulação das exceções surgidas no decorrer da aplicação.

5.3 Interface do Protótipo

O protótipo apresenta uma interface simples e intuitiva, tendo por finalidade verificar a aplicação da técnica proposta bem como torná-la mais prática possível para os analistas e desenvolvedores. O protótipo, FMIT, faz uso de outras tecnologias para dar suporte às atividades necessárias descritas no processo de integração. O FMIT associa a implementação destas tecnologias, por exemplo, o Eclipse e FetureIDE de tal forma que facilite o uso, para usuários com pouca experiência em codificação. O protótipo lê e filtra as informações das tags de arquivos escritos em XML e transforma-os em um modelo de features abstrato, no qual os elementos do modelo de entrada podem ser manipulados.

O termo integração de modelos de features pode ser definido como um conjunto de atividades que devem ser executadas com dois (ou mais) modelos de features de entrada, ou seja, o Modelo de Features Referencia, MF, e Modelo de Features Comparado, MF. O objetivo é a união destes modelos para a produção de um novo modelo, ou seja, o Modelo de Features Pretendido, MF. O principal desafio é resolver os conflitos que surgem na composição destes modelos. A Figura 5.9 ilustra o protótipo desenvolvido. Cada parte da interface será descrita a seguir.

Definição do ferramental. Para execução do protótipo se faz necessário três ferramentas: o (1) Eclipse, que é parte integrante do framework utilizado, o (2) FeatureIDE para modelagem, e por fim, o protótipo(3)FMIT, para dar suporte a integração dos modelos.

Definição dos modelos. Esta atividade consiste primeiramente na criação do modelo de features ou na importação de um modelo já existente. Estes dois processos podem ser realizados no framework FeatureIDE.

Execução do Protótipo. Esta atividade será usada para construir o novo modelo. Exibindo os resultados do protótipo, FMIT, inerente à integração de dois modelos de features, de acordo com as estratégias aplicadas, retornando como saída o modelo integrado ou pretendido. A abordagem automática ou semiautomática é estabelecida pelo limiar de acordo com as regras de negócio. A Figura 5.9 mostra uma visão geral do protótipo, FMIT, juntamente com alguns dos componentes da estrutura destacados com letras, por exemplo, (A), (B), (C) e (D-d). O protótipo apresenta uma visão inicial para a integração de modelos específicos dentro da estrutura, e é discutida brevemente abaixo:

Elaborado pelo Autor.
Figura 5.9: Protótipo feature model integration tool - FMIT.
  • Package Explorer (A). Para cada novo projeto de modelagem, é necessário criar ou importar arquivos que são usados durante o processo de modelagem. O explorador de pacotes tem como funcionalidade central permitir a organização dos projetos dos modelos de features, bem como acomodar o protótipo de integração.

  • Visualização (B-C). Os modelos criados, necessariamente devem ser visualizados com o objetivo de atender dois requisitos básicos ao usar os modelos: compreensão e comunicação. Diante desta necessidade, a visualização dos modelos permite aos analistas ou desenvolvedores analisar e editar o modelo interativamente, entre o protótipo e framework. Os modelos de features são acomodados em conjunto com o protótipo, FMIT, para ajudar a explorar os conflitos quando existir. Nesse exemplo temos dois modelos de features, o fmA e fmB a serem integrados.

  • Visualização do Console (D). Uma vez que os modelos foram criados ou importados, uma visão geral da distribuição dos elementos das features presentes é exibida e pode ser executada através do console, constituindo na usabilidade do protótipo.

    d-1, persistência:

    Consiste na persistência dos dados em um arquivo no formato de texto salvo no disco rígido, bem como define a entrada dos modelos, isto é, a importação dos arquivos de origem e destino no formato XML, no exemplo fmA e fmB. Após o protótipo executa uma validação dos arquivos, basicamente para verificar se não há uma inconstância em seu formato, sendo o passo seguinte a comparação dos modelos mencionados e exibe os resultados obtidos.

    d-2 a d-8, resultados:

    Exibe os resultados oriundos da comparação entre os modelos fmA e fmB, individualmente, em um vetor que contém os valores da similaridade, que variam entre 0 a 1. Por fim, é exibido o seu grau de equivalência das estruturas analisadas. Este cenário atribui-se como um filtro, em virtude de diagnosticar e avaliar diversos aspectos na contribuição de uma integração de boa qualidade tais como, número de features, estrutura sintática e semântica entre outros. Pode-se verificar (d-8) que a similaridade geral entre os modelos comparados no exemplo é de 0.62, ou seja, o modelo destino, fmB é 62% equivalente ao modelo origem, fmA. Neste caso, o limiar foi inferior ao esperado. Há muitos conflitos que surgiram durante a fase de comparação.

    d-9, automatização:

    Esta etapa consiste em auxiliar os analistas e desenvolvedores na condução de integração segura dos modelos. O protótipo disponibiliza duas opções de integração para escolher, a automática que atua sem a intervenção do analista ou desenvolvedor, prospectando quatro modelos de saída conforme as estratégias de integração (união, interseção, diferença e complemento) para uma futura edição, ou a semiautomática, que atua com a intervenção humana, recomendada neste caso.

    d-10,

    Após selecionar a opção semiautomática os conflitos identificados são exibidos no console para sua escolha, incumbindo ao analista ou desenvolvedor tomar a decisão que melhor direcionar os requisitos estabelecidos em seu projeto.

    d-11,

    Finalmente o console exibe a integração do novo modelo de features, bem como o seu grau de equivalência. Após a composição dos modelos neste exemplo é 100% similar, indicando que posteriormente à sua edição os conflitos existentes foram solucionados de acordo com os requisitos estabelecidos no projeto.

5.4 Algoritmos do Protótipo

Esta Seção apresenta os algoritmos elaborados para implementar as funcionalidades de (1) carregar modelos, (2) comparar modelos, (3)definir o tipo de integração, e (4)integrar os modelos. Tais atividades foram anteriormente ilustradas na Figura 5.2. Os algoritmos são apresentados a seguir.

O framework FeatureIDE exibe o modelo de features de duas formas, graficamente e textualmente, o formato adotado para representar os diagramas textualmente segue o padrão XML. Dessa forma, o seu conteúdo e sua estrutura são constituídos por instruções de marcações, ou seja, tags.

Para realizar a leitura dos modelos de features de entrada no protótipo, FMIT, o componente de análise executa o método de conversão das instruções de marcação para capturar e armazenar em memória, todas as propriedades e atributos dos elementos contidos no arquivo em análise. Cada tipo de notação (opcional, alternativo, obrigatório, etc) possui sua própria características, que são representados por atributos e propriedades nas tags XML, de modo que o interpretador precisa reconhecer cada uma delas para identificar corretamente as informações contidas na tag.

Elaborado pelo Autor.
Figura 5.10: Protótipo tags XML de modelos de features

A Figura 5.10 exibe um exemplo em que a tag struct apresenta as propriedades abstract, mandatory, e name e os atributos and, or, alt, description e feature. O modelo segue a representação proposta por KANG et al. (1990),Feature-Oriented Domain Analysis (FODA).

A Tabela 5.1 exibe o Algoritmo 1, que executa o método de exploração do conteúdo do modelo de features de entrada , que realiza um laço de repetição no arquivo (modelo de feature) para capturar todas as tags que representam os elementos e atributos. Assim que uma tag (elemento) é capturada, a mesma é identificada e seus atributos são armazenados em memória. Como suporte ao ferramental aplicou-se o uso da biblioteca JDom 111http://www.jdom.org/downloads/docs.html, que é uma API para facilitar a leitura, criação e atualização de documentos.

Algoritmo 1: Leitura e importação de modelo
Entrada: Modelo de Features
Saída: Elementos do modelo carregado em memória
1: Importa biblioteca jdom2.org;
2: arquivoXML modeloFeature.xml;
3: Enquanto arquivoXML Faça // realiza a leitura até o fim do arquivo
4: tipoElemento tagXML ;
5: tipo tipoElemento.identificaElemento();
6: Para i = 0 até tipo.qtdAtributos() Faça
7: objeto tipo.Elemento.analisaXML(tipo);
8: persiste (objeto);
9: Fim para
10: Fim enquanto

Elaborado pelo Autor.

Tabela 5.1: Algoritmo 1.

A identificação de equivalência entre os elementos dos modelos de features entrada (MF e MF) e a respectiva composição desses elementos para a produção de um Modelo de Features Integrado, MF, é realizada pelos algoritmos abaixo. Os algoritmos são responsáveis pela implementação das técnicas de comparação e integração descritos no Capitulo 4. A Tabela 5.2 apresenta o Algoritmo 2 que, executa um laço entre elementos comparados (MF e MF), verifica a sequência, ou seja, analisa se as features estão no mesmo índice e atribui um escore entre 0 e 1, para calcular o Grau de Equivalência Estrutural dos modelos comparados.

Algoritmo 2: Equivalência Estrutural
Entrada: Modelo de Features – MFR e MFC
Saída: Equivalência Estrutural carregado em memória
1: Algoritmo1 (Modelo de Features Origem - MFR)
2: vetorOrigem [] objetoOrigem
3: Algoritmo1 (Modelo de Features Destino – MFC)
4: vetorDestino [] objetoDestino
5: Para i = 0 até vetorOriem() Faça
6: Para j = 0 até vetorDestino() Faça
7: Se elemento.vetorDestino().índice[i] elemento.vetorOrigem().índice [j]
8: vetorEstrutura[i] 1;
9: Senão Se elemento.vetorDestino().índice[i] != elemento.vetorOrigem().índice [j]
10: vetorEstrutura[i] 0;
11: Fim Se
12: Fim Se
13: Fim para
14: Fim para
15: Para i = 0 até vetorEstrutura() faça
16: equivalênciaEstrutural + vetorEstrutura[i]/ vetorEstrutura .tamanhoÌndice;
17: Fim para
18: Imprimir (“FMI – Vetor de Comparação Estrutural:”) + vetorEstrutura[i] ;
19: Imprimir (“FMI – Grau de Equivalência Estrutural :”) + equivalênciaEstrutural;

Elaborado pelo Autor.

Tabela 5.2: Algoritmo 2.

A Tabela 5.3 demostra o Algoritmo 3, que exibe em sua saída o Grau de Equivalência Sintática, aplica-se a função de Jaro Winkler (WINKLER, 1990), esta métrica é indicada à comparação de pequenas strings COHEN; RAVIKUMAR; FIENBERG (2003); FARIAS; GARCIA; WHITTLE (2008), ou seja a comparação de palavras curtas, neste caso adaptado à features. O algoritmo executa um laço entre features comparado seu rótulo (MF e MF), e atribui um escore que vária entre 0 a 1.

Algoritmo 3: Equivalência Sintática
Entrada: Modelo de Features
Saída: Elementos do modelo carregado em memória
1: Algoritmo1 (Modelo de Features Origem - MFR)
2: vetorOrigem [] objetoOrigem
3: Algoritmo1 (Modelo de Features Destino – MFC)
4: vetorDestino [] objetoDestino
5: Para i = 0 até vetorOriem() Faça
6: Para j = 0 até vetorDestino() Faça
8: vetorJW [i] jaroWinkler (elemento de MFR, elemento MFC) ;
9: Fim para
10: Fim para
11: Para i = 0 até vetorJW() Faça
12: equivalênciaSintática + vetorJW [i]/ vetorJW .tamanhoÌndice;
13: Fim para
14: Imprimir (“FMI – Vetor de Comparação Sintática:”) + vetorJW[i] ;
15: Imprimir (“FMI – Grau de Equivalência Sintática:”) + equivalênciaSintática;

Elaborado pelo Autor.

Tabela 5.3: Algoritmo 3.

A Tabela 5.4 exibe o Algoritmo 4, que executa um laço entre elementos comparados (MF e MF), verificando o relacionamento entre as features (opcional, obrigatório, alternativo inclusivo, alternativo exclusivo, dependências, e exclusão) e atribui um escore entre 0 e 1, para calcular o Grau de Equivalência Semântica dos modelos comparados.

Algoritmo 4: Equivalência Semântica
Entrada: Modelo de Features
Saída: Elementos do modelo carregado em memória
1: Algoritmo1 (Modelo de Features Origem - MFR)
2: vetorOrigem [] objetoOrigem
3: Algoritmo1 (Modelo de Features Destino – MFC)
4: vetorDestino [] objetoDestino
5: Para i = 0 até vetorOriem() Faça
6: Para j = 0 até vetorDestino() Faça
7: Se elemento.vetorDestino().índice[i] == elemento.vetorOrigem().índice [j]
8: vetorSemântico[i] 1;
9: Senão Se elemento.vetorDestino().índice[i] != elemento.vetorOrigem().índice [j]
10: vetorSemântico [i] 0;
11: Fim Se
12: Fim Se
13: Fim para
14: Fim para
15: Para i = 0 até vetorSemântico () Faça
16: equivalênciaSemântica + vetorSemântico [i]/ vetorSemântico .tamanhoÌndice;
17: Fim para
18: Imprimir (“FMI – Vetor de Comparação Semântico:”) + vetorSemântico;
19: Imprimir (“FMI – Grau de Equivalência Semântica:”) + equivalênciaSemântica;

Elaborado pelo Autor.

Tabela 5.4: Algoritmo 4

Finalmente, a Tabela 5.5 demonstra o Algoritmo 5, que representa o grau de equivalência global entre os modelos comprados (MF e MF), ou seja, o Calculo de Efetividade Estratégica que representa as táticas adotadas na verificação de similaridade dos modelos, obtidos através somatório dos Algoritmos 2, 3 e 4 divididos pelo número de estratégias de comparação aplicadas.

Algoritmo 5: Equivalência Global
Entrada: Algoritmos 2, 3 e 4.
Saída: Cálculo de Efetividade Estratégica, CEE, carregado em memória.
1: CEE 0;
2: CEE (equivalênciaEstrutural+ equivalênciaSintática+ equivalênciaSemântica)/3;
3: Imprimir (“FMI – Cálculo de Equivalência Global :”) + CEE;

Elaborado pelo Autor.

Tabela 5.5: Algoritmo 5

Após a obtenção da equivalência global dos modelos comparados, aplicam-se os algoritmos para implementação das estratégias de integração: estratégia automática (1), exibida a partir do Algoritmo 6, na Tabela 5.6 e por fim a estratégia semiautomática (2), demostrada na Tabela 5.7 o Algoritmo 7. Os algoritmos implementados estendem classes e interfaces oriundos da linguagem Java, como por exemplo, o Java Utilities, para trabalhar com estruturas de coleções e interface, para trabalhar com, Set e List. A adoção destes métodos advém da facilidade de uso de recursos para operações de comparação entre elementos de conjuntos ou listas.

Algoritmo 6: Integração Automática
Entrada: MFR e MFC
Saída: MFI, carregados em memória
1: Algoritmo1 (Modelo de Feature Origem - MFR)
2: vetorOrigem [] objetoOrigem
3: Algoritmo1 (Modelo de Feature Destino – MFC)
4: vetorDestino [] objetoDestino
//união dos elementos
5: Lista <features> adicional novaLista<features>();
6: adicional.adicionarTodos(vetorOrigem),
7: adicional.adicionarTodos(vetorDestino),
//intersecção dos elementos
8: Lista <features> formal novaLista<features>();
9: formal.adicionarTodos(vetorOrigem),
10: formal.manterTodos(vetorDestino),
//diferença dos elementos
11: Lista <features> parcial novaLista<features>();
12: parcial.adicionarTodos(vetorOrigem),
13: parcial.removerTodos(vetorDestino),
//complemento dos elementos
14: Lista <features> complementar novaLista<features>();
15: complementar.adicionarTodos(vetorDestino),
16: complementar.removerTodos(vetorOrigem),
17: Imprimir (“FMI – União:”) + adicional;
18: Imprimir (“FMI – Intersecção:”) + formal;
19: Imprimir (“FMI – Diferença:”) + parcial;
20: Imprimir (“FMI – Complemento:”) + complementar;

Elaborado pelo Autor.

Tabela 5.6: Algoritmo 6

O Algoritmo 6, apresenta as técnicas operacionais de integração descritas na Seção 4.3.1 (Comum, Adicional, Formal, Parcial, Complementar, Nula), as demais técnicas a Estratégia Nula é chamada quando não há qualquer similaridade entre os elementos comparados aplicando o método adicional, descrito na linha 5, já a Estratégia Comum é, repito, o vetor de origem, pois não existe diferenças entre os modelos comparados, descrito na linha 2. O algoritmo acima contém os métodos para integrar os modelos após sua comparação, a linha 5 chama o método adicional, responsável por adicionar novos elementos aos modelo integrado, MF; a linha 8 chama o método formal, que exclui os elementos incomuns de ambos os modelos comparados; a linha 11 chama o método parcial que exibe as diferenças contidas no modelo origem, MF, comparadas ao modelo destino, MF, gerando o modelo integrado, MF; por fim, o método complementar é executado na linha 14 exibindo as diferenças contidas no modelo destino, MF, compradas ao modelo origem, MF, gerando o modelo integrado, MF.

A Figura 5.11 ilustra a integração entre o MF, e MF,, exibindo a estratégia de integração automática bem como sua respectiva saída conforme o algoritmo 6 propõe. A Figura também exibe em sua saída os resultados oriundos dos algoritmos 2, 3, 4 e 5. O cálculo global de equivalência entre os modelos é de 63%, originado do algoritmo 5. Ao selecionar a opção automática o mesmo integra ambos os modelos produzindo as seguintes saídas: (1) Estratégia Adicional-União: [MF, A, B, C, D, E, F, H, J], (2) Estratégia Formal-Intersecção: [MF, B, D], (3) Estratégia Parcial-Diferença: [F, H, J], e por fim, a (4) Estratégia Complementar-Complemento: [A, C, E].

Elaborado pelo Autor.
Figura 5.11: Exemplo de integração automática.

A Tabela 5.7 e a Tabela 5.8 exibem o Algoritmo 7, que ilustra a Estratégia de Integração Semiautomática que tem como objetivo auxiliar na produção final do modelo pretendido, MF, ou seja, sua função é localizar os conflitos inerentes aos modelos que virão a ser integrados, o modelo referência, MF, e o modelo comparado, MF, exibindo aos analistas ou desenvolvedores para que os mesmos tomem a decisão de qual elemento deve-se integrar ao modelo conforme os requisitos de projeto estabelecidos.

Algoritmo 7: Integração Semiautomática
Entrada: Modelo de Features Origem - MFR e Modelo de Features Destino – MFC
Saída: Modelo de Features Pretendido - MFAB, carregados em memória
1: Algoritmo1 (Modelo de Feature Origem - MFR)
2: vetorOrigem [] objetoOrigem
3: Algoritmo1 (Modelo de Feature Destino – MFC)
4: vetorDestino [] objetoDestino
5: Para i = 0 até vetorOriem() faça
6: Para j = 0 até vetorDestino() faça
7: Se elemento.vetorDestino().índice[i] == elemento.vetorOrigem().índice [j]
8: verificaEquivalencia[i] 1;
9: Senão Se elemento.vetorDestino().índice[i] != elemento.vetorOrigem().índice [j]
10: Imprimir (“Existem diferenças sintáticas ou semânticas entre os modelos comparados.”);
11: Imprimir (“Origem – [+vetorOrigem[i]]+ é diferente do Destino – [+vetorDestino[j]]”);
12: Imprimir (“Deseja alterar o relacionamento ou feature? sim para: [+vetorOrigem[i]] ou
não para: [+vetorDestino[j]].”)
13: Ler (retornoQuestão);
14: Faça
15: Se retornoQuestão == “sim” ou retornoQuestão== “não”
16: Se retornoQuestão == “sim”
17: vetorDestino().índice[i] vetorOrigem().índice [j];
18: Senão Se retornoQuestão == “não”
19: vetorOrigem().índice [j] vetorDestino().índice[i];
20: Fim Se
21: Fim Se
22: Fim Se
23: verificaQuestão verdadeiro
24: Se
25: Imprimir (“Escolha invalida !!!”);
26: Imprimir (“Deseja alterar o relacionamento ou feature?
sim para: [+vetorOrigem[i]] ou não para: [+vetorDestino[j]].”);
27: Ler (retornoQuestão);
28: verificaQuestão falso
29: Fim Se
30: Fim Enquanto(verificaQuestão falso);
31: verificaEquivalencia[i] 0;
32: Fim Se
33: Fim Se
34: Fim para
…continua

Elaborado pelo Autor.

Tabela 5.7: Algoritmo 7
…continuação
35: Fim para
36: Para i = 0 até vetorOrigem () faça \\ armazena valores do vetor antes de sua alteração
37: vetorOrigemInalterado[i] vetorOrigem [i];
38: Fim para
39: Para i = 0 até vetorOrigemInalterado () faça
40: Para j = 0 até vetorDestino() faça
41: Se elemento. OrigemInalterado ().índice[i] == elemento.vetorDestino().índice[j]
42: novaEquivalencia[i] 1;
43: Senão Se elemento.OrigemInalterado ().índice[i] != elemento.vetorDestino().índice[j]
44: novaEquivalencia[i] 0;
45: Fim se
46: Fim Se
47: Fim para
48: Fim para
49: resultadoNovaEquivalência 0;
50: Para i = 0 até novaEquivalencia () faça
51: resultadoNovaEquivalência + novaEquivalencia[i] / novaEquivalencia.totalElementos;
52: Fim para
53: Imprimir (“FMI – Vetor de Comparação Sintatico e Semântico:”) + novaEquivalencia[i];
54: Imprimir (“FMI – Grau de Equivalência :”) + resultadoNovaEquivalência;
55: Imprimir (“FMI – Modelo de Feature Pretendido:”) + vetorDestino;

Elaborado pelo Autor.

Tabela 5.8: Algoritmo 7 complemento

O Algoritmo 7 requer a intervenção dos analistas e dos desenvolvedores; para isso da linhas 1 até a linha 4, executam importação dos arquivos de comparação, isto é, o modelo referência, MF, e o modelo comparado, MF. As linhas subsequentes, 5 e 6 iniciam laço para verificar conflitos nos modelos em análise, mais especificamente na linha 9, exibindo em sua saída as questões inerentes às diferenças encontradas, nas linhas 10, 11 e 12. Em meio às linhas 14 a 19, mais especificamente nas linhas 17 e 19, o algoritmo substitui os elementos dos modelos conflitantes que virão a produzir como saída modelo pretendido, MF. O próximo laço, na linha 36, armazena os dados do modelo referência, para futuramente calcular similaridade do novo modelo. Os laços seguintes, designadamente nas linhas subsequentes, 39 a 52 determinam a equivalência entre o modelo referência, MF, e o novo modelo produzido, isto é, modelo pretendido, MF. Por fim, as linhas finais 53 a 55 exibem os seguintes resultados: (1) vetor de comparação dos dados que foram alterados, representados por 0 e 1, onde zero representa os elementos alterados ou não similares e hum representa os elementos inalterados ou similares; exibe o novo (2) grau de equivalência entre a comparação dos modelos MF e MF; e finalmente (3) exibe o modelo de features pretendido.

Elaborado pelo Autor.
Figura 5.12: Exemplo de integração semiautomática.

A Figura 5.12 ilustra como ocorre a interação do protótipo com os analistas e desenvolvedores aplicando a estratégia de integração semiautomática. Conforme o algoritmo 5 descrito anteriormente responsável pelo o (1) cálculo de equivalência entre os modelos comprados. A figura abaixo exibe uma equivalência de 83%. Após a alteração do modelos pode-se observar que o novo (2) cálculo de equivalência passou para 91% de similaridade. Como se pôde perceber na imagem a estratégia de integração selecionada é a semiautomática; logo abaixo é exibido os modelos de features, MF e MF. A interação com o usuário do protótipo é exibida logo abaixo, sendo identificados os seguintes conflitos nos (3) diagramas exibidos também graficamente: (A) conflito de relacionamento, conforme o exemplo manteve-se o elemento obrigatório; (B) o conflito entre as features permanecendo o elemento F, o último conflito encontrado entre as features permanece o elemento H. Por fim, é exibo um novo vetor (4) reflexo das substituições dos conflitos alterados e o (5) modelo pretendido, MF.

5.5 Tecnologias Utilizadas

O protótipo desenvolvido é um plug-in para Eclipse, utilizando a linguagem de programação em Java. O Eclipse possibilita ao desenvolvedor estender suas funcionalidades à IDE na forma de plug-in. O plug-in é um componente de software usado para adicionar funções a programas maiores, provendo uma funcionalidade específica ou sob demanda ZIBRAN; ROY (2011). A ferramenta adotada como suporte para o desenvolvimento do protótipo foi a FeatureIDE,é framework baseado na IDE Eclipse para a modelagem de features, o FeatureIDE KASTNER et al. (2009). A ferramenta foi desenvolvida para automatizar o processo de modelagem e configurações dos artefatos reusáveis. A FeatureIDE foi escolhida por dois motivos: (1) flexibilidade na importação e exportação dos modelos produzidos, possibilitando sua edição em tempo de execução; (2) o segundo fato se deve a notação da ferramenta suporta a técnica FODA KANG et al. (1990), bem como atende os critérios exclusão e as dependências entre as features.

FeatureIDE fornece um editor para modelagem de features e permite a construção textual e gráfica dos modelos. A principal característica da ferramenta é a cobertura de todas as atividades de desenvolvimento e a incorporação de ferramentas para a implementação de LPS. A proposta apresentada pelo FeatureIDE é a redução de esforço para construção de ferramentas extensíveis a LPS THÜM et al. (2014); KASTNER et al. (2009); APEL; KÄSTNER (2009), análise e implementação de domínio, análise de requisitos e geração de software.

A ferramenta apresenta também as seguintes particularidades: (1) ampla integração com o Eclipse; (2) editor de modelo de features; (3) editor de configurações e restrições; (4) dados estatísticos; e, por fim, (5) possibilita a integração com diversas linguagens de programação (por exemplo, Java, C, XML ), tais como ferramentas que dão suporte à modelagem de features (por exemplo, AHEAD, FeatureHOUSE, FeatureC, entre outros). A Figura 5.13 exibe um exemplo através da captura de tela do Eclipse mostrando algumas das principais funcionalidades do framework descritas anteriormente.

Elaborado pelo Autor.
Figura 5.13: Particularidades do framework featureIDE.

6.1 Objetivo e Questões de Pesquisa

Este estudo avalia os efeitos das técnicas de integração de modelos de features em duas variáveis: o (1) esforço dos analistas e desenvolvedores na detecção de conflitos e a (2) exatidão na correção dos modelos produzidos. Estes efeitos são investigados a partir de seis cenários de evolução envolvendo composições de modelos. Com isto em mente, o objetivo deste experimento segue o modelo GQM (Goal, Questions, Metrics) WOHLIN et al. (2000), procurando:

Analisar as técnicas de integração de modelos de features

com a finalidade de investigar os efeitos

no que diz respeito ao esforço e corretude

a partir da perspectiva de analistas e desenvolvedores

no contexto de evolução do modelo de features.

Dessa forma, este experimento procura avaliar o efeito da técnica proposta no esforço empregado para integrar modelos, bem como na corretude das integrações realizadas. Assim, o experimento busca mensurar a utilização da técnica manual em relação a utilização da técnica semiautomáticas, descritas anteriormente na Seção 1.2, tendo em vista que estes objetivos definem as hipóteses para o experimento.

6.2 Formulação das Hipóteses

Com o embasamento dos experimentos executados neste estudo, que buscam mensurar o esforço e a corretude dos modelos produzidos de forma manual e semiautomática, duas hipóteses foram formuladas para avaliar a técnica proposta no Capítulo 5 .

Hipótese 1. A técnica de integração do modelo de features tende em um primeiro momento a ser amigável, devido a sua simplicidade. Entretanto, à medida em que as possíveis características e combinações se ampliam podem tornar-se onerosas, uma vez que envolvem procedimentos de análise dos modelos de entrada MF e MF para identificar as possíveis equivalências entre os elementos de todos os modelos.

As equipes de desenvolvimento podem investir grande esforço para compor modelos, e esses esforços muitas vezes não são convertidos no modelo pretendido, ou seja, apresenta um modelo inconsistente FARIAS et al. (2015a); OLIVEIRA (2012). Portanto, a primeira hipótese avalia se a técnica de integração semiautomática, com base no protótipo proposto, reduz o esforço de integração, auxiliando os analistas e desenvolvedores a comporem os modelos consumindo menor tempo. Com base nesta conjectura, as hipóteses nula e alternativa sobre o Esforço de Integração (EI) são apresentadas a seguir:

Hipótese Nula 1, (H1-0): A técnica semiautomática e o protótipo propostos não reduzem o esforço de integração ao produzir o modelo pretendido, MF, a partir dos modelos referência, MF, e modelo comparado, MF.
H1-0: EI semiautomática (MF, MF) EI manual MF, MF).

Hipótese Alternativa 1, (H1-1): A técnica semiautomática e o protótipo propostos reduzem o esforço de integração ao produzir o modelo pretendido, MF, a partir dos modelos referência, MF, e modelo comparado, MF .
H1-1: EI semiautomática (MF, MF) EI manual (MF, MF).

Ao analisar a primeira hipótese, pretende-se avaliar se a técnica de integração proposta reduz os esforços dos analistas e desenvolvedores na produção do modelo pretendido, MF, gerando assim evidências empíricas sobre como as técnicas propostas acomodam as mudanças futuras de MF, MF.

Hipótese 2. As inconsistências incidem na composição de modelos devida às alterações conflitantes, afetando as propriedades sintáticas e semânticas do modelo, sendo que sua integração não coincide com o modelo pretendido OLIVEIRA; BREITMAN; OLIVEIRA (2009b, a); WEBER et al. (2016). A correção das integrações é influenciada pela presença, ou não, das inconsistências no modelo integrado de saída, assim é necessário avaliar a corretude das alterações efetuadas. Esta hipótese avalia se a integração realizada de forma semiautomática, com base na técnica e no protótipo proposto, auxilia os analistas e desenvolvedores a reduzir em sua saída um modelo com inconsistência, ou seja, modelos que não possuem erros em comparação ao modelo pretendido. Com base nesta declaração, definem-se as hipóteses nula e alternativa comparando a Integração Correta (IC) apresentada a seguir:

Hipótese Nula 2, (H2-0): A técnica e o protótipo proposto não amparam significativamente na extinção de falhas ao produzir o modelo pretendido, MF, a partir dos modelos referência, MF., e modelo comparado, MF.
H2-0: IC semiautomática (MF) IC manual(MF).

Hipótese Alternativa 2, (H2-1): A técnica e o protótipo proposto auxiliem significativamente na extinção de falhas ao produzir o modelo pretendido, MFAB, a partir dos modelos referência, MFR, e modelo comparado, MFC .
H2-1: IC semiautomática (MF) IC manual (MF).

Ao analisar a segunda hipótese, se produz conhecimento empírico sobre a técnica de integração semiautomática, impactando na correção do modelo, visto que a mesma pode inferir no nível de assertividade das alterações reduzindo os conflitos inerentes de falhas produzidas durante a atividade de integração manual e possivelmente um aumento de produtividade e maior precisão da informação, bem como na qualidade final dos modelos de features produzidos, e, por fim, acredita-se em uma amortização ou eliminação dos esforços de retrabalho na resolução de más integrações.

A Tabela 6.1 apresenta um resumo das hipóteses nulas e alternativas deste experimento, que visam elencar indícios que sejam suficientes para responder à questão de pesquisa deste estudo. A partir dos testes de hipóteses, pretende-se confirmar se a técnica e o protótipo proposto auxiliam na eficiência das integrações assim como propõem se em melhorar a eficácia do modelo de features final produzido.

Hipótese Tipo Representação
H1 Nula H1-0: EI semiautomática (MF, MF) EI manual (MF, MF)
Alternativa H1-1: EI semiautomática (MF, MF) EI manual (MF, MF)
H2 Nula H2-0: IC semiautomática (MF) manual (MF)
Alternativa H2-1: IC semiautomática (MF) IC manual (MF)

Elaborada pelo autor.

Tabela 6.1: Resumo das hipóteses.

6.3 Variáveis do Estudo

Como variável independente esta pesquisa identifica o modelo de diagrama baseado em feature, já as variáveis nominais são representadas através da experiência, habilidade, e do grau de escolarização dos participantes, demostrando as questões de avaliação que incidem sobre as vaiáveis dependentes: Integração Correta (IC) e Esforço de Integração (EI) que norteiam esta pesquisa WOHLIN et al. (2012); FARIAS et al. (2015a); OLIVEIRA (2008). Esforço de integração, “EI” representa o tempo médio (minutos) em que os participantes levaram para solucionar as questões de integração entre os modelos propostos. A integração correta, “IC” demonstra a assertividade, ou não da questão em analise e identifica o modelo determinado como ideal na pesquisa. Em síntese, verifica se o modelo retornado como saída, isto é, o modelo pretendido, MF, é correto ou incorreto. A Tabela 6.2 mostra o resumo das variáveis investigadas neste estudo.

A variável dependente na primeira hipótese é o Esforço de Integração exibido na Tabela 6.2, que inclui o esforço global para integrar dois modelos de entrada, MF e MF, considerado o tempo para aplicar as técnicas de integração e detecção de diferenças sintáticas, semânticas e estruturais entre os modelos comparados, assim como o tempo para resolver os conflitos que surgem durante o processo de integração, no intuito de produzir o modelo pretendido, MF, sendo esta variável medida em minutos. O motivo principal pelo qual investiga-se esta variável é determinado por ser uma das tarefas mais importantes realizadas pelos analistas e desenvolvedores para integrar dois modelos de entrada em configurações realistas WOHLIN et al. (2012); FARIAS et al. (2015a). A análise desta variável permite medir o impacto sobre a variável, independente em cada uma das questões elencadas, comparando os valores (em minutos) assumidos por essas variáveis. Pode-se também entender como as técnicas de integração analisadas tendem a ser mais eficientes na obtenção de seus resultados desejados.

Variável Escala
Variáveis independentes Principal Nominal: analistas, desenvolvedores
Experiência Nominal: Iniciante, Experiente
Habilidade Nominal: Baixa, Alta
Educação Nominal: Graduação, Pós-graduação
Variáveis dependentes Corretude Ordinal: 0 ou 1
Esforço Intervalo [0..60]

Elaborada pelo autor.

Tabela 6.2: Variáveis do estudo.

A variável independente na segunda hipótese é a Integração Correta do modelo. Considerando o primeiro, modelo integrado produzido é correto se este estiver em conformidade com as solicitações de mudanças elencadas no experimento, isto é, modelo de features integrado é igual ao modelo de features pretendido, MF MF, onde a correção total de uma integração é parcialmente assegurada. O modelo integrado poder ser classificado como Correto, considerando que todas as mudanças elencadas foram realizadas, neste caso a variável assume o valor igual 1 e Incorreto quando alguma mudança não fora realizada, a variável assume o valor igual 0. Pretende-se assim avaliar qual o impacto resultante da técnica semiautomática, visto que na ocorrência de conflitos os mesmo são indicados aos analistas e desenvolvedores, os quais tem a competência de tomada de decisão, apoiados pelo protótipo, FMIT, que exibe informações dos conflitos sejam estes semânticos sintáticos ou estruturais, determinando assim a futura integração do modelo pretendido. Com isso em mente, procura-se analisar a qualidade dos modelos produzidos, a efetividade e a pertinência do conhecimento agregado, buscando assim elevar o nível de eficácia das integrações para ser capaz de reduzir os custos, aumentar a qualidade, e produtividade dos modelos de features.

6.4 Contexto do Experimento e Seleção dos Participantes

Com o intuito de mensurar o esforço e a corretude das integrações de modelos de features, aplicou-se um experimento para avaliar como os analistas e desenvolvedores realizam esta tarefa, ou seja, a apuração das principais dificuldades durante o processo de integração avaliando-se o desempenho, assim como efetuar um comparativo entre os modelos produzidos, visto assegurar as mudanças das funcionalidades elencadas. Para isso, foram criados seis cenários de avaliação, sendo que cada cenário compreende dois modelos, identificados pelo conjunto M = (MF1R; MF1C); ( MF2R; MF2C); … (MF6R; MF6C), onde MF indica o primeiro modelo de entrada e MF , o segundo modelo e cada cenário é identificado pelos números de 1 a 6. Além disso, cada cenário apresenta uma descrição das funcionalidades estabelecidas para conduzir os analistas e desenvolvedores na produção do modelo de features desejado.

A Tabela 6.3 apresenta as atividades, bem como os cenários de evolução aplicados a este experimento. Para o desenvolvimento do experimento utilizou-se 06 atividades elaboradas para verificar o esforço e habilidade dos analistas e desenvolvedores na resolução das atividades conflitantes, sejam estas sintáticas, semânticas ou estruturais. Os cenários elaborados na Tabela 6.3 apresentam uma pequena descrição destes e os elementos contidos em cada modelo de features, isto é, o número de features, o número de relacionamentos e o número de conflito quando existir entre os modelos que virão a ser integrados, bem como o número total dos elementos que compõem o modelo. Os modelos de entrada, 06 modelos MF e 06 modelos MF, totalizando em 12 modelos produziram um total de 205 elementos entre features e relacionamentos, isto é notações.

Cenário de Evolução MFR MFC
Nome NF NR NE Nome NF NR NE NC
01- Não sofre mudanças. MF1R 7 4 11 MF1C 7 4 11 0
02- Mudanças sintáticas. MF2R 10 8 18 MF2C 10 8 18 4
03- Mudanças estruturais. MF3R 14 12 26 MF3C 14 12 26 1
04- Mudanças de semânticas. MF4R 13 11 24 MF4C 13 11 24 6
05- Inclusão de novas features. MF5R 7 5 12 MF5C 3 2 5 0
06- Mudanças sintáticas e semânticas. MF6R 9 6 15 MF6C 9 6 15 7
Total de Elementos 106 99
Legenda
NF: nº de features, NR: nº de relacionamentos,
NE: nº de elementos, NC: nº de conflitos.

Elaborada pelo autor.

Tabela 6.3: Cenário do experimento.

Além dos modelos para integração, os participantes receberam um questionário com perguntas para obter dados inerentes ao perfil, tempo de experiência, formação acadêmica, sexo, idade entre outros. Desta forma, será possível realizar uma análise dos dados dos participantes.

Após a definição das funcionalidades a serem tratadas: (1) sintática; (2) semântica e (3) estrutural, elaborou-se as atividades a serem realizadas pelos participantes, conforme a Tabela 6.3, sendo que cada atividade foi definida para um fim específico. As atividades foram subdivididas em duas tarefas, sendo uma executada manualmente, isto é, sem o auxílio do protótipo, FMIT, e a outra com o apoio do protótipo, FMIT. As questões foram separadas em dois grupos cada uma contendo três modelos de features para análise dos participantes. Formularam-se os seguintes conjuntos de questões: AQ1 = (Questão 1, Questão 2, e Questão 4) e AQ2 = (Questão 3, Questão 5, e Questão 6) , sendo estes conjuntos distribuídos entre os participantes conforme demostrada na Tabela 6.4, intercalando entre os participantes o agrupamento das questões, executando ora de forma manual e ora de forma semiautomática assim buscando equilibrar as questões entre os participantes. O experimento foi conduzido com dez participantes na maioria alunos do mestrado de Computação Aplicada da Unisnos.

Participantes Agrupamento Questões AQ1 Agrupamento Questões AQ2
P01 MS-FMIT SC-FMIt
P02 SC-FMIT MS-FMIt
P03 MS-FMIT SC-FMIt
P04 SC-FMIT MS-FMIt
P05 MS-FMIT SC-FMIt
P06 SC-FMIT MS-FMIt
P07 MS-FMIT SC-FMIt
P08 SC-FMIT MS-FMIt
P09 MS-FMIT SC-FMIt
P10 SC-FMIT MS-FMIt
Legenda
MS-FMIT : Manual- sem auxílio protótipo.
SC-FMIT: Semiautomático- com auxílio protótipo.

Elaborada pelo autor.

Tabela 6.4: Distribuição das questões por participante.

Ao elaborar o experimento para integração de modelos de features, houve a preocupação em alinhar o nível de conhecimento dos participantes sobre as técnicas de modelagem de features, visto que os participantes não tinham nenhum conhecimento sobre a aplicação desta. A condução do processo para realização do experimento ocorreu em três fases, conforme é exibido na Figura 6.1. As atividades são descritas como segue:

Treinamento. Todos os participantes receberam treinamento para assegurar que adquiriram familiaridade necessária com as técnicas de integração de modelos. Nesta etapa é demostrada uma apresentação contendo os passos para realizar a integração de forma manual sem o apoio do protótipo, FMIT, com auxilio de uma documentação, explicitando os casos desejados, em conjunto com um pequeno tutorial ilustrando os modelos de features, suas notações e configurações de relacionamento. Por fim é demostrado o uso do protótipo, FMIT, com um exemplo de uma integração de modelos features.

A próxima etapa consiste na aplicação do experimento entre os participantes, na perspectiva de analistas e desenvolvedores com a finalidade de colocar em prática a técnica proposta no Capítulo 5, facilitando na resolução dos conflitos assim como na redução dos esforços aplicados nos casos propostos, bem como na condução em realizar a integração pretendida. Os participantes realizam individualmente todas as atividades para evitar qualquer ameaça ao processo experimental.

Detectar Conflitos. A segunda fase constitui em analisar os modelos de entrada MF e MF de cada cenário com base nas descrições de mudanças (Tabela 6.3) licitadas em cada questão os quais definem como os elementos do modelo MF foram alterados. Os participantes detectam os conflitos. A mediada do esforço de detecção (tempo em minutos) foi coletada durante esta atividade, assim como uma lista dos conflitos identificados, sendo estes registros gravados em vídeo e áudio. Os registros serão utilizados para realizar as análises qualitativas.

Resolver Conflitos. Os participantes devem resolver os conflitos conforme as solicitações elencadas em cada questão para produzir o modelo pretendido, MF. O esforço da resolução também é medido (tempo em minutos) bem como o vídeo e áudios são gravados.

Integrar Modelos. Esta atividade constitui em realizar a integração dos modelos MF e MF de cada cenário com base na identificação e resolução dos conflitos. Os modelos são compostos produzindo assim o modelo integrado, MF. A medida do esforço de aplicação (tempo em minutos) é coletada durante esta atividade, armazenados em áudio e vídeo. Nesta fase também é realizada uma análise entre o modelo produzido, isto é, o modelo integrado MF, e modelo pretendido, MF, verificando assim se o mesmo encontra-se correto ou não.

Questionário. Os participantes preenchem um questionário, o que permite coletar informações sobre a experiência profissional, formação acadêmica, experiência em modelagem e desenvolvimento, sexo, idade, etc..

Material. Os modelos utilizados neste experimento foram diagramas de features com cerca de 10 features, 7 relacionamentos, 3 níveis de profundidade, e 3 conflitos em média por modelo de features apresentado. A aplicação de pequenos modelos ocorre por conta da limitação de tempo do experimento controlado, bem como mantém sob controle as variáveis em análise.

Adaptado de Farias (2015).
Figura 6.1: Processo experimental.

Para realizar este experimento, foram convidados 10 participantes todos com formação superior completa, dos cursos de Ciência da Computação, Sistemas de Informação, Licenciatura em Informática, Análise de Sistemas e Jogos Digitais. Todos os participantes estão cursando pós-graduação em nível de mestrado, conforme detalhado na Tabela 6.5.

Curso Número Participantes Mestrando
Ciência da Computação 3 3
Sistemas de Informação 2 2
Licenciatura em Informática 1 1
Análise de Sistemas 2 2
Jogos Digitais 2 2

Elaborada pelo autor.

Tabela 6.5: Grau de escolaridade dos participantes.

Desses 10 voluntários, 3 atuam como estudante/pesquisador em nível de mestrado, 5 atuam como desenvolvedor de sistemas, 01 atua como analista de negócio e por último, 1 atua como analista de qualidade, conforme descrito na Tabela 6.6. A Tabela 6.7 ilustra a faixa etária dos participantes, que compreende 3 entre 20 e 25 anos, 6 entre 26 a 30 anos e 1 com 31 anos de idade.

Cargo Número Participantes
Desenvolvedor de sistemas 5
Analista de negócios 1
Analista de qualidade 1
Estudante/pesquisador 3

Elaborada pelo autor.

Tabela 6.6: Ocupação dos participantes.
Idade Número Participantes
Entre 20 e 25 anos 3
Entre 26 e 30 anos 6
31 anos 1

Elaborada pelo autor.

Tabela 6.7: Faixa etária dos participantes.

Sobre a experiência em desenvolvimento de software, 2 participantes possuem mais de 8 anos, 3 participantes possuem entre 7 e 8 anos, 2 participantes possuem entre 5 e 6 anos, 2 participantes possuem entre 3 a 4 anos e por fim 1 participante tem menos de 2 anos de experiência, conforme ilustrado na Figura 31.

Em relação à experiência de modelagem de software, 1 participante tem mais de 8 anos, 4 participantes possuem entre 7 e 8 anos, 1 participante tem entre 5 e 6 anos, 2 participantes possuem entre 3 a 4 anos e por fim 2 participantes possuem menos de 2 anos de experiência, conforme ilustrado na Figura 6.2.

Elaborada pelo autor.
Figura 6.2: Experiência em desenvolvimento de software.
Elaborada pelo autor.
Figura 6.3: Experiência em modelagem de software.

Ao analisar o perfil dos participantes deste experimento, identificou-se que todos os selecionados possuem relação direta com a área de tecnologia, mais especificamente em desenvolvimento, análise e modelagem de software, tanto em sua formação acadêmica como em suas áreas de atuação profissional. Além disso, verificou-se que a maioria dos participantes possui entre 26 e 30 anos de idade, tem amplo conhecimento em desenvolvimento de software, ou seja, 50% dos participantes possui mais de 5 anos de experiência, outro fator decisivo para este experimento se deve a que 80% dos participantes tem mais de 3 anos de experiência em modelagem, porém nenhum destes tinha conhecimento sobre modelagem de featuares, caracterizando, assim, que a amostra selecionada possui um perfil adequado para a execução do experimento.

6.5 Análise, Resultados e Discussão dos Dados Obtidos

Após a submissão dos resultados inerentes ao questionário através dos participantes, iniciou a verificação dos dados, buscando investigar os impactos relativos ao esforço necessário para interpretar os modelos de features e realizar sua integração, bem como quantificar a corretude das respostas. Os métodos estatísticos balizaram esta pesquisa, onde buscou-se examinar todas as ocorrências dentro de uma população, isto é, a amostra a ser investigada para evidenciar o seu comportamento na aplicação da técnica de modelagem de features. Os resultados coletados foram submetidos à ferramenta RStudio 111https://www.rstudio.com/, tornando assim mais simples a visualização das variações dos resultados e sua parametrização.

Conforme descrito na Seção 6.4, este experimento consta de 12 modelos de features (MF e MF) e em seguida os modelos são compostos, produzindo 6 modelos de features, MF. Esses modelos foram analisados e corrigidos pelos participantes, assim produzindo o modelo pretendido, bem como se propõe ao mensurar o esforço aplicado na produção dos modelos. A Tabela 6.8 exibe os resultados manuais, isto é, sem o uso do protótipo individualizado por participantes para cada cenário avaliado, onde é possível visualizar o tempo que cada participante utilizou na construção dos modelos, assim como verificar se o modelo produzido é o correto ou o incorreto.

Manual – sem uso do protótipo

Participante

Cenário 1 Cenário 2 Cenário 3 Cenário 4 Cenário 5 Cenário 6

Esforço (min.)

Corretude

Esforço (min.)

Corretude

Esforço (min.)

Corretude

Esforço (min.)

Corretude

Esforço (min.)

Corretude

Esforço (min.)

Corretude

P01 5 1 6 1 - - 8 0 - - - -
P02 - - - - 5 0 - - 4 1 7 0
P03 5 1 7 0 - - 8 0 - - - -
P04 - - - - 5 1 - - 4 1 8 0
P05 6 1 7 0 - - 9 1 - - - -
P06 - - - - 6 0 - - 5 1 12 1
P07 5 1 5 0 - - 12 0 - - - -
P08 - - - - 5 0 - - 5 1 8 0
P09 5 1 5 1 - - 7 1 - - - -
P10 - - - - 5 0 - - 6 1 6 0

Elaborada pelo autor.

Tabela 6.8: Resultados individuais por participante- manual.

A Tabela 6.9 exibe os resultados semiautomáticos, ou seja, com o uso do protótipo individualizado por participantes para cada cenário avaliado, onde é possível visualizar o tempo que cada participante utilizou na construção dos modelos, assim como verificar se o modelo produzido é o correto ou incorreto.

Semiautoático – sem uso do protótipo

Participante

Cenário 1 Cenário 2 Cenário 3 Cenário 4 Cenário 5 Cenário 6

Esforço (min.)

Corretude

Esforço (min.)

Corretude

Esforço (min.)

Corretude

Esforço (min.)

Corretude

Esforço (min.)

Corretude

Esforço (min.)

Corretude

P01 - - - - 2 1 - - 0 1 2 1
P02 0 1 1 1 - - 2 1 - - - -
P03 - - - - 3 1 - - 0 1 2 1
P04 0 1 3 1 - - 4 1 - - - -
P05 - - - - 2 1 - - 0 1 4 1
P06 0 1 2 1 - - 3 1 - - - -
P07 - - - - 4 1 - - 0 1 5 0
P08 0 1 3 1 - - 4 0 - - - -
P09 - - - - 3 1 - - 0 1 5 1
P10 0 1 1 1 - - 2 1 - - - -

Elaborada pelo autor.

Tabela 6.9: Resultados individuais por participante- semiautomático.

Os dados para análise qualitativa foram coletadas das seguintes fontes: registros do questionário, áudio, vídeo, transcrições e comentários, possibilitando obter evidências para complementar os resultados quantitativos e posteriormente fundamentar as conclusões a partir destas informações. Para a análise quantitativa foi utilizada a estatística descritiva para analisar sua distribuição e para os testes de hipótese, aplicou-se a inferência estatística. O total de amostra deste experimento é igual a 60, ou seja, 30 amostras manuais, sem interferência do protótipo e 30 amostras semiautomáticas, com suporte do protótipo, FMIT. Para analisar a normalidade das amostras, optou-se em executar dois testes: Kolmogorov-Smirnov, utilizado para grandes amostras (n 30) e Shapiro-Wilk que apresenta um melhor desempenho em amostras reduzidas (n 30) (LEVINE et. al., 2005).

A Tabela 6.10 apresenta o resultado do nível descritivo - a estatística de Kolmogorov-Smirnov, com um nível de significância de Lilliefors para teste de normalidade, e Shapiro-Wilk, os resultados retornados da significância, também conhecida como valor p < 0,05 para ambos os testes nas amostras analisadas. Assim, pode-se afirmar que nível de significância de 5% não provém de uma população normal, tanto pelos indicadores de esforço como os de corretude.

A Tabela 6.11, assim como a Tabela 6.12

, apresenta um os resultados agrupado por cenário de avaliação, com base nos itens avaliados: média, mediana, desvio padrão, máximo, mínimo primeiro quartil, e terceiro quartil, separadas pelo esforço e corretude. Nos cenários Q4 e Q6 verifica-se que foi necessário aplicar o maior esforço tanto manual como semiautomático, esta questão neste experimento apresenta o maior grau de dificuldade, pois em sua elaboração foram inseridos conflitos semânticos e sintáticos ou ambos. Quanto a variável corretude, no cenário Q1 e Q5, verificou-se que todos os participantes acertaram, tanto na forma manualmente como na semiautomática, cabendo uma análise mais profunda nesta questão mo que refere-se ao esforço aplicado, que manualmente é de 5 minutos e 2 segundos para Q1 e 4 minutos e 8 segundos para Q5. Já com o uso do protótipo, FMIT, o tempo consumido é zero e isto ocorre em virtude da técnica detectar que no primeiro cenário não há qualquer alteração entre os modelos de

features comparados , ou seja, são idênticos bem como no quinto cenário ocorre somente a inclusão de novas features e, nestes casos, a integração ocorre de forma automática sem há intervenção dos participantes.

Esforço Kolmogorov-Smirnov a Shapiro-Wilk
Estatística df Sig. Estatística df Sig.
Semiautomático 0,206 30 0,002 0,881 30 0,003
Manual 0,219 30 0,001 0,814 30 0,000
Corretude Estatística df Sig. Estatística df Sig.
Semiautomático 0,354 30 0,000 0,637 30 0,000
Manual 0,537 30 0,000 0,275 30 0,000
Legenda a. Correlação de Significância de Lillieforrs

Elaborada pelo autor.

Tabela 6.10: Teste de normalidade.

Cenário 1

Cenário 2

Cenário 3

Cenário 4

Cenário 5

Cenário 6

Participantes 10 10 10 10 10 10

Esforço (temp\min.)

Manual

Média 5,2 6 5,2 8,8 4,8 8,8
Mediana 5 6 5 8 5 8
Desvio Padrão 0,4 0,9 0,4 1,7 0,7 2
Mínimo 5 5 5 7 4 6
Máximo 6 7 6 12 6 12
1º Quartil 5 5 5 8 4 7
3º Quartil 5 7 5 9 5 8

Esforço (temp\min.)

Semiautomático

Média 0 2 2,8 3 0 3,6
Mediana 0 2 3 3 0 4
Desvio Padrão 0 0,9 0,7 0,9 0 1,4
Mínimo 0 1 2 2 0 2
Máximo 0 3 4 4 0 5
1º Quartil 0 1 2 2 0 2
3º Quartil 0 3 3 4 0 5

Elaborada pelo autor.

Tabela 6.11: Resultados agrupados por cenário - Esforço.

Cenário 1

Cenário 2

Cenário 3

Cenário 4

Cenário 5

Cenário 6

Participantes 10 10 10 10 10 10

Corretude

Manual

Média 1 0,4 0,2 0,4 1 0,2
Mediana 1 0 0 0 1 0
Desvio Padrão 0 0,5 0,4 0,5 0 0,4
Mínimo 1 0 0 0 1 0
Máximo 1 1 1 1 1 1
1º Quartil 1 0 0 0 1 0
3º Quartil 1 1 0 1 1 0

Corretude

Semiautomático

Média 1 1 1 0,8 1 0,8
Mediana 1 1 1 1 1 1
Desvio Padrão 0 0 0 0,4 0 0,4
Mínimo 1 1 1 0 1 0
Máximo 1 1 1 1 1 1
1º Quartil 1 1 1 1 1 1
3º Quartil 1 1 1 1 1 1

Elaborada pelo autor.

Tabela 6.12: Resultados agrupados por cenário – Corretude.

Além disso, a Tabela 6.13 abstrai as informações por cenário aplicado, esforço de integração e integração correta, demostrando a media dos resultados individual das variáveis e o percentual de diferença entre cada tratamento.

Questões Variáveis Tratamento Média % Dif
Todos Corretude Manual 0,53 43,01
Semiautomático 0,93
Esforço Manual 6,36 70,13
Semiautomático 1,90
C1 Corretude Manual 1,0 0,00
Semiautomático 1,0
Esforço Manual 5,2 100
Semiautomático 0,0
C2 Corretude Manual 0,40 60,00
Semiautomático 1,00
Esforço Manual 6,00 66,66
Semiautomático 2,00
C3 Corretude Manual 0,20 80,00
Semiautomático 1,00
Esforço Manual 5,20 46,15
Semiautomático 2,80
C4 Corretude Manual 0,40 50,00
Semiautomático 0,80
Esforço Manual 8,80 65,9
Semiautomático 3,00
C5 Corretude Manual 1,00 0,00
Semiautomático 1,00
Esforço Manual 4,80 100
Semiautomático 0,00
C6 Corretude Manual 0,20 75,00
Semiautomático 0,80
Esforço Manual 8,82 59,18
Semiautomático 3,60

Elaborada pelo autor.

Tabela 6.13: Relação das variáveis de quantificação.

Igualmente, foi possível averiguar a compreensão dos modelos de features entre participantes, devido a estes não conhecerem a técnica de modelagem de features proposta, evidenciado ser um facilitador para análise e implementação no desenvolvimento de software, no contexto de formalizar um entendimento único entre todos.

Realizando uma análise geral, em relação ao esforço, bem como a corretude, aplicada entre os participantes em compor os modelos de features, apesar do fácil entendimento destes, dos quais são exemplos considerados como simples, a aplicação da técnica manual exige um esforço considerável, sendo que o tempo médio para solucionar todos os seis cenários proposto ficou em aproximadamente trinta e seis minutos, tendo uma assertividade de cinquenta três por cento.

Entretanto, a aplicação com os mesmos cenários utilizando o protótipo, FMIT, demostrou-se mais eficiente e eficaz. O esforço médio aplicado na condução de todo o experimento foi de aproximadamente doze minutos, tendo uma assertividade de noventa três por cento.

A Figura 6.4 exibe o comparativo em minutos de cada cenário deste experimento. Na figura é possível visualizar o tempo utilizado pelos participantes, com o auxilio do protótipo inferior ao tempo quando executado manualmente. Ressalta-se que apesar de comparar a aplicação de técnica manual versus a técnica semiautomática, a mesma requer a intervenção dos participantes, exceto quando é detectado pela técnica proposta que ambos os modelos são totalmente equivalentes ou quando não há qualquer similaridade entre os modelos comparados, assim aplicando a inclusão de forma automática. Desse modo, pode afirmar que os participantes empenharam menos esforço para realizar a técnica semiautomática em relação à técnica manual.

Elaborada pelo autor.

Elaborada pelo autor.

Figura 6.4: Tempo de execução por cenário.

A Figura 6.5 exibe o comparativo da corretude aplicada de forma manual em relação à corretude aplicada de forma semiautomática, sendo produzido um total de 60 modelos de features pelos participantes, dos quais 30 modelos de features foram produzidos de forma manual e 30 modelos de forma semiautomática. É possível visualizar que manualmente produziu-se 16 modelos de features corretamente, conforme os requisitos estabelecidos nos cenários, contra 28 Modelos de Features produzidos com o auxílio do protótipo, FMIT. Já dos modelos produzidos incorretamente, 14 modelos de features são manuais contra 2 modelos produzidos de forma semiautomática. Assim é possível concluir que a técnica proposta auxilia os analistas e desenvolvedores na detecção de conflitos, bem como melhora a precisão dos modelos integrados.

Elaborada pelo autor.

Elaborada pelo autor.

Figura 6.5: Corretude por experimento.

Aplicando os dados coletados com a ferramenta RStudio obteve-se os cálculos de cada variável, sendo estas subdivididas conforme o tratamento, em categorias, tendo em vista diferentes resultados incorporados a Tabela 6.14. Nesta tabela incluem-se os resultados para variáveis de quantificação, Integração Correta (IC), que apresenta a corretude para a integração entre modelos de features, ou seja, quanto maior o índice, melhor sua capacidade de retornar a resposta correta. Igualmente a variável Esforço de Integração (EI), apresenta o tempo médio que os participantes levaram para responder os cenários de composição dos modelos de features propostos. O principal fato em aplicar os cálculos pela estatística descritiva com o uso da ferramenta RStudio advém deste retornar dos resultados de testes estáticos e testes de hipóteses: desvio padrão, mínimo e máximo, média, mediana, e por fim a aplicação dos testes de Wilcoxon e o McNemar.

Os testes de normalidades de Kolmogorov-Smirnov – (Lilliefors) e Shapiro-Wilk RAZALI; WAH et al. (2011); OLIVEIRA (2012) executados anteriormente indicam que os dados não se encontram normalmente distribuídos, assim se aplica os testes não paramétricos. Logo, o teste de Wilcoxon é aplicado para analisar o esforço, bem como foi utilizado o teste de McNemar para certificar a validade da técnica proposta. Esses testes serão utilizados para analisar os testes das hipóteses abordados na Seção 6.2. Assim, de posse dos dados coletados e distribuídos nas tabelas para potencializar sua visualização, será aplicada a análise de cada questão e suas hipóteses investigadas.

O teste de Wilcoxon é um teste de hipótese estático não paramétrico, aplicado para confrontar a média de duas amostras relacionadas, ou seja, é um teste de diferença emparelhado, pode ser utilizado como alternativa ao t-test. O t-test é considerado um teste de hipótese que utiliza conceitos estatísticos para rejeitar ou não uma hipótese nula, empregado para confrontar médias de amostras diferentes, normalmente o teste-t é aplicado quando segue uma distribuição normal BARROS; MAZUCHELI (2005).

O teste de McNemar é usado para analisar a eficiência de determinada técnica, isto é, tem como objetivo avaliar a eficiência de situações, “o antes e o depois”, em que cada amostra é utilizada e a mensuração se faz ao nível de uma escala nominal ou ordinal. Este teste é aplicado a variáveis dicotômicas, ou seja, à amostras que apenas tomam dois valores, por exemplo, 0 e 1 FARIAS et al. (2015a); OLIVEIRA (2012); FIRMINO et al. (2015).

Variáveis Tratanento DP Mín 25th MD 75th Máx Méd %dif W N
p-v p-v
Esforço Manual 2,00 4,00 5,00 6,00 7,00 12,0 6,36 70,13 <0,001 -
Semiaut. 1,66 0,00 0,00 2,00 3,00 5,00 1,90
Corretude Manual 0,50 0,00 0,00 1,00 1,00 1,00 0,53 43,01 - 0,002
Semiaut. 0,25 0,00 1,00 1,00 1,00 1,00 0,93

Elaborada pelo autor.

Tabela 6.14: Estatística descritiva e testes estatísticos.

RQ1:QP1: Esforço de Integração. A primeira demanda investigada procura saber o impacto do protótipo, FMIT, analisando o esforço dos analista e desenvolvedores na detecção e resolução de conflitos para uma composição correta. Ao verificar os dados contidos na Tabela 6.11 e Tabela 6.13, diagnosticou-se que o esforço aplicado pelos participantes para integrar modelos de features foi inferior na aplicação da técnica manual em relação à técnica semiautomática. A tabela 6.13 exibe o esforço médio por cenário, bem como o registro acumulado em “Todas” na linha de esforço, a média de esforço empregada para a identificação e resolução de conflitos é de 6,36 (minutos) na aplicação da técnica manual e 1,90 (minutos) na aplicação da técnica semiautomática. A redução do esforço aplicado no uso da técnica semiautomática, bem como no protótipo, FMIT, também é observado na Tabela 6.14 onde exibe a diferença de 70,13% no esforço, ou seja, o esforço empregado para atingir o resultado pretendido com o protótipo, FMIT, é 70,13% menor do que o registrado quando usando a técnica manual. Este esforço também pode ser observado comparando as medianas de 6,00 (minutos) para a técnica automática e apenas 2,00 (minutos) para a técnica semiautomática, que se repetem nas médias.

Teste de Wilcoxon
Pares(n) 30
Z -4,7821
p-Valor < 0,001

Elaborada pelo autor.

Tabela 6.15: Resultado do esforço – teste Wilcoxon.

Analisando a H1-0 tem-se para a hipótese nula o teste de wilcoxon, não paramétrico que pode ser visto na Tabela 6.14 e Tabela 6.15. É possível verificar que a estatística coletada da significância é < 0,001, com um intervalo de confiança de 95% em uma amostra de 30 pares.

Para analisar a H1-1 são considerados os dados da Tabela 6.11, Tabela 6.13 e Tabela 6.14. Pode-se concluir que o tempo médio para chegar a uma resposta é menor na aplicação da técnica semiautomática, ficando em 1,90 (minutos), enquanto que na técnica manual o tempo médio para a identificação e resolução de conflitos ficou em 6,36 minutos. O percentual de esforço é exibida na Tabela 6.13, onde se pode verificar que o esforço na aplicação da técnica manual por cenário é superior a técnica semiautomática. Assim, é possível identificar que os participantes ao utilizar o protótipo, FMIT, conseguiram chegar a uma conclusão com maior eficácia. Verifica-se nessa hipótese que o esforço na identificação de conflitos, com a técnica semiautomática é menor 61,03% comparada a técnica manual. Assim pode-se concluir que essa hipótese é válida e os analistas e desenvolvedores aplicam menos esforços com a aplicação da técnica semiautomática.

Colocando em escala os resultados desta análise do esforço empregado por cenário, conforme as Tabelas 6.8 e Tabela 6.9 obtém-se o gráfico da Figura 6.4. A figura evidencia mais nitidamente a diferença de esforço para detecção e análise de conflitos na comparação de modelos de features, entre a aplicação da técnica manual e semiautomática. Observa-se que no caso da técnica manual o esforço decorrido é bem superior, confirmando as discussões anteriores.

Respondendo então a primeira questão de pesquisa o protótipo, FMIT, com base na técnica semiautomática, influencia nos esforços investidos pelos analistas e desenvolvedores na identificação e resolução de conflitos durante o processo de integração, reduzindo o esforço empregado.

RQ2:QP2: Respostas Corretas. A segunda demanda investigada procura saber o impacto na aplicação técnica semiautomática, se os modelos de features produzidos foram corretamente integrados, determinando assim a eficácia e efetividade na qualidade do processo de integração, uma vez que os conflitos existentes prejudicam a compreensibilidade dos modelos aumentando o risco de atrasos em projetos de software devido a retrabalho, bem como poderá elevar os custos de produção. Visualizando os dados na da Tabela 6.14 pode-se observar que as médias da corretude ficou superior com o uso do protótipo, FMIT, comparado à técnica manual, isto é, uma média de 0,53 (técnica manual), em comparação com a média de 0,93 (técnica semiautomática), entretanto as medianas são equivalente, isto é, são iguais a 1. Este fato ocorre devido à condução do experimento, onde o valor igual a 1 considera o modelo correto e valor igual a 0 considera o modelo incorreto. Na Tabela 6.13 é possível ver os percentuais dos modelos features corretamente integrados com a técnica semiautomática é superior se comparado com a técnica manual, ou seja, os participantes do experimento melhoram a assertividade dos modelos em 43%.

Teste de Wilcoxon
Pares(n) 30
10,08
p-Valor 0,002

Elaborada pelo autor.

Tabela 6.16: Resultado do esforço – teste McNemar.

Analisando a H2-0, tem-se para investigar a hipótese nula, o teste de McNemar não paramétrico que pode ser observado na Tabela 6.14 e Tabela 6.16. É possível verificar que a estatística coletada da significância é 0,002, com um intervalo de confiança de 95% em uma amostra de 30 pares. Este valor indica que a segunda hipótese nula (H2-0) pode ser rejeitada. Como o valor-p é menor que 0,05, pode-se concluir que há evidências de que a técnica semiautomática é significativamente mais eficaz do que a técnica manual.

Analisando a H2-1 são considerados os dados da Tabela 6.11, Tabela 6.12 e Tabela 6.14. Pode-se concluir que a técnica semiautomática, a corretude em média é 0,93 (acertos), superior a técnica manual em média é 0,53 (acertos). Os percentuais de corretude são exibidos na Tabela 6.13, onde pode-se confirmar o melhor desempenho da aplicação semiautomática em relação a técnica manual. Igualmente é confirmado um aproveitamento de 43,01% realizando as integrações de maneira semiautomática, com base na técnica e no protótipo proposto, aumentando a corretude dos modelos de features. Portanto, vê-se que a grande maioria dos participantes concluiu a integração dos modelos corretamente. A busca pela eficácia juntamente com a efetividade de compor os modelos é facilitada com o uso do protótipo, FMIT, ou seja a técnica semiautomática conduz melhor o nível de assertividade de integração comparada a técnica manual. Assim pode-se concluir que essa hipótese é válida e os analistas e desenvolvedores obtiveram maior êxito na assertividade dos modelos compostos, aplicando uso da técnica semiautomática.

Colocando em escala os resultados desta análise de corretude, conforme as Tabelas 6.8 e a Tabela 6.9 obtém-se o gráfico da Figura 6.5. A figura evidencia mais nitidamente a diferença na obtenção dos modelos de features pretendido, isto é, o modelo produzido corretamente entre a aplicação da técnica semiautomática e manual, confirmando os resultados acima.

Então respondendo a segunda questão de pesquisa pode-se concluir que o protótipo proposto, FMIT, com base na técnica semiautomática, afeta a eficácia e efetividade dos modelos produzidos entre os analistas e desenvolvedores de forma a aperfeiçoar a integração de modelos, positivamente aumentando o número de modelos corretamente produzidos.

Discussão. Nessa avaliação procura-se em cada questão explorar diferentes situações para integrar modelos de features, com o intuito de verificar as necessidades de aperfeiçoar a técnica para integração entre dois modelos de entrada, assim como calcular o esforço empregado para solucionar conflitos e validar a corretude das integrações.

Com base nos testes estatísticos executados durante este experimento, foi possível avaliar as hipóteses testadas nesta Seção, que se referem ao esforço e a corretude das integrações, relacionados às questões de pesquisa descritas na Seção 1.2. Os resultados evidenciam claramente a rejeição das duas hipóteses nulas formuladas. Assim como, foram demostrados indícios para justificar a validade das hipóteses alternativas, os resultados contribuíram para o atendimento dos objetivos específicos, citados na Seção 1.3 deste estudo.

No entanto, fazendo uma visão geral é possível concluir que de acordo com os resultados de todos os cenários o protótipo proposto, FMIT, baseado na técnica semiautomática aumentou o índice de respostas corretas em 43,01% e reduziu o esforço empregado em 70,13%. Os resultados apontam para o beneficio na execução das integrações automatizadas, porém cabe aprofundar os estudos, visto ser necessário investigar a aplicação da técnica proposta com outras ferramentas de automatização, assim como aplicar os testes no setor industrial em grandes escalas de produção, para de fato tomar conhecimento de sua aplicabilidade.

Todos os participantes desta pesquisa submeteram-se anteriormente a participar de um pequeno workshop que durou aproximadamente 20 minutos, onde se realizou uma explanação sobre os modelos de features, como se comporta, quais relacionamentos existentes e por fim exemplos de integração. Assim buscou-se balizar o conhecimento entre todos os indivíduos, sendo estes em sua maioria de sexo masculino 90%, 10% tem experiência de menos de dois anos como desenvolvedor e analista, e 70% por cento atuam com profissionais e estudantes em tempo integral. O experimento contou com a participação de 10 indivíduos, todos os estudantes do curso de pós-graduação em Computação Aplicada da universidade Unisinos. Para desempenhar uma análise mais criteriosa será de suma importância expandir o número de participantes na condução deste experimento.

Quanto à validade da conclusão estatística, pode-se afirmar que diretrizes experimentais foram seguidas para eliminar ameaças pressupostas aos testes estatísticos (teste de Wilcoxon e o teste de McNemar). A homogeneidade dos indivíduos foi assegurada. O método de quantificação empregado neste experimento se fez com o uso de ferramentas estatísticas. Os testes de Shapiro-Wilk e Kolmogorov-Smirnov foram aplicados e os mesmos não aderem a uma distribuição normal, assim utilizaram-se testes não paramétricos.

Finalizando pode-se concluir que a técnica e o protótipo proposto, FMIT, nesta pesquisa demostraram que, com a execução da avaliação e seus resultados melhoraram significativamente a eficácia no esforço empregado durante o processo de integração na mitigação de conflitos, assim como aumentaram a eficiência e efetividade na corretude dos modelos produzidos, respondendo de forma satisfatória às questões de pesquisa elaboradas neste estudo.

6.6 Ameaças à Validade do Estudo

Esta seção discute algumas possíveis limitações e ameaças a validade do estudo. A aplicação de experimento demanda da necessidade de analisar o quão valido são os métodos e os participantes selecionados, a forma como foram aplicados e avaliados, e os resultados deparados. Conforme wohlin2012, essa constatação ocorre através da avaliação de quatro tipos de validade: validade da conclusão, validade da construção e por fim a validade as ameaças internas e externas.

Validade de conclusão. A validade considera a capacidade de obter a conclusão correta apoiada nos resultados oriundos do experimento, através das escolhas dos métodos estatísticos pressupondo o tamanho da amostra e a confiabilidade das medidas WOHLIN et al. (2012). Nesse critério o experimento produziu uma amostra de 60 modelos de features, cuja análise estatística descritiva identificou que os dados não aderem a uma distribuição normal, assim aplicando os testes não paramétricos, ou seja, o teste de Wilcoxon, para mensurar o esforço empregado na detecção de conflitos e o teste de McNemar, para mensurar a corretude dos modelos produzidos, com um intervalo de confiança de 95% conforme detalhado na Seção 6.5.

Validade da construção. Leva em consideração a relação entre a teoria e a observação, ou seja, os resultados obtidos através de questionários ou experimentos e possuem relação com as expectativas da teoria estudada OLIVEIRA (2012); FARIAS et al. (2015a); WOHLIN et al. (2012); KITCHENHAM et al. (2010). Assim, os experimentos realizado nesta pesquisa foram planejados para mensurar o esforço de integração, bem como quantificar a corretude dos modelos produzidos pelos participantes, sendo está estratégia já adotada na literatura como, por exemplo, o trabalho de farias2015, kleinner2012. A fim de atender os procedimentos de execução e correção do experimento, foram cuidadosamente planejados, seguindo as boas práticas de quantificação conforme wohlin2012, kitchenham2010, kitchenham2011.

Validade externa. Leva em consideração as condições que permitem generalizar os resultados do experimento para a prática industrial ou para o mais realista possível WOHLIN et al. (2012); FARIAS et al. (2013). Nesse contexto, selecionaram-se os participantes que possuem formação adequada para a prática da atividade relacionada ao experimento, isto é, todos os participantes são mestrandos em Computação Aplicada, além de possuir boa experiência na área de desenvolvimento ou modelagem de software, conforme detalhado na Seção 6.4. Além disso, as ferramentas e equipamentos utilizados no experimento são equivalentes ao praticado na indústria, sendo que a aplicação de todo o experimento ocorreu nas dependências da universidade.

Por fim, apesar dos cuidados tomados em relação às ameaças de validade ao estudo, citados nesta Seção, não se pode afirmar que os resultados encontrados podem ser generalizados para modelos maiores, uma vez que os selecionados para este experimento são considerados pequenos, conforme detalhado na Tabela 6.3.

7.1 Mapeamento dos Trabahos Relacionados

Neste trabalho conduziu-se um estudo de mapeamento sistemático da literatura, sobre a integração de modelos de features,onde a pesquisa inicial retornou 775 publicações e 34 publicações foram selecionadas como estudos primários após um cuidadoso processo de filtragem, nos quais se investigaram seis questões de pesquisa. Resumidamente este estudo consiste em apresentar um conjunto de características para definição das técnicas de integração entre modelos de features aplicadas ao protótipo. Os estudos primários indicaram as oportunidades de pesquisa, assim como demonstraram como estas características se manifestam ao longo dos trabalhos investigados.

Técnicas Investigada Protótipo - FMIT
1 – Técnica de Automatização Automático Sim Sim
Semiautomático Sim Sim
2 - Técnicas de Comparação Sintática Sim Sim
Semântica Sim Sim
Estrutural Não Sim
Equivalência Não Sim
3 - Técnicas de Integração União Sim Sim
Intersecção Sim Sim
Diferença Sim Sim
Complemento Não Sim
4 - Notações FODA Sim Sim
FORML Sim Não
Outros Sim Não
5 - Técnicas de Configuração CSP Sim Não
SAT Sim Não
Multicritério Sim Não
6 – Métodos de Pesquisa Proposta de Solução Sim Não
Pesquisa de Avaliação Sim Sim
Pesquisa de Validação Sim Não
Artigos de Opinião Sim Não
Artigos Filosóficos Sim Não
Artigos de Experiência Sim Não

Elaborada pelo autor.

Tabela 7.1: Comparação das técnicas investigadas.

A Tabela 7.1 apresenta as variáveis das 06 questões de pesquisa descritas na Seção 3.1.1, bem como os resultados obtidos na investigação, comparados as técnicas implementadas ao protótipo, FMIT, proposto.

Técnica de Automatização. A primeira questão procura investigar o grau de automatização, a maioria dos trabalhos aplica-se a técnica automática, e o protótipo proposto implementa ambas as técnicas.

Técnicas de Comparação. A segunda questão investiga as técnicas de comparação, boa parte dos trabalhos executa comparações sintáticas e semânticas durante a composição de modelos, sendo que há duas lacunas em aberto nos trabalhos, em kastner2009, thum2014 viabilizam a ordem em que features ou produtos encontram-se, devido as possíveis configurações que possam vir a existir, assim a estrutura da features neste estudo é considerada relevante para aprimorar a qualidade das integrações. Finalmente o grau de equivalência calcula a diferença entre modelos comparados, ou seja, sintático semântico, e estrutural OLIVEIRA et al. (2008). Ao aplicar a técnicas de similaridade, esta viabiliza facilmente verificar nível ou taxa de conflitos ao comparar os modelos, assim tornando possível executar uma ação, sejam ela implementada pelo protótipo ou pelos analistas e desenvolvedores.

Técnicas de Integração. As técnicas de integração aplicadas normalmente são derivadas do grau de equivalência e executadas automaticamente. A técnica de união ocorre quando a necessidade de incluir novos elementos ao modelo e a interseção, quando é necessário excluir elementos incomuns no modelo analisado, estas são as técnicas mais utilizadas na literatura, por fim a técnica de diferença e complemento que é pouco aplicada na literatura ou mesmo não utilizada. No protótipo ambas as técnicas são consideradas e aplicadas na escolha automática, assim dando a possibilidade dos analistas e desenvolvedores verificarem um gama maior de composições, ou até mesmo para analisar as diferenças entre os modelos comparados , no caso da aplicação das técnicas de diferença e complemento.

Notações. A notação FODA KANG et al. (1990) é a mais aplicada na literatura, sendo desta técnica as demais variações existentes, há um vasto número de notações descritas na literatura. O protótipo seguiu o modelo FODA, por ser amplamente conhecido, bem como a sua facilidade de interpretação e a ferramenta incorporada ao protótipo, FeatureIDE, também faz uso desta notação.

Técnicas de Configuração. As técnicas de configurações e validação são amplamente investigadas na literatura, pois o nível de maturação é considerado elevado BENAVIDES; SEGURA; RUIZ-CORTÉS (2010). Há um número significativo de ferramentas que forcem suporte para a criação, edição, análise e configuração dos modelos de features, como por exemplo, SPLOT MENDONCA; BRANCO; COWAN (2009), FeatureIDE THÜM et al. (2014), fmp CZARNECKI; HELSEN; EISENECKER (2005), pure::variants BEUCHE (2012). Assim optou-se em utilizar a ferramenta FeatureIDE é framework baseado em Eclipse a qual abrange várias atividade no processo de desenvolvimentos das LPS.

Métodos de Pesquisa. O trabalho em questão é classificado de acordo com métodos de pesquisa descritos na Seção 3.1.4. Este estudo é classificado como uma pesquisa de avaliação, onde as técnicas e soluções são implementadas e avaliadas na prática, e as consequências investigadas.

7.2 Contribuições

Esta pesquisa propôs a aplicação de uma técnica de integração de modelos de features, que compreende um conjunto de técnicas propostos na literatura, bem como o desenvolvimento de um protótipo, Feature Model Integration Tool – FMIT, assim, procura-se aperfeiçoar as técnicas de integração e flexibilizar o processo de composição. Com o auxílio do protótipo, os analistas e desenvolvedores realizaram as tarefas com maior eficiência, impactando diretamente em sua capacidade produtiva, isto é, otimizando melhor o tempo de produção, assim como possibilitou um aumento na precisão dos modelos produzidos, oriundos da diminuição de conflitos. Com estes resultados acredita-se em uma redução nos custos de produção e uma importante melhoria decorrida do processo de integração que determinam a qualidade final do produto gerado, estabelecendo assim a primeira contribuição científica deste estudo.

A produção de conhecimento empírico sobre integração de modelos de features, apresentada pelos estudos experimentais de integração realizados manualmente ou de forma semiautomática, proporcionaram medir os esforços gerados e o taxa de modelos de features corretamente produzidos, é a segunda contribuição científica deste estudo.

Por último, através de um mapeamento sistemático da literatura, construiu-se uma base de conhecimento referente às técnicas de integração de modelos de features aplicadas na literatura, abrangendo 34 estudos primários. Este estudo reúne em um único trabalho uma descrição dos principais avanços e desafios para futuras pesquisas relacionadas neste campo de atuação.

7.3 Limitações do Trabalho

Este estudo investigou no seu decorrer questões essencialmente sobre integração de modelos de features. Embora as contribuições deste estudo sejam percebíveis, sua abordagem necessita de melhorias, uma vez que o tempo de desenvolvimento deste estudo não é o suficiente para cobrir todas as lacunas existentes. Assim, são apresentadas as principais limitações identificadas neste estudo, bem como sugestões de trabalhos futuros em virtude de cobrir estes pontos.

Limitações Experimentais. Há necessidade de expandir o número de participantes bem como ampliar a participação de profissionais ligados ao setor industrial nas pesquisas. Os modelos features utilizados nos cenários apresentados possuem uma quantidade reduzida de elementos, ou seja, são pequenos modelos que em sua maioria não condiz com a atualidade no âmbito industrial. Portando, como trabalho futuro verifica-se a necessidade implantar modelos mais ricos, que apresentem o número maior de elementos, com isso, possibilitando realizar testes de escalabilidade e desempenho de integração.

Limitações do Protótipo. Apesar, do protótipo realizar a integração de forma ampla, o mesmo encontra-se limitado a uma única notação, ou seja, a FODA KANG et al. (1990), sendo que neste estudo identificou-se um grande número de notações. Destacam-se entre as mais conhecidas 14 notações derivadas, conforme ilustrado na Figura 3.3, no Capítulo 3 deste estudo. Assim, sugere-se como trabalho futuro ampliar o suporte a um número maior de notações, por exemplo, FORM, CBFM, e PLUSS. Após, a composição dos modelos, o protótipo retorna como saída um arquivo textual com informações sobre as equivalências entre os modelos comparados, percentual de diferença sintática, semântica e estrutural individualizado, bem como similaridade geral dos modelos. Por fim, o modelo pretendido é apresentado no formato textual, ou seja, um vetor. É condizente melhorar a forma de armazenagem para a coleta de buscas futuras, assim como exibir graficamente o modelo produzido.

Limitações da Técnica. Apesar, da técnica semiautomática para a integração de modelo de features apresentar-se eficaz em relação a técnica manual, encontra-se a necessidade de ampliar e aprofundar a fase dos estudos, isso ocorre devido ao fato das decisões sofrerem interferência humana e estarem sujeitas ao erro, conforme demostrado no experimento, ou seja, aproximadamente 7% dos modelos foram produzidos incorretamente. Assim, como trabalho futuro observa-se a necessidade de novos experimentos face à execução da técnica automática, tendo ênfase em analisar sua precisão e acurácia em relação a técnica proposta, e por fim acoplar outras técnicas ao protótipo, como por exemplo o uso da inteligência artificial, visto o desafio de tomar melhores e mais precisas as decisões dos modelos de features integrados.

Apêndice A Lista de estudos primários

Os 34 artigos selecionados como estudos primários na revisão do mapeamento sistemático estão listados abaixo.

S01.

Moisan, S., Rigault, J.-P., and Acher, M. (2012) A feature-based approach to system deployment and adaptation. Proceedings of the 4th International Workshop on Modeling in Software Engineering, pp. 84-90.

S02.

Andersen, N., Czarnecki, K., She, S., and Wasowski, A. (2012) Efficient synthesis of feature models. Proceedings of the 16th International Software Product Line Conference-Volume 1, pp. 106-115.

S03.

Acher, M., Collet, P., Lahire, P., and France, R. (2009) Composing feature models. International Conference on Software Language Engineering, pp. 62-81.

S04.

Urli, S., Blay-Fornarino, M., Collet, P., and Mosser, S.(2012) Using composite feature models to support agile software product line evolution. Proceedings of the 6th International Workshop on Models and Evolution, pp. 21-26.

S05.

Sayyad, A. S., Menzies, T., and Ammar, H. (2013) On the value of user preferences in search-based software engineering: a case study in software product lines. 2013 35th International Conference on Software Engineering (ICSE), pp. 492-501.

S06.

Khalfaoui, K., Kerkouche, E., Chaoui, A., and Foudil, C. (2015) Automatic generation of spl structurally valid products: An approach based on progressive composition of partial configurations. Information and Communication Systems (ICICS), 2015 6th International Conference on, pp. 25-31.

S07.

Beidu, S., Atlee, J. M., and Shaker, P. (2015) Incremental and commutative composition of state-machine models of features. 2015 IEEE/ACM 7th International Workshop on Modeling in Software Engineering, pp. 13-18.

S08.

Schwägerl, F., Uhrig, S., and Westfechtel, B. (2015) A graph-based algorithm for three-way merging of ordered collections in emf models. Science of Computer Programming, 113, pp. 51-81.

S09.

Acher, M., Heymans, P., Collet, P., Quinton, C., Lahire, P., and Merle, P. (2012) Feature model differences. International Conference on Advanced Information Systems Engineering, pp. 629-645.

S10.

Dao, T. M. and Kang, K. C. (2010) Mapping features to reusable components: A problem frames based approach. International Conference on Software Product Lines, pp. 377-392.

S11.

Guo, J. and Wang, Y. (2010) Towards consistent evolution of feature models. International Conference on Software Product Lines, pp. 451-455.

S12.

Westfechtel, B. (2014) Merging of emf models. Software and Systems Modeling, 13, pp. 757-788.

S13.

Scholz, W., Thüm, T., Apel, S., and Lengauer, C. (2011) Automatic detection of feature interactions using the java modeling language: an experience report. Proceedings of the 15th International Software Product Line Conference, Volume 2 p. 7.

S14.

Quinton, C., Romero, D., and Duchien, L. (2013) Cardinality-based feature models with constraints: a pragmatic approach. Proceedings of the 17th International Software Product Line Conference, pp. 162-166.

S15.

Batory, D., Hofner, P., and Kim, J. (2011) Feature interactions, products, and composition. ACM SIGPLAN Notices, pp. 13-22.

S16.

Asadi, M., Bagheri, E., Mohabbati, B., and Gasevic, D. (2012) Requirements engineering in feature oriented software product lines: an initial analytical study. Proceedings of the 16th International Software Product Line Conference-Volume 2, pp. 36-44.

S17.

Sarinho, V. T. and Apolinário, A. L. (2010) Combining feature modeling and object oriented concepts to manage the software variability. Information Reuse and Integration (IRI), 2010 IEEE International Conference on, pp. 344-349.

S18.

Kolesnikov, S., von Rhein, A., Hunsen, C., and Apel, S. (2013) A comparison of product-based, feature-based, and family-based type checking. ACM SIGPLAN Notices, pp. 115-124.

S19.

Soltani, S., Asadi, M., Gasevic, D., Hatala, M., and Bagheri, E. (2012) Automated planning for feature model configuration based on functional and non-functional requirements. Proceedings of the 16th International Software Product Line Conference Volume 1, pp. 56-65.

S20.

Benavides, D., Segura, S., and Ruiz-Cortés, A. (2010) Automated analysis of feature models 20 years later: A literature review. Information Systems, 35, pp. 615-636.

S21.

Thüm, T., Kästner, C., Benduhn, F., Meinicke, J., Saake, G., and Leich, T. (2014) Featureide: An extensible framework for feature-oriented software development. Science of Computer Programming, 79, pp. 70-85.

S22.

Ensan, F., Bagheri, E., and Gasevic, D. (2012) Evolutionary search-based test generation for software product line feature models. International Conference on Advanced Information Systems Engineering, pp. 613-628.

S23.

Budiardjo, E. K., Zamzami, E. M., et al. (2014) Feature modeling and variability modeling syntactic notation comparison and mapping. Journal of Computer and Communications, 2, p. 101.

S24.

Acher, M., Collet, P., Lahire, P., and France, R. B. (2011) Decomposing feature models: language, environment, and applications. Proceedings of the 2011 26th IEEE/ACM International Conference on Automated Software Engineering, pp. 600-603.

S25.

Benavides, D., Felfernig, A., Galindo, J. A., and Reinfrank, F. (2013) Automated analysis in feature modelling and product configuration. International Conference on Software Reuse, pp. 160-175.

S26.

Czarnecki, K., Helsen, S., and Eisenecker, U. (2004) Staged configuration using feature models. International Conference on Software Product Lines, pp. 266-283.

S27.

Bécan, G., Behjati, R., Gotlieb, A., and Acher, M. (2015) Synthesis of attributed feature models from product descriptions. Proceedings of the 19th International Conference on Software Product Line, pp. 1-10.

S28.

Passos, L., Czarnecki, K., Apel, S., Wasowski, A., Kästner, C., and Guo, J. (2013) Feature-oriented software evolution. Proceedings of the Seventh International Workshop on Variability Modelling of Software-intensive Systems p. 17.

S29.

Teixeira, L., Borba, P., and Gheyi, R. (2013) Safe composition of configuration knowledge-based software product lines. Journal of Systems and Software, 86, pp. 1038-1053.

S30.

Eichelberger, H., Kröher, C., and Schmid, K. (2013) An analysis of variability modeling concepts: Expressiveness vs. analyzability. International Conference on Software Reuse, pp. 32-48.

S31.

Kästner, C., Apel, S., and Ostermann, K. (2011) The road to feature modularity? Proceedings of the 15th International Software Product Line Conference, Volume 2, p. 5.

S32.

Classen, A., Boucher, Q., and Heymans, P. (2011) A text-based approach to feature modelling: Syntax and semantics of tvl. Science of Computer Programming, 76, pp. 1130-1143.

S33.

Dehmouch, I. (2014) Towards an agile feature composition for a large scale software product lines. 2014 IEEE Eighth International Conference on Research Challenges in Information Science (RCIS), pp. 1-6.

S34.

Lesta, U., Schaefer, I., and Winkelmann, T. (2015) Detecting and explaining conflicts in attributed feature models. arXiv preprint arXiv:1504.03483, pp. 31-43.

Apêndice B Modelos de Features Experimento

Modelos propostos para integração de modelos de features aplicados na realização do experimento, manual e semiautomático. Questionário aplicado para coleta dos dados dos participantes. See pages 1-4 of questionarioMF.pdf

Referências

  • ACHER et al. (2009) ACHER, M.; COLLET, P.; LAHIRE, P.; FRANCE, R. Composing feature models. In: INTERNATIONAL CONFERENCE ON SOFTWARE LANGUAGE ENGINEERING, 2009. Anais… [S.l.: s.n.], 2009. p. 62–81.
  • ACHER et al. (2010) ACHER, M.; COLLET, P.; LAHIRE, P.; FRANCE, R. Comparing approaches to implement feature model composition. In: EUROPEAN CONFERENCE ON MODELLING FOUNDATIONS AND APPLICATIONS, 2010. Anais… [S.l.: s.n.], 2010. p. 3–19.
  • ANDERSEN et al. (2012) ANDERSEN, N.; CZARNECKI, K.; SHE, S.; WĄSOWSKI, A. Efficient synthesis of feature models. In: INTERNATIONAL SOFTWARE PRODUCT LINE CONFERENCE-VOLUME 1, 16., 2012. Proceedings… [S.l.: s.n.], 2012. p. 106–115.
  • APEL et al. (2014) APEL, S.; ATLEE, J. M.; BARESI, L.; ZAVE, P. Feature interactions: the next generation (dagstuhl seminar 14281). Dagstuhl Reports, [S.l.], v. 4, n. 7, 2014.
  • APEL; KÄSTNER (2009) APEL, S.; KÄSTNER, C. An Overview of Feature-Oriented Software Development. Journal of Object Technology, [S.l.], v. 8, n. 5, p. 49–84, 2009.
  • BARROS; MAZUCHELI (2005) BARROS, E. A. C.; MAZUCHELI, J. Um estudo sobre o tamanho e poder dos testes t-Student e Wilcoxon. Acta Scientiarum. Technology, [S.l.], v. 27, n. 1, p. 23–32, 2005.
  • BATORY (2005) BATORY, D. Feature models, grammars, and propositional formulas. In: INTERNATIONAL CONFERENCE ON SOFTWARE PRODUCT LINES, 2005. Anais… [S.l.: s.n.], 2005. p. 7–20.
  • BÉCAN et al. (2015) BÉCAN, G.; BEHJATI, R.; GOTLIEB, A.; ACHER, M. Synthesis of attributed feature models from product descriptions: foundations. arXiv preprint arXiv:1502.04645, [S.l.], 2015.
  • BENAVIDES et al. (2013) BENAVIDES, D.; FELFERNIG, A.; GALINDO, J. A.; REINFRANK, F. Automated analysis in feature modelling and product configuration. In: INTERNATIONAL CONFERENCE ON SOFTWARE REUSE, 2013. Anais… [S.l.: s.n.], 2013. p. 160–175.
  • BENAVIDES; SEGURA; RUIZ-CORTÉS (2010) BENAVIDES, D.; SEGURA, S.; RUIZ-CORTÉS, A. Automated analysis of feature models 20 years later: a literature review. Information Systems, [S.l.], v. 35, n. 6, p. 615–636, 2010.
  • BENAVIDES; TRINIDAD; RUIZ-CORTÉS (2005)

    BENAVIDES, D.; TRINIDAD, P.; RUIZ-CORTÉS, A. Automated reasoning on feature models. In: INTERNATIONAL CONFERENCE ON ADVANCED INFORMATION SYSTEMS ENGINEERING, 2005.

    Anais… [S.l.: s.n.], 2005. p. 491–503.
  • BERG; BISHOP; MUTHIG (2005) BERG, K.; BISHOP, J.; MUTHIG, D. Tracing software product line variability: from problem to solution space. In: SOUTH AFRICAN INSTITUTE OF COMPUTER SCIENTISTS AND INFORMATION TECHNOLOGISTS ON IT RESEARCH IN DEVELOPING COUNTRIES, 2005., 2005. Proceedings… [S.l.: s.n.], 2005. p. 182–191.
  • BERGER et al. (2015) BERGER, T.; LETTNER, D.; RUBIN, J.; GRÜNBACHER, P.; SILVA, A.; BECKER, M.; CHECHIK, M.; CZARNECKI, K. What is a feature?: a qualitative study of features in industrial software product lines. In: INTERNATIONAL CONFERENCE ON SOFTWARE PRODUCT LINE, 19., 2015. Proceedings… [S.l.: s.n.], 2015. p. 16–25.
  • BERGER et al. (2013) BERGER, T.; RUBLACK, R.; NAIR, D.; ATLEE, J. M.; BECKER, M.; CZARNECKI, K.; WĄSOWSKI, A. A survey of variability modeling in industrial practice. In: SEVENTH INTERNATIONAL WORKSHOP ON VARIABILITY MODELLING OF SOFTWARE-INTENSIVE SYSTEMS, 2013. Proceedings… [S.l.: s.n.], 2013. p. 7.
  • BERGEY; O’BRIEN; SMITH (2000) BERGEY, J.; O’BRIEN, L.; SMITH, D. Mining existing assets for software product lines. [S.l.]: DTIC Document, 2000.
  • BEUCHE (2012) BEUCHE, D. Modeling and building software product lines with pure:: variants. In: INTERNATIONAL SOFTWARE PRODUCT LINE CONFERENCE-VOLUME 2, 16., 2012. Proceedings… [S.l.: s.n.], 2012. p. 255–255.
  • BEUCHE; DALGARNO (2007) BEUCHE, D.; DALGARNO, M. Software product line engineering with feature models. Overload Journal, [S.l.], v. 78, p. 5–8, 2007.
  • BÉZIVIN et al. (2006) BÉZIVIN, J.; BOUZITOUNA, S.; DEL FABRO, M. D.; GERVAIS, M.-P.; JOUAULT, F.; KOLOVOS, D.; KURTEV, I.; PAIGE, R. F. A canonical scheme for model composition. In: EUROPEAN CONFERENCE ON MODEL DRIVEN ARCHITECTURE-FOUNDATIONS AND APPLICATIONS, 2006. Anais… [S.l.: s.n.], 2006. p. 346–360.
  • BISCHOFF et al. (2016) BISCHOFF, V.; FARIAS, K.; GONÇALES, L. J.; WEBER, V. Towards a Tool for Integration of Feature Model. International Journal of Computer Science and Software Engineering, [S.l.], v. 5, n. 12, p. 264–271, 2016.
  • ČAVRAK; ORLIĆ; CRNKOVIĆ (2012) ČAVRAK, I.; ORLIĆ, M.; CRNKOVIĆ, I. Collaboration patterns in distributed software development projects. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING (ICSE), 2012., 2012. Anais… [S.l.: s.n.], 2012. p. 1235–1244.
  • CHEN et al. (2005) CHEN, K.; ZHANG, W.; ZHAO, H.; MEI, H. An approach to constructing feature models based on requirements clustering. In: REQUIREMENTS ENGINEERING, 2005. PROCEEDINGS. 13TH IEEE INTERNATIONAL CONFERENCE ON, 2005. Anais… [S.l.: s.n.], 2005. p. 31–40.
  • CIRILO; KULESZA; LUCENA (2007) CIRILO, E.; KULESZA, U.; LUCENA, C. J. P. de. GenArch-A Model-Based Product Derivation Tool. In: SBCARS, 2007. Anais… [S.l.: s.n.], 2007. p. 31–46.
  • CLASSEN; BOUCHER; HEYMANS (2011) CLASSEN, A.; BOUCHER, Q.; HEYMANS, P. A text-based approach to feature modelling: syntax and semantics of tvl. Science of Computer Programming, [S.l.], v. 76, n. 12, p. 1130–1143, 2011.
  • CLASSEN; HEYMANS; SCHOBBENS (2008) CLASSEN, A.; HEYMANS, P.; SCHOBBENS, P.-Y. What’s in a feature: a requirements engineering perspective. In: INTERNATIONAL CONFERENCE ON FUNDAMENTAL APPROACHES TO SOFTWARE ENGINEERING, 2008. Anais… [S.l.: s.n.], 2008. p. 16–30.
  • CLEMENTS; NORTHROP (2002) CLEMENTS, P.; NORTHROP, L. Software product lines. [S.l.]: Addison-Wesley,, 2002.
  • COHEN; RAVIKUMAR; FIENBERG (2003) COHEN, W.; RAVIKUMAR, P.; FIENBERG, S. A comparison of string metrics for matching names and records. In: KDD WORKSHOP ON DATA CLEANING AND OBJECT CONSOLIDATION, 2003. Anais… [S.l.: s.n.], 2003. v. 3, p. 73–78.
  • CZARNECKI et al. (2002) CZARNECKI, K.; BEDNASCH, T.; UNGER, P.; EISENECKER, U. Generative programming for embedded software: an industrial experience report. In: INTERNATIONAL CONFERENCE ON GENERATIVE PROGRAMMING AND COMPONENT ENGINEERING, 2002. Anais… [S.l.: s.n.], 2002. p. 156–172.
  • CZARNECKI; EISENECKER (2000) CZARNECKI, K.; EISENECKER, U. W. Intentional programming. Generative Programming. Methods, Tools, and Applications, [S.l.], 2000.
  • CZARNECKI; HELSEN; EISENECKER (2004) CZARNECKI, K.; HELSEN, S.; EISENECKER, U. Staged configuration using feature models. In: INTERNATIONAL CONFERENCE ON SOFTWARE PRODUCT LINES, 2004. Anais… [S.l.: s.n.], 2004. p. 266–283.
  • CZARNECKI; HELSEN; EISENECKER (2005) CZARNECKI, K.; HELSEN, S.; EISENECKER, U. Formalizing cardinality-based feature models and their specialization. Software process: Improvement and practice, [S.l.], v. 10, n. 1, p. 7–29, 2005.
  • DESOUZA; AWAZU; TIWANA (2006) DESOUZA, K. C.; AWAZU, Y.; TIWANA, A. Four dynamics for bringing use back into software reuse. Communications of the ACM, [S.l.], v. 49, n. 1, p. 96–100, 2006.
  • DURSCKI et al. (2004) DURSCKI, R. C.; SPINOLA, M. M.; BURNETT, R. C.; REINEHR, S. S. Linhas de Produto de Software: riscos e vantagens de sua implantação. Simpósio Brasileiro de Processo de Software. S. Paulo, [S.l.], 2004.
  • EICHELBERGER; KRÖHER; SCHMID (2013) EICHELBERGER, H.; KRÖHER, C.; SCHMID, K. An analysis of variability modeling concepts: expressiveness vs. analyzability. In: INTERNATIONAL CONFERENCE ON SOFTWARE REUSE, 2013. Anais… [S.l.: s.n.], 2013. p. 32–48.
  • ERIKSSON et al. (2003) ERIKSSON, H.-E.; PENKER, M.; LYONS, B.; FADO, D. UML 2 toolkit. [S.l.]: John Wiley & Sons, 2003. v. 26.
  • ERIKSSON; BÖRSTLER; BORG (2005) ERIKSSON, M.; BÖRSTLER, J.; BORG, K. The PLUSS approach–domain modeling with features, use cases and use case realizations. In: INTERNATIONAL CONFERENCE ON SOFTWARE PRODUCT LINES, 2005. Anais… [S.l.: s.n.], 2005. p. 33–44.
  • EZRAN; MORISIO; TULLY (2002) EZRAN, M.; MORISIO, M.; TULLY, C. Practical software reuse. [S.l.]: Springer Science & Business Media, 2002.
  • FARIAS; GARCIA; WHITTLE (2008) FARIAS, K.; GARCIA, A.; WHITTLE, J. On the Quantitative Assessment of Class Model Compositions: an exploratory study. In: MODELS, 2008. Proceedings… [S.l.: s.n.], 2008. v. 8.
  • FARIAS et al. (2015a) FARIAS, K.; GARCIA, A.; WHITTLE, J.; CHAVEZ, C. v. F. G.; LUCENA, C. Evaluating the effort of composing design models: a controlled experiment. Software & Systems Modeling, [S.l.], v. 14, n. 4, p. 1349–1365, 2015.
  • FARIAS et al. (2013) FARIAS, K.; GARCIA, A.; WHITTLE, J.; LUCENA, C. Analyzing the effort of composing design models of large-scale software in industrial case studies. In: INTERNATIONAL CONFERENCE ON MODEL DRIVEN ENGINEERING LANGUAGES AND SYSTEMS, 2013. Anais… [S.l.: s.n.], 2013. p. 639–655.
  • FARIAS et al. (2015b) FARIAS, K.; GONÇALES, L.; SCHOLL, M.; OLIVEIRA, T. C.; VERONEZ, M. Toward an Architecture for Model Composition Techniques. In: SEKE, 2015. Anais… [S.l.: s.n.], 2015. p. 656–659.
  • FAVARO; MAZZINI (2009) FAVARO, J.; MAZZINI, S. Extending FeatuRSEB with concepts from systems engineering. In: INTERNATIONAL CONFERENCE ON SOFTWARE REUSE, 2009. Anais… [S.l.: s.n.], 2009. p. 41–50.
  • FERNÁNDEZ-SÁEZ; GENERO; CHAUDRON (2013) FERNÁNDEZ-SÁEZ, A. M.; GENERO, M.; CHAUDRON, M. R. Empirical studies concerning the maintenance of UML diagrams and their use in the maintenance of code: a systematic mapping study. Information and Software Technology, [S.l.], v. 55, n. 7, p. 1119–1142, 2013.
  • FIRMINO et al. (2015) FIRMINO, M. J. d. A. C. et al. Testes de hipóteses: uma abordagem não paramétrica. 2015. Tese (Doutorado em Ciência da Computação) — Universidade de Lisboa, 2015.
  • GAMMA (1995) GAMMA, E. Design patterns: elements of reusable object-oriented software. [S.l.]: Pearson Education India, 1995.
  • GHANAM; MAURER (2010) GHANAM, Y.; MAURER, F. Linking feature models to code artifacts using executable acceptance tests. In: INTERNATIONAL CONFERENCE ON SOFTWARE PRODUCT LINES, 2010. Anais… [S.l.: s.n.], 2010. p. 211–225.
  • GIL (2002) GIL, A. C. Como Elaborar Projetos de Pesquisa. 4. ed. São Paulo: Atlas, 2002.
  • GONÇALES et al. (2015) GONÇALES, L.; FARIAS, K.; SCHOLL, M.; OLIVEIRA, T. C.; VERONEZ, M. Model Comparison: a systematic mapping study. In: SEKE, 2015. Anais… [S.l.: s.n.], 2015. p. 546–551.
  • GRISS; FAVARO; D’ALESSANDRO (1998) GRISS, M. L.; FAVARO, J.; D’ALESSANDRO, M. Integrating feature modeling with the RSEB. In: SOFTWARE REUSE, 1998. PROCEEDINGS. FIFTH INTERNATIONAL CONFERENCE ON, 1998. Anais… [S.l.: s.n.], 1998. p. 76–85.
  • HEIN; SCHLICK; VINGA-MARTINS (2000) HEIN, A.; SCHLICK, M.; VINGA-MARTINS, R. Applying feature models in industrial settings. In: Software Product Lines. [S.l.]: Springer, 2000. p. 47–70.
  • JANSEN; BOSCH (2005) JANSEN, A.; BOSCH, J. Software architecture as a set of architectural design decisions. In: SOFTWARE ARCHITECTURE, 2005. WICSA 2005. 5TH WORKING IEEE/IFIP CONFERENCE ON, 2005. Anais… [S.l.: s.n.], 2005. p. 109–120.
  • JANSEN et al. (2004) JANSEN, A.; SMEDINGA, R.; GURP, J. van; BOSCH, J. First class feature abstractions for product derivation. IEE Proceedings-Software, [S.l.], v. 151, n. 4, p. 187–197, 2004.
  • KANG et al. (1990) KANG, K. C.; COHEN, S. G.; HESS, J. A.; NOVAK, W. E.; PETERSON, A. S. Feature-oriented domain analysis (FODA) feasibility study. [S.l.]: DTIC Document, 1990.
  • KANG et al. (1998) KANG, K. C.; KIM, S.; LEE, J.; KIM, K.; SHIN, E.; HUH, M. FORM: a feature-; oriented reuse method with domain-; specific reference architectures. Annals of Software Engineering, [S.l.], v. 5, n. 1, p. 143–168, 1998.
  • KASTNER et al. (2009) KASTNER, C.; THUM, T.; SAAKE, G.; FEIGENSPAN, J.; LEICH, T.; WIELGORZ, F.; APEL, S. FeatureIDE: a tool framework for feature-oriented software development. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 31., 2009. Proceedings… [S.l.: s.n.], 2009. p. 611–614.
  • KITCHENHAM; BUDGEN; BRERETON (2011) KITCHENHAM, B. A.; BUDGEN, D.; BRERETON, O. P. Using mapping studies as the basis for further research–a participant-observer case study. Information and Software Technology, [S.l.], v. 53, n. 6, p. 638–651, 2011.
  • KITCHENHAM et al. (2010) KITCHENHAM, B.; PRETORIUS, R.; BUDGEN, D.; BRERETON, O. P.; TURNER, M.; NIAZI, M.; LINKMAN, S. Systematic literature reviews in software engineering–a tertiary study. Information and Software Technology, [S.l.], v. 52, n. 8, p. 792–805, 2010.
  • KOEHLER et al. (2005) KOEHLER, J.; HAUSER, R.; SENDALL, S.; WAHLER, M. Declarative techniques for model-driven business process integration. IBM systems journal, [S.l.], v. 44, n. 1, p. 47–65, 2005.
  • KOLOVOS; PAIGE; POLACK (2006) KOLOVOS, D. S.; PAIGE, R. F.; POLACK, F. A. Model comparison: a foundation for model composition and model transformation testing. In: GLOBAL INTEGRATED MODEL MANAGEMENT, 2006., 2006. Proceedings… [S.l.: s.n.], 2006. p. 13–20.
  • KRUEGER (1992) KRUEGER, C. W. Software reuse. ACM Computing Surveys (CSUR), [S.l.], v. 24, n. 2, p. 131–183, 1992.
  • KRUEGER (2006) KRUEGER, C. W. New methods in software product line practice. Communications of the ACM, [S.l.], v. 49, n. 12, p. 37–40, 2006.
  • KRUEGER (2010) KRUEGER, C. W. The BigLever Software Gears Systems and Software Product Line Lifecycle Framework. In: SPLC WORKSHOPS, 2010. Anais… [S.l.: s.n.], 2010. p. 297.
  • LEE; MUTHIG (2006) LEE, J.; MUTHIG, D. Feature-oriented variability management in product line engineering. Communications of the ACM, [S.l.], v. 49, n. 12, p. 55–59, 2006.
  • LESTA; SCHAEFER; WINKELMANN (2015) LESTA, U.; SCHAEFER, I.; WINKELMANN, T. Detecting and Explaining Conflicts in Attributed Feature Models. arXiv preprint arXiv:1504.03483, [S.l.], 2015.
  • MARCONI M. A. E LAKATOS (2003) MARCONI M. A. E LAKATOS, E. M. Fundamentos de Metodologia Científica. 5. ed. São Paulo: Atlas, 2003.
  • MENDONCA; BRANCO; COWAN (2009) MENDONCA, M.; BRANCO, M.; COWAN, D. SPLOT: software product lines online tools. In: ACM SIGPLAN CONFERENCE COMPANION ON OBJECT ORIENTED PROGRAMMING SYSTEMS LANGUAGES AND APPLICATIONS, 24., 2009. Proceedings… [S.l.: s.n.], 2009. p. 761–762.
  • OLIVEIRA; BREITMAN; OLIVEIRA (2009a) OLIVEIRA, K.; BREITMAN, K.; OLIVEIRA, T. Ontology Aided Model Comparison. In: ENGINEERING OF COMPLEX COMPUTER SYSTEMS, 2009 14TH IEEE INTERNATIONAL CONFERENCE ON, 2009. Anais… [S.l.: s.n.], 2009. p. 78–83.
  • OLIVEIRA; GARCIA; WHITTLE (2008) OLIVEIRA, K.; GARCIA, A.; WHITTLE, J. On the quantitative assessment of class model compositions: an exploratory study. 1th ESMDE at MODELS, [S.l.], 2008.
  • OLIVEIRA; BREITMAN; OLIVEIRA (2009b) OLIVEIRA, K. S.; BREITMAN, K. K.; OLIVEIRA, T. C. de. A Flexible Strategy-Based Model Comparison Approach: bridging the syntactic and semantic gap. J. UCS, [S.l.], v. 15, n. 11, p. 2225–2253, 2009.
  • OLIVEIRA (2008) OLIVEIRA, K. S. F. d. Composição de UML Profiles. 2008. Dissertação (Mestrado em Ciência da Computação) — Pontifícia Universidade Católica do Rio Grande do Sul, 2008.
  • OLIVEIRA (2012) OLIVEIRA, K. S. F. de. Empirical Evaluation of Effort on Composing Design Models. 2012. Tese (Doutorado em Ciência da Computação) — PUC-Rio, 2012.
  • OLIVEIRA; OLIVEIRA (2007) OLIVEIRA, K. S.; OLIVEIRA, T. C. de. A guidance for model composition. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING ADVANCES (ICSEA 2007), 2007. Anais… [S.l.: s.n.], 2007. p. 27–27.
  • OLIVEIRA et al. (2008) OLIVEIRA, K. S.; SILVA, M.; OLIVEIRA, T. C. de; ALENCAR, P. S. Uma Abordagem Flexível para Comparação de Modelos UML. In: SBCARS, 2008. Anais… [S.l.: s.n.], 2008. p. 150–163.
  • PETERSEN et al. (2008) PETERSEN, K.; FELDT, R.; MUJTABA, S.; MATTSSON, M. Systematic Mapping Studies in Software Engineering. In: EASE, 2008. Anais… [S.l.: s.n.], 2008. v. 8, p. 68–77.
  • POHL; BÖCKLE; DER LINDEN (2005) POHL, K.; BÖCKLE, G.; DER LINDEN, F. J. van. Software product line engineering: foundations, principles and techniques. [S.l.]: Springer Science & Business Media, 2005.
  • RAZALI; WAH et al. (2011) RAZALI, N. M.; WAH, Y. B. et al. Power comparisons of shapiro-wilk, kolmogorov-smirnov, lilliefors and anderson-darling tests. Journal of statistical modeling and analytics, [S.l.], v. 2, n. 1, p. 21–33, 2011.
  • REINHARTZ-BERGER; FIGL; HAUGEN (2014) REINHARTZ-BERGER, I.; FIGL, K.; HAUGEN, Ø. Comprehending feature models expressed in CVL. In: INTERNATIONAL CONFERENCE ON MODEL DRIVEN ENGINEERING LANGUAGES AND SYSTEMS, 2014. Anais… [S.l.: s.n.], 2014. p. 501–517.
  • REINHARTZ-BERGER; STURM; TSOURY (2011) REINHARTZ-BERGER, I.; STURM, A.; TSOURY, A. Comprehension and Utilization of Core Assets Models in Software Product Line Engineering. In: CAISE FORUM, 2011. Anais… [S.l.: s.n.], 2011. p. 171–178.
  • RIEBISCH et al. (2002) RIEBISCH, M.; BÖLLERT, K.; STREITFERDT, D.; PHILIPPOW, I. Extending feature diagrams with UML multiplicities. In: WORLD CONFERENCE ON INTEGRATED DESIGN & PROCESS TECHNOLOGY (IDPT2002), 6., 2002. Anais… [S.l.: s.n.], 2002. v. 23.
  • SCHAEFER et al. (2012) SCHAEFER, I.; RABISER, R.; CLARKE, D.; BETTINI, L.; BENAVIDES, D.; BOTTERWECK, G.; PATHAK, A.; TRUJILLO, S.; VILLELA, K. Software diversity: state of the art and perspectives. [S.l.]: Springer, 2012.
  • SEGURA et al. (2008) SEGURA, S.; BENAVIDES, D.; RUIZ-CORTÉS, A.; TRINIDAD, P. Automated merging of feature models using graph transformations. In: Generative and Transformational Techniques in Software Engineering II. [S.l.]: Springer, 2008. p. 489–505.
  • TEIXEIRA; BORBA; GHEYI (2013) TEIXEIRA, L.; BORBA, P.; GHEYI, R. Safe composition of configuration knowledge-based software product lines. Journal of Systems and Software, [S.l.], v. 86, n. 4, p. 1038–1053, 2013.
  • THUM; BATORY; KASTNER (2009) THUM, T.; BATORY, D.; KASTNER, C. Reasoning about edits to feature models. In: IEEE 31ST INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 2009., 2009. Anais… [S.l.: s.n.], 2009. p. 254–264.
  • THÜM et al. (2014) THÜM, T.; KÄSTNER, C.; BENDUHN, F.; MEINICKE, J.; SAAKE, G.; LEICH, T. FeatureIDE: an extensible framework for feature-oriented software development. Science of Computer Programming, [S.l.], v. 79, p. 70–85, 2014.
  • VAN GURP; BOSCH; SVAHNBERG (2001) VAN GURP, J.; BOSCH, J.; SVAHNBERG, M. On the notion of variability in software product lines. In: SOFTWARE ARCHITECTURE, 2001. PROCEEDINGS. WORKING IEEE/IFIP CONFERENCE ON, 2001. Anais… [S.l.: s.n.], 2001. p. 45–54.
  • WEBER et al. (2016) WEBER, V.; FARIAS, K.; GONÇALES, L.; BISCHOFF, V. Detecting Inconsistencies in Multi-view UML Models. International Journal of Computer Science and Software Engineering, [S.l.], v. 5, n. 12, 2016.
  • WIERINGA et al. (2006) WIERINGA, R.; MAIDEN, N.; MEAD, N.; ROLLAND, C. Requirements engineering paper classification and evaluation criteria: a proposal and a discussion. Requirements Engineering, [S.l.], v. 11, n. 1, p. 102–107, 2006.
  • WOHLIN et al. (2012) WOHLIN, C.; RUNESON, P.; HÖST, M.; OHLSSON, M. C.; REGNELL, B.; WESSLÉN, A. Experimentation in software engineering. [S.l.]: Springer Science & Business Media, 2012.
  • WOHLIN et al. (2000) WOHLIN, C.; RUNESON, P.; HOST, M.; OHLSSON, M.; REGNELL, B.; WESSLEN, A. Experimentation in software engineering: an introduction. 2000. [S.l.]: Kluwer Academic Publishers, 2000.
  • ZIBRAN; ROY (2011) ZIBRAN, M. F.; ROY, C. K. Towards flexible code clone detection, management, and refactoring in IDE. In: INTERNATIONAL WORKSHOP ON SOFTWARE CLONES, 5., 2011. Proceedings… [S.l.: s.n.], 2011. p. 75–76.