Solução DSM para Micro e Pequenas Software House

Transcrição

1 Solução DSM para Micro e Pequenas Software House Luiz Carlos d Oleron 12, Cleyton Mário de Oliveira Rodrigues 12, Gleibson Oliveira 12, Lúcio santos 12 1 Centro de Informática Universidade Federal de Pernambuco (CIn/UFPE) P.O. Box 7851 Recife PE - Brasil 2 Improvess, Avenida Governador Carlos de Lima Cavalcante, 421 Olinda PE Brasil. {lcadb, cmor, grso, ljfs}@cin.ufpe.br Abstract. Software engineering always sought techniques to leverage productivity for Product Lines, removing from the end-developer the hard task to pro- gram the entire solution. A model-centric, domain-based software development (Domain Specific Modeling, DSM) fits well this scenario: taking models as primary artifacts is the key business to keep model and code synchronized throughout the project. This paper therefore discusses the benefits that can be achieved by micro and small software product line enterprises when incorporating within the organizational environment a software development guided by domain-specific models. Further, a simulation for an integrated solution for inventory management will be discussed. Resumo. A Engenharia de Software sempre buscou técnicas para alavancar a produtividade para linhas de produto, removendo do desenvolvedor a árdua tarefa de programar toda a solução final. Um desenvolvimento baseado em modelos de domínio da aplicação se encaixa bem neste cenário: tomar modelos como artefatos primários é a chave do negócio para mantê-los sincronizados com o código ao longo do projeto. Este artigo, portanto, discute os benefícios que podem ser alcançados por micro e pequenas empresas que trabalham em linhas de produtos de software, ao incorporar dentro do ambiente organizacional um desenvolvimento de software orientado por modelos de domínio. Além disso, uma simulação para uma solução integrada de gestão de estoques será discutida. 1. Introdução A crise financeira que abalou o cenário macroeconômico mundial, entre os anos de 2008 e 2009, paradoxalmente, revelou uma forte tendência para investir em mercados emergentes. No pós-crise que se seguiu, a retomada do crescimento econômico experimentado por este seleto grupo de países emergentes, chamou a atenção de todo o mercado internacional, incluindo o mercado de tecnologia da informação e produção de software. Dentro deste contexto, a América Latina e especialmente o Brasil está emergindo como o carro-chefe na nas vendas de software e serviços [Gandra]. Micro e pequenas empresas, juntas, representam a maior parte das indústrias de software. Não obstante, para continuar (ou voltar) a crescer em ritmo acelerado é importante que estas continuem a ser maduras o suficiente para competir no mercado.

2 Tempo de entrega de um produto no mercado (time-to-market), produtividade, custos e qualidade continuam a ser fortes parâmetros para manter ou remover uma empresa no mercado de software. A Indústria de Software tem sido alvo de constantes transformações tanto metodológicas, como tecnológicas, tais como o surgimento de novas IDE (Integrated Development Environment) e ferramentas CASE (Computer-Aided Software Engineering), focando sempre na produtividade, qualidade, reusabilidade, interoperabilidade, além de eliminar redundâncias e inconsistências, e também, promover a entrega rápida de produtos e/ou serviços, a um baixo custo. Uma das experiências mais recentes é remover do programador final todo o árduo trabalho da construção da solução final, a qual era baseada quase que exclusivamente em sua própria interpretação do problema, e na as sua experiência em programação. Nesse novo roteiro [Stahl and Völter 2006], os modelos estão assumindo o papel de principal artefato. Em um nível abstrato, a solução do problema é modelada a partir das entidades presentes no domínio da aplicação, e, sistematicamente, este modelo é refinado em direção a uma plataforma de desenvolvimento (Java,.Net, por exemplo). O modelo original, portanto, é passível de ser reutilizado para a mesma aplicação, porém visando diferentes plataformas, ou até mesmo ser estendido para aplicações diferentes. Dentro do contexto de Software Product Line (SPL) [Software Engineering Institute 2010], onde produtos dentro de uma mesma família compartilham parcialmente algumas peculiaridades (arquitetura, features, casos de testes), o uso de modelos de domínio favorece a reusabilidade e, consequentemente, produtividade e baixo custo de desenvolvimento. Assim, este artigo explora os benefícios tangíveis que podem ser alcançados pelo uso de uma solução DSM dentro de uma família de produtos de software. Também, ao final do artigo é exibido um pequeno estudo de caso, utilizando ferramentas gratuitas e disponíveis na Web, tornando a solução compatível com a realidade das micro e pequenas empresas de software. Este artigo está organizado como se segue. Na seção 2 será discutido o cenário atual financeiro das micro e pequenas software house, bem como o cenário metodológico, isto é, as abordagens que existem e tratam o problema em discussão neste artigo. Já na seção 3é discutido o estado da arte de soluções de engenharia de software dirigida por modelos. Na Seção 4 apresentamos a solução DSM através de um conjunto de 5 atividades, bem como identificamos os benefícios advindos do uso desta solução. Por fim, as seções 5 e 6 tratam de um estudo de caso, instanciando estas atividades e das conclusões acerca do trabalho, como também as perspectivas para trabalhos futuros, respectivamente. 2. Cenário Atual Esta seção faz uma correlação entre dois aspectos que tangem as software-house, o cenário financeiro e o cenário metodológico. Enquanto, por um lado, explora como as empresas de desenvolvimento de software (em particular, as micro e pequenas) estão se comportando face à grande demanda do mercado, por outro, destacamos as ferramentas, processos e metodologias disponíveis na literatura que podem ser utilizadas como subsídio ferramental para aprimorar o desenvolvimento de sistemas baseado em modelos de domínio.

3 Figura 1: Taxa de crescimento no mercado Brasileiro (em Bilhões) [ABES 2010] Cenário Financeiro De acordo com a ABES [ABES 2009], o mercado brasileiro de software movimentou mais U$ 15 bilhões em 2009 e 2010, mantendo um crescimento constante [ABES 2010], em relação aos últimos anos, figura 1. Estima-se uma movimentação de mercado em 2012 em cerca de U$ 20,2 bilhões e uma projeção de 24% no número de empresas atuantes no segmento, fornecendo indicadores de crescimento da demanda de software no país. Do total movimentado em 2009, cerca de U$ 4,35 bilhões foram com desenvolvimento de software, sendo U$ 1,12 bilhões a movimentação relacionada a softwares customizáveis provenientes de software-houses, representando perto de 35% da demanda de desenvolvimento de software. O crescimento do mercado da Tecnologia da Informação (T.I.) reflete o aumento da demanda por software e a constante necessidade de investimento, com foco na competitividade das empresas. Além do mais, o aumento da demanda por serviços e produtos de T.I. leva ao aumento da competitividade no setor, fomentando novos entrantes no mercado e a necessidade de aperfeiçoamento da eficiência e competitividade empresarial de tais empresas. Todavia, o processo de produção da grande maioria das software-houses em mercados como o brasileiro não suporta o aumento crescente da demanda. A incapacidade operacional de fabricação entra em conflito com os resultados comerciais conquistados, gerando cenários onde as empresas vendem muito, mas não tem fôlego para atender às demandas vendidas [SOFTEX 2009]. Em particular, as software-houses possuem, em geral, um processo de fabricação mais próximo do artesanal (onde cada produto exige um grande grau de personalização manual para um cliente) do que industrial (onde produtos são gerados em linhas de produção, mas mesmo assim, atendem às necessidades específicas de cada cliente) Cenário Metodológico Linhas de Produtos de Software (em inglês Software Product Line, SPL) - um conjunto de sistemas de software que satisfaz as necessidades específicas de um segmento específico do mercado [Software Engineering Institute 2010] - é uma abordagem de desenvolvimento comumente aplicada para produção de uma ampla gama de produtos.

4 A partir de requisitos de um domínio específico, SPL advoga que estes sejam refinados até um produto alvo; esta abordagem, por natureza, incorpora e elava o reuso em uma família de produtos similares, uma vez que a partir do mesmo conjunto de requisitos iniciais, uma linha de produtos pode ser desenvolvida. Neste contexto, SPL introduz métodos de análise de Variabilidade, para identificar dentre estes requisitos, aqueles que são obrigatórios, alternativos ou opcionais; a diversidade de produtos de uma família dar-se-á a partir desta configuração. Em termos gerais, a Análise de Variabilidade contempla a definição do escopo, semelhanças e pontos de variabilidades entre produtos de software de uma determinada família [Myllymäki 2001] [Coplien et al. 1998]. A identificação pode ser realizada em nível de componentes, arquitetural, de artefatos e até mesmo em casos de testes [Chen et al. 2009]. Variabilidade pode ser definida como [...] a capacidade de um ativo se adaptar em contextos de produtos diferentes que estão no escopo da mesma linha de produtos [Bachmann e Clements 2005]. Dentre os métodos mais utilizados para se realizar análise de variabilidade, destaca-se o FODA - Feature Oriented Domain Analysis [Kang et al. 1990], o qual pode ser delineado em três passos consecutivos: (I) Análise de Domínio, (II) Extração dos pontos comuns e variáveis, e (III) Refinamento do modelo em diferentes aplicações. Recentes estudados na literatura discutem uma visão multidisciplinar, ao incorporar Engenharia Dirigida por Modelos (em inglês Model-Driven Development, MDD) como um processo inerente à SPL. Em particular, explora-se o uso de modelos específicos de domínio (em inglês Domain Specific Modeling, DSM) ao invés de modelos de propósito geral, uma vez que, os primeiros podem ser mais expressivos e mais coerentes com o domínio que se deseja modelar [Kelly e Tolvanen 2008], [White et al. 2009]. 3. MDD e DSM Desenvolvimento dirigido por modelos, (em inglês Model Driven Development, MDD) um paradigma de desenvolvimento onde os modelos (gráficos e/ou textuais) não são meros artefatos utilizados informalmente. Pelo contrário, esta abordagem surgiu para fechar a lacuna entre a solução, especificada por modelos com um alto nível de abstração e o código fonte final da aplicação. Elevando o nível de abstração da solução, independente de qualquer plataforma subjacente de codificação, é possível ganhar mais em termos de reutilização e produtividade. De acordo com [Stahl e Völter 2006], MDD introduz vários outros benefícios tais como: velocidade de desenvolvimento, qualidade do software, facilidade no gerenciamento de mudanças tecnológicas, entre outros pontos. Diversos estudos na literatura [Kelly e Tolvanen 2008], [Tolvanen 2004], [Kärnä 2009] apontam que o desenvolvimento baseado em modelo não é mais um mito, e sim uma realidade já presente em muitos projetos nas empresas de desenvolvimento de software. Em [Atkinson e Kuhne 2003], os autores definem a infra-estrutura de MDD como sendo formada de conceitos, regras e restrições, além de uma notação formal para a definição de modelos expressivos, adaptáveis e abstratos. Esta infra-estrutura também deve prover meios que permitam a troca de modelos entre plataformas distintas, além de

5 geradores de código inteligentes. Figura 2: Atividades para Solução DSM À Luz deste novo contexto de desenvolvimento, a Modelagem específica de Domínio (DSM) surge como uma solução de duas vias: Em primeiro lugar, eleva o nível de abstração além da programação, especificando a solução em uma linguagem que usa diretamente conceitos e regras de um determinado problema de domínio. Segundo, gera produtos finais em uma linguagem de programação escolhida ou em outra forma, a partir dessas especificações de alto nível [Kelly e Tolvanen 2008]. 4. Solução DSM No intuito de explorar os benefícios advindos do uso de soluções DSM dentro do contexto de SPL, definimos neste artigo, um conjunto de 5 atividades para guiar o desenvolvimento de aplicações. A figura 2 ilustra estes cinco passos Análise de Domínio O analista, durante a análise de domínio, depende de variáveis como sua experiência, percepção, além de necessitar de participação ativa do cliente, para delimitar bem o escopo da aplicação. Nesta fase, as entidades do domínio e das regras de negócio da aplicação são definidas. Também, os relacionamentos entre estas entidades são gerados e, a partir destes, as entidades passam a ser classificadas com entidades fracas, ou entidades fortes. Para se obter mais exatidão na modelagem do domínio, documentações disponíveis produtos pertencentes à mesma SPL da aplicação original são recolhidos para análise. Ao final, se faz necessário a confecção de um relatório listando todos os artefatos, cenários, requisitos discutidos ao longo desta fase Análise de Variabilidade Conforme discutido anteriormente, analisando as entidades em comuns e, consequentemente, as entidades obrigatórias e opcionais entre os produtos dentro de uma SPL, pode- se definir o nível de variabilidade para uma família de produtos. Tomando como ponto de partida o documento da análise de domínio criado anteriormente, e através do modelo FODA, pode-se definir visualmente, ou através de uma estrutura de árvore, todas as entidades, bem como os relacionamentos entre estas, deixando claro o que é obrigatório, opcional ou alternativo. Após esta fase, o modelo criado é a base de todas as possíveis configurações, isto é, para cada aplicação este modelo será sistematicamente refinado, até que a aplicação na plataforma alvo seja alcançada. Vale salientar que, a cada transformação imposta no modelo, este tornará cada vez menos abstrato e, portanto, menos reusável.

6 4.3. Definição da Linguagem Dando continuidade, a próxima atividade corresponde à criação da Linguagem. Baseado no modelo FODA, é possível agora analisar quais as entidades que estarão disponíveis para o usuário, além de definir as customizações necessárias para estas. É nesta fase que restrições relativas ao domínio são criadas. Para tal, a linguagem é especificada através de um metamodelo. Usualmente escritos em UML (Unified Modeling Language) 1, estes metamodelos descrevem abstratamente a sintaxe da Linguagem. Esta fase possibilita verificações sintáticas na definição da DSM, proibindo que configurações inválidas sejam criadas Criação da Ferramenta Gráfica Para que o cliente possa criar, sem maiores dificuldades, sua DSM, a quarta fase visa à criação de uma ferramenta gráfica construída sobre o metamodelo. Neste sentido, um Modelo Gráfico é criado, onde cada entidade passa a ter uma representação visual. É nesta fase também, que ligações semânticas entre o metamodelo e o modelo gráfico são criadas. Portanto, o que é válido no metamodelo será válido no modelo gráfico e precisa ser mantido. Além do mais, podem-se construir paletas para auxiliar o usuário final na criação da DSM. Mensagens de alerta e de erro também são customizadas. Por exemplo, se existe uma ligação mandatória entre duas entidades no metamodelo, e se, ao construir a DSM, esta ligação não for representada, caberá a ferramenta informar que existe o erro Criação do Gerador de Código A automação completa da geração do código final, a partir de modelos de domínio não é totalmente possível, pois para se construir a aplicação final é necessário antes definir o gerador de código. Neste, os templates que definem a estrutura do código fonte são criados. Além disso, é possível também criar otimizações, deixando-o mais acessível para futuras (e inevitáveis) manutenções. Como será observado no estudo de caso, esta atividade é a mais demorada dentre as cinco, uma vez que requer mais cuidados devido à intervenção humana. Em certas ocasiões, o gerador de código pode tornar-se o gargalo da solução DSM, e a tarefa de programar a solução final no desenvolvimento tradicional, pode ser refletido na tarefa de se programar o gerador de código. Assim, é preciso tomar cuidados extras para que esse possa ser expansível, simples, mas não deixando de ser completo Benefícios da Solução A partir da solução DSM descrita acima, podemos listar os benefícios diretos obtidos pelo uso de Modelos de Domínio em dois grandes subconjuntos: produtividade e qualidade: Com relação à Produtividade: Menor Tempo na Entregado do Produto, e esse tempo tende a diminuir a cada novo 1

7 produto, pois a reusabilidade aumenta; Rapidez no feedback para o usuário, uma vez que a análise pode ser feita em nível de modelo (mais abstrato) sem riscos deste não estar sincronizados com o código; Baixo custo no desenvolvimento, pois há ferramentas disponíveis para auxiliar as fases da solução DSM; Fácil Manutenção da Aplicação: a manutenção pode ser refletida de duas formas: adição de novas funcionalidades, e o responsável pela análise de domínio e variabilidade deverá identificar os impactos que a mudança irá acarretar nos produtos SPL; ou correção de erros, sendo realizadas nos modelos, mais simples de entender e alterar; Redução de recursos humanos, pois diminui a necessidade de profissionais experts em programação; Facilidade na imersão de novos desenvolvedores; Com relação à Qualidade: Regras de Corretude no domínio, dificultando a criação de especificações não desejadas; Eliminação de bugs nas fases iniciais do projeto; Geração de código que não precisa ser editado a partir da especificação; Suporte a validações em protótipo. 5. Sistema de Gestão de Estoque: Um Estudo de Caso Um pequeno projeto piloto foi realizado para avaliar o desenvolvimento da solução DSM: um software para gestão de estoque. De forma simples, a gestão de estoques é um sistema de atividades logísticas com foco estratégico e todo o processo produtivo. Isto envolve uma série de entidades, desde o inventário de materiais de transporte, bem como o controle total sobre a logística: quando (segurança), quanto, onde (fornecedores) e como compras os produtos, mantendo o estoque equilibrado, sem falta de produtos, ou em quantidade excessiva. Após a análise de domínio, um documento com as entidades/relacionamentos foi criado. Este documento serviu como argumento para gerar o modelo FODA. O modelo foi criado usando o Eclipse plugin Compositional Variability Management 2 que permite a edição visual ou através de estrutura de árvore. Após a análise de Variabilidade foram obtidos os seguintes resultados: Entidades Obrigatórias: 5 Entidades Opcionais: 4 Entidades Alternativas: 5 Relacionamentos: 20 Além das entidades, é possível associar atributos a estas, o que dá um caráter de infinita variabilidade para a aplicação. Suponha, por exemplo, que uma empresa solicite um aplicativo para gerenciamento de estoque, e exija a presença da entidade Produto. Um produto, por exemplo, pode ter várias peculiaridades, em termos de descrição, preço, data de estoque, embalagem e transporte. Todas essas características são atributos inerentes do 2

8 produto e que podem ser modelados. Nesta perspectiva, defendemos que há infinitas possibilidades de variação. Para desenvolver o metamodelo (Definição da Linguagem), foi utilizado o Eclipse Modeling Framework Project [Dave Steinberg e Merks 2009]. Por razões de propriedade intelectual, apenas uma parte do metamodelo é ilustrada na figura 3(a). Figura 3: Metamodelo (a) e Exemplo de uma DSM (b) Após a conclusão desta fase, a definição da ferramenta gráfica foi feita através do Eclipse Graphical Editing Framework (GEF) 3. O modelo gráfico também foi criado para representar as entidades mapeadas para cada elemento do domínio de aplicação. Tomemos, por exemplo, a entidade Product na Figura 3(b), nada mais do que uma imagem cuja semântica está vinculada à classe Product no metamodelo. Figura 4: Exemplo de Aplicação Com base nesse mapeamento, é possível definir todas as aplicações de estoque que podem ser criadas a partir do Metamodelo, desde que se cumpram todas as restrições expressas. Por exemplo, a multiplicidade mínima entre as entidades Inventory e Product é 1 (um), portanto, em nenhuma circunstância pode ser possível definir um sistema de gerenciamento de estoque, sem a participação da entidade produto. Nessas situações, mensagens de erro (também implantadas nesta fase) deverão alterar as possíveis 3

9 inconsistências e omissões do atual modelo. Na última etapa, o gerador de código foi criado. A linguagem de desenvolvimento adotada foi Java. Sua construção dói realização utilizando o código fonte original. Não foram feitas melhorias como refatoração dos modelos para gerar um código fonte de melhor qualidade que o sistema original. Portanto, espera-se que a estrutura e o comportamento do sistema permaneça idêntica ao do sistema original. A figura 4 mostra um exemplo de aplicação criada, utilizando modelos DSM. Para este caso, a solução continha as entidades de Produto, Fornecedor, Cliente, Grupo e Família. A figura ilustra também o processo de criação de um novo produto, ilustrando os atributos que foram associados a esta entidade (código, nome e descrição). Vale lembrar que tais atributos configuram a infinita variabilidade associada à família de aplicações de gestão de estoque. O tempo gasto para criar o gerador de código foi superior em relação às outras atividades, como pode ser observado na figura 5. Figura 5: Tempo gasto nas Atividades Como resultado preliminar, foi utilizado teste de regressão [Myers e Sandler 2004]: o comportamento gerado pela solução DSM permaneceu o mesmo quando comparado com a solução desenvolvida pela engenharia tradicional. Além disso, pela análise estática do código [Ayewah ET AL. 2008] utilizada para medir acoplamentos e presença de ciclos. Indicou que a estrutura do código-fonte gerado é praticamente mantida em relação ao código fonte original. A figura 6 mostra alguns resultados comparativos entre packages de ambos os códigos. Vale salientas que estes foram desenvolvidos pela mesma equipe, evitando qualquer tipo de viés por utilizar membros com proficiência diferentes. 6. Conclusão A solução DSM pretende ser genérica o suficiente para ser apropriada para qualquer plataforma de desenvolvimento. Com os resultados satisfatórios obtidos até então, este projeto está sendo aprimorado, para que diferentes aplicações possam ser geradas e assim, avaliarmos efetivamente o ganho em reusabilidade, produtividade, e baixo custo. Vale lembrar, contudo, que o desenvolvimento do estudo de caso foi conduzido utilizando plugins na plataforma Eclipse, o que não introduziu nenhum custo financeiro. Ao contrário do que se possa pensar, todos estes se adequaram perfeitamente às atividades, mostrando estáveis e de fácil usabilidade. Também, como dito antes, a partir

10 da análise estática e do teste de regressão, o código da solução DSM manteve-se próximo ao código da aplicação gerada por um desenvolvedor padrão. Figura 6: Resultados Preliminares Finalmente, saliente-se que, em caso da necessidade de gerar a mesma aplicação para uma plataforma diferente, o foco do trabalho será na reconfiguração dos templates do gerador de código, pois os artefatos das etapas iniciais (documentos e modelos) podem ser reutilizados, impactando diretamente na redução dos cursos. Através do estudo de caso, pode-se perceber que a solução está ao alcance de pequenas e micro empresas de desenvolvimento de software. Isto é importante, pois refuta a idéia de que para se manter competitiva no mercado, empresas deste nível precisam investir tanto quanto as grandes software-house. Como trabalho futuro, propomos a implantação de um processo baseado nestas 5 atividades, com seus respectivos marcos, produtos de trabalho e responsáveis, Este processo pode servir como guia de desenvolvimento, auxiliando os analistas desde a concepção até a implantação e manutenção da aplicação. References ABES (2009). Mercado brasileiro de software: Panorama e tendências Technical report, ABES - Associação Brasileira de Empresas de Software. ABES (2010). Mercado brasileiro de software pdf. Atkinson, C. and Kuhne, T. (2003). Model-driven development: a metamodeling founda- tion. Software, IEEE, 20(5): Ayewah, N., Hovemeyer, D., Morgenthaler, J. D., Penix, J., and Pugh, W. (2008). Using static analysis to find bugs. IEEE Software, 25: Bachmann, F. and Clements, P. C. (2005). Variability in software product lines. Technical Report September.

11 Chen, L., Babar, M. A., and Ali, N. (2009). Variability management in software product lines: a systematic review. In SPLC 09: Proceedings of the 13th International Soft- ware Product Line Conference, pages 81 90, Pittsburgh, PA, USA. Carnegie Mellon University. Coplien, J., Hoffman, D., and Weiss, D. (1998). Commonality and variability in software engineering. Software, IEEE, 15(6): Dave Steinberg, Frank Budinsky, M. P. and Merks, E. (2009). EMF: Eclipse Modeling Framework (2nd Edition) (Eclipse). Addison-Wesley Longman, Amsterdam, 2nd re- vised edition (rev). edition. Gandra, A. Setor de software no brasil deve crescer. Kang, K., Cohen, S., Hess, J., Nowak, W., and Peterson, S. (1990). Feature-Oriented Domain Analysis (FODA) Feasibility Study. Kelly, S. and Tolvanen, J.-P. (2008). Domain-Specific Modeling: Enabling Full Code Generation. Wiley-IEEE Computer Society Pr. Kärnä, J., T. J.-P. K. S. (2009). Evaluating the use of domain-specific modeling in practice. Myers, G. J. and Sandler, C. (2004). The Art of Software Testing. John Wiley & Sons. Myllymäki, T. (2001). Variability management in software product-lines. Technical report, Institute of Software Systems, Tampere University of Technology. Technical report 30. SOFTEX (2009). Software e serviço de ti: A indústria brasileira em perspectiva. Technical report, Associação para Promoção da Excelência do Software Brasileiro. Software Engineering Institute, C. M. U. (2010). Software product lines. sei.cmu.edu/productlines/. Stahl, T. and Völter, M. (2006). Model-Driven Software Development: Technology, Engineering, Management. Wiley, Chichester, UK. Tolvanen, J.-P. (2004). Metaedit+: domain-specific modeling for full code generation demonstrated [gpce]. In OOPSLA Companion, pages White, J., Hill, J. H., Gray, J., Tambe, S., Gokhale, A. S., and Schmidt, D. C. (2009). Improving domain-specific language reuse with software product line techniques. Software, IEEE, 26(4):47 53.