Desenvolvimento de Software Orientado a Características e Dirigido por Modelos Revisitado

(1)

Desenvolvimento de Software Orientado a Caracter´ısticas e

Dirigido por Modelos Revisitado

Autor: Rodrigo Reis Pereira1 Orientador: Marcelo Almeida Maia1

1_{Programa de Pós-Graduação em Ciência da Computação} Universidade Federal do Uberlândia (UFU)

Uberlˆandia – MG – Brasil

rreisp@gmail.com,marcmaia@facom.ufu.br N´ıvel: Mestrado

Ano de ingresso no programa: 2007 ´

Epoca esperada de conclusão: Março / 2010 Etapa conclu´ıda: Defesa da proposta de dissertação

Resumo. O desenvolvimento de software orientado a caracter´ısticas e di-rigido por modelos (FOMDD - Feature Oriented Model Driven Development) [Trujillo et al. 2007] é uma abordagem que une FOP (Feature Oriented Program-ming - programação orientada a caracter´ısticas) [Batory et al. 2003] e MDD (Model Driven Development - desenvolvimento dirigido por modelos) [Kleppe et al. 2003]. MDD utiliza modelos para especificação de programas e transformações sobre mo-delos para s´ıntese de executáveis. FOP é um paradigma para linhas de produtos de software no qual programas são constru´ıdos através da composição de caracter´ıs-ticas. FOMDD propõe que produtos de uma linha de produtos de software sejam constru´ıdos pela criação de modelos compostos por caracter´ısticas e que estes sejam transformados em executáveis. Este trabalho é uma proposta de generalização para o método de FOMDD apresentado em [Trujillo et al. 2007].

Palavras-Chave. Desenvolvimento de software orientado a caracter´ısticas, mode-lagem de caracter´ısticas, arquiteturas dirigidas por modelos, metaprogramac¸˜ao, li-nhas de produto de software.

(2)

1. Introdução e Motivação

Um dos principais objetivos da Engenharia de Software é gerenciar e controlar a complexi-dade dos sistemas. Neste contexto, considerando o baixo n´ıvel de rastreabilicomplexi-dade entre os artefatos utilizados ao longo dos processos tradicionais de desenvolvimento, a crescente com-plexidade dos sistemas e, consequentemente, maior dificuldade na compreensão das estruturas de implementação das funcionalidades dos sistemas, cada vez mais, técnicas avançadas de de-senvolvimento se fazem necessárias para aux´ılio aos profissionais envolvidos tanto nas tarefas de modelagem quanto nas tarefas de codificação [Batory 2003].

No contexto de linha de produtos de software, i.e., um conjunto de produtos que pos-suem funcionalidades em comum, mas que no entanto apresentam outras diferenciadas, a utilização de técnicas capazes de expressar em código fonte a variabilidade de caracter´ısticas de forma modular, tal qual o racioc´ınio de projeto em alto n´ıvel de abstração, é alternativa funda-mental, considerando principalmente a necessidade de refinamento gradual dos sistemas. Uma das alternativas poss´ıveis é o uso do ambiente AHEAD, apresentado em [Batory et al. 2003].

MDD é outro paradigma avançado de produção de software e baseia-se na utilização de modelos e transformações sucessivas entre modelos para obtenção de código fonte. Estas duas abordagens em conjunto formam o núcleo conceitual deste trabalho e o resultado pretendido com esta fusão é um alto grau de automação do processo de desenvolvimento de software.

2. Caracterizac¸˜ao do Problema

As instâncias de uma linha de produtos de software podem ser diferenciadas pelas carac-ter´ısticas (capacidades) que cada um deles apresenta. Diferentes composições de caraccarac-ter´ısticas levam a diferentes produtos. A modelagem de caracter´ısticas é a atividade de especificar a variabilidade de propriedades dos conceitos e suas interdependências através de um modelo [Czarnecki et al. 2000].

FOP é um paradigma para linhas de produtos de software no qual programas são cons-tru´ıdos através da composição de caracter´ısticas. Uma linha de produtos é especificada em função de um dom´ınio de aplicação e considera-se a existência de uma caracter´ıstica base, que representa a estrutura inicial para a aplicação de refinamentos. Por exemplo, considerando uma linha de produtos simplificada para a construção de carros. Considerando que carros fossem obrigatoriamente constitu´ıdos por Motor e Transmissão e opcionalmente por Som. Poder´ıamos obter dois tipos de modelos de carro: Base (Base=Trasmissão •Motor) e um outro refinado, composto por Base e Som: (BaseSom=Base •Som).

FOMDD envolve modelagem e composição de caracter´ısticas bem como a transformação destes modelos com o objetivo final de obtenção do código executável. O estudo de caso apresentado em [Trujillo et al. 2007], mostra uma forma de se obter portlets (compo-nentes de portais web) [D´ıaz et al. 2007] através da utilização de diagramas de estados a serem transformados em modelos intermediários refináveis que antecedem o processo de geração de código. Naquele estudo, o processo de desenvolvimento inicia com a especificação de um di-agrama de estados que representa o fluxo de computação do componente (sendo cada estado a representação abstrata de uma caracter´ıstica), e que é posteriormente transformado em mode-los intermediários, em conformidade com uma linguagem de dom´ınio espec´ıfico para portlets, definindo a estrutura básica de implementação de cada um dos estados, segundo arquitetura de código previamente definida. Estes modelos intermediários são refinados pela combinação com modelos de configuração espec´ıficos de plataforma escritos manualmente, completando a especificação e possibilitando a geração de código funcionalmente completo.

(3)

Figure 1. Adordagem FOMDD de Trujillo, et al.

Este trabalho pretende generalizar o método de FOMDD apresentado em [Trujillo et al. 2007](Figura 1) através da especificação de linhas de produtos de software pelo uso de modelos independentes de plataforma descritos em UML1, DSLs para especificação dos metamodelos a serem usados nos passos intermediários de transformação, modelos adi-cionais de entrada como de entrelaçamento e layout, além de transformações de modelo para combinação (i.e., transformações endógenas) e tradução entre modelos de diferentes tipos (i.e., transformações exógenas), como s´ıntese de código.

3. Metamodelos Propostos

Nossa abordagem utiliza os seguintes modelos abstratos de entrada mostrados na Figura 2 a seguir: Modelo de Dados do Dom´ınio (MD), Modelo de Estados do Dom´ınio (ME), Mode-los de Caracter´ısticas Independentes de Plataforma para o Dom´ınio (DPIM2_{) e para o Produto} (PPIM3) e Modelos de Caracter´ısticas Espec´ıficas de Plataforma para Dom´ınio (DPSM4) e para o Produto (PPSM5_{). Os modelos PPIM e PPSM contém a seleção de caracter´ısticas para um} produto espec´ıfico escolhido a partir das caracter´ısticas do dom´ınio de aplicação presentes em DPIM e DPSM, respectivamente.

MD é caracterizado por tabelas e visões, que contém campos e métodos, além de rela-cionamentos entre as entidades. Sua função é descrever a representação dos dados persistentes do dom´ınio de aplicação possibilitando gerar esquemas de bancos de dados, bem como dirigir a geração de entidades de código para manipulação destes dados. ME é constitu´ıdo por esta-dos que representam telas para interação com o usuário, elementos componentes esta-dos estaesta-dos que representam os widgets que compõe a tela, sub-estados que determinam a configuração de widgets das telas e transições que descrevem o fluxo de navegação entre as telas do sistema (dom´ınio), incluindo comportamento em resposta a eventos.

Os modelos de dados e estados não são orientados por caracter´ısticas. Para possibili-tar a seleção de elementos destes modelos com base na seleção de caracter´ısticas, é necessário relacioná-los às caracter´ısticas do dom´ınio. O modelo de caracter´ısticas DPIM define as car-acter´ısticas independentes de plataforma presentes na linha de produtos e é utilizado como referência para a representação do entrelaçamento entre caracter´ısticas e os elementos dos mo-delos de dados e estados. Esta representação é feita através de momo-delos extras de entrada, que descrevem a relação entre os nomes das caracter´ısticas e os nomes dos elementos dos modelos.

1_{http://www.uml.org/} 2

Do inglˆes, Domain’s Platform Independent Model

3

Do inglˆes, Product’s Platform Independent Model

4

Do inglˆes, Domain’s Platform Specific Model

(4)

Figure 2. Nossa abordagem FOMDD

A partir dos modelos de dados e estados anotados com caracter´ısticas, obtemos através de transformações espec´ıficas uma representação abstrata da arquitetura do sistema, a partir da qual é poss´ıvel iniciar a geração de produtos.

Neste ponto, considera-se inicialmente o modelo de caracter´ısticas PPIM, que descreve a constituição funcional do produto, ou seja, quais são as caracter´ısticas necessárias para a sua realização. Em função destas caracter´ısticas, os elementos descritos na representação abstrata intermediária serão selecionados para tradução em artefatos espec´ıficos de plataforma.

O modelo de caracter´ısticas espec´ıficas de plataforma PPSM (expresso em conformi-dade com DPSM) define o componente de tradução a ser usado para a transformação da especificação abstrata em código fonte orientado por caracter´ısticas.

(5)

4. Transformac¸˜oes

A transição entre cada etapa do processo de geração envolve transformações de modelos. Uma transformação no contexto de MDD é definida como o processo de geração de um modelo des-tino a partir de um ou mais modelos fonte [Kleppe et al. 2003] e podem ser implementadas através de diversos mecanismos como programas executáveis ou linguagens espec´ıficas para definição de transformações como XSLT6, ATL [Jouault et al. 2008], SmartQVT 7, JET tem-plates8_{, etc. Os passos de transformação definidos por nossa abordagem são descritos a seguir.} 4.1. Passo 1: Simplificação dos Modelos de Dados e Estados

Os modelos de dados e estados são entradas para o processo e são definidos através da utilização de diagramas UML estendidos (UML profiles), descritos em XMI. Este passo consiste em simplificar a notação destes modelos, com objetivo de manter apenas informações relevantes ao processo de geração. Ao final desta fase, obtemos os modelos de dados e estado simplificados. A seguir apresenta-se as equações de transformação correspondentes a este passo, onde MD e ME são os modelos de dados e estados, respectivamente e TSimplif yDataM odel e TSimplif yStateM odelsão as funções de simplificação.

SimpleDataModel = TSimplif yDataM odel (MD) SimpleStateModel = TSimplif yStateM odel(ME)

4.2. Passo 2: Geração de Templates de Entrelaçamento

A informação de entrelaçamento entre dados e caracter´ısticas, é definida como uma relação entre os nomes das caracter´ısticas e os nomes dos membros (campos e métodos) das entidades. Da mesma forma, o entrelaçamento entre estados e caracter´ısticas é definido como uma relação entre os nomes das caracter´ısticas e os nomes dos elementos constituintes deste modelo, ou seja, telas, sub-estados, widgets e transições. É esperado que todas as caracter´ısticas se relacionem com um ou mais membros/elementos dos modelos, bem como que cada membro e elemento esteja relacionado com uma ou mais caracter´ısticas.

O objetivo desta fase é gerar templates para facilitar a declaração manual dos pares da relação entre membros/elementos e caracter´ısticas. Abaixo seguem as equações de transformação usando os resultados do Passo 1.

DataModelAnnotationTemplate = TGenerateDataM odelAnnotationT emplate(SimpleDataModel) StateModelAnnotationTemplate = TGenerateStateM odelAnnotationT emplate(SimpleStateModel)

4.3. Passo 3: Entrelac¸amento de Caracter´ısticas com Modelos de Dados e Estados

As relações entre DPIM com MD e ME, declaradas no passo anterior, devem ser incorporadas à estrutura dos modelos de dados e estados simplificados. O resultado ao final desta fase são os modelos orientados por caracter´ısticas.

AnnotatedDataModel = TAnnotateDataM odel(SimpleDataModel,DataModelAnnotations) AnnotatedStateModel = TAnnotateStateM odel(SimpleStateModel,StateModelAnnotations)

6 http : //www.w3.org/T R/xslt 7 http://smartqvt.elibel.tm.fr 8_{http : //www.eclipse.org/articles/Article − J ET /jet} tutorial1.html

(6)

4.4. Passo 4: Gerac¸˜ao do Template de Layout

Os modelos de dados e estados orientados por caracter´ısticas contém informação que possibilita a geração de estruturas espec´ıficas de plataforma, faltando apenas a lógica para os métodos da aplicação e a lógica para estruturação visual de cada uma das telas (visão).

A lógica dos métodos a serem gerados deverá ser adicionada em passos finais do processo, já em notação espec´ıfica de plataforma. No entanto, a lógica de estruturação visual é associada neste passo a cada uma das telas através de um modelo abstrato de layout, que possui nome e um conjunto de elementos identificados, que configuram os containers dispon´ıveis para organização da informação (i.e., widgets). No Passo 6, estes modelos de organização visual serão substu´ıdos por implementações espec´ıficas que devem estar em conformidade com a especificação abstrata.

LayoutTemplate = TState2LayoutT emplate(AnnotatedStateModel)

4.5. Passo 5: Gerac¸˜ao de Modelo da Arquitetura Independente de Plataforma

A partir dos modelos de dados e estados orientados por caracter´ısticas e do modelo com-plementar de layout, é gerado um modelo de arquitetura independente de plataforma. Para esta geração deve ser escolhida uma transformação que define um estilo arquitetural es-pec´ıfico, por exemplo, Model-View-Control [Gamma et al. 1995], Presentation-Abstraction-Control [Buschmann et al. 1996], dentre outros.

Este modelo contém abstrações de elementos de projeto que permitem a geração de artefatos espec´ıficos de plataforma e é a última representação independente de plataforma utilizada no processo.

ArchitecturalArtifacts = THighLevelM odels2Architecture(AnnotatedDataModel, AnnotatedStateModel, LayoutTemplate)

4.6. Passo 6: Aplicação dos Componentes de Tradução PSM

O objetivo desta fase é transformar a notação abstrata em código fonte orientado por carac-ter´ısticas. Para isto o componente, utiliza como entradas as representações de arquitetura ge-radas do Passo 5 e os modelos de caracter´ısticas DPIM e DPSM, que identificam as carac-ter´ısticas do dom´ınio de aplicação e as propriedades dos componentes de tradução dispon´ıveis (Figura 3), respectivamente. Estas propriedades definem especifidades do projeto de código como mostrado no exemplo da Figura 4.

As transformações definidas pelo componente de tradução encapsulam templates descritos em linguagens espec´ıficas de plataforma, para cada tipo de artefato existente na arquitetura, que mapeiam os elementos da representação abstrata de arquitetura (APIM) em elementos de implementação representados através de arquivos JAK e XAK, dispon´ıveis no ambiente AHEAD. A equação a seguir define este passo transformação.

(7)

Figure 3. Modelo de Caracter´ısticas PSM do Dom´ınio

Figure 4. Modelo de Caracter´ısticas PSM do Produto

4.7. Passo 7: Gerac¸˜ao do Template de Produto

Neste passo de geração, a estrutura de arquivos resultante do Passo 6, é combinada através dos mecanismos de programação orientada por caracter´ısticas. Basicamente, consiste na invocação de ferramentas espec´ıficas de combinação para cada tipo de artefato, que irão efetuar a junção de todas as ocorrências de um artefato espec´ıfico, considerando o componenente de tradução selecionado pelo modelo de caracter´ısticas PPSM e sua estrutura de implementação, seguindo ordem pré-definida pelo modelo de caracter´ısticas do produto PPIM.

ProductTemplateArtifacts= TM ergeF OArtif acts(FOTemplateArtifacts,PPIM,PPSM)

4.8. Passo 8: Transformac¸˜oes Finais

Após a combinação das caracter´ısticas espec´ıficas de um produto, pode ser necessário a utilização de transformações extras. No estudo de caso apresentado na seção 5, os arquivos de script(Javascript) gerados, não são diretamente suportados pelo ambiente de programação orientada por caracter´ısticas AHEAD. Dessa forma, foi necessário definir uma notação de representação intermediária XML, para que estes artefatos pudessem ser combinados através da ferramenta XAK. Assim, ao final do processo de combinação, é preciso retornar os artefatos resultantes deste tipo à notação original.

FinalProductTemplateArtifacts = TIntermediateN otation2OriginalN otation (ProductTem-plateArtifacts)

(8)

4.9. Passo 9: Definic¸˜ao e Preenchimentos Manuais

Neste passo final, a lógica dos métodos gerados nas representações espec´ıficas de plataforma deve ser preenchida manualmente.

FinalArtifacts = TM anualM ethodBodyF ill(FinalProductTemplateArtifacts)

5. Estudo de Caso

Para a validação do nosso trabalho está sendo realizado um estudo de caso envolvendo a geração do sistema JavaPetStore9, com o objetivo de comparar nossa abordagem e a abordagem apresen-tada em [Trujillo et al. 2007] com relação aos pontos positivos e negativos, tomando-se como parâmetros de análise a complexidade dos artefatos desenvolvidos, a rastreabilidade entre os artefatos e o grau de automação no processo. Para tal, devem ser desenvolvidos os modelos de caracter´ısticas PIM e PSM para o dom´ınio de aplicação WebStore (Figuras 5 e 3) e para o produto JavaPetStore (que contém a seleção de caracter´ısticas dos modelos de dom´ınio que caracteriza o produto espec´ıfico), os diagramas de dados (Figura 6) e estados (Figura 7) que representam a aplicação (dom´ınio), as definições de entrelaçamento entre dados/estados e cara-cter´ısticas, os modelos complementares de layout e as transformações que definem a transição entre cada passo de geração.

Figure 5. Fragmento do Modelo de Caracter´ısticas PIM do Dom´ınio

O sistema alvo a ser gerado neste estudo é uma aplicação exemplo usada para ilustrar como a plataforma JavaEE pode ser utilizada para o desenvolvimento de aplicações. Mais especificamente, este sistema é implementado seguindo a arquitetura definida pelo framework para aplicações web JSF10_{, estruturado segundo o padrão MVC [Gamma et al. 1995]. Neste} caso, a representação abstrata da arquitetura do Passo 5 é composta por três modelos: Modelo Abstrato (MA), Visão Abstrata (VA) e Controlador Abstrato (CA), que constituem a entrada principal para o Passo 6, onde as abstrações dos elementos de projeto são efetivamente trans-formadas em notação espec´ıfica de plataforma.

O componente de tradução criado para o estudo de caso, é composto por transformações que mapeiam os elementos de uma representação independente de plataforma MVC em e-lementos de código como classes Java (modelo e controlador), JSPs (visão) e Javascripts (controlador), além de arquivos de configuração XML espec´ıficos de JSF. Estas transformações

9

http://java.sun.com/developer/technicalArticles/J2EE/petstore

(9)

Figure 6. Fragmento do Modelo de Dados do Dom´ınio

Figure 7. Fragmento do Modelo de Estados do Dom´ınio

foram implementadas através de templates JET, que definem a estrutura base e de refinamento para cada tipo de artefato, a serem utilizadas de acordo com a ordem de caracter´ısticas do dom´ınio (DPIM) e a intersecção entre caracter´ısticas e elementos dos modelos de dados e estados, presente na abstração de arquitetura por transitividade. As equações seguintes detalham o processo de geração do Passo 6 realizado no estudo de caso, uma vez que as transformações a seguir são espec´ıficas para o estilo arquitetural MVC.

FOModels = TArchitectureM odels2F OM odels (ArchitecturalModel,PPIM,PPSM) FOViews = TArchitecturalV iews2F OV iews (ArchitecturalView,PPIM,PPSM)

FOControllers = TArchitecturalControllers2F OControllers(ArchitecturalController,PPIM,PPSM) FOConfigurations = TArchitecturalArtif acts2F OConf igurations

(ArchitecturalModel,ArchitecturalView,ArchitecturalController,PPIM,PPSM)

6. Discuss˜ao e Trabalhos Relacionados

Refatoração de programas, s´ıntese de software baseada em caracter´ısticas e/ou aspectos, e MDD são áreas disjuntas. Entretanto, todas elas são tecnologias de metaprogramação arquitetural por

(10)

tratarem programas como valores e usarem funções (transformações) para mapear programas para outros programas [Batory 2007].

Uma abordagem similar, baseada em templates, é proposta em [Czarnecki 2005]. Uma fam´ılia de produtos é representada pelo modelo de caracter´ısticas e um template do modelo. O modelo de caracter´ısticas define a hierarquia de caracter´ısticas bem como as restrições em suas poss´ıveis configurações. O template contém a união dos elementos do modelo em todas as instâncias válidas do template (i.e., esqueletos expressos na notação destino para cada uma das poss´ıveis combinações de caracter´ısticas válidas). Uma instância do modelo de caracter´ısticas pode ser especificada pela criação de uma configuração baseada no modelo de caracter´ısticas. De acordo com a configuração de caracter´ısticas, o template do modelo é instanciado auto-maticamente. O processo de instanciação é uma transformação entre modelos de mesma DSL, expressos na notação destino espec´ıfica de plataforma. Em contraste com abordagens baseadas em variabilidade em que modelos distintos correspondentes a diferentes caracter´ısticas são com-postos, a abordagem [Czarnecki 2005] utiliza um modelo que representa a superimposição de todos os variantes cujos elementos estão relacionados a caracter´ısticas através de anotações (i.e., um grande modelo anotado que contém conjuntamente as diferentes possibilidades).

Em [Trujillo et al. 2007] é mostrado um estudo de caso onde modelos especificados por diagramas de estados são combinados pela transformação dos modelos iniciais em modelos in-termediários espec´ıficos de plataforma que são combinados a refinamentos manuais e posterior-mente transformados em código que representa a união entre os modelos descritos pelos diagra-mas de estados. Nossa abordagem difere da abordagem apresentada em [Trujillo et al. 2007] pela utilização de modelos extras de entrada (dados, estados e layout - expressos através de UML e DSLs) para a geração de um modelo de arquitetura independente de plataforma a ser traduzido em código por componentes de tradução PSM descritos a partir de um modelo de caracter´ısticas espec´ıficas de plataforma, que define propriedades do projeto de código como mostrado no modelo da Figura 3. Atualmente, a abordagem proposta neste trabalho não avaliou a composição dos modelos de dados e estados, ou seja, não foi avaliado o caminho B mostrado na Figura 2. Ao invés disso, a composição baseada em caracter´ısticas destes modelos é descri-ta pela seleção de elementos, de acordo com o entrelaçamento de caracter´ısticas definido por anotações nos elementos que constituem cada um destes modelos. Assim, a composição de um conjunto de caracter´ısticas espec´ıfico é configurada pela seleção dos elementos anotados referentes a cada uma destas caracter´ısticas.

Independentemente da abordagem utilizada para combinação dos modelos de alto n´ıvel, a principal diferença entre nossa abordagem e a de [Trujillo et al. 2007], é que a informação que compõe os modelos de entrada no primeiro n´ıvel de transformação, é mais consistente com a caracterização de elementos de implementação, o que mantém alto o n´ıvel de rastreabilidade entre os artefatos do in´ıcio ao fim dos passos de transformação e que possibilita a obtenção de elementos espec´ıficos de plataforma através de transformações MDD, ao invés de refinamentos manuais descritos em linguagens espec´ıficas, diminuindo assim, o grau de intervenção humana no processo de geração. Também, a criação de uma representação abstrata intermediária de arquitetura, possibilita a geração de implementações distintas (i.e., diferentes plataformas) a partir de um projeto único de caracter´ısticas para linha de produtos de software e tradutores espec´ıficos de plataforma.

7. Perspectivas

Neste trabalho apresentamos uma abordagem para generalizac¸˜ao da proposta de FOMDD a-presentada em [Trujillo et al. 2007], que utiliza modelos complementares associados aos

(11)

mo-delos de caracter´ısticas utilizados para expressar a variabilidade de propriedades do dom´ınio de aplicac¸˜ao.

Como complemento a este trabalho, pretende-se ainda avaliar o processo de geração utilizando composição de caracter´ısticas em alto n´ıvel de abstração (caminho B, Figura 2) e ge-neralizar os modelos de entrada utilizados na abordagem para a aplicação da mesma na geração de linhas de produtos que não sejam caracterizados por interação com o usuário através de interfaces gráficas como, por exemplo, servidores de aplicação. Ainda, pretende-se comparar a abordagem desenvolvida com outras abordagens para controle de variabilidade em linhas de produtos de software.

Como trabalho futuro podemos citar o estudo dos benef´ıcios da estruturação dos gera-dores PSM através da composição gradual de caracter´ısticas independentes de plataforma.

References

Batory, D. (2003). A tutorial on feature oriented programming and product-lines. In ICSE ’03: Proceedings of the 25th International Conference on Software Engineering, pages 753–754, Washington, DC, USA. IEEE Computer Society.

Batory, D. (2007). Program refactoring, program synthesis, and model-driven development. pages 156–171.

Batory, D., Sarvela, J. N., and Rauschmayer, A. (2003). Scaling step-wise refinement. In Software Engineering, 2003. Proceedings. 25th International Conference on, pages 187– 197.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Sommerlad, P., and Stal, M. (1996). Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons.

Czarnecki, K. (2005). Mapping features to models: A template approach based on superim-posed variants. In GPCE’05, volume 3676 of LNCS, pages 422–437.

Czarnecki, K., Eisenecker, U., and Czarnecki, K. (2000). Generative Programming: Methods, Tools, and Applications. Addison-Wesley Professional.

D´ıaz, O., Trujillo, S., and P´erez, S. (2007). Turning portlets into services: the consumer profile. In WWW ’07: Proceedings of the 16th international conference on World Wide Web, pages 913–922, New York, NY, USA. ACM.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design patterns: elements of reusable object-oriented software. Addison-Wesley Professional.

Jouault, F., Allilaire, F., B´ezivin, J., and Kurtev, I. (2008). Atl: A model transformation tool. Science of Computer Programming, 72(1-2):31–39.

Kleppe, A. G., Warmer, J., and Bast, W. (2003). MDA Explained: The Model Driven Architec-ture: Practice and Promise. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

Trujillo, S., Batory, D., and Diaz, O. (2007). Feature oriented model driven development: A case study for portlets. In ICSE ’07: Proceedings of the 29th international conference on Software Engineering, pages 44–53, Washington, DC, USA. IEEE Computer Society.