Uma ferramenta para rastreabilidade de core assets em linha de produtos de software

Anderson Fonseca e Silva1, Vinicius Cardoso Garcia2

1Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R. EDU

2Centro de Informática – Universidade Federal de Pernambucoanderson.fonseka@gmail.com, vcg@cin.ufpe.br

Abstract. The domain analysis process is used to document common and variable features in a specific domain for Software Product Lines. This work presents a CASE tool for Software Product Line support, aiming to keep traceability between features and core assets such as requirements, components and others. Besides, the tool provides resources for domain analysis models with multiple viewpoints and confidence to analyze impacts, in an overall SPL developed by a software engineer, through a traceability matrix.

Resumo. O processo de análise de domínio é utilizado para documentar as características comuns e variáveis de um domínio específico para Linha de Produtos de Software (LPS). Esse trabalho apresenta uma ferramenta CASE para auxiliar nas atividades de engenharia de uma LPS, permitindo manter a rastreabilidade entre características e os artefatos de software (i.e. requisitos, componentes, entre outros). Além de fornecer recursos de múltiplas visões para os modelos da análise de domínio, proporcionando confiabilidade na análise de impactos sobre uma LPS, projetada pelo engenheiro de software, através de uma matriz de rastreabilidade.

1. Introdução

Pohl et al. (2005) indicam a construção de Linha de Produtos de Software (LPS) como uma maneira de se produzir software de forma mais eficiente e com menores custos. Uma LPS, consiste em uma base de ativos (i.e. requisitos, análise e projeto, código-fonte, entre outros) com uma abordagem focada na produção de uma plataforma comum e de customização em massa.

Os métodos e técnicas de uma LPS, conforme Clements (2002), possuem como objetivo a criação de famílias de sistemas de software, demandando alta qualidade e produtividade. Uma família de sistemas, conforme Parnas (1976), é um conjunto de pro-gramas que compartilham funcionalidades em comum, mantendo funcionalidades espe-cíficas que podem variar de acordo com as especificações do sistema.

Davis (1987), Pine II (1993) e Piller (2004) definem Customização em Massa (CM) como a produção em massa de bens e serviços que atendam aos anseios específi-cos de cada cliente, individualmente, com custos semelhantes aos dos produtos não cus-tomizados. Uma Plataforma de Software (PS), pode ser definida como qualquer base tecnológica onde outras tecnologias ou processos são construídos. A associação entre esses dois conceitos: CM e PS, permite que produtos similares e suas derivações, caracterizem o conceito de Engenharia de Linha de Produtos de Software.

Para Pohl et al. (2005) e Eisenecker (2000), a Engenharia de Linha de Produtos de Software é tipicamente organizada em termos de dois principais processos: engenha-ria de domínio e engenharia de aplicação.

Na engenharia de domínio é estabelecida uma plataforma reutilizável, definindo as partes comuns e variáveis de um produto de software através do conceito de features1 definido por Kang et al. (1990), que estabelece um método onde o usuário identifica o que normalmente se espera em uma aplicação de um determinado domínio.

A engenharia de aplicação permite a derivação de produtos a partir das defini-ções estabelecidas pela plataforma criada no processo de engenharia de domínio, explo-rando as variações da LPS e garantindo o vínculo correto entre as variações e as necessi-dades especificas da aplicação.

Para a garantia do vínculo entre a engenharia de domínio e a engenharia de apli -cação, é importante entender o conceito de rastreabilidade definido pelo IEEE Standard Glossary of Software Engineering Terminology (1990), como o grau com o qual um re-lacionamento pode ser estabelecido entre dois ou mais produtos de um processo de de-senvolvimento.

Segundo Lisboa (2010), é importante a utilização de ferramentas que forneçam o suporte ao analista de domínio para o gerenciamento e a representação das features, e que a ausência de produtos integrados, força o uso de ferramentas independentes para a execução de tais atividades, causando um aumento no risco de problemas, como delays, degradação de produtividade e interoperabilidade durante a execução do processo.

Este artigo apresenta a Fit2Mapping, uma ferramenta para auxiliar analistas de domínio e engenheiros de software no projeto e modelagem de artefatos inerentes a uma LPS e de diagramas UML [OMG 2003], permitindo associar tais artefatos, possibilitando a identificação de impactos e o grau de rastreabilidade entre tais relações. No restante desse artigo, as seções estão definidas da seguinte forma: Seção 2, descreve o estado da arte, com conceitos sobre LPS, tipos de variabilidade, rastreabilidade e trabalhos relacionados, com um comparativo entre quatro ferramentas, suas características e gaps que motivaram a construção da Fit2Mapping; na Seção 3, a apresentação da ferramenta Fit2Mapping, sua arquitetura, principais funcionalidades e uma validação inicial; na Seção 4, são descritas as considerações finais e os trabalhos futuros.

1.1. Caracterização do problema

Com base na pesquisa apresentada por Lisboa (2010), as ferramentas de análise de do-mínio estudadas, demonstraram uma ausência com relação ao mapeamento entre features e os artefatos que constituem a aplicação gerada. Segundo Czarnecki (2005), a utilização de um modelo de features embora apresente as características comuns e variáveis de uma LPS, representadas em um modelo, se tornam meramente símbolos, e que mapear features para outros modelos como especificação de comportamento ou dados, dá-lhe a semântica necessária. Diante desse contexto, surgem como problemática os itens des-critos abaixo:

• Como mapear as features identificadas na análise do domínio de uma LPS com os outros artefatos de software projetados?

• Como um usuário poderá efetivamente modelar um determinado domínio e, em seguida gerar o produto por meio da engenharia de aplicação, tendo a vi-são de quais core assets irão compor o software gerado?

1 Será utilizado o termo feature ao invés de característica no decorrer deste artigo.

• Como trabalhar modelos de features com um tamanho considerável em dia-gramas separados?

1.2. Objetivos

Como principal objetivo do trabalho, foi desenvolvida uma solução/ferramenta, para auxiliar o engenheiro de software a documentar e manter a rastreabilidade entre features e os demais artefatos de apoio ao desenvolvimento de uma LPS, especificamente nas atividades de engenharia de domínio e configuração do produto, de forma a possibilitar ganhos de produtividade. Como objetivos específicos destacaram-se:

• A disponibilização para a comunidade de uma ferramenta de análise de domínio que permite auxiliar o engenheiro de software no projeto e no relacionamento entre features e artefatos de software.

• Análise de mercado (estado da prática) e da literatura (estado da arte) das ferramentas existentes, de forma a especificar uma solução efetiva para documentar e manter a rastreabilidade entre features, e demais artefatos na engenharia de linha de produtos de software.

1.3. Justificativa

O desenvolvimento desse trabalho justificou-se pela escassez de ferramentas no mercado que permitam uma redução de riscos e de erros nas atividades desempenhadas pelo analista de domínio e pelo engenheiro de software, por meio de um ambiente integrado para a modelagem e a rastreabilidade dos elementos, inerentes ao projeto de uma LPS, que parte da engenharia de domínio até a configuração do produto, permitindo uma visualização dos artefatos e seus relacionamentos.

1.4. Contribuições

Como principal contribuição do trabalho, podemos destacar a especificação, projeto, construção e disponibilização sob a licença MIT2 de uma ferramenta de rastreabilidade de core assets3 de uma LPS que permite:

• Modelar features, possibilitando a segmentação dos modelos e uma consequente melhoria na visualização dos diagramas por meio do suporte a múltiplas visões;

• Rastrear as features identificadas na análise de domínio e os core assets projetados nos diagramas de requisitos e de análise e projeto (i.e. diagrama de componentes, diagrama de classes, dentre outros), visualizadas de forma intuitíva através de diagramas de mapeamento e/ou uma matriz de rastreabilidade textual;

• Documentar e compartilhar requisitos, cenários e passos através da modelagem de um diagrama de especificação de requisitos.

1.5. Metodologia

Este estudo caracterizou-se através de pesquisa em artigos e livros, tecnologias, compo-nentes, ambiente de execução, ferramentas e técnicas para a construção de um produto de software executável. A Tabela 1, descreve os itens pesquisados e sua justificativa.

2 http://www.opensource.org/licenses/mit-license.php3 Será utilizado o termo core assets ao invés de itens/ativos de software no decorrer deste artigo.

Tabela 1. Atividades metodológicas

Itens pesquisados Justificativa

Artigos e Livros Embasamento na construção de linha de produtos de software, através do trabalho e relato de casos reais de pesquisadores e profissionais citados nas referências biblio-gráficas.

Tecnologias & Componentes Selecionar tecnologias e componentes para o desenvolvimento e suporte à construção do produto, descritos na seção 3.1 deste artigo, na forma de software livre, não conferindo custo na aquisição.

Ambiente de execução Validação entre a disponibilização para a execução da ferramenta em um ambiente standalone ou web.

Ferramentas Utilizadas como apoio na documentação e suporte ao produto (editor de texto, editor de imagens, ferramenta de modelagem UML).

2. Estado da Arte

2.1. Linha de Produtos de Software

Segundo Nortrop (2008), uma linha de produtos de software é um conjunto de sistemas, que compartilham características em comum, satisfazendo necessidades específicas de um segmento de mercado em particular ou missão, e que é desenvolvida a partir de um grupo de core assets, de forma prescrita.

Para Nortrop (2008), as motivações principais para a adoção de linha de produtos são: alcançar ganhos de produtividade em larga escala, melhorar o time-to-market, manter presença de mercado, melhorar a qualidade do produto, lidar com evolução e complexidade, e obter maior agilidade de mercado. Para Eisenecker (2000), uma Engenharia de LPS é tipicamente organizada em termos de dois principais processos: engenharia de domínio e engenharia de aplicação.

2.1.1. Engenharia de domínio

Para Pohl et al. (2005), a engenharia de domínio é o processo no qual as partes comuns e variáveis de uma linha de produtos são definidas. A plataforma reutilizável definida pela engenharia de domínio, consiste de todos os tipos de artefatos de software (especificação de requisitos, diagramas de análise e projeto, código-fonte, roteiro de testes, dentre outros) onde a rastreabilidade deve ligá-los fornecendo um reuso sistemático e consistente.

Os principais focos na engenharia de domínio segundo Pohl et al. (2005) são:

• Escopo, especificação e modelagem das features comuns e variáveis de uma LPS;

• Definição de uma arquitetura flexível que compreende as features comuns e variáveis;

• A produção de um conjunto de core assets (frameworks, componentes, bibliotecas e aspectos) que são aderentes a arquitetura de uma LPS.

2.1.1.1. Feature-Oriented Domain Analysis (FODA)

Kang et al. (1990) definem a Feature-Oriented Domain Analysis (FODA), como uma técnica utilizada para a análise de domínio. O conceito de orientação a features estabele-ce um método, onde o usuário identifica, o que normalmente se espera em uma aplicação de um determinado domínio.

Sochos et al. (2004) resumem as features como um meio de:

• Modelar grandes domínios;

• Gerenciar variabilidades de produtos em uma LP;

• Encapsular as necessidades descritas nos requisitos;

• Guiar decisões de mercado;

• Orientar planejamentos futuros;

• Facilitar a comunicação entre os envolvidos no sistema.

A FODA prevê a modelagem de features para a identificação de partes comuns e variáveis de um produto, com o objetivo de capturar o entendimento dos usuários finais e clientes a respeito das capacidades gerais de aplicações em um domínio. Esse modelo prevê o agrupamento lógico de funcionalidades de mesmo interesse, podendo gerar rela-cionamentos obrigatórios, alternativos ou opcionais.

A Figura 1, apresenta um modelo de features para o domínio de carros, tratando a seleção de features alternativas para o sistema de transmissão de um veículo, podendo este ser automático ou manual. Esse mesmo modelo ainda apresenta como opção a sele-ção de ar condicionado para o veículo, sendo esta feature algo opcional.

Figura 1. Modelo de features proposto pela FODA [Kang et al. 1990].

Dentro do contexto de análise de domínio orientado a features, Kang et al. (1990) desenvolveram o método FORM [Kang et al. 1998] que procura as partes comuns e as diferenças das aplicações em termos de features, utilizando os resultados para a análise e desenvolvimento da arquitetura de domínio e de seus componentes. O FORM, segundo Sochos et al. (2004), tenta fornecer um mapeamento entre features e componentes arquiteturais, porém não fornece uma descrição concreta do processo mencionado, fornecendo apenas a implementação do processo definido pela FODA.

Embora a FODA seja utilizada como base para a maioria das metodologias ado-tadas com orientação a features, Sochos et al. (2004) destacam que juntamente com o FORM, ainda permanecem vagos com relação ao mapeamento entre features e os ele-mentos arquiteturais, pois a FODA possui o foco na modelagem do domínio e o FORM não possui uma descrição concreta de tal processo com um suporte explícito, orientando a elaboração da arquitetura de acordo com o modelo de features.

2.1.1.2. Notação estendida baseada em cardinalidades

Czarnecki (2005) indica que desde o surgimento da FODA como notação para a mode-lagem de features, diversas extensões e variações foram propostas, dentre elas, são apresentadas três extensões, conforme a Tabela 2. Em sua tese, Czarnecki (1998) introduz na notação prescrita pela FODA, além das features mandatórias, alternativas e opcionais, a or-feature que pode ser combinada com features alternativas.

Tabela 2. Extensões conceituais da notação FODA

Extensões DescriçãoFeature cardinalities Features são anotadas com cardinalidades,

como [1..*] ou [3..3]. [Czarnecki et al., 2002].

Groups and group cardinalities Features alternativas na notação FODA podem ser vistas como mecanismos de agrupamentos. Czarnecki (1998) em sua tese, propôs dois tipos de grupos: inclusive-or group e inclusive-or group com subfeatures opcionais.

Modularization Um diagrama de features pode conter um ou mais nós especiais, que representam diagramas de features separados [Bednasch, 2002]. Este mecanismo permite a quebra de grandes diagramas em diagramas menores, reutilizando partes comuns em diversos locais.

A Figura 2, apresenta a notação baseada em cardinalidades proposta por Czarnecki (2002) com os tipos: mandatory, optional subfeatures e group with cardinality (1-1, 1-k e 0-1).

Figura 2. Notação beasada em cardinalidades [Czarnecki 1998].

Certamente que a utilização da modelagem de features baseada em cardinalida-des permite expressar vários grupos de features e features adicionais, de uma forma em que não é possível conseguir com a notação estendida ou notação FODA. Porém, Czarnecki (2002) indica a utilização da notação estendida sempre que possível para efeito de legibilidade.

2.1.2. Engenharia de Aplicação

A engenharia de aplicação permite a derivação de produtos a partir das definições esta-belecidas pela plataforma criada na processo de engenharia de domínio, explorando as variações da LPS e garantindo o vínculo correto entre as variações e as necessidades especificas da aplicação.

Os principais focos na engenharia de aplicação segundo Pohl et al. (2005) são:

• Obter o mais alto grau possível de reutilização de componentes e explorar as partes comuns e variáveis da LPS durante a criação da linha de aplicações;

• Documentar os artefatos da aplicação (casos de uso e código-fonte) vin-culando-os aos artefatos de domínio (features, requisitos de LP, dentre outros);

• Vincular as variações de acordo com as necessidades da aplicação, dos requisitos até a arquitetura, para componentes e casos de testes.

2.2. Variabilidade

A variabilidade significa inconstância, e uma possível forma de gerenciamento dessa variabilidade é definido por Pohl et al. (2005), como uma das propriedades chave para distinguir uma engenharia de linha de produtos de software, do desenvolvimento de sistemas únicos e reuso de software. As subseções seguintes, apresentam os modelos de variabilidades existentes na literatura e que compõem uma parte essencial na composição de uma LPS.

2.2.1. Modelo de variabilidade utilizando UML

O modelo de variabilidade utilizando UML é proposto por Claub (2001), onde são utilizados mecanismos de extensões e objetiva tornar-se parte da UML através de profi-les, propondo a introdução de três extensões: uma para o modelo de features e duas me-nores para a modelagem de variabilidade. A extensão voltada para a modelagem de fea-tures é uma tentativa de se criar diagrama de features dentro da UML, fornecendo uma maneira sistemática na organização de variabilidades de um grupo de sistemas de software.

A segunda extensão compreende a representação explícita de pontos de variação – alternativas - na análise e projeto do software, e a terceira, compreende elementos op-cionais onde os pontos de variações não podem ser utilizados ou não são aplicáveis.

2.2.2. Modelo de variabilidade conceitual

O modelo de variabilidade conceitual proposto por Berg (2005), objetiva a rastreabili -dade entre dois artefatos desenvolvidos durante as várias fases da engenharia de softwa-re. São utilizados nesse modelo os conceitos de espaço-problema e espaço-solução in-troduzidos por Czarnecki e Eisenecker (2000), onde o espaço-problema refere-se às es-pecificações do sistema estabelecidas durante a análise de domínio e a fase de engenha-ria de requisitos, enquanto que o espaço-solução refere-se aos sistemas concretos cria-dos durante as fases de arquitetura, projeto e implementação.

A preocupação principal deste modelo é o mapeamento entre os artefatos defini-dos nos espaços problema e solução, estruturando as informações dos principais pontos de variação individualmente para cada artefato genérico, com seus relacionamentos e

dependências, fornecendo um mapeamento entre os artefatos definidos nas duas di-mensões.

2.2.3. Modelo de variabilidade ortogonal (MVO)

Pohl et al. (2005) conceituam o modelo de variabilidade ortogonal como um modelo que define a variabilidade de um produto de software, relacionando os modelos definidos em outros modelos de desenvolvimento de software, como por exemplo, modelos de features, modelos de casos de uso, modelos de classes, modelos de componentes e mo-delos de testes.

A justificativa para a criação desse modelo segundo Bühne et al. (2004), é que o modelo de features é insuficiente para representar variabilidade nos requisitos de uma LP. Os ganhos com essa abordagem é a redução do tamanho do modelo e da complexi-dade devido a somente um aspecto de variação ser documentado no modelo ortogonal.

A Figura 3, representa a associação entre o modelo de variabilidade ortogonal e os diversos artefatos inerentes ao desenvolvimento de um produto de software.

Figura 3. Relacionando variantes e artefatos de desenvolvimento [Pohl et al. 2005].

Pohl et al. (2005) indicam que ferramentas para fornecem suporte ao MVO ainda permanecem um desafio de pesquisa, porém, aponta o projeto PRIME4, que possui como foco o desenvolvimento de uma ferramenta para o gerenciamento de variabilidades, como uma opção.

Para a construção da ferramenta apresentada neste artigo, foram seguidas as definições propostas por Pohl et al. (2005), em função da utilização do modelo de variabilidade ortogonal (MVO) relacionado à modelagem das features.

2.3. Rastreabilidade

Gotel e Finkelstein (1994) definem rastreabilidade de requisitos como a habilida-de de descrever e seguir o ciclo de vida de um requisito em ambas as direções, como por exemplo, sua origem através de seu desenvolvimento e sua especificação até a subse-quente implantação e uso, através de sucessivos refinamentos e iterações em qualquer dessas fases.

Os stakeholders do projeto possuem diferentes objetivos de rastreabilidade e, se-gundo Stehle (1990), a perspectiva do gerente de projetos é que a rastreabilidade dê su-porte a forma como cada requisito é satisfeito pelos componentes do sistema. Do ponto de vista do gerente de requisitos, a rastreabilidade facilita a ligação entre os requisitos e suas origens e razões, capturando as informações necessárias para o entendimento e evo-

4 www.software-productline.com/SEGOS-VM-Tool/

lução dos requisitos, verificando a adequação destes. Edwards e Howell (1991) indicam que durante o projeto, a rastreabilidade permite que projetistas consigam manter o mapeamento entre o que acontece quando uma solicitação de mudança é implementada antes que o sistema seja reprojetado.

Dessa forma, Aizenbud-Reshef et al. (2006) afirmam que com uma rastreabili -dade completa é possível obter uma estimativa de custos e uma previsão de mudanças mais precisa, sem depender do conhecimento do programador em todas as áreas em que serão afetadas por essas modificações. As ferramentas automatizadas de suporte para rastreabilidade, começaram como processadores de texto, planilhas e sistema de banco de dados e que se tornaram mais fáceis com o advento de tecnologias de hipertexto. Po-rém a maior desvantagem desse método permanecia: as informações de rastreabilidade criadas e mantidas de forma manual, com o objetivo de gerenciar e validar as mudanças, se tornavam desatualizadas à medida que o software evoluía.

Com o passar do tempo surgiram ferramentas de propósitos específicos como IBM RequisitePro [IBM 2011] e o Telelogic DOORS [IBM 2005], que introduziram soluções de rastreabilidade mais avançadas, com suporte ao gerenciamento de informações, validando e monitorando as mudanças dos elementos mapeados e indicando ligações suspeitas. Essas ferramentas também possuem integração com outras ferramentas para facilitar a rastreabilidade dos requisitos a outros produtos do ciclo de vida de um software. Porém, mesmo com esses avanços, o trabalho de rastreabilidade ainda permanece manual devido às informações sobre os requisitos permanecerem expressos em forma de texto informal, necessitando do entendimento humano para validar as ligações. Com isso, a maioria das ferramentas não fornecem ricos esquemas de rastreabilidade, permitindo somente rastrear artefatos de forma simples.

2.4. Trabalhos Relacionados

Nessa seção serão apresentadas quatro ferramentas, selecionadas de acordo com os seguintes critérios:

• O contexto do processo de engenharia de domínio e a modelagem de features;

• A proposta de um metamodelo que prevê a rastreabilidade entre os modelos resultantes da análise de domínio e artefatos como requisitos, código-fonte, dentre outros;

• A utilização da notação baseada em cardinalidades, descrita na seção 2.1.1.2 deste artigo.

O estudo apresentado por Lisboa (2010), no item Relacionamento entre features e requisitos, identificou quatro ferramentas, sendo elas: Doors Extension [Buhne et al. 2005], DREAM [Park et al. 2004], Odyssey [Braga et al. 1999], PLUSS Toolkit [Eriksson et al. 2006] e RequiLine [Rwth 2005]. Porém, para a composição dessa seção, foram selecionadas apenas duas ferramentas: PLUSS Toolkit e RequiLine, por disponibilizarem a documentação e/ou o produto para a avaliação, e, acrescida por mais duas: pure::variants [GmbH 2009] e FeaturePlugin [Fmp 2011].

2.4.1. PLUSS Toolkit

É um conjunto de extensões para o Telelogic DOORS e o IBM-Rational Rose [IBM 2001] desenvolvidos em 2005 pela Umes University e Land SystemsHSgglunds, ambas da Suécia. A abordagem adotada pela PLUSS Toolkit foca no mapeamento entre features e casos de uso, e neste contexto são utilizados uma notação de fluxo de eventos para a

descrição de cenários e realizações de casos de uso. O objetivo dessa abordagem foi a utilização de uma linguagem natural, permitindo o interesse de uma maior diversidade de stakeholders nos modelos e que não descarta a utilização de diagramas UML como suplemento para um melhor entendimento quando necessário.

A PLUSS Toolkit indica que um conjunto de features compõe um pacote de casos de uso. Dessa forma é possível visualizar variações dentro das especificações de casos de uso utilizando o modelo de features. A Figura 4, apresenta o metamodelo onde é possível identificar as relações entre a feature, casos de uso, cenários e passos.

Figura 4. O metamodelo do PLUSS Toolkit [Eriksson et al. 2006].

A Figura 4, descreve como os casos de uso, cenários e passos são incluidos atra-vés da seleção de features. Apresentando também, como os casos de uso, cenários e pas-sos incluidos prescrevem um conjunto de elementos de design, através da realização dos casos de uso, porém, este metamodelo não apresenta o agrupamento das features e suas cardinalidades.

As ferramentas utilizadas para o suporte foram: o Telelogic DOORS para gerenciar a família de casos de uso de sistemas conforme o metamodelo PLUSS Toolkit, e o uso do IBM-Rational Rose para o desenho das features e dos diagramas UML. Os relatórios dos modelos de domínio utilizaram o MS Word [Microsoft 2011], sendo publicados para equipe de desenvolvimento em um repositório de controle de versão.

2.4.2. RequiLine

A RequiLine, desenvolvida pelo Research Group Software Construction (RWTH), Alemanha, em 2005, tem como principais características: suporte para a modelagem de features e requisitos, gerenciamento de linhas de produto, configuração do produto e checagem de consistência, interface de consultas, gerenciamento de usuários, suporte a visões e importação e exportação de dados, porém, a ferramenta não disponibiliza o seu metamodelo para análise. O objetivo principal da ferramenta é suprir as deficiências que outras ferramentas de requisitos possuem referentes ao gerenciamento de variações e dependências.

Além da opção de geração de modelos, a RequiLine também permite a execução de consultas pré-definidas ou configuradas pelo próprio usuário para facilitar a navega-ção através das features, relacionamentos e variabilidades. Embora a notação utilizada pela RequiLine não suporte cardinalidades, a ferramenta faz checagem de consistência de modelos e possui configurações básicas para a configuração do produto.

2.4.3. pure::variants

A ferramenta desenvolvida pela GmbH, é uma versão comercial para a modelagem de features e configuração, que se baseia em dois conceitos: modelos de features e family models. As partes comuns e variáveis são elaboradas através dos modelos de features, enquanto que a modelagem dos ativos são elaborados pelo family models, onde são des-critos o software em termos de elementos arquiteturais. A pure::variants utiliza uma ár-vore de visualização mas sem cardinalidades na composição das features, permite a mo-delagem de restrições globais entre features oferecendo de forma interativa, configura-ções baseadas na linguagem Prolog. A ferramenta permite que somente um grupo alternative ou or, sejam vinculados a um mesmo elemento-pai, as cardinalidades são descritas através de expressões, a partir da Family Model Element Properties, na propriedade range. A Figura 5, apresenta o modelo de features da ferramenta.

Figura 5. Modelo de Features da pure::variants [GmbH 2009].

A Figura 5, descreve que o ProblemDomainModel, consiste de qualquer número de FeatureModel. Um FeatureModel têm no mínimo uma Feature, e pode referenciar zero ou várias subfeatures agrupadas como uma FeatureGroup. Em comparação com a Figura 4, este metamodelo possui a entidade ProblemDomainModel representando o espaço-problema introduzido por Czarnecki e Eisenecker (2000).

Sousa et al. (2010) indicam que a pure::variants inclui um sincronizador para CaliberRM [Borland 2011] e Telelogic DOORS, o que permite os desenvolvedores integrarem as funcionalidades oferecidas pelas ferramentas para gerenciamento de requisitos e rastreabilidade.

2.4.4. FeaturePlugin

A FeaturePlugin é uma ferramenta para a modelagem de features utilizando a notação baseada em cardinalidades, especializações do diagrama de features e configuração ba-seada no diagrama de features. O metamodelo do FeaturePlugin pode ser estendido para associar atributos adicionais às features, como prioridades, binding times ou estado da implementação. A Figura 6, apresenta o metamodelo do FeaturePlugin.

Figura 6. O metamodelo do FeaturePlugin [FMP 2011].

A Figura 6, mostra que é possível configurar uma sub-árvore de qualquer feature no modelo de features, neste caso, a feature referenciada e tida como a feature-raiz. Uma feature-raiz possui em suas configurações, cópias de suas sub-árvores, onde os elementos são relacionados. Neste modelo também é possível definir os ValueType (feature, float, integer, none e string) como atributos da feature. Comparando com os metamodelos apresentados, neste, não existe um enfoque em rastreabilidade (Figura 4) ou a representação do espaço-problema (Figura 5), porém apresenta a representação das cardinalidades através do elemento Node e dos atributos, utilizando o elemento TypedValue.

2.4.5. Discussão

Nas seções 2.8.1 a 2.8.4, foram apresentadas ferramentas que apoiam a engenharia de domínio e a engenharia de aplicação. A Tabela 3, apresenta um resumo das ferramentas estudadas, onde é possível identificar que as mesmas não possuem os cinco itens (agrupamento de xor-or features baseado em cardinalidades (i), segmentação do modelo de features (ii), rastreabilidade de core assets (iii), modelagem de diagramas UML (iv) e configuração do produto (v)) implementados, não oferecendo dessa forma, um ambiente integrado para as atividades de projeto de uma LPS.

Tabela 3. Resumo comparativo das ferramentas estudadas

Ferramentas Forma de dis-

tribuição

(i) (ii) (iii) (iv) (v)

PLUSS Toolkit Extensões IBM

Rational Rose,

Telelogic DOORS e MS-Word

- - Requisitos, utilizando os ambientes estendidos

Sim (IBM

Rational Rose)

-

RequiLine Standalone .NET

- - Requisitos, de forma

integrada

- Sim

pure::variants Eclipse plugin

Somente um xor ou or-group por parent-feature

- Utiliza o Caliber RM e o Telelogic

DOORS

- Sim

FeaturePlugin Eclipse plugin

Sim - - - Sim

Foram apresentados até aqui, o propósito de uma Linha de Produtos de Software e os conceitos relacionados a esta, juntamente com as engenharias de domínio e a enge-nharia de aplicação que permite a derivação de produtos com base no domínio modela-do. Também vimos os conceitos de modelagem de domínio utilizando a notação de fea-tures que tem como base a Feature-Oriented Domain Analysis (FODA), e que possui al-gumas variações que foram formuladas ao longo do tempo para contornar alguns proble-mas encontrados em projetos práticos.

Foi destacada também, a notação baseada em cardinalidades proposta por Czarnecki (2005). Algumas abordagens para a modelagem das partes comuns e variáveis de uma LPS foram verificadas, abordagens essas que vêm desde a adaptação da UML através de profiles, passando pelo modelo de variabilidade conceitual que possui como foco a rastreabilidade de assets, até o modelo de variabilidade ortogonal. Também foram apresentados os conceitos básicos de rastreabilidade utilizadas como embasamento da construção da Fit2Mapping, e um estudo sobre quatro ferramentas atualmente disponiveis no mercado, identificando suas principais características e ausências, de acordo com os itens considerados importantes na definição do projeto de uma LPS.

Dentre as ferramentas estudadas, três delas (PLUSS Toolkit, pure:variants e FeaturePlugin) disponibilizaram os seus metamodelos, sendo possível constatar que a PLUSS Toolkit (Figura 4), possui um enfoque de rastreabilidade entre features e casos de uso, onde estes se relacionam com os elementos de design; A pure:variants (Figura 5), foca no espaço-problema introduzido por Czarnecki e Eisenecker (2000) e a FeaturePlugin (Figura 6), apresenta elementos para a definição de cardinalidades e atributos em features. Sendo assim, é possível concluir que somente a PLUSS Toolkit (Figura 4), apresenta um metamodelo que prevê a rastreabilidade de features e core assets.

3. Fit2Mapping

A partir dessa seção, este artigo apresenta a especificação da Fit2Mapping, que foi de-senvolvida para suportar a modelagem das engenharias de domínio e aplicação inerentes a uma LPS, considerando os itens descritos como ausentes nas ferramentas apresentadas na Tabela 3. A ausência de integração entre as atividades de modelagem e o seu mapeamento para outros artefatos, resulta em um aumento de esforço para a elaboração de uma LPS como descrito por Lisboa (2010), e que é constatado com o uso da ferramenta PLUSS Toolkit, onde são utilizados vários aplicativos, de forma não integrada, gerando um desconforto e uma baixa produtividade para o usuário final. As seções seguintes apresentam o Padrão Arquitetural adotado, as Decisões Tecnológicas, Restrições e Funcionalidades da Fit2Mapping.

Dentro desse contexto, destacaram-se os seguintes objetivos da Fit2Mapping:

• Tornar-se uma ferramenta CASE integrada, que apoia o engenheiro de software ao projetar modelos da engenharia de domínio, através da utili-zação de features, permitindo a segmentação dos modelos e uma conse-quente melhoria na visualização, por meio do suporte a múltiplas visões da ferramenta.

• Permitir a modelagem de artefatos de requisitos, análise e design (diagra-ma de componentes, diagramas de classes, sequências e atividades), sen-do possível o rastreamento entre as features e tais artefatos, bem como sua análise através das visões disponibilizadas.

• Associar os elementos modelados aos seus respectivos componentes (có-digo-fonte), de forma em que, através do produto configurado na enge-nharia de aplicação, se torne possível a geração do build.

A Tabela 4, apresenta as principais funcionalidades da Fit2Mapping:

Tabela 4. Principais funcionalidades

Funcionalidades

Modelagem de features, permitindo a segmentação e múltiplas visões do modelo.

Modelagem de requisitos.

Diagrama de especificação de requisitos (requisitos, cenários e passos);

Reuso de cenários e passos entre requisitos.

Mapeamento entre as features e os core assets.

Visualização da matriz de rastreabilidade (mapa das associações entre features, requisitos e componentes).

Árvore de configuração do produto.

A Fit2Mapping é uma ferramenta de uso livre (gratuito), disponibilizada através de um site5, a sua forma de licenciamento é a MIT6, onde se faz somente necessário a inclusão do aviso de copyright e de permissão em todas as cópias ou parte substanciais do software.

5 http://code.google.com/p/fit2mapping/6 http://www.opensource.org/licenses/mit-license.php

3.1. Padrão Arquitetural

A ferramenta possui uma abordagem tradicional em três camadas, composta por uma in-terface gráfica do usuário (GUI), uma camada de negócios e uma camada de persistência conforme a Figura 7, que apresenta os elementos e sua relação com as camadas cor-respondentes.

Além da utilização dos componentes fornecidos pela plataforma Java como Swing e Java2D, também foram utilizados:

MigLayout7 – biblioteca para facilitar o gerenciamento de layouts dos formulári-os desenvolvidos em Swing.

IText8 – biblioteca para a geração dos arquivos em formato PDF.

FaMa-FW9 – framework para análise automatizada de modelos de features.A motivação para a utilização dessas tecnologias foi a disponibilização de forma

gratuita, e por atenderem às necessidades de implementação da ferramenta.

Figura 7. Organização das camadas

3.2. Decisões Tecnológicas

Para o desenvolvimento da ferramenta, foi selecionada a plataforma Java Standard Edi-tion versão 1.610 utilizando Swing (para a codificação das telas e formulários) e Java2D (criação dos diagramas e elementos gráficos). A Fit2Mapping tem como propósito ser uma ferramenta standalone.

Foram pesquisados dois frameworks que aceleram o desenvolvimento para parte gráfica dos modelos: o GMF11 (Graphical Modeling Framework) e o GEF12 (Java Graph Editing Framework) utilizado no ArgoUML. Porém o primeiro, se destina ao desenvol-vimento baseado em plugins dentro do Eclipse IDE, e o segundo, em função da curva de aprendizado deste e de tecnologias correlatas, também não foi selecionado.

A Tabela 5, apresenta um conjunto de atividades definidas para o projeto e codificação da ferramenta, divididas em duas partes: infraestrutura e modelagem, a primeira (infraestrutura) se preocupou com a parte sistêmica da ferramenta, fornecendo

7 http://www.miglayout.com8 http://itextpdf.com9 http://www.isa.us.es/fama/10 http://www.oracle.com/technetwork/java/javase/downloads/index.html11 http://www.eclipse.org/modeling/gmp/12 http://eclipse.org/gef

toda a base para a criação dos diagramas e elementos para a modelagem, e a segunda (modelagem), trabalhou as formas específicas de cada tipo de modelo fornecido pela ferramenta.

Tabela 5. Atividades para a construção da ferramenta

Atividades

Infraestrutura Modelagem

Elaboração dos Diagramas (Java2D) Criação dos diagrama de Features

Criação dos elementos dos diagramas (Figuras, Relações)

Criação do diagrama de Requisitos

Elaboração do Editor de Diagramas (Barra de Ferramentas, Barras de ro-lagem)

Criação do diagrama de Especifica-ção de requisitos

Criação das janelas de navegação (Domain explorer) disponibilizando recursos drag'n'drop.

Criação do diagrama de componentes

Salvar/Abrir projetos (Formato XML) Criação do diagrama de mapeamento

Árvore de configuração do produto (Seleção de Features)

Criação da Matriz de rastreabilidade

3.3. Restrições

Na versão atual, a Fit2Mapping possui algumas restrições identificadas conforme a Ta-bela 6 e que serão trabalhadas juntamente com os itens descritos na seção 4.1 (Traba-lhos Futuros).

Tabela 6. Restrições da ferramenta Fit2Mapping

Restrições

A estrutura de criação dos elementos nos diagramas possui uma implementação própria, ou seja, não utiliza algum framework gráfico como o Eclipse GMF ou o ArgoUML GEF, o que não permite a geração de arquivos no padrão XMI de forma nativa;

O diagrama de features embora siga o modelo de variabilidade ortogonal, a implementação de configuração do produto na engenharia de aplicação, ainda não resolve a questão de compartilhamento de maneira consistente.

Somente é possível relacionar features e artefatos, não sendo possível um mapeamento bidirecional ou o mapeamento somente entre os artefatos, também não é possível visualizar o mapeamento para qual feature o artefato está associado partindo deste.

Em sua versão atual, a ferramenta não implementa a validação do modelo de features, identificando a quantidade de produtos possíveis com base no domínio modelado.

O padrão de persistência atual em formato XML, não é interoperável com outras ferramentas CASE de modelagem. Porém, é possível a implementação de um parser para a leitura do arquivo de projeto.

A configuração do produto resultante da engenharia de aplicação, não está funcionando de forma efetiva, gerando o produto com base nas seleções dos usuários.

3.4. Metamodelo

A Figura 8, apresenta o metamodelo do Fit2Mapping para a realização da rastreabilidade entre as features e os artefatos.

Figura 8. Metamodelo do Fit2Mapping

Na Tabela 7, é exibido um comparativo entre os três metamodelos apresentados na seção 2.4 (Trabalhos Relacionados), apresentando as características principais identificadas em cada ferramenta, e um comparativo com o metamodelo projetado para a Fit2Mapping.

Tabela 7. Comparativo entre metamodelos

Metamodelo Modelagem de Features

Rastreabilidade group cardinalities

PLUSS Toolkit Sim Sim -

pure:variants Sim - -

FeaturePlugin Sim - Sim

Requiline13 Sim Sim -

Fit2Mapping Sim Sim Sim

De acordo com a Tabela 7, é possível concluir que o metamodelo projetado para a Fit2Mapping tomou como base os metamodelos apresentados na seção 2.4 (Trabalhos Relacionados). Os artefatos (Component, Requirement, Scenario, Step) herdam da classe Artifact, a classe Mapping é responsável por conter e controlar as associações entre os artefatos e as features. Também é possível visualizar a estrutura para a composição do modelo de features (tipos de relacionamentos, agrupamentos de features, agrupamento de relacionamentos e tipos de regras).

Por fim, o metamodelo atualmente proposto, permite o mapeamento de features e requisitos incluindo cenários e passos, e componentes em um projeto de LPS, podendo ser estendido para outros artefatos, como: classes, interfaces, dentre outros.

13 A Requiline não disponibilizou em sua documentação, o metamodelo para análise.

3.5. Funcionalidades

A Fit2Mapping utiliza os conceitos para a modelagem de features baseada na Feature-Oriented Domain Analysis (FODA) (seção 2.3) e na notação estendida baseada em car-dinalidades proposta por Czarnecki (2000) (seção 2.4), além da utilização do modelo de variabilidade ortogonal (seção 2.9) permitindo o reuso de uma feature através do relacionamento com mais de uma parent-feature, como pode ser visto na Figura 9, onde a feature sensor de estacionamento é compartilhada por mais de uma parent-feature (Europa e Ásia).

Figura 9. Compartilhamento de features

A Figura 10, apresenta o fluxo de execução para a utilização da ferramenta, onde pri -meiramente é desenvolvido o modelo de domínio, através dos diagramas de features, se-guido pela modelagem dos requisitos e sua especificação, ou pela modelagem dos com-ponentes. Após o processo de modelagem, é iniciado o processo de mapeamento entre as features e os artefatos, e que podem ser visualizados através de uma matriz de rastrea-bilidade. Após a modelagem das features é possível visualizar a árvore de configuração do produto.

Figura 10. Fluxo de execução

3.5.1. Modelar e documentar Domínio e Features

A modelagem das features e a notação estendida com cardinalidades proposta por Czarnecki (2005), são representadas de maneira hierárquica em forma de árvore, organizando as partes comuns e variáveis do domínio em níveis crescentes de detalhes. Na Fit2Mapping as features são representadas junto com os seus relacionamentos e dependências conforme a Tabela 8.

Tabela 8. Tipos de relacionamentos

Relacionamento Descrição

Mandatory A feature estará sempre presente no produto.

Optional A feature pode ou não está presente no produto.

Alternative De um conjunto de features, somente uma feature pode está presente no produto.

Or: De um conjunto de features, pelo menos uma feature deve está presente no produto.

Requires (Dependência) Obriga a inclusão da feature de destino no produto toda vez que a feature de origem é selecionada. Porém, a seleção so-mente da feature de destino, não implica na inclusão da fea-ture de origem, representando uma relação unidirecional.

Excludes(Dependência)

Não permite que ambas as features estejam no mesmo pro-duto, caracterizando uma exclusão mútua.

A Figura 11, apresenta os tipos de relacionamentos e dependências entre as fea-tures disponibilizados pela ferramenta.

Figura 11. Tipos de relacionamentos

Conforme Pohl et al. (2005), é possível que vários stakeholders estejam envolvidos nos processos dos sistemas modelados. Dessa forma, o diagrama de modelagem das features, permite a representação destes, na análise de domínio através do elemento stakeholder como apresentado na Figura 12, exemplificados como Usuários, Analista de domínio e Desenvolvedor.

Figura 12. Stakeholders no modelo de features

3.5.2. Segmentação do modelo de features

Um dos problemas encontrados nas atuais ferramentas para a modelagem de features, se relaciona a questão do tamanho dos modelos e sua navegabilidade, tornando-se necessá-rio utilizar artifícios para que não se perca o entendimento devido à quantidade de infor-mação. Dentro das extensões apresentadas na Tabela 2, a Fit2Mapping aplica o conceito de modularização apresentado por Bednasch (2002), através da segmentação do modelo de features, possibilitando aos usuários, projetar o mesmo modelo dividindo-o em outros diagramas e relacionando as features umas com as outras, para a composição da mesma árvore de configuração do produto.

A Figura 13, apresenta um exemplo, onde o diagrama de features (A), tido como o diagrama-base que contém a feature Web Portal (raiz), é segmentado em outros dia-gramas (apresentados com uma seta na cor preta), na configuração do produto, as informações aparecem todas unidas a partir dos diagramas elaborados em uma única árvore.

Figura 13. Segmentação no modelo de features

A Figura 13, demonstra que as features Additional Services e Web Server são desenvolvidas em dois diagramas subsequentes (Additional Services Diagram e Web Server Diagram).

3.5.3. Modelar e documentar requisitos

A Fit2Mapping permite a modelagem de requisitos, tal qual a modelagem de casos de uso implementados por ferramentas CASE para UML. O diagrama de modelagem permite que inicialmente sejam documentados requisitos com relações: includes, extends e a inclusão de atores (actors).

A Figura 14, apresenta o modelo de requisitos (A) onde é possível identificar que através das associações e das propriedades informadas (B), é possível visualizar a docu-mentação do requisitos (C). Algumas informações como o caso de atores do requisito, provêm da associação entre os mesmos (atores e requisitos) sem a necessidade de infor-má-los na janela de propriedades (B).

Figura 14. Modelo de requisitos

3.5.4. Modelar e documentar especificação de requisitos

A modelagem da especificação de requisitos, funciona como uma extensão da atividade descrita na Seção 3.5.3. Porém, o diferencial deste diagrama é a representação dos cenários e passos dos requisitos de forma gráfica, permitindo que estes sejam associados às features.

A Figura 15, apresenta um formato de descrição de fluxo de eventos que provêm do RUP-SE 1.1 [Rational 2003], e que tem por objetivo derivar requisitos funcionais para elementos de análise. Para a construção desse formato, a atividade se inicia com a seleção dos casos de uso arquiteturalmente significativos, sendo que para cada caso de uso escolhido, um fluxo de eventos é desenvolvido. Podemos verificar inclusive a descrição da interação entre os atores e o sistema. As respostas do sistema são black box; essa descrição não referencia os elementos arquiteturais, também podemos identificar que os passos associados às respostas possuem requisitos adicionais (BlackBox Budgeted Req.)

Figura 15. Um exemplo de realização de casos de uso proposta pelo RUP-SE [Rational 2003].

A Figura 16, exemplifica a relação entre a descrição do fluxo no RUP-SE (B) e o diagrama de especificação de requisitos (A), onde é possível também identificar as des-crições contidas nos passos através da janela de propriedades (C).

Figura 16. Especificação de requisitos

Após a modelagem da especificação dos requisitos, é possível obter de forma completa a descrição textual.

A Figura 17, apresenta uma característica da modelagem da especificação de requisitos onde os cenários e passos definidos na especificação de um requisito, podem ser compartilhados por outros requisitos, dessa forma, caso ocorra qualquer alteração, será refletida em todos os documentos referenciados.

Figura 17. Compartilhamento de cenários e passos no diagrama de especificação de requisitos

Na Figura 17, vimos que os requisitos Define Web Server (A) e Define Security Police (B), compartilham o cenário Choose Content Type (C), caso haja alguma alteração nas propriedades do cenário, a mesma será refletida na especificação de ambos os requisitos.

3.5.5. Modelar e documentar componentes

A modelagem de componentes, define quais os artefatos físicos de uma LPS serão utili-zados na engenharia de aplicação, quando selecionados pelo engenheiro para a geração do produto. A Figura 18, apresenta o componente iText-pdf e a sua janela de propriedades onde o componente é associado ao arquivo físico iText-5.0.5.jar.

Figura 18. Diagrama de componentes

3.5.6. Mapear artefatos com as features

O mapeamento entre os artefatos e features é permitido através de um diagrama de mapeamento, onde podem ser arrastados (drag'n'drop) modelos ou elementos para esse diagrama, sendo possível executar tal associação como apresentado na Figura 19, onde é apresentado o mapeamento entre features e core assets de forma intuitiva, as associações possuem o estereótipo <<mapped>>.

Figura 19. Diagrama de mapeamento

3.5.7. Analisar a matriz de rastreabilidade das features

A matriz de rastreabilidade apresenta na forma textual, as associações entre as features e os artefatos desenvolvidos como apresentado na Seção 3.4.6. A Figura 20, apresenta uma matriz onde é possível identificar as features (A) e suas associações com os Requisitos, Cenários e Passos (B) e os Componentes (C).

Figura 20. Matriz de rastreabilidade

A Fit2Mapping também permite a visualização da rastreabilidade das features de forma individual, através da aba Traceability na janela de propriedades da feature conforme apresentado na Figura 21.

Figura 21. Rastreabilidade na janela de propriedades da feature.

Na Figura 21, a feature Content (A), apresenta na janela de propriedades, aba Traceability, o seu relacionamento com o requisito Define Web Server e o cenário Choose Content Type (B).

3.6. Validação

Para validar a utilização da ferramenta, foi utilizado o paradigma GQM (Goal /Question/Metric) proposto por Basili (1992), com o planejamento definido conforme a Tabela 9.

Tabela 9. Planejamento

Objeto de estudo Fit2Mapping

Equipe de avaliação 1 Doutor-orientador e 1 mestrando

Características • Dificuldade de reunir pessoas interessadas presencialmente.• Falta de participantes com conhecimento em modelagem de features.• Participantes com conhecimento nas disciplinas de Reuso e Arquitetura de Software.• Dificuldade em se realizar um estudo de caso com empresas.

Dentro das definições para a coleta dos dados, foi elaborado um questionário com seguintes objetivos:

• Identificar o conhecimento dos usuários em análise de domínio;

• Usabilidade da ferramenta;

• Uso do módulos;

• Funcionalidade dos módulos;

• Opinião dos usuários quanto a utilidade da ferramenta.

O questionário foi enviado (de forma online) a todos os alunos da turma MPES 2010.1 do CESAR.EDU (18 alunos aproximadamente com duas semanas para o preenchimento das questões), além de outras pessoas envolvidas com análise de domínio.

Como apoio na validação da ferramenta e considerando o conhecimento das pessoas questionadas em análise de domínio para LPS, foi elaborado um guia de uso, detalhando as principais funcionalidades da ferramenta e disponibilizado um arquivo (webportal8.xml) com um projeto voltado para a construção de um Web Portal.

O WebPortal project, contém o modelo de features segmentado em diversos modelos, diagramas de: requisitos, especificação de requisitos e componentes, bem como o mapeamento das features e os artefatos, sendo possível visualizar a matriz de rastreabilidade e a árvore de configuração do produto, dessa forma foi possível subsidiar os usuários no preenchimento do questionário.

A Tabela 10, apresenta as definições para a criação do questionário de avaliação.

Tabela 10. Definições

Analisar Fit2Mapping

Com o propósito de Avaliar a ferramenta e detectar melhorias a serem implantadas.

Com relação a Sua utilidade e facilidade de uso.

Do ponto de vista de Engenheiro de Software

No contexto de Linha de produtos de software

Os resultados obtidos seguem na Tabela 11, apresentando os objetivos com os itens questionados e os resultados (positivo e negativo) em percentuais de cada item. Dentre as opiniões descritas, foram identificadas que a ferramenta “...permite a rastreabilidade de fatures e diferentes visões...”, “...é clara, sem obscuridade...”, “...que permite a associação dos artefatos de forma clara”.

Dentre os pontos negativos destacam-se que a ferramenta: “...pode apresentar visões mais ricas e relatórios customizados sobre o mapeamento.”, “apresenta falta de clareza na matriz de rastreabilidade...” e “...não permite exportação do arquivo em formato XMI”.

Tabela 11. Resultados

Objetivo (%) Positivo (%) Negativo

Conhecimento de análise de domínio

Identificar o conhecimento em análise de domínio 16,66% 83,33%

Uso da ferramenta

Dificuldade na instalação da ferramenta 0,00% 100,00%

Utilidade no guia de uso 67,00% 33,00%

Utilização do arquivo de exemplo 100,00% 0,00%

Uso dos módulos

Dificuldade na execução de alguma atividade 0,00% 100,00%

Funcionalidade dos módulos

Dificuldade no uso - Diagrama de features 33,00% 67,00%

Dificuldade no uso - Diagrama de requisitos 0,00% 100,00%

Dificuldade no uso - Diagrama de especif. dos requisitos 0,00% 100,00%

Dificuldade no uso - Diagrama de componentes 33,00% 67,00%

Dificuldade no uso - Diagrama de mapeamento 0,00% 100,00%

Clareza da matriz de rastreabilidade 67,00% 33,00%

Opinião

Utilidade no uso da ferramenta 100,00% 0,00%

4. Considerações Finais

Esse artigo apresentou uma ferramenta para auxiliar o engenheiro de software nas ativi-dades de projeto de uma LPS, que possui além das funcionalidades para a modelagem de domínio e engenharia de aplicação, recursos para a modelagem de diagramas baseados na UML [38], permitindo a associação entre features e artefatos para a geração do build através da configuração do produto na engenharia da aplicação.

As quatro ferramentas (PLUSS Toolkit, RequiLine, pure::variants, Feature-Plugin) com características em rastreabilidade que subsidiaram a construção da Fit2Mapping, permitiram uma melhor análise para a integração de dois contextos: enge-nharia de domínio e aplicação inerentes a uma LPS, com modelos UML, fornecendo a base para a criação do metamodelo da Fit2Mapping em termos de mapeamento entre features e artefatos e o agrupamento de features baseado em cardinalidades. Por fim, este trabalho apresentou uma validação da ferramenta tendo como instrumento de coleta de dados, um questionário, cujo o preenchimento foi subsidiado por um guia de uso e um projeto-piloto modelado através da ferramenta.

Do resultado desta validação, verificou-se a utilidade da ferramenta proposta, devido ao alcance satisfatório do propósito principal, no âmbito de modelagem e rastrea-bilidade de core assets, e os baixos percentuais de dificuldade na utilização dos módulos. Porém, devido a dificuldade na aplicação de um estudo de caso em empresas, torna-se necessário a aplicação de validações posteriores de acordo com a evolução da ferramenta.

De fato, o intuito desse produto é permitir a geração de builds executáveis e do-cumentação, através da configuração do produto, utilizando uma plataforma bem definida e com suporte para rastreabilidade, oferecendo ao usuário respostas quanto a quantidade de possíveis produtos, realização de validações e análise de impactos quanto a adição e/ou remoção de artefatos dentro do projeto de uma LPS.

4.1. Trabalhos Futuros

Em versões futuras, serão disponibilizadas: a geração dos arquivos em formato XMI permitindo a integração com outras ferramentas CASE, um refinamento dos modelos de requisitos e componentes existentes, adição dos diagramas de classes e sequências e seu consequente mapeamento para os modelos de domínio, e por fim, a conclusão do módulo de configuração do produto para a geração dos artefatos associados, onde os componentes vinculados fisicamente, poderão ser selecionados através de um repositório de controle de versão. Outra melhoria a ser implementada é a questão da usabilidade e a portabilidade para a plataforma web, sendo considerados requisitos como performance e controle no compartilhamento dos projetos.

Agradecimentos

A Deus, a Sandra Fonseca, minha esposa, ao meu orientador Professor Vinícius Cardoso Garcia, pela sua paciência, disponibilidade e por todo o apoio dado, aos meus amigos Flavia Cavalcanti de Oliveira, Philippe Fontes e Carlos Arthur, a equipe do MojaveIT (Filipe Monteiro, Juvenal Feitosa, Anderson Fonseca, Vlairton Vasconcelos, Sergio Endrigo e Ivonaldo Torres), Karim Hallar e a todas as pessoas que contribuíram na avaliação deste artigo e na validação da ferramenta.

Referências[1] AIZENBUD-RESHEF, N.; NOLAN, B. T.; RUBIN, J.; SHAHAM-GAFNI, Y. Model traceability. IBM Systems Journal, v. 45, n. 3, p. 515-526, 2006. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5386621>.

[2] ANTKIEWICZ, M.; CZARNECKI, K. FeaturePlugin: feature modeling plug-in for Eclipse. Proceedings of the 2004 OOPSLA workshop on eclipse technology eXchange. Anais... p.67-72, 2004. ACM. Disponível em: <http://portal.acm.org/citation.cfm?id=1066129.1066143>.

[3] BASILI, V. R. Software modeling and measurement: the Goal/Question/Metric paradigm. University of Maryland CSTR2956, 1992. University of Maryland at College Park. Disponível em: <http://129.2.17.93/drum/handle/1903/7538>.

[4] BEDNASCH, T. (2002). Konzept und Implementierung eines konfigurierbaren Metamodells f¨ur die Merkmalmodellierung, Diplomarbeit, Fachbereich Informatik und Mikrosystemtechnik, Fachhochschule Kaiserslautern, Standort Zweibr¨ucken, Germany.

[5] BERG, K.; BISHOP, J.; MUTHIG, D. Tracing software product line variability: from problem to solution space. Engineering. Anais... p.182 -191, 2005. South African Institute for Computer Scientists and Information Technologists. Disponível em: <http://portal.acm.org/ citation.cfm?id=1145675.1145695>.

[6] BORLAND, CALIBER-RM. http://www.borland.com/us/products/caliber. Acessado em: abril, 2011.

[7] BRAGA, R. M. M.; WERNER, C. M. L.; MATTOSO, M. Odyssey: A Reuse Environment based on Domain Models. Proceedings of IEEE Symposium on ApplicationSpecific Systems and Software Engineering Technology ASSET99. p.49-57, 1999. IEEE/CS Press.

[8] BUHNE, S.; LAUENROTH, K.; POHL, K. Modelling requirements variability across product lines. Requirements Engineering 2005 Proceedings 13th IEEE International Conference on. Anais... p.41-52, 2005. Ieee. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper . htm ?arnumber=1531026 >.

[9] BÜHNE, S.; LAUENROTH, K.; POHL, K. Why is it not Sufficient to Model Requirements Variability with Feature Models? Workshop on Automotive Requirements Engineering AURE04. Anais... v. 04, p.5-12, 2004. Disponível em: <http://www.sse.uni-essen.de/wms/pubs/AuRE_ca mera ready.pdf >.

[10] CLAUS, M. Modeling variability with UML. GCSE 2001 Young researchers Workshop, 2001.

[11] CLEMENTS, P.; NORTHROP, L. Software Product Lines: Practices and Patterns. Addison-Wesley, 2001.

[12] CZARNECKI, K. Generative Programming Principles and Techniques of Software Engineering Based on Automated Configuration and Fragment-Based Component Models. Department of Computer Science and Automation, 1998.

[13] CZARNECKI, K.; EISENECKER, U. W. Generative Programming: methods tools and applications. ACM Press/Addison-Wesley Publishing Co., 2000.

[14] CZARNECKI, K.; ANTKIEWICZ, M. Mapping features to models: A template approach based on superimposed variants. (R. Glück & M. Lowry, Eds.)Generative Programming and Component Engineering, v. 3676, p. 422-437, 2005. Springer. Disponível em: <http://www.springerlink.com/index/9n4uhh2gaddj5lkv.pdf>.

[15] CZARNECKI, K.; HELSEN, S.; EISENECKER, U. Staged configuration through specialization and multilevel configuration of feature models. Software Process: Improvement and Practice, v. 10, n. 2, p. 143-169, 2004. Springer. Disponível em: <http://doi.wiley.com/10.1002/spip.225>.

[16] DAVIS, S. M. From “future perfect”: Mass customizing. Strategy Leadership, v. 17, n. 2, p. 16-21, 1989. Disponível em: <http://www.emeraldinsight.com/10.1108/eb05 42 49 >.

[17] ERIKSSON, M.; MORAST, H.; BÖRSTLER, J.; BORG, K. An Empirical Evaluation of the PLUSS Toolkit Department of Computing Science An Empirical Evaluation of the PLUSS Toolkit. Management, 2006. Citeseer.

[18] FMP: Feature Modeling Plug-in. http://gsd.uwaterloo.ca/book/export/html/16, Acessado em: abril, 2011.

[19] GMBH. Pure:variants. User Manual Version 3.0. (2009). pure-systems GmbH. http://www.pure-systems.com/fileadmin/downloads/pure-variants/doc/pv-user-manual.p df , Aces sado em: abril, 2011.

[20] GOTEL, O.; FINKELSTEIN, A. An analysis of the requirements traceability problem. Proceedings of IEEE International Conference on Requirements Engineering, v. pp, p. 94-101, 1994. IEEE Computer Society Press. Disponível em: <http://eprints.ucl.ac.uk/749/>.

[21] IBM-Rational Software, http://www-306.ibm.com/software/rational/. Acessado em: fevereiro, 2011.

[22] IBM. RATIONAL ROSE. http://www-01.ibm.com/software/awdtools/developer/ro se/#. Acessado em: abril, 2011.

[23] IBM. Telelogic AB, (2005), http://www-01.ibm.com/software/rational. Acessado em: fevereiro, 2011.

[24] IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, IEEE, New York (September 1990).

[25] KANG, K. C.; COHEN, S. G.; HESS, J. A.; NOVAK, W. E.; PETERSON, A. S. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Citeseer, 1990.

[26] KANG, K. C.; KIM, S.; LEE, J.; et al. FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures. Annals of Software Engineering, v. 5, n. 1, p. 143-168, 1998. Springer. Disponível em: <http://www.springerlink.com/index/V 6901T52316R1350. Pdf>.

[27] LISBOA, L. B.; GARCIA, V. C.; LUCRÉDIO, D.; et al. A systematic review of domain analysis tools. Information and Software Technology, v. 52, n. 1, p. 1-13, 2010. Disponível em: <http://linkinghub.elsevier.com/retrieve/pii/S0950584909000834 >.

[28] MICROSOFT. WORD. http://office.microsoft.com/en-gb/word. Acessado em: abril, 2011.

[29] NORTHROP, L. Software Product Lines Essentials. Engineering, p. 85, 2008. Disponível em: <http://www.sei.cmu.edu/library/assets/spl-essentials.pdf>. Acessado em: abril, 2011.

[30] PARK, J.; MOON, M.; YEOM, K. DREAM : Domain REquirement Asset Manager in Product Lines in: International Symposium on Future Software Technology (ISFST), Xi an, China. 2004.

[31] PARNAS, D. L. On the Design and Development of Program Families. IEEE Transactions on Software Engineering, v. SE-2, n. 1, p. 1-9, 1976. IEEE Press. Disponível em: <http://ieee xplore .ieee.org /lpdocs/epic03/wrapper.htm?arnumber=1702 3 32 >.

[32] PILLER, F. T.; MOESLEIN, K.; STOTKO, C. M. Does mass customization pay? An economic approach to evaluate customer integration. Production Planning Control, v. 15, n. 4, p. 435-444, 2004. Taylor & Francis. Disponível em: <http://www.informaworld . com/ openurl ? genre=article& doi=10.1080/09537280420002 3 8773&magic=crossref >.

[33] PINE, B. J. Mass Customization: The New Frontier in Business Competition. Harvard Business School Press, 1993.

[34] POHL, K.; BÖCKLE, G.; LINDEN, F. V. D. Software product line engineering: foundations, principles, and techniques. Springer, 2005.

[35] RATIONAL. The Rational Unified Process for Systems Engineering Whitepaper,Ver.1.1 (2003), http://www.ibm.com/developerworks/rational/library/content/RationalEdge/aug03/f_rupse _mc.pdf. Acessado em: fevereiro, 2011.

[36] RWTH. RequiLine. User Manual Version 1.0, (2005) Research Group Software Construction. RWTH Aachen. http://www-lufgi3.informatik.rwth-aachen.de/TOOLS/ requiline/ Support/ documentation.php#user_manual . Acessado em: fevereiro, 2011.

[37] SOCHOS, P.; PHILIPPOW, I.; RIEBISCH, M. Feature-Oriented Development of Software Product Lines: Mapping Feature Models to the Architecture. ObjectOriented and InternetBased Technologies, v. 3263, p. 138-152, 2004. Springer. Disponível em: <http://www.springerlink.com/index/KU9JM8LCNFC6Q7GY.pdf>.

[38] SOUSA, A.; KULESZA, U.; RUMMLER, A.; et al. A Model-Driven Traceability Framework to Software Product Line Development. Software Systems Modeling, v. 9, n. i, p. 427-451-451, 2009. Springer Berlin / Heidelberg. Disponível em: <http://www . spring erlink.com /index/10.1007/s10270-009-0120-9>.

[39] STEHLE, G. Requirements Traceability for Real-Time Systems. Proceedings of the EuroCASE II. Anais... , 1990.

[40] OMG, O. M. G. Unified Modeling Language Specification. 2003. OMG. Disponível em: <http://www.omg.org/cgi-bin/doc?formal/01-09-67>. Acessado em: abril, 2011.