Gerenciando Variabilidade e Reusabilidade em Linhas de Produto de Software

Transcrição

1 Gerenciando Variabilidade e Reusabilidade em Linhas de Produto de Software Luiz Carlos d Oleron, Cleyton Mário de Oliveira Rodrigues Centro de Informática (CIn) Universidade Federal de Pernambuco Recife, PE, Brasil Improvess Olinda, PE, Brasil {lcadb, cmor}@cin.ufpe.br Gleibson Oliveira, Lúcio Santos Centro de Informática (CIn) Universidade Federal de Pernambuco Recife, PE, Brasil Improvess Olinda, PE, Brasil {grso, ljfs}@cin.ufpe.br Abstract One of the biggest challenges in software companies is to identify and track changes in deployed solutions among its customers; applications originally similar but that have been customized or extended to serve more specific purposes. Maintenance on a system impacts, potentially, other customers, making an arduous task to manage the process variability without a process-guide, with explicitly roles, activities and artifacts. Recent advances in Software Engineering advocate, on the other hand, the use of engineering driven by models for Software Product Lines, where the management of variability is more intense. This paper presents, therefore, a process that combines the best of both worlds, development driven by models, covering management of variability, thus increasing productivity and reusability of artifacts within a software factory. Index Terms Variability Management, Process, Reuse, Software Product Line. I. INTRODUÇÃO Uma das experiências mais recentes em fábricas de software para acelerar a entrega de produtos/serviços ao mercado, sem impactar os recursos financeiros e humanos é remover do programador o trabalho de construir from the scracth a solução final. Neste novo contexto, ao invés de códigos, os modelos passam a ser os artefatos primários. Basicamente, estes modelos são abstrações em alto nível do domínio do problema a ser resolvido, independente de qualquer plataforma/linguagem de programação, os quais, por intermédio de sucessivas transformações automáticas ou manuais, são refinados até produzir o código final da aplicação. Este novo contexto centrado em modelos, todavia, ainda está longe de atingir a maturidade, devido à falta de ferramentas ou mesmo pelo uso inadequado destes modelos (apenas como documentação contemplativa)[1]. Linhas de Produto de Software (em inglês, Software Product Line-SPL) - conjunto de sistemas de software que satisfaz as necessidades de uma determinada parte do mercado [2] - é uma estratégia de desenvolvimento comumente aplicada para uma ampla gama de produtos. SPL incorpora reusabilidade dentro de uma família de produtos similares. Em contrapartida, Modelos de Domínio (em inglês, Domain Specific Modeling-DSM) é uma ramificação da Engenharia dirigida por modelos, onde são fabricados modelos utilizando uma linguagem de cunho específico, muitas vezes definida pelo próprio programador [3]. Mesmo havendo um conjunto de boas práticas reunindo os dois mundos (SPL + DSM) [4], existe a carência de um processo genérico, que sirva como um guia de atividades bem estruturadas a serem aplicadas sistematicamente, com os seus respectivos papéis, etapas e artefatos gerados. Este trabalho, portanto, apresenta o processo REUSE, fundamentado em um contexto de desenvolvimento baseado em modelos e que contenpla atividades críticas dentro de uma fábrica de produtos de software, como a gerência de variabilidade. O restante do artigo está organizado da seguinte forma. Nas seções 2 e 3, discutimos brevemente todo o arcabouço teórico que fundamenta esta pesquisa. Alguns trabalhos semelhantes são discutidos na seção 4. A seção 5 descreve o processo, utilizando a notação BPMN. Em seguida, na seção 6, nós consideramos um breve estudo de caso e, finalmente, conclusões e perspectivas para trabalhos futuros são discutidas na seção 7. II. DESENVOLVIMENTO DIRIGIDO POR MODELOS E MODELOS DE DOMÍNIO Desenvolvimento dirigido por modelos (em inglês, Model Driven Development-MDD) é um paradigma de desenvolvimento onde os modelos (gráficos ou textuais) não são mais artefatos meramente informais. Enquanto aumenta 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 Volter (2006) [1], MDD introduz benefícios, tais como velocidade de desenvolvimento, qualidade de software e facilidade no gerenciamento de mudanças. Atkinson e Küuhne (2003) [5], definem a infra-estrutura de MDD como: conceitos, regras e restrições do domínio além de uma notação formal para a definição de modelos expressivos, adaptáveis, abstratos, que são facilmente exportados para outras plataformas, além de geradores de código automático inteligentes. À luz do novo contexto de desenvolvimento, DSM emerge como uma solução de duas vias: Em primeiro lugar, eleva

2 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. Em seguida, gera produtos finais em uma linguagem de programação escolhida ou outra forma a partir dessas especificações de alto nível [3]. III. ANÁLISE DE DOMÍNIO: GERÊNCIA DE VARIABILIDADE Gerência de Variabilidade representa a definição do escopo, similaridades e variabilidades entre os produtos de software de uma única família [6], [7]. Esta análise pode ser realizada a nível de componentes, arquitetura, artefatos e até mesmo, casos de teste [8]. Variabilidade pode ser definida como [...] a capacidade de um requisito de se adaptar aos usos em contextos de produtos diferentes que estão no escopo da linha de produtos [9]. Essa idéia se torna mais clara em fábricas de SPL: uma atividade corriqueira no processo de análise e desenvolvimento de soluções [6], [10]. Para a reusabilidade, é necessário analisar o quanto cada produto de uma família difere dos outros da mesma família. Esta análise contempla capacidades da aplicação, arquitetura, requisitos não-funcionais, e até mesmo aspectos tecnológicos. A partir destas semelhanças observadas, é razoável pensar em termos de um modelo abstrato, abrangente, cobrindo todas estes pontos em comum, enquanto permanece longe de qualquer plataforma de codificação. Nestas circunstâncias, Feature-Oriented Domain Analysis (FODA) [11] surge como um método para capturar as variabilidades. FODA pode ser delineado em três etapas: (i) a análise de domínio (por documentações ou aplicações existentes, requisitos, informações do domínio), (ii) extração de similaridades na criação de um modelo genérico e paramétrico, (iii) refinamento do modelo em diferentes aplicações. IV. TRABALHOS RELACIONADOS Bragança e Machado (2007) [12] argumentam que o uso do MDD com SPL traz diversas melhorias, ao avaliar o reuso intra-organizacional através da análise de variabilidade. No entanto, os autores discutem sobre a falta de uma padronização internacional quanto ao método, a experiência e as ferramentas existentes para a otimização da sinergia destas abordagens. Assim, um processo é proposto, conhecido como 4SRS (Four Step Rule set). O processo contempla o estudo da variabilidade e é inteiramente baseado em UML 1. No entanto, o uso de um diagrama de atividades para descrever o processo não reflete todas as informações necessárias, tais como produtos de saída e responsabilidades. Outras obras como [13], [14] preocupam-se em definir os ganhos potenciais com a sinergia entre SPL e MDD. Estes trabalhos também destacam transformações entre modelos e geração de código, mas não se preocupam em definir uma seqüência planejada de etapas e, como e quando (em que situação) técnicas, métodos e ferramentas devem ser utilizadas 1 para alcançar a reutilização, mitigando riscos e, reduzindo custos. Outros trabalhos abordam o uso de MDD e SPL dentro do contexto de MDA (em inglês, Model Driven Architecture) 2, tais como [15] e [16]. Krahn et al. [4] definiu uma série de papéis que podem ser associados com o desenvolvimento em DSM, como desenvolvedor de linguagem, desenvolvedor de ferramentas, e o desenvolvedor da biblioteca e de produtos; além disso, o artigo define as três atividades genéricas para o desenvolvimento de uma aplicação arbritária. Um conjunto de boas práticas para o desenvolvimento de aplicações neste paradigma pode ser encontrado em [3]. De fato, essas políticas de uso e os papéis definidos em [4] serviram como pano de fundo para a criação do processo apresentado neste artigo. No entanto, o objetivo deste processo é ser simples, claro, mas completo o suficiente para que todos os participantes possam facilmente entendê-lo, ajudando a melhorar a comunicação intra-organizacional. V. PROCESSO REUSE Os processos descritos a seguir foram desenvolvidos utilizando o Business Process Model and Notation (BPMN) [17], mantida pela Object Management Group-OMG 3. Entre os principais benefícios que norteou a escolha deste sistema de notação, destacam-se, que ele é compreensível por todos os usuários de negócios, além de ser apto para processos de negócios. O processo, conhecido como REUSE, figura 1, pode ser descrito em termos de cinco macro-processos internos: (1) Análise de Domínio (2) Análise da Variabilidade, (3) Definição da Linguagem (4) construção das Ferramentas Gráficas e (5) Definição do Gerador de Código. Para cada subprocesso, produtos de trabalho são gerados e estes artefatos serão tomados como entrada para as fases subsequentes.nas subseções que seguem, cada sub-processo será detalhado. Pela dimensão do artigo, as figuras foram ajustadas para não prejudicar a legibilidade. A. Papéis Fig. 1. Processo REUSE Os seguintes papéis foram identificados: Analista de Domínio - Especialista para compreender regras de negócio envolvidas na solução; Arquiteto da Linguagem - Desenvolvedor com conhecimento em (meta)modelagem que irá gerenciar o projeto da linguagem para representar o domínio; Desenvolvedor de Componentes - Capaz de encapsular comportamento

3 comum entre os trechos do gerador de código; Desenvolvedor da Ferramenta - Desenvolve ferramentas que aumentam a produtividade do usuário final no uso da linguagem; Desenvolvedor do Gerador - Cria o gerador de código. B. Sub-processos Análise de Domínio: Neste processo, o Analista de Domínio é o responsável pelo conjunto das atividades listadas abaixo. Nesta fase (Figura 2), temos: Entrada Um documento que descreve os requisitos da família da aplicação-alvo (Especificação de Requisitos) e documentação de todos os produtos a serem gerados. Atividades 1. Listar Entidades: Levantamento das entidades do domínio da família dos produtos. Essas entidades são os elementos básicos das regras de negócio que a aplicação representa. 2. Listar Relacionamentos das Entidades: Definir as relações entre entidades do domínio e seu comportamento lógico. As dependências são mapeadas e as entidades são classificadas em forte ou fraca. 3. Analisar Documentação de Componentes de Software da mesma SPL: Analisar a documentação de qualquer produto de software que pertenca a mesma linha de produção. Esta análise permite uma visão superficial da complexidade do cenário. Produtos de Trabalho Documento com uma análise completa do domínio. gerador de código. Essa análise também é feita ao nível da observação e documentação de software. 3. Identificar os requisitos que variam entre diferentes versões do produto: Realizar análise para identificar as necessidades que variam em diferentes versões do produto. Esta análise é realizada ao nível da funcionalidade e da observação da arquitetura e do código fonte. 4. Identificação das variações de restrições em relação ao conhecimento de domínio: Identificar restrições que existem entre a família de produtos de software. Estas restrições serão mapeadas (em actividades posteriores) nos elementos do domínio da linguagem. Inicialmente restrições podem estar em conformidade com o fator da variabilidade (onde o mesmo recurso está disponível com diferentes comportamentos) ou obedecer o fator de inclusão/exclusão (onde o recurso está presente ou não no produto final). Produtos de Trabalho Relatório contendo a análise da viabilidade e da variabilidade do cenário; Definição dos pontos de similaridade e variabilidade da SPL. Fig. 3. Subprocesso da Análise de Variabilidade Fig. 2. Subprocesso da Análise de Domínio Análise da Variabilidade: Todas as atividades deste subprocesso são da responsabilidade do Analista de Domínio (Figura 3). Entrada Mesmos documentos da fase anterior acrescido do Documento com a análise completa do domínio em que a DSM será utilizada. Atividades 1. Identificar os requisitos comuns dentro da linha de produtos: Atividade para identificar os elementos que se repetem em todos os membros da linha de produção de software. Esta análise é realizada a nível de observação e documentação de software. 2. Identificar os requisitos distintos dentro da linha de produtos: Atividade para identificar os elementos que variam dentro da família de produtos. Estas diferenças evidenciam pontos em que a linguagem deve oferecer flexibilidade. Esses pontos também são refletidos no Definição da Linguagem: Todas as atividades deste subprocesso são da responsabilidade do Arquiteto da Linguagem, no entanto, nas duas primeiras atividades, a experiência do Analista de Domínio é ainda valiosa (Figura 4). Entrada Modelo Caraterísticas Variáveis e Similares; Ferramentas usadas para modelar a linguagem DSL. Atividades 1. Define as entidades que estarão disponíveis: Configurar entidades de domínio que serão fornecidas pela linguagem para os usuários finais, além de quais personalizações podem ser realizada para cada entidade (em relação ao comportamento). 2. Define recursos a serem disponibilizados: Definir características ou comportamentos que serão fornecidas pela linguagem para usuários finais e personalizações que podem ser realizadas em cada um. 3. Configuração de restrições da linguagem em relação ao conhecimento de domínio: Definir como os pontos de variabilidade serão apresentados para possíveis alterações na construção de produtos finais de software. 4. Implementar a linguagem usando um metamodelo: Construção do metamodelo da linguagem. Este define a estrutura de linguagem que é utilizada para determinar

4 o comportamento no campo analisado. Produtos de Trabalho Metamodelo da linguagem que expressará o domínio investigado nas últimas etapas. Fig. 5. Subprocesso de Construção da Ferramenta Fig. 4. Subprocesso da definição da linguagem Construção da ferramenta gráfica: Neste quarto passo, o desenvolvedor da ferramenta tem a responsabilidade do subprocesso (Figura 5). Entrada Metamodelo da Linguagem. Atividades 1. Criação do templates do Gerador: Modelo responsável por gerar o código base de plug-ins (edit, editor e testes). 2. Criar Modelo Gráfico: O modelo gráfico contém links para as imagens que farão parte do modelo do usuário final. Este modelo se baseia na definição destas imagens e com a personalização das relações entre as entidades mapeadas no início do projeto. 3. Criação do Modelo de Mapeamento: Este é responsável por implementar a ligação entre o modelo gráfico e do modelo da paleta (o modelo responsável pela gestão/organização da paleta para o usuário final). Neste modelo, é possível especificar quais os elementos da paleta o usuário final terá acesso. Portanto, o metamodelo deve identificar todas as possibilidades e o modelo de mapeamento deve restringir quais as possibilidades que estarão disponíveis para o usuário final. 4. Personalizar o código do plu-in gráfico gerado: Depois de definir todos os modelos e gerar o código do plug gráfico, nós modificamos trechos do código, a fim de melhorar a aparência da ferramenta. As mensagens para o usuário (dicas de ferramenta e mensagens de alerta sobre inconsistências/incoerências) são definidas nesta etapa. Produtos de Trabalho Plug in que representa a ferramenta DSM em produção. Definição do Gerador de Código: As três atividades descritas a seguir são realizadas pelo desenvolvedor do gerador (Figura 6). Entrada Metamodelo da Linguagem. Atividades 1. Definir a granularidade do gerador de código: Definir o nível de abstração do gerador de código. Nesta atividade, a separação entre o código comum e do domínio da aplicação é realizada, por exemplo, formulários para aplicações web, o código específico que contém regras de negócio. O código comum é agrupados em templates que facilitam a reutilização de partes do gerador em outros projetos. Como o gerador de código é também um software, sua arquitetura é passível de estruturação e análise de reutilização. Nesta fase, as inspecções serão realizadas em aplicação da família de produtos para capturar a estrutura do código. Esta estrutura deve ser antecipado pelo gerador, determinando a distribuição do código entre os templates. 2. Implementação dos templates: estes modelam a arquitetura da solução e padronizam o código gerado. A organização torna a estrutura do gerador mais próxima da aplicação, tornando a manutenção mais fácil. Os templates também são agrupados de acordo com a natureza do código gerado, comum ou específico da aplicação. Nesta atividade, a análise é indispensável para a geração de templates mais genéricos para facilitar a manutenção evolutiva. Estes templates genéricos podem ser utilizados para melhorar a estrutura do design do gerador, bem como para incluir recursos genéricos que podem ser ampliados com a adição de novos templates.3. Teste do gerador: nesta atividade, alguns aplicativos são criados e amostras do código são inspecionados para analisar o comportamento final. A variabilidade da solução é testada com a geração de muitos exemplos, analisando a presença ou ausência de certos requisitos. Estes testes endorssam o metamodelo criad, além de testar a exatidão e a completude do gerador de código. Produtos de Trabalho Templates de geração de código responsáveis pela geração do código comportamental final; Aplicação gerada e pronta para a avaliação final. Além dos papéis apresentados ao longo desta seção, os outros são incorporados no processo tradicional de desenvolvimento de software. É oportuno esclarecer que há uma dependência natural entre a linguagem e o gerador de código. Este último pode tornar-se excessivamente complexo se toda a codificação necessária ficar sob sua responsabilidade. Para minimizar este problema, pode-se configurar, manter e reutilizar componentes que podem ser integrados de forma a tornálo mais viável. Assim, para trabalhos futuros, sugerimos um novo subprocesso opcional que cria e reutiliza componentes utilizados pelos aplicativo.

5 Fig. 6. Subprocesso do Gerador de Código VI. ESTUDO DE CASO Um projeto piloto foi realizado para avaliar o desenvolvimento de uma solução utilizando o processo REUSE: um software para estoque e gestão financeira. A gestão de estoques é um sistema de atividades logísticas com um plano estratégico com foco no processo de produção. Isto envolve uma série de entidades, desde o estoque de materiais, transporte, bem como o controle completo sobre logística e quando (segurança), quanto, onde (fornecedores) e como comprar os produtos, mantendo o saldo do estoque em perfeito equilíbrio. Já um sistema financeiro inclui clientes, fornecedores, centro de custo, taxas associadas, transferência de contas, contas a pagar e a receber, reembolso e de período de competência, além das demais regras de negócio (omitidas por questão de espaço). O projeto foi desenvolvido em inglês, por isso, as figuras estão todas na língua inglesa. Fig. 7. Visão Parcial do Metamodelo Após a análise do domínio, um documento com as prováveis entidades e relacionamentos foi criado. Este documento serviu como um argumento para gerar o modelo FODA. O modelo foi criado pelo Plug in Eclipse Compositional Variability Management 4. A Análise da variabilidade foi feita em dois níveis. No nível macro, ou seja, entre os sistemas, podendo haver quatro combinações possíveis: Sistema Gestão de Estoque para Prefeituras; Sistema de Gerenciamento de Estoque para Micro e Médias Empresas; Sistema Financeiro; Sistema de Gerenciamento de Estoque para Micro e Médias Empresas acoplado ao Sistema Financeiro. Não é possível acoplar o sistema financeiro e o sistema de estoque para prefeituras, por incompatibilidades funcionais. No nível micro, isto é, variabilidade à nível de presença/ausência de entidades, os seguintes resultados foram alcançados: para o sistema de estoque foram identificadas 5, 4, 5 e 20 entidades obrigatórias, opcionais, alternativas e número de relacionamentos, respectivamente; para o sistema financeiro, obtivemos 9, 2, 2 e 28, respectivamente. Para desenvolver o metamodelo (Definição da Linguagem), foi utilizado o Eclipse Modeling Framework Project [18]. Uma parte do metamodelo de estoque é ilustrado na figura 7. Por razões de espaço, o metamodelo para o sistema financeiro foi omitido. A definição da (Ferramenta gráfica) foi feita através do Eclipse Graphical Editing Framework (GEF) 5, onde foi criada uma paleta com quatro seções bem definidas: uma lista os sistemas disponíveis, outra os elementos do domínio do estoque, a terceira os elementos do domínio financeiro, e uma quarta seção com os elementos comuns entre os sistemas. Além disso, o modelo gráfico foi criado para representar as entidades mapeadas para cada elemento do domínio de aplicação. Tomemos, por exemplo, a entidade Product na Figura 8: não é nada mais do que uma imagem cuja semântica está vinculada à classe Product no metamodelo. Esta figura representa um exemplo de uma DSM, com as seguintes entidades: Product, Output, Group, Family of Products e Release. Pelo espaço limitado deste artigo, a paleta do sistema foi omitida (do financeiro inclusive). Na última etapa, o o gerador de código foi construído utilizando o código fonte da aplicação original. Não foram feitas melhorias como refatoração dos modelos para gerar código-fonte de qualidade superior ao sistema original. Assim, verificou-se que a estrutura e o comportamento do sistema gerado permaneceu idênticos ao do sistema original. O tempo gasto para criar o gerador de código foi superior as outras atividades. Como resultados preliminares, foi utilizado o teste de regressão [19]. O comportamento gerado pelo sistema de estoque permaneceu o mesmo quando comparado com a aplicação original. Além disso, a análise estática de código [20] para identificar os acoplamentos e a presença de ciclos indicou que a estrutura do do código-fonte gerado é praticamente mantido em relação ao original, como pode ser observado na figura 9. O Gráfico, no eixo horizontal, está dividido em quatro partes: total de classes, classes abstratas, concretas e acoplamento aferentes (afferent coupling). O eixo vertical

6 Fig. 9. Fig. 8. Exemplo DSM Análise Estática do Código do Sistema de Estoque mostra a medição por packages da aplicação (7 no total). O mesmo coportamento foi mantido para o sistma financeiro. VII. CONCLUSÃO O processo REUSE aqui discutido se destina a ser suficientemente amplo para ser adequado para qualquer plataforma de desenvolvimento. Espera-se que o próprio processo facilite a reutilização mesmo entre diferentes aplicações e plataformas. Além disso, em vez de um conjunto disperso de práticas e sem estrutura, foi definido um framework de atividades sincronizadas com os respectivos papéis dos responsáveis e produtos de trabalho, mostrando como cada atividade está em estrita conformidade com as passadas e futuras, tornando-se bastante consistente. No entanto, argumentamos que ainda há muito trabalho a ser feito. Há um projeto em andamento para ampliar o processo com componentes pré-fabricados. Além disso, pretendemos desenvolver um estudo de caso em novas aplicações para analisar quantitativamente os benefícios do uso do processo em termos de manutenção, custo, produtividade e qualidade de software. REFERENCES [1] T. Stahl and M. Völter, Model-Driven Software Development: Technology, Engineering, Management. Chichester, UK: Wiley, [2] C. M. U. Software Engineering Institute, Software product lines, Jun [3] S. Kelly and J.-P. Tolvanen, Domain-Specific Modeling: Enabling Full Code Generation. Wiley-IEEE Computer Society Pr, March [Online]. Available: [4] H. Krahn, B. Rumpe, and S. Volkel, Roles in software development using domain specific modelling languages, in In Proceedings of the 6th OOPSLA Workshop on Domain-Specific Modeling 2006, 2006, pp [5] C. Atkinson and T. Kuhne, Model-driven development: a metamodeling foundation, Software, IEEE, vol. 20, no. 5, pp , [Online]. Available: [6] T. Myllymäki, Variability management in software product-lines, Institute of Software Systems, Tampere University of Technology, Tech. Rep., December 2001, technical report 30. [7] D. H. James Coplien and D. Weiss, Commonality and variability in software engineering, Software, IEEE, vol. 15, no. 6, pp , November [Online]. Available: [8] M. A. B. Lianping Chen and N. Ali, Variability management in software product lines: a systematic review, in SPLC 09: Proceedings of the 13th International Software Product Line Conference. Pittsburgh, PA, USA: Carnegie Mellon University, 2009, pp [9] F. Bachmann and P. C. Clements, Variability in software product lines, Tech. Rep. September, [10] J. Estublier and G. Vega, Reuse and variability in large software applications, in ESEC/FSE-13: Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering. New York, NY, USA: ACM, 2005, pp [11] J. A. H. W. E. N. Kyo C. Kang, Sholom G. Cohen and A. S. Peterson, Feature-Oriented Domain Analysis (FODA) Feasibility Study, [12] A. Braganca and R. J. Machado, Model driven development of software product lines, in QUATIC 07: Proceedings of the 6th International Conference on Quality of Information and Communications Technology. Washington, DC, USA: IEEE Computer Society, 2007, pp [13] K. Czarnecki, M. Antkiewicz, C. H. P. Kim, S. Lau, and K. Pietroszek, Model-driven software product lines, in OOPSLA 05: Companion to the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications. New York, NY, USA: ACM, 2005, pp [14] G. Rushton and R. Baillargeon, Model-driven product line software development process, General Motors Corp., Tech. Rep., [15] K. Garces, C. Parra, H. Arboleda, A. Yie, and R. Casallas, Variability management in a model-driven software product line, Avances en Sistemas e Informática, vol. 4, no. 2, pp. 3 12, [16] I. Schaefer, Variability modelling for model-driven development of software product lines, in VaMoS, ser. ICB-Research Report, vol. 37. Universität Duisburg-Essen, 2010, pp [17] O. M. Group, Business process modeling notation (bpmn) version 2.0, Tech. Rep., June [Online]. Available: [18] M. P. Dave Steinberg, Frank Budinsky and E. Merks, EMF: Eclipse Modeling Framework (2nd Edition) (Eclipse), 2nd ed. Addison-Wesley Longman, Amsterdam, January [Online]. Available: [19] G. J. Myers and C. Sandler, The Art of Software Testing. John Wiley & Sons, [20] N. Ayewah, D. Hovemeyer, J. D. Morgenthaler, J. Penix, and W. Pugh, Using static analysis to find bugs, IEEE Software, vol. 25, pp , 2008.