Embed Size (px)
Citation preview
Association for Information SystemsAIS Electronic Library (AISeL)Proceedings of the XI Brazilian Symposium onInformation Systems (SBSI 2015)
Brazilian Symposium on Information Systems(SBIS)
5-2015
A Systematic Study on Approaches to deal with theSystems’ Evolution and CustomizationFernanda Almeida PassosUniversidade Federal de Sergipe, [email protected]
Kleber T. O. SantosUniversidade Federal de Sergipe, [email protected]
Raphael F. S. BarretoUniversidade Federal de Sergipe, [email protected]
Galileu Santos de JesusUniversidade Federal de Sergipe, [email protected]
Glayderson Jonathan NunesUniversidade Federal de Sergipe, [email protected]
See next page for additional authors
Follow this and additional works at: http://aisel.aisnet.org/sbis2015
This material is brought to you by the Brazilian Symposium on Information Systems (SBIS) at AIS Electronic Library (AISeL). It has been accepted forinclusion in Proceedings of the XI Brazilian Symposium on Information Systems (SBSI 2015) by an authorized administrator of AIS Electronic Library(AISeL). For more information, please contact [email protected].
Recommended CitationPassos, Fernanda Almeida; Santos, Kleber T. O.; Barreto, Raphael F. S.; de Jesus, Galileu Santos; Nunes, Glayderson Jonathan; andSantos, Lidiany C., "A Systematic Study on Approaches to deal with the Systems’ Evolution and Customization" (2015). Proceedings ofthe XI Brazilian Symposium on Information Systems (SBSI 2015). 39.http://aisel.aisnet.org/sbis2015/39
brought to you by COREView metadata, citation and similar papers at core.ac.uk
provided by AIS Electronic Library (AISeL)
AuthorsFernanda Almeida Passos, Kleber T. O. Santos, Raphael F. S. Barreto, Galileu Santos de Jesus, GlaydersonJonathan Nunes, and Lidiany C. Santos
This article is available at AIS Electronic Library (AISeL): http://aisel.aisnet.org/sbis2015/39
Um Estudo Sistemático sobre Abordagens para lidar coma Evolução e Customização de Sistemas
Alternative Title: A Systematic Study on Approaches to deal with the Systems’Evolution and Customization
Fernanda A. PassosUniversidade Federal de
SergipeMarechal Rondon, Rosa Elze
São Cristóvão – SE, [email protected]
Kleber T. O. SantosUniversidade Federal de
SergipeMarechal Rondon, Rosa Elze
São Cristóvão – SE, Brasilklebertarci-
Raphael F. S. BarretoUniversidade Federal de
SergipeMarechal Rondon, Rosa Elze
São Cristóvão – SE, [email protected]
Galileu S. de JesusUniversidade Federal de
SergipeMarechal Rondon, Rosa Elze
São Cristóvão – SE, [email protected]
Glayderson J. NunesUniversidade Federal de
SergipeMarechal Rondon, Rosa Elze
São Cristóvão – SE, [email protected]
Lidiany C. SantosUniversidade Federal de
SergipeMarechal Rondon, Rosa Elze
São Cristóvão – SE, [email protected]
RESUMODesenvolvedores de sistemas muitas vezes enfrentam pro-blemas na manutencao e evolucao de sistemas de softwarequando precisam customizar produtos para atender as ne-cessidades de diferentes clientes, atraves da criacao de novoscomponentes e modificacao do codigo fonte existente. Nestetrabalho, e apresentada uma analise comparativa das abor-dagens que lidam com variacoes em Linhas de Produto deSoftware (LPS) atraves de um estudo rigoroso do estado daarte, observando sua aplicabilidade para lidar com customi-zacoes.
Palavras-ChaveCustomizacao de Software; Variabilidade; Estudo Sistema-tico; Analise Comparativa.
ABSTRACTSystem developers often face problems in the maintenanceand evolution of software systems when they need to custo-mize products to meet different customers needs, by creatingnew components and modifying existing source code. In thiswork, it is presented a comparative analysis of existing ap-proaches that deal with variations in Software Product Lines
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SBSI 2015, May 26th-29th, 2015, Goiânia, Goiás, BrazilCopyright SBC 2015.
(LPS) through a rigorous study of the state of the art, ob-serving their applicability to handle customizations.
Categories and Subject DescriptorsK.6.3 [Software Management]: Software maintenance
General TermsManagement, Languages.
KeywordsSoftware Customization; Variability; Systematic Study; Com-parative Analysis.
1. INTRODUÇÃOO processo de adaptacao e manutencao de sistemas ad-
quiridos de outras empresas desenvolvedoras desses siste-mas requer atividades inevitaveis em aplicativos de softwaredesde lidar com mudancas no domınio de aplicacao a re-quisitos dos usuarios referentes as melhorias na aplicacao,alem de, novos requisitos. Desta forma, um unico aplicativode software nem sempre consegue satisfazer aos diferentesrequisitos de grupos de usuarios distintos. Este cenario efrequente e ocorre em sistemas customizados pela equipe deorganizacoes adquirentes, como pode ser observado no SIG(Sistema Integrado de Gestao), descrito em mais detalhesno artigo [24]. Essse sistema foi desenvolvido pela Universi-dade Federal do Rio Grande do Norte (UFRN), adquirido eadaptado pela Universidade Federal de Sergipe (UFS).
As atividades envolvidas neste processo nao sao triviais,porque as variacoes nos requisitos para satisfazer os usua-rios finais sao relativamente frequentes e muitas vezes afe-tam varios pontos do sistema original adquirido. Sendo as-sim, torna-se difıcil o gerenciamento das variacoes de forma
XI Brazilian Symposium on Information System, Goiania, GO, May 26-29, 2015.
467
modular. Alem disso, tem que lidar com as evolucoes dosistema original realizadas pelos criadores que normalmentegeram impacto sobre as variacoes desenvolvidas pelos ad-quirentes, por estas serem realizadas diretamente sobre ocodigo base do sistema original, conforme discutido no tra-balho [24]. Consequentemente, o processo de adaptacao emanutencao precisa ser aprimorado, necessitando de abor-dagens que possibilitem:
• A criacao de produtos customizaveis perante as neces-sidades especıficas de cada organizacao;
• A modularizacao das implementacoes das variacoes nosistema sem que seja preciso modificar diretamente ocodigo base do sistema original;
• Gerenciamento das variacoes realizadas pelas organi-zacoes adquirentes no sistema original atraves da mo-dularizacao das mesmas;
• Agilidade no processo de sincronizacao de versoes aoser disponibilizada uma nova versao pelo fornecedor dosistema original;
Diante deste cenario, a utilizacao de tecnicas que lidamcom variacoes em Linhas de Produtos de Software [10], atra-ves de seus princıpios de variabilidade, podem ser capazesde proporcionar a modularizacao e o gerenciamento das va-riacoes, aprimorando o processo de adaptacao e manutencaoem sistemas customizados e a evolucao destes em sincroniacom as novas versoes disponibilizadas pelo fornecedor. Emtrabalhos anteriores [24] e [26] foi analisada a aplicabilidadede tres tecnicas para alguns tipos de variacoes levantadasno cenario atual de customizacao do SIG, sendo elas: As-pectJ [17], o Java Transformation System (JaTS) [9] e aXML-based Variant Configuration Language (XVCL) [16].Estas tecnicas, se mostraram boas candidatas a resolucao doproblema.
Este artigo traz como contribuicao a realizacao de um es-tudo mais rigoroso do estado da arte sobre abordagens exis-tentes para lidar com customizacoes no codigo base de sis-temas adquiridos de outras empresas. Neste estudo, foi ob-servada a aplicabilidade de cada abordagem seguindo algunscriterios relevantes adotados para classificacao das tecnicas.De posse desta classificacao, foi realizado um comparativodas abordagens selecionadas no estudo, indicando possıveistecnicas a serem utilizadas no processo de adaptacao e ma-nutencao desses sistemas adquiridos.
E importante ressaltar que as abordagens levantadas atra-ves desse estudo para serem utilizadas nao consistem narefatoracao do codigo base do sistema adquirido, mas naadaptacao do sistema sem modificar diretamente o codigobase do sistema original. A refatoracao, apesar de facilitar acustomizacao de uma versao especıfica, dificultaria bastantea atualizacao para versoes subsequentes do sistema. Istoacontece porque o codigo estaria muito diferente da versaooriginal, necessitando-se analisar a versao anterior, a nova ea customizada ao mesmo tempo. Desta maneira, a analise doque evoluiu de uma versao para a outra torna-se complexa.
As secoes seguintes do artigo estao organizadas da se-guinte forma. A Secao 2 descreve como foi realizado o estudosistematico sobre o atual estado da arte referente as abor-dagens que lidam com as customizacoes em sistemas. NaSecao 3 sao apresentadas as tecnicas selecionadas no estudo,classificando-as de acordo com as diferentes abordagens de
implementacao de LPS e segundo criterios relevantes a im-plementacao de variabilidades em sistemas customizaveis. ASecao 4 apresenta uma analise comparativa entre as tecni-cas conforme suas abordagens de implementacao, indicandodentre elas as que sao consideradas boas candidatas para aresolucao do problema de pesquisa. Logo em seguida, nasecao 5 e descrita em mais detalhes as tecnicas escolhidasatraves de suas caracterısticas e seu funcionamento. Final-mente, a Secao 6 traz as conclusoes e trabalhos futuros.
2. ESTUDO SISTEMÁTICOO processo de revisao sistematica adotado neste trabalho
foi o proposto por Kitchenham [18].A pesquisa tem como questao central: Quais tecnicas vem
sendo utilizadas para lidar com customizacoes (variacoes) nocodigo a fim de melhorar o processo de adaptacao e manu-tencao em sistemas passıveis de customizacao?
Os criterios de inclusao adotados foram: (a) Nenhumarestricao no perıodo de publicacao; (b) Os trabalhos devemapresentar textos integrais de estudos, escritos em Portuguesou Ingles, em um formato eletronico disponıvel na WEB; (c)Os estudos encontrados devem apresentar tecnicas ou ferra-mentas que lidam com variabilidades em sistemas. Para osde exclusao: estudos que nao apresentam pelo menos umatecnica ou ferramenta que lide com variabilidades em siste-mas.
O estudo foi realizado por meio de busca eletronica: (a)No portal da CAPES1 por periodicos escritos na lıngua in-glesa, referenciando as principais bases de pesquisa como:IEEE Xplore Digital Library, ScienceDirect, Springer Linke ACM Digital Library. Alem, das bases de teses e disserta-coes relacionadas com o tema de pesquisa na lıngua portu-guesa. (b) No Google Scholar2 por trabalhos indexados poralgumas das bases de pesquisa, escritos na lıngua inglesa eportuguesa.
As strings de busca utilizadas em ingles: (techniques ortool) and ”variability in code”; (techniques or tool) and ”vari-ability managing”; (techniques or tool) and ”variability cus-tomization”; (techniques or tool) and ”software variability”;(techniques or tool) and ”variability implementation”. Emportugues foram: ”transformacao de codigo”; ”variabilidadesem codigo”; ”gerenciamento de variabilidades”; ”customiza-cao de variabilidades”; ”implementacao de variabilidades”.
Para a fonte de busca Google Scholar (Ingles) e CAPES(Teses e Dissertacoes), foi necessario realizar modificacoesem algumas expressoes, para em alguns casos ampliar aabrangencia da busca e em outros delimitar mais o escopoda busca devido aos resultados serem bastante abrangentes.
A conducao foi realizada em um mes. A partir das stringsde buscas foram retornados um conjunto de 1481 registros,que apos analise inicialmente do tıtulo e do resumo e emalguns casos da introducao resultou na selecao de 31 tra-balhos, nestes nao foram encontrados trabalhos repetidos.O resultado final do estudo esta apresentada na Tabela 1,em que na coluna Res. Enc. refere-se ao quantitativo deResultados Encontrados e a coluna Trab. Sel. ao quanti-tativo de Trabalhos Selecionados. Vale ressaltar que muitosdos trabalhos selecionados nao tratam especificamente deuma tecnica, mas citam ou fazem comparacoes entre elas.Porem, atraves das referencias as tecnicas foi possıvel encon-
1http://www.periodicos.capes.gov.br2http://scholar.google.com.br
XI Brazilian Symposium on Information System, Goiania, GO, May 26-29, 2015.
468
trar o periodico e ainda obter referencias de outras tecnicasna secao de Trabalhos Relacionados destes periodicos.
Tabela 1: Resultados da Revisao Sistematica, 2013.Base Res. Enc. Trab. Sel.
ACM Digital Library 37 2IEEExplore 159 6
ScienceDirect 135 0Google Scholar (Ingles) 837 18
Google Scholar (Portugues) 141 3CAPES (Teses e Dissertacoes) 172 2
Total 1481 31
Na proxima secao serao apresentadas as tecnicas levanta-das neste estudo classificando-as em abordagens de imple-mentacao de variacoes em LPS, segundo as seguintes cate-gorias: anotativa, composicional, modelagem e transforma-cional.
3. ABORDAGENS QUE LIDAM COM VA-RIAÇÃO EM LPS
A implementacao de variabilidades em Linhas de Produtosde Software (LPS) permite construir assets customizaveis eextensıveis para a concepcao de diferentes produtos de soft-ware derivados de uma LPS. Existem diferentes abordagenspara a implementacao das variantes em LPS, podendo serclassificadas nas seguintes categorias: anotativa, composici-onal, modelagem e transformacional.
As abordagens sao apresentadas nas subsecoes seguintese nelas as tecnicas para LPS encontradas no estudo siste-matico relatado na Secao 2 sao enquadradas e classificadasseguindo criterios adicionais relevantes a implementacao devariabilidades em sistemas. Os criterios foram definidos paraverificar dentre as tecnicas levantadas, quais se enquadra-riam em uma abordagem para aprimorar o processo de adap-tacao e manutencao de sistemas customizados. Para isso, atecnica deve permitir o suporte a fase de implementacao dociclo de vida do software, a derivacao de produtos, a criacaode artefatos de software customizaveis com suporte no nıvelde granularidade grossa e fina e a separacao das variacoesdo codigo base do sistema original.
Os criterios escolhidos para classificacao das tecnicas fo-ram: (i) Configuracao do Produto: especificacao de umproduto da LPS a ser gerado pelo processo de derivacao deprodutos baseado na configuracao de features; (ii) Fasesdo ciclo de Vida da LPS: as fases do ciclo de vida dosoftware suportadas pela ferramenta no desenvolvimento deLPS; (iii) Selecao dos Componentes Concretos: assetsde codigo concretos (classes, aspectos, arquivos e outros)mapeados as features selecionadas para geracao do produtofinal; (iv) Geracao dos Componentes Flexıveis: su-porta adaptacoes, composicoes e transformacoes dos assetsreusaveis para contemplar possıveis variacoes conforme as fe-atures selecionadas para geracao do produto final; (v) Gra-nularidade da Variabilidade: o nıvel de granularidade(grossa ou fina) suportada pela tecnica para implementacaodos assets reusaveis e de variacoes nos mesmos. Nıvel degranularidade grossa possibilita adicionar novas classes, as-pectos, metodos e atributos ou estender pontos de variacoesexplıcitos. E o nıvel de granularidade fina permite introduzirtrechos de codigo a metodos existentes, estender expressoes
ou assinaturas de metodos; (vi) Separacao da Variacaodo Codigo: implementacao das variacoes separada do co-digo base do sistema original.
As classificacoes e dados informados nas tabelas apresen-tadas nas subsecoes seguintes foram obtidos da analise deinformacoes disponıveis em documentacoes e periodicos pu-blicados sobre cada tecnica. E as seguintes abreviacoes saoutilizadas: (i) Fases do Ciclo de Vida: C (Concepcao), A(Analise), P (Projeto), I (Implementacao) e TD (Todas);(ii) Granularidade da Variabilidade: G (Grossa) e F (Fina).
3.1 Abordagem AnotativaNa abordagem anotativa, os fragmentos de codigo de fea-
tures (caracterısticas) sao anotados em uma base de codigocomum e podem ser usados nao somente para configurarvariantes estaticamente antes da compilacao, mas tambempara habilitar ou desabilitar features em tempo de execucao.As anotacoes tambem podem ser realizadas em outros arte-fatos como em modelos [25]. E utilizado nesta abordagemo pre-processador, um programa executado antes do com-pilador para analisar o codigo fonte a ser compilado e, deacordo com as anotacoes adicionadas ao mesmo, sao execu-tadas alteracoes antes de repassa-lo ao compilador. Dentreas tecnicas levantadas, foram identificadas 3 propostas deabordagem anotativa: Antenna3, XVCL (XML-based Vari-ant Configuration Language) [16] e CIDE (Colored Integra-ted Development Environment)4.
Tabela 2: Classificando as Tecnicas de LPS de Abor-dagem Anotativa.
Tecnica Config.doProd.
FasesdoCiclodeVida
Sel.dosComp.Con-cretos
Ger.dosComp.Flex.
Granu.da Var.
Sep.daVar.doCo-digo
Antenna SIM I NAO SIM SIM(G,F) NAO
CIDE SIM I SIM SIM SIM(G,F) NAO
XVCL SIM I NAO SIM SIM(G,F) SIM
De acordo com a Tabela 2 as tecnicas desta abordagemporporcionam a configuracao de produtos e a geracao decomponentes flexıveis atraves do mecanismo de anotacao ex-plıcita com granularidade fina diretamente no codigo fontepodendo ser textual ou visual. As tecnicas Antenna e XVCLutilizam anotacoes textuais por meio de diretivas de pre-processamento ou de comandos especıficos da tecnica dire-tamente no codigo fonte. Diferentemente, a CIDE baseia-seem anotacoes visuais atraves da marcacao do codigo poruma cor de fundo, o que proporciona uma separacao virtualatraves das cores das features, mas nao ha uma separacao defato do codigo base do sistema. No entanto, a tecnica XVCLpossui uma vantagem em relacao a Antenna e CIDE que ea separacao do trecho de codigo que contempla a customi-zacao do codigo base do sistema original em outro arquivo,requerendo apenas a anotacao dos pontos no codigo base dosistema original onde estes trechos de codigo irao ser intro-duzidos.
3.2 Abordagem Composicional3http://antenna.sourceforge.net/wtkpreprocess.php4http://wwwiti.cs.uni-magdeburg.de/iti_db/research/cide/
XI Brazilian Symposium on Information System, Goiania, GO, May 26-29, 2015.
469
Na abordagem composicional, as features sao implemen-tadas separadamente em modulos distintos (arquivos, clas-ses, pacotes, plug-ins e outros) e sao geradas instancias dalinha de produtos atraves da composicao destes modulos.Para gerar variantes, estes modulos podem ser compostos emdiferentes combinacoes. Os mecanismos de implementacaoutilizados sao: componentes, mixin layers, classes virtuais,aspectos e outros [25]. Nesta abordagem foram identifica-das 7 tecnicas: AHEAD [3], FeatureHouse5, JPEL 6, As-pectJ [17], CaesarJ 7, JBOSS AOP8 e Spring AOP9. Estasultimas quatro tecnicas pertencem ao paradigma de Progra-macao Orientado a Aspectos (POA), tendo como unidademodular o aspecto.
As tecnicas enquadradas nesta abordagem, como mostra aclassificacao realizada na Tabela 3, possibilitam a configura-cao de produtos e a geracao de componentes flexıveis atravesda implementacao de modulos distintos com granularidadeque vai de grossa a fina contemplando as customizacoes ne-cessarias ao sistema original mediante a composicao destesmodulos ao codigo base do sistema. As tecnicas AHEAD,FeatureHouse e POA possibilitam a adicao de novos campose metodos a classes do sistema afetando a estrutura estatica,ou ainda a adicao de comportamento extra no inıcio ou finaldos metodos existentes. Diferentemente do JPEL que e limi-tado a implementar variacoes de valor, atraves de arquivosde parametrizacao para alterar os valores das variaveis lo-cais, atributos, constantes usadas para calcular uma expres-sao no sistema e a testes condicionais referentes a adicaoou nao de variabilidades comportamentais implementadasdiretamente no codigo base do sistema original, nao sendoconcebıvel alterar a estrutura do programa.
Tabela 3: Classificando as Tecnicas de LPS de Abor-dagem Composicional
Tecnica Conf.doProd.
FasesdoCi-clodeVida
Sel.dosComp.Con-cre-tos
Ger.dosComp.Flex.
Granu.da Var.
Sep.daVar.doCo-digo
AHEAD SIM I NAO SIM SIM(G,F) SIM
FeatureHouse SIM I NAO SIM SIM(G,F) SIM
JPEL SIM I NAO SIM SIM(F) NAO
POA SIM I NAO SIM SIM(G,F) SIM
3.3 Abordagem de Modelagem de LPSNa abordagem de modelagem de LPS e possıvel especi-
ficar as features que contemplam o escopo de toda a linhade produtos, as dependencias, os relacionamentos e as res-tricoes entre as mesmas. E ainda sistematizar o processo dederivacao de produtos que envolvem a selecao, composicao ecustomizacao dos artefatos de codigo que implementam umaLPS com o objetivo de atender a configuracao de features.
Foram levantadas nesta abordagem 21 propostas: CodeS-coping [21], CONSUL [7], COVAMOF [27], DOPLER10,
5http://www.fosd.de/fh6http://sourceforge.net/projects/jpel/7http://www.caesarj.org/8http://docs.jboss.org/jbossaop/docs/index.html9http://static.springsource.org/spring/docs/2.5.5/reference/aop.html
10http://ase.jku.at/dopler/
FAMA FW [6], FeatureIDE [29], FeatureMapper [15], Fe-aturePlugin [1], Gears [20], GenArch11, Holmes [28], Kum-bang [19], Menage [12], PLUSEE [14], pure::variants12, Re-quiline [30], S2T2 [8], S.P.L.O.T. [22] , VarMod13, V-Manage [5] e XToF [13].
Segundo a Tabela 4, algumas tecnicas adotam somenteuma abordagem de modelagem de LPS para a especifica-cao das features que compoem o escopo de todo o sistemamodelando as partes comuns e variaveis entre os diversosprodutos de software que formam uma LPS. Algumas des-tas tecnicas, como FeatureMapper, FeaturePlugin, Menagee Kumbang, somente realizam a modelagem, isto e, define osrelacionamentos e as dependencias entre as features cobrindosomente a fase de projeto do ciclo de vida da LPS. E outrascomo: COVAMOF, DOPLER, Holmes e CodeScoping rea-lizam tambem o processo efetivo de construcao do produtobaseado na selecao de componentes concretos atraves do ma-peamento dos assets reusaveis as features selecionadas paracompor o produto final. Porem, essas tecnicas nao permitemrealizar customizacoes nos assets que possibilitem a existen-cia de diferentes especificacoes de codigo (variacoes) parauma mesma feature.
Por outro lado, as tecnicas pure::variants, Gears, XToF,GenArch e CONSUL, alem de realizarem a especificacao dasfeatures correspondentes ao domınio da linha de produto e aconfiguracao do produto (atraves de um subconjunto validode features que satisfazem as restricoes presentes no modelode features especificado para obtencao de um produto espe-cıfico da LPS), possuem como recurso adicional a geracaode componentes flexıveis para efetuar customizacoes nos as-sets com granularidade grossa atraves de transformacoes eda composicao de novos assets para possıveis adaptacoes asfeatures e a evolucao da LPS devido a novos requisitos dedomınio.
3.4 Abordagem TransformacionalNa abordagem transformacional, os sistemas de transfor-
macao de programa fornecem mecanismos para a realizacaode modificacoes arbitrarias e nao apenas a composicao demodulos, como transformar a linguagem fonte de um pro-grama num novo programa com linguagem diferente (porexemplo, na compilacao) ou transformar um programa emum novo programa na mesma linguagem (por exemplo, narefatoracao). Os mecanismos de implementacao encontradosforam: Linguagem Especıfica de Domınio (Domain SpecificLanguage - DSL14) e meta-programacao para definir regrasde transformacoes de programas [25]. Em relacao a estetipo de abordagem foram encontradas 5 propostas: DMS(Design Maintenance System) [4], JaTS (Java Transfor-mation System)15, MetaJ 16, Stratego/XT 17 e TXL(TuringeXtender Language) 18.
11http://www.inf.puc-rio.br/~ecirilo/genarch/12http://www.pure-systems.com/fileadmin/downloads/pv-whitepaper-en-04.pdf
13http://www.sse.uni-essen.de/swpl/SEGOS-VM-Tool/14A Domain Specific Language (DSL) e uma linguagem tex-tual ou grafica que proporciona abstracoes de primeira classerepresentando diretamente os conceitos de domınio da apli-cacao.
15www.cin.ufpe.br/~jats/16www.emn.fr/sudholt/research/metaj/17http://www.strategoxt.org18www.txl.ca
XI Brazilian Symposium on Information System, Goiania, GO, May 26-29, 2015.
470
Tabela 4: Classificando as Tecnicas de LPS de Abor-dagem de Modelagem
Tecnica Conf.doProd.
FasesdoCiclodeVida
Sel.dosComp.Con-cre-tos
Ger.dosComp.Flex.
Granu.daVar.
Sep.daVar.doCo-digo
CodeScoping NAO P SIM NAO NAO NAOCONSUL SIM A,P,I SIM SIM SIM(G) SIM
COVAMOF SIM A,P,I SIM NAO NAO NAO
DOPLER SIM C,A,P,I SIM NAO NAO NAO
FAMA-FW NAO A, P NAO NAO NAO NAOFeatureIDE SIM A,P,I SIM SIM SIM(G) SIM
FeatureMapper SIM P NAO NAO NAO NAO
FeaturePlugin SIM P NAO NAO NAO NAOGears SIM A,P,I SIM SIM SIM(G) SIMGenArch SIM P, I SIM SIM SIM(G) SIM
Holmes NAO TD SIM - - -
Kumbang SIM P NAO NAO NAO NAO
Menage NAO P NAO NAO NAO NAO
PLUSEE SIM A, P NAO NAO NAO NAOpure::variants SIM TD SIM SIM SIM(G) SIM
RequiLine SIM C,A,P NAO NAO NAO NAO
S2T2 NAO A, P NAO NAO NAO NAO
S.P.L.O.T. SIM A, P NAO NAO NAO NAO
VarMod SIM A, P NAO NAO NAO NAOV-Manage SIM C,A,P,I SIM SIM SIM(G) SIM
XToF SIM A,P,I NAO SIM SIM(G) NAO
Tabela 5: Classificando as Tecnicas de LPS de Abor-dagem Transformacional.
Tecnica Conf.doProd.
FasesdoCi-clodeVida
Sel.dosComp.Con-cre-tos
Ger.dosComp.Flex.
Granu.da Var.
Sep.daVar.doCo-digo
DMS SIM I NAO SIM SIM(G,F) SIM
JaTS SIM I NAO SIM SIM(G,F) SIM
MetaJ SIM I NAO SIM SIM(G,F) SIM
Stratego/XT SIM I NAO SIM SIM(G,F) SIM
TXL SIM I NAO SIM SIM(G,F) SIM
Essas tecnicas utilizam o casamento de padrao a ser cor-respondido, tornando possıvel a configuracao de produtos ea geracao de componentes flexıveis para efetuar customiza-coes nos assets separadamente do codigo base do sistemaoriginal proporcionando um nıvel de granularidade que vaide grossa a fina, como mostra a classificacao realizada na Ta-bela 5. As tecnicas Stratego/XT, DMS e TXL sao baseadasem regras de reescrita para realizar as transformacoes na lin-guagem alvo de acordo com o padrao informado. A MetaJ eo JaTS utilizam templates que definem um padrao de codigocujas sintaxes sao bastante similares. Sendo que na MetaJ,os templates sao entao traduzidos para uma classe Java e ocasamento e verificado atraves do metodo match() em que ocodigo fonte e passado como parametro. O comportamentoao encontrar casamentos de padroes deve ser programadopelo desenvolvedor na linguagem Java. Ja o JaTS utilizatemplates de casamento e de geracao. Os templates de ca-samento sao descritos com base nos padroes do programaque se deseja modificar, enquanto que os de geracao definemas modificacoes que serao produzidas pela transformacao doprograma.
4. ANÁLISE COMPARATIVA DAS TÉCNI-CAS DE LPS
As tecnicas apresentadas ate entao, foram classificadas nasecao anterior de acordo com as diferentes abordagens deimplementacao de LPS e segundo criterios adicionais rele-vantes a implementacao de variabilidades em sistemas. Estasecao traz uma analise comparativa das tecnicas LPS emsuas abordagens de implementacao, tendo como contribui-cao a analise mais focada na indicacao de algumas das tec-nicas mencionadas na Secao 3, por estas serem consideradasboas candidatas para a resolucao do problema de pesquisa.
Na analise realizada sobre a Secao 3.3 referente as tec-nicas de abordagem de modelagem de LPS, foi verificadoque apesar de existirem tecnicas que efetuam customizacoesnos assets com granularidade grossa atraves de mecanismosde implementacao como, anotacao e composicao, as mesmasnecessitam das especificacoes das features que compoem oescopo do sistema para que seja possıvel gerar diferentesconfiguracoes de produtos atraves da selecao, transformacaoou combinacao dos assets associados as features selecionadasno processo de derivacao do produto. Sendo assim, os meca-nismos de implementacao de variabilidade em LPS propostopor essa abordagem nao se alinham com os objetivos destetrabalho, que refere-se a customizacao do codigo fonte desistemas originais desenvolvidos por empresas fornecedorasde software e adquiridos por outras organizacoes sem a rea-lizacao de refatoracoes no codigo original cobrindo somentea fase de implementacao e nao contemplando a especifica-cao e a modelagem de features do domınio, as quais seriamnecessarias para adocao de uma das tecnicas de abordagemde modelagem de LPS.
As tecnicas da Secao 3.1 de abordagem anotativa utilizamdo mecanismo de anotacao explıcita com granularidade finadiretamente no codigo fonte o que de certa forma inviabili-zaria a sua utilizacao nesta pesquisa, pois os problemas demanutencao e evolucao do sistema continuariam devido anecessidade de reintroduzir as customizacoes efetuadas aosistema original a cada nova versao disponibilizada pelo for-necedor. No entanto, a tecnica XVCL foi uma das tecnicasescolhidas por proporcionar algumas vantagens: a delimita-cao exata do trecho de codigo em que ocorre a alteracao;a separacao do trecho de codigo que contempla a customi-zacao do codigo base do sistema original em outro arquivorequerendo apenas a anotacao dos pontos no codigo basedo sistema original em que estes trechos de codigo irao serintroduzidos; e a facilidade de aprendizado da tecnica, poisnao se faz necessario que o desenvolvedor possua um amploconhecimento da tecnica para entender seu funcionamento eseus comandos.
Diferentemente das tecnicas anotativas, nas composicio-nais (Secao 3.2) as variacoes podem ser implementadas semanotacoes explıcitas no codigo original atraves da separacaodas variabilidades existentes das features do codigo base dosistema em modulos distintos com granularidade que vai degrossa a fina, promovendo assim a modularizacao dos inte-resses (funcionalidades). A POA (atraves do AspectJ) e aFeatureHouse foram as escolhidas nesta abordagem por pro-porcionar modificacao na estrutura estatica de um sistemaadicionando atributos, metodos e construtores a uma classe,ou ainda a adicao de comportamento extra no inıcio ou fi-nal dos metodos existentes. Com a POA e possıvel aindaafetar a estrutura dinamica de um programa mediante a in-
XI Brazilian Symposium on Information System, Goiania, GO, May 26-29, 2015.
471
terceptacao de pontos no fluxo de execucao do programa,chamados join points, definidos em pointcuts e de um con-junto de advice que podem executar comportamento antese/ou depois de join points, e ate substituir um comporta-mento existente no programa por outro. O AHEAD nao foiselecionado devido a necessidade de transferencia completado codigo do sistema para arquivos ”.jak”, pois para utiliza-cao desta tecnica o desenvolvedor deve separar o codigo emarquivos (”.jak”) diferentes de acordo com as features. Paraa geracao de instancias da LPS deve-se escolher quais dasfeatures serao incluıdas, entao a ferramenta de composicaodo AHEAD faz a juncao dos arquivos de cada feature emum novo arquivo ”.jak”. E logo apos essa juncao o arquivoe transformado em um arquivo Java.
As abordagens somente transformacionais da Secao 3.4,como os sistemas de transformacao de programa Strate-go/XT, DMS e TXL sao tecnicas que possuem um nıvelde complexidade alto na implementacao, visto que realizammodificacoes arbitrarias, normalmente incluindo a remocaoou reestruturacao completa da sintaxe concreta da lingua-gem objeto. Portanto, nao sao frequentemente adotadosna pratica para implementar variacoes em LPS. A MetaJe uma tecnica de transformacao semelhante ao JaTS sendoque a linguagem de templates e muito simples e nao suportatransformacoes mais complexas sendo necessario a definicaode metodos, por outro lado as transformacoes descritas deforma declarativa, como em JaTS, sao de certa forma maissimples de serem escritas, devido a linguagem de templatesser proxima da template da linguagem objeto. No entanto,o JaTS apesar de ser um bom candidato nao tem acom-panhado as atualizacoes da linguagem Java, gerando assimuma incompatibilidade ao usar as construcoes novas da lin-guagem Java, como Generics.
Deste modo, as tecnicas indicadas de acordo com os crite-rios relevantes, mencionados neste artigo, a implementacaode variabilidades em sistemas sao: as tecnicas de abordagemcomposicional, POA (atraves do AspectJ) e a FeatureHouse,e a tecnica de abordagem anotativa XVCL. As principaisrazoes pela escolha dessas tecnicas foram o suporte a imple-mentacao de variacoes em diferentes nıveis de granularidadee a separacao das mesmas do codigo sem que seja necessa-rio alterar diretamente o codigo base do sistema original,refletindo-se em uma vantagem durante a evolucao do sis-tema. A XVCL, apesar de nao suportar a separacao totaldas variacoes, porque exige a marcacao dos pontos aonde se-rao introduzidas as variacoes (estas sim estao separadas emarquivos), foi selecionada principalmente pela simplicidadede aprendizado e utilizacao.
5. TÉCNICAS DE LPS ESCOLHIDASNesta secao, serao apresentadas as tecnicas AspectJ, Fea-
tureHouse e XVCL escolhidas para a implementacao das va-riantes em sistemas customizaveis descrevendo as suas prin-cipais caracterısticas e seu funcionamento.
AspectJ [17] e uma extensao da linguagem Java para su-portar o paradigma de Programacao Orientada a Aspectos.Esse paradigma tem como objetivo o suporte a modulariza-cao dos interesses transversais por meio de abstracoes quepossibilitem a separacao e composicao destes interesses noprocesso de desenvolvimento de software.
O princıpio da separacao de interesses (concerns) foi in-troduzido por Dijkstra[11], tendo como objetivo dividir odomınio do sistema em partes menores, ou seja, separados
em modulos. O termo interesse e utilizado no contexto daEngenharia de Software para representar requisitos que pre-cisam estar contidos nos sistemas. Os interesses podem servistos como requisitos funcionais, tais como regras de nego-cios, ou nao funcionais, como gerenciamento de transacaoe persistencia. Os interesses transversais (crosscutting con-cerns) sao portanto interesses que afetam varios modulos dosistema e sao difıceis de separar por estarem espalhados portodo o sistema e entrelacados com os outros interesses den-tro de um mesmo modulo. Exemplos destes interesses saodentre outros: logging, tracing, distribuicao e autorizacao.
Com a utilizacao desse paradigma e introduzida uma novaabstracao, chamada aspecto, em que os interesses transver-sais sao encapsulados e os mecanismos de integracao da POArealizam a composicao do aspecto aos artefatos de software(componentes de software da programacao orientada a ob-jetos tais como classes, metodos e atributos) num processochamado weaving.
Sendo assim, uma aplicacao AspectJ e composta por clas-ses e aspectos. Os aspectos permitem modificar a estruturaestatica de um sistema, por exemplo, adicionando atributos,metodos e construtores a uma classe e alterando a hierar-quia do sistema. Alem disso, e possıvel afetar a estruturadinamica de um programa atraves da interceptacao de pon-tos no fluxo de execucao, chamados join points e da adicaode comportamento definido em um advice.
A FeatureHouse 19 e uma arquitetura geral de composicaode software baseada em um modelo independente de lingua-gem de artefatos de software e um mecanismo de plug-inautomatico para a integracao de novos artefatos de lingua-gens sendo apoiada por um framework e um conjunto deferramentas.
A tecnica generaliza e integra os artefatos de softwareatraves da ferramenta FSTCOMPOSER que se baseia emum modelo geral da estrutura de artefatos de software, cha-mado de modelo de Arvore da Estrutura de Features (Fea-ture Structure Tree - FST). Uma FST representa a estruturaessencial de um artefato de software e resumos a partir dedetalhes especıficos da linguagem. Por exemplo, um artefatoescrito em Java contem pacotes, classes, metodos e assim pordiante, que sao representados por nos em FST.
A composicao dos artefatos de software e realizada atravesdo princıpio de sobreposicao, pois duas FSTs sao sobrepos-tos pelo merge dos nos, identificados pelos nomes, tipos eposicoes relativas, comecando a partir da raiz e descendorecursivamente. No entanto, a composicao de duas folhasde uma FST que contenham conteudo a mais, por exemplo,dois corpos de metodos exigem um tratamento especial. Arazao e que o conteudo dos metodos nao e representado comouma sub-arvore, mas como um simples texto. Nesta situa-cao e realizado o merge dos corpos dos metodos atraves deoverride, em que a inclusao da palavra reservada original
define como os corpos dos metodos serao mesclados, que decerta forma se assemelha ao super do Java. A palavra reser-vada original e uma meta-notacao que desaparece apos acomposicao. O interpretador Java trata original como umachamada de metodo. Durante a composicao de dois corposde metodos, a palavra reservada original sera procuradae substituıda pelo corpo do metodo original. As Figuras 1ilustra o processo de sobreposicao de FSTs.
A tecnica XVCL [16] e baseada numa abordagem de ano-
19http://www.fosd.de/fh
XI Brazilian Symposium on Information System, Goiania, GO, May 26-29, 2015.
472
Figura 1: Composicao de FSTs [2].
tacao permitindo realizar marcacoes semelhante ao XML(eXtensible Markup Language) em trechos especıficos do co-digo indepentende de linguagem, sendo incentivada para oscasos de reuso e de adaptacao do software com a finalidadede configurar variantes em uma variedade de ativos de soft-ware, tais como modelo, o codigo de programa de domınio,casos de teste e outros. E geralmente utilizada no desenvol-vimento de Linhas de Produtos de Software (LPS), visto queuma famılia de software necessita constantemente adaptar osistema aos requisitos exigidos pelo cliente.
A tecnica e embasada no conceito de programacao deframe em que cada definicao de frame e chamada de X-FRAME. Cada X-FRAME e um componente adaptavel pro-gramado em uma estrutura de arquivo XML. Neste arquivoesta presente um trecho de codigo fonte com marcacoes decomandos XVCL, estes comandos possibilitam que trechosdo codigo fonte possam ter diversos comportamentos dife-rentes de acordo com os requisitos do cliente, demonstrandoa capacidade de adaptacao fornecida pela tecnica.
Um X-FRAME pode invocar outros X-FRAMES atravesde um processo chamado de adaptacao, que permite realizara customizacao do programa. Cada frame adapta qualquerum ou todos seus descendentes e cada frame pode ser adap-tado pelo frame pai, sendo entao organizados em hierarquiacomo demonstra a Figura 2. O conceito mais importantena adaptacao e o ponto de interrupcao que marca pontos nocodigo fonte onde sera feita insercao de trecho de codigo.
Figura 2: Funcionamento do XVCL [16].
Na Figura 2, todos os X-FRAMES estao conectados aoX-FRAME raiz A, que e o ponto de partida para gerar oprograma com as adaptacoes a partir das anotacoes reali-zadas. Ja os X-FRAMES filhos contem o codigo fonte com
as adaptacoes que precisam ser realizadas nos pontos de in-terrupcao. Portanto, cada programa XVCL consiste de umX-FRAME raiz, sendo referenciado como um arquivo de es-pecificacao, e da composicao de varios X-FRAMES. O pro-cessador XVCL analisa o arquivo de especificacao e constroio programa, realizando a composicao com todos os outrosX-FRAMES utilizados.
6. CONCLUSÕESEste artigo traz um estudo sistematico sobre tecnicas que
podem auxiliar na implementacao de customizacoes (vari-acoes) no codigo base de sistemas adquiridos de empresasdesenvolvedoras de aplicativos de software. Apos o levan-tamento do estudo, foi realizada a classificacao das tecnicasencontradas de acordo com as abordagens de implementacaode LPS e os criterios adicionais importantes a customiza-cao de sistemas adquiridos. Em seguida, foi feita a compa-racao dessas abordagens, obtendo a indicacao de AspectJ,FeatureHouse e XVCL como as tecnicas mais apropriadasao problema discutido neste artigo. Diante da contribuicaodeste trabalho, as tecnicas indicadas foram avaliadas numcontexto real no trabalho [23], atraves do planejamento eexecucao de um quasi-experimento.
Como trabalho futuro, esta em processo de realizacao umaanalise mais rigorosa dos resultados do quasi-experimento doponto de vista estatıstico. Esta analise, visa observar esta-tisticamente o desempenho e a confianca das tecnicas indi-cadas neste artigo no processo de adaptacao e manutencaode sistemas customizados.
AgradecimentosGostarıamos de agradecer ao CNPq, CAPES e Fapitec, agen-cias brasileiras de fomento a pesquisa, por apoiar parcial-mente este trabalho.
7. ADDITIONAL AUTHORSAlberto Costa Neto (Universidade Federal de Sergipe, email:
8. REFERÊNCIAS[1] M. Antkiewicz and K. Czarnecki. Featureplugin:
feature modeling plug-in for eclipse. In Proceedings ofthe 2004 OOPSLA workshop on eclipse technologyeXchange, pages 67–72, Vancouver, British Columbia,Canada, 2004. ACM.
[2] S. Apel and C. Lengauer. Superimposition: Alanguage-independent approach to softwarecomposition. In 7th International Symposium SoftwareComposition, pages 20–35, Budapest, Hungary, 2008.Springer.
[3] D. Batory. Feature-oriented programming and theahead tool suite. In Proceedings of the 26thInternational Conference on Software Engineering(ICSE ’04), pages 702–703, Scotland, UK, 2004. IEEEComputer Society.
[4] I. D. Baxter, C. Pidgeon, and M. Mehlich. Dms R©:Program transformations for practical scalablesoftware evolution. In Proceedings of the 26thInternational Conference on Software Engineering(ICSE ’04), pages 625–634, Scotland, UK, 2004. IEEEComputer Society.
XI Brazilian Symposium on Information System, Goiania, GO, May 26-29, 2015.
473
[5] J. Bayer, S. Gerard, Ø. Haugen, J. Mansell,B. Møller-Pedersen, J. Oldevik, P. Tessier, J.-P.Thibault, and T. Widen. Consolidated product linevariability modeling. Software Product Lines, pages195–241, 2006.
[6] D. Benavides, S. Segura, P. Trinidad, andA. Ruiz-Cortes. Fama: Tooling a framework for theautomated analysis of feature models. In Proceeding ofthe First International Workshop on VariabilityModelling of Software-intensive Systems (VaMoS2007), pages 129–134, Limerick, Ireland, 2007.Citeseer.
[7] D. Beuche, H. Papajewski, andW. Schroder-Preikschat. Variability management withfeature models. Science of Computer Programming,53(3):333–352, December 2004.
[8] G. Botterweck, M. Janota, and D. Schneeweiss. Adesign of a configurable feature model configurator. In3rd International Workshop on Variability Modellingof Software-intensive Systems (VaMoS 2009),volume 29, pages 165–168, Sevilla, Spain, 2009. ICBResearch Report.
[9] F. Castor, K. Oliveira, A. Souza, G. Santos, andP. Borba. JaTS: A Java Transformation System. InProceedinds of XV Brazilian Symposium on SoftwareEngineering (SBES 2001), pages 374–379, Rio deJaneiro, Brasil, October 2001.
[10] P. Clements and L. M. Northrop. Software ProductLines: Practices and Patterns. Addison-Wesley,Boston, MA, USA, 2001.
[11] E. W. Dijkstra. A discipline of programming,volume 1. Prentice-Hall, Englewood Cliffs, NJ, 1976.
[12] A. Garg, M. Critchlow, P. Chen, C. Van derWesthuizen, and A. Van der Hoek. An environmentfor managing evolving product line architectures. InProceedings of the 19th International Conference onSoftware Maintenance (ICSM 2003), pages 358–367,Amsterdam, The Netherlands, 2003. IEEE.
[13] C. Gauthier, A. Classen, Q. Boucher, P. Heymans,M.-A. Storey, and M. Mendonca. Xtof: A tool fortag-based product line implementation. volume 10,pages 163–166, Linz, Austria, 2010. University ofDuisburg-Essen.
[14] H. Gomaa and M. E. Shin. Tool support for softwarevariability management and product derivation insoftware product lines. In International Workshop onSoftware Variability Management for ProductDerivation, Software Product Line Conference(SPLC)., Boston, USA, August 2004.
[15] F. Heidenreich, J. Kopcsek, and C. Wende.Featuremapper: mapping features to models. InProceedings of the 30th International Conference onSoftware Engineering (ICSE), pages 943–944, Leipzig,Germany, 2008. ACM.
[16] S. Jarzabek. XML-based Variant ConfigurationLanguage (XVCL), Specification Version 2.10.Singapore, National University of Singapore edition,Junho 2006.
[17] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten,J. Palm, and W. Griswold. Getting Started withAspectJ. Communications of the ACM, 44(10):59–65,Oct. 2001.
[18] B. Kitchenham. Procedures for performing systematicreviews. Joint Technical Report, Computer ScienceDepartment, 33, 2004.
[19] H. Koivu. A tool for modelling software productfamilies – user-centred prototype implementation.Master’s thesis, Department of Computer Science andEngineering, Helsinki University of Technology, Espoo,Finland, February 2007.
[20] C. W. Krueger. Software mass customization. Whitepaper, BigLever Software Inc., May 2005.
[21] T. F. L. Medeiros, E. S. Almeida, and S. R.Lemos Meira. Codescoping: A source code based toolto software product lines scoping. In 38thEUROMICRO Conference on Software Engineeringand Advanced Applications (SEAA’12), pages101–104, Cesme, Izmir, 2012. IEEE.
[22] M. Mendonca, M. Branco, and D. Cowan. S.P.L.O.T.:Software Product Lines online tools. In Proceedings ofthe 24th ACM SIGPLAN conference companion onObject Oriented Programming Systems Languages andApplications (OOPSLA’09), pages 761–762, Orlando,Florida, USA, October 2009. ACM.
[23] F. Passos, G. Jesus, G. Nunes, R. Barreto, K. Santos,and A. Costa Neto. Experimentando AspectJ comouma abordagem para lidar com a Evolucao eCustomizacao de um Sistema Integrado de Gestao. InWMod2014 - 11th Workshop on Software Modularity ,Maceio, Brasil, 2014.
[24] F. Passos, K. Santos, R. Barreto, and A. Costa Neto.Adaptacao e Manutencao de Sistemas Integrados deGestao apoiados pela Programacao Orientada aAspectos. In IX Simposio Brasileiro de Sistemas deInformacao, Joao Pessoa, Brasil, Maio 2013.
[25] G. Saake, D. Batory, and K. Czarnecki. Virtualseparation of concerns: toward preprocessors 2.0. PhDthesis, Otto-von-Guericke-Universitat Magdeburg,Magdeburg, Germany, May 2010.
[26] K. Santos, R. Barreto, F. Passos, and A. Costa Neto.Utilizando JaTS e XVCL para customizacao emSistemas Integrados de Gestao. In Erbase 2013 - XIIIEscola Regional de Computacao Bahia AlagoasSergipe, Aracaju, Brasil, Abril 2013.
[27] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch.Covamof: A framework for modeling variability insoftware product families. volume 3154, pages 197–213,Boston, MA, USA, August 2004. Springer Verlag.
[28] G. Succi, J. Yip, and W. Pedrycz. Holmes: anintelligent system to support software product linedevelopment. In Proceedings of the 23rd InternationalConference on Software Engineering, pages 829–830,Toronto, Ontario, Canada, May 2001. IEEE ComputerSociety.
[29] T. Thm, C. Kstner, F. Benduhn, J. Meinicke,G. Saake, and T. Leich. FeatureIDE: An ExtensibleFramework for Feature-Oriented SoftwareDevelopment. Science of Computer Programming,2012.
[30] T. von der Maßen and H. Lichter. Requiline: Arequirements engineering tool for software productlines. In Proceedings of the 5th Workshop on ProductFamily Engineering (PFE 2003), volume 3014, pages168–180, Siena, Italy, 2003. Springer.
XI Brazilian Symposium on Information System, Goiania, GO, May 26-29, 2015.
474
