Scafi: Scala with Computational Fields

Scaﬁ: Scala with Computational Fields
Roberto Casadei
PhD Student in CS&Eng
roby.casadei@unibo.it
Department of Computer Science and Engineering (DISI)
Alma Mater Studiorum – Università of Bologna
March 6, 2018
R. Casadei Intro SCAFI ACP Analysis 1/69

Outline
1 Introduction: Aggregate Computing
2 SCAFI: Practical Aggregate Programming in Scala
3 Analysis for an Aggregate Computing Platform (ACP)

Problem: design/programming CASs
Collective/Complex Adaptive Systems (CASs)
Structure: Environment + (Mobile, Large-scale) Networks of { people + devices }
Global interpretation: embedded devices collectively form a “diffused”
computational system

Towards an approach to CAS development
Issues ⇒ approach
• Large-scale ⇒ decentralised coordination
• Situatedness + distributed autonomy ⇒ substantial unpredictability ⇒ self-*
• Complex collective behavior ⇒ good abstractions, layered approach,
compositionality
Shifting the mindset: from local to global
• Declarativeness and the global viewpoint
• Crowd-aware services
• Failure recovery of enterprise services
• Distributed monitoring and reacting (e.g., temperature, ﬁre)
• Expected global behavior vs. traditional device-centric interface
⇒ Aggregate Programming [1]: a paradigm for programming whole aggregates of
devices.

Aggregate programming
From the local/device-centric viewpoint to the global/aggregate viewpoint
Aggregate programming: what
Goal: programming the collective behaviour of aggregates (of devices) ⇒
global-to-local
Aggregate programming: how
Prominent approach (generalizing over several prior approaches and strategies [2])
founded on ﬁeld calculus and self-org patterns
Computational ﬁelds as unifying abstraction of local/global viewpoints

Aggregate Programming Stack

Aggregate (computing) systems & Execution model
Structure ⇒ (network/graph)
A set of devices (aka nodes/points/things).
Each device is able to communicate with a subset of devices known as its
neighbourhood.
Dynamics
Each device is given the same aggregate program and works at async /
partially-sync rounds:
(1) Retrieve context
⇐ Messages from neighbours
⇐ Sensor values
(2) Aggregate program execution
⇒ export (a tree-like repr of computation) + output (result of last expr in body)
(3) Broadcast export to neighbourhood
(4) Execute actuators

Aggregate Computing (AC) » how
Repeated execution
Provides reactivity and incremental adaptivity
Broadcast + aligned interaction
Allows the construction of a “local” context for computation

Scala Fields Example Howto
Outline
Scala Fields
Example
Howto: operational instructions

Outline
Scala Fields
Example
Platforms
Requirements
Analysis
Current framework: SCAFI platform

SCAFI: Scala with Computational Fields
Goal: bring Aggregate Computing to the field of mainstream software development
What
SCAFI [7] is an integrated framework for building systems with aggregate
programming.
• Scala-internal DSL for expressing aggregate computations.
• Linguistic support + execution support (interpreter/VM)
• Correct, complete, efficient impl. of the Higher-Order Field Calculus
semantics [forte2015]
• Distributed platform for execution of aggregate systems.
• Support for multiple architectural styles and system configurations.
• Actor-based implementation (based on Akka).

Some papers about or involving scaﬁ
“Towards Aggregate Programming in Scala”
Casadei and Viroli 2016 [7]
“Simulating Large-scale Aggregate MASs with Alchemist and Scala”
Casadei, Pianini, and Viroli 2016 [5]
“On Execution Platforms for Large-Scale Aggregate Computing”
Viroli, Casadei, and Pianini 2016 [9]
“Programming Actor-based Collective Adaptive Systems”
Casadei and Viroli 2016 [6]
“Combining Trust and Aggregate Computing”
Casadei, Aldini, and Viroli 2018 [4]

Computational ﬁelds [8]
• (Abstract interpretation) Mapping space-time to computational objects
• (Concrete interpretation) Mapping devices to values: φ : δ →
• “Distributed” data structure working as the global abstraction
• The bridge abstraction between local behavior and global behavior
Discrete systems as an approximation of
spacetime

Field/aggregate computations
Global viewpoint
• Aggregate interpretation
• Natural/denotational semantics
• Program: computation over whole ﬁelds
• Output (at a given time): system-wide
snapshot of a computational ﬁeld
• Geometric view: properties of
collections of points
Local viewpoint
• Device-centric interpretation
• Operational semantics
• Program: steps of a single device
• Output (at a given time): latest value
yielded by the device
• Geometric view: properties of a single
point

So, what is an aggregate program?
• The global program
– "Local programs" obtained via global-to-local mapping
• May take the form of field calculus programs (in the representation given by
some PL)
– Actually, the field calculus is like FJ for Java, or the lambda calculus for Haskell
• An aggregate program consists of
1) A set of function definitions
2) A body of expressions.
• Example: an aggregate program in SCAFI
class MyProgram extends AggregateProgram with MyAPI {
def isSource = sense[Boolean]("source")
// Entry point for execution
override def main() = gradient(isSource)
}
:– Each device of the aggregate system is given an instance of MyProgram.
– Each device repeatedly runs the main method at async rounds of execution.

Computing with fields
Expressing aggregate/field computations in SCAFI
trait Constructs {
def rep[A](init: A)(fun: (A) => A): A
def nbr[A](expr: => A): A
def foldhood[A](init: => A)(acc: (A,A)=>A)(expr: => A): A
def aggregate[A](f: => A): A
// Not primitive, but foundational
def sense[A](name: LSNS): A
def nbrvar[A](name: NSNS): A
def branch[A](cond: => Boolean)(th: => A)(el: => A): A
}
:• Mechanisms for context-sensitiveness: nbr, nbrvar, sense
• Mechanisms for field evolution: rep
• Mechanisms for interaction: nbr
• Mechanisms for field domain restriction and partitioning: aggregate, branch
• Reference formal system: field calculus [forte2015, 8]

Simple fields
0
(x)=>x+1
true t<0,1>
Constant, uniform field: 5
– Local view: evaluates to 5 in the context of a single device
– Global view: yields a uniform constant field that holds 5 at any point (i.e., at any
device)
Constant, non-uniform field: mid()
– mid() is a built-in function that returns the ID of the running device

rep: dynamically evolving ﬁelds
def rep[A](init: A)(fun: (A) => A): A
rep
0
(x)=>x+1
t
v0
t
v1
..
rep(0){(x)=>x+1}
// Initially 0; state is incremented at each round
rep(0){ _+1 }
:
– Notice: the frequency of computation can vary over time and from device to
device
– In general, the resulting ﬁeld will be heterogeneous in time and space

nbr: interaction, communication, observation
def nbr[A](expr: => A): A
def foldhood[A](init: => A)(acc: (A,A)=>A)(expr: => A): A
nbr de
nbr{e}
φd=[d1→v1,..,dn→vn]
– Local view: nbr returns a field from neighbors to their corresponding value of the
given expr e
– Global view: a field of fields
– Needs to be reduced using a *hood operation
– foldhood works by retrieving the value of expr for each neighbour and then
folding over the resulting structure as you’d expect from FP.
foldhood(0)(_+_){ nbr{1} }
:

Context-sensitiveness and sensors
Local context:
1) The export of the previous computation
2) Messages received from neighbours
3) Values perceived from the physical/software environment
Sensing
def sense[A](name: LSNS): A
def nbrvar[A](name: NSNS): A
// Query a local sensor
sense[Double]("temperature")
// Compute the maximum distance from neighbours
foldhood(Double.MinValue)(max(_,_)){ // Also: maxHood {...}
nbrvar[Double](NBR_RANGE_NAME)
}
:– nbr queries a local sensor; nbrvar queries a "neighbouring sensor"
("environmental probe")

Field domain restriction
Alignment
• Aggregate computations can be represented as a trees
• Device exports are "paths" along these trees
• When two devices execute the same tree node, they are said to be aligned
• Interaction is possible only between aligned devices
Use cases for branch
• Partitioning the space into subspaces performing subcomputations
• Regulating admissible interactions (i.e., further restricting the neighbourhood)
def branch[A](cond: => Boolean)(th: => A)(el: => A): A
branch(sense[Boolean]("flag")){
compute(...) // sub-computation
}{
Double.MaxValue // stable value (i.e., not computing)
}
:

Functions
Two kinds of functions in SCAFI:
1) "Normal" Scala functions: serve as units for encapsulating behavior/logic
def foldhoodMinus[A](init: => A)(acc: (A,A) => A)(ex: => A): A =
foldhood(init)(acc){ mux(mid()==nbr(mid())){ init }{ ex } }
def isSource = sense[Boolean]("source")
:
2) First-class "aggregate" functions [forte2015] – which also work as units for
alignment
def aggregate[A](f: => A): A
def branch[A](cond: => Boolean)(th: => A)(el: => A): A =
mux(cond, ()=>aggregate{ th }, ()=>aggregate{ el })()
:

Example: the gradient [beal2008fastgradients]
def nbrRange = nbrvar[Double](NBR_RANGE_NAME)
def gradient(source: Boolean): Double =
rep(Double.PositiveInfinity){ distance =>
mux(source) {
0.0
}{
minHood { nbr{distance} + nbrRange }
}
}
:

Example: the channel I
Each device is given the same aggregate program:
class ChannelProgram extends AggregateProgram with ChannelAPI {
def main = channel(isSource, isDestination, width)
}
:
def channel(src: Boolean, dest: Boolean, width: Double) =
distTo(src) + distTo(dest) <= distBetween(src,dest) + width
:

Example: the channel II
trait ChannelAPI extends Language with Builtins {
def channel(src: Boolean, dest: Boolean, width: Double) =
distanceTo(src) + distanceTo(dest) <= distBetween(src, dest) + width
def G[V:OB](src: Boolean, field: V, acc: V=>V, metric: =>Double): V =
rep( (Double.MaxValue, field) ){ dv =>
mux(src) { (0.0, field) } {
minHoodMinus {
val (d, v) = nbr { (dv._1, dv._2) }
(d + metric, acc(v))
}
}
}._2
def broadcast[V:OB](source: Boolean, field: V): V =
G[V](source, field, x=>x, nbrRange())
def distanceTo(source: Boolean): Double =
G[Double](source, 0, _ + nbrRange(), nbrRange())
def distBetween(source: Boolean, target: Boolean): Double =
broadcast(source, distanceTo(target))
def nbrRange(): Double = nbrvar[Double](NBR_RANGE_NAME)
def isSource = sense[Boolean]("source"); def isDestination = sense[Boolean]("destination
")
}
:

Scaling with complexity
General coordination operators [10]
• Gradient-cast: accumulates values “outward” along a gradient starting from
source nodes.
def G[V:OB](src: Boolean, init: V,
acc: V=>V, metric: =>Double): V
:
• Converge-cast: collects data distributed across space “inward” by accumulating
values from edge nodes to sink nodes down a “potential” ﬁeld.
def C[V:OB](potential: V, acc: (V,V)=>V, local: V, Null: V): V
:
• Time-decay: supports information summarisation across time.
def T[V:Numeric](initial: V, floor: V, decay: V=>V): V
:
• Sparse-choice: supports creation of partitions and selection of sparse subsets
of devices in space
def S(grain: Double, metric: => Double): Boolean
:

Outline
Scala Fields
Example
Platforms
Requirements
Analysis

Aggregate Computing (AC) » what
Goal: programming the collective behaviour of aggregates of devices
Main ideas
Macro-level programming with automatic macro-micro bridging
Declarativity
Support for “engineered emergence”
Composition of aggregate behaviour with predictable dynamics
Layers of reusable abstractions
Abstraction from interaction-level and platform-level issues
Inherent adaptivity
Inherent resiliency
Operational ﬂexibility

Compositionality in AC: example
trait DistributedSum extends AggregateProgram {
def distribSum(size:Double, metric: =>Double, v:Double): Double =
???
}
trait Broadcast extends BlockG with ... { s: AggregateProgram =>
def broadcast[V: Bounded](src: Boolean, value: V): V =
G(src, value)(x => x, nbrRange)
}
trait SumCollect extends BlockC with ... { s: AggregateProgram =>
def sumCollect(target: Boolean, value: Double): Double =
C(value)(distanceTo(target,nbrRange))(_+_,0)
}
:
Distributed sum
Split the space into regions with grain size
Calculate the mean of ﬁeld v in each region
Collect the values and the number of nodes in the region
Compute the average
Propagate the computed value

trait DistributedSum extends AggregateProgram
with BlockG with BlockC with BlockS
with Broadcast with SumCollect with Utilities
{
def distribSum(size:Double, metric: =>Double, v:Double): Double = {
val leaders = S(size, metric)
???
}
}
:

trait DistributedSum extends AggregateProgram
with BlockG with BlockC with BlockS
with Broadcast with SumCollect with Utilities
{
val potential = distanceTo(leaders, metric)
???
}
}
:

trait DistributedSum extends AggregateProgram ... with SumCollect {
val collection = sumCollect(leaders, v)
val count = sumCollect(leaders, 1.0)
val avg = collection / count
}
}
:

trait DistributedSum extends AggregateProgram ... with Broadcast {
val collection = sumCollect(leaders, v)
val count = sumCollect(leaders, 1.0)
val avg = collection / count
broadcast(leaders, avg)
}
}
:

Outline
Scala Fields
Example
Platforms
Requirements
Analysis

Engineering CAS applications with AC platforms

SCAFI: state-of-art

Practical information
Repository URL: http://github.com/scafi/scafi
GitHub Pages page: https://scafi.github.io/
Maven Central artifacts
// Gradle
compile group: ’it.unibo.apice.scafiteam’, name: ’scafi-simulator-
gui_2.12’, version: ’0.2.0’
// SBT
libraryDependencies += "it.unibo.apice.scafiteam" %% "scafi-simulator-
gui" % "0.2.0"
:

Playing with scaﬁ in IntelliJ
1) git clone http://github.com/scafi/scafi && cd scafi
2) git checkout develop (or another branch s.t. feature-aligned-map)
3) Open Intellij, File -> Open -> select scaﬁ root directory
Select Java SDK
IntelliJ should prompt you with the list of modules to import
Right click on GUI simulation
examples and select Run
May take some time to download
dependencies and build

IntelliJ: some notions
Some notions of IntelliJ
Doc: https://www.jetbrains.com/help/idea/
Project: an organizational unit representing a complete SW solution
Project metadata stored as a set of XML files within .idea directory
Module: discrete unit of functionality, in the context of a project, which you can
compile, run, test and debug independently
Configuration info stored in a .iml file located (by default) in the module’s content root
folder.
The .idea directory (except workspace.xml) and .iml files should be version
controlled.
To develop an application, you need a SDK (e.g., Java or Android SDK)—to be
installed apart ant then configured in IntelliJ.
Working with Scala leverages a Scala plugin

Scafi: orient yourself in the codebase
Points of interest
Interpreter: Module core; component it.unibo.scafi.core.Semantics
Standard library: Module stdlib
Code examples: Module demos
Distributed systems: folders demos/ or examples/
Plain simulations: examples/DemoSequence.scala
GUI-based simulations: folder sims/
Unfinalised complex libs: folder lib/
Simulator core: Module simulator; pkg it.unibo.scafi.simulation
Semantics tests: [core]/test
Functional tests: [tests]/test
For details on the architecture of scafi, refer to [3]

Scaﬁ and Alchemist I
Scaﬁ is shipped with Alchemist (since v.6.0.0)
Example project (from [4]):
https://bitbucket.org/metaphori/trusted-ac-experiments
Differences wrt Protelis
incarnation: scafi # Instead of ’protelis’
pools:
- pool: &program
- time-distribution: 1
type: Event
actions:
- type: RunScafiProgram # Not ’RunProtelisProgram’
parameters: [gradient, 20]
:

Scafi and Alchemist II
And there’ll be some .scala in classpath with file as follows
import it.unibo.alchemist.model.scafi.ScafiIncarnationForAlchemist._
trait ScafiAlchemistSupport { self: AggregateProgram =>
def env = sense[NodeManager]("manager")
}
class gradient extends AggregateProgram with ScafiAlchemistSupport {
override def main(): Double = {
val someParam = env.get[Double]("parameter")
env.put[Double]("someKey", 77.7)
???
}
}
:
Import the scafi-Alchemist incarnation (line 1)
Create a class that extends AggregateProgram and defines main()

Platforms Requirements Analysis Current framework: SCAFI platform
Outline
Platforms
Requirements
Analysis

Outline
Scala Fields
Example
Platforms
Requirements
Analysis

The starting point of any engineering process
A vision that must be made concrete / top-down or bottom-up

Applications as the interface to the needs
Abstractly deﬁned until some concrete underlying technology is identiﬁed

Aggregate Computing: bridging the gap to SASO systems
Supports the development and execution of Aggregate Computing applications

Zooming the AC layer

Outline
Scala Fields
Example
Platforms
Requirements
Analysis

Requirements for an Aggregate Computing platform
High-level, Functional
FR1 Support the speciﬁcation and conﬁguration of AGGREGATE-SYSTEMs
FR2 Support the runtime execution of AGGREGATE-APPLICATIONs
High-level, Non-functional
NR1 Scalability to a large number of NODEs
NR2 Reliability
An AGGREGATE-SYSTEM made of unreliable INFRASTRUCTURAL-COMPONENTs and
unreliable NODEs should be able to continue operation even in face of faults.

Outline
Scala Fields
Example
Platforms
Requirements
Analysis

Requirements analysis
Approach: informal but systematic (cartesian)
Give names to things
Reﬁne meaning and relationships
Explore in (mentally simulated) use, adopt perspectives and visualize
(Then, formalize early, when enough committed)
AGGREGATE-LOGIC: the representation-independent view of some
aggregate-level behaviour in space/time
AGGREGATE-PROGRAM: an AGGREGATE-LOGIC expressed in some executable
representation
AGGREGATE-SYSTEM: a set of networked NODEs supporting the collective
execution of AGGREGATE-PROGRAMs
AGGREGATE-APPLICATION: a particular AGGREGATE-LOGIC running on a certain
AGGREGATE-SYSTEM, aimed at solving some problem in some context

High-level, logical, informal model
Starting point for a systematic characterisation of our (fuzzy) class of systems
We think of no speciﬁc application/system, but a range of applications/systems
to support/drive analysis and be concrete

Structure / Interaction / Behaviour decomposition
(Logical) Structure
DEVICEs (aka NODEs, AGENTs)
Have an identity (UID)
Have SENSORs and ACTUATORs
(Logical) Behaviour/Interaction
A DEVICE can only directly communicate with the DEVICEs of its
NEIGHBOURHOOD
A DEVICE computes its part of AGGREGATE-LOGIC on a round-by-round basis
Steps of a round of execution
1) Retrieve the device’s CONTEXT (SENSOR-DATA, NBR-DATA)
2) Execute LOCAL-AGGREGATE-LOGIC to produce OUTPUT + EXPORT
3) Broadcast EXPORT to NEIGHBOURHOOD
4) Feed ACTUATORS with OUTPUT
This characterization is mainly logical and “standard”
Many questions arise: who? what? where? when? how?

Analysis » execution rounds I
SCHEDULING-POLICY: who decides when a round has to be executed?
A SCHEDULER (owned by a device or external)
Construction of the CONTEXT using up-to-date SENSOR-DATA and NBR-DATA
Ideally, we’d like to separate the time/frequency in which these information are
collected from the time in which they are received
Retrieval of SENSOR-DATA: request/response to device’s SENSOR or sampling of
an incoming SENSOR-DATA-STREAM
Note: location data (e.g., GPS coords) may need to be sent to the
TOPOLOGY-MANAGER
Retrieval of NBR-DATA: request/response to a FIELD-MANAGER or sampling of an
incoming NBR-DATA-STREAM
Who actually executes the AGGREGATE-LOGIC for a given DEVICE?
An AGGREGATE-LOGIC-EXECUTOR (owned by a device or external)

Analysis » execution rounds II
Broadcast of EXPORT to NEIGHBOURHOOD
By the DEVICE itself (if it knows how to reach its NEIGHBOURHOOD)
But the DEVICE’s awareness of communication is questionable
“No matter who you are! I know where you are” [zambonelli2004spatial]
The DEVICE may simply send its computation descriptors (EXPORTs) to the
FIELD-MANAGER
The FIELD-MANAGER in turn may delegate the task to an EXPORT-PROPAGATOR
which must then know the NEIGHBOURHOODs and how to reach them
Invocation of ACTUATORs
In general, we may have ACTUATION-DATA-STREAMs directed to ACTUATORs
which may be controlled by (but still decoupled from) rounds.

Analysis » neighbourhood
NBR-POLICY: how is NEIGHBOURHOOD determined?
May be communication-determined (i.e., my neighbours are those I can reach)
May be spatially-determined (i.e., derived from the devices’ position in space)
May be ad-hoc (i.e., application-speciﬁc)
Who owns the knowledge of a device’s NEIGHBOURHOOD?
A TOPOLOGY-MANAGER (owned by a device or external)
Who uses the knowledge of a device’s NEIGHBOURHOOD?
The EXPORT-PROPAGATOR
Properties of NEIGHBOURHOOD
It is usually dynamic
Can be asymmetric

Analysis » conﬁguration
How do components locate (the address of) other components?
DEVICEs should be addressable to support e.g. peer-to-peer interaction or the
the delivery of ACTUATION-DATA
The mappings between DEVICEs’ UIDs and their ADDRESS may be kept in a
REGISTRY
Devices should also be given some CONFIGURATION data – so that they know the
ADDRESS of required services
How do AGGREGATE-LOGIC-EXECUTOR obtain the AGGREGATE-LOGIC to execute?
Can be provided at deployment or conﬁguration time

Logical components emerging from analysis (dev-centric)
It comes natural to assign many responsibilities to the DEVICEs (cf., p2p setup)..

Logical components emerging from analysis (sys-centric)
It comes natural to consider DEVICEs only as situated contexts..

Many kinds of deployments
Such ﬂexibility demands for ﬂuid responsibilities

The data perspective
Data payloads
SENSOR-DATA: map from sensor UIDs to sensor values
ACTUATION-DATA: map from actuator UIDs to actuation values
NBR-DATA (i.e., EXPORTS): map from neighbour UIDs to exports
CONTEXT-DATA = SENSOR-DATA + NBR-DATA
Control data
SCHEDULE-DATA (i.e., TICKs)
...
Configuration data
Deployment data, addresses, ...
...
Analysis from a data (flow) perspective
» On an app-specific basis, analysis of Volume-Velocity-Variety-Veracity
» Further analysis: persistent vs. transient data
» Further analysis: replication, partitioning, ...
» Analysis of data flow can help architectural design (cf., reactive architectures)

Outline
Scala Fields
Example
Platforms
Requirements
Analysis

SCAFI: state-of-art

AC Platform: state-of-art
Key features
Actor-based (Akka)
Two styles
a) fully decentralised (P2P)
b) server-based (mediating interactions)
Simple object-oriented API façade
Easy conﬁguration (ﬁle, cmd-line, programmatically)
Limitations (work-in-progress)
Not ready for use across the Internet
Serialization issues and constrained architecture due to nested design
Tightly coupled with SCAFI-core

AC actor platform: overview

AC actor platform: building

AC actor platform: modular actor design

AC actor platform: styles

Quick platform setup
// STEP 1: CHOOSE INCARNATION
import it.unibo.scafi.incarnations.{ BasicActorP2P => Platform }
// STEP 2: DEFINE AGGREGATE PROGRAM SCHEMA
class Demo_AggregateProgram extends Platform.AggregateProgram {
override def main(): Any = foldhood(0){_ + _}(1)
}
// STEP 3: DEFINE MAIN PROGRAM
object Demo_MainProgram extends Platform.CmdLineMain
:
1) Demo_MainProgram -h 127.0.0.1 -p 9000
-e 1:2,4,5;2;3 --subsystems
127.0.0.1:9500:4:5
--program "demos.Demo_AggregateProgram"
2) Demo_MainProgram -h 127.0.0.1 -p 9500
-e 4;5:4
--program "demos.Demo_AggregateProgram"
:

Manual node setup
// STEP 1: CHOOSE INCARNATION
import scafi.incarnations.{ BasicActorP2P => Platform }
import Platform.{AggregateProgram,Settings,PlatformConfig}
// STEP 2: DEFINE AGGREGATE PROGRAM SCHEMA
class Program extends AggregateProgram with CrowdAPI {
// Specify a "dangerous density" aggregate computation
override def main(): Any = crowdWarning(...)
}
// STEP 3: PLATFORM SETUP
val settings = Settings()
val platform = PlatformConfig.setupPlatform(settings)
// STEP 4: NODE SETUP
val sys = platform.newAggregateApplication()
val dm = sys.newDevice(id = Utils.newId(),
program = Program,
neighbours = Utils.discoverNbrs())
val devActor = dm.actorRef // get underlying actor
:

References I
Jacob Beal, Danilo Pianini, and Mirko Viroli. “Aggregate Programming for the Internet of Things”.
In: IEEE Computer (2015). ISSN: 1364-503X.
Jacob Beal et al. “Organizing the Aggregate: Languages for Spatial Computing”. In: CoRR
abs/1202.5509 (2012).
Roberto Casadei. “Aggregate Programming in Scala: a Core Library and Actor-Based Platform for
Distributed Computational Fields”. MA thesis. URL:
http://amslaurea.unibo.it/id/eprint/10341.
Roberto Casadei, Alessandro Aldini, and Mirko Viroli. “Combining Trust and Aggregate Computing”.
In: Software Engineering and Formal Methods. Ed. by Antonio Cerone and Marco Roveri. Cham:
Springer International Publishing, 2018, pp. 507–522. ISBN: 978-3-319-74781-1.
Roberto Casadei, Danilo Pianini, and Mirko Viroli. “Simulating Large-scale Aggregate MASs with
Alchemist and Scala”. In: Proceedings of the Federated Conference on Computer Science and
Information Systems (FedCSIS 2016). Ed. by Maria Ganzha, Leszek Maciaszek, and
Marcin Paprzycki. Gdansk, Poland: IEEE Computer Society Press, 2016.
Roberto Casadei and Mirko Viroli. “Programming Actor-based Collective Adaptive Systems”. In:
AGERE16 workshop. To appear. ACM SIGPLAN. 2016.
R. Casadei Appendix References 68/69

References II
Roberto Casadei and Mirko Viroli. “Towards Aggregate Programming in Scala”. In: First Workshop
on Programming Models and Languages for Distributed Computing. PMLDC ’16. Rome, Italy: ACM,
2016, 5:1–5:7. ISBN: 978-1-4503-4775-4. DOI: 10.1145/2957319.2957372. URL:
http://doi.acm.org/10.1145/2957319.2957372.
Ferruccio Damiani, Mirko Viroli, and Jacob Beal. “A type-sound calculus of computational ﬁelds”.
In: Science of Computer Programming 117 (2016), pp. 17 –44. ISSN: 0167-6423. DOI:
http://dx.doi.org/10.1016/j.scico.2015.11.005. URL:
http://www.sciencedirect.com/science/article/pii/S0167642315003573.
Mirko Viroli, Roberto Casadei, and Danilo Pianini. “On Execution Platforms for Large-Scale
Aggregate Computing”. In: 3rd International Workshop on Collective Adaptation in Very Large
Scale Ubicomp (VLSU): Towards a Superorganism of Wearables - UbiComp. Heidelberg, Germany,
2016.
Mirko Viroli et al. “Efﬁcient Engineering of Complex Self-Organising Systems by Self-Stabilising
Fields”. In: IEEE Self-Adaptive and Self-Organizing Systems 2015. IEEE, 2015, pp. 81–90. DOI:
10.1109/SASO.2015.16.
R. Casadei Appendix References 69/69

Scafi: Scala with Computational Fields

More Related Content

What's hot (20)

Similar to Scafi: Scala with Computational Fields (20)

More from Roberto Casadei (16)

Recently uploaded (20)

Scafi: Scala with Computational Fields