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

Anderson Fonseca e Silva1, Vinicius Cardoso Garcia2

1

Centro de Estudos e Sistemas Avanados do Recife C.E.S.A.R. EDU

2

Centro de Informtica Universidade Federal de Pernambuco

anderson.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 anlise de domnio utilizado para documentar as caractersticas comuns e variveis de um domnio especfico 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 caractersticas e os artefatos de software (i.e. requisitos, componentes, entre outros). Alm de fornecer recursos de mltiplas vises para os modelos da anlise de domnio, proporcionando confiabilidade na anlise de impactos sobre uma LPS, projetada pelo engenheiro de software, atravs de uma matriz de rastreabilidade.

1. Introduo
Pohl et al. (2005) indicam a construo 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, anlise e projeto, cdigo-fonte, entre outros) com uma abordagem focada na produo de uma plataforma comum e de customizao em massa. Os mtodos e tcnicas de uma LPS, conforme Clements (2002), possuem como objetivo a criao de famlias de sistemas de software, demandando alta qualidade e produtividade. Uma famlia de sistemas, conforme Parnas (1976), um conjunto de programas que compartilham funcionalidades em comum, mantendo funcionalidades especficas que podem variar de acordo com as especificaes do sistema. Davis (1987), Pine II (1993) e Piller (2004) definem Customizao em Massa (CM) como a produo em massa de bens e servios que atendam aos anseios especficos de cada cliente, individualmente, com custos semelhantes aos dos produtos no customizados. Uma Plataforma de Software (PS), pode ser definida como qualquer base tecnolgica onde outras tecnologias ou processos so construdos. A associao entre esses dois conceitos: CM e PS, permite que produtos similares e suas derivaes, 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: engenharia de domnio e engenharia de aplicao. Na engenharia de domnio estabelecida uma plataforma reutilizvel, definindo as partes comuns e variveis de um produto de software atravs do conceito de features 1 definido por Kang et al. (1990), que estabelece um mtodo onde o usurio identifica o que normalmente se espera em uma aplicao de um determinado domnio. A engenharia de aplicao permite a derivao de produtos a partir das definies estabelecidas pela plataforma criada no processo de engenharia de domnio, explorando as variaes da LPS e garantindo o vnculo correto entre as variaes e as necessidades especificas da aplicao. Para a garantia do vnculo entre a engenharia de domnio e a engenharia de apli cao, importante entender o conceito de rastreabilidade definido pelo IEEE Standard Glossary of Software Engineering Terminology (1990), como o grau com o qual um relacionamento pode ser estabelecido entre dois ou mais produtos de um processo de desenvolvimento. Segundo Lisboa (2010), importante a utilizao de ferramentas que forneam o suporte ao analista de domnio para o gerenciamento e a representao das features, e que a ausncia de produtos integrados, fora o uso de ferramentas independentes para a execuo de tais atividades, causando um aumento no risco de problemas, como delays, degradao de produtividade e interoperabilidade durante a execuo do processo. Este artigo apresenta a Fit2Mapping, uma ferramenta para auxiliar analistas de domnio 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 identificao de impactos e o grau de rastreabilidade entre tais relaes. No restante desse artigo, as sees esto definidas da seguinte forma: Seo 2, descreve o estado da arte, com conceitos sobre LPS, tipos de variabilidade, rastreabilidade e trabalhos relacionados, com um comparativo entre quatro ferramentas, suas caractersticas e gaps que motivaram a construo da Fit2Mapping; na Seo 3, a apresentao da ferramenta Fit2Mapping, sua arquitetura, principais funcionalidades e uma validao inicial; na Seo 4, so descritas as consideraes finais e os trabalhos futuros. 1.1. Caracterizao do problema Com base na pesquisa apresentada por Lisboa (2010), as ferramentas de anlise de domnio estudadas, demonstraram uma ausncia com relao ao mapeamento entre features e os artefatos que constituem a aplicao gerada. Segundo Czarnecki (2005), a utilizao de um modelo de features embora apresente as caractersticas comuns e variveis de uma LPS, representadas em um modelo, se tornam meramente smbolos, e que mapear features para outros modelos como especificao de comportamento ou dados, d-lhe a semntica necessria. Diante desse contexto, surgem como problemtica os itens descritos abaixo:

Como mapear as features identificadas na anlise do domnio de uma LPS com os outros artefatos de software projetados? Como um usurio poder efetivamente modelar um determinado domnio e, em seguida gerar o produto por meio da engenharia de aplicao, tendo a viso de quais core assets iro compor o software gerado?

1 Ser utilizado o termo feature ao invs de caracterstica no decorrer deste artigo.

Como trabalhar modelos de features com um tamanho considervel em diagramas separados?

1.2. Objetivos Como principal objetivo do trabalho, foi desenvolvida uma soluo/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 domnio e configurao do produto, de forma a possibilitar ganhos de produtividade. Como objetivos especficos destacaram-se:

A disponibilizao para a comunidade de uma ferramenta de anlise de domnio que permite auxiliar o engenheiro de software no projeto e no relacionamento entre features e artefatos de software.

Anlise de mercado (estado da prtica) e da literatura (estado da arte) das ferramentas existentes, de forma a especificar uma soluo 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 reduo de riscos e de erros nas atividades desempenhadas pelo analista de domnio 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 domnio at a configurao do produto, permitindo uma visualizao dos artefatos e seus relacionamentos. 1.4. Contribuies Como principal contribuio do trabalho, podemos destacar a especificao, projeto, construo e disponibilizao sob a licena MIT2 de uma ferramenta de rastreabilidade de core assets 3 de uma LPS que permite:

Modelar features, possibilitando a segmentao dos modelos e uma consequente melhoria na visualizao dos diagramas por meio do suporte a mltiplas vises; Rastrear as features identificadas na anlise de domnio e os core assets projetados nos diagramas de requisitos e de anlise e projeto (i.e. diagrama de componentes, diagrama de classes, dentre outros), visualizadas de forma intuitva atravs de diagramas de mapeamento e/ou uma matriz de rastreabilidade textual; Documentar e compartilhar requisitos, cenrios e passos atravs da modelagem de um diagrama de especificao de requisitos.

1.5. Metodologia Este estudo caracterizou-se atravs de pesquisa em artigos e livros, tecnologias, componentes, ambiente de execuo, ferramentas e tcnicas para a construo de um produto de software executvel. A Tabela 1, descreve os itens pesquisados e sua justificativa.

2 http://www.opensource.org/licenses/mit-license.php 3 Ser utilizado o termo core assets ao invs de itens/ativos de software no decorrer deste artigo.

Tabela 1. Atividades metodolgicas

Itens pesquisados Artigos e Livros

Justificativa Embasamento na construo de linha de produtos de software, atravs do trabalho e relato de casos reais de pesquisadores e profissionais citados nas referncias bibliogrficas. Selecionar tecnologias e componentes para o desenvolvimento e suporte construo do produto, descritos na seo 3.1 deste artigo, na forma de software livre, no conferindo custo na aquisio. Validao entre a disponibilizao para a execuo da ferramenta em um ambiente standalone ou web. Utilizadas como apoio na documentao e suporte ao produto (editor de texto, editor de imagens, ferramenta de modelagem UML).

Tecnologias & Componentes

Ambiente de execuo

Ferramentas

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 caractersticas em comum, satisfazendo necessidades especficas de um segmento de mercado em particular ou misso, e que desenvolvida a partir de um grupo de core assets, de forma prescrita. Para Nortrop (2008), as motivaes principais para a adoo de linha de produtos so: alcanar ganhos de produtividade em larga escala, melhorar o time-tomarket, manter presena de mercado, melhorar a qualidade do produto, lidar com evoluo 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 domnio e engenharia de aplicao. 2.1.1. Engenharia de domnio Para Pohl et al. (2005), a engenharia de domnio o processo no qual as partes comuns e variveis de uma linha de produtos so definidas. A plataforma reutilizvel definida pela engenharia de domnio, consiste de todos os tipos de artefatos de software (especificao de requisitos, diagramas de anlise e projeto, cdigo-fonte, roteiro de testes, dentre outros) onde a rastreabilidade deve lig-los fornecendo um reuso sistemtico e consistente. Os principais focos na engenharia de domnio segundo Pohl et al. (2005) so:

Escopo, especificao e modelagem das features comuns e variveis de uma LPS; Definio de uma arquitetura flexvel que compreende as features comuns e variveis;

A produo de um conjunto de core assets (frameworks, componentes, bibliotecas e aspectos) que so 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 tcnica utilizada para a anlise de domnio. O conceito de orientao a features estabelece um mtodo, onde o usurio identifica, o que normalmente se espera em uma aplicao de um determinado domnio. Sochos et al. (2004) resumem as features como um meio de: Modelar grandes domnios; Gerenciar variabilidades de produtos em uma LP; Encapsular as necessidades descritas nos requisitos; Guiar decises de mercado; Orientar planejamentos futuros; Facilitar a comunicao entre os envolvidos no sistema.

A FODA prev a modelagem de features para a identificao de partes comuns e variveis de um produto, com o objetivo de capturar o entendimento dos usurios finais e clientes a respeito das capacidades gerais de aplicaes em um domnio. Esse modelo prev o agrupamento lgico de funcionalidades de mesmo interesse, podendo gerar relacionamentos obrigatrios, alternativos ou opcionais. A Figura 1, apresenta um modelo de features para o domnio de carros, tratando a seleo de features alternativas para o sistema de transmisso de um veculo, podendo este ser automtico ou manual. Esse mesmo modelo ainda apresenta como opo a seleo de ar condicionado para o veculo, sendo esta feature algo opcional.

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

Dentro do contexto de anlise de domnio orientado a features, Kang et al. (1990) desenvolveram o mtodo FORM [Kang et al. 1998] que procura as partes comuns e as diferenas das aplicaes em termos de features, utilizando os resultados para a anlise e desenvolvimento da arquitetura de domnio e de seus componentes. O FORM, segundo Sochos et al. (2004), tenta fornecer um mapeamento entre features e componentes arquiteturais, porm no fornece uma descrio concreta do processo mencionado, fornecendo apenas a implementao do processo definido pela FODA.

Embora a FODA seja utilizada como base para a maioria das metodologias adotadas com orientao a features, Sochos et al. (2004) destacam que juntamente com o FORM, ainda permanecem vagos com relao ao mapeamento entre features e os elementos arquiteturais, pois a FODA possui o foco na modelagem do domnio e o FORM no possui uma descrio concreta de tal processo com um suporte explcito, orientando a elaborao da arquitetura de acordo com o modelo de features. 2.1.1.2. Notao estendida baseada em cardinalidades Czarnecki (2005) indica que desde o surgimento da FODA como notao para a modelagem de features, diversas extenses e variaes foram propostas, dentre elas, so apresentadas trs extenses, conforme a Tabela 2. Em sua tese, Czarnecki (1998) introduz na notao prescrita pela FODA, alm das features mandatrias, alternativas e opcionais, a or-feature que pode ser combinada com features alternativas.
Tabela 2. Extenses conceituais da notao FODA

Extenses
Feature cardinalities Groups and group cardinalities

Descrio
Features so anotadas com cardinalidades, como [1..*] ou [3..3]. [Czarnecki et al., 2002]. Features alternativas na notao FODA podem ser vistas como mecanismos de agrupamentos. Czarnecki (1998) em sua tese, props dois tipos de grupos: inclusive-or group e inclusive-or group com subfeatures opcionais.
Um diagrama de features pode conter um ou mais ns 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.

Modularization

A Figura 2, apresenta a notao 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. Notao beasada em cardinalidades [Czarnecki 1998].

Certamente que a utilizao da modelagem de features baseada em cardinalidades permite expressar vrios grupos de features e features adicionais, de uma forma em que no possvel conseguir com a notao estendida ou notao FODA. Porm, Czarnecki (2002) indica a utilizao da notao estendida sempre que possvel para efeito de legibilidade.

2.1.2. Engenharia de Aplicao A engenharia de aplicao permite a derivao de produtos a partir das definies estabelecidas pela plataforma criada na processo de engenharia de domnio, explorando as variaes da LPS e garantindo o vnculo correto entre as variaes e as necessidades especificas da aplicao. Os principais focos na engenharia de aplicao segundo Pohl et al. (2005) so:

Obter o mais alto grau possvel de reutilizao de componentes e explorar as partes comuns e variveis da LPS durante a criao da linha de aplicaes; Documentar os artefatos da aplicao (casos de uso e cdigo-fonte) vinculando-os aos artefatos de domnio (features, requisitos de LP, dentre outros); Vincular as variaes de acordo com as necessidades da aplicao, dos requisitos at a arquitetura, para componentes e casos de testes.

2.2. Variabilidade A variabilidade significa inconstncia, e uma possvel 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 subsees seguintes, apresentam os modelos de variabilidades existentes na literatura e que compem uma parte essencial na composio de uma LPS. 2.2.1. Modelo de variabilidade utilizando UML O modelo de variabilidade utilizando UML proposto por Claub (2001), onde so utilizados mecanismos de extenses e objetiva tornar-se parte da UML atravs de profiles, propondo a introduo de trs extenses: uma para o modelo de features e duas menores para a modelagem de variabilidade. A extenso voltada para a modelagem de features uma tentativa de se criar diagrama de features dentro da UML, fornecendo uma maneira sistemtica na organizao de variabilidades de um grupo de sistemas de software. A segunda extenso compreende a representao explcita de pontos de variao alternativas - na anlise e projeto do software, e a terceira, compreende elementos opcionais onde os pontos de variaes no podem ser utilizados ou no so aplicveis. 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 vrias fases da engenharia de software. So utilizados nesse modelo os conceitos de espao-problema e espao-soluo introduzidos por Czarnecki e Eisenecker (2000), onde o espao-problema refere-se s especificaes do sistema estabelecidas durante a anlise de domnio e a fase de engenharia de requisitos, enquanto que o espao-soluo refere-se aos sistemas concretos criados durante as fases de arquitetura, projeto e implementao. A preocupao principal deste modelo o mapeamento entre os artefatos definidos nos espaos problema e soluo, estruturando as informaes dos principais pontos de variao individualmente para cada artefato genrico, com seus relacionamentos e

dependncias, fornecendo um mapeamento entre os artefatos definidos nas duas dimenses. 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 modelos de testes. A justificativa para a criao desse modelo segundo Bhne et al. (2004), que o modelo de features insuficiente para representar variabilidade nos requisitos de uma LP. Os ganhos com essa abordagem a reduo do tamanho do modelo e da complexidade devido a somente um aspecto de variao ser documentado no modelo ortogonal. A Figura 3, representa a associao 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, porm, aponta o projeto PRIME4, que possui como foco o desenvolvimento de uma ferramenta para o gerenciamento de variabilidades, como uma opo. Para a construo da ferramenta apresentada neste artigo, foram seguidas as definies propostas por Pohl et al. (2005), em funo da utilizao do modelo de variabilidade ortogonal (MVO) relacionado modelagem das features. 2.3. Rastreabilidade Gotel e Finkelstein (1994) definem rastreabilidade de requisitos como a habilidade de descrever e seguir o ciclo de vida de um requisito em ambas as direes, como por exemplo, sua origem atravs de seu desenvolvimento e sua especificao at a subsequente implantao e uso, atravs de sucessivos refinamentos e iteraes em qualquer dessas fases. Os stakeholders do projeto possuem diferentes objetivos de rastreabilidade e, segundo Stehle (1990), a perspectiva do gerente de projetos que a rastreabilidade d suporte a forma como cada requisito satisfeito pelos componentes do sistema. Do ponto de vista do gerente de requisitos, a rastreabilidade facilita a ligao entre os requisitos e suas origens e razes, capturando as informaes necessrias para o entendimento e evo4 www.software-productline.com/SEGOS-VM-Tool/

luo dos requisitos, verificando a adequao 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 solicitao de mudana implementada antes que o sistema seja reprojetado. Dessa forma, Aizenbud-Reshef et al. (2006) afirmam que com uma rastreabili dade completa possvel obter uma estimativa de custos e uma previso de mudanas mais precisa, sem depender do conhecimento do programador em todas as reas em que sero afetadas por essas modificaes. As ferramentas automatizadas de suporte para rastreabilidade, comearam como processadores de texto, planilhas e sistema de banco de dados e que se tornaram mais fceis com o advento de tecnologias de hipertexto. Porm a maior desvantagem desse mtodo permanecia: as informaes de rastreabilidade criadas e mantidas de forma manual, com o objetivo de gerenciar e validar as mudanas, se tornavam desatualizadas medida que o software evolua. Com o passar do tempo surgiram ferramentas de propsitos especficos como IBM RequisitePro [IBM 2011] e o Telelogic DOORS [IBM 2005], que introduziram solues de rastreabilidade mais avanadas, com suporte ao gerenciamento de informaes, validando e monitorando as mudanas dos elementos mapeados e indicando ligaes suspeitas. Essas ferramentas tambm possuem integrao com outras ferramentas para facilitar a rastreabilidade dos requisitos a outros produtos do ciclo de vida de um software. Porm, mesmo com esses avanos, o trabalho de rastreabilidade ainda permanece manual devido s informaes sobre os requisitos permanecerem expressos em forma de texto informal, necessitando do entendimento humano para validar as ligaes. Com isso, a maioria das ferramentas no fornecem ricos esquemas de rastreabilidade, permitindo somente rastrear artefatos de forma simples. 2.4. Trabalhos Relacionados Nessa seo sero apresentadas quatro ferramentas, selecionadas de acordo com os seguintes critrios:

O contexto do processo de engenharia de domnio e a modelagem de features; A proposta de um metamodelo que prev a rastreabilidade entre os modelos resultantes da anlise de domnio e artefatos como requisitos, cdigo-fonte, dentre outros; A utilizao da notao baseada em cardinalidades, descrita na seo 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]. Porm, para a composio dessa seo, foram selecionadas apenas duas ferramentas: PLUSS Toolkit e RequiLine, por disponibilizarem a documentao e/ou o produto para a avaliao, e, acrescida por mais duas: pure::variants [GmbH 2009] e FeaturePlugin [Fmp 2011]. 2.4.1. PLUSS Toolkit um conjunto de extenses para o Telelogic DOORS e o IBM-Rational Rose [IBM 2001] desenvolvidos em 2005 pela Umes University e Land SystemsHSgglunds, ambas da Sucia. A abordagem adotada pela PLUSS Toolkit foca no mapeamento entre features e casos de uso, e neste contexto so utilizados uma notao de fluxo de eventos para a

descrio de cenrios e realizaes de casos de uso. O objetivo dessa abordagem foi a utilizao de uma linguagem natural, permitindo o interesse de uma maior diversidade de stakeholders nos modelos e que no descarta a utilizao de diagramas UML como suplemento para um melhor entendimento quando necessrio. A PLUSS Toolkit indica que um conjunto de features compe um pacote de casos de uso. Dessa forma possvel visualizar variaes dentro das especificaes de casos de uso utilizando o modelo de features. A Figura 4, apresenta o metamodelo onde possvel identificar as relaes entre a feature, casos de uso, cenrios e passos.

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

A Figura 4, descreve como os casos de uso, cenrios e passos so incluidos atravs da seleo de features. Apresentando tambm, como os casos de uso, cenrios e passos incluidos prescrevem um conjunto de elementos de design, atravs da realizao dos casos de uso, porm, este metamodelo no apresenta o agrupamento das features e suas cardinalidades. As ferramentas utilizadas para o suporte foram: o Telelogic DOORS para gerenciar a famlia 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 relatrios dos modelos de domnio utilizaram o MS Word [Microsoft 2011], sendo publicados para equipe de desenvolvimento em um repositrio de controle de verso. 2.4.2. RequiLine A RequiLine, desenvolvida pelo Research Group Software Construction (RWTH), Alemanha, em 2005, tem como principais caractersticas: suporte para a modelagem de features e requisitos, gerenciamento de linhas de produto, configurao do produto e checagem de consistncia, interface de consultas, gerenciamento de usurios, suporte a vises e importao e exportao de dados, porm, a ferramenta no disponibiliza o seu metamodelo para anlise. O objetivo principal da ferramenta suprir as deficincias que outras ferramentas de requisitos possuem referentes ao gerenciamento de variaes e dependncias.

Alm da opo de gerao de modelos, a RequiLine tambm permite a execuo de consultas pr-definidas ou configuradas pelo prprio usurio para facilitar a navegao atravs das features, relacionamentos e variabilidades. Embora a notao utilizada pela RequiLine no suporte cardinalidades, a ferramenta faz checagem de consistncia de modelos e possui configuraes bsicas para a configurao do produto. 2.4.3. pure::variants A ferramenta desenvolvida pela GmbH, uma verso comercial para a modelagem de features e configurao, que se baseia em dois conceitos: modelos de features e family models. As partes comuns e variveis so elaboradas atravs dos modelos de features, enquanto que a modelagem dos ativos so elaborados pelo family models, onde so descritos o software em termos de elementos arquiteturais. A pure::variants utiliza uma rvore de visualizao mas sem cardinalidades na composio das features, permite a modelagem de restries globais entre features oferecendo de forma interativa, configuraes baseadas na linguagem Prolog. A ferramenta permite que somente um grupo alternative ou or, sejam vinculados a um mesmo elemento-pai, as cardinalidades so descritas atravs de expresses, 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 nmero de FeatureModel. Um FeatureModel tm no mnimo uma Feature, e pode referenciar zero ou vrias subfeatures agrupadas como uma FeatureGroup. Em comparao com a Figura 4, este metamodelo possui a entidade ProblemDomainModel representando o espao-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 notao baseada em cardinalidades, especializaes do diagrama de features e configurao baseada no diagrama de features. O metamodelo do FeaturePlugin pode ser estendido para associar atributos adicionais s features, como prioridades, binding times ou estado da implementao. A Figura 6, apresenta o metamodelo do FeaturePlugin.

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

A Figura 6, mostra que possvel 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 configuraes, cpias de suas sub-rvores, onde os elementos so relacionados. Neste modelo tambm possvel definir os ValueType (feature, float, integer, none e string) como atributos da feature. Comparando com os metamodelos apresentados, neste, no existe um enfoque em rastreabilidade (Figura 4) ou a representao do espao-problema (Figura 5), porm apresenta a representao das cardinalidades atravs do elemento Node e dos atributos, utilizando o elemento TypedValue. 2.4.5. Discusso Nas sees 2.8.1 a 2.8.4, foram apresentadas ferramentas que apoiam a engenharia de domnio e a engenharia de aplicao. A Tabela 3, apresenta um resumo das ferramentas estudadas, onde possvel identificar que as mesmas no possuem os cinco itens (agrupamento de xor-or features baseado em cardinalidades (i), segmentao do modelo de features (ii), rastreabilidade de core assets (iii), modelagem de diagramas UML (iv) e configurao do produto (v)) implementados, no oferecendo dessa forma, um ambiente integrado para as atividades de projeto de uma LPS.

Tabela 3. Resumo comparativo das ferramentas estudadas

Ferramentas

Forma de distribuio

(i)

(ii)

(iii)

(iv)

(v)

PLUSS Toolkit Extenses IBM Rational Rose, Telelogic DOORS e MS-Word RequiLine
Standalone .NET Eclipse plugin

Requisitos, utilizando os ambientes estendidos

Sim (IBM Rational Rose)

Requisitos, de forma integrada Utiliza o Caliber RM e o Telelogic DOORS -

Sim

pure::variants

Somente um xor ou orgroup por parentfeature Sim

Sim

FeaturePlugin

Eclipse plugin

Sim

Foram apresentados at aqui, o propsito de uma Linha de Produtos de Software e os conceitos relacionados a esta, juntamente com as engenharias de domnio e a engenharia de aplicao que permite a derivao de produtos com base no domnio modelado. Tambm vimos os conceitos de modelagem de domnio utilizando a notao de features que tem como base a Feature-Oriented Domain Analysis (FODA), e que possui algumas variaes que foram formuladas ao longo do tempo para contornar alguns problemas encontrados em projetos prticos. Foi destacada tambm, a notao baseada em cardinalidades proposta por Czarnecki (2005). Algumas abordagens para a modelagem das partes comuns e variveis de uma LPS foram verificadas, abordagens essas que vm desde a adaptao da UML atravs de profiles, passando pelo modelo de variabilidade conceitual que possui como foco a rastreabilidade de assets, at o modelo de variabilidade ortogonal. Tambm foram apresentados os conceitos bsicos de rastreabilidade utilizadas como embasamento da construo da Fit2Mapping, e um estudo sobre quatro ferramentas atualmente disponiveis no mercado, identificando suas principais caractersticas e ausncias, de acordo com os itens considerados importantes na definio do projeto de uma LPS. Dentre as ferramentas estudadas, trs delas (PLUSS Toolkit, pure:variants e FeaturePlugin) disponibilizaram os seus metamodelos, sendo possvel 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 espao-problema introduzido por Czarnecki e Eisenecker (2000) e a FeaturePlugin (Figura 6), apresenta elementos para a definio de cardinalidades e atributos em features. Sendo assim, possvel 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 seo, este artigo apresenta a especificao da Fit2Mapping, que foi desenvolvida para suportar a modelagem das engenharias de domnio e aplicao inerentes a uma LPS, considerando os itens descritos como ausentes nas ferramentas apresentadas na Tabela 3. A ausncia de integrao entre as atividades de modelagem e o seu mapeamento para outros artefatos, resulta em um aumento de esforo para a elaborao de uma LPS como descrito por Lisboa (2010), e que constatado com o uso da ferramenta PLUSS Toolkit, onde so utilizados vrios aplicativos, de forma no integrada, gerando um desconforto e uma baixa produtividade para o usurio final. As sees seguintes apresentam o Padro Arquitetural adotado, as Decises Tecnolgicas, Restries 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 domnio, atravs da utilizao de features, permitindo a segmentao dos modelos e uma consequente melhoria na visualizao, por meio do suporte a mltiplas vises da ferramenta. Permitir a modelagem de artefatos de requisitos, anlise e design (diagrama de componentes, diagramas de classes, sequncias e atividades), sendo possvel o rastreamento entre as features e tais artefatos, bem como sua anlise atravs das vises disponibilizadas. Associar os elementos modelados aos seus respectivos componentes (cdigo-fonte), de forma em que, atravs do produto configurado na engenharia de aplicao, se torne possvel a gerao do build.

A Tabela 4, apresenta as principais funcionalidades da Fit2Mapping:

Tabela 4. Principais funcionalidades

Funcionalidades
Modelagem de features, permitindo a segmentao e mltiplas vises do modelo. Modelagem de requisitos. Diagrama de especificao de requisitos (requisitos, cenrios e passos); Reuso de cenrios e passos entre requisitos. Mapeamento entre as features e os core assets. Visualizao da matriz de rastreabilidade (mapa das associaes entre features, requisitos e componentes). rvore de configurao do produto.

A Fit2Mapping uma ferramenta de uso livre (gratuito), disponibilizada atravs de um site5, a sua forma de licenciamento a MIT6, onde se faz somente necessrio a incluso do aviso de copyright e de permisso em todas as cpias ou parte substanciais do software.
5 http://code.google.com/p/fit2mapping/ 6 http://www.opensource.org/licenses/mit-license.php

3.1. Padro Arquitetural A ferramenta possui uma abordagem tradicional em trs camadas, composta por uma interface grfica do usurio (GUI), uma camada de negcios e uma camada de persistncia conforme a Figura 7, que apresenta os elementos e sua relao com as camadas correspondentes. Alm da utilizao dos componentes fornecidos pela plataforma Java como Swing e Java2D, tambm foram utilizados: MigLayout7 biblioteca para facilitar o gerenciamento de layouts dos formulrios desenvolvidos em Swing. IText8 biblioteca para a gerao dos arquivos em formato PDF. FaMa-FW9 framework para anlise automatizada de modelos de features. A motivao para a utilizao dessas tecnologias foi a disponibilizao de forma gratuita, e por atenderem s necessidades de implementao da ferramenta.

Figura 7. Organizao das camadas

3.2. Decises Tecnolgicas Para o desenvolvimento da ferramenta, foi selecionada a plataforma Java Standard Edition verso 1.610 utilizando Swing (para a codificao das telas e formulrios) e Java2D (criao dos diagramas e elementos grficos). A Fit2Mapping tem como propsito ser uma ferramenta standalone. Foram pesquisados dois frameworks que aceleram o desenvolvimento para parte grfica dos modelos: o GMF11 (Graphical Modeling Framework) e o GEF12 (Java Graph Editing Framework) utilizado no ArgoUML. Porm o primeiro, se destina ao desenvolvimento baseado em plugins dentro do Eclipse IDE, e o segundo, em funo da curva de aprendizado deste e de tecnologias correlatas, tambm no foi selecionado. A Tabela 5, apresenta um conjunto de atividades definidas para o projeto e codificao da ferramenta, divididas em duas partes: infraestrutura e modelagem, a primeira (infraestrutura) se preocupou com a parte sistmica da ferramenta, fornecendo
7 8 9 10 11 12 http://www.miglayout.com http://itextpdf.com http://www.isa.us.es/fama/ http://www.oracle.com/technetwork/java/javase/downloads/index.html http://www.eclipse.org/modeling/gmp/ http://eclipse.org/gef

toda a base para a criao dos diagramas e elementos para a modelagem, e a segunda (modelagem), trabalhou as formas especficas de cada tipo de modelo fornecido pela ferramenta.
Tabela 5. Atividades para a construo da ferramenta

Atividades Infraestrutura Elaborao dos Diagramas (Java2D) Criao dos elementos dos diagramas (Figuras, Relaes) Elaborao do Editor de Diagramas (Barra de Ferramentas, Barras de rolagem) Criao das janelas de navegao (Domain explorer) disponibilizando recursos drag'n'drop. Salvar/Abrir projetos (Formato XML) rvore de configurao do produto (Seleo de Features) 3.3. Restries Na verso atual, a Fit2Mapping possui algumas restries identificadas conforme a Tabela 6 e que sero trabalhadas juntamente com os itens descritos na seo 4.1 (Trabalhos Futuros).
Tabela 6. Restries da ferramenta Fit2Mapping

Modelagem Criao dos diagrama de Features Criao do diagrama de Requisitos Criao do diagrama de Especificao de requisitos Criao do componentes diagrama de

Criao do diagrama de mapeamento Criao da Matriz de rastreabilidade

Restries A estrutura de criao dos elementos nos diagramas possui uma implementao prpria, ou seja, no utiliza algum framework grfico como o Eclipse GMF ou o ArgoUML GEF, o que no permite a gerao de arquivos no padro XMI de forma nativa; O diagrama de features embora siga o modelo de variabilidade ortogonal, a implementao de configurao do produto na engenharia de aplicao, ainda no resolve a questo de compartilhamento de maneira consistente. Somente possvel relacionar features e artefatos, no sendo possvel um mapeamento bidirecional ou o mapeamento somente entre os artefatos, tambm no possvel visualizar o mapeamento para qual feature o artefato est associado partindo deste. Em sua verso atual, a ferramenta no implementa a validao do modelo de features, identificando a quantidade de produtos possveis com base no domnio modelado. O padro de persistncia atual em formato XML, no interopervel com outras ferramentas CASE de modelagem. Porm, possvel a implementao de um parser para a leitura do arquivo de projeto. A configurao do produto resultante da engenharia de aplicao, no est funcionando de forma efetiva, gerando o produto com base nas selees dos usurios.

3.4. Metamodelo A Figura 8, apresenta o metamodelo do Fit2Mapping para a realizao da rastreabilidade entre as features e os artefatos.

Figura 8. Metamodelo do Fit2Mapping

Na Tabela 7, exibido um comparativo entre os trs metamodelos apresentados na seo 2.4 (Trabalhos Relacionados), apresentando as caractersticas principais identificadas em cada ferramenta, e um comparativo com o metamodelo projetado para a Fit2Mapping.
Tabela 7. Comparativo entre metamodelos

Metamodelo

Modelagem de Features Sim Sim Sim Sim Sim

Rastreabilidade Sim Sim Sim

group cardinalities
Sim Sim

PLUSS Toolkit pure:variants FeaturePlugin Requiline13 Fit2Mapping

De acordo com a Tabela 7, possvel concluir que o metamodelo projetado para a Fit2Mapping tomou como base os metamodelos apresentados na seo 2.4 (Trabalhos Relacionados). Os artefatos (Component, Requirement, Scenario, Step) herdam da classe Artifact, a classe Mapping responsvel por conter e controlar as associaes entre os artefatos e as features. Tambm possvel visualizar a estrutura para a composio 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 cenrios e passos, e componentes em um projeto de LPS, podendo ser estendido para outros artefatos, como: classes, interfaces, dentre outros.
13 A Requiline no disponibilizou em sua documentao, o metamodelo para anlise.

3.5. Funcionalidades A Fit2Mapping utiliza os conceitos para a modelagem de features baseada na FeatureOriented Domain Analysis (FODA) (seo 2.3) e na notao estendida baseada em cardinalidades proposta por Czarnecki (2000) (seo 2.4), alm da utilizao do modelo de variabilidade ortogonal (seo 2.9) permitindo o reuso de uma feature atravs 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 execuo para a utilizao da ferramenta, onde pri meiramente desenvolvido o modelo de domnio, atravs dos diagramas de features, seguido pela modelagem dos requisitos e sua especificao, ou pela modelagem dos componentes. Aps o processo de modelagem, iniciado o processo de mapeamento entre as features e os artefatos, e que podem ser visualizados atravs de uma matriz de rastreabilidade. Aps a modelagem das features possvel visualizar a rvore de configurao do produto.

Figura 10. Fluxo de execuo

3.5.1. Modelar e documentar Domnio e Features A modelagem das features e a notao estendida com cardinalidades proposta por Czarnecki (2005), so representadas de maneira hierrquica em forma de rvore, organizando as partes comuns e variveis do domnio em nveis crescentes de detalhes. Na Fit2Mapping as features so representadas junto com os seus relacionamentos e dependncias conforme a Tabela 8.
Tabela 8. Tipos de relacionamentos

Relacionamento Mandatory Optional Alternative Or:

Descrio A feature estar sempre presente no produto. A feature pode ou no est presente no produto. De um conjunto de features, somente uma feature pode est presente no produto. De um conjunto de features, pelo menos uma feature deve est presente no produto.

Requires (Dependncia) Obriga a incluso da feature de destino no produto toda vez que a feature de origem selecionada. Porm, a seleo somente da feature de destino, no implica na incluso da feature de origem, representando uma relao unidirecional. Excludes (Dependncia) No permite que ambas as features estejam no mesmo produto, caracterizando uma excluso mtua.

A Figura 11, apresenta os tipos de relacionamentos e dependncias entre as features disponibilizados pela ferramenta.

Figura 11. Tipos de relacionamentos

Conforme Pohl et al. (2005), possvel que vrios stakeholders estejam envolvidos nos processos dos sistemas modelados. Dessa forma, o diagrama de modelagem das features, permite a representao destes, na anlise de domnio atravs do elemento stakeholder como apresentado na Figura 12, exemplificados como Usurios, Analista de domnio e Desenvolvedor.

Figura 12. Stakeholders no modelo de features

3.5.2. Segmentao do modelo de features Um dos problemas encontrados nas atuais ferramentas para a modelagem de features, se relaciona a questo do tamanho dos modelos e sua navegabilidade, tornando-se necessrio utilizar artifcios para que no se perca o entendimento devido quantidade de informao. Dentro das extenses apresentadas na Tabela 2, a Fit2Mapping aplica o conceito de modularizao apresentado por Bednasch (2002), atravs da segmentao do modelo de features, possibilitando aos usurios, projetar o mesmo modelo dividindo-o em outros diagramas e relacionando as features umas com as outras, para a composio da mesma rvore de configurao do produto. A Figura 13, apresenta um exemplo, onde o diagrama de features (A), tido como o diagrama-base que contm a feature Web Portal (raiz), segmentado em outros diagramas (apresentados com uma seta na cor preta), na configurao do produto, as informaes aparecem todas unidas a partir dos diagramas elaborados em uma nica rvore.

Figura 13. Segmentao no modelo de features

A Figura 13, demonstra que as features Additional Services e Web Server so 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 relaes: includes, extends e a incluso de atores (actors). A Figura 14, apresenta o modelo de requisitos (A) onde possvel identificar que atravs das associaes e das propriedades informadas (B), possvel visualizar a documentao do requisitos (C). Algumas informaes como o caso de atores do requisito, provm da associao entre os mesmos (atores e requisitos) sem a necessidade de inform-los na janela de propriedades (B).

Figura 14. Modelo de requisitos

3.5.4. Modelar e documentar especificao de requisitos A modelagem da especificao de requisitos, funciona como uma extenso da atividade descrita na Seo 3.5.3. Porm, o diferencial deste diagrama a representao dos cenrios e passos dos requisitos de forma grfica, permitindo que estes sejam associados s features. A Figura 15, apresenta um formato de descrio de fluxo de eventos que provm do RUP-SE 1.1 [Rational 2003], e que tem por objetivo derivar requisitos funcionais para elementos de anlise. Para a construo desse formato, a atividade se inicia com a seleo dos casos de uso arquiteturalmente significativos, sendo que para cada caso de uso escolhido, um fluxo de eventos desenvolvido. Podemos verificar inclusive a descrio da interao entre os atores e o sistema. As respostas do sistema so black box; essa descrio no referencia os elementos arquiteturais, tambm podemos identificar que os passos associados s respostas possuem requisitos adicionais (BlackBox Budgeted Req.)

Figura 15. Um exemplo de realizao de casos de uso proposta pelo RUP-SE [Rational 2003].

A Figura 16, exemplifica a relao entre a descrio do fluxo no RUP-SE (B) e o diagrama de especificao de requisitos (A), onde possvel tambm identificar as descries contidas nos passos atravs da janela de propriedades (C).

Figura 16. Especificao de requisitos

Aps a modelagem da especificao dos requisitos, possvel obter de forma completa a descrio textual. A Figura 17, apresenta uma caracterstica da modelagem da especificao de requisitos onde os cenrios e passos definidos na especificao de um requisito, podem ser compartilhados por outros requisitos, dessa forma, caso ocorra qualquer alterao, ser refletida em todos os documentos referenciados.

Figura 17. Compartilhamento especificao de requisitos

de

cenrios e

passos no

diagrama de

Na Figura 17, vimos que os requisitos Define Web Server (A) e Define Security Police (B), compartilham o cenrio Choose Content Type (C), caso haja alguma alterao nas propriedades do cenrio, a mesma ser refletida na especificao de ambos os requisitos. 3.5.5. Modelar e documentar componentes A modelagem de componentes, define quais os artefatos fsicos de uma LPS sero utilizados na engenharia de aplicao, quando selecionados pelo engenheiro para a gerao do produto. A Figura 18, apresenta o componente iText-pdf e a sua janela de propriedades onde o componente associado ao arquivo fsico 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 atravs de um diagrama de mapeamento, onde podem ser arrastados (drag'n'drop) modelos ou elementos para esse diagrama, sendo possvel executar tal associao como apresentado na Figura 19, onde apresentado o mapeamento entre features e core assets de forma intuitiva, as associaes possuem o esteretipo <<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 associaes entre as features e os artefatos desenvolvidos como apresentado na Seo 3.4.6. A Figura 20, apresenta uma matriz onde possvel identificar as features (A) e suas associaes com os Requisitos, Cenrios e Passos (B) e os Componentes (C).

Figura 20. Matriz de rastreabilidade

A Fit2Mapping tambm permite a visualizao da rastreabilidade das features de forma individual, atravs 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 cenrio Choose Content Type (B). 3.6. Validao Para validar a utilizao 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 Equipe de avaliao Caractersticas

Fit2Mapping 1 Doutor-orientador e 1 mestrando

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 definies para a coleta dos dados, foi elaborado um questionrio com seguintes objetivos:

Identificar o conhecimento dos usurios em anlise de domnio; Usabilidade da ferramenta; Uso do mdulos; Funcionalidade dos mdulos; Opinio dos usurios quanto a utilidade da ferramenta.

O questionrio 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 questes), alm de outras pessoas envolvidas com anlise de domnio. Como apoio na validao da ferramenta e considerando o conhecimento das pessoas questionadas em anlise de domnio 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 construo de um Web Portal. O WebPortal project, contm o modelo de features segmentado em diversos modelos, diagramas de: requisitos, especificao de requisitos e componentes, bem como o mapeamento das features e os artefatos, sendo possvel visualizar a matriz de rastreabilidade e a rvore de configurao do produto, dessa forma foi possvel subsidiar os usurios no preenchimento do questionrio. A Tabela 10, apresenta as definies para a criao do questionrio de avaliao.
Tabela 10. Definies

Analisar Com o propsito de Com relao a Do ponto de vista de No contexto de

Fit2Mapping Avaliar a ferramenta e detectar melhorias a serem implantadas. Sua utilidade e facilidade de uso. Engenheiro de Software 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 opinies descritas, foram identificadas que a ferramenta ...permite a rastreabilidade de fatures e diferentes vises..., ... clara, sem obscuridade..., ...que permite a associao dos artefatos de forma clara. Dentre os pontos negativos destacam-se que a ferramenta: ...pode apresentar vises mais ricas e relatrios customizados sobre o mapeamento., apresenta falta de clareza na matriz de rastreabilidade... e ...no permite exportao do arquivo em formato XMI.
Tabela 11. Resultados

Objetivo Conhecimento de anlise de domnio Identificar o conhecimento em anlise de domnio Uso da ferramenta Dificuldade na instalao da ferramenta Utilidade no guia de uso Utilizao do arquivo de exemplo Uso dos mdulos Dificuldade na execuo de alguma atividade Funcionalidade dos mdulos Dificuldade no uso - Diagrama de features

(%) Positivo 16,66% 0,00% 67,00% 100,00% 0,00% 33,00%

(%) Negativo 83,33% 100,00% 33,00% 0,00% 100,00% 67,00%

Dificuldade no uso - Diagrama de requisitos Dificuldade no uso - Diagrama de especif. dos requisitos Dificuldade no uso - Diagrama de componentes Dificuldade no uso - Diagrama de mapeamento Clareza da matriz de rastreabilidade Opinio Utilidade no uso da ferramenta

0,00% 0,00% 33,00% 0,00% 67,00% 100,00%

100,00% 100,00% 67,00% 100,00% 33,00% 0,00%

4. Consideraes Finais
Esse artigo apresentou uma ferramenta para auxiliar o engenheiro de software nas atividades de projeto de uma LPS, que possui alm das funcionalidades para a modelagem de domnio e engenharia de aplicao, recursos para a modelagem de diagramas baseados na UML [38], permitindo a associao entre features e artefatos para a gerao do build atravs da configurao do produto na engenharia da aplicao. As quatro ferramentas (PLUSS Toolkit, RequiLine, pure::variants, FeaturePlugin) com caractersticas em rastreabilidade que subsidiaram a construo da Fit2Mapping, permitiram uma melhor anlise para a integrao de dois contextos: engenharia de domnio e aplicao inerentes a uma LPS, com modelos UML, fornecendo a base para a criao 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 validao da ferramenta tendo como instrumento de coleta de dados, um questionrio, cujo o preenchimento foi subsidiado por um guia de uso e um projeto-piloto modelado atravs da ferramenta. Do resultado desta validao, verificou-se a utilidade da ferramenta proposta, devido ao alcance satisfatrio do propsito principal, no mbito de modelagem e rastreabilidade de core assets, e os baixos percentuais de dificuldade na utilizao dos mdulos. Porm, devido a dificuldade na aplicao de um estudo de caso em empresas, torna-se necessrio a aplicao de validaes posteriores de acordo com a evoluo da ferramenta. De fato, o intuito desse produto permitir a gerao de builds executveis e documentao, atravs da configurao do produto, utilizando uma plataforma bem definida e com suporte para rastreabilidade, oferecendo ao usurio respostas quanto a quantidade de possveis produtos, realizao de validaes e anlise de impactos quanto a adio e/ou remoo de artefatos dentro do projeto de uma LPS. 4.1. Trabalhos Futuros Em verses futuras, sero disponibilizadas: a gerao dos arquivos em formato XMI permitindo a integrao com outras ferramentas CASE, um refinamento dos modelos de requisitos e componentes existentes, adio dos diagramas de classes e sequncias e seu consequente mapeamento para os modelos de domnio, e por fim, a concluso do mdulo de configurao do produto para a gerao dos artefatos associados, onde os componentes vinculados fisicamente, podero ser selecionados atravs de um repositrio de controle de verso. Outra melhoria a ser implementada a questo 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 Vincius Cardoso Garcia, pela sua pacincia, 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 contriburam na avaliao deste artigo e na validao da ferramenta.

Referncias
[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. Disponvel 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. Disponvel 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. Disponvel em: <http://129.2.17.93/drum/handle/1903/7538>. [4] BEDNASCH, T. (2002). Konzept und Implementierung eines konfigurierbaren Metamodells fur die Merkmalmodellierung, Diplomarbeit, Fachbereich Informatik und Mikrosystemtechnik, Fachhochschule Kaiserslautern, Standort Zweibrucken, 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. Disponvel 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. Disponvel em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper. htm?arnumber=1531026>. [9] BHNE, 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. Disponvel em: <http://www.sse.uni-essen.de/wms/pubs/AuRE_ca meraready.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. Glck & M. Lowry, Eds.)Generative Programming and Component Engineering, v. 3676, p. 422-437, 2005. Springer. Disponvel 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. Disponvel 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. Disponvel em: <http://www.emeraldinsight.com/10.1108/eb05 4249>. [17] ERIKSSON, M.; MORAST, H.; BRSTLER, 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. Disponvel em: <http://eprints.ucl.ac.uk/749/>. [21] IBM-Rational fevereiro, 2011. Software, http://www-306.ibm.com/software/rational/. Acessado em:

[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. FeatureOriented 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. Disponvel em: <http://www.springerlink.com/index/V 6901T52316R1350. Pdf>. [27] LISBOA, L. B.; GARCIA, V. C.; LUCRDIO, D.; et al. A systematic review of domain analysis tools. Information and Software Technology, v. 52, n. 1, p. 1-13, 2010. Disponvel 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. Disponvel 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. Disponvel em: <http://ieee xplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1702 332>.

[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. Disponvel em: <http://www.informaworld. com/openurl? genre=article&doi=10.1080/09537280420002 38773&magic=crossref>. [33] PINE, B. J. Mass Customization: The New Frontier in Business Competition. Harvard Business School Press, 1993. [34] POHL, K.; BCKLE, 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. Disponvel 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. Disponvel em: <http://www. springerlink.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. Disponvel em: <http://www.omg.org/cgi-bin/doc?formal/01-09-67>. Acessado em: abril, 2011.