=Paper=
{{Paper
|id=None
|storemode=property
|title=Modeling Variability, Evolvability, and Adaptability in Service Computing (a vision for future research)
|pdfUrl=https://ceur-ws.org/Vol-688/acota2010_paper3_terbeek.pdf
|volume=Vol-688
|dblpUrl=https://dblp.org/rec/conf/acota/BeekGFZ10
}}
==Modeling Variability, Evolvability, and Adaptability in Service Computing (a vision for future research)==
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
Modelling Variability, Evolvability, and Adaptability
in Service Computing
(a vision for future research)
M.H. ter Beek, S. Gnesi A. Fantechi G. Zavattaro
ISTI–CNR, Pisa, Italy Università di Firenze, Italy Università di Bologna, Italy
{terbeek,gnesi}@isti.cnr.it fantechi@dsi.unifi.it zavattar@cs.unibo.it
Abstract—We present a vision for future research on an oriented systems deliver application functionalities as services
emerging topic in software engineering, namely the synergy to either end-user applications or other services. Their under-
between Software Product Line Engineering (SPLE) and Service- lying infrastructures are called Service-Oriented Architectures
Oriented Computing (SOC). Our aim is to develop rigorous
modelling techniques and analysis and verification tools that can (SOAs). Unlike any earlier computing paradigm, SOC is des-
be used for the systematic, large-scale provision and market tined to exert a continuous influence on modern day domains
segmentation of software services. We foresee flexible design like e-Commerce, e-Government, e-Health, and e-Learning.
techniques with which software service line organizations can In this paper, we present a vision for future research on an
develop novel classes of service-oriented applications that can
easily be adapted to customer requirements as well as to changes emerging topic in software engineering, namely the synergy
in the context in which, and while, they execute. By superposing between SPLE and SOC [6], [12], [20], [22]–[27], [29], [40].
variability mechanisms on current languages for service design, Our aim is to develop rigorous modelling techniques as well as
based on policies and strategies defined by service providers, we analysis and verification tools that can be used for the system-
envision the possibility to identify variability points that can be atic, large-scale provision and market segmentation of software
triggered at run time to increase adaptability and optimize the
(re)use of resources. services. We foresee flexible design techniques with which
software service line organizations can develop novel classes
of service-oriented applications that can easily be adapted to
I. I NTRODUCTION
customer requirements as well as to changes in the context
Product Line Engineering (PLE) is a paradigm to develop in which, and while, they execute. By superposing variability
a family of products using a common platform and mass mechanisms on current languages for service design, based
customization [34]. This engineering approach aims to lower on policies and strategies defined by service providers, we
production costs of the individual products by letting them envision the possibility to identify variability points that can
share an overall reference model of the product family, while at be triggered at run-time to increase adaptability and optimize
the same time allowing them to differ with respect to particular the (re)use of resources. The resulting design techniques and
characteristics in order to serve, e.g., different markets. As support tools will be able to assist organizations to plan,
a result, the production process in PLE is organized so as optimize, and control the quality of software service provision,
to maximize commonalities of the products and at the same both at design- and at run-time. We currently do not aim
time minimize the cost of variations. The product variants can to assist also the early requirements engineering phase of
be derived from the product family, which allows reuse and system modelling; instead, the reader is referred to [20] and
differentiation of products of the family. Software Product Line its references for work on enhancing the i∗ framework with
Engineering (SPLE) is a paradigm for developing a diversity variability modelling capabilities.
of software products and software-intensive systems based
Our concrete proposal is to first focus on the definition of
on the underlying architecture of an organization’s product
the formal modelling framework, with a threefold objective:
platform [11], [38].
Service-Oriented Computing (SOC) has emerged as an 1) the extension of (semi)formal existing notations and
evolutionary new paradigm for distributed and object-oriented languages for SOC with notions of variability through
computing [37], [39]. Services are autonomous, distributed, which increased levels of flexibility and adaptability can
and platform-independent computational elements capable of be achieved in software service provision;
solving specific tasks (ranging from answers to simple requests 2) the definition of a rigorous semantics of variability
to complex business processes) which all need to be described, over behavioural models of services that can support a
published, categorized, discovered, and then dynamically and number of design- and run-time analysis techniques;
loosely coupled in novel ways (composed, orchestrated) so 3) the development of analysis and verification techniques
as to create largely distributed, interoperable, and dynamic that remain effective over specifications with variability
applications and business processes which span organizational points, including situations in which the variability is
boundaries as well as computing platforms. In the end, service- triggered at run-time.
14
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
As a motivating example, consider a case study drawn from In [24] the application of dynamic product line practices
daily academic life, namely a software system that supports the is proposed to facilitate the design of service-based systems.
teaching activities of a university. This system is constituted Atomic services are used to represent basic system features.
by a set of services offered to the teachers, to the students and A composition of such services creates a configuration, which
to the university staff, following a SOC paradigm. Migration is a product of the product line. The requirements of an
of such a system to a different university will introduce some application are modelled in terms of a feature diagram during
changes due to the different governance structure, different a domain analysis phase, while distinguishing between atomic
size, and/or different teaching organization. and composite features. The entire system is built from atomic
A product family, or product line, can therefore be envisaged features, mapped directly onto a set of existing services.
to encompass all possible variants. Hence, a definition of In [29] feature analysis and service analysis are combined
a service-oriented product line is needed. This product line into a method to guide developers to developed service-
definition should be able to cope with static variability, which oriented product lines. While the methods inherits the flexibil-
is confined to deal with the difference between universities. ity from service orientation, it still allows to manage variability
However, the evolution of laws introduce another form of through SPLE techniques. It comes with an architectural model
variability, namely dynamic variability, which needs to be for the systematic development of service-oriented product
addressed in order to make the system adaptable to the lines, and with support for dynamic reconfiguration.
evolution of its environment. We envision to go beyond the state-of-the-art of the con-
nection between SPLE and SOC, with a twofold objective:
II. B EYOND THE S TATE OF THE A RT
1) to provide a full formal model of such connections, with
The SPLE and SOC approaches to software development verification techniques based upon them;
share a common goal: Both encourage an organization to 2) to address run-time adaptability by extending the scope
reuse existing assets and capabilities rather than repeatedly of the flexibility that can be achieved by introducing
redevelop them for new software systems. These approaches variability in service definitions.
enable organizations to capitalize on reuse to achieve desired
benefits such as productivity gains, decreased development
costs, improved time-to-market, higher reliability, and com- III. OVERALL S TRATEGY
petitive advantage. Their distinct goals may be stated as
follows [40]. The primary objective of the research we envision is to
add variability and adaptability to the principles of SOC.
SPLE Systematically capture and exploit commonalities The strategy is, in the first instance, to inherit from SPLE
among a set of related systems, while managing mechanisms to include variability notions in a software arti-
variations for specific customers or market segments; fact. A crosscutting concern is to guarantee basic correctness
SOC Enable the assembly, orchestration, and maintenance assumptions of the provided services, in terms of certain
of enterprise solutions to quickly react to changing desired qualitative and quantitative properties, by means of
business requirements. formal modelling of variability and adaptability. The ratio-
Contributions concerning the connection between SPLE and nale is that families of services should be formally defined
SOC are starting to emerge in the software engineering with a service-oriented description language such as, e.g,
community [6], [20], [22]–[25], [29] and a recent workshop UML4SOA (www.uml4soa.eu), BPEL 2.0 (www.oasis-open.
series [12], [26], [27] examines the connection between SOA org/committees/wsbpel) and/or JOLIE (www.jolie-lang.org),
and SPL approaches with the purpose of answering how the suitably extended to deal with variability and adaptability.
two techniques can benefit from each other. Indeed service- Current service-oriented languages do not support (or support
oriented systems can benefit from SPL’s variation management in a very limited form) the possibility to configure, adapt, and
approaches to identify and design services targeted to multiple reconfigure the specified system. Subsequently, the extension
service-oriented systems. along the same lines of the formal verification techniques
In [6] an approach is proposed to transfer the main pecu- already available for such languages, will provide the possibil-
liarities of a SPL (i.e., asset reuse and variation mechanisms) ity to conduct formal property verification on service-oriented
to service-oriented systems development, in order to realize specifications that include variability.
a service-oriented systems line. In this way, a method is In our vision, variability needs to be investigated from
provided to easily adapt a service-oriented application to several points of view:
different customer needs in changeable environments. The
service-oriented systems line consists of two main phases 1) The formal modelling of variability and evolvability;
using respectively the Business Process Lines concept, that 2) The linguistic mechanisms to express variability in
allows realizing a process variant specifically for the given service-oriented descriptions;
requirements and the Process-Oriented Development paradigm 3) The development of formal verification techniques and
that allows automating this model and transforming it into a tools for service-oriented systems utilizing variability.
service-oriented system. We now provide details on how to pursue these three issues.
15
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
A. Modelling Variability and Evolvability Concerning static variability, we need to investigate the most
effective ways to include constructs in the languages to express
To address the aforementioned crosscutting concern on
so-called variation points, i.e., the points where a single
correctness, we need to provide a formal model of service
service, or a choreography, or an orchestration, admit different
lines that is able to capture the notion of variability, i.e., it
variants. The choice of variants is made at configuration time
is able to express the variations that certain characteristics
(i.e., product derivation time), hence we expect that a single
of services can be subject to. To this aim, the basics of
product respects the syntax of the considered language.
variability modelling need to be investigated in connection
A particular role can be played in this regard by behavioural
with the formal modelling of SOAs.
contracts. Behavioural contracts have been independently in-
A common reference model for the behaviour of a service
troduced in SOC by various authors (see, e.g., [7]–[9] and
in SOC computing is based on Labelled Transition Systems
the references therein), and represent an abstraction of the
(LTSs): A service is defined as a state machine that interacts
expected behaviour of a service according to its main observ-
with its clients and with other services, and such interactions
able features: a notion of compliance is also defined, to verify
may trigger a transition to a different state.
that a service actually presents the abstraction required by the
An extension of LTSs, called Modal Transition Systems
contract. Indeed, the very same definition of contract entails
(MTSs), has been proposed as a formal model for product
a definition of a family of services: the family of all services
families [19], [28], allowing one to embed in a single model
that are compliant to the contract. Hence, one of the possible
the behaviour of a family of products that share the basic
ways to express variability is just an invocation to a service
structure of states and transitions, transitions which can more-
compliant to a contract, leaving free the binding to an actual
over be seen as mandatory or possible for the products of the
service at configuration time.
family. In [17], the MTS concept has been pushed to a more
Regarding dynamic variability, several directions of investi-
general form, allowing more precise modelling of the different
gation can be pursued. For instance, we plan to study two
kinds of variability that can typically be found in the definition
different scenarios: predictable and unpredictable updates.
of a product family.
In general, a dynamic update is triggered by some specific
On the other hand, deontic logics [1], [30], [32], [33],
events indicating the necessity to modify the system. If the
[41] have recently become popular in computer science for
modifications to be applied are known at design-time (i.e.,
formalizing descriptional and behavioural aspects of systems.
they are predictable), then it is possible to program such
This is mainly because they provide a natural way to for-
modifications using mechanisms similar to fault-handling in
malize concepts like violation, obligation, permission, and
standard languages. On the other hand, if the modifications to
prohibition. Intuitively, they permit one to distinguish between
be applied to the system are not known at design-time (i.e.,
correct (normative) states and actions on the one hand and
they are unpredictable), then it is not only necessary to extend
non-compliant states and actions on the other hand. This
the language, but the system architecture needs to be changed
makes deontic logic a natural candidate for expressing the
by adding specific components that we call reconfiguration
conformance of members of a family of products with respect
managers.
to variability rules.
First of all, we can address it by including in the language
A first goal is therefore to establish a common reference evolution hooks, i.e., information on part of the system struc-
model that develops these concepts to fully take into account ture or behaviour on which modifications could be applied,
the peculiarities of SOC and the characteristics of SPLE. allowing the programmer specify points that could be affected
When the modelling of variability in SOC is consolidated, by future system reconfigurations. A reconfiguration manager
the reference model will be extended to address run-time is responsible for catching the events indicating the necessity
adaptability. However, this is a challenging task that can only to reconfigure the system, and then it reacts by applying the
be attacked when the modelling of variability in SOC is fully required modifications to the evolution hooks. In our vision, a
understood (cf. Sect. III-C). reconfiguration manager should follow some update rules that
A second, future goal is to model not only functional can be dynamically modified, thus giving the possibility to
variability but also quality attribute variability in SPLE [16]. inject in the system new adaptation policies that were unknown
In particular, it would be interesting to study how to model at design-time.
and maintain certain Quality of Service (QoS) levels and The dynamic variability logic should be developed sep-
QoS-aware service composition in the presence of variability, arately, e.g., as a set of evolution rules. Such rules could
evolvability, and adaptability [31], [36]. be created/changed after the application has been deployed
without affecting the running application. Evolution should
B. Extending Service-Oriented Languages
be enacted by an evolution manager, possibly composed by
The idea is to investigate the extensions/modifications that different evolution servers. At run-time, such servers should
need to be applied to current service-oriented languages in check the environment conditions and the user needs, control
order to support both static and dynamic variability. It is nec- whether some modification has to be applied to the application,
essary to revisit choreography, orchestration, and behavioural and exploit the evolution hooks provided by the application to
contract languages. reconfigure it.
16
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
Based on the extended languages, also the theories already probability bound. Recent results on the verification of such
developed for choreographies, orchestrators, and behavioural quantitative and qualitative properties on service descrip-
contracts need to be revisited. These three distinct aspects tions [4], [5], [13]–[15], [18] can be adapted in order to be able
of SOC are strictly related. For instance, one could extract to deal not only with single services, but directly with service
from choreographies the behavioural contracts of the involved family specifications. In this way we can factorize both the
services, or verify whether or not an orchestrator respects a time and the cost that is needed to verify products that have
behavioural contract. The theories relating these aspects need been correctly derived from a family definition.
to be revisited in order to cope with variability. A second, related, concern will be the adoption of specific
In particular, variability of the system architecture can be analysis and verification techniques aimed at proving correct
more easily expressed with choreography languages. In the derivations of products from a service family definition [2]. We
case of dynamic variability, in order for the reconfiguration to have already mentioned (in Sect. 3.1) the recent interest raised
take place, the modifications must be applied to the running by deontic logics for the modelling of variability. Indeed,
services. Therefore, appropriate projection functions must be some work [2], [3] has been done on the use of deontic-
defined which can automatically obtain, from the variability style logics for modelling notions of variability in product
expressed with choreography languages, the modifications to family descriptions, in two different directions: characterizing
be applied to the evolution hooks of the relevant services. feature models by direct modelling of constraints over the
Moreover, current behavioural contract theories have to be products of a family, and proposing behavioural extensions
enhanced in order to include also dynamic checks that are able of deontic-style logics. A behavioural extension of a deontic-
to verify, at reconfiguration time, whether or not the modified style logic permits one to express in a unique framework
system still preserves some expected properties such as service both behavioural aspects, using standard branching-time logic
compliance. operators, and static constraints over the products of a family
These proposed enhancements to SOC languages have to (usually a separate expression in a first-order logic is required).
be validated by experimenting them on an existing SOC Proper variants of established model checkers, like CMC
framework, like JOLIE (www.jolie-lang.org). JOLIE is a fully (fmt.isti.cnr.it/cmc), must be defined as automatic verification
fledged orchestration language that already includes some tools for checking such properties.
form of dynamic variability such as the possibility to rebind A third concern is the introduction of run-time adaptability,
service ports or replace internal services. The goal in this which presents a big challenge for the off-line verification
case is to extend JOLIE with evolution hooks, to define a by model checking [10]. This question requires innovative
choreography language for JOLIE applications, and to assess verification techniques and a deep understanding of the re-
the developed behavioural contract theories by applying them lation between sought service properties and variability in the
to this specific JOLIE-based framework. definition of services. For instance, a typical question can be
whether a SOA satisfies a given property, irrespective of which
C. Develop Verification Techniques/Tools
variant has actually been chosen, or of which evolution is
The combination and extension of the ideas underlying the occurring inside the architecture. Finally, variability is used
modelling and verification techniques and tools that have been differently in adaptive system modelling. For product lines,
developed in the SOC domain with those from the SPLE do- a particular set of variants is chosen at compile time (or at
main, will have the aim of developing analysis and verification deployment time) while for an adaptive system variability has
techniques that support design-time verification and validation, to be available and managed also at run-time [35]. A possible
run-time monitoring, and verification of flexible and adaptable way out is thus to represent the product family architecture at
services. The fact that the resulting analysis and verification run-time [21].
techniques should still be effective over specifications with
variability points, including situations of variability triggered IV. A PPLICATION D OMAINS
at run-time, requires particular care. The research activity envisioned in this paper will produce
A first concern is the analysis of abstract properties (quali- innovative elements to be used in the definition of a design
tative and possibly quantitative) both at the level of the family and development methodology for the systematic large-scale
specification and at that of their derived products. Exemplary production of software systems and their market segmentation.
qualitative properties of services are [18]: These innovative elements will consist of the definition of
Availability: a service is always capable of accepting a techniques for the flexible modelling and design of software
request; adaptability, by means of which it will be possible to develop
Responsiveness: a service guarantees a response to each services families. These are new classes of service-based
received request; applications, easily derivable from the definition of the family
Reliability: a service guarantees a successful response to through adaptation to client needs or to modification of the
each received request. specific context for which the application has been deployed.
Quantitative properties instead include QoS properties based We can refer to the motivating example already introduced
on a notion such as cost, as well as classical quantitative in Sect. 1, i.e. a software system that supports the teaching
properties, stating that certain properties hold within a given activities of a university. This system is constituted by a
17
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
set of services offered to the teachers, to the students and by different devices. In this way, this service realized the
to the university staff, following a SOC paradigm. Selling Forever Yours model — one of the objectives of the European
such a system to different universities requires to manage Commission FP7 in ICT — at least as far as data and file
variability due to the different governance structure, different storage is concerned. Cloud Computing aims at the realization
size, and/or different teaching organization of the different of this model also as far as programs and computing power
universities. A product family, or product line, can therefore is concerned. Nevertheless, such systems are subject to an
be envisaged to encompass all possible variants. Hence, a evolution which is far more complex than that in file systems
definition of a service-oriented product line is needed. This (in which only creation, change, and delete operations can be
product line definition is however confined to cope with static performed) as strong dependencies exist among the involved
variability, i.e., differences between universities. However, the software components.
rapid evolution of laws (at least in Italy...) and their following The techniques developed according to the research vision
reception from the university offices can be dealt efficiently outlined in this paper will be applicable in this specific field,
only introducing dynamic adaptability and evolvability. with the aim of facilitating the management of this kind of
Another application domain where we can expect that services, making the user configuration completely automatic,
the proposed advancements can have a favourable impact is and providing the user with tools supporting the update and
that of the so-called package-based software distributions, evolution of the system.
an approach adopted, typically, by FOSS (Free and Open- One can think also of many other fields of applications, in
Source Software) to flexibly manage the different variants which a high degree of configurability and an easy and fast
and versions of a software system, as exemplified by the adaptation are extremely critical. One could consider, e.g., e-
distribution of open-source operating systems like LINUX. Health where hospital services must be highly flexible in order
One of the main challenges for such distributions is the to quickly adapt to specific medical needs, or the emergency
possibility to scale the system to distributed computing plat- management field where the support tools must be quickly
forms, beyond the bound of executing on a single computing exploitable in an always different and unstable context, in
element. In the framework of recent virtualization technologies which run-time adaptability features are clearly needed.
known as Cloud Computing, e.g., the management of virtual In all these application fields, the models, techniques and
machines that support flexible and on-demand computing tools developed according to the vision proposed in this paper
resource offering, such as "Infrastructures as a Service" (IaaS) can achieve significant advantages in terms of development
and "Platform as a Service" (PaaS) turns to be extremely costs, as it will be able to factorize common elements as well
complex. as the verification processes.
Traditionally, the package-based software distributions pro-
vide flexible tools for personalizing and updating the system.
Moreover, they provide tools that support the system adminis- R EFERENCES
trator to design and manage the system. Such tools are based
on a complex interdependency network between packages that [1] L. Åqvist, Deontic Logic. In Handbook of Philosophical Logic, 2nd Edi-
tion (D. Gabbay and F. Guenthner, Eds.), Volume 8, Kluwer Academic,
allow the automatic installation of updates and of new system 2002, 147–264.
components. Normally, as the system executes on a single [2] P. Asirelli, M.H. ter Beek, A. Fantechi and S. Gnesi, Deontic Logics
computing element, such elements should be switched off first for Modeling Behavioural Variability. In Proceedings of the 3rd Interna-
to make new functions available (cold update). This approach tional Workshop on Variability Modelling of Software-intensive Systems
(VaMoS’09) (D. Benavides, A. Metzger and U. Eisenecker, Eds.), ICB
turns out to be impossible in a distributed system. A new Research Report 29, Universität Duisburg-Essen, 2009, 71–76.
approach (hot update), which does not interrupt the system [3] P. Asirelli, M.H. ter Beek, A. Fantechi and S. Gnesi, A deontic logical
functioning, is needed. framework for modelling product families. In Proceedings of the 4th
International Workshop on Variability Modelling of Software-intensive
The definition of mechanisms supporting the update of only Systems (VaMoS’10) (D. Benavides, D. Batory and P. Grünbacher, Eds.),
the relevant components is fundamental for the widespread ICB Research Report 37, Universität Duisburg-Essen, 2010, 37–44.
utilization of emerging technologies such as, e.g., Cloud Com- [4] M.H. ter Beek, A. Fantechi, S. Gnesi and F. Mazzanti, An action/state-
based model-checking approach for the analysis of communication
puting. This technology, based on virtualization, is at the basis protocols for Service-Oriented Applications. In Formal Methods for
of the so-called disappearing computer scenario, according to Industrial Critical Systems—Revised Selected Papers of the 12th Inter-
which computing and storage devices are physically moved national Workshop on Formal Methods for Industrial Critical Systems
(FMICS’07), Berlin, Germany (S. Leue and P. Merino, Eds.), LNCS
far from the end user, and are offered by specific vendors able 4916, Springer, 2008, 133–148.
to deliver computing and storage power as a remote service [5] M.H. ter Beek, A. Fantechi, S. Gnesi and F. Mazzanti, A state/event-
(see, e.g., Google AppEngine and Amazon EC2). based model-checking approach for the analysis of abstract system
properties. To appear in Science of Computer Programming, 2010.
Concerning remote file storage, some services already
[6] N. Boffoli, M. Cimitile, F. Maria Maggi, G. Visaggio, Managing SOA
reached large diffusion, see, e.g., Dropbox (that provides System Variation through Business Process Lines and Process Oriented
storage, sharing and synchronization of files) that in February Development. In [27].
2010 already counted more than 4 million users. One of the [7] M. Bravetti and G. Zavattaro, A Theory for Strong Service Compli-
ance. In Proceedings of the 9th International Conference on Coordi-
aspects that contributed most to the success of Dropbox is the nation Models and Languages (COORDINATION’07), Paphos, Cyprus
possibility to provide the user with a virtual hard disk shared (A.L. Murphy and J. Vitek, Eds.), LNCS 4467, Springer, 2007, 96–112.
18
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
[8] M. Bravetti and G. Zavattaro, Contract based Multi-party Service Com- [24] P. Istoan, G. Nain, G. Perrouin and J.-M. Jezequel, Dynamic Software
position. In Proceedings of the 1st International Symposium on Funda- Product Lines for Service-Based Systems. In IEEE 9th International
mentals of Software Engineering (FSEN’07), Tehran, Iran (F. Arbab and Conference on Computer and Information Technology, IEEE, 2009.
M. Sirjani, Eds.), LNCS 4767, Springer, 2007, 207–222. [25] M. Koning, C.-a. Sun, M. Sinnema and P. Avgeriou, VxBPEL: Sup-
[9] M. Bravetti and G. Zavattaro, Towards a Unifying Theory for Chore- porting variability for Web services in BPEL. Information and Software
ography Conformance and Contract Compliance. In Proceedings of the Technology 51 (2009), 258–269.
6th International Symposium on Software Composition (SC’07), Braga, [26] R.W. Krut and S.G. Cohen (Eds.), Proceedings of the 2nd Workshop
Portugal (M. Lumpe and W. Vanderperren, Eds.), LNCS 4829, Springer, on Service-Oriented Architectures and Software Product Lines: Putting
2007, 34–50. Both Together (SOAPL’08). In Proceedings of the 12th International
[10] E.M. Clarke, O. Grumberg and D.A. Peled, Model Checking. The MIT Software Product Lines Conference (SPLC’08), Second Volume (Work-
Press, 2000. shops) (S. Thiel and K. Pohl, Eds.), Lero, University of Limerick,
[11] P.C. Clements and L. Northrop, Software Product Lines: Practices and Ireland, 2008, 115–147.
Patterns. Addison-Wesley, 2002. [27] R.W. Krut and S.G. Cohen (Eds.), 3rd Workshop on Service-
[12] S.G. Cohen and R.W. Krut (Eds.), Proceedings of the 1st Workshop Oriented Architectures and Software Product Lines: Enhancing Vari-
on Service-Oriented Architectures and Software Product Lines: What ation (SOAPL’09). In Proceedings of the 13th International Software
is the Connection? (SOAPL’07). Technical Report CMU/SEI-2008-SR- Product Lines Conference (SPLC’09) (D. Muthig and J.D. McGregor,
006, 2008. Eds.), ACM, 2009, 301–302.
[13] R. De Nicola, D. Latella and M. Massink, Formal modeling and [28] K.G. Larsen, U. Nyman and A. Wasowski,
˛ Modal I/O Automata for In-
quantitative analysis of KLAIM-based mobile systems. In Proceedings terface and Product Line Theories. In Proceedings of the 16th European
of the 20th Annual ACM Symposium on Applied Computing (SAC’05), Symposium on Programming Languages and Systems (ESOP’07) (R. De
ACM, 2005, 428–435. Nicola, Ed.), LNCS 4421, Springer, 2007, 64–79.
[14] R. De Nicola, J.-P. Katoen, D. Latella and M. Massink, Towards a logic [29] J. Lee, D. Muthig and M. Naab, An Approach for Developing Service
for performance and mobility. Electronic Notes in Theoretical Computer Oriented Product Lines. In Proceedings of the 12th International Soft-
Science 153, 2 (2006), 161–175. ware Product Lines Conference (SPLC’08), IEEE, 2008, 275–284.
[15] R. De Nicola, J.-P. Katoen, D. Latella, M. Loreti and M. Massink, Model [30] A. Lomuscio and M.J. Sergot, Deontic interpreted systems. Studia
checking mobile stochastic logic. Theoretical Computer Science 382, 1 Logica 75, 1 (2003), 63–92.
(2007), 42–70. [31] N.B. Mabrouk, S. Beauche, E. Kuznetsova, N. Georgantas and V. Is-
[16] L. Etxeberria, G. Sagardui and L. Belategi, Modelling Variation in sarny, QoS-Aware Service Composition in Dynamic Service Oriented
Quality Attributes. In Proceedings of the 1st International Workshop Environments. In Proceedings of the 10th International Middleware
on Variability Modelling of Software-Intensive Systems (VaMoS’07) Conference (Middleware’09) (J.M. Bacon and B.F. Cooper, Eds.), LNCS
(K. Pohl, P. Heymans, K.C. Kang and A. Metzger, Eds.), Lero Technical 5896, Springer, 2009, 123–142.
Report 2007-01, 2007, 51–59. [32] L. McCarty, Permissions and Obligations. In Proceedings of the 8th
[17] A. Fantechi and S. Gnesi, Formal modelling for Product Families International Joint Conference on Artificial Intelligence (IJCAI’83)
Engineering. In Proceedings of the 12th International Software Product (A. Bundy, Ed.), William Kaufmann, 1983, 287–294.
Lines Conference (SPLC’08), IEEE, 2008, 193–202. [33] J.-J.Ch. Meyer and R.J. Wieringa (Eds.), Deontic Logic in Computer
[18] A. Fantechi, S. Gnesi, A. Lapadula, F. Mazzanti, R. Pugliese and Science: Normative System Specification, Wiley, 1993.
F. Tiezzi, A Model Checking Approach for Verifying COWS Speci- [34] M.H. Meyer and A.P. Lehnerd, The Power of Product Platforms:
fications. In Proceedings of the 11th International Conference on Fun- Building Value and Cost Leadership. The Free Press, 1997.
damental Approaches to Software Engineering (FASE’08) (J.L. Fiadeiro [35] B. Morin, O. Barais, J.M. Jézéquel, F. Fleurey and A. Solberg, Models
and P. Inverardi, Eds.), LNCS 4961, Springer, 2008, 230–245. Run.time to Support Dynamic Adaptation. IEEE Computer 42, 10
[19] D. Fischbein, S. Uchitel and V.A. Braberman, A Foundation for Be- (2009), 44–51.
havioural Conformance in Software Product Line Architectures. In [36] A.D. Mosincat, W. Binder and M. Jazayeri, Dynamically Adaptive
Proceedings of the 2nd Workshop on the Role of Software Architecture Systems through Automated Model Evolution Using Service Compo-
for Testing and Analysis (ROSATEA’06) (R.M. Hierons and H. Muccini, sitions. In Proceedings of the 9th International Conference on Software
Eds.), ACM, 2006, 39–48. Composition (SC’10) (B. Baudry and E. Wohlstadter, Eds.), LNCS 6144,
[20] P. Grünbacher, D. Dhungana, N. Seyff, M. Quintus, R. Clotet, X. Franch, Springer, 2010, 82–89.
L. López and J. Marco, Goal and Variability Modeling for Service- [37] M.P. Papazoglou, P. Traverso, S. Dustdar and F. Leymann, Service-
oriented System: Integrating i∗ with Decision Models. In Proceedings Oriented Computing: State of the Art and Research Challenges. IEEE
of Software and Services Variability Management Workshop – Concepts Computer 40, 11 (2007), 38–45.
Models and Tools (T. Männistö, E. Niemelä and M. Raatikainen, Eds.), [38] K. Pohl, G. Böckle and F. van der Linden, Software Product Line
Helsinki University of Technology, Software Business and Engineering Engineering: Foundations, Principles, and Techniques. Springer, 2005.
Institute Research Reports 3, HUT-SoberIT-A3, 2007, 99–104. [39] M.P. Singh and M.N. Huhns, Service-Oriented Computing: Semantics,
[21] S.O. Hallsteinsen, E. Stav, A. Solberg and J. Floch, Using Product Processes, Agents. Wiley, 2005.
Line Techniques to Build Adaptive Systems. In Proceedings of the [40] Ch. Wienands, Studying the Common Problems with Service-Oriented
10th International Software Product Lines Conference (SPLC’06), IEEE, Architecture and Software Product Lines. Presented at the 4th Service-
2006, 141–150. Oriented Architecture (SOA) & Web Services Conference, 2006.
[22] A. Helferich, G. Herzwurm and S. Jesse, Software Product Lines [41] R. Wieringa, J.-J.Ch. Meyer and H. Weigand, Specifying Dynamic
and Service-Oriented Architecture: A Systematic Comparison of Two and Deontic Integrity Constraints. Data and Knowledge Engineering
Concepts. In [12]. 4 (1989), 157–189.
[23] A. Helferich, G. Herzwurm, S. Jesse and M. Mikusz, Software Product
Lines, Service-Oriented Architecture and Frameworks: Worlds Apart or
Ideal Partners? In Trends in Enterprise Application Architecture, LNCS
4473, Springer, 2007, 187–201.
19