An approach to variability management in service-oriented product lines

Abstract

Service-Oriented product lines (SOPLs) are dynamic software product lines, in which, the products are developed based on services and service-oriented architecture. Although there are similarities between components and services, there are important differences so that we cannot use component-based product line engineering methods and techniques for SOPL engineering. These differences emerge from the fact that, services can be discovered as black box elements from external repositories. Moreover, services can be dynamically bound and are business-aligned. Therefore, analyzing the conformance of discovered external services with the variability of services in the SOPL -which must be aligned to the variable business needs-is necessary. Variability must be managed, that is, it must be represented (modeled), used (instantiated and capable of conformance checking) and maintained (evolved) over time. Feature Models are insufficient for modeling variability in SOPL, because, services cannot be simply mapped to one or more features, and identification of the mapping depends on knowing the detailed implementation of the services. This research aims at providing an approach to managing the variability in SOPLs so that external services can be involved in the SOPL engineering. This paper presents an overview of the proposal.

Dynamic product line for Business Process Management

“…From 15 related works, containing PL approaches for BPM, which present at least one of these properties, in average they present only two of them. Two of them represent five and four properties of Dynamic PLs (Altintas and Cetin, 2008;Khoshnevis, 2012) but, on the other hand, they could not actually be considered complete PL approaches for BPM, since they encompass, for example, only the first phase of the BPM lifecycle.…”

“…X means in which works each one of the 18 attributes evaluated were found approaches examined here. DyPL4BPM addresses seven dynamic properties, followed by the approaches presented by Altintas and Cetin (2008), addressing five dynamic properties, and Khoshnevis (2012), addressing four dynamic properties. General analysis for all the related works can demonstrate that DynPL4BPM is the most complete one when these comparison criteria are used.…”

An Approach for e-Commerce On-Demand Service-oriented Product line Development

“…It is recommended that a more elaborate case study development would have to be embarked upon to demonstrate SOPL in on-demand contexts. It is desirable that external services be considered in the modelling of product line reference architecture [27], but we assumed in our work that all the product line assets were developed under the control of the developer organization. Further work would have to be done to incorporate third party and external services as part of the variable product line reference model, and their functionalities invoked through the use of APIs.…”

Uma abordagem para gerenciamento de Linhas de Produtos de Software baseada em serviços

“…• Utilização de serviços: A utilização de orientação a serviços também é uma boa opção para promover a interoperabilidade entre ferramentas e facilitar o acesso às funcionalidades da solução. Este é um recurso que não foi encontrado na maior parte das soluções analisadas, com exceção da solução proposta por Khoshnevis (2012).…”

“…,(ACHER et al, 2013),(ALVES et al, 2008),(PEROVICH;ROSSEL;BASTARRICA, 2009),(THAO, 2012),(SELLIER;MANNION;MANSELL, 2008),(ZHENG et al, 2009),(SCHUBANZ et al, 2012),(HOLL et al, 2011),(MENDONCA;BRANCO;COWAN, 2009),(SARABURA;BOWDEN, 2008), (EL-SHARKAWY; KRöHER; SCHMID, 2011a), (SINNEMA; DEELSTRA; HOEKSTRA, 2006), (TANHAEI; MOAVEN; HABIBI, 2010)) preocupa-se em resolver somente um problema, ou seja, auxiliam o gerenciamento em somente uma área bem específica. Além disso, diversas soluções ((AJILA;KABA, 2008) ,(KHOSHNEVIS, 2012),(ACHER et al, 2010),(ROMERO et al, 2013), (EL-SHARKAWY; KRöHER; SCHMID, 2011a), (TANHAEI; MOAVEN; HABIBI, 2010)) possuem uma limitação bem acentuada em relação a sua abrangência em abordar uma área, podendo ser tão específica como gerenciar somente requisitos, por exemplo, e além disso não oferecem possibilidade de extensão ou parametrização para generalizar seu uso.Os autores de um grupo de soluções ((MORENO-RIVERA; NAVARRO; CUESTA, 2011),(SUCCI et al, 2000),(ROUILLÉ et al, 2012),(CIRILO et al, 2012),(ROMERO et al, 2013), (SINNEMA; DEELSTRA; HOEKSTRA, 2006), (BEUCHE; PAPAJEWSKI; SCHRÖDER-PREIKSCHAT, 2004)) declaram que seu uso pode ser muitas vezes mais complexo do que o desejado, visto que para utilizar a solução precisa-se primeiro estudar e dominar bem suas especificações, o que muitas vezes dificulta sua adoção. Além da complexidade, um dos obstáculos também a ser considerado, é que boa parte das soluções analisadas ((SINNEMA; DEELSTRA; HOEKSTRA, 2006), (MUTHIG; SCHROETER, 2013), (MORENO-RIVERA; NAVARRO; CUESTA, 2011),(ROUILLÉ et al, 2012),(SUCCI et al, 2000),(PEROVICH;ROSSEL;BASTARRICA, 2009),(JUNIOR et al, 2005),(CIRILO et al, 2012),(BACHMANN;NORTHROP, ...…”