Checklist-based Inspection Technique for Feature Models Review
Rafael M. de Mello, Eldanae N. Teixeira, Marcelo Schots, Cláudia M. L. Werner, Guilherme Horta Travassos
PESC/COPPE – Universidade Federal do Rio de JaneiroCaixa Postal 68.511 – 21945-970 – Rio de Janeiro – RJ – Brasil
Abstract— Software Product Line Engineering aims to ensure the correctness, completeness and consistency among its artifacts and the specified domain, in order to prevent the spread of defects for the products derived from this domain. Among initial artifacts of a software product line, feature models are artifacts generated in various domain engineering approaches. Although software inspection is highlighted as an effective review activity for detection of defects in software artifacts, mainly in the early models of software projects, a recent quasi-systematic review of literature indicated a lack of techniques to support the inspection of software product line artifacts, which include features models. Thus, this paper presents FMCheck, a checklist-based inspection technique to support the detection of defects on feature models. This technique was developed to be configurable and to be applied on several extensions of the original feature model notation presented by FODA approach, including the Odyssey-FEX notation, in particular. FMCheck was submitted to a proof of concept and to a further in vitro feasibility study, in which it could be seen the feasibility of FMCheck application and also that inspections applying FMCheck are more effective than ad-hoc inspections, when applied on four distinct domains.
Keywords— Feature Model, Software Inspection, Domain Engineering, Software Reuse, Software Product Line, Experimental Software Engineering.
Resumo— A Engenharia de Linha de Produtos de software visa garantir a corretude, completude e consistência de seus artefatos com o domínio especificado, visando evitar a propagação de defeitos para os produtos derivados para este domínio. Dentre os artefatos iniciais de uma linha de produtos de software, modelos de características (feature models) consistem em um artefato gerado em diversas abordagens de engenharia de domínio. Embora a inspeção de software destaque-se como uma atividade de revisão efetiva para a detecção de defeitos em artefatos de software, especialmente em modelos iniciais dos projetos de software, uma recente quasi-Revisão Sistemática de literatura indicou a carência de técnicas que apoiem a inspeção de artefatos de linha de produtos de software, incluindo modelos de características. Neste sentido, este trabalho apresenta FMCheck, uma técnica de inspeção baseada em checklist para apoiar a detecção de defeitos em feature models. A técnica foi elaborada para ser configurável, visando atender a diversas extensões da notação do modelo de características originalmente apresentada pela abordagem FODA, abrangendo a notação Odyssey-FEX, em particular. Esta técnica de inspeção foi submetida a uma prova de conceito e a um posterior estudo de viabilidade in vitro, onde pôde ser observado a sua viabilidade de utilização e que as inspeções com FMCheck apresentaram-se mais eficazes do que as inspeções ad-hoc, quando aplicadas a quatro domínios distintos.
Palavras chave— Feature Model, Inspeção de Software, Engenharia de Domínio, Reutilização de Software, Linhas de Produtos de Software, Engenharia de Software Experimental.
I. INTRODUÇÃO
Se no desenvolvimento de software convencional os artefatos iniciais de um projeto precisam ser verificados por formarem a base para a construção de um software, no contexto do desenvolvimento para reutilização existe ainda o agravante de que um único artefato de domínio mal especificado pode levar à propagação de defeitos nos diversos produtos de uma Linha de Produtos de Software (LPS). Por esta razão, torna-se fundamental a execução de atividades de verificação para garantir que os defeitos identificados em artefatos de domínio não sejam propagados para as demais fases da engenharia de domínio, bem como para os produtos derivados a partir de uma LPS.
A verificação de artefatos de software desde as fases iniciais do desenvolvimento do software pode ser realizada através de inspeções de software, que representam um recurso importante para promover tanto a qualidade do produto de software quanto à produtividade no seu desenvolvimento, viabilizando a detecção antecipada de defeitos antes da realização dos testes com consequente redução de retrabalho.
Desde a introdução do processo de inspeção de software por [1], diversas pesquisas têm sido conduzidas buscando o aprimoramento e a sistematização do método de inspeção, incluindo a etapa de preparação para inspeção [2]; o processo de inspeção [3]; a definição de critérios para seleção dos inspetores [4]; critérios para decisão sobre reinspeção [5], infraestrutura de apoio ao processo [6] e o desenvolvimento de técnicas aplicadas em inspeções [7]. No que se refere a este último aspecto, a literatura técnica apresenta diversas técnicas para apoiar a detecção de defeitos em artefatos das fases iniciais do processo de desenvolvimento de software, incluindo checklists [8][9] e técnicas de leitura [10][11].
Entretanto, no contexto de reutilização de software, os resultados de uma quasi-revisão sistemática conduzida em 2011 indicaram a carência de tecnologia específica para a inspeção de artefatos produzidos durante o desenvolvimento de LPSs. Nesta revisão, apenas dois trabalhos referentes à verificação de modelos arquiteturais desenvolvidos para reúso foram identificados, sendo que apenas um deles trata-se de uma técnica de inspeção [12]. Esta técnica, porém, é voltada para modelos arquiteturais, não sendo aplicável aos demais artefatos de uma LPS. Em particular, um artefato gerado em diversas abordagens de engenharia de domínio é o modelo de características (feature model) deste domínio. Este artefato é voltado especificamente para o desenvolvimento para reúso e representa o conjunto de variabilidades de um domínio, i.e., suas similaridades e variabilidades, por meio de características. Pela definição de Kang et al. [13], uma característica representa “um aspecto, uma qualidade, ou uma
característica visível ao usuário, proeminente ou distinta, de um sistema (ou sistemas) de software”.
Feature models são gerados a partir de uma prática de modelagem amplamente utilizada por técnicas sistemáticas de reutilização, podendo ser aplicada tanto na análise quanto no projeto de domínio em diversas abordagens de desenvolvimento para reúso, desde sua versão original em FODA [13] até suas versões estendidas mais recentes, como a notação Odyssey-FEX [14]. Embora a literatura especializada apresente algumas abordagens para a detecção de problemas sintáticos em feature models [15][16][17] apresentando heurísticas tipicamente automatizáveis, estas não apoiam a identificação de defeitos semânticos. Uma ampla e recente revisão da literatura sobre abordagens para verificação automática de feature models pode ser encontrada em [18]. Tais abordagens são importantes para evitar a modelagem incorreta de feature models e apoiar o desenvolvimento de LPS, porém não permitem verificar se um dado feature model corretamente modelado é o mais adequado para representar determinado domínio. Com o objetivo de suprir esta lacuna, portanto, este artigo apresenta uma técnica de inspeção baseada em checklist para apoiar a detecção de defeitos semânticos em feature models. Esta técnica de inspeção (FMCheck) foi construída de forma a ser configurada de acordo com a notação utilizada na LPS. Estudos realizados com FMCheck indicam sua viabilidade e eficácia quando comparada a inspeção realizada de modo ad-hoc.
De forma a apresentar o desenvolvimento de FMCheck e os estudos realizados, este artigo encontra-se estruturado em cinco seções, além desta introdução. A Seção II apresenta como a técnica de inspeção foi concebida, indicando as notações que podem ser usadas nos modelos de características e o conjunto mínimo de possíveis defeitos (casos discrepantes), após a análise dos conceitos presentes nestas notações de feature model consideradas. A Seção III descreve FMCheck, a técnica de inspeção proposta. A Seção IV trata da prova de conceito e do posterior estudo de viabilidade conduzido para a avaliação de FMCheck. Por último, a Seção V apresenta as conclusões e propostas de trabalhos futuros.
II. IDENTIFICAÇÃO DE POSSÍVEIS DEFEITOS EM FEATURE
MODELS
Esta seção apresenta resumidamente conceitos comuns às notações de feature model e outros conceitos específicos da notação Odyssey-FEX [14]. A partir do estudo das diversas notações citadas nesta seção, foi elaborado um conjunto de possíveis defeitos que podem ser detectados em um feature model, quando confrontados com uma descrição textual do domínio correspondente.
A. Notações de Feature Model
Uma das maneiras de especificar o conhecimento adquirido do domínio (denominada modelagem de variabilidades) é pelo enfoque de modelagem de características (features), um modelo de alto nível de abstração que visa expressar os requisitos do domínio através de características. Embora variabilidades possam ser modeladas através de modelos de software já conhecidos (modelos UML estendidos, por exemplo), a modelagem de
variabilidades através de características costuma ser utilizada em processos de LPS.
Essa modelagem de características pode ser realizada através de diferentes notações, incluindo a notação original de [13] e variações, tais como: a notação de Riebisch [19], a notação de Cechticky [20], Czarnecki [21][22] e a notação de Gomaa [23]. A literatura também apresenta notações disponíveis para métodos específicos, tais como FeatuRSEB [24] e FORM [25][26], além da própria Odyssey-FEX [14]. Entre todas estas notações e abordagens, alguns conceitos apresentam uma semântica comum, independente de sua representação gráfica ou de sua nomenclatura, formando um núcleo ou base de conceitos, a partir do qual cada notação pode ser estendida, como os conceitos de opcionalidade e obrigatoriedade, variabilidades e as relações simples de dependência. Além destes conceitos em comum, algumas notações são mais abrangentes,com maior riqueza de aparatos para apoiar a modelagem, como no caso da notação Odyssey-FEX [14] que proporciona uma maior variedade de relacionamentos entre as características e uma melhor classificação das características quando comparada com outras notações [27], através de tipos de características que refletem as diferentes fases de desenvolvimento do software (Figura 1). A notação Odyssey-FEX permite ainda descrever textualmente relações de dependência e de mútua exclusividade através de Regras de Composição Complexas, envolvendo operadores booleanos em expressões formadas por duas ou mais características.
Figura 1. Tipos de Características na notação Odyssey-FEX
B. Casos Discrepantes
Entende-se por caso discrepante uma situação genérica que pode ser encontrada em um artefato a ser inspecionado de modo a qualificar uma discrepância, ou seja, um possível defeito [28]. A partir da experiência obtida com inspeções ad hoc de feature models, combinada à análise dos conceitos presentes na notação original de feature model de Kang [13] e das outras notações citadas na subseção A, foram identificados 48 casos discrepantes para este tipo de modelagem, basicamente relacionados à consistência, clareza, corretude e completude de um feature model com relação a uma descrição textual do domínio. É importante observar que os casos discrepantes identificados não pretendem abranger todas as
possibilidades de defeito que possam ser detectadas em um feature model.
Cada caso discrepante está relacionado a uma categoria de defeito, de acordo com a classificação adotada por Shull [11] para defeitos na descrição textual de requisitos, estendida em [29] para modelos UML: omissão, fato incorreto, inconsistência, ambiguidade e informação estranha. Esta categorização foi adaptada para orientar a identificação e classificação dos casos discrepantes em feature models, como pode ser observado na TABELA I.
TABELA I
CATEGORIAS DE DEFEITO (ADAPTADO DE TRAVASSOS ET AL.2001)
Nome Descrição
Omissão Alguma informação do domínio não foi devidamente incluída no feature model.
Fato Incorreto Alguma informação ou comportamento do feature model contradiz a especificação do domínio.
Inconsistência Algum elemento do modelo não está consistente com outro elemento do próprio feature model.
Ambiguidade
Alguma informação presente no feature model não está clara, levando a múltiplas interpretações dentro do domínio especificado.
Informação Estranha
Alguma informação presente no feature model não faz parte do domínio especificado.
Os 48 casos discrepantes identificados foram organizados nos seguintes grupos:
A. Descrição da característica: cinco casos discrepantes relacionados a uma análise individual de cada característica. Essa categoria verifica a clareza da descrição de uma característica e sua participação no domínio de acordo com o documento base;
B. Tipo da característica: sete casos discrepantes relacionados ao uso dos tipos de característica previstos na notação Odyssey-FEX [14];
C. Opcionalidade/ Obrigatoriedade: três casos discrepantes relacionados à classificação de cada característica do modelo como opcional ou obrigatória dentro do domínio como um todo. Essa categoria também verifica se essa classificação pode ser definida a partir do documento base;
D. Variabilidade e Relacionamentos de associação: 16 casos discrepantes referentes ao estabelecimento de relações entre características. Esta categoria analisa se as relações especificadas no documento base foram devidamente representadas no modelo. O conceito de variabilidade é avaliado através do estabelecimento de relações de uma característica ponto de variação (característica que reflete a parametrização no domínio de uma maneira abstrata) e suas alternativas de configuração (características variantes). Para este conceito, o número de instâncias de variantes que podem configurá-lo em um produto específico é analisado. Relacionamentos de agregação, composição, generalização, e “implementado por” (relacionamento entre Características de Domínio e Características Tecnológicas) também são considerados;
E. Relacionamentos de dependência e mútua exclusividade: seis casos discrepantes referentes à representação gráfica de dependência e de exclusão mútua entre características. Esses conceitos são
intrínsecos à modelagem de variabilidades e tratam da seleção conjunta de elementos (dependência), ou, ao contrário, da incompatibilidade de uma seleção conjunta (mútua exclusividade), durante a instanciação de uma aplicação a partir de um domínio ou no desenvolvimento de um novo produto em uma LPS. Tais indicações possibilitam a derivação de uma aplicação ou produto mais consistente em relação às especificações do domínio;
F. Lógica e Regras de Composição: cinco casos discrepantes referentes à descrição de textual de regras lógicas e de composição no modelo, não se restringindo a dependência e exclusão mútua;
G. Visão geral do modelo: seis casos discrepantes referentes à clareza e à consistência do modelo como um todo. As características constituintes do modelo são avaliadas a fim de verificar se são de fato significativas dentro do domínio. Também é analisado o nível de detalhamento do modelo para sua compreensão e posterior aplicação para implementação do domínio.
III. FMCHECK
A partir dos casos discrepantes mencionados na seção anterior e, com base na experiência obtida com o desenvolvimento da técnica de inspeção ActCheck [9], foi elaborada FMCheck (Feature Model Checklist), uma técnica de inspeção baseada em checklist para apoiar a detecção de defeitos em feature models. Esta técnica foi desenvolvida com foco em processos de inspeção que preveem a execução de inspeções individuais, em que cada inspetor detecta e relata individualmente as discrepâncias por ele identificadas.
A técnica não requer que os inspetores detenham conhecimento prévio sobre o domínio que irão inspecionar. Entretanto, como premissa para a aplicação de FMCheck, espera-se que exista alguma descrição textual (documento de requisitos, descrição/ especificação do domínio) válida (previamente inspecionada) que sirva como base de comparação para viabilizar a verificação do feature model.
A aplicação de FMCheck prevê um fluxo de atividades específicas para sua aplicação. A primeira atividade é realizada pelo analista/ projetista do domínio e consiste no preenchimento do questionário de caracterização do modelo, que visa auxiliar no recorte do checklist para aplicação em um contexto específico. Esta atividade está relacionada à flexibilidade de FMCheck e sua possibilidade em atender a diferentes notações de modelagem de características, que tenham como base a notação original de FODA [13].
A atividade seguinte consiste na configuração do checklist, e é realizada pelo moderador da inspeção, levando em consideração o questionário preenchido e uma tabela de rastreabilidade definida na técnica. O questionário auxilia a determinar quais serão os itens de verificação que farão parte do checklist de determinada inspeção.
A última atividade consiste na realização de uma ou mais inspeções individuais e, consequentemente, no preenchimento do relatório de discrepâncias correspondente a cada inspeção. FMCheck possui um formulário padrão para o relato das discrepâncias identificadas, no qual o inspetor deve classificar cada discrepância identificada e especificar sua respectiva
localização no modelo. As subseções a seguir apresentam o questionário de caracterização do modelo e o checklist que compõem a técnica de inspeção.
A. Questionário de Caracterização do Modelo
Os itens do Questionário de Caracterização do Modelo visam fornecer subsídios para a configuração do checklist. Estas questões visam definir: (1) a fase da Engenharia de Domínio que o modelo visa atender (Análise ou Projeto do Domínio); (2) a notação escolhida para representar o modelo; e (3) quais recursos de modelagem estão comtemplados no modelo.
Conforme a resposta a estas questões, o checklist de uma inspeção específica poderá conter desde um número mínimo de itens de verificação (14), aplicável a qualquer feature model, até todos os 34 itens de verificação de FMCheck. O objetivo principal é evitar que o desempenho da inspeção seja impactado por itens de verificação desnecessários, já que nem todos os itens se aplicam a todos os cenários possíveis de utilização da técnica. Os itens do questionário devem ser respondidos pelo analista/ projetista do domínio com base no que é previsto na abordagem adotada, e não necessariamente nos recursos apresentados pelo modelo a ser inspecionado. B. O Checklist
Embora os 48 casos discrepantes apresentados na Seção II estejam subdivididos em sete grupos, é importante observar que, para efeito da composição do checklist, uma quantidade excessiva de divisões pode levar os inspetores ao retrabalho de inspeção, conforme foi constatado em experiência anterior com a técnica ActCheck [9]. A organização de uma técnica de inspeção deve, portanto, primar pela sua praticidade. Assim, alguns casos discrepantes foram analisados e agrupados, de forma que um mesmo item de verificação possa avaliar mais de um caso discrepante. Como resultado, o checklist de FMCheck ficou composto por 34 questões ou itens de verificação, que se dividem em três grupos de verificação, nesta ordem: verificação individual das características do modelo; verificação dos relacionamentos entre as características do modelo; verificação das regras de composição do modelo.
Cada grupo de verificação será detalhado a seguir, com seus itens de verificação apresentados em tabelas correspondentes. Para cada item, existem três opções de resposta (“Sim”, “Não” e ”N.A.”). A opção “N.A.” em cada item significa que este item não seria passível de avaliação no modelo inspecionado, ou seja, ele é previsto na notação adotada, mas não é necessário e nem se encontra presente no modelo. Os itens de verificação em negrito nas Tabelas II e III a seguir representam aqueles itens que se aplicam exclusivamente à notação Odyssey-FEX.
1) Verificação individual das características do modelo Os 13 itens de verificação (TABELA II) que abordam este grupo tratam exclusivamente da análise de cada característica do modelo, sem observar os seus relacionamentos. De um modo geral, busca-se garantir que o modelo possui características corretas, pertinentes ao domínio e descritas com clareza e objetividade. Os itens constituintes deste grupo são
correspondentes às categorias A, B, C e G dos casos discrepantes descritos na Seção II.
TABELA II
ITENS PARA VERIFICAÇÃO INDIVIDUAL DAS CARACTERÍSTICAS DO MODELO
# Item de verificação Resposta
1 Todas as características do modelo foram descritas com clareza e estão corretas? Sim ( ) Não ( ) N.A. ( ) 2
A opcionalidade/ obrigatoriedade das características do modelo estão em conformidade com o descrito pelo domínio?
Sim ( ) Não ( ) N.A. ( ) 3 É possível identificar o tipo de cada característica do modelo
a partir de sua descrição?
Sim ( ) Não ( ) N.A. ( )
4
As características que representam conceitos reais do domínio estão devidamente representadas no modelo como características de domínio conceituais (conceptual)?
Sim ( ) Não ( ) N.A. ( ) 5
As características que representam funcionalidades do domínio estão devidamente representadas no modelo como características de domínio funcionais (functional)?
Sim ( ) Não ( ) N.A. ( ) 6
As características que representam uma entidade real do domínio estão devidamente representadas no modelo como características de entidade?
Sim ( ) Não ( ) N.A. ( ) 7
As características que representam atributos de um ambiente relacionado ao uso/operação da aplicação do domínio estão devidamente representadas no modelo como características do ambiente operacional?
Sim ( ) Não ( ) N.A. ( )
8
As características que representam uma tecnologia utilizada para modelar ou implementar o domínio estão devidamente representadas no modelo como características de tecnologia do domínio?
Sim ( ) Não ( ) N.A. ( )
9
As características que representam uma tecnologia utilizada para implementar outras características do modelo estão devidamente representadas no modelo como características da técnica de implementação?
Sim ( ) Não ( ) N.A. ( )
10
As características que não possuem ligações concretas com o domínio, mas facilitam o seu entendimento, estão representadas no modelo como características organizacionais?
Sim ( ) Não ( ) N.A. ( )
11
Alguma característica do modelo, embora correta, está fora do escopo do modelo, não contribuindo para o entendimento do domínio?
Sim ( ) Não ( ) N.A. ( ) 12 Existem características distintas no modelo que representam um mesmo conceito do domínio?
Sim ( ) Não ( ) N.A. ( ) 13 Algum conceito relevante do domínio deixou de ser incluído no modelo?
Sim ( ) Não ( ) N.A. ( )
2) Verificação dos relacionamentos entre as características do modelo
Os 16 itens de verificação deste grupo (TABELA III) orientam o inspetor a examinar os relacionamentos entre as características. Os itens visam analisar o quanto os relacionamentos entre as características do modelo o tornam compreensível, aderente ao domínio e implementável. Este grupo aborda as categorias D e E dos casos discrepantes descritas na Seção II.
3) Verificação das regras de composição entre as características do modelo
Os cinco itens de verificação deste grupo (
) orientam o inspetor no exame da clareza, completude, corretude, pertinência e consistência das regras de composição do modelo (que podem ser utilizadas para complementar a representação gráfica de um feature model) com relação aos
conceitos previstos no domínio. Esse conjunto de itens corresponde à categoria F dos casos discrepantes descrita na Seção II.
TABELA III
ITENS PARA VERIFICAÇÃO DOS RELACIONAMENTOS ENTRE AS
CARACTERÍSTICAS DO MODELO
# Item de verificação Resposta
14
As situações do domínio em que uma ou mais de uma característica podem ser escolhidas dentro de um conjunto de características (OU, OU Exclusivo) estão devidamente representadas no modelo?
Sim ( ) Não ( ) N.A. ( ) 15 As cardinalidades dos pontos de variação do modelo estão corretas?
Sim ( ) Não ( ) N.A. ( ) 16
Os pontos de variação do modelo estão descritos com clareza e suas descrições refletem as características que os compõem?
Sim ( ) Não ( ) N.A. ( ) 17
Duas ou mais características do modelo estão reunidas em um relacionamento, mas não é possível identificar este relacionamento no domínio?
Sim ( ) Não ( ) N.A. ( ) 18 Existe algum relacionamento entre características que deixou
de ser informado no modelo?
Sim ( ) Não ( ) N.A. ( ) 19 A hierarquia entre as características está em conformidade
com o domínio?
Sim ( ) Não ( ) N.A. ( )
20 Alguma característica foi indevidamente apontada como generalização de outra?
Sim ( ) Não ( ) N.A. ( ) 21
As características que estão apontadas no modelo como "implementada por" outra característica, possuem este relacionamento no domínio?
Sim ( ) Não ( ) N.A. ( ) 22
Os relacionamentos de agregação e de composição entre características do domínio apontados no modelo condizem com a realidade deste domínio?
Sim ( ) Não ( ) N.A. ( )
23
Alguma dependência ou relação de mútua exclusividade entre características no modelo não se aplica ao domínio descrito?
Sim ( ) Não ( ) N.A. ( ) 24 Alguma dependência ou relação de mútua exclusividade
entre características deixou de ser informada no modelo?
Sim ( ) Não ( ) N.A. ( ) 25 A presença de alguma característica no modelo contraria
outra característica do mesmo modelo?
Sim ( ) Não ( ) N.A. ( ) 26 A característica-raiz auxilia a compreensão do domínio que
ela e as demais características do modelo buscam descrever?
Sim ( ) Não ( ) N.A. ( ) 27 De um modo geral, é possível compreender o domínio a
partir de suas características?
Sim ( ) Não ( ) N.A. ( ) 28
O modelo descreve o domínio em um nível de detalhamento adequado para ser compreendido sob a perspectiva pretendida?
Sim ( ) Não ( ) N.A. ( ) 29 O modelo apresenta as características necessárias e
suficientes para orientar sua implementação?
Sim ( ) Não ( ) N.A. ( )
IV. AVALIAÇÃO DA TÉCNICA DE INSPEÇÃO
A avaliação da viabilidade de FMCheck se deu por meio de duas atividades: uma prova de conceito e um primeiro estudo experimental. As subseções a seguir descrevem estas duas avaliações.
A. Prova de Conceito
Após a elaboração da primeira versão de FMCheck, foram convocados dois desenvolvedores, um aluno de doutorado (mais experiente) e um de mestrado (menos experiente) do
grupo de Reutilização de Software da COPPE/UFRJ, para aplicarem a técnica em um domínio específico (telefonia móvel). Os participantes da prova de conceito foram apresentados à técnica de inspeção, mas desconheciam os artefatos do domínio antes da inspeção. Cada participante recebeu um e-mail contendo os artefatos necessários para a realização da inspeção, incluindo uma planilha contendo FMCheck. Como o feature model deste domínio foi modelado utilizando-se Odyssey-FEX, o checklist da prova de conceito continha todos os itens de verificação oferecidos pela técnica.
A Tabela V a seguir apresenta os resultados das inspeções de cada participante. A eficácia é retratada como a razão entre o número de defeitos detectados por um inspetor e a quantidade total de defeitos do domínio, enquanto que a eficiência indica o tempo médio em minutos que foram necessários para que o inspetor detectasse um defeito. É importante destacar a baixa incidência de falsos positivos e a alta incidência de defeitos idênticos encontrados pelos dois participantes. Comparando o resultado das duas inspeções, destacamos que o inspetor mais experiente (P2) detectou mais defeitos do que o participante menos experiente (P1), embora tenha precisado de muito mais tempo para realizar sua tarefa.
Foram feitas observações positivas pelos dois participantes quanto à técnica de inspeção ter ajudado no desempenho da tarefa. O participante mais experiente observou um possível fator de influência negativa no seu desempenho, referente à limitação de recursos do ambiente para auxiliar o preenchimento da planilha e a análise dos artefatos envolvidos em uma mesma tela. Neste momento, entretanto, o interesse maior é observar a viabilidade de utilização da técnica. Questões relacionadas a um possível apoio automatizado ou semi automatizado deverão ser observadas em investigações futuras. Por outro lado, os resultados observados motivaram o planejamento e execução de um estudo experimental visando aumentar a capacidade de observação e a confiança na viabilidade de uso de FMCheck.
TABELA IV
ITENS PARA VERIFICAÇÃO DAS REGRAS DE COMPOSIÇÃO ENTRE AS
CARACTERÍSTICAS DO MODELO
# Item de verificação Resposta
30
Todas as regras de composição do modelo estão descritas com clareza e objetividade e estão em conformidade com o domínio?
Sim ( ) Não ( ) N. A. ( ) 31 Alguma regra de composição do modelo contraria outra
regra de composição do mesmo modelo?
Sim ( ) Não ( ) N. A. ( ) 32 Alguma regra de composição do modelo não se aplica ao
domínio, embora possa estar correta?
Sim ( ) Não ( ) N. A. ( ) 33 Todas as regras de composição necessárias para descrever o
domínio foram devidamente representadas no modelo?
Sim ( ) Não ( ) N. A. ( ) 34 O modelo apresenta as regras de composição necessárias e
suficientes para orientar sua implementação?
Sim ( ) Não ( ) N. A. ( )
TABELA V
RESUMO DOS RESULTADOS DA PROVA DE CONCEITO
Part. Defeitos Defeitos iguais
Falsos Positivos
Tempo
(min.) Eficácia Eficiência
P1 12
6 2 80 92,31% 6,67
P2 7 1 12 53,85% 1,71
B. Estudo Experimental
Os resultados observados na prova de conceito indicaram que a mesma versão de FMCheck deveria ser submetida a um estudo experimental para avaliar sua viabilidade. Este estudo consiste de duas perspectivas, a saber: análise quantitativa e análise qualitativa. As subseções a seguir apresentam um resumo do plano de estudo elaborado, os resultados obtidos e a análise quantitativa realizada. Os resultados da análise qualitativa, tendo em vista o volume de informação associado, não serão apresentados neste artigo. Entretanto, as avaliações iniciais, embora não conclusivas, não indicam tendência de contradição com os resultados quantitativos. Pelo contrário, trazem sugestões que podem apoiar futuras melhorias em FMCheck. Do mesmo modo, ressaltamos que a análise quantitativa apresentada nos itens a seguir não trata de desdobramentos relevantes, tais como: a relação entre defeitos nativos, defeitos semeados e defeitos detectados; a análise da distribuição por categorias de defeitos, entre outros.
1) Metas Específicas
Analisar: a realização de inspeção de feature models com técnicas ad-hoc e FMCheck
Com o propósito de: caracterizar
Com respeito a: eficácia (defeitos identificados/total de defeitos existentes) e eficiência (defeitos identificados/hora) na identificação de defeitos e a percepção dos inspetores,
Do ponto de vista de: pesquisadores em engenharia de software
No contexto de: estudantes de graduação e de pós-graduação da disciplina de Reutilização de Software do programa de Engenharia de Sistemas e Computação da COPPE/UFRJ inspecionando feature models representando 4 domínios de aplicação distintos (telefonia móvel, hotelaria, dispositivos móveis sensíveis ao contexto, biblioteca).
2) Questões e Métricas:
• Questão: Como se caracteriza o tempo utilizado na inspeção com a técnica FMCheck e com a técnica ad-hoc?
• Métricas: tempo (horas) dedicado à inspeção, eficiência da inspeção.
• Questão: Qual técnica de inspeção (FMCheck, ad-hoc) permite aos inspetores encontrar mais defeitos?
• Métricas: quantidade de defeitos detectados, eficácia da inspeção.
3) Hipóteses
H01: Não existe diferença entre a eficiência de inspeções de feature models realizadas com a técnica FMCheck ou técnica ad-hoc.
HA1: A eficiência de inspeções de feature models realizadas com a técnica FMCheck é melhor que a eficiência com técnica ad-hoc.
H02: Não existe diferença entre a eficácia de inspeções de feature models realizadas com a técnica FMCheck ou técnica ad-hoc.
HA2: A eficácia de inspeções de feature models com a técnica FMCheck é melhor que a eficácia com a técnica ad-hoc.
4) Variáveis
• Independentes: domínios de aplicação descritos textualmente e representados através de feature models por meio da notação Odyssey-FEX, experiência dos participantes com inspeções, conhecimento prévio dos inspetores nos domínios envolvidos.
• Dependentes: Quantidade de defeitos e de falsos positivos, tempo dedicado às inspeções, eficiência e eficácia das inspeções.
5) Projeto Experimental
A população do estudo foi representada por 14 alunos (quatro de graduação e 10 de pós-graduação) de uma disciplina de Reutilização de Software na COPPE/UFRJ, que assinaram o termo de consentimento e preencheram o formulário de caracterização.
Estes participantes foram organizados em três grupos (A, B e C) com base nos seguintes critérios, nesta ordem: experiência com engenharia de software na indústria e na academia; tipo de curso do participante (graduação, mestrado, doutorado); experiência com inspeções de software em geral e com feature models. Entretanto, para alocar os participantes nos grupos, foi utilizado apenas o uso do primeiro critério. Assim o Grupo A foi formado por quatro participantes com maior experiência na indústria; o grupo B foi formado por seis participantes com alguma experiência na indústria e o Grupo C foi formado por quatro participantes com experiência estritamente acadêmica.
Antes da primeira rodada, os participantes foram treinados em inspeção de software e em descrições de domínio por meio de feature models, preparando-os para a realização de duas inspeções ad-hoc. Neste momento, dois participantes desistiram de participar do estudo. Na segunda rodada, cada participante deveria realizar duas inspeções de artefatos distintos dos que haviam sido inspecionados na primeira rodada, utilizando FMCheck. Para tal, os participantes foram treinados na técnica antes da execução da segunda rodada. Na segunda rodada, três participantes desistiram do estudo. Desta forma, apenas nove participantes do total apresentam resultados relacionados à inspeção com as técnicas ad-hoc e FMCheck.
6) Instrumentação
Os artefatos (especificação do domínio e feature model) de quatro domínios distintos (telefonia móvel, hotelaria, dispositivos móveis sensíveis ao contexto, biblioteca) foram selecionados para que os participantes realizassem suas inspeções em cada rodada. A Figura 2 apresenta um recorte do feature model do domínio de hotelaria. A cada rodada, os participantes inspecionaram dois domínios distintos, que foram balanceados conforme (i) a complexidade do feature model e (ii) a quantidade prévia de participantes e seus grupos de pertinência (A, B ou C).
Figura 2. Recorte do feature model “Hotelaria”.
Para definir a complexidade de cada feature model, foi feita uma análise comparativa entre os quatro modelos, considerando os seguintes critérios: quantidade de características, profundidade máxima entre características e quantidade de variabilidades. Deste modo, dois domínios foram considerados simples: telefonia móvel e biblioteca (S01 e S02, respectivamente); e os outros dois modelos foram considerados complexos: dispositivos móveis sensíveis ao contexto e hotelaria (C01 e C02, respectivamente). A distribuição final dos modelos entre os participantes nas duas rodadas pode ser visualizada na Tabela VI.
TABELA VI
DISTRIBUIÇÃO PLANEJADA DOS INSPETORES E DOS ARTEFATOS NAS DUAS
RODADAS
Grupo Participante Rodada 1 (ad-hoc) (FMCheck) Rodada 2
A P1 C01 C02 S01 S02 P2 S01 S02 C01 C02 P3 S01 C01 S02 C02 P4 S02 C02 S01 C01 B P5 S01 C02 S02 C01 P6 S02 C01 S01 C02 P7 S01 S02 C01 C02 P8 C01 C02 S01 S02 P9 S01 C01 S02 C02 P10 S02 C02 S01 C01 C P11 S01 C02 S02 C01 P12 S02 C01 S01 C02 P13 S01 S02 C01 C02 P14 C01 C02 S01 S02
A partir de um questionário de follow-up enviado por e-mail para cada participante, foram coletadas as impressões
sobre a aplicação de FMCheck, incluindo possíveis contribuições que a aplicação técnica trouxe para os participantes no seu aprendizado e na detecção de defeitos; além disso, foram também coletadas sugestões de melhoria.
7) Mecanismos de análise
Os seguintes mecanismos de análise sobre os dados coletados foram adotados neste estudo:
• Comparação dos resultados totais e por grupo das inspeções ad-hoc e com FMCheck.
• Comparação do desempenho de cada participante ao longo das duas rodadas.
• Cálculo da variância e do desvio padrão dos defeitos e do tempo dedicado à inspeção para cada tipo de inspeção aplicado.
• Eliminação de outliers.
• Verificação da normalidade dos dados (Shapiro-Wilk).
• Verificação da homocedasticidade dos dados (Levene).
• Aplicação do teste de Wilcoxon (não paramétrico) ou o teste t de Student (paramétrico), conforme cada caso.
8) Execução
A execução do estudo deu-se nos meses de abril/maio de 2012, iniciando-se com o preenchimento do termo de consentimento e do questionário de caracterização pelos 14 participantes. Em seguida, os participantes foram treinados em feature models e na notação Odyssey-FEX, que faziam parte do conteúdo programático da disciplina. Complementarmente, os alunos receberam um treinamento introdutório de uma hora sobre inspeções de software, bem como orientações para a execução da primeira rodada do estudo.
Com o agrupamento dos participantes e a definição de seus domínios de inspeção em cada rodada, foi encaminhado para cada um, por e-mail, os pacotes de inspeção, sendo que 12 participantes responderam dentro do prazo, relatando os defeitos detectados em cada inspeção. Em seguida, os participantes foram treinados por uma hora na técnica de inspeção FMCheck, através dos seus itens de verificação e de exemplos de defeitos que poderiam ser detectados através destes itens. Na segunda rodada, conforme dito anteriormente, nove participantes mantiveram sua participação no estudo, respondendo aos pacotes encaminhados.
A Tabela VII apresenta um resumo dos resultados obtidos nas inspeções ad-hoc, com o cálculo da eficácia e da eficiência. A Tabela VIII mostra os resultados para FMCheck. Para o cálculo da eficácia (razão entre os defeitos detectados e o total de defeitos), foram considerados como total de defeitos de cada feature model a soma dos defeitos distintos detectados nas inspeções de cada artefato nas duas rodadas. Esta totalização é apresentada na Tabela IX.
TABELA VII
RESULTADOS DA PRIMEIRA RODADA:INSPEÇÕES AD-HOC
Grupo Part. Domínio Tempo Defeitos Eficiência Eficácia
A P2 S01 31 3 10,33 23,08% S02 19 3 6,33 6,98% P3 C01 50 8 6,25 18,18% S01 50 6 8,33 46,15% P4 C02 40 2 20,00 6,90% S02 32 3 10,67 6,98% B P5 C02 138 15 9,20 51,72% S01 43 9 4,78 69,23% P6 C01 44 11 4,00 25,00% S02 50 6 8,33 13,95% P7 S01 34 6 5,67 46,15% S02 41 6 6,83 13,95% P8 C01 32 4 8,00 9,09% C02 43 2 21,50 6,90% P9 C01 25 5 5,00 11,36% S01 30 3 10,00 23,08% C P11 C02 94 16 5,88 55,17% S01 65 3 21,67 23,08% P12 C01 50 8 6,25 18,18% S02 35 14 2,50 32,56% P13 S01 30 1 30,00 7,69% S02 30 4 7,50 9,30% P14 C01 65 6 10,83 13,64% C02 45 6 7,50 20,69% TABELA VIII
RESULTADOS DA SEGUNDA RODADA:INSPEÇÕES COM FMCHECK. Grupo Part. Domínio Tempo Defeitos Eficiência Eficácia
A P2 C01 83 25 6,92 27,27% C02 78 21 9,75 27,59% P3 C02 60 12 6,00 34,48% S02 60 19 4,00 34,88% B P5 C01 142 32 6,17 52,27% S02 138 31 4,76 67,44% P6 C02 55 12 6,11 31,03% S01 36 6 9,00 30,77% P7 C01 63 20 4,50 31,82% C02 54 16 4,15 44,83% P8 S01 20 2 10,00 15,38% S02 45 5 22,50 4,65% C P11 C01 104 21 6,12 38,64% S02 90 23 5,63 37,21% P12 C02 85 16 7,73 37,93% S01 50 11 7,14 53,85% P13 C01 60 7 10,00 13,64% C02 60 9 8,57 24,14% TABELA IX
TOTAL DE DEFEITOS DISTINTOS DETECTADOS EM CADA DOMÍNIO
Domínio Total Defeitos C01 44 C02 29 S01 13 S02 43 9) Análise Quantitativa
Os resultados obtidos nas duas rodadas foram analisados sob diversas perspectivas, dentre elas: tempo, discrepâncias, defeitos, eficiência e eficácia. Além disto, buscou-se observar também diferenças nestas perspectivas em relação aos grupos e artefatos inspecionados. Para cada distribuição analisada, foram removidos os respectivos outliers. As análises foram realizadas com o auxílio da ferramenta JMP 4.0, com α=0,05.
Todas as distribuições apresentaram distribuição normal após a retirada de 14 outliers (11 observações em ad-hoc e 3 em FMCheck). Para a maioria das perspectivas, incluindo a eficácia e a eficiência, foi verificado que as distribuições apresentaram homocedasticidade, exceto para discrepâncias e defeitos. A Tabela X apresenta o comportamento das distribuições e o resultados dos testes, considerando 13 observações em ad-hoc e 15 em FMCheck.
TABELAX
NORMALIDADE E HOMOCEDASTICIDADE DAS DISTRIBUIÇÕES
Distribuição
Normalidade
(Shapiro-Wilk, p-value) Variância (Levene, p-value) Ad-hoc FMCheck Tempo 0,3966 0,6756 0,2078 Discrepâncias 0,1225 0,7162 0,0021 Defeitos 0,0606 0,9247 0,0047 Eficiência 0,2683 0,3128 0,7176 Eficácia 0,3056 0,7809 0,1833
Nas distribuições normais e homocedásticas foi aplicado o teste t de Student. Nas distribuições que não apresentaram homocedasticidade foi usado teste não paramétrico de Wilcoxon. A Tabela XI mostra o resultado dos testes e o resultado final da comparação. Pode-se observar que não foi possível refutar a hipótese nula em relação à eficiência das técnicas. Entretanto, a hipótese nula a respeito da eficácia foi refutada.
TABELA XI
TESTE ESTATÍSTICO DAS DISTRIBUIÇÕES
Distribuição Resultado da Análise
Teste Estatístico (p-value) t-test Wilcoxon
Tempo Adhoc < FMCheck 0,0008 - Discrepâncias Adhoc < FMCheck - 0,0118 Defeitos Adhoc < FMCheck - 0,0018 Eficiência Adhoc = FMCheck 0,2229 - Eficácia Adhoc < FMCheck 0,0001 - De acordo com os resultados, o tempo necessário para realizar inspeção com a técnica FMCheck é maior do que com ad-hoc. Entretanto, foi possível observar que, embora apresente eficiência equivalente, FMCheck faz com que os inspetores consigam identificar 51,3% a mais de defeitos do que com a técnica ad-hoc, cuja distribuição pode ser visto através dos boxplots apresentados na Figura 3.
A análise comparativa da eficácia entre as duas técnicas permitiu refutar a hipótese nula H02, ou seja, as inspeções com
FMCheck apresentaram-se significativamente mais eficazes do que inspeções ad-hoc, com α=0,05, como pode ser observado na Figura 4.
D e fe it o s 0 5 10 15 Adhoc FMCheck Tecnica
Figura 3: Distribuição da quantidade de defeitos das amostras.
E fi c a c ia 0,1 0,2 0,3 0,4 0,5 Adhoc FMCheck Tecnica Each Pair Student's t 0,05
Figura 4. Distribuição da Eficácia das amostras e teste-t de Student correspondente
Buscando entender melhor os comportamentos observados nas distribuições, foi analisado o desempenho de cada grupo (A, B e C) individualmente. A análise individual apontou que os três grupos apresentaram incremento significativo em sua eficácia com a aplicação de FMCheck (α=0,05). Quanto à eficiência, os resultados de cada grupo também refletiram a mesma conclusão da amostra como um todo, ou seja, os grupos foram tão eficientes em inspeções com FMCheck quanto em inspeções ad-hoc.
Testes estatísticos também foram aplicados para observar a influência de cada domínio inspecionado (S01, S02, C01 e C02) nos resultados observados para a amostra como um todo. Neste sentido, observou-se que nenhum dos quatro domínios inspecionados representou ser fator de confusão para a conclusão sobre a eficácia superior de FMCheck, não sendo detectado nenhum comportamento divergente daquele observado para a amostra como um todo. Com FMCheck, inclusive, foi observado um comportamento mais homogêneo (menor variação) do que as inspeções ad-hoc quanto à eficácia dos inspetores para todos os quatro domínios.
Observando o desempenho individual dos nove participantes que atuaram nas duas rodadas, foi observado que sete destes apresentaram um incremento na sua eficácia aplicando FMCheck, sendo que seis destes (ou seja, 2/3 da população que atuou nas duas rodadas) apresentaram melhoria na eficácia superior a 40%.
Em geral, as inspeções com FMCheck foram capazes de detectar 118 defeitos distintos, enquanto que as inspeções ad-hoc detectaram apenas 76 defeitos. É importante observar que esta vantagem de FMCheck foi obtida com um grupo de inspetores 25% menor.
Outro aspecto relevante a ser observado é que FMCheck detectou 53 defeitos distintos que as inspeções ad-hoc não detectaram, enquanto que as inspeções ad-hoc foram capazes de detectar apenas 11 defeitos distintos que não foram também capturados por FMCheck (Figura 5). Entretanto, foi verificado que os itens de verificação de FMCheck cobrem 10 dos 11 defeitos relatados somente nas inspeções ad-hoc, o que sugere uma ampla cobertura dos itens de verificação de FMCheck quanto ao contexto avaliado. Quanto às categorias de defeitos, observou-se que FMCheck contribuiu, principalmente, para a detecção de mais omissões, fatos incorretos e ambiguidades.
Figura 5. Quantidade de defeitos distintos detectados em ambas as rodadas de inspeção e defeitos distintos detectados apenas em cada uma das rodadas.
10) Ameaças à validade do Estudo
Como ameaças à validade deste estudo, destacam-se a pequena quantidade de participantes e a limitação de domínios inspecionados. A avaliação estatística por grupos, por exemplo, foi expressivamente limitada. Além disto, a pequena quantidade de participantes também limitou a combinação de grupos e rodadas de inspeção, podendo causar algum viés. Entretanto, é importante ressaltar que nenhum participante inspecionou um mesmo domínio mais de uma vez.
A inexistência de uma lista prévia de defeitos conhecidos também pode ser considerada uma ameaça à validade, afetando diretamente o cálculo da cobertura das inspeções. Foram considerados como defeitos conhecidos apenas os defeitos distintos que foram detectados em ambas as rodadas. É importante ressaltar também que este estudo in vitro foi realizado de modo assíncrono, sem o controle de variáveis do ambiente. Desta forma, é possível que os recursos utilizados pelos participantes para realizar suas inspeções (tamanho da tela, artefatos impressos) possam ter influenciado positiva ou negativamente nos resultados do estudo.
V. PROPOSTA PARA CONDUÇÃO DE TRABALHOS FUTUROS Como proposta de trabalhos futuros, além da evolução de FMCheck com base nas conclusões do estudo experimental, consideramos também relevante para a melhoria dos resultados a elaboração de uma ferramenta que integre a realização das inspeções ao ambiente de elaboração do feature model, como pretendemos realizar no ambiente Odyssey [31], de modo a facilitar a interação dos inspetores com os modelos inspecionados e também com a técnica.
Outro trabalho futuro relevante ao contexto da inspeção de feature models diz respeito ao aprimoramento da verificação da descrição textual do domínio que serve como referência de
comparação para a extensão da técnica de leitura baseada em perspectiva (PBR) [11], incluindo a perspectiva do analista de domínio.
VI. CONCLUSÕES
Este trabalho apresentou FMCheck, uma técnica baseada em checklist para apoiar inspetores na detecção de defeitos de feature models. Esta técnica foi elaborada com o intuito de contribuir para a garantia da qualidade semântica de linhas de produtos de software e o seu processo de desenvolvimento voltado para reúso, auxiliando na detecção preventiva de defeitos semânticos desde a fase de análise de domínio.
Embora a técnica de inspeção proposta abranja a verificação de recursos de feature models previstos apenas em algumas extensões da notação original, como no caso de Odyssey-FEX, a técnica permite também que o checklist seja previamente configurado, evitando o retrabalho do inspetor com itens de verificação desnecessários ao contexto de modelagem de domínio adotado.
A técnica de inspeção apresentada foi submetida a uma prova de conceito e a um estudo experimental que sugerem sua viabilidade como técnica de inspeção, apresentando uma eficácia superior e uma eficiência equivalente à de inspeções ad-hoc. A análise qualitativa do estudo encontra-se em andamento e será importante para ampliar as conclusões deste primeiro estudo, bem como orientar a implementação de melhorias em FMCheck.
AGRADECIMENTOS
Agradecemos aos alunos da disciplina de Tópicos Especiais em Engenharia de Software IV em 2011, e aos alunos da disciplina de Reutilização de Software em 2012, do Programa de Engenharia de Sistemas e Computação da COPPE/UFRJ, em especial à colaboração do aluno Marcelo Palmieri. Agradecemos também ao pesquisador Jobson Massollar pelas suas relevantes contribuições. Profs. Werner e Travassos são pesquisadores CNPq.
REFERÊNCIAS
[1] Fagan, M. E. “Design and Code inspections to reduce errors in program development”. IBM Systems Journal 15 (3): pp. 182–211, 1976. [2] Wee Land, L.P., Tan, B.C.Y., Bin, L. “Investigating training effects on
software reviews: a controlled experiment”. Proc. of Int. Symposium on Empirical Software Engineering (ESEM) 2005, pp 344-354.
[3] Sauer, C., Jeffery, D. R., Land, L., Yetton, P. “The effectiveness of software development technical reviews: a behaviorally motivated program of research”. IEEE Transactions on Software Engineering, vol. 26 (1), pp. 1-14, 2000.
[4] McMeekin, D. A., von Konsky, B. R., R. Michael, Robey, Cooper, D. J.A. “The Significance of Participant Experience when Evaluating Software Inspection Techniques”. Proceedings of Australian Software Engineering Conference, 2009.
[5] Walia, G. S., Carver, J. C. “Evaluation of Capture-Recapture Models for Estimating the Abundance of Naturally-Occurring Defects”. Proc. of Int. Symp. on Empirical Software Engineering (ESEM) 2008, pp 158-167. [6] Kalinwoski, M., Travassos, G. H. “ISPIS: A Framework Supporting
Software Inspection Process. Proceedings of 19th International Conference on Automated Software Engineering . IEEE, 2004. [7] Petersson, H. Supporting Software Inspections through Fault Content
Estimation and Effectiveness Analysis. Technical report 147, Department of Communication Systems, Lund Institute of Technology. Lund University, 2002.
[8] Barcelos, R. F. e Travassos, G. H. “ArqCheck: Uma Abordagem para inspeção de documentos arquiteturais baseada em checklist”. V SBQS, 2006.
[9] de Mello, R. M., Massollar, J. L., Travassos. G. H., “Técnica de Inspeção Baseada em Checklist para Identificação de Defeitos em Diagramas de Atividades”. XX SBQS, 2011.
[10] Travassos, G. H., Shull, F., Fredericks, M, Basili, V.R. “Detecting Defects in Object-Oriented Designs: Using Reading Techniques to Increase Software Quality” Proc. of OOPSLA’99, 1999.
[11] Shull, F., Rus I., Basili, V. “How Perspective-Based Reading can Improve Requirements Inspections”, IEEE Software, 2000,
[12] Vasconcelos, A. e Werner, C. “Architecture Recovery and Evaluation Aiming at Program Understanding and Reuse”. QoSA 2007, LNCS 4880, pp. 72-89, 2007.
[13] Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., Peterson, A. S. “Feature-Oriented Domain Analysis (FODA) Feasibility Study”. Technical Report CMU/SEI-90-TR-21/ ESD-90-TR-222, 1990. [14] Oliveira, R. F., “Formalização e Verificação de Consistência na
Representação de Variabilidades”, Dissertação de M.Sc., COPPE Sistemas, UFRJ, Rio de Janeiro, 2006.
[15] von der Massen, T; Lichter H. “RequiLine: A Requirements Engineering Tool for Software Product Lines”. LNCS 3014, pp. 168– 180, 2004.
[16] Salinesi, C., Rolland, C., Mazo, R. “Vmware: Tool support for automatic verification of structural and semantic correctness in product line models”. Proceedings of Third Int. Workshop on Variability Modelling of Software-intensive Systems, pp. 173–176, 2009.
[17] Sun, J., Zhang, H., Li, Y., Wang, H. “Formal semantics and verification for feature modeling”. Proceedings of ICECSS, 2005.
[18] Benavides, D., Segura, S., Ruiz-Cortés, A. “Automated Analysis of Feature Models 20 Years Later: A Literature Review”. Information Systems, vol. 35(6), pp. 615-636, 2010.
[19] Riebisch, M., Böllert, K., Streitferdt, D., et al., "Extending Feature Diagrams with UML Multiplicities". In: Proceedings of 6th Conference on Integrated Design & Process Technology, pp. 1-7, Pasadena, California, USA, June, 2002
[20] Cechticky, V., Pasetti, A., Rohlik, O., et al., "XML-based feature modelling". In: Software Reuse: Methods, Techniques and Tools, 8th International Conference, ICSR, Proceedings, v. 3107, pp. 101–114, Madrid, Spain, July, 2004.
[21] Czarnecki, K., Helsen, S., Eisenecker, U., “Staged Configuration using feature models”. In: Software Product Lines: Third Internacional Conference, SPLC 2004, Proceedings, v. 3154, pp. 266-283, Boston, MA, USA, August 30-September 2, 2004.
[22] Czarnecki, K., Helsen, S., Eisenecker, U.W., “Formalizing cardinality based feature models and their specialization”, Software Process: Improvement and Practice, v.10, n.1 (March), pp. 7-29, 2005.
[23] Gomaa, H. A., Shin, M. E. B., “Automated Software Product Line Engineering and Product Derivation”. Proceedings of the 40th Hawaii International Conference on System Sciences, 2007.
[24] Griss, M.L., Favaro, J., D'Alessandro, M., “Integrating feature modelling with the RSEB”. In: Proceedings of Fifth International Conference on Softwre Reuse – ICSR5, pp. 76-85. Victoria, British Columbia, Canada, 1998.
[25] Kang, K.C., Lee, J., Donohoe, P., “Feature – Oriented Product Line Engineering”, IEEE Software, v.9, n.4 (Jul/August 2002), pp 58-65. [26] Lee, K., Kang, K.C., Lee, J., "Concepts and Guidelines of Feature
Modeling for Product Line Software Engineering". In: Software Reuse: Methods, Techniques, and Tools : 7th International Conference, ICSR-7, Proceedings pp. 62 - 77, Austin, TX, USA, April, 2002.
[27] Teixeira, E., Vasconcelos, A., Werner, C., “An Approach to Support a Flexible Feature Modeling”. III SBCARS, Natal, pp. 81-94, 2009, [28] de Mello, R. M., Pereira, W. M., Travassos, G. H. “Activity Diagram
Inspection on Requirements Specification”. XXIV Simpósio Brasileiro de Engenharia de Software, 2010.
[29] Travassos, G. H. in Rocha, A. R. C., Maldonado, J. C., Weber, K. C., “Qualidade de Software- Teoria e Prática,”. Prentice Hall, 2001. [30] OMG. “OMG Unified Modeling Language (OMG UML),
Superstructure- Version 2.2,” disponível em:
http://www.omg.org/spec/UML/2.2/Superstructure., 2009.
[31] Werner, C. M. L., Mattoso, M., Braga, R, "Odyssey: Infraestrutura de Reutilização Baseada em Modelos de Domínio". In: Seção de Ferramentas do XIII SBES, pp. 17-20. Outubro de 1999.
