=Paper=
{{Paper
|id=Vol-1867/w1
|storemode=property
|title=Towards an Approach for Engineering Complex Systems: Agents and Agility
|pdfUrl=https://ceur-ws.org/Vol-1867/w1.pdf
|volume=Vol-1867
|authors=Massimo Cossentino,Luca Sabatucci,Valeria Seidita
|dblpUrl=https://dblp.org/rec/conf/woa/CossentinoSS17
}}
==Towards an Approach for Engineering Complex Systems: Agents and Agility==
https://ceur-ws.org/Vol-1867/w1.pdf
1
Towards an Approach for Engineering Complex
Systems: Agents and Agility
Massimo Cossentino, Luca Sabatucci Valeria Seidita
Istituto di Calcolo e Reti ad Alte Prestazioni Dip. dell’Innovazione Industriale e Digitale
CNR, Palermo, Italy Università degli Studi di Palermo, Italy
massimo.cossentino, luca.sabatucci@icar.cnr.it valeria.seidita@unipa.it
Abstract—The way in which we use and conceive modern Promising approaches to engineering complex physical sys-
software systems is changing. Humans/users are becoming more tems like these span from Agile approaches to a new current
and more immersed in today complex systems operation, systems where design time and runtime approach are plunging into
interact in a dynamic fashion with the users and with changing
and dynamic environments. New design paradigms are necessary. each other.
In this paper we propose a first insight to engineering complex In this paper, we propose the use of the framework MUSA
physical systems by employing agility and a framework for self- supported by an agile approach that sees users and agents
adaptive service composition. highly immersed in the design process. Agility let realize the
user inclusion.
I. I NTRODUCTION
The paper is structured as follows: section II outlines
Due to the advancements in computer technologies, we are motivations and challenges of the work from a design point
now drawing near a new era where each of us owns more of view; section III describes the MUSA framework and how
than one computer (or smart or wearable device and so on). it is engaged in including the user in the design loop; section
Computers and devices are more and more interconnected and IV illustrates Agile approaches features and how they may
we are getting used to work and live with them in an active be useful in the complex systems domain; section V focuses
fashion. on the use of MUSA and agility detailing how the use of
Our life is shared and in partnership with the technology. MUSA realize agility; finally in section VI some conclusions
This brings to the necessity of communication, collaboration, are drawn.
cooperation and understanding among different devices and
among users and devices. The everyday life style is deeply II. M OTIVATION
changing and consequently a new way of considering the Engineering and developing complex physical systems
creation and the interconnection of modern software systems is where humans (or users) work together with the system and
arising. Indeed, modern computer and devices must be more they both are immersed and continuously interact with a very
than simple responders; they have to be able to sense and dynamic environment, requires to consider several factors that
anticipate users’ needs in order to support them in the right may be summarized in: changing operational context and
way. Instructions we give to software systems are not passive changing environment. Complex software systems supporting
and plan of actions no more decided at design time. digital economy have to intrinsically exhibit adaptation.
The scenario from now on is: humans work in tandem with A complex (self-adaptive) physical system is a system able
their devices (and software systems). At the same time soft- to modify its behavior in order to respond or to face changes
ware systems have to interact in a proactive fashion in order occurring in the environment it is working on or inside the
to guide and support users on the base of their preferences, system itself. Adaptation depends on all the actors that interact
habits, constraints and contexts they live. with the system, the environment whose changes are affected
Such a kind of situations is common, for instance, in the by and affect the system. The system behavior itself is a source
field of smart cities, e-health, e-commerce, etc. and the open of changes and adaptation. Adaptive behavior is prone to three
challenges are still a lot, from design approaches to standards, types of dependency: actor-dependency, system-dependency
from interoperability to trust and so on. and environment-dependency. These factors are taken into
Software systems where users are included and are part account during the requirement engineering phase of complex
of the system require a high level of adaptivity and self- physical (self-adaptive) systems.
organization. Classic design approaches are not suitable for Different kinds of approaches for engineering self adaptive
analyzing, designing and developing software systems sup- systems exist, they span from control theory to service oriented
porting users in the cited scenarios where, in a few words, and from agent-based approaches to nature inspired ones. They
main features are: continuous changing operational context all map to the four MAPE activities - well known in the field
and changing environment. We have to change the way in of Autonomic Computing - Monitoring, Analyzing, Planning
which we look at software development. and Executing.
2
A promising approach to manage complexity in runtime terconnected and various than before, designers have not
environments and to implement MAPE activities is to de- the right means to anticipate and design interactions among
velop adaptation mechanisms that involves software models. different components, and interactions among users and the
This is referred to as models@run.time [3]. The idea is to system. Indeed, (self-adaptive) software system properties are
extend the model produced using MDE approaches to runtime effectively known only when all the relationships among
environment. The authors of [3] emphasize the importance the software components and between the software and the
that software models (artifacts) may play at runtime stating environment have been expressed and have been made explicit.
that if .....“a system changes, the representation of the system Such issues have to be dealt with at runtime; modeling and
(the models) should all change, and viceversa”. In so doing, monitoring users and the environment is the key for enabling
researchers in this field stop at artifact levels; they wish artifact software to be adaptive [11], [7]. Self-adaptation deals with
produced were tied to the process used for creating them. requirements that vary at run time. Therefore it is important
However at the best of our knowledge this is still a vision, that requirements lend themselves to be dynamically observed,
an idea and nothing has been really realized for really putting i.e., during execution.
the design phases at runtime. We are moving into a new era of research for engineer-
Baresi et al. [2] introduce the need of bringing near the ing complex (self-adaptive) physical systems. A new design
design time to the runtime: “The clear separation between paradigm is necessary for enabling the design and development
development-time and run-time is blurring and may disappear of systems that adapt their behavior at runtime with little, or
in the future for relevant classes of applications”. This allows better, no human intervention.
some changing activities to be shifted from design and devel- This paper attempts at framing some characteristics related
opment to run time and some changing responsibilities to be to engineering complex physical systems by merging Agile
assigned to the system itself instead of to the analysts or de- approach to design at runtime. This is a first experiment to
signers. Thus realizing and really implementing adaptation [1], engineering complex systems and exploit the lessons learnt
[6]. on the use of self-adaptive composition of services in dynamic
Hence, requirements engineering has to deal with require- and distributed environment by means of MUSA (Middleware
ments that change at run time, for instance as the result of for User-Driven Service Adaptation).
changing in the environment. Uncertainty and incompleteness
are at the base of requirements engineering for complex III. A M IDDLEWARE FOR U SER - DRIVEN
(self-adaptive) physical systems [11], [7]. Some researchers S ELF -A DAPTATION (MUSA)
investigated the use of a goal model for specifying behavior The Middleware for User-driven Self-Adaptation (MUSA)
and requirements [14], [10] and for supporting the modeling has arisen for managing evolution and adaptivity of dy-
of adaptation mechanism instead of implementing adaptation namic workflows [19]. Compared to traditional languages (e.g.
at run time. BPMN and BPEL) MUSA provides a wider space of solution
The life cycle of a complex (self-adaptive) physical system, that improve the freedom of action when it is necessary
or of one of its components, starts with its design and does to overcome exceptional events such as failures or resource
not terminate with its deployment and testing. The life-cycle unavailability. The authors adopted the solution of relaxing
continues with some monitoring phases aiming at identifying the high constrained workflow specification to increase the
and handling new or emergent requirements and/or needs from flexibility in dynamically generating alternative solutions.
users. The key concept is a clear separation between ‘what the
Classic heavyweight methodologies cannot be used anymore system has to address’ and ‘how it will operate for addressing
for engineering and developing such a kind of systems in fact, it’. The enablers of the MUSA vision are: a) representing the
normally, they prescribe a very disciplined process that follows two dimensions, what and how, as a couple of run-time arti-
a well specific life-cycle; the main aim is to make the software facts (respectively goals and capabilities); b) implementing a
development as more predictable as possible. In these cases reasoning system for dynamic binding of capabilities to goals;
all the requirements have to be identified and analyzed in the c) representing goals and capabilities with some formalism,
very early activities of the design process and transformed based on a common grounding semantic.
into code through whatever life cycle the designer considers The result is a multi-agent system, implemented in the
more useful (waterfall, iterative and incremental and so on). Jason [4] agent-oriented programming language.
This way of working has been well established for years for
all those systems that do not require particular changes. What A. What: a Declarative Specification of Goals
we mean is: normally, a software system is the solution to The characteristics of being autonomous and proactive make
a problem, regardless the level of complexity of the problem the agents able to explore a solution space, even when this
and the software, and the level of adaptability to changing space dynamically changes or contains uncertainty.
requirements is managed at design time using ad-hoc life Indeed, MUSA accepts, at run-time, requirements as a set
cycles or process models. of goals to be addressed [21].
Due to the features of complex (self-adaptive) physical The main language for goal injection is GoalSPEC, based on
systems and the fact that, nowadays, systems are more in- the natural language, and specifically conceived to be attractive
3
for a business audience. This language allows for describing through this space. Therefore self-configuration is defined as
workflows as a set of the user’s goals that are delegated to the a space search problem.
management system. Actually, the automatic reasoner is not a property of a single
GoalSPEC supports Adaptivity because it is intended to agent, but rather it is a social ability of all the agents of the
make the business goals explicit in the process. Goals do not system. Indeed, the algorithm is distributed and decentralized
specify how to operate, but they rather define the expected (for details see [20]).
results.
GoalSPEC also supports Evolution because business pro- D. The Self-Adaptation property
cesses change during the time. This could happen because of The main advantage of using MUSA for executing work-
the introduction of new business goals (laws to be respected flows is the ability to self-adapt the running instance when
or new desired functionalities). Whereas, traditionally, all the something unexpected happens. The self-adaptation property
revisions imply to check inter-dependencies among process’s is based on the feedback loop [5].
tasks, with a consequent hard work of maintenance, MUSA In MUSA, the feedback loop is composed of two nested
accepts run time variations in the set of injected goals. loops. The inner loop is a traditional MAPE-K loop [7] where
In the last years, MUSA and GoalSPEC have been used the activities are: Monitor, Analyze, Plan, and Act. This loop is
in many different application domains, from document man- responsible for managing the periods of stability of the system.
agement systems, smart travel planning, to cloud application During this time the system tries to run a specific workflow
mashup. The design activity necessary for instantiating the configuration. Local task replacement may be enacted for
system in a specific domain includes the definition of an ensuring the continuity of service.
ontology/conceptual diagram. However, it is possible that some severe malfunctioning
occurs and that the monitor reveals a violation of requirements
B. How: a Declarative Specification of Capabilities forces the system to stop working. The system becomes un-
The concept of capability is a mixture of planning ac- stable and some fixing is necessary. These events are captured
tions [8] and services (or micro-services [16]). MUSA respects by the outer adaptation loop. In this case the system blocks
this dual nature by separating the abstract capability – a any capability concerning the current execution and executes a
symbolic description of the effect of the action – and the new self-configuration phase. The result may be a totally new
concrete capability – a small, independent, composable unit workflow instance to be executed for replacing the previous
of computation that produces some concrete result. one.
The capability supports self-adaptation because it is not The outer loop also monitors the goal injection, retrieving
specific for a given goal, but it can be reused for addressing cases in which the running workflow is obsolete with respect
several ones. It also is implemented for explicit fault isolation. to the new injected goals. Also in these case the system’s
Moreover, we focus on the idea that capabilities make it objective is that of switching from a workflow configuration
easier to deploy new versions of the software frequently. to another one that is able of addressing the new set of goals.
Indeed, providing capabilities as run-time entities constitute
the basis for continuous data exchange between human and
agents and therefore system evolution. Moreover, each capa- IV. AGILITY AND C OMPLEX ( SELF - ADAPTIVE ) S YSTEMS
bility is relatively small, and therefore easier for a developer Agile is not strictly a methodology, it is more a way of
to implement. It can be deployed independently of other conceiving working in teams. Agile movements were born
capabilities. By separating the overall functionality through and are operating for exploring new alternatives to traditional
capabilities, it is easier to organize the overall development software development. Proponents of Agile approaches think
effort around multiple teams. that software development process can adapt to changing
and dynamic operational conditions, imposed by variable and
C. Self-Configuring a Solution unpredictable environment, by putting emphasis to actual
MUSA provides an automatic reasoner that, at run-time, working code [13]. In this way Agile allows people to act in
configures the workflow by associating available capabilities response to uncertainty and unpredictability through iterations,
to the injected goals. increments and feedbacks.
The approach is possible because both goals and capabilities Agile is an efficacious alternative to traditional software
are first-class entities to be used within agent deliberation. sequential development. Agile development paradigm is well
An agent requiring to address an unanticipated goal must suited to the design of systems where requirements contin-
decide which capability (or combination of capabilities) have uously change. Requirements changing is, in the case of
to execute. the system we are considering here, due to uncertain and
The automatic reasoner selects and associates capabilities dynamic development environments resulting from: evolv-
according to the goals that are injected [18]. The basic idea is ing technologies, changing customer requirements and other
that of exploring a space of solutions, where goals represent changes related to the analysis and design phase. All the
points of the space that must be reached, and the abstract existing Agile approaches face changes with incremental and
capabilities provide evolution functions that allow moving small software releases, with highly adaptation to sudden or
4
Design Time Runtime
System Design (offline)
New
Execution and
Requirements
Monitoring
Requirements System Design Acquisition
Analysis (online)
able to
no re-plan yes
MUSA
Minimal human system is
intervention autonomous
feedback loop
Fig. 1. Designing complex self-adaptive systems employing MUSA and Agility
last moment changes and with the production of the amount bring to the illustration on how its use is agile.
of documentation necessary only for learning and modifying.
V. D ESIGNING C OMPLEX S ELF -A DAPTIVE S YSTEMS
So how and why talking about agility in the context of
E MPLOYING MUSA AND AGILITY
complex (self-adaptive) physical systems and agents? In [9]
the author states that lightweight methodologies, including XP Using the MUSA framework allows to include the user
and Agile, “include some concepts and principles of natural in the design process by employing the following agents:
complex systems”. The main principles of natural complex discovery agent, specification manager, negotiator, worker e
systems (see [17] for a literature review) are: case manager; moreover it partially realizes the design time at
run time [18].
• open systems and inner interactions - complex adaptive
Fig. 1 is intended to explain which are the main activities to
physical systems are open systems exchanging informa-
be performed when developing an application with MUSA.
tion in open and dynamic environments and components
The process is divided in two parts, the first one (the left
of the systems interact dynamically each other. Interac-
block in the figure) includes the standard design activities
tions affect the overall behavior of the system.
(Requirements Analysis and System Design) for developing
• feedback loop and emergent behavior - changes in some
a first release of an application. During the very first step,
parts or components of the system result in changes in
the system design activity is performed “offline”, hence re-
other parts or in the whole system.
quirements are captured and analyzed in a quite common and
• distributed control - control is distributed through the
standard fashion and then they are converted in the design of
system.
the multi-agent system underpinning MUSA. During the first
• emergent behavior - features of the system and its be-
execution at runtime (the first specific workflow configuration)
havior in its whole cannot be described and understood
the system starts to monitor the environment and each time a
only looking at the single components, a holistic vision
change occurs, a new requirement or a need, then the system
is necessary, interactions among components let the be-
tries to re-plan. If re-planning is possible then the system goes
havior arise.
on in its work and continues the executing and monitoring
These principles perfectly fit agile practices, the most im- phase otherwise the system searches for a new solution. An
portant one is that Agile greatly focuses attention on the “online” system design is performed, users and agents in
continuous open interaction among all the involved stakeholder MUSA collaborate in order to find a new solution at run
of the system. So, our hypothesis is: complex physical system time as explained in the previous section. The design phase is
involves software components and users both at run time and immersed in the run time one, agents and users work in team.
design time. If we consider the complex adaptive physical During the “online” System Design the presence of agents lets
system and its design process as it were a whole, as if one users apply a minimal intervention thus enhancing adaptation.
were an integral part of the other then we may apply the Agile Moreover, the team formed by agents and users, during the
principles. Agile principles assure us to use one of the best implementation of the feedback loop, apply an agile approach
approaches for engineering self-adaptation [12], [15]; agents, that, as said in section IV, gives a means and is one of the most
in some moments of the software development, are “agilists”. promising approaches for designing and developing complex
Users are included in the design process with the support of (self-adaptive) systems.
the multi-agent system from which MUSA is made. In the In the following we analyze the Manifesto for Agile Soft-
following we give an overview of the MUSA framework in ware Development1 with respect to the rationale underpinning
order to let understand how it (by means of agents) support
in the developing and enacting a software application and to 1 http://agilemanifesto.org
5
TABLE I
MUSA FEATURES SUPPORTING AGILITY
Agile Manifesto MUSA general Features
Early and continuous delivery of valuable software. The Proactive Means-End-Reasoning for producing plans allows to create
soon a working software and to continually update it by (re)starting from
a set of goals and capabilities. (See also the following principle).
Deliver working software frequently with a preference to the shorter Once a new set of goals is specified, MUSA, by means of the injection
timescale. technique, allows to produce new portions of working software. (See also
the previous principle).
Business people and developers must work together daily throughout the Regardless of the role played by agents or humans in the MUSA loop, the
project. use of goals allows to specify the business logic of how services have to
be composed thus realizing the continuous collaboration among business
people and developers.
Give projects the environment and support they need, and trust the job will Capabilities and goal specifications are compliant with the conceptualiza-
be done. tion of the environment.
Working software is the primary measure of progress. MUSA, by means of the solution explorer agent, checks in the space of
solutions if the new set of goal has been reached.
Agile processes promote sustainable (all the involved stakeholder maintain The use of MUSA as a middle layer, for realizing design process at runtime,
a constant pace) development. Simplicity–the art of maximizing the amount allows of some part the process to be made automatic thus reducing the
of work not done–is essential. amount of work to be done and documentation to be produced.
The best architectures, requirements, and designs emerge from self- The core of MUSA collaboration issues is guaranteed by the holonic ar-
organizing teams. chitecture. Holons allow self organization among, distributed coordination
and knowledge sharing.
Frequently tuning and adjusting team’s behavior for becoming more With regard to the team composed both by agents, holons continuously
effective. know the state of the environment and so they are able to reach all the
new goals by organizing and self adapting their behavior.
the use of MUSA: right column shows which MUSA’s feature helps in putting
Individuals and interactions over process and into practice agility.
tools VI. C ONCLUSION
MUSA interacts with its environment. There is no Actually, complex physical (self-adaptive) systems are re-
need to follow a rigid design process and the pres- quired to be much more than simply an ensemble of interacting
ence of MUSA guarantees that the user is the center components; components are not only intertwined but they
of design/runtime as well as interaction between form a unique ensemble of persons, technologies, organi-
users and software. zations and environmental contexts. Environment, moreover,
Working software over comprehensive documen- could involve laws and rules regulating the social interactions
tation and the interaction of people with the technology. Humans
Using MUSA does not imply to produce documen- are immersed together with devices in a highly dynamic
tation; the only useful documentation is the one for environment where a great amount of data and services are
describing the environment through the ontology and constantly available. It is unthinkable that a human user were
for the newly introduced capabilities and goals. able to act in such a kind of environment and to consciously
Customer collaboration over contract negotiation handle all the offered possibilities.
Considering the runtime phase as part of the design Standard analysis and design of systems with these extended
process, the user and the customer are at the center features are more challenging than ever, mainly because the
of MUSA activities; the customer collaboration starts behavior of system components depends and have to be
with the definition of the requirements and contin- specified in terms of their interactions and communications
ues during the execution with advising new goals. with the physical environment. Moreover, interactions and
Negotiation happens at run time with a pay per use communications are affected by environment dynamics at
criterion, it is automatic and has a minor importance runtime.
with respect to collaboration. Inspired by models@runtime [3] research line and by Baresi
Responding to change over following a plan et al. [2] that suggest to reduce the boundary gap between
No plans are pre-defined but the system is made able design time and run time, we propose the use of MUSA
to configure itself at runtime each time a change along with some Agile design activities that see users and
occurs. agents highly included and immersed in the design process.
In Table I, we show how the principles behind the Agile Agility allows to realize user inclusion and to provide a means
Manifesto2 are met by using MUSA, both during the self- for establishing a design approach that adapt and evolve at
adaptive system development and its running. In the left run time while new requirements arise from the continuous
column the principles of Agile Manifest are summarized, the interaction among users and dynamic environment.
What we illustrate here is a first experiment towards en-
2 http://agilemanifesto.org/principles.html gineering complex (self-adaptive) physical systems; it was
6
helpfulfor gaining useful insights on design activities in order [21] Luca Sabatucci, Patrizia Ribino, Carmelo Lodato, Salvatore Lopes,
to complete the development of a design methodology for and Massimo Cossentino. Goalspec: A goal specification language
supporting adaptivity and evolution. In International Workshop on
complex systems we are working on. Engineering Multi-Agent Systems, pages 235–254. Springer, 2013.
R EFERENCES
[1] Jesper Andersson, Luciano Baresi, Nelly Bencomo, Rogério de Lemos,
Alessandra Gorla, Paola Inverardi, and Thomas Vogel. Software engi-
neering processes for self-adaptive systems. In Software Engineering
for Self-Adaptive Systems II, pages 51–75. Springer, 2013.
[2] Luciano Baresi and Carlo Ghezzi. The disappearing boundary between
development-time and run-time. In Proceedings of the FSE/SDP
workshop on Future of software engineering research, pages 17–22.
ACM, 2010.
[3] G. Blair, N. Bencomo, and R. B. France. Models@ run.time. Computer,
42(10):22–27, Oct 2009.
[4] Rafael H Bordini, Jomi Fred Hübner, and Michael Wooldridge. Pro-
gramming multi-agent systems in AgentSpeak using Jason, volume 8.
John Wiley & Sons, 2007.
[5] Yuriy Brun, Giovanna Di Marzo Serugendo, Cristina Gacek, Holger
Giese, Holger Kienle, Marin Litoiu, Hausi Müller, Mauro Pezzè, and
Mary Shaw. Engineering self-adaptive systems through feedback
loops. In Software engineering for self-adaptive systems, pages 48–70.
Springer, 2009.
[6] Jim Buckley, Tom Mens, Matthias Zenger, Awais Rashid, and Günter
Kniesel. Towards a taxonomy of software change. Journal of Software
Maintenance and Evolution: Research and Practice, 17(5):309–332,
2005.
[7] Betty HC Cheng, Rogerio De Lemos, Holger Giese, Paola Inverardi, Jeff
Magee, Jesper Andersson, Basil Becker, Nelly Bencomo, Yuriy Brun,
Bojan Cukic, et al. Software engineering for self-adaptive systems: A
research roadmap. In Software engineering for self-adaptive systems,
pages 1–26. Springer, 2009.
[8] Michael Gelfond and Vladimir Lifschitz. Action languages. Computer
and Information Science, 3(16), 1998.
[9] M Gerber. Keynote speech: Lightweight methods and their foundations
in chaos theory. In 6th IEEE International Enterprise Distributed Object
Computing Conference (EDOC 2002), Ecole Polytechnique Fédérale de
Lausanne (EPFL), Switzerland, 2002.
[10] Heather J Goldsby, Pete Sawyer, Nelly Bencomo, Betty HC Cheng, and
Danny Hughes. Goal-based modeling of dynamically adaptive system
requirements. In Engineering of Computer Based Systems, 2008. ECBS
2008. 15th Annual IEEE International Conference and Workshop on the,
pages 36–45. IEEE, 2008.
[11] Paola Inverardi. Software of the future is the future of software? In
International Symposium on Trustworthy Global Computing, pages 69–
85. Springer, 2006.
[12] Radhika Jain and Peter Meso. Theory of complex adaptive systems and
agile software development. AMCIS 2004 Proceedings, page 197, 2004.
[13] Philippe Kruchten. Agility with the rup. Cutter IT journal, 14(12):27–
33, 2001.
[14] Sotirios Liaskos, Alexei Lapouchnian, Yiqiao Wang, Yijun Yu, and Steve
Easterbrook. Configuring common personal software: a requirements-
driven approach. In 13th IEEE International Conference on Require-
ments Engineering (RE’05), pages 9–18. IEEE, 2005.
[15] Peter Meso and Radhika Jain. Agile software development: Adaptive
systems principles and best practices. Information Systems Management,
23(3):19–30, 2006.
[16] Dmitry Namiot and Manfred Sneps-Sneppe. On micro-services archi-
tecture. International Journal of Open Information Technologies, 2(9),
2014.
[17] Mark EJ Newman. Complex systems: A survey. arXiv preprint
arXiv:1112.1440, 2011.
[18] Luca Sabatucci and Massimo Cossentino. From Means-End Analysis to
Proactive Means-End Reasoning. In Proceedings of 10th International
Symposium on Software Engineering for Adaptive and Self-Managing
Systems, May 18-19 2015, Florence, Italy.
[19] Luca Sabatucci, Carmelo Lodato, Salvatore Lopes, and Massimo
Cossentino. Towards self-adaptation and evolution in business process.
In AIBP@ AI* IA, pages 1–10. Citeseer, 2013.
[20] Luca Sabatucci, Salvatore Lopes, and Massimo Cossentino. Self-
configuring cloud application mashup with goals and capabilities.
Cluster Computing - The Journal of Networks Software Tools and
Applications, 2017.