## 2 Background and Related Work
### Flexible Deployment  
In _distributed_ systems, software components are deployed to hardware elements, and this affects the notion of \"locality\", and the connection of computations to physical space, in ways that deserve attention. We generally refer to the hardware and the media supporting communication between hardware elements (in general, these hardware element are part of the communication network and the physical environment, where principles of stigmergy are applied [55] to support the exchange of information of sensors and actuators) as _(ICT) infrastructure_. The problem of _deployment_ is about how to map (components of) the system to available infrastructure. We use the same terminology of major literature [4; 56], where term \"distribution\" refers to deployment and term \"decentralization\" refers to the degree by which _adaptation control_ is handled by multiple interacting components rather than by a single, central component. Notice that decentralization of control is _orthogonal_ to distribution (i.e., to deployment) [4; 56]: this is indeed the main theme of this article, where we show how this principle can actually be implemented, methodologically. Though deployment is considered a research challenge for self-adaptive systems [56], few works address the tension between application logic, adaptation control, and deployment. Presently, infrastructure is increasingly heterogeneous, complex, and dynamic: computers range from low-powered, thin devices to large supercomputers; telecommunications technology can be wired or wireless, with many subtypes providing a wide range of capabilities and guarantees; storage and computational resources may be close, distant, or very distant to a communication endpoint--cf. edge, fog, and cloud computing; and finally, failures, interferences, replacements, extensions, can make the infrastructure dynamic. This richness is an opportunity but also a challenge for distributed computing paradigms, as typically each of them tends to address a specific deployment style. At a first instance, applications should aim at being agnostic with respect to the underlying infrastructure and deployment. This is supported by _abstraction_, hiding unnecessary details for better focusing on the problem at hand, _and_ by a _middleware_ that makes the abstraction operational--filling the \"gap\" with the underlying platform or infrastructure where the details do matter. This paper addresses the problem of identifying a suitable abstraction level to support deployment independence, or deployment agnosticism, in self-organizing systems. Instead of trying to match specific self-organizing models or patterns to the deployment at hand, we aim at a model by which general self-organizing strategies can be mapped to a variety of contexts. The key idea, inherited by approaches of so-called macro-programming [15; 57; 58], is to consider system behavior as a conceptually global computation performed on the whole set of system devices, and being effectively independent on details such as number and (mutual) location of devices. Declarative programming approaches can naturally be applied to promote the specification of _what_ the computational system should perform, abstracting from concrete aspects pertaining lower-level details. Facilitated by declarativity, one such macro-behavior should then be \"pulverized\" into smaller pieces or chunks of behavior, each to be executed in a continuous way across \"space\", i.e., across all the devices of a system. According to the self-organization principle, such chunks affect only a logical locality, in terms of perception/action over the local portion of the environment, and exchange of messages with neighbors. Deployment independence is then achieved by a suitable mapping of a general self-organization problem to the actual platform, and performed by spreading such chunks in the available devices.