Desenvolvimento de software orientado a características e dirigido por modelos

Transcrição

1 Desenvolvimento de software orientado a características e dirigido por modelos Rodrigo Reis Pereira 1, Marcelo Almeida Maia 1 1 Faculdade de Computação Universidade Federal de Uberlândia (UFU) Uberlândia MG Brasil rreisp@gmail.com,marcmaia@facom.ufu.br Nível: Mestrado Ano de Ingresso no programa: 2007/1 Previsão de conclusão: 2009/2 Resumo. O desenvolvimento de software orientado a características e dirigido por modelos (FOMDD - Feature Oriented Model Driven Development)[1] é uma abordagem que une FOP (Feature Oriented Programming - programação orientada a características)[4] e MDD (Model Driven Development - desenvolvimento dirigido por modelos)[3]. MDD utiliza modelos para especificação de programas e transformações sobre modelos 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ísticas. 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. Esse trabalho é uma proposta de generalização para o método de FMODD apresentado em [1]. Palavras Chave Desenvolvimento de software orientado a características, modelagem de características, arquiteturas dirigidas por modelos, metaprogramação, linhas de produto de software

2 1. Caracterização do Problema As instâncias de uma linha de produtos de software podem ser diferenciadas pelas capacidades (características) que cada um deles apresenta. Diferentes composições de características levam a diferentes produtos. A modelagem de características 1 é a atividade de especificar a variabilidade de propriedades dos conceitos e suas interdependências através de um modelo [5]. FOP é um paradigma para linhas de produtos de software no qual programas são construí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 sempre 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, Transmissão e opcionalmente Som. Poderíamos gerar dois tipos de modelos de carro: Base (Base = Transmissão Motor), e o outro refinado, composto por Base e Som (Base&Som = Som Base). 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 [1], mostra uma forma de se obter portlets (componentes de portais web) [23] 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 diagrama 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 modelos 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 entã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. No que diz respeito à inclusão de novas características, i.e., refinamento do modelo de características, [1] mostra como a adição de novos estados (PIMs 2 ) no diagrama inicial, é propagada ao longo das fases para os PSMs 3 intermediários e como os modelos base e de refinamento podem ser combinados com o objetivo de gerar uma representação final coerente com as mudanças aplicadas. As cinco transformações em destaque na Figura 1(Modelo de Feature1 Modelo de Feature2, T1 (2), T1 (3), Tn (3) e Tn+1 (3) ) não foram executadas em [1]. Ao invés, a síntese de código foi obtida pela combinação, via FOP, do código gerado para cada uma das partes, i.e., base e refinamento (Figura 1, caminho A). Idealmente, a síntese de código deve ser feita pela transformação do modelo que representa a combinação das características base e refinamento (Figura 2, caminho B) conforme mostrado em [1]. Ainda, dentre os dados de entrada apenas o diagrama de estados é independente de plataforma, os demais (refinamentos manuais) são PSMs e deveriam ser derivados de um ou mais PIMs. A Figura 1 mostra diferentes caminhos possíveis de comutação de elementos para obtenção de código a partir de modelos de entrada. 1 Do inglês feature modeling 2 Do inglês platform independent model modelo independente de plataforma 3 Do inglês platform specific model modelo específico de plataforma

3 Figura 1: Exemplo de processo FOMDD Para a construção de tal mecanismo (Figura 1, caminho B) é necessária a implementação de uma linguagem de especificação de modelos orientada a características com suporte a mecanismos de refinamento, definição de linguagens de domínio específico que permitam a criação de modelos auxiliares de alto nível para configuração do modelo principal, bem como as transformações capazes de traduzir as especificações de alto nível em código fonte. 2. Fundamentação Teórica A principal diferença entre o processo tradicional de desenvolvimento e MDD é que os artefatos gerados ao longo das fases de desenvolvimento de MDD são modelos passíveis de transformação especificados através de DSLs [6], o que sugere altos índices de automação entre as fases. Modelos definem detalhes particulares do projeto de um sistema e podem ser derivados a partir de outros modelos. Neste contexto, o conceito de transformações de modelos é fundamental para a realização dos benefícios decorrentes da abordagem tais como aumento de produtividade, portabilidade e interoperabilidade. Os modelos gerados são utilizados como parâmetros para geração de modelos nas fases posteriores e finalmente geração de código executável (que também pode ser considerado um modelo), preservando, conseqüentemente, a conformidade entre os artefatos das diferentes fases. A Modelagem de Características provê uma representação para expressar a variabilidade e a dependência entre as características. Características são entidades de primeira classe do projeto, que encapsulam representações de programas estruturadas hierarquicamente (como código, arquivos de configuração, etc) e que descrevem em alto nível de abstração os requisitos de um sistema [17]. São criadas/adaptadas em função de um contexto. É considerada a presença de uma característica base (um ponto de partida para os produtos de uma linha) e seu comportamento é refinado por sua combinação com outras características. Esta mudança de comportamento altera a semântica do produto final. Os diagramas de características da Modelagem de Características definem as diferentes possibilidades de produtos a serem gerados a partir de um conjunto de características organizadas hierarquicamente. Em essência, eles definem uma linha de produtos. Na prática, muitas características são independentes de outras, e não modificam os seus estados quando agrupadas. Estas podem ser combinadas sem mudar as demais características. Entretanto, uma característica pode refinar o comportamento de outras existentes ou necessitar a exclusão/substituição de uma outra por questões de incompatibilidade. O resultado de análises como esta é um conjunto de critérios (restrições específicas do domínio) para composição de

4 características, que permite um raciocínio modular e o refinamento sobre as composições. FOP é um paradigma para linhas de produtos de software onde programas são sintetizados pela composição de características. Uma linha de produtos de software define uma família de produtos similares onde as características (ou features) correspondem às funcionalidades que os programas provêem. Logo, se descrevemos, diferenciamos, modelamos programas através de características, então um requisito importante neste contexto é construir programas (ou famílias de programas) através da especificação de características. Batory em [7] apresenta o ambiente AHEAD, baseado em refinamentos sucessivos [10], através do qual programas complexos podem ser construídos pela adição incremental de detalhes (características). A OMG (Object Management Group)[11] é uma organização que define padrões como UML, XMI [11] e MOF [12]. MOF define uma linguagem e um framework para a especificação, construção e gerência de metamodelos independentes de tecnologia. Na busca de um padrão para linguagens de transformação no contexto de MDD, a OMG, define a especificação MOF 2.0 Query, View, and Transformation (QVT) [13], que trata do problema de como traduzir um modelo em diversos artefatos textuais como modelos conceituais, código, especificações de implantação 4, relatórios, documentos, etc. Ela define três linguagens de domínio específico Relações, Núcleo e Mapeamentos Relacionais além de um mecanismo denominado BlackBox (caixa-preta). Relações e Núcleo são duas linguagens declarativas em diferentes níveis de abstração, que contém um mapeamento normativo de correspondência. Os mapeamentos relacionais são definidos por uma linguagem imperativa que estende Relações e Núcleo, e cuja sintaxe provê construções comuns encontradas em linguagens imperativas (estruturas de repetição e seleção, etc). BlackBox permite a integração de bibliotecas e implementações externas de transformações (i.e., não QVT). O esquema geral da arquitetura QVT é mostrado na figura a seguir. Figura 2: Arquitetura QVT Considerando o desenvolvimento de sistemas através de modelos de alto nível e a necessidade de efetuarmos refinamentos sobre estes modelos durante no processo orientado a características, é necessária a existência de mecanismos de composição específicos para cada tipo de modelo a ser manipulado. AHEAD provê mecanismos de refinamento para alguns tipos particulares de artefatos como arquivos Jak (Jakarta uma versão estendida de Java) [17] e XML. Entretanto, para que composições sejam feitas a nível de modelagem, é preciso estender este recurso aos modelos abstratos de representação através da definição de um operador de combinação para os modelos descritos em uma linguagem de especificação de modelos orientada a característica. 3. Caracterização da Contribuição Nosso trabalho visa generalizar o método apresentado em [1] através da especificação de linhas de produto de software pelo uso de modelos independentes de plataforma descritos em UML [11], 4 Do inglês deployment

5 DSLs 5 (como OCL [11]) para definição de restrições arquiteturais sobre o modelo e de configurações em alto nível de abstração, de elementos de arquitetura de código, lógicas de domínio e visão, 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. A principal contribuição pretendida por este trabalho é a definição de um conjunto de operadores de combinação e transformação, que permitam traduzir o modelo de entrada, especificado em uma linguagem de modelagem genérica de alto nível orientada a característica, em código executável. Para a realização do nosso trabalho é necessária a elaboração de uma ferramenta que tome como parâmetros de entrada um modelo base e um modelo de refinamento e retorne o modelo que representa a combinação destes modelos. Dada a disponibilidade de um mecanismo de combinação de arquivos XML no ambiente AHEAD e a existência de diversas implementações disponíveis de linguagens de transformação MDD, baseadas no padrão QVT (como ATL [15] e SmartQVT [16]), aplicáveis a modelos XML, acredita-se poder alcançar nosso objetivo através da definição de um profile UML para modelagem de características (configurável via OCL e representável por XML). Pretende-se obter ao término deste trabalho uma ferramenta de composição capaz de tomar como parâmetros uma especificação concreta de alto nível (segundo o metamodelo de entrada abstrato orientado a características descrito pelo profile UML) representada por um conjunto de arquivos XML e que permita com o auxílio de módulos específicos de plataforma (ex.: arquitetura MVC para portlets) gerar os diferentes produtos descritos pela linha de produtos através de um processo automatizado. 4. Estado Atual do Trabalho Entre os resultados parciais de nosso trabalho consta a elaboração de um profile UML [11], definido por um metamodelo para linguagem orientada a características. A definição deste foi possível por meio do IDE Eclipse [18] e plugins relacionados aos projetos Eclipse Modeling Framework (EMF) [19] e Model Development Tools (MDT) [20], que provêem suporte ferramental para a especificação de modelos UML em formato XML, inclusive graficamente. A figura a seguir mostra o resultado obtido. Figura 3: Profile UML do meta modelo para Modelagem de Características 5 Do inglês domain specific language linguagem de domínio específico

6 Ainda, foram realizados estudos e testes sobre algumas ferramentas, como AHEAD e ATL, úteis à implementação dos operadores de transformação, bem como em ambientes de desenvolvimento MDD (como AndroMDA [21]), com finalidade de observação e experimentação dos métodos e ferramentas atualmente utilizados. Com fundamentação nesses estudos, a arquitetura prevista para a nossa ferramenta é descrita na Figura Trabalhos Relacionados Figura 4: Arquitetura da solução proposta 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 tratarem programas como valores e usarem funções (transformações) para mapear programas para outros programas [8]. FOMDD é a união de FOP e MDD. Nesta abordagem modelos podem ser refinados pela composição de características ou podem ser derivados de outros modelos através de transformações. Em [1] é mostrado um estudo de caso onde modelos especificados por diagramas de estados são combinados pela transformação dos modelos iniciais em modelos intermediários que são combinados a refinamentos manuais e posteriormente transformados em código individualmente para finalmente serem combinados e representarem a nível de código o modelo que representa a união entre os modelos descritos por diagramas de estados. Nossa abordagem difere da abordagem apresentada em [1] pelo uso de uma linguagem geral de modelagem (UML), uso de linguagens específicas de domínio (como OCL) para configuração do modelo de características além de transformações exógenas de modelos (i.e., entre modelos de diferentes DSLs) para síntese de executáveis. Outra abordagem similar, baseada em templates, é proposta em [9]. Uma família de produtos é representada pelo modelo de características e um template do modelo. O modelo de características

7 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 automaticamente. 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 (como a nossa) em que modelos distintos correspondentes a diferentes características são compostos, a abordagem [9] 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). 6. Avaliação de Resultados Para a validação do nosso trabalho será realizado um estudo de caso envolvendo a implementação de um a sistema a ser escolhido usando a abordagem proposta em [1] e usando a abordagem proposta neste trabalho para posterior comparação das duas abordagens em 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, grau de automação e qualidade do produto final. 7. Referências [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] Trujillo, S., Batory, D., and Diaz, O.: Feature Oriented Model Driven Development: A Case Study for Portlets, 29th International Conference on Software Engineering (ICSE 2007), Minneapolis, Minnesota, USA, May 20-26, 2007 Batory, Don, Sarvela, Jacob Neal, and Rauschmayer, Axel: Scaling Step-Wise Refinement, IEEE Transactions on Software Engineering 30(6), IEEE Computer Society, , 2004 Kleppe, Anneke, Warmer, Jos, and Bast, Win: MDA Explained: The Model Driven Architecture: Pratice and Promise, Addison Wesley, April 2003 D. Batory, J.N. Sarvela, and A. Rauschmayer. Scaling Step-Wise Refinement. IEEE TSE, June Czarnecki, Krzysztof, Eisenecker, Ulrich, and Czarnecki, Krzysztof: Generative Programming: Methods, Tools, and Applications, Addison-Wesley Professional, June 2000 Deursen, Arie, Klint, Paul and Visser, Joost. Domain-Specific Languages:An Annotated Bibliography, Batory, D.: Feature-Oriented Programming and the AHEAD Tool Suite, Batory, Don: Program refactoring, program synthesis, and model-driven development, Proceedings of the 16th International Conference on Compiler Constuction (CC 07), volume 4420 of LNCS, Springer, , 2007 Czarnecki, Krzysztof, and Antkiewicz, Michal: Mapping Features to Models: A Template Approach Based on Superimposed Variants, GPCE, , 2005 E.W. Dijkstra, A Discipline of Programming. Prentice-Hall,1976. The Unified Modeling Language. OMG/MOF Meta Object Facility (MOF) 1.4. Final Adopted Specification Document. Formal/ , OMG/RFP/QVT MOF 2.0 Query/Views/Transformations RFP Czarnecki, Krzysztof, Hwan, Chang, and Kim, Peter: Feature Models are Views on

8 [15] [16] [17] [18] [19] [20] [21] [22] [23] Ontologies, In: Software Product Line Conference, 21 24, 2006 ATLAS Transformation Language. SmartQVT. Batory, D. and Lofaso, B. and Smaragdakis, Y. JTS: Tools for Implementing Domain- Specific Languages, In: ICSR '98: Proceedings of the 5th International Conference on Software Reuse, Eclipse IDE. Eclipse Modeling Framework Project. Model Develpment Tools. AndroMDA. O. Diaz, S. Trujillo and S. Perez. Turning Portlets into Services: Introducing the Organization Profile. WWW 2007.